<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <br>
    Le 20/10/2022 à 10:27, Martin Koppenhoefer - <a class="moz-txt-link-abbreviated" href="mailto:dieterdreist@gmail.com">dieterdreist@gmail.com</a>
    a écrit :<br>
    >> 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"<br>
    > 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.<br>
    <p>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!</p>
    <p>And rather use presets (explicitly or implicitly).<br>
    </p>
    <p>Yes there is a risk as mentioned by Frederik that it tends to
      focus on a US-centric point of view.<br>
      <br>
    </p>
    Le 20/10/2022 à 01:53, Craig Allan - <a class="moz-txt-link-abbreviated" href="mailto:allan@iafrica.com">allan@iafrica.com</a> a écrit :<br>
    > 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"<br>
    <p>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.</p>
    <p><br>
    </p>
    Le 20/10/2022 à 10:27, Martin Koppenhoefer - <a class="moz-txt-link-abbreviated" href="mailto:dieterdreist@gmail.com">dieterdreist@gmail.com</a>
    a écrit :<br>
    > A similar question: can you assume from a shop=butcher that
    you’ll get a warm meal at lunchtime?<br>
    Surely not. And the wiki says "A butcher sells meats that are
    "cold", prepared or unprepared, in contrast to a <a
      href="https://wiki.openstreetmap.org/wiki/Restaurant"
      class="mw-redirect" title="Restaurant">restaurant</a> or a <a
      href="https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dfast_food"
      title="Tag:amenity=fast food">fast food restaurant</a> that sells
    "hot" foo". <br>
    <br>
    <br>
    Le 20/10/2022 à 10:59, Shawn K. Quinn - <a class="moz-txt-link-abbreviated" href="mailto:skquinn@rushpost.com">skquinn@rushpost.com</a> a écrit
    :<br>
    > 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.)<br>
    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 <a
      href="https://wiki.openstreetmap.org/wiki/Semi-colon_value_separator"
      title="Semi-colon value separator">semicolon</a> as separator
    (without space)."
    <p><br>
      Le 20/10/2022 à 03:40, Keitaroh Kobayashi - <a class="moz-txt-link-abbreviated" href="mailto:keita@kbys.me">keita@kbys.me</a> a écrit
      :<br>
      > 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<br>
    </p>
    <p>Thanks, for the feedback.</p>
    <p>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.<br>
    </p>
    <p>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.</p>
    <p>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). ;-(</p>
    <p>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.<br>
      Yes not an OSM tag issue but a very similar issue.</p>
    <p><br>
      Le 20/10/2022 à 18:10, Zeke Farwell - <a class="moz-txt-link-abbreviated" href="mailto:ezekielf@gmail.com">ezekielf@gmail.com</a> a écrit :<br>
      > There seems to be a feeling among many that open tagging and
      standardisation are fundamentally incompatible.  I do not see it
      this way.</p>
    <p>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).<br>
    </p>
    <p>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.<br>
    </p>
    <p>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.</p>
    <p>So even with strong norms, you can't fix everything: a stable
      norm is a dead/unused norm. And S-101 followed S-57.</p>
    <p>What they did is that evolutions of S-101 should be easier than
      those of S-57.</p>
    <p>That pretty similar to OSM : try to stick to standards and if you
      change them, you need transition paths.</p>
    <p>Not making a public transport version 2 without thinking about
      the migration of the good old data set was a bad idea.<br>
    </p>
    <p>Note: I may not be neutral as working in a company working on
      nautical charts (and products around them).</p>
    <p>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.<br>
    </p>
    <p>Jean-Yvon<br>
    </p>
  </body>
</html>