update from original #1
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
makes #70 less severe or maybe even fixed
"Always specify zoom levels as either >= or < . Don't use = or =< or >"
This expands the shield generation script to cover multi-line shields, and commits those shields. It doesn't yet use them.
…etmap-carto into allotment-metatile
We still render landuse=cemetery and amenity=grave_yard. See issue #204.
Drop polygon-opacity from landcover tags that still had it, i.e.: * tourism = camp_site * tourism = caravan_site * tourism = picnic_site * landuse = garages * landuse = fill * leisure = park * leisure = recreation_ground * landuse = brownfield * landuse = landfill * landuse = construction * aeroway = aerodome Polygon-opacity should be avoided, as it gives smudgy and sometimes unexpected colours in case of overlapping polygons. Also colour landuse=field as landuse=farm_land, as the old landuse=field without opacity is too dark.
explain workflow in contribution guidelines
Increase text-dy for default shop style
Drop landuse=grave_yard
Currently, rendering order of road rendering within one layer is handled by the z_order column, which comes from osm2pgsql. As such, we have little control over road rendering without reloading the database. This PR moves control over the rendering order to the SQL query. This adds complexity to the SQL queries, but increases customizability, and simplifies the roads.mms code. This solves the following issues: * #462 (Move rendering order road types from osm2pgsql to our SQL queries) * #163 (Railways are now drawn above roads) * #167 (Tramway layering issues) * #168 (Paths are now drawn below link roads) * Trac 2024 (Service roads are now rendered below link roads) * Trac 3649 (Service roads are now rendered below race tracks) * Pedestrian and living streets are now consistently ordered * Footways are now always displayed under service ways
This corrects a mismatch between the queries and the style sheet for the roads-low-zoom and roads-text-name layers. This should not have influence on performance.
The colors have been chosen in such a way that they stay the same on the gray 'land' background.
Be consistent in the bridge values for which we test. Note that bridge=true and bridge=1 are no longer in use.
This resolves #700.
This resolves #817.
This solves #760.
…enstreetmap-carto into math1985-service-casing-color
This works around mapbox/carto#368, but it's more to lock down versions and keep CI as a test solely of the stylesheet, not of any components.
…as become unweildy.
I didn't know how this would work when we first started, but it's settled down now so worth writing it out.
Requires PyYAML. If this dependency is an issue on a particular
platform, pretty much any language allows you to do this.
A ruby example is
ruby -ryaml -rjson -e 'puts JSON.pretty_generate(YAML.load(ARGF))' < project.yml > project.json
This one-time conversion was done with the json2yaml node module,
and then substantially reformatted by hand, using mappings and alias
to avoid repeating projection and extents information for each layer,
and to get consistent ordering of the properties of each layer. The
latter does not matter semantically, but makes editing with a text
editor cleaner.
By using the scripts/yaml2mml.py script, the YAML can be converted
back into JSON, which is still what TileMill uses.
A JSON-aware diff of the original project.mml and the new generated
one shows that the only differences are the new "_parts" property,
used for aliases and ignored by TileMill, and layer extents.
The script can be invoked with
scripts/yaml2mml.py < project.yaml > project.mml
The project.mml file remains checked in to git, as TileMill requires
it and this allows someone to clone the repo, and immediately have
it work. Merge conflicts in project.mml are trivial to solve, as
the entire file is just regenerated by running the script again.
This does mean that the .MML file should not be edited directly,
but this is fine, as editing the JSON by hand is extremely difficult
anyways! The HOT OSM style has a similar workflow, making use of cartocc.
By using aliases, we can avoid having to specify the same information repeatedly, saving lines, avoiding mistakes, and making it easier to use a differently named database. The last is evident in that the landcover extents changed slightly in this, because they were different than all the other layers.
Block scalars allow you to use newlines, and are far more readable This commit also catches some extents that were missed previously.
Docs grammar
Use a specific version of carto for travis
A lot of the SQL was badly formatted, with random tabs, caps, and lines of 5000 characters. This commit cleans up about half of them but is not complete.
…into pnorman-yaml
polarbearing
pushed a commit
that referenced
this pull request
Jan 13, 2018
Add additional SQL condition for very low admin logic
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.