[Tagging] Boundaries (was: Grouping buildings together using relations)

Joseph Eisenberg joseph.eisenberg at gmail.com
Mon Jan 11 06:10:49 UTC 2021


> Re: "is still treated with disdain for essentially dogmatic reasons."

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.

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).

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.

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.

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

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.

On Sun, Jan 10, 2021 at 8:47 PM Brian M. Sperlongano <zelonewolf at gmail.com>
wrote:

>
> 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!
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20210110/0b246291/attachment-0001.htm>


More information about the Tagging mailing list