[GraphHopper] Additional Datasource for Graph Construction

[Peter K]

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/d3a3dce1/attachment-0001.html>