[Osmf-talk] App damaging OSM data

Brian M. Sperlongano zelonewolf at gmail.com
Mon Sep 20 23:30:37 UTC 2021


On Mon, Sep 20, 2021 at 6:57 PM Simon Poole <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
>
> 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
Caused this gap:
https://www.openstreetmap.org/relation/253769#map=16/32.9928/-96.9907

Here's another example:
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), you'll see two
members that have blank roles.

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/20210920/6d086253/attachment.htm>


More information about the osmf-talk mailing list