Re: [mkgmap-dev] [Patch V1]Re: Still problems with lakes
The patch works for my sweden map (vänern): Before: http://gis.19327.n5.nabble.com/file/n5732113/Bildschirmfoto_2012-10-20_um_21.13.01.png After: http://gis.19327.n5.nabble.com/file/n5732113/Bildschirmfoto_2012-10-20_um_21.33.49.png Grand ... Klaus -- View this message in context: http://gis.19327.n5.nabble.com/Still-problems-with-lakes-tp5725668p5732113.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [Patch V1]Re: Still problems with lakes
On Sun, Oct 21, toc-rox wrote: The patch works for my sweden map (vänern): Before: http://gis.19327.n5.nabble.com/file/n5732113/Bildschirmfoto_2012-10-20_um_21.13.01.png After: http://gis.19327.n5.nabble.com/file/n5732113/Bildschirmfoto_2012-10-20_um_21.33.49.png On both pictures you see some lines, where you see the background and not the polygon. Is this an artefact of the rounding issues discussed the last days here? Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] spltter software design question
Hi, I am still working on the cleanup of the patch for splitter (splitter_problem_list.patch) I got the impression that the patched code is quite messed up now regarding the naming and use of interfaces and abstract classes. I'd like to change that so that a) - MapReader defines the interface to the IO routines that read OSM data, each format like pbf, o5m, or osm(xml) requires a special MapReader implementation. Current r202 defines an empty and more or less unused interface - MapProcessor defines the interface to the routines that should process the OSM data provided by the IO routines (nodes, ways, relations, etc). - OSMWriter defines the interface to the IO routines that write OSM data, each format like pbf, o5m, or osm(xml) requires a special OSMWriter implementation. Current r202 defines this as an abstract class. - class AbstractMapReader should contain common code in (at least two) readers - class AbstractMapProcessor should contain common code in (at least two) processors - class AbstractOSMWriter should contain common code in (at least two) writers b) The NodeCollector (used with parm --legacy-mode) seems to be obsolete to me, I want to remove it c) A few other helper classes are no longer in use (e.g. IntList, IntObjMap, SparseInt2ShortMap). I'd like to move them to a folder called obsolete What do you think about this? -- View this message in context: http://gis.19327.n5.nabble.com/spltter-software-design-question-tp5732135.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [Patch V1]Re: Still problems with lakes
Hi Gerd, before adding severals boundarys and many ferry-ways in baltic sea just a question. Would it be possible to add wildcards like all ways and relation with ferry=* or all ways and relations with admin_level=2 ? How do others thing about it? Are there more ways which have typical a larger distance between nodes? Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [Patch V1]Re: Still problems with lakes
Hi Henning, I don't want to make the parser for this list too complex, but maybe I can copy some code from mkgmap. If you like, you can code some rules in the MultiTileProcessor, it contains a deactivated code in processRelation(), search for experimental code:. The more heap you can offer to splitter, and the less big your input file is, the more likely splitter can handle more (or all) relations without running out of memory. Reg. admin_level=2: That's funny, I thought it might be useful to delete all boundary=administrative relations completely and only use the precompiled bounds. Gerd Date: Sun, 21 Oct 2012 13:08:47 +0200 From: o...@aighes.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] [Patch V1]Re: Still problems with lakes Hi Gerd, before adding severals boundarys and many ferry-ways in baltic sea just a question. Would it be possible to add wildcards like all ways and relation with ferry=* or all ways and relations with admin_level=2 ? How do others thing about it? Are there more ways which have typical a larger distance between nodes? Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [Patch V1]Re: Still problems with lakes
I have tested the patch but the southern half of Lake Geneva is still dry, Multipolygon: http://www.openstreetmap.org/browse/relation/332617 areas.list: 0094: 2162688,278528 to 2183168,339968 # : 46.406250,5.976563 to 46.845703,7.294922 0554: 2142208,290816 to 2162688,339968 # : 45.966797,6.240234 to 46.406250,7.294922 1046: 2146304,258048 to 2162688,290816 # : 46.054688,5.537109 to 46.406250,6.240234 Tested on today's extract from http://download.geofabrik.de/openstreetmap/europe/alps.osm.pbf java -Xmx1400m -jar splitter-r200\splitter_patched.jar --write-kml=areas.kml --split-file=areas.list --no-trim --output=pbf --problem-file=problem_polygons.txt alps.osm.pbf ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [Patch V1]Re: Still problems with lakes
Hi Minko, Minko-2 wrote I have tested the patch but the southern half of Lake Geneva is still dry, Okay, I try to find out wether it is splitter that still writes incomplete data or is it mkgmap. Ciao, Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Still-problems-with-lakes-tp5725668p5732180.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] point number too big
I'm trying to debug an error with the following 'Lambertus' mapset: Openfietsmap Lite France 15-10-2012, temp download location: http://osm.pleiades.uni-wuppertal.de/garmin/openfietsmap_lite/15-10-2012/582f3533739247ac4a268eb4e1f91fc6/ This map is generated with mkgmap-r2337 If I send one or more tiles to the GPS, Mapsource crashes instantly: MDR_TRIM_ADDR.CXX-347-6.16.3.0 (it doesnt matter which tile I send) Other country sets don't have this issue as far as I have tested (NL, B) so there might be a few or more corrupt tiles in this France mapset. I ran mkgmap on the individual img tiles to recreate a new index, and notice that mkgmap complains several times about point number too big. What is this error and might this be the reason for the MDR_TRIM_ADDR crash? ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] point number too big
I have isolated the file which gives an error message point number too big http://mijndev.openstreetmap.nl/~ligfietser/test/63440791.zip However, this one didnt cause the problem with writing an index. So I have to search in the other tiles (but still like to know what point number too big means) ;-) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [Patch V1]Re: Still problems with lakes
Minko-2 wrote I have tested the patch but the southern half of Lake Geneva is still dry, ... java -Xmx1400m -jar splitter-r200\splitter_patched.jar --write-kml=areas.kml --split-file=areas.list --no-trim --output=pbf --problem-file=problem_polygons.txt alps.osm.pbf ... Hi Minko, you haven't specified a problem file ? E.g. something like this: java -Xmx6000M -jar /home/kto/Freizeitkarte-Entwicklung/tools/splitter/splitter-poly.jar --geonames-file=/home/kto/Freizeitkarte-Entwicklung/cities/cities15000.zip --problem-file=/home/kto/Freizeitkarte-Entwicklung/*problem_polygons.txt* --mixed --no-trim --overlap=1 --mapid=58440001 --max-nodes=60 --output=xml --output-dir=/home/kto/Freizeitkarte-Entwicklung/work/Freizeitkarte_Schweden /home/kto/Freizeitkarte-Entwicklung/source/Freizeitkarte_Schweden.o5m Regards Klaus -- View this message in context: http://gis.19327.n5.nabble.com/Still-problems-with-lakes-tp5725668p5732194.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [Patch V1]Re: Still problems with lakes
I did, Klaus: --problem-file=problem_polygons.txt I only didnt convert it to 05m format, but that shouldnt matter or does it? java -Xmx1400m -jar splitter-r200\splitter_patched.jar --write-kml=areas.kml --split-file=areas.list --no-trim --output=pbf --problem-file=problem_polygons.txt alps.osm.pbf ... Hi Minko, you haven't specified a problem file ? ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [Patch V2]Re: Still problems with lakes
Hi Minko, Minko-2 wrote I did, Klaus: --problem-file=problem_polygons.txt I only didnt convert it to 05m format, but that shouldnt matter or does it? No, that doesn't matter. I found the error, here is a new patch based on r202 (also containing the boundingBox.patch) + the new binary. Thanks for testing! splitter_problem_list_v2.patch http://gis.19327.n5.nabble.com/file/n5732197/splitter_problem_list_v2.patch splitter.jar http://gis.19327.n5.nabble.com/file/n5732197/splitter.jar Ciao, Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Still-problems-with-lakes-tp5725668p5732197.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [Patch V1]Re: Still problems with lakes
Minko-2 wrote I did, Klaus: --problem-file=problem_polygons.txt Oops - sorry - it seems I'm blind today. Regards Klaus -- View this message in context: http://gis.19327.n5.nabble.com/Still-problems-with-lakes-tp5725668p5732199.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] MDR_TRIM_ADDR.CXX error
I have detected the tile that makes the index crash. http://osm.pleiades.uni-wuppertal.de/garmin/openfietsmap_lite/15-10-2012/63440190.img If I send this tile to the GPS, Mapsource crashes instantly: MDR_TRIM_ADDR.CXX-347-6.16.3.0 Maybe someone can find the bug in this file? I have isolated the file which gives an error message point number too big http://mijndev.openstreetmap.nl/~ligfietser/test/63440791.zip However, this one didnt cause the problem with writing an index. So I have to search in the other tiles (but still like to know what point number too big means) ;-) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [Patch V1]Re: Still problems with lakes
Hi Thorsten, well, believe it or not, I did never create a map to use it, I am just trying to solve the problems ;-) Your are probably right, afaik the precompiled bounds are only used to set the admin level tags, the data cannot be accessed to draw an object. Ciao, Gerd Date: Sun, 21 Oct 2012 19:13:57 +0200 From: ku...@suse.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] [Patch V1]Re: Still problems with lakes On Sun, Oct 21, Gerd Petermann wrote: Reg. admin_level=2: That's funny, I thought it might be useful to delete all boundary=administrative relations completely and only use the precompiled bounds. You cannot use precompiled bounds to draw borders on your map, can you? -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [Patch V2]Re: Still problems with lakes
Thanks Gerd, works fine now! I only didnt convert it to 05m format, but that shouldnt matter or does it? No, that doesn't matter. I found the error, here is a new patch based on r202 (also containing the boundingBox.patch) + the new binary. Thanks for testing! splitter_problem_list_v2.patch http://gis.19327.n5.nabble.com/file/n5732197/splitter_problem_list_v2.patch splitter.jar http://gis.19327.n5.nabble.com/file/n5732197/splitter.jar Ciao, Gerd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] point number too big
Hi Minko, please post the OSM data file together with your mkgmap options. The img file does not help when searching for problems and/or error messages in the mkgmap chain. Thanks! WanMil I have isolated the file which gives an error message point number too big http://mijndev.openstreetmap.nl/~ligfietser/test/63440791.zip However, this one didnt cause the problem with writing an index. So I have to search in the other tiles (but still like to know what point number too big means) ;-) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] spltter software design question
Am 21.10.2012 12:30, schrieb GerdP: Hi, I am still working on the cleanup of the patch for splitter (splitter_problem_list.patch) I got the impression that the patched code is quite messed up now regarding the naming and use of interfaces and abstract classes. I'd like to change that so that a) - MapReader defines the interface to the IO routines that read OSM data, each format like pbf, o5m, or osm(xml) requires a special MapReader implementation. Current r202 defines an empty and more or less unused interface - MapProcessor defines the interface to the routines that should process the OSM data provided by the IO routines (nodes, ways, relations, etc). - OSMWriter defines the interface to the IO routines that write OSM data, each format like pbf, o5m, or osm(xml) requires a special OSMWriter implementation. Current r202 defines this as an abstract class. - class AbstractMapReader should contain common code in (at least two) readers - class AbstractMapProcessor should contain common code in (at least two) processors - class AbstractOSMWriter should contain common code in (at least two) writers b) The NodeCollector (used with parm --legacy-mode) seems to be obsolete to me, I want to remove it c) A few other helper classes are no longer in use (e.g. IntList, IntObjMap, SparseInt2ShortMap). I'd like to move them to a folder called obsolete What do you think about this? Hi Gerd, I don't have time to have a look into the changes. Only one hint about your design ideas: The OSMWriter is used by the mgkmap sea precompiler. So if you change that please change the mkgmap sea precompiler too. WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] spltter software design question
Hi WanMil, WanMil wrote Am 21.10.2012 12:30, schrieb GerdP: What do you think about this? I don't have time to have a look into the changes. Only one hint about your design ideas: The OSMWriter is used by the mgkmap sea precompiler. So if you change that please change the mkgmap sea precompiler too. WanMil Good that you tell me, I did not see that before. I'll have to find out how to build and sea precompiler, but it should not be a big problem. Ciao, Gerd -- View this message in context: http://gis.19327.n5.nabble.com/spltter-software-design-question-tp5732135p5732228.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] point number too big
Thanks Wanmil, I have noticed that changing my styles very slightly, the tile won't crash anymore. So there is a very small bug in my style file, I have to investigate some more where exactly. BTW I also noticed I still use location-autofill: bounds,is-in,nearest in combination with bounds: bounds_20120916.zip I guess I should have used location-autofill: is-in,nearest ? please post the OSM data file together with your mkgmap options. The img file does not help when searching for problems and/or error messages in the mkgmap chain. Thanks! WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
