Layered Model

[MaasOne]

I participate in OSM for one year now and also read a lot of forum entries. During this time I came along that one of the biggest problems of OSM data model is the absence of layers.

A lot of discussions in the forum intensified just because of different opinions of what should be part of OSM and what not. On the one side I can understand that too many "unnecessary" data wouldn't be useful for the actual project for different reasons, mainly there are "on the ground", technical editing and quality/maintainability issues. On the other side a lot of these "unnecessary" data could improve the attractiveness of OSM for a lot of new users and applications. Of course there is a fine line between "could be generally useful" and "private data base".

Another reason for splitting the data could be indoor vs. outdoor mapping. Indoor mapping has a lot more nodes than outdoor mapping on the same area size. This can influence the editing experience i.e. when I'm just editing outdoor but have to download/handle all these indoor data. The same with the usage of the data. If I'm not interested in indoor data for my project I wouldn't need all that "overhead". Overpass is also an issue here. Queries with outdoor only scope could process much faster without indoor data in the data source. The indoor vs. outdoor mapping issues are not so much relevant today, but could be in future.

So, I think there are very good reasons for changing to a layered model. But some new issues would pop up with a layered model. Especially I'm thinking of shared nodes. Today i.e. administrative boundaries can share nodes with a river, because the border is defined as watershed. Or a boundary way can contain a milestone/borderstone node. The river or the milestone could be with a layered model in a different layer than the admin boundaries which would get its own layer. The question is then if there is some kind of reference between layers which could complicate the things, or would the layers be strictly independent of each other?
Also a question would be how far the "base layer" would be splitted. I.e. administrative boundaries would form a separate layer, that's clear. But what to do with the rest. Are buildings and streets in the same layer or separated? What to do with waters (sea, lakes, rivers, etc.)? Is there one big base layer or should everything be separated? And so on...

My main reasons for a layered model is avoiding a lot of discussions, handling the increasing amount of data and making OSM more attractive for "special scope" users too. All that can be achieved with a layered model.

So far...

Would be great when you participate in this discussion. I would be happy to hear about new ideas, examples and solutions for this issue.

Maas

[flacombe]

Hello :)

To me, a layered model means splitting OSM in several independent projects, with pros and cons you've mentioned.

Consumers already have the ability to select what is interesting to them by making a query.
As said, despite a potential high amount of data to handle, contributors have to get the whole dataset as to ensure consistency and not adding something in their view which is already existing in the main database.

No layers is a killer feature of OSM and one cool solution is filters in editors to remain focused despite an overcrowded map :)

Regards

[pietervdvn]

Hi,

I'm the author of MapComplete, of which the big strength is to present the map data as if they are layered.

And yet, I'm against splitting the data into layers. Let me give an example: where I live, there is a cafe which also is a boardgame shop and a social project for mentally disabled people. In what layer should the data go?

And what which e.g. railway crossings? And if the railway receives an update, won't people forget to update the road and the crossing?

[mmd-osm]

Overpass is also an issue here. Queries with outdoor only scope could process much faster without indoor data in the data source.

FWIW: the amount of indoor data is so tiny that it doesn’t make a difference in any practical way.

The area where I see most friction is with historical artefacts which are no longer existing. Today, we’re suggesting that folks move over to other projects such as OpenHistoricalMap. A built in layer for such data would ease the pain but it comes with huge costs.

[1ec5]

OpenHistoricalMap itself relies much more heavily on tag filtering than OSM does, so I’m not sure it would benefit much from formal layers anyways.