Ist just a matter where/“at which object” you multiply the reference - If you use the same way for multiple polygons using relations you multiply the reference on the relation level, not on the way level. The number of references on the node (double indirect via relation) stays the same.
Using relations for building polygons from lines its just a matter of adding complexity. You are not reducing the amount of data, or the number of references to nodes or the like.
In the end you produce more ways (Going back to API 0.3 using something segment like) and create a relation per polygon. You reduce the number of nodes in a way. The number of nodes stays the same.
Yes, you are most of the time reducing the amount of data, if you add the way instead of its nodes - more so, if the way has lots of nodes, less if it has only 2 nodes. If you have 2 MPs that share a way with 100 nodes, then each node is only referenced once: by the way. The way itself is referenced twice (once through each MP). So you’re saving the space of roughly 99 references.
But is that really important? We should not argue pro/con database size, unless the people running the database are telling us to. And I haven’t heard from anyone in charge, that the database is getting too big
The number of references on the node (double indirect via relation) stays the same.
Using relations for building polygons from lines its just a matter of adding complexity. You are not reducing the amount of data, or the number of references to nodes or the like.
In the end you produce more ways (Going back to API 0.3 using something segment like) and create a relation per polygon. You reduce the number of nodes in a way. The number of nodes stays the same.
yes, the difference arises from then on, if you add a node to the polygon, it will produce 2 new versions with overlapping ways (one for each way) or 1 (as there is only one way with multipolygons). What I found most annoying with overlapping ways is the ungluing of lots of nodes for modifications, this is the most important reason for me to prefer relations.
Same here. For me, overlapping polygons makes it more challenging to edit and relations sharing common lines easier. But as you say: everybody is different.
And it’s still peanuts if you know how and not going to descent to the lowest common mapping denominator. Once up a time, say late 2020, conversed with a ID developer who pointed me to a similar function as mouse wheel click in JOSM to get a list of all the underlying relations/MPs . He (i think) gave a link to the live ID which had the function in testing. Never learned if it made it into the production release of ID. A true loss if it did not make it.
Finally some words that make total sense. Andy Townsend mentioned few moons ago the compressed total OSM database is 150GB (curious what compressor algo they use, some lossless deliver 80-90%). Anyway my 10+ years old comp has 1TB drive and still 300GB free after all that time… much loiters in the cloud these days to ensure everything is backed up). Not going to board any of techie reasoning of why. Nothing in the write ups to tell me at all let convincingly to change my current ways, except when I have a bunch of landuse SPs and there’s a small area inside a bigger I no longer make the small inner to the the bigger, with exception of farmyards. Someone wrote up and deep read with some voodoo sprinkle that farm+farm_auxiliary buildings can’t be on farmland… well here they’re all over the place and no farmyard in sight not to speak of greenhouses that are half hidden by the olive tree branches hanging over. Why can’t a greenhouse be on a plant nursery parcel or a piece of farmland squeezed between the soya beans? No, the only place legit is horticulture ground.
No, we normally optimise for “ease of mapping”, and to my mind that suggests using multipolygons only where necessary. A rough straw poll on Discord (only a small portion of OSM, obviously) came out strongly against the “multipolygons for everything” approach.
Pretty much as @chris66 said at the start of the thread:
I think this is quite a widespread experience: that the benefits do not compensate for the disbenefits. I think much of the Corine data were imported in this style and has been problematic (also for other reasons). The original bulk_upload.py tool definitely did this (for instance on buildings with shared walls).
The shared ways and relation is, however, the accepted way of mapping boundaries.
I think the key difference is that most people maintaining boundaries are experienced OSM users, likely using Josm, and follow quite careful QA before uploading changes. On-line editing inevitably involves less-experienced users, need to save work more frequently, and less explicit support for handling relations (and their QA).
It isn’t just the experience-level of mappers. For boundaries, the single shared way is semantically the dividing line between neighboring administrative areas and is literally shared by all of the administrative areas of different levels where they are conjoined. A single boundary way may be part of two municipal boundaries, two county boundaries, two state/province boundaries, and country boundaries. For example this way on the US/Canada border is part of 14 boundary relations.
In Database - possibly - in memory rebuilding polygons most likely not - More storage, more passes to rebuild polygons from relations.
I havent heard either - For me “complexity” is the key point. As soon as the Data gets to complex it tends to break or deteriorate in other means. Relations are complex, building polygons from lines is much more complex than “drawing a rectangle”.
I have QA tools to find large polygons, complex polygons (By sum of interior angles) and i tend to split them down to managable sizes. The larger polygons grow, the more often they break. The smaller polygons get the less the need for MPs exist.
If at least one part of a building is hanging over the building footprint or if the building has a complex structure with lots of parts, a type=building relation can be used to group the building outline and all building parts together. Otherwise, there is no need to create a type=building relation, i.e. simply position all building parts inside the building outline as described above.
Multipolygon relations were developed to map complex structures in OSM that could not be mapped with simple polygons. As far as I know, require less memory was not a goal.
The whole discussion about memory becomes absurd when a way consists of so many nodes that are not necessary in my eyes (painting the tree tops from the aerial photo does not correspond to the landuse on the ground!)
Sorry, that’s just my opinion. But I agree with @flohoff. Complex MPs, where we don’t need them, make editing much more complicated and error-prone for subsequent mappers, especially new and inexperienced mappers. Errors accumulate, and in the worst case the data is broken.
Like here, where the address data is only on three outer sides of the building and not in the relation - and therefore cannot be rendered.
It is one of several possible legit = not prohibited methods to do landcovers. However it has its pros and cons as all other alternatives. From my view it (ab)uses multiplygons to do things they are not intended to be used, only to serve one single personal goal: to have no “double lines”.
The use of commonly used bondaries by multiple outline multipolygons makes maintenance rather more difficult than easier and particularly hard to understand for users not that prolificient in multipolygon use. As a “power user” one should not think: “all people are…”
In your example, in many cases existent tracks etc could provide easy separating between areas.
You decided to map rather large landuse areas where one could easily specify more finely. Mulitple times there was an visible hesitating: Should I do all the fuss for this little triangle of other landuse or not? So “no, just add it to the larger area as some by-area”. Else: just put 3 Points and specifa landuse.
If this would be recommended as a general rule, other questions would occure:
does this not take more calculating time for worldwide tile generation than simple polygons with common boundaries ?
the existing data base I for my person know from Germany, Acores, Capo Verde, Peru and in some other places do not follow this scheme. Why we do absolute need to introduce another “innovative approach”?
I do mainly landcover stuff and would not consider doing this. I rather prefer to keep small polygons by using boundaries like tracks, ditches … separating them without sticking areas and boundary line together. So if someting changes, you have a set of distinct lines and areas easily manipulated by anyone.
Using multipolygons for areas included in otherr areas, boundaries of massive forrest outlines and the like
On the other hand I would appreciate more bindig editing rules in OSM. I am working in the technical documentation business and know about the importance of such rules for smooth operation.
This would avoild much trouble if one would decide by a democratic decision process about rules how to do important things (and not leave many “correct too” alternatives" - would ease data base interpretation for map generation too, I suppose.) but then also enforce this decisions. “Grass root democraty” is not always the best kind of democraty.
