[Osmf-talk] App damaging OSM data

Simon Poole simon at poole.ch
Tue Sep 21 00:49:08 UTC 2021


Am 21.09.2021 um 01:30 schrieb Brian M. Sperlongano:
>
>
> On Mon, Sep 20, 2021 at 6:57 PM Simon Poole <simon at poole.ch 
> <mailto:simon at poole.ch>> wrote:
>
>
>     Am 20.09.2021 um 21:50 schrieb Brian M. Sperlongano:
>>     This is also an issue with boundaries, ticket #8286:
>>     https://github.com/openstreetmap/iD/issues/8286
>>     <https://github.com/openstreetmap/iD/issues/8286>
>
>     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.
>
> 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.
>
> The specific problem I'm calling out in that ticket is that iD is 
> causing either gaps in boundaries or members with missing roles.
>
> For example, in Lewiston, Texas, USA:
> This changeset: 
> https://www.openstreetmap.org/changeset/108334888#map=16/32.9935/-96.9922 
> <https://www.openstreetmap.org/changeset/108334888#map=16/32.9935/-96.9922>
> Caused this gap: 
> https://www.openstreetmap.org/relation/253769#map=16/32.9928/-96.9907 
> <https://www.openstreetmap.org/relation/253769#map=16/32.9928/-96.9907>

The user in question deleted one already split way there and I suspect 
the end of the other part of the boundary that he did actually split in 
the changeset. See https://overpass-api.de/achavi/?changeset=108334888 
IMHO likely not related to iD mishandling splitting.

>
> Here's another example:
> https://www.openstreetmap.org/relation/170585 
> <https://www.openstreetmap.org/relation/170585>
> If you expand the member list, or better look at the XML 
> (https://www.openstreetmap.org/api/0.6/relation/170585 
> <https://www.openstreetmap.org/api/0.6/relation/170585>), you'll see 
> two members that have blank roles.
>
Again I don't see any evidence of this being down to way splitting, it 
could very well be that both ways were added manually to the border..

Simon

> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/osmf-talk/attachments/20210921/cccd662f/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstreetmap.org/pipermail/osmf-talk/attachments/20210921/cccd662f/attachment.sig>


More information about the osmf-talk mailing list