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
* Fields: Break long lines in combo dropdown instead of ellipsis
Longer translations keys are not readable with ellipsis and the tooltip only shows the description (or fallback), not the title.
This change makes long use line breaks with small line height to make the whole text visible.
* Fields: Use table styles for rows to maximize available space
The flex box solution gave a lot of space to the label. This solution minimizes that space to give more space to the values dropdown.
Most DMS format parsed by @mapbox/sexagesimal,
add a expandable matcher and two new formats for coordinates in DMS format in search bar
example: `35 11 10.1 , 136 49 53.8` (D M SS format), or `35 11.168 , 136 49.896` (D MM format)
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
The common use case is for the `sources` key, often you have multiple URLs separated with semicolon.
This allow to navigate to URL and check them more easily instead of
doing manual work to select the URL copy and paste.
Created with the help of Martin Raifer at the sotmeu2023!
fixes#9898
Fixes a problem that occurs because the order of the field `options`
can be in general different from the order returned by taginfo
(taginfo sorts by usage, while presets typically are sorted alphabetically),
causing different values to be potentially selected for autocomplete values.
As the taginfo results typically come in a few moments delayed, this can
lead to confusing behaviour.
This solves it by just not reattempting an autocomplete using the taginfo
results, if a field has static options available.
