Talk:Area/The Future of Areas

From OpenStreetMap Wiki
Jump to: navigation, search

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)