natural=coastline renders name along shore/coastline #38

Closed
skorasaurus opened this Issue Feb 6, 2013 · 8 comments

Projects

None yet

3 participants

@skorasaurus

On z15+, name of a lake (which, because it's very large, is tagged as natural=coastline) is displayed along its edge, as shown in this image instead of being within the body of water.

Here it is on osm

This may be the result of using different coastline files being used in osm-carto and on the main mapnik server.

@pnorman
Collaborator
pnorman commented Apr 7, 2013

Likely not a carto port issue, but the yevaud database having fewer ways (coastline ways are normally dropped)

http://www.openstreetmap.org/browse/relation/1205139 may be the offending relation. That relation seems to duplicate geodata.

@skorasaurus

@pnorman So, what then needs to be done to fix this ? Will this problem also occur when osm-carto is used as the stylesheet on osm.org instead of the mapnik.xml ?

@pnorman
Collaborator
pnorman commented Apr 13, 2013

the best solution seems to be to delete relation 1205139 as I don't see that the carto rendering is wrong.

@pnorman
Collaborator
pnorman commented Apr 14, 2013

The issue appears to be more complex than I first thought.

The offending item in the DB is in the planet_osm_polygon table with

  osm_id  |   name    | natural
----------+-----------+---------
 -1205150 | Lake Erie | water

In errol's DB it is a ST_Polygon and in @skorasaurus DB it is a ST_MultiPolygon. Both report true for ST_IsValid.

This MP may of not been fully in the extract he used.

It seems to me there are three issues

  1. A hideously large multipolygon duplicating natural=coastline

  2. Potentially bad handling of partial MPs by osm2pgsql

  3. Whatever is causing this ST_MultiPolygon to be rendered as a line rather than an area.

The EWKT for the ST_MultiPolygon from skorasaurus' DB is

SRID=900913;MULTIPOLYGON(((-9096280.27 5087544.79,-9096265.11 5087556.45,
-9096263.08 5087553.58,-9096048.92 5087721.72,-9096042.25 5087731.68,
-9096037.45 5087742.77,-9095515.17 5088136.26,-9095503.28 5088142.12,
-9095497.37 5088138.94,-9095449.65 5088172.11,-9095372.38 5088231.66,
-9095348.75 5088254.38,-9095296.02 5088301.19,-9095164.35 5088398.19,
-9094780.13 5088689.1,-9094780.52 5088696.43,-9094783.11 5088703.27,
-9094168.84 5089168.54,-9094162.3 5089169,-9094151.51 5089169.57,
-9093117.26 5089948.19,-9093117.46 5089960.53,-9092764.58 5090231.72,
-9092697.34 5090275.68,-9092325.49 5090562.73,-9092610 5090318.22,
-9093113.5 5089938.83,-9094154.06 5089152.5,-9094748.49 5088699.24,
-9094743.73 5088693.79,-9094763.18 5088679.34,-9094768.04 5088683.93,
-9095199.21 5088361.65,-9095284.2 5088293.01,-9095345.56 5088238.02,
-9096048.97 5087702.86,-9096256.41 5087546.43,-9096254.39 5087542.86,
-9096270.15 5087530.26,-9096280.27 5087544.79)),

((-9098054.11 5085796.65,-9098052.7 5085800.12,-9098050.18 5085800.98,
-9098020.15 5085787.99,-9098014.27 5085790.17,-9098008.05 5085791.24,
-9097977.37 5085804.49,-9097847.2 5085873.4,-9097821.16 5085888.93,
-9097817.99 5086338.6,-9097823.89 5086344.32,-9097828.26 5086353.62,
-9097828.55 5086378.65,-9097822.43 5086388.83,-9097812.25 5086398.14,
-9096769.56 5087183.58,-9096757.3 5087187,-9096557.39 5087337.56,
-9096548.68 5087324.64,-9097804.36 5086377.29,-9097809.51 5085849.3,
-9097821.64 5085849.47,-9097821.29 5085876.9,-9097844.02 5085866.09,
-9097972.25 5085798.29,-9098007.26 5085782.03,-9098015.23 5085780.85,
-9098023.61 5085779.17,-9098053.99 5085793.71,-9098054.11 5085796.65)),

((-9088663.81 5091949.92,-9088661.18 5091952.44,-9088657.72 5091952.65,
-9088651.08 5091947.77,-9088644.03 5091939.19,-9088617.65 5091901.54,
-9088542.33 5091803.93,-9088536.7 5091799.06,-9088530.55 5091798.04,
-9088522.6 5091800.86,-9088407.48 5091886.95,-9088404.13 5091891.04,
-9088402.76 5091895.54,-9088402.87 5091902.16,-9088407.16 5091918.1,
-9088404.75 5091936.99,-9088397.61 5091953.99,-9088387.55 5091970.14,
-9088374.01 5091983.36,-9088359.95 5091994.49,-9088357.33 5091994.49,
-9088355.77 5091992.76,-9088355.77 5091988.66,-9088370.12 5091977.38,
-9088382.42 5091964.33,-9088391.38 5091950.5,-9088397.01 5091934.09,
-9088398.55 5091919.23,-9088394.52 5091908.29,-9088332.4 5091824.07,
-9088486.42 5091709.75,-9088635.96 5091904.76,-9088652.92 5091931.98,
-9088663.5 5091944.78,-9088663.81 5091949.92)))

(reformatted with whitespace)

The EWKT from errol's DB is 1.7 MB.

@skorasaurus

For what it's worth, this problem isn't on @iandees '
US extract (although last I heard, he hadn't updated the osm-carto code since early January).
http://bl.ocks.org/tmcw/raw/4271706/#16.00/41.4918/-81.7376

@gravitystorm
Owner

So by the sounds of it, there's no problem with this on the main servers, since full planets lead to (multi-)polygons in the database. Am I correct?

In any case, the underlying cause is #1 which is causing the unwarranted / unwanted labelling in the first place, regardless of any unexpected output from osm2pgsql.

@pnorman
Collaborator
pnorman commented Apr 16, 2013

Would #1 label area features as well as linear features? These are in the DB as area features

@gravitystorm
Owner

Closing in favour of other tickets

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment