[GraphHopper] Calculating fastest path with A*/Dijkstra with CH disabled
mythex3cutioner .
mizantropy at gmail.com
Sun Jan 12 02:40:22 UTC 2014
Okay, I figured it out and it was really silly - I was putting latitutes
instead of longtitutes when forming a bbox.. I still have one big question
due to bbox but I'll put into another message for future reference since
it's not relevant with the topic
On Sat, Jan 11, 2014 at 6:07 PM, mythex3cutioner . <mizantropy at gmail.com>wrote:
> uhh, sorry for the spam.
> i've tried it like this:
>
> EdgeFilter edgFilt = new EdgeFilter()
> {
> @Override
> public boolean accept( EdgeIteratorState edgeIterState
> )
> {
> baseLat =
> graph.getLatitude(fromRes.getClosestNode()); //fromRes - user's current
> position
> baseLon =
> graph.getLongitude(fromRes.getClosestNode());
> adjLat =
> graph.getLatitude(toRes.getClosestNode()); //toRes - destination
> adjLon =
> graph.getLongitude(toRes.getClosestNode());
> BBox bbox = new BBox(baseLat, baseLon, adjLat,
> adjLon);
> return bbox.contains(baseLat + baseLat*0.5,
> baseLon + baseLon * 0.5) || bbox.contains(adjLat + adjLat * 0.5, adjLon +
> adjLon * 0.5);
>
>
> }
> };
>
> yet it didn't even start algorithm - I think it found no usable nodes/edges
>
>
>
> On Sat, Jan 11, 2014 at 6:04 PM, mythex3cutioner . <mizantropy at gmail.com>wrote:
>
>> >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've tried to set a bounding box like this:
>>
>>
>> On Sat, Jan 11, 2014 at 6:02 PM, mythex3cutioner . <mizantropy at gmail.com>wrote:
>>
>>> Well, I'm absolutely new to the maps & Android so sorry if I bother you.
>>> I'm trying to manipulate some routing algorithms, basically, 'implement'
>>> my own one but just for presentation purposes.
>>>
>>> My final goal's flowchart would look something like this
>>> -The map is loaded and centered on device's coordinates provided by GPS
>>> (can't find .setFocus() on mapsforge, heh;)) (pointA)
>>> -User selects a point on the map, marker is added (pointB)
>>> -Shortest/fastest path is calculated between those two points
>>> -Second point is selected (pointB)
>>> -Then the algorithm runs only inside my Bounding Box
>>>
>>> Since I've added manual weights to some of the edges, there should be
>>> different times for calculations, different routes will be selected, etc.
>>>
>>> This is what I want to show - what are the differences when you apply
>>> bounding box or put some insane traffic-weight on the edge while running
>>> the same algorithm :)
>>>
>>> Best regards
>>>
>>>
>>> On Sat, Jan 11, 2014 at 5:27 PM, Peter K <peathal at yahoo.de> wrote:
>>>
>>>> > 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> 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
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> GraphHopper mailing listGraphHopper at openstreetmap.orghttps://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/20140112/112c3221/attachment.html>
More information about the GraphHopper
mailing list