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
1. direct OSM id results (e.g. `node/123`)
2. local osm data matches
3. lat/lon coordinate
4. geocoded results
5. other results (currently: only guessed OSM ids if the search looks like a number)
