<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 8/01/2016 9:56 AM, Colin Smale
      wrote:<br>
    </div>
    <blockquote
      cite="mid:23A0EB40-4CA1-4C60-A75A-FF3079DDCC8F@xs4all.nl"
      type="cite">Nobody will be using the raw data to fly a plane. It
      doesn't matter if we use the ele tag for the top or the bottom -
      as long as the height is given, the other value can easily be
      derived. What is important is consistency, both in its definition
      and it's usage. Defining it as sometimes the top and sometimes the
      bottom of a feature doesn't help.<br>
    </blockquote>
    <br>
    And consistent with other mapping products/practices?  <br>
    <br>
    By convention maps uses blue to indicate sea, rivers and streams. <br>
    The idea is to be readily usable by using the same practice as
    others have used in the past.<br>
     Not to set some new standard where there is no reason for it. <br>
    <br>
    Grasping at straws .. the elevation of a mountain is given as its
    peak. If there is consistency within the map then the elevation of
    all objects should be their maximum height. <br>
    <br>
    <blockquote
      cite="mid:23A0EB40-4CA1-4C60-A75A-FF3079DDCC8F@xs4all.nl"
      type="cite">
      We will also need to standardize on a datum for elevations. The
      wiki refers to both mean sea level (which varies by country) and
      wgs84. The differences might be enough to take the wheels off your
      plane..<br>
    </blockquote>
    <br>
    Good point there! <span class="moz-smiley-s1"><span> :-)     </span></span><br>
    For most it won't matter. What do international planes use as there
    reference for height? Use that - again consistency. <br>
    <br>
    By maintaining some consistency with what has been done elsewhere it
    will make it easier to compare, check and confirm OSM data. <br>
    <blockquote
      cite="mid:23A0EB40-4CA1-4C60-A75A-FF3079DDCC8F@xs4all.nl"
      type="cite">
      <br>
      <br>
      <div class="gmail_quote">On 7 January 2016 22:50:02 CET, Warin
        <a class="moz-txt-link-rfc2396E" href="mailto:61sundowner@gmail.com"><61sundowner@gmail.com></a> wrote:
        <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
          0.8ex; border-left: 1px solid rgb(204, 204, 204);
          padding-left: 1ex;">
          <pre class="k9mail">On 8/01/2016 3:32 AM, Christoph Hormann wrote:
<blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> On Thursday 07 January 2016, Aaron Spaulding wrote:
<blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"> Hi all,

 I’ve been working on generating 3D meshes based on OSM data and I ran
 into a problem. Vertical features like 'natural=cliff',
 'barrier=retaining_wall’ and 'waterway=waterfall' occupy two points
 in physical space, but because of the 2D nature of OSM its ambiguous
 which side of the feature that the ‘ele’ tag applies.
</blockquote> For cliffs mapping conventions say that you should put the line on top
 of the cliff in case it is not exactly vertical - accordingly the ele
 tag would also refer to the top  - but keep in mind that the elevation
 does not
have to be constant.</blockquote>

Consider who is going to use the map, and for what purpose.

The most critical use is for aeroplanes .. where the maximum height is 
critical information!
I think for that reason alone most maps should indicate the maximum 
elevation of an object.

<hr>
Tagging mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Tagging@openstreetmap.org">Tagging@openstreetmap.org</a>
<a moz-do-not-send="true" href="https://lists.openstreetmap.org/listinfo/tagging">https://lists.openstreetmap.org/listinfo/tagging</a>
</pre></blockquote></div>


</blockquote>
</body></html>