[Tagging] RFC: Removal of Eruvs from OSM, and further boundry=religious

[Simon Poole]

[Very OT]

People could simply filter out boundaries for display purposes -right 
now-. One problem with that is not that it doesn't work, but that it 
creates magical links between visible and invisible objects. Doing away 
with shared geometries/nodes as Jochen proposes would/could make that 
aspect of the issue go away.

Simon

Am 05.09.2022 um 22:24 schrieb Brian M. Sperlongano:
>
> On Mon, Sep 5, 2022 at 1:25 PM Frederik Ramm <frederik at remote.org> wrote:
>
>     is there agreement that something physical needs to be there for a
>     religious boundary to be mapped
>
>
> Of course there isn't agreement.  Like anything else on the project, 
> reasonable people disagree on the topic of what belongs in the map.  
> Some people think that time zones should be deleted, and some think 
> they are useful. Likewise, some people think that recording the exact 
> shape of the roof on a building, or the exact species of each tree in 
> a city park are a waste of time that makes the database 
> unnecessarily bloated.
>
>     I don't like it at all - you can find places in OSM that are
>     covered by 5 or more such boundaries
>
>
> This is really the crux of the issue, increasing numbers of objects in 
> the same place, which results in:
>
>     they make editing harder for mappers
>
>
> And here lies the problem.  We built a technical solution a decade and 
> a half ago that doesn't do a great job of supporting the level of 
> detail and types of features that mappers and data consumers wish to 
> have in a common data source.  In a "typical" GIS system, data is 
> divided into layers.  So if you don't want to see religious boundaries 
> when mapping trees in Karlsruhe, you don't have to - they're separate 
> objects in separate layers that can't be comingled.  We wouldn't be 
> having this debate because the craft tree mappers would not have a 
> care in the world how many paper boundaries were getting shoved into 
> the boundary layer - it's a separate database that doesn't impact it. 
> The problem isn't that mappers are trying to add things that clutter 
> other mappers' JOSM or iD screens, the problem is that our monolithic 
> GIS database isn't scaling to meet the community's needs.
>
> I have to say that I'm disappointed that Jochen's recent data model 
> study failed to identify the problems, both technical and people-wise, 
> that have resulted from the single layer approach.
>
> I think the current infrastructure could expand to support layers by 
> creating separate database instances for each layer.  Boundaries could 
> be the first such layer forked off from the main database, and copied 
> over in some sort of automated fashion onto the boundary layer 
> instance.  You'd have a migration strategy, with timelines for data 
> consumer to adapt, with the end state being that all boundary edits go 
> into the boundary layer and other edits go into the main database.  
> Repeat for any other feature classes which are desirable to separate.
>
> Wrapping our hands around the layers problem would certainly be more 
> work than parading on the mailing list to complain about someone 
> else's pet feature that's cluttering up your favorite editor.  
> However, it would be the right thing to do, and thus I expect that 
> we'll continue to wring our hands about objects in the database that 
> we don't like.
>
>
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20220906/582f8369/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20220906/582f8369/attachment.sig>