<div dir="auto">At the moment the lead iD maintainer contract is vacant. The OSMF Board is close to awarding the contract. Current maintainers are volunteers. I suggest you put in a pull request to fix the bug and be a bit more patient. <div dir="auto">Cheers,</div><div dir="auto">apm</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 22, 2021, 1:54 PM Robert Grübler <<a href="mailto:robgruebler@gmail.com">robgruebler@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="DE-AT" link="blue" vlink="purple"><div class="m_2610815657530404172WordSection1"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Am Mi. 22.09.2021 00:24 schrieb Minh Nguyen <a href="mailto:mxn@1ec5.org" target="_blank" rel="noreferrer">mxn@1ec5.org</a><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">> If the loops represent one-way splits along some portion of the route, <u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">> consider refactoring the route relation into two unidirectional route <u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">> relations that are members of a superrelation. This approach is already <u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">> common for public transportation routes<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Thank you for the suggestions for a more robust construction of the relation. I very much appreciate the commitment to support.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">I still need to think about whether a more robust construction is possible without additional complexity. The "public transportation routes" relations are daunting to me. They may have a more robust data model, but it is far too complicated.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">> Other things have been more straightforward to solve in the meantime, <u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">> especially when volunteers have generously contributed pull requests. <u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">> If the iD project were to impose a moratorium on all changes in favor <u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">> of relation sorting and validation, there would probably be some frustration <u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">> among users and subscribers to this list.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Yes, and it's fine that way. There are currently 728 open issues and one of them is the "splitting way" issue. How many developers and maintainers are there for it? 0, 1, 2 or ...? <u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">I understand the delay. But what I would like to see is a transparent prioritisation of the issues, including a short rationale.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Are the iD developers unpaid volunteers? Then I take back my wish and just say thanks for their work.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Robert<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p><div><div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0cm 0cm 0cm"><p class="MsoNormal"><b><span lang="DE" style="font-size:11.0pt;font-family:"Calibri",sans-serif">Von:</span></b><span lang="DE" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Minh Nguyen [mailto:<a href="mailto:mxn@1ec5.org" target="_blank" rel="noreferrer">mxn@1ec5.org</a>] <br><b>Gesendet:</b> Mittwoch, 22. September 2021 00:24<br><b>An:</b> Robert Grübler <<a href="mailto:robgruebler@gmail.com" target="_blank" rel="noreferrer">robgruebler@gmail.com</a>><br><b>Betreff:</b> Re: [Osmf-talk] App damaging OSM data<u></u><u></u></span></p></div></div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">Vào lúc 14:30 2021-09-21, Robert Grübler đã viết:<u></u><u></u></p></div><blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"><div><p class="MsoNormal"><span lang="EN-US">Some routes are quickly repaired. An automatic sort is all that is needed. I'm not sure if these cases are in the majority. At least a significant proportion need manual effort. Routes with damaged order in loops cannot be sorted automatically (at least JOSM currently cannot). Every one-way creates a loop, so cycle routes without loops tend to be exceptions.</span><u></u><u></u></p></div></blockquote><p>If the loops represent one-way splits along some portion of the route, consider refactoring the route relation into two unidirectional route relations that are members of a superrelation. This approach is already common for public transportation routes and for road routes in some regions but maybe not as common for recreational routes. It’s more work upfront, but after that, editors sort the members more reliably and QA tools can make better sense of the relation too. This may not work as well for recreational routes with <a href="https://wiki.openstreetmap.org/wiki/Roles_for_recreational_route_relations" target="_blank" rel="noreferrer">less common roles</a>. There may be other approaches worth exploring on the tagging mailing list.<u></u><u></u></p><blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"><div><p class="MsoNormal"><span lang="EN-US"> Sometimes I go into the damaged relations and try to understand how it happened. I don't keep statistics on the causes of errors, but my impression is that it is very often the iD-Editor that goes wrong. </span><u></u><u></u></p></div></blockquote><p>As you investigate these cases, please share your insights on the iD issue tracker or another technical venue. As far as I can tell, there isn’t a fundamental opposition to reducing the prevalence of broken relations; like a lot of software development, it’s a matter of understanding the root causes and the tradeoffs to any solutions or workarounds.<u></u><u></u></p><p>Other things have been more straightforward to solve in the meantime, especially when volunteers have generously contributed pull requests. If the iD project were to impose a moratorium on all changes in favor of relation sorting and validation, there would probably be some frustration among users and subscribers to this list.<u></u><u></u></p><pre>-- <u></u><u></u></pre><pre>Minh Nguyen <a href="mailto:mxn@1ec5.org" target="_blank" rel="noreferrer"><mxn@1ec5.org></a><u></u><u></u></pre><pre>Jabber: <a href="mailto:mxn@1ec5.org" target="_blank" rel="noreferrer">mxn@1ec5.org</a>; Blog: <a href="http://notes.1ec5.org/" target="_blank" rel="noreferrer">http://notes.1ec5.org/</a><u></u><u></u></pre></div></div>_______________________________________________<br>
osmf-talk mailing list<br>
<a href="mailto:osmf-talk@openstreetmap.org" target="_blank" rel="noreferrer">osmf-talk@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/osmf-talk" rel="noreferrer noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/osmf-talk</a><br>
</blockquote></div>