[Tagging] Layers (was Eruvs etc.)

[Minh Nguyen]

Vào lúc 12:42 2022-09-06, Zeke Farwell đã viết:
> 
> On Tue, Sep 6, 2022 at 6:50 AM Frederik Ramm 
> <frederik at remote.org 
> <mailto:frederik at remote.org>> wrote:
> 
> 
>     (I have several thousand such "boundaries slightly overlapping but not
>     quite" examples all over the planet. A few of them will probably be
>     "unlikely but correct", but most will just be sloppy mapping or sloppy
>     importing.)
> 
>     In my opinion, "layer thinking" means giving up on the shared
>     stewardship of the map, and allows everyone to dump their garbage into
>     OSM with an excuse of "you can switch that layer off if you do not like
>     it". I think it would be detrimental to OSM.
> 
> 
> These slightly overlapping boundaries are a great example of sloppy 
> mapping, and I share the concern of garbage data being dumped into OSM.  
> However, I do not find this to be a strong argument against the concept 
> of layers.  People seem perfectly capable of garbage dumping with the 
> current data model.  No layers necessary!  Rather than "layer thinking", 
> I would call this lazy, narrow minded, or inconsiderate thinking.  In a 
> layer based OSM data model I'd expect each layer to contain similar 
> object types where topological connections between them are often 
> appropriate, and the separation of object types where topological 
> connections are not appropriate.  For example highways could connect 
> within the highway layer and boundaries could connect within the 
> boundary layer.  However, the separation into layers would prevent 
> unwanted connections between highways and boundaries.
> 
> In such a system, properly aligning and connecting boundaries would be 
> just as encouraged as it is now, and unmotivated mappers would be able 
> to map boundaries just as sloppily as they do now.  What they wouldn't 
> be able to do is connect boundaries to highways, land cover, land use, 
> waterways, etc.  This would make the data easier to work with and 
> maintain since editing an object of one type would not require also 
> editing other object types that happen to be connected to it.

This doesn't strictly require layers as a first-class concept within the 
database. There have been countless requests for editors to block such 
connections, just as they warn about or block nonsensical connections 
between certain feature types already. These discussions always start 
out with blanket statements and quickly get bogged down in 
counterexamples as we think harder about what people are actually 
mapping and find it hard to say no to these things. [1][2]

OSM let the genie out of the bottle many years ago by allowing 
connections between arbitrary feature types. In the intervening years, 
mappers have poured a lot of effort into mapping these connections. Our 
tagging model has grown up around the idea that you can micromap in 
increasing detail while keeping smaller features explicitly connected to 
the broader feature.

"Any tags you like" certainly keeps this mailing list interesting, but 
would we also have "Any layers you like"? If we had started out with 
traditional GIS layers, there would be much more reliance today on tags 
that indicate the presence of something (atm=yes, bench=yes, shop=yes, 
swimming_pool=yes, etc.), and there would've been a higher barrier to 
mapping novel things. We would've lacked the flexibility that recently 
allowed man_made=funding_sign to become advertising=funding_sign and 
finally message=funding as we grappled with the right level of 
abstraction. [3]

Fundamentally, the world we're mapping is not built in stratified 
layers. A standard GIS database treats connections between layers as a 
special case if at all, but this is workable because the database exists 
for a small, well-known set of use cases. One of the unique aspects of 
OSM is that it serves many use cases and is designed to be extensible to 
use cases we haven't thought of, yet we don't really try to trade off 
one use case for another. I predict that moving in the direction of 
formal layer separation would pose a significant test to the project's 
social processes as much as to any technical process.

[1] https://github.com/openstreetmap/iD/issues/6631#issuecomment-509190000
[2] https://github.com/openstreetmap/iD/issues/8263#issuecomment-749279400
[3] https://wiki.openstreetmap.org/wiki/Talk:Tag:message%3Dfunding

-- 
minh at nguyen.cincinnati.oh.us