Some US roads were not included in tiles, because the `ST_AsMVTGeom` did not transform geometry (result was NULL). This PR is trying to fix the geometry for `ST_AsMVTGeom`, even if the geometry is marked as valid (`ST_IsValid`). The odd geometry was caused by simplification when it could create `LINESTRING(1 1, 2 2, 1 1)` linestring, which in some cases was not converted into MVT.
Also, for the US (on zoom 4) keeps just the network `us-interstate` and the `highway=motorway` or `osm_national_network(network)` for the rest of the world.
Drop the main table for layer `transportation_name` layer before creation.
For the first SQL import, it is OK, but for the second import (e.g. for a different country by `import-osm area=yyy`) without dropping the whole database it will keep `osm_transportation_name_network` filled with data from the first import (after first `import-sql` step)
This PR will drop the already-filled table from the first import and insert data from the reimported area.
Partial revert the `e-road` and `a-road` added in https://github.com/openmaptiles/openmaptiles/pull/1619.
This PR leads to breaking the change of `network` and `ref` attributes for roads, which are not included in `osm_route_member_network_type`.
This PR reduces transportation_name layer fragmentation by ensuring the short brunnel segments are merged rather than dropped from view.
---------
Co-authored-by: Tomas Pohanka <TomPohys@gmail.com>
This PR replaces the `route_N` attribute scheme with individual attributes for name and colour on routes. Thus you will have:
* `route_N_network` to hold the route `network` value
* `route_N_ref` to hold the route `ref` value
* `route_N_name` to hold the route `name` value
* `route_N_colour` to hold the route `colour` or `ref:colour` value
Adding source_ids column if not exist in the table
- osm_transportation_merge_linestring_gen_z11
- osm_transportation_merge_linestring_gen_z8
- osm_transportation_name_linestring
- osm_important_waterway_linestring
#1313 added `expressway` tagging to the transportation layer. However, this also added the `expressway` attributes to ramps where it doesn't make sense (ramps by definition are controlled-access roads in all cases). This PR corrects this by dropping the `expressway` attribute from ramps where it doesn't make sense to do so.
See also ZeLonewolf/openstreetmap-americana#1017
This PR removes the `oneway` attribute from ferry lines and rail lines. These attributes don't really make sense for these feature classes and they are not typically rendered in general-purpose maps.
This PR addresses two main issues introduced by the new ID-Based Merged-LineString Updates
1. Partial Indexes can only be accessed when the query matches more or less exactly and the query-planner will fail to use indexes when targeted via the join-condition and not the where-condition
- `osm_transportation_merge_linestring_gen_z9`
- `osm_transportation_name_network`
- `osm_shipway_linestring`
- `osm_aerialway_linestring`
- `osm_waterway_linestring`
2. When intersecting updated Source-LineStrings with the existing Merged-LineStrings we join the Source-IDs of each existing Merged-LineString. This bloats the table unnecessarily and slows down bigger updates considerably.
- This is addressed by aggregating the Source-IDs of each existing Merged-LineString into an array and concatinating these arrays when grouping them. Afterwards we add the IDs of updated SourceLineStrings and deduplicate the result before adding it to the Source-IDs-Table.
LEAKPROOF requires the executing user to have superuser privileges when creating the functions which would be the only statement required to be executed as a superuser.
Multi-Column Primary-Keys (Unique-Constraints) must not contain NULL values in postgres up until version 15.
This PR coalesces NULL to empty strings for the primary columns during `transportation_route_member_coalesced` updates and import.
Additionally adds the missing `concurrency_index` to UPSERT statement of `transportation_route_member_coalesced`
Improved update performance of transportation_name layer
- Refactored LineString-merging and diff updates in update_transportation_name.sql
- Refactored transportation_route_member_coalesced materialized view to table
- Added analyze statements before update queries during transportation_name.refresh_network and update_osm_route_member
In some areas of the world, ship transportation is the main means of long-distance travel. For example, in Alaska, the [Alaska Marine Highway System](https://dot.alaska.gov/amhs/route.shtml) is the principal means of transportation through the Alaska Panhandle and down the Aleutian island chain. The AMHS carries the same importance that the Interstate Highway System has on land, and these ferry routes are exceptionally long distance.
This PR now removes bridge/tunnel/ford attributes from the `transportation` layer from sections of bridge/tunnel etc that are too small to be meaningfully visible at a particular zoom level. This allows those segments to be generalized into geometries along with the surrounding sections of road, thereby dropping lots of useless little pieces of geometry in lower-zoom tiles.
This PR changes the three-column unique index to an on-insert trigger. This should fix the issues we're having with CI failures and still achieve the behavior of coalescing duplicate routes.
I moved the concurrency_index calculation into an intermediate materialized view to separate the de-duplication capability from both DENSE_RANK() and from imposm updates.
This PR sets `surface=paved` for `highway=track` + `tracktype=grade1` if no other value of `surface` is set. Roads tagged in this way are [generally paved](https://wiki.openstreetmap.org/wiki/Key:tracktype) and therefore encoding them as a paved road is appropriate.
# Problem description
#1128 introduced route relation concurrency information in OpenMapTiles via the `route_X` attributes. The original implementation assumed that there would be a single route relation for each `network` and `ref` pair. However, it is increasingly common practice to tag a separate route relation for each direction of a route in order to provide awareness to routers and other data consumers of the directionality of a route. This standard and growing practice is described on the [OSM wiki page on route directions](https://wiki.openstreetmap.org/wiki/Route_directions). Thus, the naïve implementation of #1128 caused duplicate entries to be added as `route_X` attributes in the case where separate route relations were used for directional routes.
# Solution description
This PR adds grouping when computing route concurrency information, such that duplicate entries are coalesced in a predictable way. Since this grouping is done only within a route membership join of a single member way, the computational complexity should be trivial.
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
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".
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 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>
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.
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_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.
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.
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.
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 removes cases of `oneway=0` as this is an assumed default. It is not necessary to have this tag on every road or path and by removing it we can save space in the tiles by only including the meaningful values. It leaves intact `oneway=1` and `oneway=-1`, the latter of which indicates a oneway in the opposite direction of the way.
Unblocks #1265
This PR removes unnecessary `ramp` tagging from the `transportation` layer. The `ramp` tag is used for two situations. First, it is set for all `highway=***_link` tags to indicate a highway ramp. The second situation is when the `ramp` tag is set on a highway object, which indicates the presence of a ramp, such as one that would be used for a wheelchair. `ramp=0` is a reasonable default in these situations; by removing cases of `ramp=0` and presenting only `ramp=1` to the tiles, we can save considerable size in the tiles. Additionally, there appears to be a bug in which all objects tagged `highway=steps` are inexplicably tagged `ramp=1`.
The changes as follows:
1. Remove `ramp=0` where it appears in the tile.
2. `highway=steps` no longer assumes `ramp=1` in cases where `ramp=*` is not explicitly set.
In the current behavior, `ramp=0` is tagged only in at z13+ but suppressed in lower zooms:
This PR unifies `ramp=0` suppression between z13+ and z12-.
This PR fixes a bug in the `WHERE` clauses in the transportation layer generalization tables for zoom 10. The intended behavior of the layer is to suppress `highway=tertiary` and `highway=tertiary_link` at zoom 10 and lower. However, due to this bug, these objects were not suppressed as intended, because an `OR` was used in the SQL where an `AND` was needed instead.
This bug was inadvertently introduced in #1172😞
Tomas Pohanka
