File:Osm data structures - future of areas - supermultipolygon.svg
Original file (SVG file, nominally 1,052 × 744 pixels, file size: 279 KB)
Summary
Ideas for (re)structuring large (as in many members) multipolygons.
Rationale: Human editors are used to splitting up large route relations if they feel the length of a relation becomes unmaintainable. Most of the time this will be /long/ before the technical limits strike. The same convenience of partitioning route relations should be possible for editors when handling areas, or more specific multipolygons (as closed ways are unpartitionable). This will be helpful in ground areas where available high-resolution imagery leads to increased micromapping (and consequently the loss of the bigger picture).
Without such a mechanism it will become increasingly hard to maintain 'rough'/fuzzy features (like residential, commercial, industrial, municipal areas) aside 'precise'/tiny ones (with respect to the imagery precision) in a manner that can attracts future maintainers.
Imho, a tidy/sensible data appearance with either 10-20 overlapping ways or copies of which running closely in parallel (but still incorrect) cannot be achieved for data editors and users alike. Naturally, there have been some thoughts of this already - see the wiki page on the future of areas, comparing mainly approaches that mandate an OSM API change .
In theory, if caching is good, changing a way taking part in a relation that in turn participates in the building of one of the multipolygons rings, it should ideally not lead to a full recalculation of the whole derived data (tiles, data extracts, computed copies with a lower LOD, etc.).
For instance, if a tile server detects that only a single member of a SMP changed, it should try to only mark and rerender those tiles intersecting the old and new geometry of that member.
Software that currently already does this for MPs should be trivial to adapt to handling the proposed SMPs as well. From a software point of view it is merely a representation issue, mainly putting pieces together that are more easily to maintain by editors and even occasional contributors.
Ideally, data consumers (read machinery) fed continously with osm diffs should not process and/or update more than the fraction of data changed. In theory, if lots of unchanged data needs to be reprocessed as well, an optimized caching strategy might be worth looking for.
Like Overpass does multipolygon caching now, this should continue to apply to the proposed supermultipolygons as well. (maybe a better name for the tag value is found..)
As a side effect this may bridge the gap to boundaries-relations, making it possible to simply reuse the definition of a boundary for the area contained (instead of maintaining a fully separate landmass relation, repeating boundary elements).
Note: The SVG standard allows linking svg elements, but mediawiki blocks this for security reasons. If you're interested in having the "full" interactive svg, you need to download and edit the file, changing text fragments _onclick= to onclick=.
Licensing
In case this is not legally possible, I grant anyone the right to use this work for any purpose, without any conditions, unless such conditions are required by law.
Notice to creator or uploader: Please consider using {{CC0-self}} instead for your work.
"Releasing work to public domain" has some issues, as it is not well defined in some jurisdictions and/or it is not actually possible to "release to public domain". Using CC0 license achieves the intended effect while avoiding such problems and is well suited for media files.
File history
Click on a date/time to view the file as it appeared at that time.
| Date/Time | Thumbnail | Dimensions | User | Comment | |
|---|---|---|---|---|---|
| current | 09:45, 3 January 2016 | | 1,052 × 744 (279 KB) | Cmuelle8 (talk | contribs) | missing space fixed.. |
| 09:42, 3 January 2016 |  | 1,052 × 744 (279 KB) | Cmuelle8 (talk | contribs) | nu aber.. | |
| 09:40, 3 January 2016 |  | 1,052 × 744 (241 KB) | Cmuelle8 (talk | contribs) | another conversion to view the whole thing.. | |
| 09:32, 3 January 2016 |  | 1,052 × 744 (276 KB) | Cmuelle8 (talk | contribs) | Converted text objects to path that incompatibly were not rendered by the wiki's svg implementation | |
| 09:25, 3 January 2016 |  | 1,052 × 744 (235 KB) | Cmuelle8 (talk | contribs) | Ideas for (re)structuring large (as in many members) multipolygons. <p>Rationale: Human editors are used to splitting up large route relations if they feel the length of a relation becomes unmaintainable. Most of the time this will be /long/ before t... |
You cannot overwrite this file.
File usage
The following page uses this file:
