<div dir="ltr">Reliability and completeness is not an inherent strength of OSM. Separate storage does not really matter, I think.  <div>Any person organization needing reliable data can use OSM, but will need to implement additional QC and QA (and things like controlled imports), no matter if the data is stored in OSM or in a separate database / dataset.</div><div><div><br></div><div>The main question is: who will do the QA and QC. My answer is always: the people who need the quality data. </div><div><br></div><div>Peter Elderson<br></div><div><br><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Op ma 11 jan. 2021 om 07:13 schreef Joseph Eisenberg <<a href="mailto:joseph.eisenberg@gmail.com">joseph.eisenberg@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr">> Re: "is still treated with disdain for essentially dogmatic reasons."</div><div dir="ltr"><br></div><div>I certainly did not disdain or dismiss the importance of administrative boundaries. I said that some of them are not a good fit for the database. </div><div><br></div><div>Not everything that is important or useful is a good fit for OpenStreetMap. For example, digital elevation data is extremely important and useful if you want to make a topographic map. But we don't mass-import contour lines or elevation points into the OpenStreetMap database, because the huge amount of ways and nodes would make it hard to edit anything else, and mappers could only make it worse. Fortunately, other open sources of elevation data are available and often used together with OpenStreetMap data to render good maps or produce routing results which take elevation into count (e.g. for bike routing).</div><div><br></div><div>Similarly, traffic data is very important for routing. We don't have this in OpenStreetMap because we can't collect it and maintain it easily. We also don't have reviews of restaurants because the data is subjective and we don't have a way to verify accounts or remove huge amounts of spam. </div><div><br></div><div>If you had been on this list 2 years ago when I first got involved, you would have seen that I did not originally believe that practical verifiability was that important, I just wanted a nice looking map, by whatever means. But after learning more, I've realized that we need to first think about what mappers can actually maintain and improve.</div><div><br></div><div>> Re: "I know I for one would be happy to have the problem of mappers accidentally editing (and breaking) boundaries be solved by some sort of technical solution that separates this data in some way from other features!"</div><div><br></div><div>This is precisely why it would have been better to build a separate dataset with just these boundaries, based entirely on official imports. But since pretty good admin boundary data is conveniently available in our main database there is not much motivation to duplicate it elsewhere now, even though that means boundaries will constantly be damaged and incomplete. </div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jan 10, 2021 at 8:47 PM Brian M. Sperlongano <<a href="mailto:zelonewolf@gmail.com" target="_blank">zelonewolf@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div></div><div>I am willing to argue that local administrative boundaries and other types of boundary relations are often not verifiable and therefore are a poor fit for OpenStreetMap. If the only source for the boundary is importing it from an official database, then OpenStreetMap users can never hope to improve the data. This is often the case for minor boundaries which are not significant, e.g. admin_level=9 or =10, and sometimes even lower numbers like municipalities.</div><div><br></div><div>It would have been better for us to have developed a separate, open-source database for just administrative boundaries (and other data that can only hope to be imported, like protected areas), where the data would not be mixed up with the things that mappers need to be editing. Any time you edit an administrative boundary you are just making it worse, if it was imported from a reliable source.</div><br>But this is all just whataboutism - administrative boundaries are already imported, and I am not actually suggesting we get rid of them, even though we can't hope to make them much better than the official maps (except at the international border level).</div></div></div></blockquote><div><br></div><div>I developed a service that consumes administrative boundaries at level 5-10, predominately at level 7 and 8.  Simply put, I could not have built it without the ability to access administrative boundaries in bulk, and query for features within those boundaries.  I am certainly not alone in consuming this type of data.  Boundary data is so useful in a global map project for any number of usages that it amazes me that it is still treated with disdain for essentially dogmatic reasons.</div><div><br></div><div>I am not aware of any other service or database that has managed to assemble a global aggregation of continuously updated boundary information.  If there is such a service, it certainly isn't free.  It seems short-sighted to hand wave away this aggregation as just a copy of other databases when you consider the work that went into creating it, and breadth of applications that it enables!</div><div><br></div><div>Of course, if boundary data had emerged as a separate project, BUT there was still an easy way for data consumers to extract data within boundary polygons, that would certainly scratch the itch.  In the ten years we've been waiting for the probably-apocryphal API 0.7, "layers" comes up frequently as a requested feature.  Perhaps in a future where OSM has a layer implementation, this might allow us a space where we could have appropriate separations, and different rules, tools, and ecosystems that are different for boundaries than they are for categories of features.</div><div><br></div><div>I know I for one would be happy to have the problem of mappers accidentally editing (and breaking) boundaries be solved by some sort of technical solution that separates this data in some way from other features!</div></div></div>
_______________________________________________<br>
Tagging mailing list<br>
<a href="mailto:Tagging@openstreetmap.org" target="_blank">Tagging@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/tagging" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a><br>
</blockquote></div>
_______________________________________________<br>
Tagging mailing list<br>
<a href="mailto:Tagging@openstreetmap.org" target="_blank">Tagging@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/tagging" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a><br>
</blockquote></div>