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

Sat Feb 27 18:52:14 UTC 2021

> " 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
- 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> 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 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, 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 and
> 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
>
>
> _______________________________________________
> Tagging mailing listTagging at openstreetmap.orghttps://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/5df19d13/attachment-0001.htm>