Last week I generated a routable map for South Wales which does everything you'd expect concerning routing just fine, but suffers the well-known "flooding" problem. Symptoms are a bit odd - it's not as if the flooding merely follows the coastline on the wrong side or anything. Just south and east of Swansea University for instance is a point where the sea seems to "turn inside out" and to the east (for a while) things are OK, but to the west the sea starts to grow outwards over the land. At the "turn inside out" point, the sea to the east has contracted to a point, and to the west the sea spreads from that point (on the land). The point itself looks like two sea triangles touching at their shared apexes. (This is viewing it on a Garmin Streetpilot, no idea if it looks like that on MapSource or anything). Another oddity is that on the west, the incorrectly spreading sea almost seems to be following a false coast slightly inshore of the real one for a short while. Then it floods everywhere. I can put up the original .pbf files, tile .pbf files and the eventual .img file for this situation if anyone is interested. Steve
You can try the following: Download the European coastline file from [1] with the same time stamp as your input pbf and pass it to mkgmap via the --coastlinefile option. If this fixes the flooding, you are suffering from the same problem that I keep running into - the coastline fails to reach some of the tile boundaries. - Bartosz [1] http://fabianowski.eu/osm/coastlines/
On 2011-10-10 13:50, Bartosz Fabianowski wrote:
You can try the following:
Download the European coastline file from [1] with the same time stamp as your input pbf and pass it to mkgmap via the --coastlinefile option. If this fixes the flooding, you are suffering from the same problem that I keep running into - the coastline fails to reach some of the tile boundaries.
- Bartosz
Thank you Bartosz. So I loaded europe-111004, but I got the following very strange message: Warning: using default sort SEVERE (CoastlineFileLoader): ./coastlines_europe-111004.osm.pbf: Coastline file not found. SEVERE (LocationHook): ./coastlines_europe-111004.osm.pbf: Disable LocationHook because boundary directory does not exist. Dir: bounds SEVERE (LocationHook): 63240001.osm.pbf: Disable LocationHook because boundary directory does not exist. Dir: bounds SEVERE (LocationHook): 63240002.osm.pbf: Disable LocationHook because boundary directory does not exist. Dir: bounds SEVERE (LocationHook): 63240001.osm.pbf: Disable LocationHook because boundary directory does not exist. Dir: bounds SEVERE (LocationHook): 63240002.osm.pbf: Disable LocationHook because boundary directory does not exist. Dir: bounds Warning: using default sort bash-4.1$ The result of this is that I get no sea at all! Hey - at least the flooding has gone! :-) I have no idea why mkgmap makes the claim "coastlines_europe-111004.osm.pbf: Coastline file not found." The file is most certainly there. I have tried it as "./coastlines_europe-111004.osm.pbf" and as just plain vanilla "coastlines_europe-111004.osm.pbf". Same problem both ways. This was with mkgmap r2045. I think I was getting the "Disable LocationHook ...." error message originally, i.e. without the --coastlinefile param. Steve
How did you pass the file to mkgmap? If the file is in the current directory, the parameter should be: --coastlinefile=coastlines_europe-111004.osm.pbf - Bartosz
Replying to myself, I think I see the problem now. You are specifying paths relative to the current working directory while mkgmap searches relative to its installation directory. Try specifying the coastline file and the boundary directors as absolute paths. - Bartosz
On 10/10/11 19:33, Bartosz Fabianowski wrote:
Replying to myself, I think I see the problem now. You are specifying paths relative to the current working directory while mkgmap searches relative to its installation directory. Try specifying the coastline file and the boundary directors as absolute paths.
I also left the "=" sign off! But the error message seemed to know what filename that I had specified, it just couldn't find it. I was trying to remove the chance of "looking in the wrong directory" by specifying "./" at the start of the name, but I've since realised that that wouldn't work! I'll chase this in a couple of days - I'm out of the office and off my machine until then. Thanks anyway. Steve
On 2011-10-10 19:33, Bartosz Fabianowski wrote:
Replying to myself, I think I see the problem now. You are specifying paths relative to the current working directory while mkgmap searches relative to its installation directory. Try specifying the coastline file and the boundary directors as absolute paths.
No - the problem was that I'd forgotten the '=' in the command-line syntax. Correct: --coastlinefile=coastlines_europe-111004.osm.pbf What I'd entered: --coastlinefile coastlines_europe-111004.osm.pbf It might be a worthwhile improvement for mkgmap to notice dud syntax like that and either accept the form without the '=' sign, or to put up an error message. As it is, it *seems* to realise that the coastline file is as I'd flagged it, but then reports that it can't read such a file. Confusing. Steve P.S: I can now confirm that Bartosz's fix (specifying a separate coastline file) appears to have completely fixed my flooding issues. Thank you Bartosz. Hopefully my experiences will help the coastline/flooding/tiles people get more of a grip on what's causing this problem. As I said last time, if anyone wants my files for investigations, I'll keep them for a while - just ask me and I'll send them.
As it is, it *seems* to realise that the coastline file is as I'd flagged it, but then reports that it can't read such a file. Confusing.
That is rather silly behavior indeed :).
P.S: I can now confirm that Bartosz's fix (specifying a separate coastline file) appears to have completely fixed my flooding issues.
I am quite convinced my analysis of the problem is correct. I know what is going wrong. And the only way to fix it that I can see is to use coastlines based on a larger extract that the one you are processing into a map. Hence, European coastlines when generating a map for the EU are not really a hack or a workaround. They are the correct solution. - Bartosz
On 2011-10-13 12:07, Bartosz Fabianowski wrote:
As it is, it *seems* to realise that the coastline file is as I'd flagged it, but then reports that it can't read such a file. Confusing.
That is rather silly behavior indeed :). Well, hopefully one of the gurus will drop in a fix sometime. If it got me, it'll certainly get someone else. No point in having the list continually jammed with people asking what's the matter!
P.S: I can now confirm that Bartosz's fix (specifying a separate coastline file) appears to have completely fixed my flooding issues.
I am quite convinced my analysis of the problem is correct. I know what is going wrong. And the only way to fix it that I can see is to use coastlines based on a larger extract that the one you are processing into a map. Hence, European coastlines when generating a map for the EU are not really a hack or a workaround. They are the correct solution.
Hmm - well I agree with you Bartosz that your analysis is correct. And the workaround is a good one, but quite honestly, it ought to be possible to handle coastlines directly. As I see it, the coastline problem (and a possible similar issue over other monster polygons like country boundaries) are the same. I did post about this before, but possibly we handle polygons (and polygon splitting) in too naiive a fashion. I would argue that whenever a splitter works on a map, it must keep any polygons complete in the output file: but to reduce all the points outside the tile's region-of-interest to a simple set of lines that skirt the boundary of the tile but located infinitesimally outside the region-of-interest, (possibly marked up as "invisible"), but preserving the closed nature of the polygon. So for instance, with my map of Wales, the splitter that generated "Wales" from the planet file would notice that the UK's coastline runs off the eastern side of the tile at the southern border of Gwent near the Second Severn Crossing (a bridge over the Severn Estuary into England). The splitter would follow the coastline right around the UK, noticing that it re-enters the "Wales" tile at the River Dee near Chester in the North East. So the splitter would replace all that UK coastline with a single (invisible) line joining the Severn Estuary in the south-east with the River Dee Estuary in the north-east, running just outside the eastern side of the "Wales" tile. That way, of someone took the Wales tile, and split it again to isolate just (say) the south west corner of Wales, then the coastline follower could easily repeat the same trick, as the invisible line alone Wales's eastern border maintains the continuity. It would be the same issue with country boundaries, city boundaries and other such things that might get chopped by a splitter. Notice also that a "stitcher" would be able to use this information to join two adjacent tiles and correctly maintain the polygon continuity. Steve **
Following the coastline to check whether it enters the current tile again will work in Great Britain but may fail in continental Europe. The Geofabrik Europe extract does not have a closed coastline after all. That would have to go all around Asia and back. So yes, following the coastline out of the tile somehow is a good idea. But no, it is not as simple as following it until it enters the tile again :(. - Bartosz
On 2011-10-13 14:07, Bartosz Fabianowski wrote:
Following the coastline to check whether it enters the current tile again will work in Great Britain but may fail in continental Europe. The Geofabrik Europe extract does not have a closed coastline after all. That would have to go all around Asia and back.
That's right! What, you mean it doesn't go round Asia?? :-( Notice that once you've done the miserable tour of Asia once, then it's OK to split the resulting "Europe" tile to get a tile for just "Poland" (say) because the coastline to the east of Europe's area (i.e. around Asia) would by now have simplified to just a couple of straight (invisible, out-of-bounds) lines.
So yes, following the coastline out of the tile somehow is a good idea. But no, it is not as simple as following it until it enters the tile again :(.
- Bartosz
Hmm - I don't know about that. Maybe with the data the way it is now, but I argue that we've got the data wrong if so. Steve
Notice that once you've done the miserable tour of Asia once, then it's OK to split the resulting "Europe" tile
Correct. So your idea would work but only if the extracts you begin with have coastlines generated in the same way, by following the parts that extend outside the tile boundaries. Right now, the extracts you get from Geofabrik have coastlines ending abruptly at their boundaries. - Bartosz
What I'd entered: --coastlinefile coastlines_europe-111004.osm.pbf
It might be a worthwhile improvement for mkgmap to notice dud syntax like that and either accept the form without the '=' sign, or to put up an error message. As it is, it *seems* to realise that the coastline file is as I'd flagged it, but then reports that it can't read such a file. Confusing.
The message is confusing, granted, but all that is happening is that coastlines_europe-111004.osm.pbf is being treated as a map to compile. The coastline file is the empty string because no argument was given. So when it says: coastlines_europe-111004.osm.pbf: Coastline file not found It means while processing the map 'coastlines_europe-111004.osm.pbf', the coastline file '' was not found. ..Steve
On Mon, Oct 10, 2011 at 11:44:07AM +0100, Steve Hosgood wrote:
Last week I generated a routable map for South Wales which does everything you'd expect concerning routing just fine, but suffers the well-known "flooding" problem.
Coincidentally, someone reported a flooding problem in Finland as well. I had not paid attention to it, because mkgmap did not complain. It turned out that the reason was that almost a month ago, someone had added an island to a natural=water lake not by adding it as a role=inner member to the multipolygon relation, but by tagging it as natural=coastline. Because this was the only natural=coastline in the map tile, everything was flooded with sea water. I was wondering if generate-sea could complain when a natural=coastline (multi)polygon overlaps a natural=water (multi)polygon. I do understand that it might not be too useful to complain about other cases of overlapping areas, but I would guess that there is no valid case of having lakes in sea areas. Best regards, Marko PS: Did you try to enable logging and grepping the log for coastline messages? You can get my logging.properties at http://www.polkupyoraily.net/osm/. Invoke mkgmap like this: java -Dlog.config=logging.properties ... -jar mkgmap.jar ... grep -i coast mkgmap.log.0
On 11/10/11 06:09, Marko Mäkelä wrote:
I was wondering if generate-sea could complain when a natural=coastline (multi)polygon overlaps a natural=water (multi)polygon. I do understand that it might not be too useful to complain about other cases of overlapping areas, but I would guess that there is no valid case of having lakes in sea areas.
Best regards,
Marko
For that matter, closed areas with "building=yes" shouldn't appear underwater, indeed, neither should roads! I'd say there were many opportunities to auto-test for dud sea polygons.
PS: Did you try to enable logging and grepping the log for coastline messages? You can get my logging.properties at http://www.polkupyoraily.net/osm/. Invoke mkgmap like this: java -Dlog.config=logging.properties ... -jar mkgmap.jar ... grep -i coast mkgmap.log.0
I'll try that when I'm back in the office. Thanks Steve
participants (4)
-
Bartosz Fabianowski -
Marko Mäkelä -
Steve Hosgood -
Steve Ratcliffe