Avoiding collateral damages in PTv2 routes

[Weide <osm@…>]

By far the most damages in Public Transport Version 2 Routes are done by mappers using "p" when working in an entirely different context, mostly lanes and speed limits. Some of them dont even know, that relations carrying information in the sequence of members exist and may be invisible. JOSM handles this situation very well if the necessary objects to handle this are already loaded. The advice to the mappers is to use "p" each and every time only after selecting the way and it's end nodes and using Alt-Ctrl-D on them. But it would be enough to load all the PTv2-routes having the way as a member and the neighbour elements of the way in their member list. Is there any way to support this automatically?

A few damages in Public Transport V2 Routes are done using the button "add to relation". As inserting a member into a PTv2 route without giving the position is nearly always wrong, the button should be deactivated if the destination relation contains type=route and public_transport:version=2.

A function to replace an already existing object by another already existing object (especially a node by a way or a relation or a way by a relation) in every parent relation without changing the position or role would avoid many problems. This process is very error prone if done step by step by the mapper. This occurs mainly in the context of detail mapping of platforms.

[skyper]

Especially with public_transport:version=2 it should be no problem to insert the new member at the right position. Do not know if it is worth to code a routine for stop/platform but for route ways it shouldn't be that much work.

[Weide <osm@…>]

It is only needed for route ways.

I think think the code to do the insertion is already in JOSM. Problems occur, if the information needed by the code is not loaded.

[skyper]

Replying to Weide <osm@…>:

It is only needed for route ways.

I was replying also to below, where stop/platform come into play and yes, the order should be from first to last stop which could be recognized as stop is a node of a route way.

Replying to Weide <osm@…>:

A few damages in Public Transport V2 Routes are done using the button "add to relation". As inserting a member into a PTv2 route without giving the position is nearly always wrong, the button should be deactivated if the destination relation contains type=route and public_transport:version=2.

[Weide <osm@…>]

Replying to skyper:

I was replying also to below,...

Ahh, I see. I think, it would be too much work for the result.

[skyper]

Replying to Weide <osm@…>:

A function to replace an already existing object by another already existing object (especially a node by a way or a relation or a way by a relation) in every parent relation without changing the position or role would avoid many problems.

Have a look at ReplaceGeometry from utilsplugin2. It will do the job.

[Weide <osm@…>]

Replying to skyper:

Replying to Weide <osm@…>:

A function to replace an already existing object by another already existing object (especially a node by a way or a relation or a way by a relation) in every parent relation without changing the position or role would avoid many problems.

Have a look at ReplaceGeometry from utilsplugin2. It will do the job.

Yes, I didn't know that one. Thanks.

(Well, I'm missing the "del" delete warning "You are about to delete nodes outside of the area you have downloaded. This can cause problems because other objects (that you do not see) might use them. Do you really want to delete?", but it's a big advantage.)

[skyper]

Replying to Weide <osm@…>:

Replying to skyper:

(Well, I'm missing the "del" delete warning "You are about to delete nodes outside of the area you have downloaded. This can cause problems because other objects (that you do not see) might use them. Do you really want to delete?", but it's a big advantage.)

Please recheck and open an new ticket if it really deletes existing nodes with positive ids outside download area.
Note: It should first replace all nodes with id=0 or negative and as far as I know it should not work outside download area.

[Weide <osm@…>]

Replying to skyper:

Please recheck and open an new ticket if it really deletes existing nodes with positive ids outside download area.
Note: It should first replace all nodes with id=0 or negative and as far as I know it should not work outside download area.

No, it does not delete the node - after the exchange it's id is in one of the nodes of the new object. But it works outside of the downloaded area and if you forget to do CTRL-Alt-D on the node before doing the exchange, the node will be replaced only in the relations which are already loaded. The warning that I am missing should have been "You are about to exchange an object outside of the area you have downloaded. This can cause problems because other objects (that you do not see) might use them. Do you really want to exchange?"

[skyper]

Strange, as far as I remember it did not work outside download area. Did not check what happens if I first move the object inside the area but this is probably always a problem.

Please, open a new ticket, with a step by step description. - Thanks

[Weide <osm@…>]

Replying to skyper:

Please, open a new ticket, with a step by step description. - Thanks

That should be an enhancement request, right?

[skyper]

Replying to Weide <osm@…>:

Replying to skyper:

Please, open a new ticket, with a step by step description. - Thanks

That should be an enhancement request, right?

Still think this is a regression (e.g. defect) but have to check it. Maybe, try some older tested-versions.
Though it does not really matter, as long as we get a proper bug report with status report we are usually happy and changing type later is no problem.