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

[Peter Elderson]

Reliability and completeness is not an inherent strength of OSM. Separate
storage does not really matter, I think.
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.

The main question is: who will do the QA and QC. My answer is always: the
people who need the quality data.

Peter Elderson



Op ma 11 jan. 2021 om 07:13 schreef Joseph Eisenberg <
joseph.eisenberg at gmail.com>:

> > 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
>>
> _______________________________________________
> 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/20210111/d048773d/attachment.htm>