3 ms·

Your wiki link states that multiple nodes can share the same latitude and longitude (different heights/layers), so the ID could not be subsumed. (Unless you wer

Your wiki link states that multiple nodes can share the same latitude and longitude (different heights/layers), so the ID could not be subsumed. (Unless you were trying to imply something else?)

zigzag312 2y ago
Nodes have different uses in OSM. I was refereeing to the case where node provide a location for way's geometry. 97.5% of nodes don’t have tags and only contain latitude and longitude data. [0] Only 0.01 % to 0.05 % of the nodes are distinct nodes with the same coordinates and majority of them have been created by error. [1] While there are some cases where a node provides an additional information for a way, it would still be much better, if ways would contain geometry directly (instead of node IDs) and encode that additional information differently. If way's coordinates contain altitude as 3rd dimension, it can just store three-dimensional geometry. Any layer tag, on a node that is part of a way, could probably be moved to the way itself. [0] https://media.jochentopf.com/media/2022-08-15-study-evolution-of-the-osm-data-model.pdf https://media.jochentopf.com/media/2022-08-15-study-evolutio... [1] https://github.com/osmlab/osm-data-model/blob/master/geometry_for_ways/approaches.md https://github.com/osmlab/osm-data-model/blob/master/geometr...
- ghusbands 2y ago
  When you're down to 90% of them only providing location (unless you stop caring about topology), it's no longer as clear-cut. I was only really arguing against the implication that it's "funny" to use nodes; the topological connections and normalisation/deduplication do have advantages and it looks like a reasonable technical decision to have made. I also imagine that creating new topological connections may become trickier when most locations are 'hidden' in ways. However, I do hope you find a common way forward that reduces the apparent redundancy and excess processing/storage requirements.
  - zigzag312 2y ago
    I found the added complexity of this normalization funny/ironic when I wanted to process some OSM data. As IMO, the benefits don't nearly outweigh the added complexity and costs caused by it. A different way of creating new topological connections wouldn't be that difficult. For example, some topological connections are already being created via relation type. I'm not involved with OSM project, but I think that some changes to OSM data model would benefit it greatly. Resolved geometries would enable stream processing and decrease complexity for majority of task. It would make OSM data much more accessible.

Your wiki link states that multiple nodes can share the same latitude and longitude (different heights/layers), so the ID could not be subsumed. (Unless you were trying to imply something else?)

zigzag312 2y ago

Nodes have different uses in OSM. I was refereeing to the case where node provide a location for way's geometry. 97.5% of nodes don’t have tags and only contain latitude and longitude data. [0] Only 0.01 % to 0.05 % of the nodes are distinct nodes with the same coordinates and majority of them have been created by error. [1] While there are some cases where a node provides an additional information for a way, it would still be much better, if ways would contain geometry directly (instead of node IDs) and encode that additional information differently. If way's coordinates contain altitude as 3rd dimension, it can just store three-dimensional geometry. Any layer tag, on a node that is part of a way, could probably be moved to the way itself. [0] https://media.jochentopf.com/media/2022-08-15-study-evolution-of-the-osm-data-model.pdf https://media.jochentopf.com/media/2022-08-15-study-evolutio... [1] https://github.com/osmlab/osm-data-model/blob/master/geometry_for_ways/approaches.md https://github.com/osmlab/osm-data-model/blob/master/geometr...

ghusbands 2y ago
When you're down to 90% of them only providing location (unless you stop caring about topology), it's no longer as clear-cut. I was only really arguing against the implication that it's "funny" to use nodes; the topological connections and normalisation/deduplication do have advantages and it looks like a reasonable technical decision to have made. I also imagine that creating new topological connections may become trickier when most locations are 'hidden' in ways. However, I do hope you find a common way forward that reduces the apparent redundancy and excess processing/storage requirements.
- zigzag312 2y ago
  I found the added complexity of this normalization funny/ironic when I wanted to process some OSM data. As IMO, the benefits don't nearly outweigh the added complexity and costs caused by it. A different way of creating new topological connections wouldn't be that difficult. For example, some topological connections are already being created via relation type. I'm not involved with OSM project, but I think that some changes to OSM data model would benefit it greatly. Resolved geometries would enable stream processing and decrease complexity for majority of task. It would make OSM data much more accessible.