What's the state of the area datatype proposal?

General talk
1

I’m referring to this

Is it still current ?

Is anyone working on this ?

Who is, possibly ?

Are there any updates on the state of progress of such work ?

Or: is this idea abandoned or freezed ?

Why ?

Thanks

2

You are looking at the outdated section Area/The Future of Areas - OpenStreetMap Wiki

I’m guessing EWG is focused on vector tiles currently?
Last might explain the lack of pressing needs, incentives, and priority Paper about "Evolution of the OSM Data Model" - #4 by ZeLonewolf

3

This is something that came up as a potential area of investigation when I was putting together a roadmap for OSM’s core software. The general sentiment among developers I talked to was that the data model study’s recommendations (eliminating way nodes, introducing an area type) would require significant time and funding not only toward OSMF or OSM projects but also toward affected data consumers. As the paper points out, there is precedent for this to happen if and when there is sufficient demand.

In the meantime, we’ll continue to cope with paper cuts like a subtle semantic difference between area:highway=* and highway=* area=yes and opinionated conversions to non-OSM file formats. If you have development skills, there may be ways to help out even if we aren’t quite ready to take the leap into a new data model.

2 Likes
4

You’ve already been pointed to current work on the data model, but I would note that we could and probably should add an area attribute to ways even without any of the other changes.

But what I really wanted to point out is that that wiki page completely ignores the advantages of the current approach to areas, if not to say the massive advantages of the current approach.

There is a reason none of the numerous alternatives suggested over the years ever got any traction, because overall they have always been worse than the status quo.

5

What are some ways to help ?

6

For example, I linked to an example of a developer mentioning implicit area tags as a source of complexity. Everyone rolls their own list and no one is confident about theirs. An up-to-date reusable package like id-area-keys for that or another platform could be helpful to developers freshly confronting this issue, such as osm2geojson-ultra, which is being considered for the map on the main website’s homepage once we migrate it to MapLibre. Or if you see an incomplete implementation anywhere, that could be a place to start contributing.

1 Like
7

I would dispute that GitHub - simonpoole/osm-area-tags: Data on which OpenStreetMap tags imply areas · GitHub

That’s a bit unfair as ATYL includes semantics and I can in seconds render any list incomplete.

8

The problem is that everyone is confident of theirs :grinning_face:

5 Likes
9

PS: this bit of the discussion is why adding an area attribute to the way data model would be such an easy win, with minimal impact on tooling and API.

4 Likes
10

Just to be clear, you’re referring to something like <way area="true"> in OSM XML? An additive approach, optional to consume, would certainly be cleaner than one that overhauls a larger chunk of the data model, but it’s still a change to the data model. If we want the attribute to be more than a footnote on a wiki page, then at a minimum:

  • The OSM database needs another table to track whether a way is an area.
  • Any low-level software that serializes or deserializes OSM XML needs to roundtrip the attribute, including software that previously didn’t care whether a way is an area. Will anything get confused if a changeset does nothing but flip area="true" to area="false" on some way, incrementing its version?
  • Alternative transfer formats like OSM JSON, Overpass JSON, Level0L, and the various formats that Osmium understands all need to encode the attribute to avoid dataloss.
  • JOSM needs to consume the attribute when downloading Overpass API results.
  • Editors need to automatically set the attribute based on their understanding of which tags suggest an area representation.
  • Mappers need to retrofit the attribute onto existing areas, probably in bulk edits.

This is without considering what data consumers would eventually do with the attribute. The multipolygon refactoring project demonstrates that we could feasibly carry out many of these tasks with adequate volunteer effort and/or funding. Either way, it’s going to require more coordination than a handshake agreement about a less widespread format. Would any of you be interested in helping to sketch out these ideas in more detail?

2 Likes
11

As an EWG member, I was somewhat closely involved with commissioning Jochen’s data model study. The sentiment I perceived from core devs and the OSMF board at the time was that the proposed project exceeded the OSMF’s abilities both in terms of budget and ability to coordinate between the various parts of the OSM ecosystem affected by such a change.

At the time, this would have indeed been somewhat unprecedented in scope. Since then, there have been some larger OSMF-funded engineering efforts (e.g. vector tiles), and we do have invested in our ability to coordinate software projects (e.g. with Minh’s Core Software Development Facilitator role). So maybe we’re approaching the point where it’s feasible, or maybe a more gradual approach such as just introducing an “area attribute” for ways to the data model would lower the barriers enough that it would be within reach.

In any case, I still feel that an area datatype is a glaring omission from the OSM data model, and would welcome progress in this regard.

12

To be clear the “easy” was relative to a total overhaul or just any of the more involved area datatype proposals (the idea of adding an area attribute to ways is at least a decade old), it doesn’t mean “no effort”.

Quick brain dump:

If we seriously want to do this a 1st step would be to actually nail down the semantics. One thing would be do we want areas to “auto-close” or should we require ways with the attribute set to be closed (my preference as this is backwards compatible). There are probably a couple of more things (for example can normal ways morph in to area ways and vice versa or not).

Then there’s the question of generating 0.6 data format compatible output (from a practical pov a must). As elements that shared a geometry between a linear geometry and an area would have to be split up in to two (potentially glued) during migration (how big of an issue this is is one of things that we should quantify) this shouldn’t be a big issue, that is adding back an area tag should be enough for tagging that doesn’t imply an area and everything else will already be correct.

1 Like
13

I agree that there’s an elegance to the attribute idea that we should consider for any future work in this direction. For many reasons, our data model isn’t going to resemble Simple Features, nor would we want it to. An area attribute evolves the data model we do have in a manner that’s at least explainable.

From a data consumer standpoint, it would be nice if an area is guaranteed to be closed. We have plenty of unclosed ways with area=yes on them and plenty of broken multipolygons. The sky hasn’t fallen, but it is annoying to have to deal with (and the area attribute won’t solve it in the case of multipolygons).

During a transition period, data consumers would have no choice but to consider the attribute as just another signal on top of any existing heuristics for detecting an area. Eventually, the heuristics would recede in importance, just like any residual code to handle old-style multipolygons. As long as those other heuristics are around, there will be a porous boundary between line ways and area ways.

On the editor side, I’m not terribly concerned that one editor might allow converting between areas and normal ways while another doesn’t, as that’s already the status quo with respect to the area=yes tag. Additionally, some editors can convert fairly seamlessly between “areas” and multipolygon relations, and there was even talk of doing the same between lines and multilinestring relations in some cases (speaking of Simple Features).

Are you referring to dual tagging, such as leisure=dog_park barrier=fence on the same closed way? I think mappers would have to come to terms with the tradeoff of having to map two features as two elements that share the same nodes. Alternatively, if they insist, they could still map the area as a single-element multipolygon, ugh.

14

As to morphing, if to and how to allow it can just be a convention (just as not bumping way versions on way node geometry changes is just a convention nothing else). IMHO to maintain history in some form we should allow splitting area ways (obviously setting an area attribute to false), if we should go as far as iD and then automatically create a MP is a matter of debate (because of the downsides that has).

Yes. Double tagging wouldn’t be possible in such a scenario (one of the main reasons we are having this discussion). A migration could double such ways automatically and/or we could migrate them manually, if there are only a couple of 1’000 then the later makes most sense, if there are 100’000 less so.

15

For starters, 485,996 ways combine landuse=* with barrier=*. A few barrier=* tags can represent areas, such as wall and hedge, but those instances of dual tagging are more likely to intend the barrier as a linear feature rather than a micromapped area. It’s probably just the tip of the iceberg.