[Osmf-talk] App damaging OSM data

Robert Grübler robgruebler at gmail.com
Wed Sep 22 18:51:23 UTC 2021


Am Mi. 22.09.2021 00:24 schrieb Minh Nguyen mxn at 1ec5.org

 

> 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

 

Thank you for the suggestions for a more robust construction of the relation. I very much appreciate the commitment to support.

 

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.

 

> 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.

 

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 ...? 

I understand the delay. But what I would like to see is a transparent prioritisation of the issues, including a short rationale.

 

Are the iD developers unpaid volunteers? Then I take back my wish and just say thanks for their work.

 

Robert

 

 

Von: Minh Nguyen [mailto:mxn at 1ec5.org] 
Gesendet: Mittwoch, 22. September 2021 00:24
An: Robert Grübler <robgruebler at gmail.com>
Betreff: Re: [Osmf-talk] App damaging OSM data

 

Vào lúc 14:30 2021-09-21, Robert Grübler đã viết:

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.

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 less common roles <https://wiki.openstreetmap.org/wiki/Roles_for_recreational_route_relations> . There may be other approaches worth exploring on the tagging mailing list.

 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. 

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.

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.

-- 
Minh Nguyen  <mailto:mxn at 1ec5.org> <mxn at 1ec5.org>
Jabber: mxn at 1ec5.org <mailto:mxn at 1ec5.org> ; Blog: http://notes.1ec5.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/osmf-talk/attachments/20210922/a6983cde/attachment.htm>


More information about the osmf-talk mailing list