Re: [OSM-talk] Multi Polygon problem - could someone take a look?
Hi, On 04/01/2017 12:36 AM, Dave F wrote: > But how did the edit affect *all* nodes? Why didn't a changeset revert > solve the issue? is this 'osmtools' publicly available or is it a > self-written tool? Ortholgonalizing a shape will usually move all its nodes so no surprise there. Reverting the *correct* changeset (that contained the node edits) would have solved the issue but probably also reverted good edits made by the mapper. The scripts I used are on github (woodpeck/osm-revert-scripts) however they require some Perl/Unix foo to use correctly (or else you run the danger of creating more damage). In this case what I did was * create new changeset (using changeset.pl) * download the polygon (using wget) * extract from it a list of nodes it's using (using "grep" and "cut" unix utilitiess) * revert every node to whatever state it was in before touched by the user ndm (using a "for" loop and undo.pl) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Multi Polygon problem - could someone take a look?
Hi >Hence while the shape my have been drastically altered, the polygon way is still the "same" it has been since you touched it 2 weeks ago. You can see that in the history of the individual nodes. >Potlatch uses a slightly different data model where a way's nodes are integrated with the way, hence Potlatch "sees" a changed way. I'm struggling to see how this isn't a fundamentally incorrect way for OSM/JOSM etc to interpret the data. If nodes are moved then ways are amended & should be listed as such to avoid confusion & "reverting good edits made by the mapper". Hi, Reverting the *correct* changeset (that contained the node edits) would have solved the issue Unfortunately not. In JOSM I tried two operations: I downloaded all the data in the https://www.openstreetmap.org/changeset/47243857 into JOSM Also a boundary box of the area. In each case I attempted to revert just the affected polygon with the revert plugin. Neither case worked. In P1 I selected the polygon & a similar attempted revert of the way failed. but probably also reverted good edits made by the mapper. The scripts I used are on github (woodpeck/osm-revert-scripts) however they require some Perl/Unix foo to use correctly (or else you run the danger of creating more damage). In this case what I did was * create new changeset (using changeset.pl) * download the polygon (using wget) * extract from it a list of nodes it's using (using "grep" and "cut" unix utilitiess) * revert every node to whatever state it was in before touched by the user ndm (using a "for" loop and undo.pl) This long-winded procedure + the failed reverts clearly indicates an improvement in data storage/interpretation is required: Ways with moved nodes need to be tagged as being amended. DaveF. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Multi Polygon problem - could someone take a look?
sent from a phone > On 1 Apr 2017, at 23:22, Dave F wrote: > > I'm struggling to see how this isn't a fundamentally incorrect way for > OSM/JOSM etc to interpret the data. If nodes are moved then ways are amended > & should be listed as such to avoid confusion & "reverting good edits made by > the mapper". Every object (node, way, relation) has its own version count. This makes sense, so that only changes to this object create new versions. If you move nodes, they will change their version. Only nodes have coordinates. Nodes and relations don't, their exact geometry depends on the node coordinates of their members. As such it is perfectly correct how osm and josm are handling this: same members and order and same tags: no new version. But I agree it would seem convenient to show the effects of those node movements on ways and relations in some way by looking at the node positions (i.e. the actual geometry), e.g. as an additional option. cheers, Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
