[Osmf-talk] Tagging standards

[osm.sanspourriel at spamgourmet.com]

Le 20/10/2022 à 10:27, Martin Koppenhoefer - dieterdreist at gmail.com a
écrit :
 >> To avoid the same tag identifying different features we need to
collectively set just one rule. "No two different mapped features may be
identified by the same tag"
 > this is assuming we all know what a feature is and how it is
defined/which are its core properties that must not miss. This is not so
often the case on a global level.

One basic requirement is to look if similar features exist and how
they're mapped. We don't need to know the whole approved tag set for
that, do we? Normally, standard users don't use the raw API to describe
new objects!

And rather use presets (explicitly or implicitly).

Yes there is a risk as mentioned by Frederik that it tends to focus on a
US-centric point of view.

Le 20/10/2022 à 01:53, Craig Allan - allan at iafrica.com a écrit :
 > to avoid the same tag identifying different features we need to
collectively set just one rule. "No two different mapped features may be
identified by the same tag"

Nope, well more precisely: "No two different mapped features may be
identified by the same tag set". I don't care if oneway=yes is used on a
highway or a waterway for instance. If noname=yes was used on highway=
but hasname=no on waterway=, you would make it just harder.


Le 20/10/2022 à 10:27, Martin Koppenhoefer - dieterdreist at gmail.com a
écrit :
 > A similar question: can you assume from a shop=butcher that you’ll
get a warm meal at lunchtime?
Surely not. And the wiki says "A butcher sells meats that are "cold",
prepared or unprepared, in contrast to a restaurant
<https://wiki.openstreetmap.org/wiki/Restaurant> or a fast food
restaurant <https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dfast_food>
that sells "hot" foo".


Le 20/10/2022 à 10:59, Shawn K. Quinn - skquinn at rushpost.com a écrit :
 > You want to talk about jamming square pegs into round holes, look at
how we have to enter co-branded KFC/Taco Bell or Dunkin'/Baskin-Robbins
locations. (To do it "right" it's two separate nodes even though they
are the same location under the same roof.)
No need to create fictive nodes, brand=KFC;Taco Bell is the solution,
here again look at the wiki: "In case of several brands use a semicolon
<https://wiki.openstreetmap.org/wiki/Semi-colon_value_separator> as
separator (without space)."


Le 20/10/2022 à 03:40, Keitaroh Kobayashi - keita at kbys.me a écrit :
 > By the way, I checked with some people in the OSM Japan community,
and it looks like they currently encourage using relations for
representing prefectural or national road status

Thanks, for the feedback.

It's a nice solution: 100% compatible by the tagging standard and made
by the community aware or made aware of the issue. Progresses made in
good faith.

Next step is to write it done on the wiki so that the average Japanese
maps it the now agreed way and that some rendering engines render those
road the traditional way.

About cafe/bar/pub: in an Irish pub I ordered a coffee. Looking at the
eyes looking at me I saw I made a mistake. So in theory you can buy a
coffee in an Irish pub. Don't expect anything or you would be
disappointed ;-). Don't try to avoid cultural difference. Because
English was lacking a word to make the difference between pétoncles and
coquilles saint-jacques, now In France any Pecten instead of just Pecten
Maximus can be sold as coquilles saint-jacques (expect as fresh food). ;-(

Normally it should have been done the opposite way (use pétoncles
whatever the Pecten, and possibly use the taxon Maximus for coquilles
saint-jacques.
Yes not an OSM tag issue but a very similar issue.


Le 20/10/2022 à 18:10, Zeke Farwell - ezekielf at gmail.com a écrit :
 > There seems to be a feeling among many that open tagging and
standardisation are fundamentally incompatible.  I do not see it this way.

In some very specific parts of OSM we do have standards based on norms:
the open sea map tagging schema is based on the S-100 series (mostly S-101).

Even with strong norms, you can't avoid that depending on the IALA
region, buoys that have the SAME meaning have DIFFERENT meaning: port
side marks in IALA A regions are red, but port side marks in IALA B
regions are green,so we need to know in which part of the world we are
to interpret correctly the beacon. Ugly isn't it? Probably they should
have chosen 2 new colours for the conflicting red/green conventions. But
they haven't. At least they are aware of that and if a mariner clicks on
a buoy, the system knowing the position of the buoy tell the mariner how
to interpret what he/she sees.

But as some new features arrive, they have created a kind of
node/line/area NEW OBJECT where you specify how to draw it on the map.

So even with strong norms, you can't fix everything: a stable norm is a
dead/unused norm. And S-101 followed S-57.

What they did is that evolutions of S-101 should be easier than those of
S-57.

That pretty similar to OSM : try to stick to standards and if you change
them, you need transition paths.

Not making a public transport version 2 without thinking about the
migration of the good old data set was a bad idea.

Note: I may not be neutral as working in a company working on nautical
charts (and products around them).

And Martin is right: standardisation (with an s as the language for OSM
is British English, not American English) of tags is quite similar to
standardisation of a language.

Jean-Yvon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/osmf-talk/attachments/20221020/ec8f504f/attachment.htm>