Smallest possible first step

[dktue]

I would love to see this progressing.

In short terms many developers would greatly benefit from an area attribute on ways. @joto mentioned in one of his talks that this attribute can possibly be added automatically in most cases -- a mechanical edit of current data seems to be possible.

Just imagine how easy the world of a developer would be, if we had

<way id="214501181" area="yes">  <!-- look here! -->
    <nd ref="2240372834"/>
    <nd ref="2240372819"/>
    <nd ref="2240372884"/>
    <nd ref="2462021289"/>
    <nd ref="2462021293"/>
    <nd ref="2240372847"/>
    <nd ref="2240372834"/>
    <tag k="addr:city" v="Tübingen"/>
    <tag k="addr:country" v="DE"/>
    <tag k="addr:housenumber" v="1"/>
    <tag k="addr:postcode" v="72074"/>
    <tag k="addr:street" v="Brunnenstraße"/>
    <tag k="building" v="house"/>
</way>

So my question is: Can we do this separately? Can we already start providing the area-attribute right now for ways where an area-tag is explicitely set and go on from there?

[kamicut]

@dktue would you also add this to multipolygon relations that denote areas as well?

[dktue]

@kamicut sounds like a reasonable generalization. But for relations it's quite easier to figure out if they are areas or rings. If it's about the smallest possible step, we could start with ways only if relations would impose further problems.

[dktue]

@mmd-osm : I know it's not supported yet like nothing of the proposals in this repository is supported. I just wanted to encourage progress by pointing out a smallest possible step.

And if editors don't support it, it's not an issue: The bot that performs the mechanical edit could continue working continguously adding the attribute to those ways that have it set to null.

[HolgerJeromin]

If a bot can add the new attribute there is no value with this change.

[dktue]

@HolgerJeromin : I think there's value in it if a bot can make this change because the bot is very complicated. @joto mentioned in his talk at SOTM that he identified at least 187 (!) rules to decide wether a closed way is an area or not.

Every software using OSM data therefore must implement at least all of those rules to work correctly. Having an attribute would greatly simplify the way other software can consume and interpret OSM data.

It's really about having complexy at one place (in the bot!) and not in every software that uses OSM data.

And at some point in the future when editors support this, the bot can be disabled.

[dktue]

If there are really 187 rules, the following list should probably get updated https://wiki.openstreetmap.org/wiki/Overpass_turbo/Polygon_Features

@mmd-osm : And that's why I think the attribute would be beneficial.

[ImreSamu]

@dktue :

in my mind - the minimal first step is creating

• an area metadata
• and/or start planning a basic ~"central key/tag metadata" repository ( long term vision )

For me : the area metadata is very important for processing osm historical data or fixing area tags.

area metadata

according my knowledge:

• https://github.com/tyrasd/osm-polygon-features/blob/master/polygon-features.json (CC0-1.0)
• https://github.com/osmlab/id-area-keys/blob/master/areaKeys.json (ISC )
• https://github.com/gravitystorm/openstreetmap-carto/blob/master/openstreetmap-carto.lua#L5 (CC0)
• ...

universal area metadata ? ( we need more planning, because https://xkcd.com/927/ )

Other important metadata

for a long term - I would like if we have a same format for integrating all key/tags metadata
( my vision : ~"central key/tag metadata" repository )

some examples:

'feature keys' ( or primary keys )

• https://github.com/geofabrik/osmi_simple_views/blob/master/src/tagging_view_handler.cpp#L360 (GPL license) ( https://blog.geofabrik.de/?p=425 )
• ...

Import keys ( can be dropped for the data consumers )

• https://github.com/gravitystorm/openstreetmap-carto/blob/master/openstreetmap-carto.lua#L51
• ...

key regexp value types ( for QA tools )

• name value type ( value == any utf8 )
  • 'name','old_name','int_name', ... '
  • parish,diocese,deanery
  • architect
  • ...
• speed type ( km, mph, knot, .. ) + access type
  • maxspeed
• normal ( english letters ) regexp value
  • 'amenity', 'shop', 'craft', 'highway', ...
• opening hours type

deprecated keys/tags

• https://wiki.openstreetmap.org/wiki/Deprecated_features

We have a Wikibase proposal for the central metadata, but I am not sure this is a best solution for us.

• https://wiki.openstreetmap.org/wiki/OpenStreetMap:Wikibase
  We need more information, more planning.

[dktue]

@ImreSamu : Is it really necessary to do this all at once? What I want to start with this discussion is encouraging people and convincing the developer-community that this is feasible. OSM can evolve, we're not forever locked to the current state.

So: Why can't we simply start with an area-metadata without having to plan metadata-organisation itself from scratch?

[dktue]

@mmd-osm : Of course it would be better to have a separate area data type. The advantage of an area attribute would be that it is completely backwards compatible.

[dktue]

@mmd-osm
What if instead of an (asynchronous) bot we build the logic directly into the backend? If the user uploads a way without area attribute the backed guesses and attaches the guessed value directly (synchronously)?

[ImreSamu]

@dktue

Why can't we simply start with an area-metadata without having
to plan metadata-organisation itself from scratch?

imho we need a minimal discussion about the " Local optimum vs global optimum dilemma".

I would like to reuse this metadata for QA tools and/or in the (future) central metadata repository.

imho: - this area metadata can be a puzzle piece - in the "big metadata picture".

Connection with

• other metadata
• other tools
  is important.

for me - some important design corner stones:

• programming language independent metadata ( no Javascript, no lua, .. code )
• I can easily merge with other similar metadata ( ~ similar key/tags structure )
  • so this is like a metadata puzzle piece - where each piece should fit together. And the overall osm metadata picture becomes coherent.

[dktue]

@ImreSamu : Where is the right place to discuss the metadata picture?

[ImreSamu]

@dktue

Where is the right place to discuss the metadata picture?

I don't know, a new "issue" here?

imho: This is related to the collecting the Business requirements. I am only one of business stakeholders that have requirements. ( as a QA tool writer )