[GraphHopper] Does Graphhopper merge ways with equal flags and name?

Peter graphhopper at gmx.de
Wed Jun 3 21:27:37 UTC 2015


Hi John,

the problem is as follows:
Assume the osm ways A-B-C (west to east) and D-E-F (north to south)

Now if the node B is the same as F or E then we have a tower node or
junction. But if the nodes C and F are identical then this would be a
pillar node (and we handle it like a tower node). So the import always
assumes case 1 and we are always safe but in some rare cases we could
avoid creating a tower node.

Regards,
Peter

On 03.06.2015 23:13, John Zhao wrote:
> Hi Peter,
>
> I am more confused.
> I think the original question is:
> If there are 2 different OSMways in original OSM data, they and only
> they are connected.
> And all the other tags are the same.
> Does Graphhopper will merge them into a single edge in GH?
> Then the graph is a little bit simplified.
>
> *Best Regards,*
> *ZhiQiang ZHAO*
>
> On Wed, Jun 3, 2015 at 2:07 PM, Peter <graphhopper at gmx.de
> <mailto:graphhopper at gmx.de>> wrote:
>
>     Hi John,
>
>     good question :)
>
>     Maybe that is the reason that in rare cases pillar nodes are
>     incorrectly determined as tower nodes. One could introduce a new
>     PILLAR_NODE2=0 variable and try if everything is still working.
>     But before I would pick a big area and count the percentage of
>     those incorrectly determined tower nodes if this is valuable at all.
>
>     Regards,
>     Peter
>
>
>
>     On 03.06.2015 22:16, John Zhao wrote:
>>     Hi Peter,
>>
>>     That sounds reasonable. But I am still confused.
>>     I think the logic is under the below logic. 
>>     Based on the logic and commets, a node is "mark node as tower
>>     node as it occured at least twice times", not "at least 3 times".
>>
>>         void prepareHighwayNode( long osmId )
>>
>>         {
>>
>>             int tmpIndex = getNodeMap().get(osmId);
>>
>>             if (tmpIndex == EMPTY)
>>
>>             {
>>
>>                 // osmId is used exactly once
>>
>>                 getNodeMap().put(osmId, PILLAR_NODE);
>>
>>             } else if (tmpIndex > EMPTY)
>>
>>             {
>>
>>                 // mark node as tower node as it occured at least
>>     twice times
>>
>>                 getNodeMap().put(osmId, TOWER_NODE);
>>
>>             } else
>>
>>             {
>>
>>                 // tmpIndex is already negative (already tower node)
>>
>>             }
>>
>>         }
>>
>>
>>     *Best Regards,*
>>     *ZhiQiang ZHAO*
>>
>>     On Wed, Jun 3, 2015 at 12:15 PM, Peter <graphhopper at gmx.de
>>     <mailto:graphhopper at gmx.de>> wrote:
>>
>>         Hi,
>>
>>         the details are a bit trickier as we do everything very
>>         memory efficient.
>>
>>         And if a osm node occurs twice it is a pillar node, otherwise
>>         it is a tower node.
>>
>>         Kind Regards,
>>         Peter
>>
>>
>>         On 03.06.2015 21:05, John Zhao wrote:
>>>         I go through the logic:
>>>         It go through all osmways, and count the occurrence of nodeID.
>>>         if nodeID appear only once, it's a pillar node.
>>>         otherwise, it's a tower node.
>>>
>>>         That's it. Do I miss something?
>>>
>>>
>>>         *Best Regards,*
>>>         *ZhiQiang ZHAO*
>>>
>>>         On Wed, Jun 3, 2015 at 11:55 AM, Peter <graphhopper at gmx.de
>>>         <mailto:graphhopper at gmx.de>> wrote:
>>>
>>>             Hi,
>>>
>>>             there is no separate merging logic (although there was
>>>             in 0.1 or something). In OSMReader it is decided when an
>>>             edge is created and e.g. OSM ways are splitted if there
>>>             are barriers or junctions on the way. So it decides
>>>             whether an osm nodes will be a tower node or just a
>>>             pillar node
>>>
>>>             Regards,
>>>             Peter
>>>
>>>
>>>             On 03.06.2015 20:35, John Zhao wrote:
>>>>             Hi Peter,
>>>>
>>>>             Could you tell me where is the merging logic?
>>>>             That's interesting.
>>>>
>>>>             *Best Regards,*
>>>>             *ZhiQiang ZHAO*
>>>>
>>>>             On Wed, Jun 3, 2015 at 12:09 AM, Peter
>>>>             <graphhopper at gmx.de <mailto:graphhopper at gmx.de>> wrote:
>>>>
>>>>                 Hi Jan,
>>>>
>>>>                 we do this kind of 'merging' logic already in the
>>>>                 import step when deciding what should be handled as
>>>>                 tower node and what is a pillar node. Otherwise
>>>>                 you'll need as twice as many RAM when copying from
>>>>                 one graph to the other.
>>>>
>>>>
>>>>                 > Have you made a experiment to count the number of 2
>>>>                 degree nodes with the equal flags and name in OSM?
>>>>                 > And then we can know how many edges we can save.
>>>>
>>>>                 Yes, this should be done before implementing it :)
>>>>
>>>>                 And as the merging logic is currently not 100%
>>>>                 optimal, there could be some minor savings even
>>>>                 when recognizing the different street names, but
>>>>                 I'm unsure if it is worth the effort.
>>>>
>>>>                 Issues like #234 or #111 will probably make more
>>>>                 difference.
>>>>
>>>>                 Kind Regards,
>>>>                 Peter
>>>>
>>>>
>>>>                 On 02.06.2015 22:35, John Zhao wrote:
>>>>>                 Hi,
>>>>>
>>>>>                 AFAIK, there is no this kind of merging logic here.
>>>>>                 Wait the answer from Peter.
>>>>>                 Probably you need to implement it by your own.
>>>>>                 And it's not easy. 
>>>>>                 Maybe can be done before import?
>>>>>                 What you want, is actually convert a tower node to
>>>>>                 a pillar node.
>>>>>
>>>>>
>>>>>                 *Best Regards,*
>>>>>                 *ZhiQiang ZHAO*
>>>>>
>>>>>                 On Tue, Jun 2, 2015 at 1:27 PM, Jan Torben Heuer
>>>>>                 <jan at komoot.de <mailto:jan at komoot.de>> wrote:
>>>>>
>>>>>                     Hi ZhiQiang ZHAO,
>>>>>
>>>>>                     Thanks for your quick answer.
>>>>>                     I have a custom FlagEncoder that imports only
>>>>>                     very few ways and I don’t need the names. I
>>>>>                     guess, I have mostly nodes with a degree of two.
>>>>>
>>>>>                     Jan
>>>>>
>>>>>                     Am 02.06.2015 um 21:53 schrieb John Zhao
>>>>>                     <johnthu at gmail.com <mailto:johnthu at gmail.com>>:
>>>>>
>>>>>>                     Hi,
>>>>>>
>>>>>>                     Have you made a experiment to count the
>>>>>>                     number of 2 degree nodes with the equal flags
>>>>>>                     and name in OSM?
>>>>>>                     And then we can know how many edges we can save.
>>>>>>
>>>>>>                     I doubt this should be not too much for OSM.
>>>>>>
>>>>>>                     *Best Regards,*
>>>>>>                     *ZhiQiang ZHAO*
>>>>>>
>>>>>>                     On Tue, Jun 2, 2015 at 11:59 AM, Jan Torben
>>>>>>                     Heuer <jan at komoot.de <mailto:jan at komoot.de>>
>>>>>>                     wrote:
>>>>>>
>>>>>>                         Hi,
>>>>>>
>>>>>>                         Can Graphhopper merge two ways with equal
>>>>>>                         flags and name if there is no
>>>>>>                         intersection between them (no third way
>>>>>>                         connected)?
>>>>>>
>>>>>>                         I would like to create a very reduces
>>>>>>                         graph with only few edges. What would be
>>>>>>                         the easiest way to achieve it? I think I
>>>>>>                         would have to disable the nameIndex for
>>>>>>                         instance.
>>>>>>
>>>>>>                         Thanks,
>>>>>>
>>>>>>                         Jan
>>>>>>
>>>>
>>>
>>
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/graphhopper/attachments/20150603/ce442733/attachment.html>


More information about the GraphHopper mailing list