- Remove translation description strings, will be using supplied
translations once the API is updated
- Change the way elements and details are presented since they can't be
easily integrated into the 3rd party description strings
This is just step one in the process while we wait for the API to supply
further strings and filtering to reduce the amount of string data
requested (since we don't need it all).
Strings are requested when the layer is first enabled and cached for the
current language (plus English as a backup).
- Unconnected level crossings
- Unconnected highway features/barries
- Unexpected punctuation/symbols in tag values
- Unbalanced parentheses/quotes in name values
- Invalid date formats
- Access tagging that permits all transport modes
- Elements with a "name" tag and no main tagging
- Relations missing a "type" value
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
Also adds support for the following error types:
- Objects mapped as both node/area or way/area
- Power lines that lead to nowhere
- Extra nodes in power lines (which should only go from support to
support to endpoint)
- Power line supports with no power lines
- 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.
This also includes a bunch of tweaks to make the tests work
in both PhantomJS and modern browsers like Chrome.
Basically - introduce some more async into the test code so that
the coreData.get promise is guaranteed to settle. Because in
PhantomJS the promise is polyfilled, and Chrome it's native, they
work slightly differently.
Also dist/data/* contains minified files now
These are now external and will fetch as needed:
-export { dataAddressFormats } from './address-formats.json';
-export { dataDeprecated } from './deprecated.json';
-export { dataDiscarded } from './discarded.json';
-export { dataLanguages } from './languages.json';
-export { dataPhoneFormats } from './phone-formats.json';
-export { dataShortcuts } from './shortcuts.json';
-export { dataTerritoryLanguages } from './territory-languages.json';
