Generalize the logic of objects in the backend, especially attributes

[ghost]

I haven't read the study yet, but people told me about the discussion here.

In my opinion, it makes sense to generalize the data model in terms of nodes, ways and relations.

Imo it makes sense to not differentiate between ways and relations. A way should be a relation of nodes. A node itself should be an empty relation with at least the attributes lon, lat.

Therefore, there aren't three tables, but one for all (objectid, fr_key attribute)

For membership we need another table (membershipid, parentobjectid, childobjectid, childposition)

The attribute table has a hierarchical structure with one root element (attributeid, attributename, attributevalue, parentattribute) with parentattribute = Null for the root element.

The last part about the attributes can also be implemented right now as osm is currently and has the big advantage of the possibility to assign certain tags to certain parent tags. If I have I. E. A road with a sidewalk and a cycle lane, I can attribute one instance of width to the car lane, one instance of the same attribute to the sidewalk and another one to the cycle lane. Right now, this can be done with subtags in the ":" notation. But at least from three levels on, it becomes pretty messy. The hierarchical tree structure is implicitly collision free (tags with same name), cleaner and should be easier computable. A 3D renderer needs to know only one spelling of the tag height and knows to what to apply it to.

Thoughts about this?

[fititnt]

While the title you wrote says to generalize, the proposal is less generic than the existing approach on the Elements. Also, your proposal mixes vocabulary with container syntax, while for example not even Simple Features do this.

Maybe a limited number of tags/values (like the ones used for metadata) could be strictly formalized, but why do this with the vocabulary? And if it has to do with vocabulary, from where to start? There's so many approaches to encode relationships with vocabulary that would not be able at all to make it something as generic/reusable.

Maybe you could give more concrete examples? Because is not clear how detailed you want this suggestion to be