<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>Just a general remark on the technical issue that sparked of this
      discussion:  squaring buildings is not primarily about improving
      data quality. Non-square buildings are simply visually annoying
      when rendered, so much that I support squaring them "as a rule"
      too when it can reasonably be assumed that there are 90° angles in
      the actual building outline. But I'm not kidding myself that it
      improves "quality". If we wanted to define quality of building
      outlines in OSM we would probably be talking about deviations from
      the buildings footprint area, average deviations from the outline
      and so on, any of these could be very small even without squaring.
      Actually, squaring might impact them negatively, particularly when
      the outline is rough, but as said: square buildings are just so
      much easier on the eyes :-).</p>
    <p>Simon<br>
    </p>
    <div class="moz-cite-prefix">Am 10.05.2019 um 21:05 schrieb Pierre
      Béland via talk:<br>
    </div>
    <blockquote type="cite"
      cite="mid:1287619183.11871342.1557515105826@mail.yahoo.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div class="ydp1d108a83yahoo-style-wrap" style="font-family:
        verdana, helvetica, sans-serif; font-size: 13px;">
        <div>
          <div>
            <div>May 20 2019 at 14 h 02 min 51 s UTC−4, Stefan Keller
              <a class="moz-txt-link-rfc2396E" href="mailto:sfkeller@gmail.com"><sfkeller@gmail.com></a> wrote :
              <div><br>
              </div>
              > Trying to get focus back on the thread topic.<br
                clear="none">
              <br clear="none">
              > Storing hints like nosquare=yes (or square=no) is not
              best practice of<br clear="none">
              > data curation on w worldwide level.</div>
            <div><br>
            </div>
            <div>I dont think either that this is the solution.  We have
              to look where these problems come and try to correct from
              the source.  Adding  such tag will not help software tools
              to identify where we have problems and can create some
              missunderstanding about its meaning. And experienced
              mappers are more and more reluctant to correct inprecise
              building mapping.<br>
            </div>
            <div><br>
            </div>
            <div>For Newbies, Building Quality Analysis last year this
              show some Tasking Manager projects with some 60% of
              unsquarred buldings (see <a
href="https://opendatalabrdc.github.io/Blog/#!Database_Quality_Analysis_Tasking_Manager.md"
                rel="nofollow" target="_blank" class=""
                moz-do-not-send="true">https://opendatalabrdc.github.io/Blog/#!Database_Quality_Analysis_Tasking_Manager.md</a>).
              <br>
            </div>
            <div>The same problem for the DR Congo Ebola response in
              november where we had to restart mapping Butembo in an
              emergency response and restrict mapping to experienced
              mappers.<br>
            </div>
          </div>
          <div><br>
          </div>
          <div>For an editor like iD, it can participate with other
            solutions like better training to assure that Newbies
            understand what Building tracing really mean and give then
            some feedback, like for example saying before save "You have
            10 over 12 buildings that are unsquarred.  If you dont know
            how to make rectangular buildings, you should ask for help
            before you continue.  Do you want to send data anyway ?"<br>
          </div>
          <div><br>
          </div>
          <div>We have the same problem with some Building import
            projects and I think that this needs to be fixed where it
            originates, before it goes in the database.  For newbies,
            this mean more training and monitoring in particular in the
            context of Mapathons.</div>
          <div><br>
          </div>
          <div>For Imports, this mean to analyze carefully and correct
            the data before the Import.<br>
          </div>
          <div class="ydp1d108a83signature"><span
              style="font-style:italic;color:rgb(0, 0,
              191);font-weight:bold;"> <br>
              <font face="garamond, new york, times, serif">Pierre </font><br>
            </span></div>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
talk mailing list
<a class="moz-txt-link-abbreviated" href="mailto:talk@openstreetmap.org">talk@openstreetmap.org</a>
<a class="moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/talk">https://lists.openstreetmap.org/listinfo/talk</a>
</pre>
    </blockquote>
  </body>
</html>