JOSM default orthogonalization logic is too agressive

[openstreetmap.org-user-d1g]

It collapses 45 and 60 angles to 90 - this is not what most users want or ask. Probably, better logic was implemented in iD.

Alternative implementations:

• ortho2 by OverQuantum accounts this ​https://github.com/OverQuantum/JOSM-CommandLine-commands/commit/8c81c3ce053cacccfa4dd06473ea69c6fad9d4ce
• ​https://github.com/OverQuantum/path_ortho

[openstreetmap.org-user-d1g]

Alternative to this is to include more complex plugin in core: ​https://wiki.openstreetmap.org/wiki/JOSM/Plugins/Building_Generalization

"Third example - if we don't have roads, the angles of the buildings are still edited"

All other cases may be deactivated in core by default, but we need a good Q (orthonization) tool in core.

[bastiK]

There is a parameter to limit the angle change. However, it has been set to "unbounded" on purpose: The user can always undo the action if unsatisfied with the result. On the other hand, if we limit the angle change and the user actually wants to change 60 degrees to 90 degrees, this becomes an unwanted restriction.

Keeping this in mind, please collect examples where other implementations give a better result (before & after screenshot + .osm file).

Regarding the alternative implementations:

• OverQuantum: At first glance, the algorithm looks fairly similar to the one in JOSM core.
• iD/Potlatch 2 code is certainly interesting: It moves each corner, so it becomes a right angle relative to the two neighbor points. This is repeated for all corner nodes, over and over, until all angles are sufficiently square.
• Building_Generalization plugin: This is a student project, which was abandoned soon after. Besides missing license information, I cannot find any general purpose orthogonalization code in the sources.

[openstreetmap.org-user-d1g]

Current JOSM Q tool has very limited use IMO, simply open any decently mapped city (Moscow, Paris) to see that most buildings are very far from perfect rectangles with 90 and 180 angles:

​http://www.openstreetmap.org/way/68566394/history
​http://www.openstreetmap.org/way/32903273/history
​http://www.openstreetmap.org/way/31497219/history
​http://www.openstreetmap.org/way/266220292/history#map=19/37.75004/-122.43241 - this area may look like they are rectangular, but in fact they have many low level curves or faces, ex 266220292 way.

Also, you can draw 90 degree geometries, not with single tool (extrude tool) but also with smaller building_tools. building_tools goes further and makes alignment by 2 points of Q unnecessary.

the user actually wants to change 60 degrees to 90 degrees

I would say this is very infrequent case. In most cases you want to snap one (or all) angles to 5, 10, 15, 20, 85, 90, 95, ..., 175, 180 degrees. Similar to angle snapping, but after you drawn something - having this variant in JOSM would be more useful.

We don't need "right" angles (objects in the real world are not like this), we need more "rounded to the closest nice number" tool.

[bastiK]

Okay, I understand your request now:

(1) It should be possible to rectify some corners of a building, but don't touch corners that aren't sufficiently close to a target angle (typically 90 or 180 degrees).
(1a) (my idea) you can select way nodes and it would rectify only the selected corners and leave unselected nodes alone
(2) It should be possible to "snap to" angles other than 90 and 180 degrees (e.g. 45, 60 degrees).

I agree, that at least (1) would be very handy. The current implementation cannot be extended in this direction, a complete rewrite is needed for that.

[openstreetmap.org-user-d1g]

Replying to bastiK:

(1) It should be possible to rectify some corners of a building, but don't touch corners that aren't sufficiently close to a target angle (typically 90 or 180 degrees).

I agree, that at least (1) would be very handy.

This tool could replace "Align in circle" (easy when node count is even, special case for odd node count), "Align in line" tools and partially "Draw an arc", leaving more keys free.

The current implementation cannot be extended in this direction, a complete rewrite is needed for that.

Is part 2 simpler to implement? List of values would be sufficient, I think many users would use it without changing list of angles.

[openstreetmap.org-user-d1g]

Closed as duplicate of #7651.