[GraphHopper] Graphhopper and Pg_Routing Bridge

Thu Jul 3 14:27:23 UTC 2014

Vivek. We put it the osm data postgres db using osm2pgsql but use osmosis
for 5min diff updates
Cheers mark

Sent from my android. Please excuse typos.
On Jul 3, 2014 9:45 PM, "Vivek Nallur" <vivek.nallur at scss.tcd.ie> wrote:

> On a related note (I know this isn't the right mailing list), but does
> anyone have any experience using Osmosis to update existing tags in OSM
> maps? I've been trying for a while now, but without success.
> regs
> Vivek
>
> On Thu, Jul 03, 2014 at 02:51:25PM +0100, Vivek Nallur wrote:
>
>> Hi guys,
>>
>> I have almost the exact requirements as Mark! However, what I'm trying
>> to do is integrate sensor data (like pollution) onto the map, and then
>> allow the user the ability to either take it into account or go with the
>> default (car).
>>
>> The problem is that sensor data might update the map a few times a day.
>>
>> My current idea is as follows (Peter, you may have read this already!):
>>
>> 1) Grab the sensor data and push it into Redis (or any datastore. I
>> don't really care)
>> 2) Using a cron job, convert the sensor data into weights, and
>> create/update a tag inside the OSM file
>> 3) Re-start Graphhopper so that it can re-read the updated OSM file
>>
>> Mark, this might work for you, if you have a flooding sensor in place
>> (or similar). Peter, is this a sane plan, in the first place?
>>
>> So, my big question is: would it be easy/feasible to create a
>> postgres/neo4j bridge,
>> that graphhopper can read from? It'll save me doing
>> cron....update.....restartGraphhopper process. Also, it might make it
>> easier to combine preferences like 'cycling route' + 'least polluted'
>>
>> regs
>> Vivek
>>
>>
>> On Thu, Jul 03, 2014 at 02:06:02PM +0200, Peter wrote:
>>
>>> Hi,
>>>
>>> There was work done where neo4j was used as storage and so you could do
>>> with pg routing (although I think it would be even less suited as pg is
>>> not a graph database). But you'll need solid Java skills:
>>> https://github.com/graphhopper/graphhopper-experiments/blob/master/src/
>>> main/java/com/graphhopper/compare/neo4j/Neo4JGraphImpl.java
>>>
>>> Besides this it is probably easier to change the edge costs directly in
>>> GraphHopper but I'm with you that a postgres or neo4j bridge would be a
>>> very interesting thing.
>>>
>>> Regards,
>>> Peter.
>>>
>>>  Hi All
>>>>
>>>> I have been looking at Graphhopper for our routing needs and also
>>>> looking at Pg_Routing and both packages are very impressive.
>>>>
>>>> In a Nutshell, if you want to compare the two, Graphhopper's best
>>>> feature is it speed, PG_Routing's best feature is flexibility (speed
>>>> is not it .. that is for sure)
>>>>
>>>> It struck me last night that there may be a way to get the best form
>>>> both environments. I have been looking at how I can use Graphhopper in
>>>> a Dynamic and Changing environment for our Disaster Network as well as
>>>> a few other possibilities, but I need the ability to be able to
>>>> quickly update road unavailability due to flooding, etc so that
>>>> routing will not be used on those areas.
>>>>
>>>> PG_Routing makes this quite easy by simply adding a high cost to that
>>>> bridge or segment of road Whereas Graphhopper requires the rebuilding
>>>> of the entire graph. (at the moment anyway)
>>>>
>>>> My thought was, why not use both!! Use PG_Routing to maintain the
>>>> graph design and costs but make a program that builds the graphhopper
>>>> graph based on the pg_routing database and not the osm file ..
>>>>
>>>> My gut feel tells me that this might be quite feasible from a timing
>>>> standpoint, but I am not sure if the structure of the routing database
>>>> is suited to sequential scanning and building a graphhopper graph. If
>>>> it was, this would be a relative painless process that could be done
>>>> daily (or less) or on demand for disaster prone applications
>>>>
>>>> Unfortunately my Java and C skills are virtually non existent (I am a
>>>> VB and Windows guy) and pulling the code apart to look at this is
>>>> going to be extremely difficult for me
>>>>
>>>> I would be interested in your thoughts and if you see any immediate
>>>> ShowStoppers in this or any reason that it should not be done.
>>>>
>>>>
>>>> Regards
>>>>
>>>> Mark Cupitt
>>>>
>>>> "If we change the world, let it bear the mark of our intelligence"
>>>>
>>>> See me on Open Street Map <https://www.openstreetmap.
>>>> org/user/Mark_Cupitt>
>>>>
>>>> See me on LinkedIn <http://ph.linkedin.com/in/markcupitt>
>>>>
>>>>
>>>> *See me on StackExchange <http://gis.stackexchange.com/
>>>> users/17846/mark-c>
>>>> *
>>>> ============================================================
>>>> ===================================
>>>> The contents of this email are intended only for the individual(s) to
>>>> whom it is addressed and may contain
>>>> confidential or privileged information. If you are not the intended
>>>> recipient, you must not disclose, copy, distribute,
>>>> or use the contents of this email. If you have received this email in
>>>> error, please notify the sender immediately and
>>>> delete the email and any attachments.
>>>> ============================================================
>>>> ===================================
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> GraphHopper mailing list
>>>> GraphHopper at openstreetmap.org
>>>> https://lists.openstreetmap.org/listinfo/graphhopper
>>>>
>>>
>>>
>>  _______________________________________________
>>> GraphHopper mailing list
>>> GraphHopper at openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/graphhopper
>>>
>>
>>
>> _______________________________________________
>> GraphHopper mailing list
>> 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/20140703/23b771ec/attachment.html>