Re: [mkgmap-dev] Commit: r1198: Merge in the sea polygon patch from
Tomas I used your advice and built a map of SA with sea successfully. When building SA from one tile, the sea is correct with only some islands drowned, (I download Africa from geofabrik and extract southern Africa from it with splitter because geofabrik SA cuts the coastline at the country border and not at the tile border.) When I build SA from 4 tiles (Windhoek; Jhb;Durban;Capetown) the sea and land is reversed in some tiles, and correct in some. I guess some splits in the coastline made by splitter does not get merged again / correct by mkgmap? BennieD ##################################################################################### Scanned by MailMarshal - Marshal's comprehensive email content security solution. Download a free evaluation of MailMarshal at www.marshal.com #####################################################################################
Dear Bennie, can you check if - the cut coastline segments really extend to the tile borders - the bounding box of the tiles is stated correctly in the osm files? My first guess is that some part of the coastline is missing - I still have no good solution how to handle incomplete shoreline segments. If this is not the case and you can provide me a download link for the tiles, I can check what the problem is. Best wishes Christian Du Plessis, Bennie schrieb:
Tomas
I used your advice and built a map of SA with sea successfully.
When building SA from one tile, the sea is correct with only some islands drowned,
(I download Africa from geofabrik and extract southern Africa from it with splitter because geofabrik SA
cuts the coastline at the country border and not at the tile border.)
When I build SA from 4 tiles (Windhoek; Jhb;Durban;Capetown)
the sea and land is reversed in some tiles, and correct in some.
I guess some splits in the coastline made by splitter does not get merged again / correct by mkgmap?
BennieD
------------------------------------------------------------------------
Scanned by *MailMarshal* - Marshal's comprehensive email content security solution. Download a free evaluation of MailMarshal at www.marshal.com <http://www.marshal.com>
** ------------------------------------------------------------------------ ------------------------------------------------------------------------
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Since the sea polygons are being discussed... With the merge back into trunk, should I expect that the support there is identical to that on the multipolygon branch? I ask because there appear to be remaining differences. My test data is the Geofabrik Ireland extract. This is processed "correctly" (apart from the spurious lines we know about already) by the multipolygon branch but if I process it using trunk code I get a mostly flooded map. Anybody else seeing such differences? Dermot -- -------------------------------------- Iren sind menschlich
Dermot McNally schreef:
With the merge back into trunk, should I expect that the support there is identical to that on the multipolygon branch? [...] but if I process it using trunk code I get a mostly flooded map.
Anybody else seeing such differences?
Actually, I don't use the --sea-... option anymore, as there are a couple of tiles in the Netherlands flooded. This could the result of splitting (but I'm not entirely sure). It is *not* the geofabric cutout that is at fault, as one of these flooded tiles is in the centre of my map (but borders with http://osm.org/go/0E6W1PA_- so could still be a cutoff problem. I wrote about this before (17-09-09 12:12). I did not test the multipoligon branch - but I'm willing to do that; is there a rough outline of how to use svn branches here? (I'm perfectly able to compile and patch, I just never used svn branches before). So basically, for trunk, I leave the sea-polygon thing out, I'd rather not swim to Utrecht ;) V.
Dermot McNally schreef:
With the merge back into trunk, should I expect that the support there is identical to that on the multipolygon branch? [...] but if I process it using trunk code I get a mostly flooded map.
Anybody else seeing such differences?
Actually, I don't use the --sea-... option anymore, as there are a couple of tiles in the Netherlands flooded. This could the result of splitting (but I'm not entirely sure). It is *not* the geofabric cutout that is at fault, as one of these flooded tiles is in the centre of my.map >(but borders with http://osm.org/go/0E6W1PA_- so could still be a cutoff problem.
I wrote about this before (17-09-09 12:12).
I did not test the multipoligon branch - but I'm willing to do that; is there a rough outline of how to use svn branches here? (I'm perfectly able to compile and patch, I just never used svn branches before).
So basically, for trunk, I leave the sea-polygon thing out, I'd rather not swim to Utrecht ;)
V.
I brought the discusion on sea polygons back not because I'm that concerned with the sea. It's a nice to have. When I build South Africa in one tile it works very good. I build SA in one tile anyway for better routing. What is intersting is that when I build the exact same area in 4 tiles i.s.o. one, some tiles reverses the land & sea. I don't think there are broken coastlines in the original OSM data, because the sea polys are correct when using one tile. I am wondering if this might be a clue to other inter-tile problems? BTW I can not route across tile borders any more. Is any one else experiencing this, or am I blundering somewhere. I use --ignore-osm-bounds, (but I have always) would it have an effect? BennieD The opinions contained in this message are those of the sender only and do not reflect those of Sappi Limited or any of its subsidiary or associated companies. "This message, including any attachment(s), may contain information which is private, privileged or confidential and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient of this message, please notify the sender thereof and destroy/delete the message. Neither the sender nor Sappi Limited (including its subsidiaries and associated companies, jointly referred to as 'Sappi') shall incur any liability resulting directly or indirectly from accessing any of the attached files which may contain a virus or the like. Any opinions, statements, conclusions and other information contained in this message and/or its attachment(s) that do not relate or refer to the official business of Sappi Limited or any of its subsidiary or associated companies shall be regarded as neither provided nor approved by any Sappi company. Views expressed in this message or its attachment(s) may not necessarily be those of Sappi and Sappi cannot be held liable for any direct or indirect loss or injury resulting from the contents of a message and/or its attachments." Directors names A list of Sappi companies and the names of their directors can be retrieved from http://www.sappi.com/SappiWeb/Investor+info/Corporate+governance/Board+resum... ##################################################################################### Scanned by MailMarshal - Marshal's comprehensive email content security solution. Download a free evaluation of MailMarshal at www.marshal.com #####################################################################################
From: Christian Gawron can you check if - the cut coastline segments really extend to the tile borders
I am not quite sure how to confirm this, but it is cut from an area that works fine with sea poly (therefore I asume the original coastline is not broken), by splitter with default overlap. And when I view all 4 tiles together in gpsmapedit I can see no breaks at the borders. I tried to view the files in JOSM, but it is to big for JOSM.
- the bounding box of the tiles is stated correctly in the osm files? The bounds in the osm files difers slightly from the areas.list coordinates See at the bottom of this mail.
My first guess is that some part of the coastline is missing - I still have no good solution how to handle incomplete shoreline segments.
The funny thing is that I make the same area in one tile, and it works beautifully, (except for the spurious lines which I am confident you will fix shortly ;) but splitting into tiles it goes awry. Therefore I thought it might rather be a splitting / merging problem, than an originally broken coastline. I use --ignore-osm-bounds, could that mangle things? I also lately experience routing failure over tile boundaries, and trying with mkgmap 1243 my map failed to make last night. I am still trying to pinpoint the problem and differences in my own approach. If everyone else can still route over tiles, I must be doing something wrong?
If this is not the case and you can provide me a download link for the tiles, I can check what the problem is.
I don't know how- I even tried to e-mail it but it is too large (57 Mb compressed) Hints? <bounds minlat='-35.28900861740112' minlon='12.999980449676514' maxlat='-18.999996185302734' maxlon='36.00000858306885'/> # List of areas (split from GeoFabrik africa download) 010000000: -1644587,605843 to -885464,1677722# : -35.289,12.99998 to -19,36 <bounds minlat='-35.244140625' minlon='17.0947265625' maxlat='-30.849609375' maxlon='25.0048828125'/> <bounds minlat='-30.849609375' minlon='12.9638671875' maxlat='-18.984375' maxlon='25.0048828125'/> <bounds minlat='-34.453125' minlon='25.0048828125' maxlat='-28.037109375' maxlon='33.0908203125'/> <bounds minlat='-28.037109375' minlon='25.0048828125' maxlat='-18.984375' maxlon='35.9033203125'/> # List of areas (split with default overlap) 01000001: -1642496,796672 to -1437696,1165312 # ZA-Cape Town : -35.244141,17.094727 to -30.849609,25.004883 01000002: -1437696,604160 to -884736,1165312 # NA-Windhoek : -30.849609,12.963867 to -18.984375,25.004883 01000003: -1605632,1165312 to -1306624,1542144 # ZA-Durban : -34.453125,25.004883 to -28.037109,33.090820 01000004: -1306624,1165312 to -884736,1673216 # ZA-Johannesburg : -28.037109,25.004883 to -18.984375,35.903320 ##################################################################################### Scanned by MailMarshal - Marshal's comprehensive email content security solution. Download a free evaluation of MailMarshal at www.marshal.com #####################################################################################
Therefore I thought it might rather be a splitting / merging problem, than an originally broken coastline. I use --ignore-osm-bounds, could that mangle things? I also lately experience routing failure over tile boundaries, and trying with mkgmap 1243 my map failed to make last night.
I distinctly recall that you should not use --ignore-osm-bounds if you want to route between tiles. Regarding the sea polygons, I get the same problem on the Cloudmade extract of Ontario, Canada, when it is split but compiled without --ignore-osm-bounds. So this parameter is most likely the cause of your routing problems, but not your sea polygon problems. Cheers.
participants (5)
-
Christian Gawron -
Clinton Gladstone -
Dermot McNally -
Du Plessis, Bennie -
Valentijn Sessink