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

[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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20220905/213464af/attachment-0001.htm>