openplannerteam / routable-tiles

An API and preprocessor to serve routable tiles.
https://openplanner.team/
11 stars 1 forks source link

Handling of ways with multiple segments in the tile #8

Closed xivk closed 5 years ago

xivk commented 5 years ago

This issue:

https://github.com/openplannerteam/website/issues/1

hdelva commented 5 years ago

Has any progress been made on this issue?

Just to add some extra information; https://tiles.openplanner.team/planet/14/8413/5484 contains:

{
  "@id":"http://www.openstreetmap.org/way/34254888",
  "@type":"osm:Way",
  "osm:nodes": [
    "http://www.openstreetmap.org/node/339446106",
    "http://www.openstreetmap.org/node/339446095",
    "http://www.openstreetmap.org/node/340290642",
    "http://www.openstreetmap.org/node/339446091",
    "http://www.openstreetmap.org/node/340291066",
    "http://www.openstreetmap.org/node/339446078"
  ]
},

Nodes 340290642 and 339446091 are part of the same road but aren't directly connected as the data implies. It is missing 3 nodes (339446099, 339446087, 2575521617) from the tile next to it.

If we go the planned route (no pun intended) of splitting up the way definitions we should mention that somewhere in the semantics. We should specify that the osm:nodes lists are way segments, sequences of connected nodes, and not actual ways. We should guarantee that if a way is split into two segments there’s at least a single node overlap. This should suffice for anyone trying to reassemble the ways. Most users will probably want to keep the segments separate though because:

  1. It’s enough to compose an edge-graph for a dijkstra-like algorithm
  2. Combining segments is non-trivial; a. There can be arbitrarily many overlapping nodes b. Nodes aren’t actually ordered. Roads may include cycles, violating the anti-symmetry property of a total order. c. Weird roads due to bad urban planning might not be representable as a simple sequence of nodes
  3. Adding a new tile could introduce the segments that glues other segments together. This means that all the complexities from the previous point resurface when loading additional tiles.
xivk commented 5 years ago

This is a bug in the code building the tiles I think, it was the idea to include, for now, all the nodes between the first and the last node in a way that's part of the tile. This has even regressed, the previous version did include all the nodes in between.

Alternatively we could include an 'index' along with every node, that way we could leave out these parts in between.

I suggest first getting things back as they used to be, by include the extra nodes, if we want to do things differently we should work on the spec.

hdelva commented 5 years ago

I think I actually prefer including the extra nodes over the proposed solution in https://github.com/openplannerteam/website/issues/1 (split up definitions). It would make each tile more stand-alone, which makes them easier to work with.

xivk commented 5 years ago

This is also fixed now as discussed.