[Tagging] Boundaries (was: Grouping buildings together using relations)
Brian M. Sperlongano
zelonewolf at gmail.com
Mon Jan 11 04:44:50 UTC 2021
> 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.
> 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.
> 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).
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.
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!
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.
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!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Tagging