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

[Peter K]

> I mean, just simply like this?

No. First not in the method (in some outer scope instead) and second
with your own limits not with the edge properties. Again: I have no idea
what you are trying ...

> 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.

You can extend the GraphHopper class and overwrite the necessary methods
to call setEdgeFilter I think.

Regards,
Peter.

>
>
> On Fri, Jan 10, 2014 at 11:23 PM, Peter K <peathal at yahoo.de
> <mailto: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 ifno 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 <mailto:GraphHopper at openstreetmap.org>
>     https://lists.openstreetmap.org/listinfo/graphhopper
>
>
>
>
> _______________________________________________
> 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/31ce7d81/attachment.html>