openmaptiles/layers/transportation_name/transportation_name.sql

292 wiersze
10 KiB
MySQL
Czysty Zwykły widok Historia

-- etldoc: layer_transportation_name[shape=record fillcolor=lightpink, style="rounded,filled",
-- etldoc: label="layer_transportation_name | <z6> z6 | <z7> z7 | <z8> z8 |<z9> z9 |<z10> z10 |<z11> z11 |<z12> z12|<z13> z13|<z14_> z14+" ] ;
CREATE OR REPLACE FUNCTION layer_transportation_name(bbox geometry, zoom_level integer)
RETURNS TABLE
(
geometry geometry,
name text,
name_en text,
name_de text,
tags hstore,
ref text,
ref_length int,
network text,
route_1_network text,
route_1_ref text,
route_1_name text,
route_1_colour text,
route_2_network text,
route_2_ref text,
route_2_name text,
route_2_colour text,
route_3_network text,
route_3_ref text,
route_3_name text,
route_3_colour text,
route_4_network text,
route_4_ref text,
route_4_name text,
route_4_colour text,
route_5_network text,
route_5_ref text,
route_5_name text,
route_5_colour text,
route_6_network text,
route_6_ref text,
route_6_name text,
route_6_colour text,
class text,
subclass text,
brunnel text,
layer int,
level int,
indoor int
)
AS
$$
SELECT geometry,
BUGFIX: Fix name-based way fragmentation in transportation_name (#1295) 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.
2021-11-25 09:45:11 +00:00
tags->'name' AS name,
COALESCE(tags->'name:en', tags->'name') AS name_en,
COALESCE(tags->'name:de', tags->'name', tags->'name:en') AS name_de,
tags,
ref,
NULLIF(LENGTH(ref), 0) AS ref_length,
CASE
WHEN network IS NOT NULL
THEN network::text
WHEN length(coalesce(ref, '')) > 0
THEN 'road'
END AS network,
route_1->'network' AS route_1_network,
route_1->'ref' AS route_1_ref,
route_1->'name' AS route_1_name,
route_1->'colour' AS route_1_colour,
route_2->'network' AS route_2_network,
route_2->'ref' AS route_2_ref,
route_2->'name' AS route_2_name,
route_2->'colour' AS route_2_colour,
route_3->'network' AS route_3_network,
route_3->'ref' AS route_3_ref,
route_3->'name' AS route_3_name,
route_3->'colour' AS route_3_colour,
route_4->'network' AS route_4_network,
route_4->'ref' AS route_4_ref,
route_4->'name' AS route_4_name,
route_4->'colour' AS route_4_colour,
route_5->'network' AS route_5_network,
route_5->'ref' AS route_5_ref,
route_5->'name' AS route_5_name,
route_5->'colour' AS route_5_colour,
route_6->'network' AS route_6_network,
route_6->'ref' AS route_6_ref,
route_6->'name' AS route_6_name,
route_6->'colour' AS route_6_colour,
highway_class(highway, '', subclass) AS class,
CASE
WHEN highway IS NOT NULL AND highway_class(highway, '', subclass) = 'path'
THEN highway
ELSE subclass
END AS subclass,
NULLIF(brunnel, '') AS brunnel,
NULLIF(layer, 0) AS layer,
"level",
CASE WHEN indoor = TRUE THEN 1 END AS indoor
FROM (
-- etldoc: osm_transportation_name_linestring_gen4 -> layer_transportation_name:z6
SELECT geometry,
tags,
ref,
highway,
subclass,
brunnel,
network,
route_1,
route_2,
route_3,
route_4,
route_5,
route_6,
z_order,
NULL::int AS layer,
NULL::int AS level,
NULL::boolean AS indoor
FROM osm_transportation_name_linestring_gen4
WHERE zoom_level = 6
UNION ALL
-- etldoc: osm_transportation_name_linestring_gen3 -> layer_transportation_name:z7
SELECT geometry,
tags,
ref,
highway,
subclass,
brunnel,
network,
route_1,
route_2,
route_3,
route_4,
route_5,
route_6,
z_order,
NULL::int AS layer,
NULL::int AS level,
NULL::boolean AS indoor
FROM osm_transportation_name_linestring_gen3
WHERE ST_Length(geometry) > 20000 AND zoom_level = 7
UNION ALL
-- etldoc: osm_transportation_name_linestring_gen2 -> layer_transportation_name:z8
SELECT geometry,
tags,
ref,
highway,
subclass,
brunnel,
network,
route_1,
route_2,
route_3,
route_4,
route_5,
route_6,
z_order,
NULL::int AS layer,
NULL::int AS level,
NULL::boolean AS indoor
FROM osm_transportation_name_linestring_gen2
WHERE ST_Length(geometry) > 14000 AND zoom_level = 8
UNION ALL
-- etldoc: osm_transportation_name_linestring_gen1 -> layer_transportation_name:z9
-- etldoc: osm_transportation_name_linestring_gen1 -> layer_transportation_name:z10
-- etldoc: osm_transportation_name_linestring_gen1 -> layer_transportation_name:z11
SELECT geometry,
tags,
ref,
highway,
subclass,
brunnel,
network,
route_1,
route_2,
route_3,
route_4,
route_5,
route_6,
z_order,
NULL::int AS layer,
NULL::int AS level,
NULL::boolean AS indoor
FROM osm_transportation_name_linestring_gen1
WHERE ST_Length(geometry) > 8000 / POWER(2, zoom_level - 9) AND zoom_level BETWEEN 9 AND 11
UNION ALL
-- etldoc: osm_transportation_name_linestring -> layer_transportation_name:z12
SELECT geometry,
"tags",
ref,
highway,
subclass,
brunnel,
network,
Implement concurrent highway routes (#1152) Fixes #1128 This PR adds 6 new columns to the `transportation_name` column, named `route_1` through `route_6`. These columns contain route information for a section of roadway. The value is stored in the form **network=ref**. For example, Interstate 95 in the United States would be `US:I=95`. Thus, each `route_N` value contains enough information to render a highway shield. Since a section of road can be a part of more than one route, the `route_2`, `route_3`, etc, will contain the 2nd, 3rd, etc., concurrent routes. The technical approach was to extend the change in #1135, which added ordered concurrency indexes to the `osm_route_member` table by joining up to the the first six entries to the `osm_transportation_name_network` table. In addition, that PR provided a ranking system for concurrent highways, ordering first by `network_type` (for example, `us-interstate`, `us-state`, etc), then alphabetically by network name, and then by ref in ascending order. This ordering of concurrent route memberships is now exposed in this PR in the sequential `route_N` values, meaning that rendered concurrent highway shields will be reasonably sorted. The renderings below were generated using this branch of OpenMapTiles, as well as a separate branch of openstreetmap-americana: https://github.com/ZeLonewolf/openstreetmap-americana/tree/openmaptilers-new-features-test The rendering approach is to use the [formatted expressions](https://maplibre.org/maplibre-gl-js-docs/style-spec/expressions/) feature in mapLibre to insert images into a string of text. Blank shields are added to the sprite sheet for all possible route networks. Next, a [styleimagemissing](https://maplibre.org/maplibre-gl-js-docs/api/map/) callback is registered. As each shield ID is requested, the callback retrieves the sprite shield blank associated with the route's network, draw the `ref` text on the shield, and insert the complete shield back into the map. Of note, this approach currently results in shields which are rotated about the road rather than being viewport aligned. This issue is currently documented as maplibre/maplibre-gl-js#188. A separate repository (https://github.com/ZeLonewolf/maplibre-shield-rotation-sample) has been created as a test case to fix this rotation issue. Adding route concurrency information to OpenMapTiles would be a major step forward in achieving comprehensive highway shield renderings in a vector map! **Renderings**: ![routes_1](https://user-images.githubusercontent.com/3254090/126054350-fa7475a7-1b60-4989-bbc2-107678e6c73b.png) ![routes_2](https://user-images.githubusercontent.com/3254090/126054351-fe73bc70-d75f-4ab5-8365-0ee3c3d3eab0.png) ![routes_3](https://user-images.githubusercontent.com/3254090/126054353-a1e74c8f-df21-423c-a300-b7f1a7c9231c.png) ![routes_4](https://user-images.githubusercontent.com/3254090/126054355-6b5dcc83-c611-42b3-bb67-d4f26d789744.png)
2021-07-26 12:28:36 +00:00
route_1, route_2, route_3, route_4, route_5, route_6,
z_order,
layer,
"level",
indoor
FROM osm_transportation_name_linestring
WHERE zoom_level = 12
2024-03-20 17:07:28 +00:00
AND LineLabel(zoom_level, COALESCE(ref, tags->'name'), geometry)
AND NOT highway_is_link(highway)
AND
CASE WHEN highway_class(highway, NULL::text, NULL::text) NOT IN ('path', 'minor') THEN TRUE
WHEN highway IN ('aerialway', 'unclassified', 'residential', 'shipway') THEN TRUE
WHEN route_rank = 1 THEN TRUE END
UNION ALL
-- etldoc: osm_transportation_name_linestring -> layer_transportation_name:z13
SELECT geometry,
"tags",
ref,
highway,
subclass,
brunnel,
network,
Implement concurrent highway routes (#1152) Fixes #1128 This PR adds 6 new columns to the `transportation_name` column, named `route_1` through `route_6`. These columns contain route information for a section of roadway. The value is stored in the form **network=ref**. For example, Interstate 95 in the United States would be `US:I=95`. Thus, each `route_N` value contains enough information to render a highway shield. Since a section of road can be a part of more than one route, the `route_2`, `route_3`, etc, will contain the 2nd, 3rd, etc., concurrent routes. The technical approach was to extend the change in #1135, which added ordered concurrency indexes to the `osm_route_member` table by joining up to the the first six entries to the `osm_transportation_name_network` table. In addition, that PR provided a ranking system for concurrent highways, ordering first by `network_type` (for example, `us-interstate`, `us-state`, etc), then alphabetically by network name, and then by ref in ascending order. This ordering of concurrent route memberships is now exposed in this PR in the sequential `route_N` values, meaning that rendered concurrent highway shields will be reasonably sorted. The renderings below were generated using this branch of OpenMapTiles, as well as a separate branch of openstreetmap-americana: https://github.com/ZeLonewolf/openstreetmap-americana/tree/openmaptilers-new-features-test The rendering approach is to use the [formatted expressions](https://maplibre.org/maplibre-gl-js-docs/style-spec/expressions/) feature in mapLibre to insert images into a string of text. Blank shields are added to the sprite sheet for all possible route networks. Next, a [styleimagemissing](https://maplibre.org/maplibre-gl-js-docs/api/map/) callback is registered. As each shield ID is requested, the callback retrieves the sprite shield blank associated with the route's network, draw the `ref` text on the shield, and insert the complete shield back into the map. Of note, this approach currently results in shields which are rotated about the road rather than being viewport aligned. This issue is currently documented as maplibre/maplibre-gl-js#188. A separate repository (https://github.com/ZeLonewolf/maplibre-shield-rotation-sample) has been created as a test case to fix this rotation issue. Adding route concurrency information to OpenMapTiles would be a major step forward in achieving comprehensive highway shield renderings in a vector map! **Renderings**: ![routes_1](https://user-images.githubusercontent.com/3254090/126054350-fa7475a7-1b60-4989-bbc2-107678e6c73b.png) ![routes_2](https://user-images.githubusercontent.com/3254090/126054351-fe73bc70-d75f-4ab5-8365-0ee3c3d3eab0.png) ![routes_3](https://user-images.githubusercontent.com/3254090/126054353-a1e74c8f-df21-423c-a300-b7f1a7c9231c.png) ![routes_4](https://user-images.githubusercontent.com/3254090/126054355-6b5dcc83-c611-42b3-bb67-d4f26d789744.png)
2021-07-26 12:28:36 +00:00
route_1, route_2, route_3, route_4, route_5, route_6,
z_order,
layer,
"level",
indoor
FROM osm_transportation_name_linestring
WHERE zoom_level = 13
2024-03-20 17:07:28 +00:00
AND LineLabel(zoom_level, COALESCE(ref, tags->'name'), geometry)
AND
CASE WHEN highway <> 'path' THEN TRUE
WHEN highway = 'path' AND (
BUGFIX: Fix name-based way fragmentation in transportation_name (#1295) 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.
2021-11-25 09:45:11 +00:00
tags->'name' <> ''
OR network IS NOT NULL
OR sac_scale <> ''
OR route_rank <= 2
) THEN TRUE
END
UNION ALL
-- etldoc: osm_transportation_name_linestring -> layer_transportation_name:z14_
SELECT geometry,
"tags",
ref,
highway,
subclass,
brunnel,
network,
Implement concurrent highway routes (#1152) Fixes #1128 This PR adds 6 new columns to the `transportation_name` column, named `route_1` through `route_6`. These columns contain route information for a section of roadway. The value is stored in the form **network=ref**. For example, Interstate 95 in the United States would be `US:I=95`. Thus, each `route_N` value contains enough information to render a highway shield. Since a section of road can be a part of more than one route, the `route_2`, `route_3`, etc, will contain the 2nd, 3rd, etc., concurrent routes. The technical approach was to extend the change in #1135, which added ordered concurrency indexes to the `osm_route_member` table by joining up to the the first six entries to the `osm_transportation_name_network` table. In addition, that PR provided a ranking system for concurrent highways, ordering first by `network_type` (for example, `us-interstate`, `us-state`, etc), then alphabetically by network name, and then by ref in ascending order. This ordering of concurrent route memberships is now exposed in this PR in the sequential `route_N` values, meaning that rendered concurrent highway shields will be reasonably sorted. The renderings below were generated using this branch of OpenMapTiles, as well as a separate branch of openstreetmap-americana: https://github.com/ZeLonewolf/openstreetmap-americana/tree/openmaptilers-new-features-test The rendering approach is to use the [formatted expressions](https://maplibre.org/maplibre-gl-js-docs/style-spec/expressions/) feature in mapLibre to insert images into a string of text. Blank shields are added to the sprite sheet for all possible route networks. Next, a [styleimagemissing](https://maplibre.org/maplibre-gl-js-docs/api/map/) callback is registered. As each shield ID is requested, the callback retrieves the sprite shield blank associated with the route's network, draw the `ref` text on the shield, and insert the complete shield back into the map. Of note, this approach currently results in shields which are rotated about the road rather than being viewport aligned. This issue is currently documented as maplibre/maplibre-gl-js#188. A separate repository (https://github.com/ZeLonewolf/maplibre-shield-rotation-sample) has been created as a test case to fix this rotation issue. Adding route concurrency information to OpenMapTiles would be a major step forward in achieving comprehensive highway shield renderings in a vector map! **Renderings**: ![routes_1](https://user-images.githubusercontent.com/3254090/126054350-fa7475a7-1b60-4989-bbc2-107678e6c73b.png) ![routes_2](https://user-images.githubusercontent.com/3254090/126054351-fe73bc70-d75f-4ab5-8365-0ee3c3d3eab0.png) ![routes_3](https://user-images.githubusercontent.com/3254090/126054353-a1e74c8f-df21-423c-a300-b7f1a7c9231c.png) ![routes_4](https://user-images.githubusercontent.com/3254090/126054355-6b5dcc83-c611-42b3-bb67-d4f26d789744.png)
2021-07-26 12:28:36 +00:00
route_1, route_2, route_3, route_4, route_5, route_6,
z_order,
layer,
"level",
indoor
FROM osm_transportation_name_linestring
WHERE zoom_level >= 14
UNION ALL
-- etldoc: osm_highway_point -> layer_transportation_name:z10
SELECT
p.geometry,
p.tags,
BUGFIX: Fix name-based way fragmentation in transportation_name (#1295) 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.
2021-11-25 09:45:11 +00:00
p.ref,
(
SELECT highest_highway(l.tags->'highway')
FROM osm_highway_linestring l
WHERE ST_Intersects(p.geometry,l.geometry)
) AS class,
'junction'::text AS subclass,
NULL AS brunnel,
NULL AS network,
NULL::hstore AS route_1,
NULL::hstore AS route_2,
NULL::hstore AS route_3,
NULL::hstore AS route_4,
NULL::hstore AS route_5,
NULL::hstore AS route_6,
z_order,
layer,
NULL::int AS level,
NULL::boolean AS indoor
FROM osm_highway_point p
WHERE highway = 'motorway_junction' AND zoom_level >= 10
) AS zoom_levels
WHERE geometry && bbox
ORDER BY z_order ASC;
$$ LANGUAGE SQL STABLE
-- STRICT
PARALLEL SAFE;