[GraphHopper] Additional Datasource for Graph Construction

[Peter K]

Hi Quinton,

> The way IDs would bloat things slightly.

yes, that is true. Probably for now just overwrite the parseWay method. 
Later on we can indirectly enable (by relation-configuration) to read
the way IDs as well. But have a look into Karls work for turn
restrictions where he already has a osmidsOfEdgesobject. Still I'm not
sure if this all this is that easy. See
https://github.com/khuebner/graphhopper/blob/master/core/src/main/java/com/graphhopper/reader/OSMRestrictionRelation.java
https://github.com/karussell/graphhopper/blob/master/core/src/main/java/com/graphhopper/reader/OSMReaderHelperDoubleParse.java

where Karl writes:/we cannot hold a map for osmId->edgeId, because
different edgeIds can have the same osmId//instead we hold for each
edgeId the corresponding OSM id and compare it later when we need it
@see OSMRestrictionRelation#getAsEntries(...)///


> What do you mean by soon?  Is there a ticket tracking this that I can
participate in? Or is this a priority type discussion?

By soon I didn't exactly mean a time - I more ment what is very next in
my road map, I cannot make any time prediction or time guarantees
(albeit this feature shouldn't be complicated). I would like to finish
improving bike&foot support and then directly after that I will tackly
instructions and safety stuff (probably interfered by the turn
restrictions or other stuff).

Please open a ticket if you like or even better a pull request :) !

Regards,
Peter.


> Hi Peter,
>
> If the way ids are included in general then it would possible
> (probably) to do the import separately, so as not to touch the OSM
> Reader. If the id isn't added then the only place to enable the
> relation is the OSMReader. The way IDs would bloat things slightly.
> Which option would you prefer to accept a pull request for? 
>
> When you say the "safest" will be added to graphhopper soon? What do
> you mean by soon?  Is there a ticket tracking this that I can
> participate in? Or is this a priority type discussion? 
>
> Regards,
> Quinton Anderson
>
> On 27 May 2013, at 8:50 PM, Peter K wrote:
>
>> H Quinton,
>>
>> >and add the functionality to extract the way ID, Add the external
>> nodes to the list where applicable based on a match of the way IDs
>> between the datasets, and in the correct order.
>>
>> Somewhen in the future the graphhopper core will need the way ids too
>> (for relations etc) so this might be a useful addition on its own (+
>> making it configurable)
>>
>>
>> > The particular case I am looking at is a custom datasource, that
>> needs to be merged into a single graph with CH.
>>
>> I have to think about it. But your solutions seems to be okay.
>> Another possibility would be to do the external import afterwards so
>> that you don't need to modify the OSMReader stuff.
>>
>>
>> > we simply want users to be routed by via the best/safest possible
>> route.
>>
>> 'safest' will be added in graphhopper core in the very (?) near
>> future. This is something very important for FOOT/BIKE and it is
>> similar to the already existing fastest/shortest WeightCalculation.
>> It also requires modifications to the encoders as the flag-integer
>> will hold some more 'safety' bits indicating not safe/somewhat safe
>> and safe or something like this. E.g. a pedestrian is allowed to walk
>> on a highway=road but this wouldn't be safe, instead
>> highway=pedestrian or a track would be safe. But e.g. if bike access
>> or even car is allowed at the same time, then the safety for
>> pedestrian would be only 'somewhat safe' or something like this ...
>> at the same time this cost can be multiplied with the speed (or
>> surface) or with a 'beautyness' of a way (if in parks, lots of POIs
>> or far away from cars etc).
>>
>> Regards,
>> Peter.
>>
>>> Hi Peter,
>>>
>>> Not elevation data, more in line with GTFS, but not quite. It is in
>>> fact a custom GIS that has links in its data back to OSM in some
>>> cases. Some cases being the way id. It is a simple CSV format
>>> export, which I can manipulate in any way before importing it. I do
>>> also have a GTFS datasource for train routing, however I was simply
>>> going to use OTP as a restful service to do the train routing, not
>>> merge the graphs, then merge the routes later. The particular case I
>>> am looking at is a custom datasource, that needs to be merged into a
>>> single graph with CH. 
>>>
>>> One other requirement I have that involves an external datasource is
>>> to try and limit walking to areas that have higher densities of
>>> "places". This data will come from google or 4square. At a high
>>> level, we simply want users to be routed by via the best/safest
>>> possible route. The inherent assumption is that alleys and the like
>>> won't have any/many places on them. I am not quite sure how to
>>> collapse that requirement down into something that is useful within
>>> this context yet though. One thought was a cost factoring of some
>>> kind. Any thoughts?
>>>
>>> On 27 May 2013, at 6:55 PM, Peter K wrote:
>>>
>>>> Hi Quinton,
>>>>
>>>> do you mean external datasource like the elevation data in #43? Or
>>>> more in the direction of two graphs (like GTFS as external data
>>>> source) which should be merged?
>>>>
>>>> Regards,
>>>> Peter.
>>>>
>>>>
>>>>> Hi,
>>>>>
>>>>> I have a separate data source which needs to be merged into the
>>>>> graph as part of the OSM import process. The data essentially
>>>>> consists of a set of ways, each consisting of a way ID and a list
>>>>> of nodes. The Way id corresponds to the OSM way ID exactly. The
>>>>> nodes consist of a lat, long and sequence number within the way
>>>>> (which includes the version). My current thought process is: 
>>>>>
>>>>>   * to process this separate datasource first
>>>>>   * Override OSMReaderHelper.parseWay, 
>>>>>       o and add the functionality to extract the way ID
>>>>>       o Add the external nodes to the list where applicable based
>>>>>         on a match of the way IDs between the datasets, and in the
>>>>>         correct order.
>>>>>
>>>>>
>>>>> This should allow my external data to mix in quite nicely. Can
>>>>> anyone suggest a better approach or a way to generalize it better?
>>>>>
>>>>> Regards,
>>>>> Quinton Anderson

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/graphhopper/attachments/20130527/8860af0e/attachment-0001.html>