<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi Quinton,<br>
<br>
> The way IDs would bloat things slightly. <br>
<br>
yes, that is true. Probably for now just overwrite the <span
class="Apple-style-span" style="font-family: Monaco; font-size:
11px; ">parseWay method. </span>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 <span class="n">osmidsOfEdges</span><span class="o"></span>
object. Still I'm not sure if this all this is that easy. See<br>
<a class="moz-txt-link-freetext" href="https://github.com/khuebner/graphhopper/blob/master/core/src/main/java/com/graphhopper/reader/OSMRestrictionRelation.java">https://github.com/khuebner/graphhopper/blob/master/core/src/main/java/com/graphhopper/reader/OSMRestrictionRelation.java</a><br>
<a class="moz-txt-link-freetext" href="https://github.com/karussell/graphhopper/blob/master/core/src/main/java/com/graphhopper/reader/OSMReaderHelperDoubleParse.java">https://github.com/karussell/graphhopper/blob/master/core/src/main/java/com/graphhopper/reader/OSMReaderHelperDoubleParse.java</a><br>
<br>
where Karl writes:<span class="cm"> <i>we cannot hold a map for
osmId->edgeId, because different edgeIds can have the same
osmId</i></span><i><span class="cm"> instead we hold for each
edgeId the corresponding OSM id and compare it later when we
need it @see OSMRestrictionRelation#getAsEntries(...)</span></i><i>
</i><br>
<br>
<br>
> What do you mean by soon? Is there a ticket tracking this
that I can participate in? Or is this a priority type discussion?
<br>
<br>
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).<br>
<br>
Please open a ticket if you like or even better a pull request :)
!<br>
<br>
Regards,<br>
Peter.<br>
<br>
<br>
</div>
<blockquote
cite="mid:913A1EEA-EAEC-4447-9BE7-61E5EB0599D7@gmail.com"
type="cite">Hi Peter,
<div><br>
</div>
<div>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? </div>
<div><br>
</div>
<div>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? </div>
<div><br>
</div>
<div>Regards,</div>
<div>Quinton Anderson</div>
<div><br>
<div>
<div>On 27 May 2013, at 8:50 PM, Peter K wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">H Quinton,<br>
<br>
><span class="Apple-style-span" style="font-family:
Monaco; font-size: 11px; "> and add the functionality
to extract the way ID</span><span
class="Apple-style-span" style="font-family: Monaco;
font-size: 11px; ">, 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.</span><br>
<br>
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)<br>
<br>
<br>
> The particular case I am looking at is a custom
datasource, that needs to be merged into a single graph
with CH. <br>
<br>
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.<br>
<br>
<br>
> we simply want users to be routed by via the
best/safest possible route. <br>
<br>
'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).<br>
<br>
Regards,<br>
Peter.<br>
<br>
</div>
<blockquote
cite="mid:42E6CB03-90C3-45E6-A790-9430F5295756@gmail.com"
type="cite">Hi Peter,
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>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?</div>
<div><br>
<div>
<div>On 27 May 2013, at 6:55 PM, Peter K wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi Quinton,<br>
<br>
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?<br>
<br>
Regards,<br>
Peter.<br>
<br>
<br>
</div>
<blockquote
cite="mid:2E10CAFB-D3A4-4F3A-8F26-61028F57BCC2@gmail.com"
type="cite">Hi,
<div><br>
</div>
<div>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: </div>
<div>
<ul class="MailOutline">
<li>to process this separate datasource
first</li>
<li>Override <span
class="Apple-style-span"
style="font-family: Monaco; font-size:
11px; ">OSMReaderHelper.parseWay, </span></li>
<ul>
<li><span class="Apple-style-span"
style="font-family: Monaco;
font-size: 11px; ">and add the
functionality to extract the way ID</span></li>
<li><span class="Apple-style-span"
style="font-family: Monaco;
font-size: 11px; ">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.</span></li>
</ul>
</ul>
<div><font class="Apple-style-span"
face="Monaco"><span
class="Apple-style-span"
style="font-size: 11px;"><br>
</span></font></div>
</div>
<div><font class="Apple-style-span"
face="Monaco"><span
class="Apple-style-span"
style="font-size: 11px;">This should
allow my external data to mix in quite
nicely. Can anyone suggest a better
approach or a way to generalize it
better?</span></font></div>
<div><font class="Apple-style-span"
face="Monaco"><span
class="Apple-style-span"
style="font-size: 11px;"><br>
</span></font></div>
<div><font class="Apple-style-span"
face="Monaco"><span
class="Apple-style-span"
style="font-size: 11px;">Regards,</span></font></div>
<div><font class="Apple-style-span"
face="Monaco"><span
class="Apple-style-span"
style="font-size: 11px;">Quinton
Anderson</span></font></div>
</blockquote>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
</blockquote>
<br>
</body>
</html>