<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>[Very OT]<br>
</p>
<p>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. <br>
</p>
<p>Simon<br>
</p>
<div class="moz-cite-prefix">Am 05.09.2022 um 22:24 schrieb Brian M.
Sperlongano:<br>
</div>
<blockquote type="cite"
cite="mid:CAMrfQx08nB30WE2NLeRTaSbkK1EetT-CMtp2FE_DchMYe78=9A@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr"><br>
</div>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Sep 5, 2022 at 1:25
PM Frederik Ramm <<a href="mailto:frederik@remote.org"
moz-do-not-send="true" class="moz-txt-link-freetext">frederik@remote.org</a>>
wrote:</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">is there agreement that
something physical needs to be there for a religious
boundary to be mapped</blockquote>
<div><br>
</div>
<div>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.</div>
<div> <br>
</div>
<div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">I don't like it at all
- you can find places in OSM that are covered by 5 or more
such boundaries</blockquote>
<div><br>
</div>
<div>This is really the crux of the issue, increasing
numbers of objects in the same place, which results in:</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">they make editing
harder for mappers<br>
</blockquote>
<br class="gmail-Apple-interchange-newline">
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div><br>
</div>
</div>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Tagging mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Tagging@openstreetmap.org">Tagging@openstreetmap.org</a>
<a class="moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/tagging">https://lists.openstreetmap.org/listinfo/tagging</a>
</pre>
</blockquote>
</body>
</html>