<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 27/02/2021 19:47, Georg wrote:<br>
</div>
<blockquote type="cite"
cite="mid:1N9dsV-1lv1kg25rR-015Xdf@mail.gmx.net">
<br>
Am 2021-02-27 um 16:47 schrieb Bert -Araali- Van Opstal:
<br>
<br>
> - tag a building as amenity shop, supermarket, bank, postal
office
<br>
> etc..., and tag it with it's primary service keys. Apply
one unique
<br>
> name. In the building add additional names for the
supplementary
<br>
> services you want to map, without providing a name.
<br>
<br>
While I like this "linking approach" quite a lot for its
simplicity,
<br>
IMHO it is not a well feasible solution for our case: In Germany,
a
<br>
_considerable_ share of shops/offices/amenities offering also
postal
<br>
services are not having a complete building on their own (like
building
<br>
supply markets usually have), nor is indoor mapping common enough
that
<br>
they have a polygon on their own (e.g. within a shopping mall),
but many
<br>
of these shops/offices/amenities are mapped as points only - as a
point
<br>
does not stretch, it can't contain anything.
<br>
</blockquote>
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.<br>
This tagging scheme in the mean time is extended, so we use operator
and owner keys to distinguish one service from another, with the
same motivation, so f.i. 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. <br>
<blockquote type="cite"
cite="mid:1N9dsV-1lv1kg25rR-015Xdf@mail.gmx.net">
<br>
<blockquote type="cite">We also considered using relations for
this to avoid
<br>
duplicate names, but at the time didn't seem a good idea because
most
<br>
data consumers didn't process relations.
<br>
</blockquote>
<br>
Relations sound interesting as they avoid duplicate data AND make
clear
<br>
that several different features are belonging together AND it
works for
<br>
all kinds of features in OSM (relation/way/point).
<br>
<br>
Do you know how data consumers respond to it nowadays, e.g. when
<br>
searching for such a feature in maps.me or OsmAnd or Locus, do
they
<br>
display e.g. the opening hours of the relation, or do they at
least show
<br>
the point is part of a relation and thus you can look up the
opening
<br>
hours manually (e.g. by following a link from point to relation)?
<br>
</blockquote>
<br>
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.
<blockquote type="cite"
cite="mid:1N9dsV-1lv1kg25rR-015Xdf@mail.gmx.net">
<br>
<blockquote type="cite">But we have some candidates like
relation=site, relation=cluster
<br>
</blockquote>
<br>
I found only the proposals under way
<br>
<a class="moz-txt-link-freetext" href="https://wiki.openstreetmap.org/wiki/Relations/Proposed/Site">https://wiki.openstreetmap.org/wiki/Relations/Proposed/Site</a> and
<br>
<a class="moz-txt-link-freetext" href="https://wiki.openstreetmap.org/wiki/Relations/Proposed/Cluster">https://wiki.openstreetmap.org/wiki/Relations/Proposed/Cluster</a>
despite
<br>
>>100k uses?! Amazing.
<br>
<br>
I think relation=site would be suited for the postal partner case.
<br>
</blockquote>
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. Maybe because they were never well
documented ? You can however use them in Nominatim, works perfect. I
know we should not tag for rendering but at that time it was a
breaking point not to use relations, also because relations are not
feasible for most beginner mappers.<br>
<blockquote type="cite"
cite="mid:1N9dsV-1lv1kg25rR-015Xdf@mail.gmx.net">
<br>
> Reflecting this back to your proposal you could use the same
<br>
> principals with a minimum of specific service keys in your
cases.
<br>
<br>
I will add this into the proposal so we can start discussion on
it.
<br>
Thanks for pointing out!
<br>
<br>
Georg
<br>
<br>
_______________________________________________
<br>
Tagging mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Tagging@openstreetmap.org">Tagging@openstreetmap.org</a>
<br>
<a class="moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/tagging">https://lists.openstreetmap.org/listinfo/tagging</a>
<br>
</blockquote>
</body>
</html>