|
I'm currently using Tilemill on windows for designing maps. I noticed that there was a problem with the water layer for a particular city (Montreal). For example, some small islands of this city, like St-Helen, are completely covered with water. While other area came out as land instead of water. Is this a known problem ? Do I need some special shapefile or something to render the map ? 2 screenshots: *Picture #1 : (1) The island is covered with water. (2) This area should have been covered with water.
Picture #2 : I commented the line: polygon-fill: @water; so it is disabled (see red square #2). The island look normal now. It looks like the water layer bypass the others. It still doesn't explain why there is no water fill in the #2 red square in picture #1
Any help would be greatly appreciated! Ty in advance! |
|
There are a couple of possibilities - one is that the style you're using is getting confused by the riverbank (the relevant relation I think is this one). The other is that someone that relation is somehow broken in your data. I wouldn't expect that to be the case, since that relation is fully within Quebec as defined at Geofabrik, assuming you didn't cut Quebec down any more before importing. Another possibility is how Tilemill is accessing the data. You're using Tilemill on Windows - is that using an osm2pgsql database to render from, or are you doing something else? If it is a database, what are you using to import the data? If not, how is Tilemill accessing it? In order to find out which is likely to be the problem, the first thing I'd do is to see if other similiar riverbank relations are rendered OK? 1
For info, I've just downloaded a Montreal metro extract from Mapzen, loaded it using osm2pgsql and had a look at it in OSMBright in TileMill. The water displays as water, and the Ile Ste Helene as land. The OSMBright and TileMill versions are from around 2013, but I suspect that neither have changed much.
(10 Dec '16, 13:55)
SomeoneElse ♦
|
|
I did two tests from what you mentionned. First, I tried one specific area (ID : 156816898) from the link you posted and I got the same problem. The island was also covered with water and St-Lawrence river was "land-filled". (sry no picture) Then I did another test with Quebec city and the result was exactly like as expected.
On the picture, you can see that the island on the top right is coming out correctly. Like you said, I’m supposing it is the style that get confused by the riverbank. But I don't know why the result is different for Montreal. To answer your questions, I'm using osm2pgsql (PostgreSQL with PostGIS) for importing data. I installed everything from the following procedure. Do you think the problem might come from openstreetmap carto ? I also want to thank you for your elaborate answer. It's helping me and I’m feeling closer to a solution. Out of interest, where did you get the data from? I'm wondering if whatever process was used could have chopped off part of the multipolygon. Also I don't quite understand "Do you think the problem might come from openstreetmap carto" - it looks like you're using OSM Bright as a style not OSM Carto?
(10 Dec '16, 13:13)
SomeoneElse ♦
I think I got confused.. I was thinking about the openstreetmap carto (or OSMBright)because I thought that maybe some tags were missing in the style (like Wetitpig0 proposed)
(10 Dec '16, 20:51)
DanielQc
|
|
Problem should be fixed. Whenever you get water-filled islands, most probably it is because there are no tags about whether it is an island or not. If that is the case, choose the area and tag it with "natural=coastline" & "place=island". |
|
I just downloaded the Mapzen extract and it worked. I’m happy :-) You were right SomeoneElse, it’s probably the process of extracting the data that caused my problem. It's still curious... I was using quebec-latest.osm from Geofabrik. Here, the osmosis command line that I was using for extracting a smaller part from the quebec-latest map: bzcat quebec-latest.osm.bz2 | osmosis --read-xml enableDateParsing=no file=- --bounding-box top=45.993 left=-74.312 bottom=45.228 right=-72.812 --write-xml file=- | bzip2 > mtl.osm.bz2 I think it might be the command line.. (or the coordinates ?) 1
I'm guessing that you'd need to use both the "complete" options and also "cascading" option in osmosis as per: https://wiki.openstreetmap.org/wiki/Osmosis/Detailed_Usage_0.41
(11 Dec '16, 16:05)
SomeoneElse ♦
1
Tyvm.. you've found it! This command line did the trick! bzcat quebec-latest.osm.bz2 | osmosis --read-xml enableDateParsing=no file=- --bounding-box top=45.993 left=-74.312 bottom=45.228 right=-72.812 completeRelations=yes cascadingRelations=yes --write-xml file=- | bzip2 > mtl.osm.bz2
(13 Dec '16, 03:52)
DanielQc
Well, the "trick" actually does not solve the problem. If your request scripts are properly constructed, something is still wrong in the sw involved.
(13 Dec '16, 11:13)
sanser
@sanser - I'm sure that pull requests at https://github.com/openstreetmap/osmosis would be welcomed :) Personally I think that the options that they're offering are more than adequate.
(13 Dec '16, 11:21)
SomeoneElse ♦
It dit the trick for my needs.. I understand from your post that the first command line should have worked. In fact, It worked properly with JOSM. The problem was only with Tilemill (inverted colors). By adding those 2 additional arguments I got at least the expected result.
(14 Dec '16, 04:29)
DanielQc
|
I'd also like to understand the reason behind this behavior. Why it's happening in the first place ?
I used the most recent map for this area on geofabrik. I confirm you that it's not from the map itself because when I imported it in JOSM, everything was correct. So it means, it must come from tilemill (and not from my map's extract.)
I also googled how to manually change the color for a specific area and I found nothing.. This workaround proposed could do the job. I'm not an expert and maybe it's something very simple that I missed.
Feel free to tell me if i'm not addressing my demand in the right forum.
ty again