osmlab
Area datatype
from https://wiki.openstreetmap.org/wiki/Top_Ten_Tasks#Area_datatype
Area datatype
- What's involved: Ruby on Rails, C++, SQL, Java, etc
- Who can you talk to: dev mailing list or EWG
- What's being done already: mostly conceptual work, see Area/The Future of Areas for some background and thoughts on the issue
OpenStreetMap has three data types: nodes, ways and relations. Areas, lacking a dedicated type, are modeled with either ways or relations. This is often ambiguous and needlessly hard to understand, creates problems for software development, and makes it hard to detect common errors in our map data (especially for larger polygons).
A native area datatype would solve this, but despite widespread support for the idea, it has not been implemented so far. The task is very hard due to the number of tools affected by it, and considered "a holy grail of OSM" by many. It would require a database migration, support in the website and all editors, a (temporary) means to convert data to API 0.6 on the fly, testing, and so on. It is likely too complex for a single person. If you want help, please read Area/The Future of Areas page for some hints.
This issue comes from the OSM Top Ten Tasks page
We discussed this briefly and agree that it would be a really big lift.
Areas (polygons) are currently implemented in iD by detecting tags which imply that a closed way should be treated as an area.
This logic has been exported into its own library, see https://github.com/osmlab/id-area-keys
This is fine.
Overpass API has a similar list to define criteria of what should be considered as an area. This is based on work by @tyrasd : https://wiki.openstreetmap.org/wiki/Overpass_turbo/Polygon_Features
Overpass API even calculates an own "area" data type based on this list. However, this is going to change in the future to make it much more flexible. Hardcoded criteria will be a thing of the past then.
