Talk:Area/The Future of Areas

From OpenStreetMap Wiki
Jump to navigation Jump to search

The problem with this page ...

is that it only describes the issues with the current area modelling not the positive properties (for example that simple cases are very simple, local geometry changes can often be made without downloading the whole, potentially very very large, data structures) with the result that the proposals tend to concentrate on fixing the perceived deficiencies throwing out other requirements on the way.

Isochrones for areas?

How about generating isochrones to represent areas?

The user submitted data would be extremely simple, just points (with tags). Each point states that what the land cover is at that point, for example sea or land.

Isochrones would then be automatically generated from the points, resulting in a contiguous surface over the whole map. The polygonal regions generated by the isochrones would be reasonably simple, not too many nodes per polygon, no holes. Where two polygons representing the same feature (eg sea) abut each other, the fill shading would continue from one to the other. But if two polygons representing different features abut each other there is an opportunity to highlight that border.

Pros; Robustness - changing, deleting or adding points does not result in dramatic changes to the rendered map, since the user is only changing the area immeadiately around the nodes that they edit. The sea will not "spill" inland like it does now, because it will quickly run into isochrone polygons located inland.

Simplicity - user submitted data is of the simplest possible geometry, just a point with tags

Scalability - for less detail use fewer points, for more detail use more points

Interesting idea. In the extreme case this is basically a bitmap... The problem I see is that this is quite different from how humans tend to think about objects. I actually do want to draw the "border line" between, say, a forest and a meadow and not add a bunch of points I know to be in the forest and some that are not. I guess people would tend to draw two sets of points everywhere to mark such a "border line", not very elegant. That being said there is a precedence with addr:postcode tags which basically define postal code areas in exactly the way you describe. Similar the is_in tag could be used in such a way... Joto 11:09, 16 October 2012 (BST)
Alternatively, Voronoi cells / Thiessen polygons? Or is this the same thing as isochrones?

These are commonly used for climate/weather modelling, but could be easily applied for landform, land cover, coastline, geomorphology.

For the coastline, nodes could easily be tagged as "sea", "land" and "intertidal/coastline". The result would be an area representation of the coastline, where the area between low and high tide varies in width, just like it does in real life.

any new status?

This page describes a lot of problems, and a lot of proposed solutions, all as of 3.5 years ago. Has anything changed since then?

As an implementor who's about to dive into the swamp of relations and multipolygons, I really don't want to code to an obsolescent standard if something new is on the way. Pgf (talk) 18:56, 26 September 2015 (UTC)

No new developments as far as I know. Nobody has the time and energy to take this on. Joto (talk) 08:05, 27 September 2015 (UTC)
Thanks. I can't say as I'm surprised.  :-) Pgf (talk) 11:52, 27 September 2015 (UTC)
It's possible that focusing on "the future of areas" or any other similar question won't produce a better result than now exists. But if we were to think about mapping as less like painting than sculpture, I suspect that might show the way forward. MMacD (talk) 16:23, 17 September 2016 (UTC)

Would be interested in an update, if there is any at this point. --Harahu (talk) 07:34, 25 January 2022 (UTC)

colour code in the table in "Proposals"

I'm shure the different colours used as background have a meaning but I do not find a legend. Can someone help?