<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">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>