fixes a bug where the field was not properly filled in when the tag contained a non-numeric value (e.g. `direction=S`), which could eventually cause the tag be deleted inadvertently after focussing/blurring the field.
closes#11076
this regressed in 2b64d70352
to allow more snappy scrolling through the photos of a sequence using the prev/next buttons
the cache is primed with information for "most of" the selected sequence, see also https://gitlab.com/panoramax/server/api/-/issues/268
while loading a "scene", pannellum cannot load a new panorama scene. This means we have to wait while the viewer is busy loading an existing panorama until we can load a new one.
…back to the default state. This was a slight regression from the refactoring in #10730: In an intermeditate step, the entity has `oneway=yes`, which should actually be ignored when determining if an entity has an implicit oneway state.
* always show empty line at bottom of the tag list to allow adding more tags (replaces `+` button and tab logic)
* disable delete and info buttons on empty tag
* replace deferring of tag change events and re-rendering with a simpler logic (to fix issues like #10871):
only set input field values if the rendering event was triggered by an external event, or by a change of the respective field in the raw tag editor itself
* skip delete and tag info buttons while navigating using tab: makes it more quick to get to where one typically needs to, deleting a key using the keyboard only is possible by emptying the tag's key, and advanced users are not typically using the `i` button anyway
previously, when the photo was already loaded in the mapillary viewer, then another photo from a different provider was displayed and the previous mapillary photo selected again, the "highlighted photo" marker was not drawn correctly, and the "set mapillary id from photo" button not properly updated
this makes the most sense, as it should be almost always present in the address field and be the most "unique/important" value to edit for an address
closes#11004
this makes it similar to how the non 360° viewer and mapillary's 360° viewer work, allowing regular iD keyboard shortcuts to be used even when the focus is on the photo viewer
fixes#10997
Also change the split operation to only split the ways which contain all selected nodes (when thare are more than one node selected). This is more likely what the person performing the splitting intends to do
…when using the zoom buttons or +/- keyboard shortcuts (i.e. does not affect the mouse-wheel/pinch zooming)
Also: make zoom in/out transition slightly faster.
In sum, this allows to zoom in/out multiple levels in quick succession, and using the zoom buttons should be more intuive: they don't snap to very-close zoom levels anymore (e.g. hitting `+` when the current zoom was 15.97 would previously result in a final zoom of 16.00, which is not really what a user would need. Now the zooming in results in a final zoom level of 17.00, which is "actually properly zoomed in".
initial zoom | operation | final zoom (new) | final zoom (old code)
----- | --- | ----- | -----
16.00 | `+` | 17.00 | 17.00
16.00 | `-` | 15.00 | 15.00
16.10 | `+` | 17.00 | 17.00
16.10 | `-` | 15.00 | 15.00
15.90 | `+` | 17.00 | 16.00
15.90 | `-` | 15.00 | 14.00
consider some additional tags as "not interesting"/non-POI-like:
* check_date/fixme/note/note:*/survey:* — mapping related tags
* layer/level/level:ref — can be considered attributes of the address
* ref:* – often used to indicate a source ID on imported data
as the current graph has now the most recent version of the modified entities, each individual change only needs to take into account the delta of the mouse movement between the current position and the previous one (instead of the original mouse position when the operation was started)
* preserve the sum of certain tags (`step_count`, `parking:*:capacity`) during _join_ operation
* preserve total value of `parking:*:capacity` tags during _split_ operation by distributing it proportionally to the resulting ways
* the abstract osm entity now accepts a list of tags to override during the merging, but otherwise is agnostic about how tags can be merged: the concrete merging resolution might depend on the concrete action that was performed
* append relation id as hovertext in membership editor as last-resort disambiguation in case multiple relations have otherwise the exact same label (and type)
* show regular relation label also as hover text, which is useful to see the full name in case it is cut off with an ellipisis (…) for long-ish labels
fixes#10186, where features with e.g. `intermittent=yes` were incorrectly sorted into the past/futures layer
now only features with correct tagging are included in the "past/futures" layer:
* either the "legacy" lifecycle tagging (e.g. `highway=construction`)
* or proper lifecycle prefix tags (e.g. `disused:shop=convenience`)
housenumber/housename are taken from surrounding areas, as well as address points that are inside (or on the perimeter of) the same building as the selected feature
