2021-11-11 07:27:01 +00:00
|
|
|
<?xml version='1.0' encoding='UTF-8'?>
|
|
|
|
|
<osmChange version="0.6" generator="Manual" timestamp="2020-01-02T00:00:00Z">
|
|
|
|
|
<!--
|
|
|
|
|
Test 500: Highways
|
|
|
|
|
Change tags
|
|
|
|
|
-->
|
|
|
|
|
<modify>
|
2021-11-26 06:55:20 +00:00
|
|
|
<way id="5002" version="1" timestamp="2019-01-01T00:00:00Z" visible="true">
|
|
|
|
|
<nd ref="500021" />
|
|
|
|
|
<nd ref="500022" />
|
|
|
|
|
<tag k="highway" v="primary"/>
|
|
|
|
|
<tag k="expressway" v="yes"/>
|
|
|
|
|
<tag k="name" v="OpenMapTiles Primary"/>
|
|
|
|
|
</way>
|
2021-11-11 07:27:01 +00:00
|
|
|
<!-- Change 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
|
|
|
<way id="5003" version="2" timestamp="2020-01-02T00:00:00Z" visible="true">
|
2021-11-11 07:27:01 +00:00
|
|
|
<nd ref="500031" />
|
|
|
|
|
<nd ref="500032" />
|
|
|
|
|
<tag k="highway" v="secondary"/>
|
|
|
|
|
<tag k="name" v="OpenMapTiles Secondary Updated"/>
|
|
|
|
|
<tag k="tunnel" v="yes"/>
|
|
|
|
|
<tag k="oneway" v="no"/>
|
|
|
|
|
<tag k="toll" v="no"/>
|
|
|
|
|
<tag k="layer" v="-1"/>
|
|
|
|
|
<tag k="bicycle" v="yes"/>
|
|
|
|
|
<tag k="horse" v="yes"/>
|
|
|
|
|
<tag k="foot" v="yes"/>
|
|
|
|
|
</way>
|
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
|
|
|
|
|
|
|
|
<!-- Remove toll to make way match adjoining ways -->
|
|
|
|
|
<way id="5010" version="2" timestamp="2019-01-01T00:00:00Z" visible="true">
|
|
|
|
|
<nd ref="500101" />
|
|
|
|
|
<nd ref="500102" />
|
|
|
|
|
<tag k="highway" v="secondary"/>
|
|
|
|
|
<tag k="name" v="OpenMapTiles Secondary 3"/>
|
|
|
|
|
</way>
|
|
|
|
|
<way id="5011" version="2" timestamp="2020-01-02T00:00:00Z" visible="true">
|
|
|
|
|
<nd ref="500102" />
|
|
|
|
|
<nd ref="500111" />
|
|
|
|
|
<tag k="highway" v="secondary"/>
|
|
|
|
|
<tag k="name" v="OpenMapTiles Secondary 3"/>
|
|
|
|
|
</way>
|
2021-11-11 07:27:01 +00:00
|
|
|
</modify>
|
|
|
|
|
</osmChange>
|