This PR introduces simple filtering of duplicate housenumbers.
Simple means that filtering is done withing the tile.
Duplicates are defined as same housenumber, street, block_number[1].
Duplicates are usually caused by POIs. People like to add addresses to them. Most POIs have names so to prioritize addresses we pick features without names first.
Formula is: `row_number() OVER(PARTITION BY concat(street, block_number, housenumber) ORDER BY has_name ASC) == 1`
This PR reduces the minimum lake line zoom to z3, allowing the largest lakes to show a renderable label. The lakeline function is restricted by the LineLabel() function, which limits lakelines to only those that are big enough to render a text label. Therefore, further restricting lakelines by zoom is not necessary.
This PR follows #1465 to implement pseudo-route relations for Republic of Ireland road routes as described in the [OSM wiki](https://wiki.openstreetmap.org/wiki/Ireland/Roads). Irish road routes work in the same way as UK road routes in that signage is derived from highway classification on a 1:1 basis. The scheme described in the OSM wiki is confirmed via [overpass query](https://overpass-turbo.eu/s/1por).
This feature follows the implementation currently used for UK road routes, in which a 10m Natural Earth polygon is used to determine which roads are located within Ireland to apply this processing.
This PR implements 3 classes of routes:
* M-roads, which are `highway=motorway` and signed with blue/white lettering.
* N-roads ("national roads"), which are `highway=trunk` or `highway=primary` and are signed with green/yellow lettering.
* R- and L-roads ("regional and local roads"), which are `highway=secondary`, `highway=tertiary` or `highway=unclassified`, and signed with white/black lettering
Currently, river areas (`natural=water` + `water=river`) are rendered in the tiles as `class=river`. However, canal, stream, ditch, and drain water areas are rendered as `class=lake`. Since these types of objects are all flowing water, they should be grouped together into `class=river`, which allows for styles that render flowing water differently to do so on a consistent basis.
This PR adds an additional pseudo-network for UK non-primary [routes](https://en.wikipedia.org/wiki/Great_Britain_road_numbering_scheme), which are signed with black on white signage with "A" and "B" prefixes. This scheme is described on the [OSM wiki](https://wiki.openstreetmap.org/wiki/Roads_in_the_United_Kingdom). Adding this third psuedo network is needed for generating shields for UK white/black signage for non-primary routes.
Additionally, this fixes a minor bug under which single-digit refs would have been included. Single-digit refs don't exist in the UK, because the numbering scheme is always prefixed by a letter, e.g. "A4".
I also included documentation updates and fixed the typo where a view was named "bg" instead of "gb".
* At zooms 9-13, water labels will now be rendered for water features that are at least 0.25 tiles in size. This means that water features that are the same size as a 128x128 pixel square will get a point label.
* Labels for large water features are now shown at the lowest zoom at which it's appropriate to show a label.
* Bay and strait names (`natural=bay` and `natural=strait`) are included.
* Large seas modeled as areas (e.g. Caspian Sea) render as `class=sea` rather than `class=lake`
This PR addresses that by:
* rendering oneway arrows on more than `subclass=cycleway`
* less opacity for path/footway casing
* adding the thin black casing to bridges
* adding `subclass=steps` & `subclass=bridleway` rendering
* render `bicycle=designated` as `subclass=cycleway` and `horse=designated` as `subclass=bridleway` (bike taking priority)
* improved tunnel rendering with double casing & adding main line
* made casing min zoom consistent across subclasses
All of these changes were made to mimic OSM Carto.
This PR proposes to add a new class, "pond" to the water layer, which allows for a style to de-emphasize minor bodies of water (tagged `water=pond,basin,wastewater`) when compared to more significant objects tagged reservoir/lake. This PR retains the default behavior of classifying a water body as a "lake" if more specific tagging is not added.
This PR defines the set of routes in Canada which are equivalent in national importance to the US Interstate Highway System, and are therefore appropriate to render at zoom 4. This creates a sane, connected highway network at this zoom level across the USA and Canada.
This adds two additional network types for Canadian highways, ca-provincial for provincial-level roads, and ca-provincial-arterial for "highest importance" roads that are not part of the Trans-Canada highway but should be regarded as equivalent for low-zoom rendering purposes.
Additionally, this extracts out the country-specific network checks to a separate function in order to define "equivalent top-level networks" by country, providing a place to add additional national definitions as they're added by contributors.
This PR improves the behavior introduced in #1440, which inadvertently included all motorways at z4, which was unintended. Instead, this PR provides an appropriate progression from z4 to z5 with the highest national-importance highways being rendered at z4 (including where they degrade to trunk, as in Canada), and all motorways being added to the mix at z5.
This adds support to show the Trans-Canada Highway at zoom 4. Despite being the most important highway network in Canada, portions are `highway=trunk` due to the remoteness of the countryside. However, it's still important to show a connected highway network at the lowest zoom without showing all trunk roads at this zoom.
This change also adds support for US Interstate Highways to be drawn at z4 when they're tagged as trunks. There's only a few examples of this, but it removes those (tiny) gaps from the generalized road geometries. As we identify additional countries which should have their most important road network rendered at the lowest road zoom even if they're trunk, we can add them to the list of networks that get this treatment.
* OpenMapTiles style
* Rename style snippets from layer_name.json to defaultstyle.json
* Add README to icons dir.
* Add README to icons dir.
* Rename snippets to style.json
* Fix spritezero - move icons to svg subdir
* Move icons from style/icons/svg directly to style/icons
Co-authored-by: Tomas Pohanka <TomPohys@gmail.com>
This PR creates larger polygons of `residential` land-use areas for upper zoom levels (especially for zoom 6 - 10).
Clusters are created with the same logic as for [`building on z13`](b14da2eafb/layers/building/update_building.sql (L34-L49)).
The generalization of land-use prolongs the `import-sql` step of the `landuse` layer. But it is still faster than the `building z13` generalization which with the parallel importing keeps the whole `import-sql` time untouched.
This PR updating Natural Earth dataset from v4.1 to 5.1.2. It is in cooperation with https://github.com/openmaptiles/openmaptiles-tools/pull/414, where is `import-data` docker image updated.
PR removes manual fixes for lake merging (already fixed in version 5.1.2)
Switched comparison from `gn_ascii` (removed from NE5) to `name_en`.
Could be merged after https://github.com/openmaptiles/openmaptiles-tools/pull/413. After OMT-T is merged, it will use `latest` image (until the release of OMT-T v7)
Guided busways (or bus guideways in OSM terminology) are special roadways along which bus operators can travel smoothly at high speeds without steering. These are tagged highway=bus_guideway on OpenStreetMap.
Currently, highway=busway is surfaced in OpenMapTiles as the busway class in the transportation layer, but highway=bus_guideway is not present. These two types of roadways serve generally similar purposes, so it would make sense to have guided busways at the same zoom levels.
This PR adds support for `capital=6` in the place layer, which is used for tagging county seats in the US. A county seat is the capital of a county. In addition, I reorganized the code a bit to be simpler.
As noted in ZeLonewolf/openstreetmap-americana#384, we would like to render county seats along with state and national capitals, as this is typical styling on American-style maps.
Update with also with `capital=3` and `capital=5`
closes#1370
This PR adds a parcel locker to post class.
Similarly to ATMs from PR #1375 if a name is not present we try to use `brand` or `operator`. Here we also try to add `ref` to the brand or operator since it can disambiguate parcel lockers that are next to each other (which happens).
This PR adding OSM ID to the lakes
OSM lakes are used from zoom 6
From zoom 0 to zoom 5 are used Natural Earth lakes.
- There is a new joining mat. view (`match_osm_ne_id`) contains which Natural Earth ID should convert to OSM ID. This logic is used to keep a consistent ID between switching between NE (zooms 0 - 5) and OSM (zooms 6 - 12). For smaller areas (not the whole planet), where are not available OSM lakes, the NE lakes keep their NE ID.
- There are also switch the final views to the mat. views - this should slightly increase performance (get rid of multipolygons).
- FIX typo for zooms 0 - 3 (`lakes` instead of `lake`).
Fixes#1374
This PR fixes `update_osm_route_member()` function. Before this the column `network_type` became empty after daily-update.
This PR adds `network_type` into upsert together with `rank` and `concurrency_index` columns.
This bug had occurred once already and had been fixed in https://github.com/openmaptiles/openmaptiles/pull/1239 but then some columns were added and these new columns were not added into the upsert.
Replace the `REFRESH MATERIALIZED` on `osm_important_waterway_linestring*` by differential update.
The way of doing this is the same as other differential updates.
Replace the `REFRESH MATERIALIZED` on `osm_transportation_merge_linestring_gen_z*` by differential update.
The way of doing this is the same as other differential updates. But in this case there two `GROUP BY` level. So all the the process have to be done twice.
This PR removes an unnecessary check in water.yml.
generated SQL before:
```
SELECT CASE
WHEN waterway='riverbank' THEN 'river'
WHEN "waterway" = 'dock' THEN 'dock'
WHEN "water" = 'river'
OR "waterway" = 'riverbank'
THEN 'river'
WHEN "waterway" = '' THEN 'lake'
ELSE 'lake'
END;
```
generated SQL after:
```
SELECT CASE
WHEN waterway='riverbank' THEN 'river'
WHEN "waterway" = 'dock' THEN 'dock'
WHEN "water" = 'river'
OR "waterway" = 'riverbank'
THEN 'river'
ELSE 'lake'
END;
```
The `waterway=''` test is purely redundant because it returns the same value as the fall-through ELSE case: `lake`.
Before this, only `aerialway=cable_car` and `aerialway=gondola` were included in the tiles. That misses some widely-used tags, notably `aerialway=chair_lift`, `aerialway=drag_lift`, and `aerialway=platter`. The usage of all the tags added in this commit, by fraction of all aerialway way keys (according to TagInfo), is:
| Tag | Usage |
|------------------------|-------:|
| `aerialway=chair_lift` | 25.51% |
| `aerialway=drag_lift` | 12.93% |
| `aerialway=platter` | 11.35% |
| `aerialway=t-bar` | 7.93% |
| `aerialway=j-bar` | 0.63% |
| `aerialway=mixed_lift` | 0.24% |
Some of these tags were also added in PR #620 back in May 2019, but were removed again before it was merged.
Fixes#1342.
Updates on `transporation_name` layer take much more time than before.
In 3.13 there had been introduced highway concurrency into `transportation` and `transportation_name` so I expected the update process will take more time but not that much. Because of this it's impossible to use updates on larger areas because the process takes too long.
The issue is caused by `IS NOT DISTINCT FROM` operator over `tags` (hstore) columns. I replaced it with `=` operator in combination with `coalesce()` function which returns the same results but in shorter time.
This PR fixes a bug that causes that `track` lines disappear at z13. This bug was introduced in https://github.com/openmaptiles/openmaptiles/pull/1190, which adds rendering of paths and tracks at z12 and z13.
Before this PR:
z12: lines with `route_rank = 1` are added (no matter what `highway`).
z13: lines with `route_rank BETWEEN 1 AND 2` and `highway = 'path'` are added.
-> tracks with `route_rank=1` are added at z12 but not at z13.
After this PR
z12: lines with `route_rank = 1` and `highway IN ('path', 'track')` are added.
z13: lines with `route_rank BETWEEN 1 AND 2` and `highway IN ('path', 'track')` are added .
-> only tracks and paths are added at z12 and z13 (which was IMHO the goal of https://github.com/openmaptiles/openmaptiles/pull/1190)
* Add only the most important paths and tracks (route_rank=1) to z12 and more important ones (route_rank between 1-2 or sac_scale or has name) to z13.
PR move `get_basic_names(tags, geometry)` function from `transportation_name_tags` function and adding it after `transportation_name_tags` resolve street abbrevation.
PR runs through `test-sql` test without error. Adding to `osm_transportation_name_network` (table and for update) was done in consequence of `test-sql` errors ([update test 500](a747d98550/tests/test-post-update.sql (L53))). Originally `get_basic_names` was just in `osm_transportation_name_linestring` table.
FIX#1324
Remove `STRICT` statement from `transportation_name_tags` function.
Concurrently with remove `STRICT` from `get_basic_names` and `get_latin_name` in OMT-T
FIX#1319
Fixes#1148
This PR adds expressway tagging to the `transportation` layer, by setting `expressway=1` for non-motorway roads tagged `expressway=yes`, and omitting the tag otherwise. Additionally, I've added a few unit tests to verify that the expressway tagging is being imported and updated into the intermediate tables.
Here is an example of expressway tagging on US-1 in Rhode Island, USA:
I discovered this bug while investigating issues with the updates process related to #1190#1292, and #814.
The `transportation_name` layer produces slightly different `tags` hstore values in the `osm_transportation_name_linestring` table during the initial import versus when running an update. As currently written, the import code produces null-value keys in the `tags` column, while the update code suppresses them. This PR removes that difference and makes the import code use same method that is currently used in the update code.
With a test case I've written, the import code produces a tags hstore that looks like this:
`"name"=>"OpenMapTiles Secondary 2", "name:de"=>NULL, "name:en"=>NULL, "name_int"=>"OpenMapTiles Secondary 2", "name:latin"=>"OpenMapTiles Secondary 2"`
...while the update code produces a tags hstore that looks like this:
`"name"=>"OpenMapTiles Secondary 2", "name_int"=>"OpenMapTiles Secondary 2", "name:latin"=>"OpenMapTiles Secondary 2"`
Note the missing NULL values.
This bug causes a small amount of space wastage after an update is run, because the update matching code detects the `tags` value as different, resulting in a duplicate copy of the tags value if that row is updated. This causes duplicate objects and breaks GROUP BY clauses that expect to group same-tagged features together. I've tested this by inspection of a generated mbtiles, database spot checks, and the unit test code included in this PR.
This PR implements non-blocking updates in the park layer.
The approach was to use the `REFRESH MATERIALIZED VIEW CONCURRENTLY` feature in postgres. In order to achieve this, a unique index was added on the z4 dissolved park area table. The `ST_Union` / `ST_Dump` sequence was changed to an explicit cluster DB scan (an equivalent operation) so that a unique osm ID could be generated from each dissolved polygon.
Below is a screen shot from Idaho, USA showing that the dissolved z4 still works as expected.
Closes#271
This PR adds track and path rendering at lower zooms than currently provided, and also achieves near-parity with openstreetmap-carto on track and path rendering. A previously-abandoned attempt, with significant discussion, was #1169.
This PR is solving https://github.com/openmaptiles/openmaptiles/issues/406, partially also https://github.com/openmaptiles/openmaptiles/issues/320.
It is changing source of data for zoomlevel 6 - 8 in `waterway` layer to OSM (relation `waterway = river`), this way it corresponds with `water` layer.
Testing on Europe, z0 - z9 tiles increase size from 20.7 MB to 21.4 MB. We can discuss the level of generalization, but I think this size change is not critical.
ttomasz
