"select all inside" could delete the selection way by itself...

[cquest]

It would be very useful to have "select all inside" deleting the way use to do the selection when this way is new (id=0) and has no tag at all nor is a member of any relation (some kind of new orphan way). It it is possible to detect that it was the last way created, it's even better.

This allows to draw a way temporarily just to select objets, but have the way removed immediately after selection is done.

[verdy_p]

We should not even need to create a pseudo object just to make a selection. If the purpose of a selection is to reduce the size of the generated changeset, JOSM should have a default configuration forcing changeset to not exceed a maximum count of objects.

Note that JOSM allows a changeset to remain open after a submission. This means that JOSM will need to track the number of objects that are already part of an open changeset. Ideally, it should query the server to know how many objects are already in that changeset.

If the changeset reached the maximum number of objects, the changeset should be closed and a new changeset (with the same comment, it will remain generally OK) should be created and opened.

Ideally, for large numbers of objects, the division of the list of objects to send should preferably be within separate bounding boxes that should be as complete as possible: ideally you count the number of objects to send, and if it exceeds some level,

• you compute its bounding box (objects without bounding boxes such as relations without geometry by themselves, containing no ways and no nodes but only other relation members, could be treated separately in final changesets)
• if there's an open changeset, query the server to know how many objects are in it, otherwise create a new changeset with the current changeset comment.
• you subdivide sucessively that bounding box it in two almost equal parts (on the largest longitude ou latitude dimension) and recompute a subselection in the first part, up to the point where the max number of is not reach
• then you can complete that changeset by adding relations without geometries, that are referencing ONLY either
  • modified objects that will be part of the current changeset and NO other modified objects outside of it
  • possibly other unmodified objects
• then you can complete that changeset by adding relations without geometries that are referencing ONLY
  • ONLY unmodified objects
• You then send that changeset and mark these objects in their new state with their version and unmodified state.
• You close the changeset

This done it remains a smaller list of modified objects, and you loop around this process if there remains objects (you may add a minimum delay, e.g. 1 minute, between changesets at this step).

This loop will create changesets with reasonnable sizes that will almost not overlap and will be easier to manage and revert in case of too many edit conflicts that are too difficult to resolve. And it will minimize the impact on tile renderers, allowing each subzone to be almost completed in one pass without having to regenerate the same tiles, when people will look at the content of a recently closed changeset.

[cquest]

My proposal has nothing to do with changesets.

[Don-vip]

The problem is that this functionality has been created with the idea of selecting inside an existing polygon, so I'm not really at ease to silently delete something with a "select" action. Isn't the lasso mode enough for your purpose ? I would prefer improve the lasso mode if it does not completely satisfy your needs rather than implement this behaviour.

[Don-vip]

By the way, ticket #3910 is still open for further discussions on the lasso mode.

[Don-vip]

Sorry Christian, I don't think we'll do this one :)