<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 Ottavio,<br>
<br>
> my idea is to create another file, let's call it names, with
all the street names and to add an offset for each node<br>
<br>
sorry for the confusion, that is exactly what I mentioned :) !<br>
<br>
But rather than per node I would add a pointer for every edge
instead.<br>
(Also - at a later stage - one could think about how to store the
names so that they could be used for address lookup. e.g. sorted
etc)<br>
<br>
<br>
> do nodes correspond to the nodes of OSM?<br>
<br>
Nodes do not correspond to OSM ids. As we need to use them as
array indices. This avoids costly HashMap lookups and memory waste
(maps are 1.5 to 2 times larger than an array).<br>
Also see the osmIdToIndexMap in OSMReaderHelperDoubleParse where I
map OSM ids (long) to node ids (integer)<br>
<br>
<br>
> In the picture of the data layout I don't understand the <br>
> meaning of the arrows that go from the nodes to the edge<br>
<br>
The arrow from one node to an edge is just the first edge of this
node. It is an implementation of a linked list.<br>
See my updated description:<br>
<br>
<i>One node has several edges which is implemented with a linked
list. E.g. node 3 points to its first edge in the edge area at
position 0 to edge 0-3 (nodeA-nodeB where nodeA is always
smaller than nodeB). To get the next edge of node 3 you need
nextB and this goes to edge 1-3, again node 3 is nodeB, but for
the next edge 3-5 node 3 is nodeA ... and so on.</i><i><br>
<br>
</i><br>
> Finally, do properties have a fixed length? Do you plan to
store the name of the stree there? But I think <br>
> that this solution would duplicate the name of the street for
all the nodes. Would it be more efficient to <br>
> store an offset for the content of a file holding all the
names of the street?<br>
<br>
Exactly. See also how I'm using a separate 'file' (or DataAccess
object) for wayGeometry, which is refered from one of the edge
properties and uses the 'geometry' DataAccess object.<br>
<br>
<br>
> Can you please explain me how you thought about using a
byte-oriented DataAccess
<br>
> to handle the street names?<br>
<br>
I just meant again a 'file'. But DataAccess is a bit more generic
as one can use it for in-memory access (fast for server-side)<br>
or memory mapped (for android). At the moment one can only store
integer values (to keep it simple), but we need<br>
to store strings which could be easily converted to a byte array
but not so easy to an integer array. So I would have to change or
extend the DataAccess interface to make it possible to hold and
access an in-memory byte array (or the memory-mapped ByteBuffer
equivalent).<br>
<br>
Regards,<br>
Peter.<br>
<br>
</div>
<blockquote cite="mid:51420F3E.2080302@campana.vi.it" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">Il 12/03/2013 17:41, Peter K ha
scritto:<br>
</div>
<blockquote cite="mid:513F5AB0.8080301@yahoo.de" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">Hi Ottavio,<br>
<br>
thanks for reaching out. That is still on the todo list. I
would be very happy for your contribution! But you'll have to
digg deep into GraphHopper - just to warn you ;)<br>
<br>
See the newly created issue: <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="https://github.com/graphhopper/graphhopper/issues/23">https://github.com/graphhopper/graphhopper/issues/23</a><br>
<br>
Let me know if you need assistance or further details. I could
probably do the first step relative fast in a separate
instructions branch if that would help a bit.<br>
</div>
</blockquote>
<br>
Hello Peter,<br>
<br>
yesterday I studied the issue #23 and I think that the second and
the third point are clear,<br>
<br>
I think that the first point is not clear. Let me explain: you say
that you would like to add a DataAccess to GraphStorage. If I
correctly understand, the DataAccess interface is a way to access
the graph information. I don't understand why you think that
changing the access from int to byte would be sufficient to have
it implemented.<br>
<br>
I've read <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://github.com/graphhopper/graphhopper/wiki/Developers">https://github.com/graphhopper/graphhopper/wiki/Developers</a>
, and I have some questions about the data layout:<br>
<ol>
<li>do nodes correspond to the nodes of OSM? In the picture of
the data layout I don't understand the meaning of the arrows
that go from the nodes to the edges.</li>
<li>are the edges the adjacency of the nodes? The would explain
nextA and nextB, but I don't understand why in the picture you
have the nodes 0 and 3 pointing to the same row.</li>
<li>what is the meaning of nodeA and nodeB? and what does
nodeA<nodeB mean? Really, I tried to understand but I was
not able to get the structure.</li>
<li>Finally, do properties have a fixed length? Do you plan to
store the name of the stree there? But I think that this
solution would duplicate the name of the street for all the
nodes. Would it be more efficient to store an offset for the
content of a file holding all the names of the street?</li>
</ol>
<p>my idea is to create another file, let's call it names, with
all the street names and to add an offset for each node so that
it would be fast to retrieve the name of the streets when the
evaluated path is converted to instructions. Can you please
explain me how you thought about using a byte-oriented
DataAccess to handle the street names?<br>
</p>
<p>Ottavio<br>
</p>
</blockquote>
<br>
</body>
</html>