natural=coastline renders name along shore/coastline

[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]

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]

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

[pnorman]

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]

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]

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

[gravitystorm]

Closing in favour of other tickets