Reconsidering geometry, and separation of meta-information from geometry

[Andygol]

My proposals are based on all those elements that are already in the OSM data scheme. I am proposing evolutionary changes to the data schema that I believe can improve the OSM data experience.

---

Geometry issues

In the current data schema (API 0.6), any data primitive can have tags (meta-information) that describe what this or that element of the database is. At the same time, one primitive is used to create other primitives. While we have a fairly flexible approach to tagging data elements, we are faced with the problem of reconstructing the geometry of features.

A node is the only element that contains information about the position in space. And I think it's a great solution, a feature of OSM, that we can use nodes to denote relationships between tangent objects in the real world. When one line ends, another starts from the same point.

We use the nodes to create the geometry of other objects (nodes without tags). And that's OK. The problem arises when we try to reproduce the geometry of the lines to which nodes belong. This problem stems from the fact that the nodes do not contain information about the elements in which they participate. Ways and Relations have nodes ids in their properties, nodes do not.

Nodes <-> Ways

At the moment, we need to read information about all the nodes in order to start rendering the ways. If nodes have identifiers of dependent ways (relations) in their properties, we can start parallel processing of ways (relations), which in turn should reduce the processing time of the entire data set. In addition, the acceleration of data processing can be achieved by appropriate data organisation. OSM-XML is not organised as a geo-spatial data. Nodes and Ways must be located in the dump next to each other. (This is similar to coordinates listing instead of node IDs). That way, we don't have to wait to finish reading and indexing all the nodes information before we can start assembling the ways.

Way is a relation of nodes

It has already been mentioned that the ways are a kind of relation and it would be good to represent them in the form of a relation, where nodes are members, to represent linear geometry.

Geometry as a relations

Using relations for ways it is possible to represent such kind of geometry primitives as Area (Polygon), MultiPolygon (compilation of Polygons), Arcs (that reduce number of nodes for curved features) and so on. For example: circle is a subset of arcs, where minimum number of arcs is 2 and each arc is 3 nodes. Depending on the method of forming the arc, the circle can consist of at least 3 nodes.

Tracking geometry changes

In order to be able to track changes in the geometry of elements that rely on others to create their geometry (nodes for ways, ways for relations), you need to add the version number of these elements in addition to the ID of the base elements.

Now when we move a node of a way, the node changes its version, but the way does not. If, in addition to the ID of the node, the way also refers to the version number of the node, then a change in the version of the node will also lead to a change in the version of the way (chain changes), which will allow us to track changes in the geometry of objects quite effectively.

Meta-data presentation

When we have a geometry, we can begin to define what this geometry is. I propose to separate geometric elements from meta-elements. Meta-elements will, of course, use geometry primitives, but will do so in a slightly different way than they do now. We will still use tags to mark meta-elements. The difference is that the tags will be assigned to relations, members of which will be geometric primitives. Thus, we will have two types of relations in the data. These are relations for geometric primitives, and relations for meta-elements. Meta-elements are what we call POIs, roads, rivers, forests and lakes, things that make sense with the help of tags.

Using relations for meta-elements, we can get such elements as: MultiPoint, MultiLineString, GeometryCollection.

For example, a dual carriageway can be represented in a form of a MultiLineString relation, which will include all segments of the road in all directions and indicate the information common to all of them: the name, classification of the road, which correlates well with the principle "one object of the real world - one element in the data". It can also help stabilize object identifiers.

[tordanik]

You say

it would be good to represent them in the form of a relation

but your post doesn't really say why. Having a shared ID space across element types would have some benefits for ID stability, but what you propose seems to go beyond that.

Sure, it would be possible to abstract ways into relations with node members, and even abstract nodes into relations with lat and lon tags. But would that lead to a better editing experience? After all, it seems to me that relations are working quite poorly in practice: Even after a decade, support for them in the ecosystem of tools is spotty. There is no good user interface metaphor for working with them, and mapping communities consider it best practice to only use them when absolutely required because of their usability downsides and the barrier to entry caused by relation editing.

I believe that the reason for this situation is precisely that relations are too abstract and too powerful: A relation could be anything and everything, so any user interface which fully exposes their capabilities is likely to be quite complex.

In contrast, ways are have an obvious visual representation, established UI concepts for working with them, and are easily understood by novice mappers. To me, this suggests that having dedicated primitives for geometry types (such as ways and areas) makes it much more likely to achieve consistent editor support, enables validation of certain properties (way length, self intersection-free areas, and so on) in the API, and lends itself well to a gentle learning curve for mapping.

[Andygol]

Technically a way is an ordered list of nodes which normally also has at least one tags or is included within a relations.

A relation is an element with at least the tag type=* and a group of members which is an ordered list of one or more nodes, ways and/or relations.

According to the Wiki, a way is essentially an ordered collection of nodes with associated tags. On the other hand, a relation is also an ordered collection, but it can include nodes, ways, and/or other relations. Both ways and relations have tags associated with them.

In terms of their structure, the main distinction is that a way is a subset of a relation, separate from it. However, apart from this separation, there may not be significant differences between ways and relations.

In contrast, ways are have an obvious visual representation, established UI concepts for working with them, and are easily understood by novice mappers.

I understand that when referring to novice mappers, it implies that they may not be well-versed in all the technical aspects. The main point being made is that ways, regardless of how they are represented in the underlying data, have several advantages. These include a clear visual representation, established user interface concepts specifically designed for working with them, and a higher level of familiarity among mappers.

The mention of editing software pertains to how data is presented to mappers during the editing process. By ensuring that the software effectively communicates and represents the data in a clear and intuitive manner, any potential confusion among mappers can be greatly reduced. The focus is on creating an editing experience that is user-friendly, accommodating mappers of all skill levels, and minimizing any challenges they may face while working with the data.

[extua]

RE: geometry as relations, I really like the idea of arcs. Straight lines, or assemblies of straight lines between nodes, do well enough for most geometry, but the data model struggles to represent circular and curved features. For example, see the Attenborough Arts Centre at the University of Sussex - a circular building made up of several other smaller circles.

A nightmare for OSM mappers.

At the moment, curves can be more accurately represented by adding more nodes, which only works until someone zooms in close enough for the straight lines and corners to become obvious. Also, as @Andygol suggests above, arcs would reduce the number of nodes needed to map curves, leading to a more efficient (smaller) database.

[tordanik]

There are a lot of unsolved user interface challenges to make arcs as easy to edit as linestrings. It would also have to meet other requirements such as making it easy to create adjacent ways and areas. And remember, OSM is a map built mostly by people with zero prior experience with GIS/CAD/vector graphics tools.

It's not just a potential challenge for mappers, either. Arcs are not necessarily easy to work with for programmers as soon as you need to do any kind of calculations such as distances between geometry, intersections and so on. There are some types of curves which are easier to work with than others (the maths for are much easier for, say, circular arcs than for clothoids or Bézier curves), but they all lack the simplicity of the line segment. In terms of performance, the more complex calculations are likely to overwhelm any benefits from the reduced number of nodes.

In the traditional spirit of starting with "the simplest thing that might possibly work", I feel that inventing a round=yes tagging for wall sections to tell renderers to smooth out the geometry could make that Arts Centre look pretty nice.

[Andygol]

OSM is a map built mostly by people with zero prior experience with GIS/CAD/vector graphics tools.

It is important to recognize that many OSM users may not be familiar with the underlying raw data and the intricacies involved in its processing. Their primary focus tends to be on the editing software and the desired outcome of a rendered map. While this may be perceived as a limitation in understanding the technical aspects, it should not serve as a hindrance to the improvement of both the editing software and the backend data store and processing.

It is crucial to consider the diverse user base of OSM, including those with limited knowledge of raw data and the technicalities involved. By enhancing the editing software and improving the backend data infrastructure, we can ensure a more user-friendly experience for all users, irrespective of their technical background. This approach acknowledges the importance of meeting the needs and expectations of the OSM community while working towards comprehensive improvements across the entire OSM ecosystem.

Arcs are not necessarily easy to work with for programmers as soon as you need to do any kind of calculations such as distances between geometry, intersections and so on.

Is there a specific reason to be concerned about the difficulties related to working with arcs, especially if our intention does not involve performing calculations such as measuring distances between geometries or determining intersections?

I feel that inventing a round=yes tagging for wall sections to tell renderers to smooth out the geometry

It appears that suggesting the introduction of a round=yes tagging for wall sections to facilitate geometry smoothing implies potentially shifting the responsibility onto the developers of rendering software, which may be perceived as placing an additional burden on them.