I have a question regarding the Route Match Extension.
Should I expect any gaps in the GPS trace to be snapped to the road network as the most probable route, or to be represented as a straight line from A to B?
No, you should not expect any gaps here. The Route Match Extension works well with these locations. I reproduced it on a local demo (same gap between #3 and #4):
You should not use a different map source for displaying.
Related
I need to get as much info as possible based on GPS - road type, interaction or not, etc.
What is the right way to get it?
I've seen this question and answer
HERE maps - getting road type based on gps coordinates
but the provided link doesn't work anymore.
It looks like you want to migrate to the Routing API, specifically the getRoute call, https://developer.here.com/documentation/routing/dev_guide/topics/resource-get-route.html#resource-get-route. In the details here you can see the attribute, linkAttributes, which lets you return the information you are looking for I believe. Let me know if not.
It looks like the right way to do it to use the next POST request:
https://fleet.api.here.com/2/calculateroute.json?app_id=APP_ID&app_code=APP_CODE&routeMatch=1&mode=car&attributes=LINK_ATTRIBUTE_FCn%28%2A%29
Example of the body:
LATITUDE,LONGITUDE
37.401996,-122.041338
37.402948,-122.045580
37.403690,-122.049024
I want to measure the distance to the next intersection/traffic light based on a gps location(s).
I DON’T have a route (i.e. no destination point) but I can get gps locations every second (while on the move).
Is it possible to get the information using HERE APIs?
I understand that there is no direct way (specific api) to do it, but I would appreciate any idea that will fulfill my needs.
The general idea that I came up with was getting at least 2 gps points to understand the direction, then getting link_id for current location and try to get the next links in same direction/road and find if any of them are intersections...
I didn’t find a way to do it. Any ideas?
There is no direct API for this however there is an idea that you have to crawl along the link into the direction determined like you outlined (or better by sending the last few GPS points to our Route Matcher (aka RME)) until you reach an intersection.
And this can be achieved with a concept of "electronic horizon" in SDK. It takes your current road link and driving direction and then crawls forward over the upcoming links until an intersection comes (or even beyond taking the most probable choice). mobile SDK has this "electronic horizon" feature.
https://developer.here.com/documentation/android-premium/dev_guide/topics/electronic-horizon.html
I am using here map api for getting nearby places but it is giving blank data (/places/v1/descover/here). While in /descover/explore/ it is giving so many records on same lat long. I am sharing screenshot for better understanding, Visit https://www.awesomescreenshot.com/image/3804672/65583a3e4f228ade754feba101ef26eb.
This depends on the use case you have.
The Here entrypoint helps users to identify direct places at their location or at a point selected on a map by returning places close to a given point, sorted by distance. (Normally the closest known places are returned, but if the uncertainty in the position is high then some nearer places are excluded from the result in favour of more popular places in the area of uncertainty.)
Then again the Explore entrypoint retrieves a complete list of relevant places nearby a given position or area. It answers the question "What interesting places are in the viewport of the map?" The results presented to the user are confined to those located in the current map view or search area and are ordered by popularity.
In general I would recommend to use the Explore entrypoint as the Here one is deprecated:
https://developer.here.com/documentation/places/topics_api/entrypoint-maturity-availability.html
I have built an small application which calls the Google Directions API in Transit mode. It works - nevertheless it returns only one possible route, so it shows no alternatives. Usually I expect 3-4 options to choose from.
Example:
http://maps.googleapis.com/maps/api/directions/json?origin=bieberstrasse,+dusseldorf&destination=norf,+neuss&sensor=false&mode=transit&departure_time=1399399424
The returned JSON structure has the expected "routes" array, but this array always has only one element. I have tried it with addresses in Brazil and Germany - it doesn't matter the country, I only get one single route.
Did I miss some parameter? Could someone help me with it?
If you want alternative routes, specify the request parameter alternatives=true:
http://maps.googleapis.com/maps/api/directions/json?alternatives=true&origin=bieberstrasse,+dusseldorf&destination=norf,+neuss&sensor=false&mode=transit&departure_time=1399399424
I am trying to get the distance traveled on a transit route -- particularly San Francisco MUNI, but the standards NextBus, GTFS, and Google Maps API appear to be universal. I'm comfortable using any of these APIs, I'm just not sure how to go about this problem.
The easy way - ask Google Maps (this using webservices, but there is also the javascript API):
http://maps.googleapis.com/maps/api/directions/json?origin=37.7954199,-122.397&destination=37.7873299,-122.44691&sensor=false&mode=transit&departure_time=1348109609&alternatives=true
this JSON includes distance traveled, but there are two issues:
Google does not allow you to use this data unless you're displaying a map, which I don't want to do
I would need to ensure that the distance returned is for the correct route/line, since it can/will give multiple routing options. This is probably doable but would require more logic.
EDIT: using alternatives=true (or provideRouteAlternatives: true using the javascript API) only returns a maximum of 3 routes, which here in SF often doesn't include the route I'm looking for (other transit agencies, multiple lines on the same route, etc). So this isn't such a great option.
NextBus:
example route config:
http://webservices.nextbus.com/service/publicXMLFeed?command=routeConfig&a=sf-muni&r=1
The coordinates for each stop are given, but connecting the dots on those is not the same as the route taken -- it will cut corners, etc, and I need this to be accurate. The actual route taken is given under <path>/<point>, but I don't see any obvious correlation between stop and path coordinates. Plus, NextBus says in their documentation (p.10 near the bottom) that you should NOT connect points between <path> segments, they're only meant for drawing on a map and can overlap.
GTFS:
The GTFS data also separates stop and "shape" coordinates (like NextBus paths). Unfortunately, the coordinates are slightly different for the same stops between NextBus and GTFS (rounding), though the stop ID/tags are the same. Also, the data files are in the megabytes, and I need to use this for a mobile app. I suppose I could put all the data in a database and query that, but that still leaves figuring out how to correlate the stops with the shape. The "shapes_distance_traveled" column in the shapes.txt file is especially promising. MUNI chooses to leave the optional "shapes_distance_traveled" field out of stop_times.txt, though.
Any advice would be appreciated, I understand this seems like an epic task to get a simple value. Maybe I'll just throw a map in to legitimately use the distance :)
Instead of using Google Maps, I would look into the un-encumbered licensing of OpenStreetMap. There are multiple
routing engines that can use OSM data. Personally, I would use routing in PostGIS or SQLite, but depending on your skillset you might choose another.
You've clearly done your research, (+1), and as you said, the easy way is to ask Google. If it is worth for you then you might want to look into purchasing a business licence to use the Google Maps API, and negotiate with them about the requirement of displaying a map. That's the only legal way I can think of with the Google API. Alternatively, you can try building you own routing engine with data from the TIGER data set, which is freely available from the US Census Bureau, but again, as you said, it may seem like an epic task. :-)