<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 20, 2021 at 6:57 PM Simon Poole <<a href="mailto:simon@poole.ch">simon@poole.ch</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div>
    <p><br>
    </p>
    <div>Am 20.09.2021 um 21:50 schrieb Brian M.
      Sperlongano:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">This is also an issue with boundaries, ticket
        #8286:
        <div><a href="https://github.com/openstreetmap/iD/issues/8286" target="_blank">https://github.com/openstreetmap/iD/issues/8286</a><br>
        </div>
      </div>
    </blockquote>
    <p>While it is clearly good practice to try and maintain order when
      splitting a way that is a member of a boundary or multi-polygon,
      not doing so doesn't break the object at hand in any meaningful
      way. Any processing of a boundary or multi-polygon on the other
      hand that relies on the members being correctly ordered is
      actually broken.</p></div></blockquote><div>There is no issue with member order and I'm not sure why you're bringing it up in the context of the issue I linked.</div><div><br></div><div>The specific problem I'm calling out in that ticket is that iD is causing either gaps in boundaries or members with missing roles.</div><div><br></div><div>For example, in Lewiston, Texas, USA:</div><div>This changeset: <a href="https://www.openstreetmap.org/changeset/108334888#map=16/32.9935/-96.9922">https://www.openstreetmap.org/changeset/108334888#map=16/32.9935/-96.9922</a></div><div>Caused this gap: <a href="https://www.openstreetmap.org/relation/253769#map=16/32.9928/-96.9907">https://www.openstreetmap.org/relation/253769#map=16/32.9928/-96.9907</a></div><div><br></div><div>Here's another example:</div><div><a href="https://www.openstreetmap.org/relation/170585">https://www.openstreetmap.org/relation/170585</a></div><div>If you expand the member list, or better look at the XML (<a href="https://www.openstreetmap.org/api/0.6/relation/170585">https://www.openstreetmap.org/api/0.6/relation/170585</a>), you'll see two members that have blank roles.<br></div><div><br></div><div>Now, it's possible to infer inner/outer roles algorithmically if nothing else is broken, but it seems like this ought to be a standard QA check rather than passed downstream to data consumers.</div><div><br></div></div></div>