[GraphHopper] Calculating fastest path with A*/Dijkstra with CH disabled

mythex3cutioner . mizantropy at gmail.com
Sat Jan 11 00:31:55 UTC 2014


name finding worked, thank you!


>Will work for none CH only. You'll have to tweak the algorithm to accept
only edges which are in the bounds:
>edgeFilter = new EdgeFilter() {
>   accept(EdgeIteratorState state) {
>      base = state.getBaseNode();
>      adj = state.getAdjNode();
>      int baseLat = graph.getLatitude(base);
>      int baseLon = graph.getLatitude(base);
>...
>      return bbox.contains(baseLat, baseLon) || bbox.contains(adjLat,
adjLon);
>   }
>}
>dijkstra.setEdgeFilter(edgeFilter);


as for creating a box, sorry for being that dumb but where should I put it?
I don't want to change the main code structure a lot.
so can I use it inside Graphhopper.java's  public GHResponse route(
GHRequest request ) method?
I saw examples but they imply that I create algorithms object manually and
I don't want to since I intend to keep the same Graphhopper.java structure
(more or less) that's very usable with Android.

Best regards




On Fri, Jan 10, 2014 at 11:23 PM, Peter K <peathal at yahoo.de> wrote:

>  Hey,
>
>  >This is called geocoding and not provided by GraphHopper. Although we
> >have some (closed source) prototype we still recommend other existing
> >solutions.
>
>  Isn't there a way then to somehow manually find which node/edge ID is
> associated with street name by reading routing data provided from
> graphopper.sh script? I only need to figure out 5-10 street's names
> associated with their edge/node ids so that I could manipulate them via
> hardcoding. I mean, yes, it's that unpractical and basic but that's my goal
> here :)
>
>
> yes, sure: loop over all edges! This extremely expensive and error-prone
> as there are multiple identical named streets even in one city! But you can
> find the names:
>
> EdgeIterator iter = getAllEdges();
> while (iter.next())
> {
>       iter.getName()
>
> }
>
>  >Where the last option probably would be the simplest one as there is
> >already a (hidden) method for it in OSMReader called isInBounds or just
> >use OSM tools like osmosis:
> >http://wiki.openstreetmap.org/wiki/Osmosis#Extracting_bounding_boxes
> >
> >Or do you need to define it per request? What is your usecase?
>
>  Yes, my usecase would be to define per request:
> -First request calculates the fastest path
> -Point A is moving inside the map (GPS tracking on)
> -Timer should recalculate path each 30s or so
>
>
> Ok, but why would you need to find a path in a subgraph - to limit search
> space? Wouldn't it make more sense to re-compute the whole path (where you
> could reuse parts of the old result) or if that is too expensive you could
> re-compute a path in a bounding box leading you back to the original path.
>
>
>
>  > >* limit the search to only nodes in this area (this is only possible
> if no CH is used)
>  > >
>  > how is this possible to implement?
>
>  Will work for none CH only. You'll have to tweak the algorithm to accept
> only edges which are in the bounds:
> edgeFilter = new EdgeFilter() {
>    accept(EdgeIteratorState state) {
>       base = state.getBaseNode();
>       adj = state.getAdjNode();
>       int baseLat = graph.getLatitude(base);
>       int baseLon = graph.getLatitude(base);
> ...
>       return bbox.contains(baseLat, baseLon) || bbox.contains(adjLat,
> adjLon);
>    }
> }
> dijkstra.setEdgeFilter(edgeFilter);
>
> Regards,
> Peter.
>
> _______________________________________________
> GraphHopper mailing list
> GraphHopper at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/graphhopper
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/graphhopper/attachments/20140111/046ee55c/attachment.html>


More information about the GraphHopper mailing list