[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