When I added special handling for mapillary errors the code was trying
to access translation strings nested under the error category (which
doesn't exist for all error types). This code is now moved into it's own
function so that variable hoisting doesn't run it for non-applicable
error types and prevent them from working.
- Also adds support for error type 3040 (bad tag value)
- Updated the Osmose sidebar UI title
This seems more useful than tagging with a list of joined coordinates
which quickly becomes truncated due to tag value length.
Adds a tag per issue type similar to iDs own validation.
- Missing parking access
- Malformed opening hours tagging
- Objects detected by Mapillary that aren't mapped
- Traffic sign information detected by Mapillary that isn't mapped
Mapillary errors add example code for special error type handling as
they don't need to request further details and can use piecewise
translation strings
- Simplifies our code a little bit
- Quick to provide and gives us the `item` + `class` without requesting
all other information (the two things needed to know the error type)
- Removed handling of associated elements for now, need to implement
fetching for that data on a per-issue basis when the UI loads
- Set things up for the possibility of using the provided translation
strings (need to determine if desirable)
See: https://github.com/osm-fr/osmose-frontend/issues/193
Some error types don't require unique strings and can share common
strings among the category. This makes that possible as well as adding
support for some other types of error for demonstrative purposes.
Filters out errors not present in the data .json file to enable
selective support since Osmose has a wide variety of errors which may be
too advanced for iD.
Also added processing for the elements associated with an error for
forced visibility and highlighting.
- Seems that the expected payload has changed so now all error types use
key "targetIds"
- Also includes minor fix so that comments display in the UI immediately
(closes#6426)
After switching from XHR->fetch, we now parse the response separately,
so the `vtToGeoJSON` function already has an ArrayBuffer to work with.
`utilIdleWorker` was only used one place.
It just processes a list in an idle callback.
I'm working towards removing the util functions for handling idle work.
We can still do `requestIdleCallback` work throughout the code, however
each place we use it needs to have a strategy for cancellation, which
the existing util functions don't allow for.
- can't reliably use sinon.spy to tell whether a thing has been called,
so we listen for events instead and check server.requests()
- make sure to request the next page before dispatching `loadedImages` so
we can `server.respond()` to the request in the event handler if we want to
- also moves `localeDateString` in the openstreetcam service from parsing
code to display code, because it's very slow (we can just do this for the
images we look at, instead of all images we fetch)
Because the done callback is expecting something that has a `status` property,
(like an XHR would), we need to extract the status out of the error message.
d3-xml includes status in the error message, but we can't access the response itself.
