Wykres commitów

3 Commity (5e51627895b685b3365622759855f618099b3533)

Autor SHA1 Wiadomość Data
Tomas Pohanka 73dcd23497
Run get_basic_name after osml10n_street_abbrev_* (#1326)
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

![seattle_fix](https://user-images.githubusercontent.com/5182210/145085141-7857e97e-9b83-4467-bb98-84cc4a2e0623.png)
2021-12-08 08:20:15 +01:00
Tomas Pohanka 44ae83718c
Remove `STRICT` statement (#1320)
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
2021-12-07 17:59:04 +01:00
Brian Sperlongano ec74480414
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 10:45:11 +01:00