[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