As per the graphhopper 0.9 release, it says
A new graph change API to change road speed and access properties, #845. Can be applied before preprocessing or per-request.
how do i use it, can someone point me to the documentation with example ?
thanks for your support
Indeed there is no good documentation at the moment. Have a look into the tests:
Disable speed mode - set prepare.ch.weightings=no in the config.properties
Create a GeoJSON where e.g. you want to change the access properties to false (blocking):
{
"type": "FeatureCollection",
"features": [{
"type": "Feature",
"geometry": {
"type": "Point",
"coordinates": [1.521692, 42.522969]
},
"properties": {
"vehicles": ["car"],
"access": false
}
}]
}
Then POST this as json to the /change endpoint.
Please note that in 0.9.0
for geometry type only Point, MultiPoint and LineString are supported.
for the properties only access (Boolean) and speed (Double) are supported that can be applied to multiple vehicles (but only in both directions).
You can also use the Java equivalent.
Please see this issue to improve the documentation.
Related
According to the standard, there's a type such as "object" shown below. What is this type for and what other types can we use? Can I use like "art?"
{
"title": "Asset Metadata",
"type": "object",
"properties": {
"name": {
"type": "string",
"description": "Identifies the asset to which this NFT represents"
},
"description": {
"type": "string",
"description": "Describes the asset to which this NFT represents"
},
"image": {
"type": "string",
"description": "A URI pointing to a resource with mime type image/* representing the asset to which this NFT represents. Consider making any images at a width between 320 and 1080 pixels and aspect ratio between 1.91:1 and 4:5 inclusive."
}
}
}
It's the datatype of the described item according to the JSON Schema specification. It's a standard used in other development fields as well - not limited just to NFTs or blockchain development.
There is a list of default allowed type values: http://json-schema.org/understanding-json-schema/reference/type.html
It's possible to create a custom type in JSON Schema, but the limited scope of what the "ERC-721 Metadata Document" document allows, doesn't effectively allow for custom types.
TLDR: Cannot use type: "art" in an "ERC-721 Metadata Document". Can use it in a larger scope (e.g. a REST endpoint definition).
I am using FIWARE for some time-series data of heat-pumps. I use Orion 2.5.2 and Quantumleap 0.7.6.
My entities have a lot of attributes which are reported in batches. Those data-batches have individual time-stamps for each attribute, so the exact time of a measurement is known (this is also rather important). I use a little python tool to split these batches and send them to the iot-agent seperately via http, using the time-stamp parameter.
I end up with an entity like this:
...
"attrs": {
"temp_outdoor": {
"value": "-6.6",
"type": "Number",
"md": {
"TimeInstant": {
"type": "DateTime",
"value": 1613148707.7509995
}
},
"mdNames": [
"TimeInstant"
],
"creDate": 1612780352.3855166,
"modDate": 1613148716.1449544
},
"temp_return_flow": {
"value": "40.8",
"type": "Number",
"md": {
"TimeInstant": {
"type": "DateTime",
"value": 1613149016.394001
}
},
"mdNames": [
"TimeInstant"
],
"creDate": 1612780352.3855166,
"modDate": 1613149021.5991328
},
"TimeInstant": {
"value": 1613149101.1790009,
"type": "DateTime",
"mdNames": [],
"creDate": 1612780352.3855166,
"modDate": 1613149102.5100079
},
...
I don't really care about the creDate and modDate but about the TimeInstant in "md" of each attribute. Also the bottom "TimeInstant" attribute is just the value of the last Data-Point I think? I would like to use the "md" TimeInstant to create the time_index in CrateDB. Hence, the reported time has to be the custom-metadata one. I tried some different values while subscribing to Quantumleap but can't get it right.
Can someone tell me how to specify md->TimeInstant as value for time_index?
I find the documentation to be rather unconclusive on that topic and hope that someone has already solved that mistery and might let me in on it :)
Thanks!
Looking at your payload, it is not clear what's the NGSI model used, which would be the information need to help you. Anyhow, as reported by the documentation:
A fundamental element in the time-series database is the time index. You may be wondering... where is it stored? QuantumLeap will persist the time index for each notification in a special column called time_index.
The value that is used for the time index of a received notification is defined according to the following policy, which choses the first present and valid time value chosen from the following ordered list of options.
Custom time index. The value of the Fiware-TimeIndex-Attribute http header. Note that for a notification to contain such header, the corresponding subscription has to be created with an httpCustom block, as detailed in the Subscriptions and Custom Notifications section of the NGSI spec. This is the way you can instruct QL to use custom attributes of the notification payload to be taken as time index indicators.
Custom time index metadata. The most recent custom time index (the value of the Fiware-TimeIndex-Attribute) attribute value found in any of the attribute metadata sections in the notification. See the previous option about the details regarding subscriptions.
TimeInstant attribute. As specified in the FIWARE IoT agent documentation.
TimeInstant metadata. The most recent TimeInstant attribute value found in any of the attribute metadata sections in the notification. (Again, refer to the FIWARE IoT agent documentation.)
timestamp attribute.
timestamp metadata. The most recent timestamp attribute value found in any of the attribute metadata sections in the notification. As specified in the FIWARE data models documentation.
dateModified attribute. If you payed attention in the Orion Subscription section, this is the "dateModified" value notified by Orion.
dateModified metadata. The most recent dateModified attribute value found in any of the attribute metadata sections in the notification.
Finally, QL will use the Current Time (the time of notification reception) if none of the above options is present or none of the values found can actually be converted to a datetime.
This means that (and if you understand NGSI model, the documentation is quite clear), with the following payload
{
"id": "Room1",
"type": "Room",
"temperature": {
"value": 24.2,
"type": "Number",
"metadata": {
"myTime": {
"type": "DateTime",
"value": "2020-12-16T17:13:46.00Z"
}
}
},
"pressure": {
"value": 720,
"type": "Number",
"metadata": {
"TimeInstant": {
"type": "DateTime",
"value": "2020-12-16T17:13:46.00Z"
}
}
},
"dateObserved": "2021-02-02T00:00:00.00Z",
"dateCreated": "2019-09-24T12:49:02.00Z",
"dateModified": "2021-02-02T23:00:50.00Z",
"TimeInstant": {
"type": "DateTime",
"value": "2020-12-16T17:13:46.00Z"
}
}
If in the notification you set a custom header Fiware-TimeIndex-Attribute=dateObserved, time_index will be the value of dateObserved. If you set Fiware-TimeIndex-Attribute=myTime it will be the myTime attribute metadata linked to temperature. If not Fiware-TimeIndex-Attribute header is passed, the most recent value of metadata attribute TimeInstant will be picked. Suppose to remove the metadata attribute TimeInstant in the payload above, then attribute TimeInstant will be picked. If TimeInstant attribute is removed as well, dateModified value will be picked. In case that attribute is not received as well, current time is used.
Can I use coordinates [Lat,Long, Elevation, Time] in a GeoJSON file so that file can be used by any other application?
{ "type": "Feature",
"geometry": {
"type": "LineString",
"coordinates": [
[102.0, 0.0,805,"22-08-2016 13:04:04"],
[103.0, 1.0,806,"22-08-2016 13:05:04"],
[104.0, 0.0,804,"22-08-2016 13:06:00"],
[105.0, 1.0,808,"22-08-2016 13:07:40"]]
},
"properties": {
"prop0": "value0",
"prop1": 0.0
}
}
// "Using elevation and time in coordinate array elevation as numeric and time in string format
This would be the geoJSON specification.
As they say in the section about extending geoJSON you can extend to add foreign members, but anything that alters the structure of the already defined types is referred to as versioning geoJSON, and as such that kind of object should not be called a geoJSON.
You can check the specifications they define for a position array.
TL;DR you can, but it wont be a geoJSON anymore and parsers are not guaranteed to work with it.
I have an API used by a mobile app. It has an endpoint named /feed
It returns a collection of objects with different types.
[
{
"type": "USER",
"value": 5632,
},
{
"type": "IMAGE",
"value": 1412,
},
]
I am wondering, whether the type should be a string or a number like this:
[
{
"type": 100,
"value": 5632,
},
{
"type": 200,
"value": 1412,
},
]
Is there a significant difference between the two? The IOS developer of the app stated that numbers are easier to compare than strings.
Found a similar question but it does not have any answers.
Yes, numbers are faster to compare than strings, that's a fact. Then, whether it is a significant gain or not will depend on the algorithm where this json is parsed, the quantity of data it contains, etc. And furthermore, sacrificing code design for performances is often a bad option. It really depends on your project.
After seeing a recent video by the Google Devs I decided to do a regional map of the UK. There were a couple of possibilities mentioned on this site that I've since had to dismiss*
So I ended up using this site (example page of data downloads): http://mapit.mysociety.org/area/11804.html
Notice the GeoJSON download as the third link down? Its about a 1Mb file size. When I first tried using it with my map:
function initMap(){
var ukc = new google.maps.LatLng(54.8, -4.6);
var mapOptions = {
zoom: 5,
center: ukc
};
map = new google.maps.Map(document.getElementById('map-canvas'), mapOptions);
map.data.loadGeoJson('http://local.mapsite.com:8080/app/jsondata/eastern.json');
}
$(document).ready(function(){
initMap();
});
I got the above error: Uncaught InvalidValueError: not a Feature or FeatureCollection
Fix Attempt 1 - Google it
Googling the error came back with nothing useful.
Fix Attempt 2 - Shrink it
I thought maybe it was the sheer size of the beast so I shrank it using mapshaper.org to a more manageable 10K. Still no luck!
Fix Attempt 3 - Lint it
Maybe my GeoJSON was badly formatted? But how could it be considering it was right there working on mapit.org but I found this wonderful site for linting GeoJSON data: http://geojsonlint.com/ - The linting worked! Apparently the GeoJSON worked so well that it drew my polygon of East Anglia on the UK in all its glory (note geojsonlint uses OpenStreetMap). But still No Luck
Fix Attempt 4 - TopoJson
Hoping I could combine the regions and compress at the same time I thought desperately that topojson would work. I tried - I still got that same error. Here's a link to my topojson file shared on Google Drive: someregions.json No luck.
Fix Attempt 5 - Add Feature code to start of JSON
The current GeoJSON file starts
{"bbox":[-0.745702,51.448473,1.767999,52.98991],"type":"GeometryCollection","geometries":...
I added:
{"type": "Feature", "bbox":[-0.745702,51.448473,1.767999,52.98991],"type":"GeometryCollection","geometries":
Fix Attempt 6
Retry different regions as they donm't contain the bbox parameter near the start but simply start
{ "type": "Polygon", "coordinates": [ [ [ -3.155785, 53.427385 ], [ -3.151533, 53.427328 ], [...
Still no luck.
In (Failed) Conclusion
Even though I proved my file was small enough, linted and worked elsewhere I still got those infuriating error messages from the console when attempting to put them on my map.
Uncaught InvalidValueError: not a Feature or FeatureCollection
Here is my shrunk GeoJSON file publically shared via GDrive: https://drive.google.com/file/d/0B42Aec8RKcHtNVNZZUxqV0Y5Rkk/edit?usp=sharing
My next attempts will involve topojson to compress all regions into one with internal borders but I wanted to check here first to see if anyone knows what my problem could be? Because that may be another few hours of futile energy wasted.
* Attempting to use Ordanance Survey data failed as they provided SHD data and not SHP as stated in a previous question on the subject. So I couldn't convert it into GeoJSON using ogr2ogr.
The specification for GeoJSON can be found at http://geojson.org/geojson-spec.html
Relevant (though experimental) Google Maps API documentation can be found at https://developers.google.com/maps/documentation/javascript/3.exp/reference#Data
So it looks like for GeoJSON to be acceptable by Google Maps, you need to wrap a Polygon (or similar) returned by MapIt in a Feature or FeatureCollection, here's an example for bermuda-triangle:
{ "type": "FeatureCollection",
"features": [
{ "type": "Feature",
"geometry": {
"type": "Polygon",
"coordinates":
[
[
[-80.190262,25.774252],
[-66.118292,18.466465],
[-64.75737,32.321384],
[-80.190262,25.774252]
]
]
}
}
]
}
for the data provided by http://mapit.mysociety.org/area/11804.html it has to be:
{ "type": "FeatureCollection",
"features": [
{ "type": "Feature",
"geometry": /** paste here the complete output of
http://mapit.mysociety.org/area/11804.geojson **/
}
]
}
I had the same problem (or at least similar) and solved it by introducing one extra step.
Origin of the data:
My semantic Network delivers on a first round request the data about the caves in Southern France in GeoJSON format. This is directly imported via:
map.data.loadGeoJson(theUrl);
As we might want to work independent of the semantic network with these data (the app is a thick client) the caves are locally stored via jStorage.
Iterating of the features of the map and storing these objects directly in jStorage failed because of circular references.
I made a handcrafted routine (not generic enough but suiting the purpose) to transform the map.data.Feature into a javascript object that could be stored.
When getting the data from the store:
var cave = $.jStorage.get(key);
map.data.addGeoJson(cave);
throws the Uncaught InvalidValueError: not a Feature or FeatureCollection error.
But:
var geojson = JSON.parse(cave);
map.data.addGeoJson(geojson);
Works fine.
My interpretation is that the function addGeoJson needs a javascript object and not a string.
Sample geoJson (the orignal "cave") value:
{ "type": "Feature", "geometry": {"type": "Point", "coordinates": [5.368743302306143, 44.0421921072459]},"id": "84.MON.014", "properties": {"nom": "Aven du Grand Guérin", "nid": "7b4703-f387f6f544-0750e59f441be7bb30a7e097c5d725f7", "nature": "Aven", "nodeTime": 1400743203325, "dataId": "5b66137c-1461fdfe5ca-f528764d624db129b32c21fbca0cb8d6", "status": 1}}
If you are looking to load the data to a JavaScript variable then use this
var map = new google.maps.Map(document.getElementById("googleMap"), mapProp);
var data = map.data.loadGeoJson("GeoJSONfilename.geojson");
googleMap is the div id where you want your map to be presented, and GeoJSONfilename.geojson where you saved your GeoJSON data.
I had the same error, but the problem was something very simple. On my GeoJSON, instead of
"type": "Feature"
I had
"type": "feature"
(note the lowercase 'f')
Once I fixed this, the error was gone.
I had the same error message. My .json file missed one line of code on line 2:
"type": "FeatureCollection",
Before I had in my .json-file:
{
"features": [
{
"type": "Feature",
"properties": {
"stroke": "#ECD911",
"stroke-width": 5
},
"geometry": {
"type": "LineString",
"coordinates": [
[13.295141458511353, 52.5069227387063],
[13.295291662216187, 52.50721006978328],
[13.29544186592102, 52.507471278223285]
]
}
}
]
}
It fixed it for me with:
{
"type": "FeatureCollection",
"features": [
{
"type": "Feature",
"properties": {
"stroke": "#ECD911",
"stroke-width": 5
},
"geometry": {
"type": "LineString",
"coordinates": [
[13.295141458511353, 52.5069227387063],
[13.295291662216187, 52.50721006978328],
[13.29544186592102, 52.507471278223285]
]
}
}
]
}