[Tagging] Feature Proposal - RFC - shop as post-partner
Bert -Araali- Van Opstal
bert.araali.afritastic at gmail.com
Sat Feb 27 19:31:35 UTC 2021
It was not intended as to be the one and only solution, just an example
how it was solved here long time ago with what was available at that
time, and for sure as I said before lots of room for improvement.
I totally agree, if there is a one and single same service provided,
there is nothing against using multiple values in attributes for the
same service. That isn't feasible in many multi-disciplinary places if
you try to tag them with multiple different top level keys. But as
marc_marc said, we've passed that point.
1 or 2 nodes or even more nodes I think is best practice to be guided by
the concept if we can define the one node with a single value for the
top level key, covering all the services provided, if that isn't clear
use more nodes. Carefully consider that on a case by case bass but don't
favour or exclude one or the other, just give some guidance to make it
as simple as possible. Attributes like brand or owner names, if the
service is identical to the one chosen as top level key, of course, go
for it. It should be a one to many, not a many to one or many to many
relationship.
If they differ however, then you would split again, it's a different
feature in the map, a different service for which we have a different
top-level tag. It needs to be considered on a case by case basis.
At present, I would favour also to use a relation to link different
services to one single place of service, not the relationship by
manipulating and duplicating the names. Just to avoid duplicating data
but also to make the link more explicit.
Greetings,
Bert Araali
On 27/02/2021 21:52, Joseph Eisenberg wrote:
> > " if a shop provides postal services from company A as well as from
> company B, again we split it in different nodes with owner (owner of
> the service provided since the shop is a licensor, brand=* is another
> candidate) is owner=Company A and another node with owner=Company B"
>
> I believe this is incorrect.
>
> It is totally fine to use multiple values with a semicolon in property
> tags like network="Company A;Company B" so that a single counter which
> provides services from two different systems can be mapped properly,
> e.g. a mobile phone shop which sells SIM cards and service refills for
> two different mobile phone systems.
>
> Using two different "owner=" tags seems incorrect, because we are
> talking about one shop or one service counter in a shop, which has one
> local owner.
>
> (The case where I might use two different nodes would be something
> like this Orange Julius and Dairy Queen in Singapore: they share a
> building and employees but have two different counters right next to
> each other:
> https://en.wikipedia.org/wiki/Orange_Julius#/media/File:Orange_Julius-SG.JPG
> <https://en.wikipedia.org/wiki/Orange_Julius#/media/File:Orange_Julius-SG.JPG>
> - this way you can have each brand=* separately, a few meters apart.
> The alternative of "brand"="Orange Julius;Dairy Queen" seems worse,
> though I would not fault anyone who mapped it as a single shop with a
> semicolon for the brand= and name=)
>
> -- Joseph Eisenberg
>
> -- Joseph EIsenberg
>
> On Sat, Feb 27, 2021 at 10:18 AM Bert -Araali- Van Opstal
> <bert.araali.afritastic at gmail.com
> <mailto:bert.araali.afritastic at gmail.com>> wrote:
>
>
> On 27/02/2021 20:55, Robin Burek wrote:
>> I could cry....
>>
>>
>>> Very true, same here, but that shoudn't stop you from using
>>> different
>>> nodes which are closely mapped to each other. When someone searches
>>> for a specific service they will show up on the same screen. It
>>> makes
>>> it also a feasible concept and easy to understand for beginner
>>> mappers.
>>
>> Than it is mapping for the randerer. You create extra nodes to show
>> multiple services of one shop/amenity etc. to display it on the map.
>> And really - I don't understand it after years. Why should I map
>> an shop
>> four or five times?!?! There is only ONE SHOP.
> Nope, we don't tag primarily for tagging, we use different nodes
> to avoid duplicating data, to avoid to have to add multiple values
> in the same key. The rendering is a nice positive side effect.
> It's ONE shop with multiple services or is it ONE service supplied
> at ONE place. This concept is used in other cases.
>>
>>
>>>>
>>>>> We also considered using relations for this to avoid
>>>>> duplicate names, but at the time didn't seem a good idea
>>>>> because most
>>>>> data consumers didn't process relations.
>>>>
>>>> Relations sound interesting as they avoid duplicate data AND
>>>> make clear
>>>> that several different features are belonging together AND it
>>>> works for
>>>> all kinds of features in OSM (relation/way/point).
>>>>
>>>> Do you know how data consumers respond to it nowadays, e.g. when
>>>> searching for such a feature in maps.me <http://maps.me> or
>>>> OsmAnd or Locus, do they
>>>> display e.g. the opening hours of the relation, or do they at
>>>> least show
>>>> the point is part of a relation and thus you can look up the
>>>> opening
>>>> hours manually (e.g. by following a link from point to relation)?
>>>
>>> We still provide the names of the service owners in the name
>>> fields,
>>> because some users might prefer Company A instead of Company B and
>>> some licensors provide the same service for different brands. This
>>> concept was developed initially by a HOTOSM project. So they
>>> use the
>>> standard humanitarian mapping on OSM and Nominatim. I don't
>>> know if
>>> Nominatim does support searching in owner and operator keys now, At
>>> the time this concept was developed it was not the case however
>>> like
>>> f.i. with maps.me <http://maps.me>, I don't know if that has
>>> evolved in the mean time,
>>> neither for the other ones. It is however the reason why we still
>>> duplicate the service owner names in the name fields, which is
>>> not an
>>> advisable good practice but makes it work in most data consumers
>>> and
>>> rendering.
>>>>
>>>>> But we have some candidates like relation=site, relation=cluster
>>>>
>>>> I found only the proposals under way
>>>> https://wiki.openstreetmap.org/wiki/Relations/Proposed/Site
>>>> <https://wiki.openstreetmap.org/wiki/Relations/Proposed/Site> and
>>>> https://wiki.openstreetmap.org/wiki/Relations/Proposed/Cluster
>>>> <https://wiki.openstreetmap.org/wiki/Relations/Proposed/Cluster>
>>>> despite
>>>> >>100k uses?! Amazing.
>>>>
>>>> I think relation=site would be suited for the postal partner case.
>>> True, they do exist since long time, developed when there was a
>>> need
>>> to develop parent-child relations which never got well documented.
>>> We have a big improvement to make in that. We didn't consider
>>> it as
>>> a feasible solution because the names of these relations (site /
>>> cluster but also group which is somehow identical to cluster) don't
>>> show up in any rendering in OSM.�
>> The problem is - when and where you want to display the name on wide
>> range sites like [1] - but it is a different problem that is not
>> supposed to be discussed here.
> Agree, no need to discuss that here, just wanted to give it as a
> justification why it was not considered as feasible in that
> particular project, because it's not rendered, but we don't tag
> for the renderer !
> However, although we all agree with that concept, many consider
> other tagging schemes, not relations as more favourable without
> saying explicitly it's because of rendering issues.
>>
>> [1] - https://www.openstreetmap.org/relation/128009
>> <https://www.openstreetmap.org/relation/128009>
>>
>>
>> _______________________________________________
>> Tagging mailing list
>> Tagging at openstreetmap.org <mailto:Tagging at openstreetmap.org>
>> https://lists.openstreetmap.org/listinfo/tagging <https://lists.openstreetmap.org/listinfo/tagging>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org <mailto:Tagging at openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/tagging
> <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/20210227/d113d370/attachment.htm>
More information about the Tagging
mailing list