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 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
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
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.
# 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 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.
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.
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 a bugfix for the `transportation_name` layer. Currently, the updates process does not work, as noted by @zstadler in #1230. The issue is that the computed `concurrency_index` column in `osm_route_member` is never updated after the initial updates. Therefore, whenever route member ways are updated, they will lose their route concurrency index, and hence route concurrencies will be lost in the `transportation_name` tiles. This PR adds the missing concurrency index update code to the transportation/network update triggers.
This PR as written also incorporates the fixes in #1230 and #1233.
The following SQL is a unit test to demonstrate that these triggers work correctly:
```
select count(*) from osm_route_member where concurrency_index > 5;
select count(*) from osm_transportation_name_network where route_6 is not null;
update osm_route_member set concurrency_index=NULL where concurrency_index > 5;
select count(*) from osm_route_member where concurrency_index > 5;
select count(*) from osm_transportation_name_network where route_6 is not null;
```
If working correctly, both pairs of `count(*)` values should return the same pair of numbers.
While troubleshooting #1230, I discovered that there were cases where a way was a member of the same route relation more than once, such as: https://www.openstreetmap.org/way/17439235
<img src="https://user-images.githubusercontent.com/3254090/133726616-acd01332-343e-4930-ad3d-1fb3c3190a4c.png" width=280/>
This segment would end up showing duplicate highway shields in a rendered style, which is not desirable. While I personally think this style of tagging is wrong, it's a relatively easy fix to remove those duplicates. This PR replaces `ROW_NUMBER()` with `DENSE_RANK()` in the concurrency index generation code and adds a `DISTINCT` constraint on the concurrency join to handle multiple member rows with the same concurrency index.
Since I was in this file, I also fixed the copy/paste error in generating the route names.
Screenshot from database showing correct mapping:
This PR updates the `transportation` layer creation scripts to simplify the SQL and remove unneeded sub-selects, checks and conditionals, fix indexes, and improve inline documentation.
Currently, there are two sequences of materialized view creations. There is one from zoom 11 through 9, and a second one for zoom 8 through 4. This PR removes that break in the sequence of transportation table materialized view creations, in favor of one in which high-zoom views are created first, and then each lower zoom is created from the zoom above.
Instead, the current generalized zoom 8 transportation table is built directly from `osm_transportation_linestring` rather than being built from the zoom 9 transportation table. This means that when building the zoom 8 table, it must scan the entire transportation network rather than just selecting from the pre-filtered zoom 9 table.
This PR removes an unneeded sub-select in the build of the zoom 8 table, which appears to be a leftover from an old version of the SQL that did some sort of merge. Once this PR is implemented all zooms from 11 through 4 will be linked via a progressive series of materialized views.
Lastly, this adds in missing materialized view refreshes for zooms 9-11, which appear to have been entirely missing, and as far as I can tell aren't getting updated in the current version of this code.
In addition, the following optimizations were added as part of this commit:
1. Updates the `osm_highway_linestring_highway_partial_idx` partial index to match the `SELECT..WHERE` clause actually present in `transportation/update_route_member.sql`, which is where it appears to be actually used, and update inline documentation to reflect this.
2. Collapses unnecessary sub-select block in `osm_transportation_merge_linestring_gen_z11`, and removes unnecessary ST_IsValid() call, which already provided in `mapping.yaml`, and update inline documentation to reflect these assumptions.
3. Updates `WHERE` blocks to remove unnecesary checks and further document assumptions. The `highway=construction` check is unnecessary in all cases, because it is sufficient to check the `construction` key alone. If `construction=*` is set, then `highway=construction` is implied.
4. Two indexes were added to `layers/transportation/update_route_member.sql` to improve route population performance.
In testing locally, I'm seeing performance improvements around 10% in the generation of the `transportation` layer, based on modifying `openmaptiles.yaml` to generate only the transportation layer and then repeatedly running `time make import-sql`, however, this timing might be impacted by docker, so I would ask for confirmation of acceptable performance.
In addition, this PR shortens the length of the transportation update SQL file by 30 lines, which makes it easier for contributors to work with.
Tomas Pohanka
