Talk:Remapping

JOSM: Replacing Nodes which are part of ways

The current description to replace nodes which are part of ways seems to be somewhat complicated. How about using utilsplugin2's function 'Extract node' instead?

-- mmd 12:51, 20 December 2011 (UTC)

Pictures of JOSM and Potlatch

It would be really helpful, if someone could place a picture of JOSM and Potlatch how "Dark red", "Transparent red" and "Orange" should look like. If one did not find each of them in order to compare, one is not really sure. In example I found only "yellow" nodes and ways in JOSM. -- Tirkon 09:39, 26 November 2011 (UTC)

There's a sreenshot at the bottom of this page: JOSM/Plugins/LicenseChange. Does that show it? We could include that image on this page, but... see next comment -- Harry Wood 22:20, 15 December 2011 (UTC)

Content re-arranging

I think this page goes into too much detail about Potlatch and JOSM. In the case of JOSM the details would better me merged onto JOSM/Plugins/LicenseChange I think. In the case of Potlatch a new subpage of the Polatch perhaps. Of course we can keep one paragraph summaries on this page too. That re-arrangement would make more space for...

...generalised summaries and lists of other tools. There's a page Help preparing for the license change which is another sort of general overview with slightly different content. It's not very well linked. I suggest we merge, i.e. migrate the useful bits of that onto this page.

-- Harry Wood 22:20, 15 December 2011 (UTC)

I've moved the tools section from the "Help preparing for the license change" page to here. That page is now just a more wordy description - Harry Wood 16:09, 6 January 2012 (UTC)

Is Potlatch adequate for remapping?

Correct me, if I am wrong. As far as I now, Potlatch is made for beginners. Therefore it is not able to show everything, that is needed for remapping - in example the order of objects within relations. Also it does not show if a relation is member of parent-relations. Every node and every way in OSM could be a member of a sorted relation and as well be the member of a relation, which is member of a parent relation. The potlatch user is not able to see that. Replacing would end in destroying these (parent) relations during remapping without the editing person being able to take notice of that. Thus Potlatch is not adequate for remapping. And I am not aware, whether Potlatch hides further details that are important for remapping. Sorry, but for that reason I would warn in this article using Potlatch for remapping and would not give any guidance how to use it. Potlatch should only be used for viewing. In my opinion alone JOSM is adequate and should be recommended for this job. As already said: Correct me, if I am wrong. -- Tirkon 10:02, 26 November 2011 (UTC)

Well for starters, the problems you describe will only effect data which is member of relations which are members of relations. I would hope that not too much of our data is tangleup in relations in that manner, but sadly some people do go over the top with these things.

Potlatch lets you see relations quite clearly, so users can avoid them if necessary, but I'm not sure if there are bugs/problems when users go ahead and edit such objects. Can you link to a very specific example of somebody breaking the data, or to a trac bug describing the problem?

-- Harry Wood 22:14, 15 December 2011 (UTC)

Richard made clear, that this is implemented in Potlatch in the meantime. As far as I could figure out a left problem is that Potlatch does not warn users, who delete a way which is member of a relation. As far as I know there is no other way than relations in order to describe i.e. boundaries, routes, turn restrictions and public transport. Thus relations have become quite normal without going over the top. I.e. nearly every referenced road is passed by buses - in rurely regions as well. Turn restrictions are quite common, too. They are essential for automatic routing. The problem is that every way and node could be a potential member of a relation - even then if there are only a few. But as already said: They have become quite common. Thus it would be helpful, if we had appropriate tools that allows i.e. to "paint" these directly into the map. Possibly it would be helpful to have coders in OSM who come from other free graphic design projects. -- Tirkon 14:42, 1 January 2012 (UTC)

anonymous contributions

It would be helpful, if someone could explain, what "anonymous contributions" are. -- Tirkon 10:16, 26 November 2011 (UTC)

Well I made it a link to anonymous edits page which is the concept being referred to I believe. It's a old option which is no longer available (read that page). As far as I know, this effects a tiny minority of data, but is a technical challenge to handle correctly -- Harry Wood 22:10, 15 December 2011 (UTC)

From what I've seen the anonymous edits are still linked to a particular user, its just that you can't see which user it is (see the page above for more info). The anonymous users can agree to the new licence and you can see a list of which changesets where made made users who have accepted the changes here: planet.osm.org --MarkS 18:45, 8 January 2012 (UTC)

Remapping based on existing CC-BY-SA data in OSM

I've recently made a note in this article (you can find it underlined here) describing both why remapping existing CC-BY-SA data is bad, but also noting that the same article includes explicit instructions how to literaly copy some data (relations) under new name, delete original, and rename the copy back to original name. So exactly the same data, even without any effort to cover the trails, is copied. Only difference would be timestamps and author. This shall not be done. Why is such instruction in this article at all?

Similarly, at least one translation of this article literaly describes copy-paste-delete technique for ways.

It is very important to note that following can happen, what would be very bad for OSM and for enthusiasm of all the contributors:

• a contributor does described copy-scheme, claiming that it was done in good faith, that instructions are telling so, etc
• OSM Foundation then decides to drop CC-BY-SA and swich to ODbL based on claim that all data of that moment is done under new Contributor terms, and that contributors know that they are doing, and that no mistakes, or ill-intended sumbitions are noticed

Result is that original CC-BY-SA data is trough above two-step-scheme wrongfully claimed under ODbL. And both participants (contributor and OSMF) claim that whatever happened, their part of action is fully honest and legal. However, original author did not allow this, so breach is done, someone is at fault, and if original author pursuits this further case, that would be bad for both OSMF and for contributor community. If more than one similar case is found, it would be very difficult to claim that all this is only unfortunate coincidence, and not planned data laundry.

Please take care that this and related articles do not convey wrong instructions.

User:DarkoS Revision as of 19:59, 19 January 2012

Advice on reverting

I wonder if it would be possible to include some advice on reverting changes by non-acceptors.

Given a way where the majority of edits have been done by CT-acceptors, and there are a small number of edits by CT-decliners. Assuming it is desirable to keep this way, will the edits by the CT-decliners simply be reverted automatically?

Is there benefit in manually reverting edits by CT-decliners? If edits by CT-decliners are reverted (assuming v1 was created by a CT-acceptor) will the way be preserved?

Again, assuming the situation that reverting edits by non-acceptors is preferable to re-mapping the way, perhaps this page could include advice on how to go about doing this. (Even if only a link to the Revert page.)

--Ebenezer 00:45, 9 February 2012 (UTC)

Disappointed in lost mapping data

I am very disappointed in the fact I spent alot of time manually creating the nodes and ways from the beginning, including naming them, to now find all the names are removed due to this new license and the redaction bot. I have also noticed this seems to be a common issue: http://blog.osmfoundation.org/2012/07/09/licence-redaction-ready/ This is an example of my effort wasted: http://osm.org/go/uN9885UA

Is anything being done to fix this?

Except remapping data (i.e. mapping it again), there isn't much that can be done to fix it, unfortunately. If data was deleted during the license change, then it means that at least one person has contributed to the area who has not given OSM permission to continue using their contributions under the new legal terms. I agree that this it is particularly painful where it affects contributions by people who have accepted the new license, such as in your case. --Tordanik 19:08, 7 December 2012 (UTC)