[Tagging] Feature Proposal - RFC - shop as post-partner

Bert -Araali- Van Opstal bert.araali.afritastic at gmail.com
Sat Feb 27 22:03:28 UTC 2021


I think we are getting your point Rubik, and it's a problem of data 
consistency, which is not implemented in our data structures versus a 
system, like Georg already explained professionally, as an alternative: 
allowing multiple values in top level keys / agreeing on value 
combinations. Since our data structure is set up as supporting only 
uniique values do we want to end up with endless lists of values because 
there are millions of combined services around the world. Is that where 
we want to go?
Or regard a relation as the one shop containing several nodes as 
services, there is just no way to define it otherwise, the nodes are 
data containers, not in the strict sense additional spatial information.

Using relations in this context could support in better data 
consistency, it doesn't enforce it but at least in JOSM when I delete a 
relation or delete an element in a relation I get a warning that it 
might compromise data consistency.  I am not a favourite of using 
spatial relationships to create these links, because non-spatial data 
consumers will not be able to process these and this type of multiple 
node usage coudl create some confusion in rendering. The nodes are more 
like singular data containers, again because of our data model. No one 
stops a renderer however to render the relation as a single POI on a map 
and consider those individual nodes, contained in the relation as just 
data containers.

I don't think neither of both (or the three) can ever offer a water 
tight solution or satisfy everyone.  But if we want to tag these kind of 
features, and I think we should, it's rather making a choice between bad 
or not complete alternatives:

- we want to evolve into a model with millions of unique keys trying to 
define all kinds of combined uses

or

- a more relational model that can support some data consistency through 
validations in our editors, which we already have.

or we allow both to co-exist which makes the whole model even more complex ?

Greetings,

Bert Araali

On 28/02/2021 00:26, Robin Burek wrote:
> Am 27.02.2021 um 22:08 schrieb Martin Koppenhoefer:
>> it depends on the semantics we imply for our tags. How important is 
>> it to know whether it is one shop or two, at the same place
>
> I think it is very important. And heres a example: A week ago I was 
> standing in Berlin searched for a post partner-store, that was 
> disclaimed as an "post_office" in OSM. Hell and there was nothing at 
> all.... And why? Yeah, the real shop was closed two years ago. Thanks! 
> Due to two nodes it causes an error at some point - stupid, now it hit 
> me again. But it further reinforces the fact that setting multiple 
> nodes does not make sense. And I refer to it again - a shop-in-shop is 
> not meant!
>
> And if your argument goes like you called before, then you have to 
> list each meat or cheese counter individually. These are own services...
>
>
> _______________________________________________
> 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/20210228/05cc2d67/attachment-0001.htm>


More information about the Tagging mailing list