- preset data is no longer bundled into iD.js
- some code pathways commented out re: external presets
- many changes so that tests can run without presets at start, or async
- still need to make sure fallbacks are always there (point, line, area, etc)
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';
- This is to make difference comparisons easier
- The only nodes that didn't have a `loc` were fake nodes we made for testing
- So this commit also fixes the `osmIntersection` code and tests.
Return old_multipolygon validation issues for the relations as well as the outer ways
Remove console logging
Don't run missing_tag validation for relations with old_multipolygon issues
This generalizes the oneway arrow logic for adding SVG markers along a
line. Using that functionality, certain tags get arrows on their
right-hand side, indicating which side is "inside", e.g. the
right-side of a cliff is the lower side.
The list of tags considered to be sided (unless there's a
two_sided=yes tag) is:
- natural=cliff
- natural=coastline
- barrier=retaining_wall
- barrier=kerb
- barrier=guard_rail
- barrier=city_wall
- man_made=embankment
The triangles attempt to be reminiscent of the triangles used for
rendering cliffs on OSM (and elsewhere). The different tags get
different renderings (e.g. colors that match the main way, and
different spacings). In addition, natural=coastline is special-cased
to have blue markers (despite having a green way), to emphasise that
the "inside" of a coastline is the water.
Fixes https://github.com/openstreetmap/iD/issues/1475.
- actionRestrictTurn will no longer "infer" the turn type
- restrictionType *must* be passed in - this is ok because the only code
we use this action (restrictions.js) already has inferred the type
- this simplifies what the action actually does
- moved the tests from restrict_turn.js that were really just testing
the restriction type inferrence over to intersection.js
(and added a few more tests for iD.osmInferRestriction)
These should not be a thing, and if they are, I'm ok with them
being treated as 2 separate ways. We can add code back in later
if it turns out to be a widespread issue in OSM.
(re #4589)
Strongly prefer to generate a forward path that preserves the order
of the members array. For multipolygons and most relations, member
order does not matter - but for routes, it does. If we started this
sequence backwards (i.e. next member way attaches to the start node
and not the end node), reverse the initial way before continuing.
