these cases are not covered by the splitting algorithm at the moment:
* typicall, only a part of the roundabout should be part of the resulting route
* when multiple routes meet at a roundabout coming from different angles, the roundabout must be split at any of those entry/exit point simutaneously, such that all routes remain correct
as a workaround, a mapper can remove the route relation(s) from the roundabout, split it accordingly and then re-add the respective parts to the relation(s) again.
instead of fully re-sorting the whole relation every time a member is split, perform a local operation: This works under the assumption that the relation is already sorted properly. The new way is inserted into the relation before or after the existing member, depending on how the old/new way connect to their neighboring members.
for cases where two ways form a loop, a additional look-ahead is implemented to disambiguate the order
When extracting a POI from a building or downgrading a building, this update keeps nycdoitt:bin= tag with the building, not extracts it to the node or deletes it.
resolves#8539
this necessary when a regional preset (e.g. from NSI) is supposed to inherit fields from a parent preset, but the direct parent does NOT apply at the location of the entity to be added/edited. In that case we need to search for a potential regional variant of the parent preset.
as it silently strips non-numeric suffixes (e.g. a value of "123 foo" is transformed into a numeric value of 123 by `parseFloat`, which is typically not what we desire)
* Clamp degree values in `direction` fields between 0 and 359 degrees, fixes#9386
* Only match cardinal values to numbers in `direction` fields
* Disable increment/decrement buttons on number fields if the input value is not numeric or when there is a multi-selection with conflicting values
* Fix/implement reverse operation for semicolon delimited `direction` values
Depending on which way is the longest, the new way is inserted into the
relation before the existing one. This case must be explicitly handled
for the relation to remain correct.
The operation is disabled when attempting to join ways which don't belong to identical sets of relations. Restriction relations are excluded, because they are already handled with slightly different logic.
Fixes#8674Fixes#8645Fixes#3825Fixes#1512
