Re: [mkgmap-dev] IO-problem with actual trunk
Hi Henning, okay, maybe it was an error in the update process. I see that e.g. OSM stats also had problems: http://osmstats.altogetherlost.com/index.php?item=nodes Anyway, it is obvious the code in splitter is missing a check, either in the o5m read or in the write routine (or both) :-( If you can reproduce the problem with the downloaded planet, maybe try to use --output=pbf first. Gerd Date: Fri, 22 Nov 2013 23:37:02 +0100 From: o...@aighes.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] IO-problem with actual trunk No it's a combination of an updated planet and a srtm file. I started downloading a fresh planet and will try that tomorrow. Splitting was done with latest splitter. Henning Am 22.11.2013 23:08, schrieb GerdP: Hi Henning, hmm, it seems that all files are corrupted, since osmconvert cannot read them as well without printing error messages, so I don't think the problem was caused by an IO error. I assume the files were created with latest splitter? Did you create the planet file using update procedures or download it ? If the latter is true, I should be able to reproduce it when I download latest planet. Gerd Henning Scholland wrote Here it is: http://www.aighes.de/data/1010.tar.gz Henning Am 22.11.2013 19:28, schrieb GerdP: Hi Henning, please post a link to the o5m input file. Gerd Henning Scholland wrote Hi, while generating a map of Oman I got the attached error-message (see below 1010). The map is generated out of planet.o5m. Henning ___ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev mkgmap_error.log (3K) lt;http://gis.19327.n5.nabble.com/attachment/5786885/0/mkgmap_error.loggt; -- View this message in context: http://gis.19327.n5.nabble.com/IO-problem-with-actual-trunk-tp5786885p5786888.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- View this message in context: http://gis.19327.n5.nabble.com/IO-problem-with-actual-trunk-tp5786885p5786913.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 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] IO-problem with actual trunk
Am 23.11.2013 09:36, schrieb Gerd Petermann: Hi Henning, okay, maybe it was an error in the update process. I see that e.g. OSM stats also had problems: http://osmstats.altogetherlost.com/index.php?item=nodes Anyway, it is obvious the code in splitter is missing a check, either in the o5m read or in the write routine (or both) :-( If you can reproduce the problem with the downloaded planet, maybe try to use --output=pbf first. Gerd Hi Gerd, I'm not that familiar with o5m-format, but it is possible,, that only a part of the world is corrupted? Maybe you remember, that I'm splitting all my maps at ones. And all other maps are correct. If it's not possible, I think splitter have a problem with this. Also I can update the used planet-file with osmupdate. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] IO-problem with actual trunk
Hi Henning, I'm not that familiar with o5m-format, but it is possible,, that only a part of the world is corrupted? yes, I think so. The o5m format doesn't contain checksums or so, so the read routine tends to skip unexpected data until it finds something readable. Maybe you remember, that I'm splitting all my maps at ones. And all other maps are correct. If it's not possible, I think splitter have a problem with this. okay, that implies that the Oman area contains a special case, maybe a special string. Please test: What happens if you create the Oman files with --output=pbf? If the created files are okay for osmconvert, the problem is probably in splitters o5m write routine. Gerd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] IO-problem with actual trunk
Hi Henning, I think the problem is in the splitter o5m write routine. It seems to write wrong string references for the SRTM data. Maybe I can reproduce the problem with a small test routine. Gerd Date: Sat, 23 Nov 2013 10:26:07 +0100 From: o...@aighes.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] IO-problem with actual trunk Am 23.11.2013 09:36, schrieb Gerd Petermann: Hi Henning, okay, maybe it was an error in the update process. I see that e.g. OSM stats also had problems: http://osmstats.altogetherlost.com/index.php?item=nodes Anyway, it is obvious the code in splitter is missing a check, either in the o5m read or in the write routine (or both) :-( If you can reproduce the problem with the downloaded planet, maybe try to use --output=pbf first. Gerd Hi Gerd, I'm not that familiar with o5m-format, but it is possible,, that only a part of the world is corrupted? Maybe you remember, that I'm splitting all my maps at ones. And all other maps are correct. If it's not possible, I think splitter have a problem with this. Also I can update the used planet-file with osmupdate. 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] IO-problem with actual trunk
Hi Henning, I was not able to reproduce the problem, but I found a potential error in the o5m write routine: it did not write enough reset bytes. I've changed that in r313. Please try if this helps. Gerd Date: Sat, 23 Nov 2013 10:26:07 +0100 From: o...@aighes.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] IO-problem with actual trunk Am 23.11.2013 09:36, schrieb Gerd Petermann: Hi Henning, okay, maybe it was an error in the update process. I see that e.g. OSM stats also had problems: http://osmstats.altogetherlost.com/index.php?item=nodes Anyway, it is obvious the code in splitter is missing a check, either in the o5m read or in the write routine (or both) :-( If you can reproduce the problem with the downloaded planet, maybe try to use --output=pbf first. Gerd Hi Gerd, I'm not that familiar with o5m-format, but it is possible,, that only a part of the world is corrupted? Maybe you remember, that I'm splitting all my maps at ones. And all other maps are correct. If it's not possible, I think splitter have a problem with this. Also I can update the used planet-file with osmupdate. 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] Possible solution for deformed polygons
...very interesting! I'll stay tuned... Thanks! --enrico -- View this message in context: http://gis.19327.n5.nabble.com/Possible-solution-for-deformed-polygons-tp5786064p5786945.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] Possible solution for deformed polygons
Hi Gerd, 1) merge polygons with equal types etc. like in merge-lines algo, so that e.g. buildings that share walls are combined to one polygon (without creating holes). I would expect that many buildings have address tag which would make merging not advisable. How merging would cooperate with option add-pois-to-areas? -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Possible solution for deformed polygons
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Gerd, if this merging is done after style-processing, then it should be a great improvement without complications. Otherwise only polygons should be merged if all tags are equal. Henning Am 23.11.2013 16:25, schrieb GerdP: Hi Andrzej, for address search the data is saved with the roads, not with the polygons and poi are separate points, so I don't see a problem here. I did not yet start coding, as I still try to find a better algo for the bad angles in roads. Gerd popej wrote Hi Gerd, 1) merge polygons with equal types etc. like in merge-lines algo, so that e.g. buildings that share walls are combined to one polygon (without creating holes). I would expect that many buildings have address tag which would make merging not advisable. How merging would cooperate with option add-pois-to-areas? -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- View this message in context: http://gis.19327.n5.nabble.com/Possible-solution-for-deformed-polygons-tp5786064p5786952.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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) iQEcBAEBAgAGBQJSkNa2AAoJEPFgsWC7jOeTG+EIALR1DG4mMeJ1996r8ZMJJJxX qb8r0vN5E67Iai4bURr4za2G2BGCVaukvdvjEA78V3SwTakcDGXOc/Y+oCiXgp6j dcWLE/tdeP9bsd8dM8WI9jOsoIvXZOzpun5q8H+HbWZbj5xZOVGJooDMJCNb5Gi7 L42NyLOobR1eVUztwdl4AoVrXok69UI18I5+gQKv0RacOcVvPWGPEjzxclHHDiqH 1wmJruf26VaEtXpZGGpAN0Shbzx3Vex/G8B+EX8dqOI7iN83SqBLQMBL0zXu5QWs WxBJrZX3He5uw6AlliA9sg3p8mxAfK2XElp09Rd7ZgfqNApNQmp7WfTWFwWhUjY= =TfIG -END PGP SIGNATURE- ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Possible solution for deformed polygons
Hi, yes, I plan to implement it at the same place were lines are merged, that means, one merge for each sub division. Question is whether I find a way to do it without complex calculations, else it will slow down processing too much. Gerd Henning Scholland wrote -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Gerd, if this merging is done after style-processing, then it should be a great improvement without complications. Otherwise only polygons should be merged if all tags are equal. Henning Am 23.11.2013 16:25, schrieb GerdP: Hi Andrzej, for address search the data is saved with the roads, not with the polygons and poi are separate points, so I don't see a problem here. I did not yet start coding, as I still try to find a better algo for the bad angles in roads. Gerd popej wrote Hi Gerd, 1) merge polygons with equal types etc. like in merge-lines algo, so that e.g. buildings that share walls are combined to one polygon (without creating holes). I would expect that many buildings have address tag which would make merging not advisable. How merging would cooperate with option add-pois-to-areas? -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- View this message in context: http://gis.19327.n5.nabble.com/Possible-solution-for-deformed-polygons-tp5786064p5786952.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) iQEcBAEBAgAGBQJSkNa2AAoJEPFgsWC7jOeTG+EIALR1DG4mMeJ1996r8ZMJJJxX qb8r0vN5E67Iai4bURr4za2G2BGCVaukvdvjEA78V3SwTakcDGXOc/Y+oCiXgp6j dcWLE/tdeP9bsd8dM8WI9jOsoIvXZOzpun5q8H+HbWZbj5xZOVGJooDMJCNb5Gi7 L42NyLOobR1eVUztwdl4AoVrXok69UI18I5+gQKv0RacOcVvPWGPEjzxclHHDiqH 1wmJruf26VaEtXpZGGpAN0Shbzx3Vex/G8B+EX8dqOI7iN83SqBLQMBL0zXu5QWs WxBJrZX3He5uw6AlliA9sg3p8mxAfK2XElp09Rd7ZgfqNApNQmp7WfTWFwWhUjY= =TfIG -END PGP SIGNATURE- ___ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- View this message in context: http://gis.19327.n5.nabble.com/Possible-solution-for-deformed-polygons-tp5786064p5786968.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] Possible solution for deformed polygons
Hi Andrzej, popej wrote for address search the data is saved with the roads, not with the polygons and poi are separate points, so I don't see a problem here. I'm interested if POI from polygons will be created before or after merging. Making them before merging seems better solution. Yes, POI are created much earlier (before style processing), in the style you decide what is done with the POI. The merge should happen much later. popej wrote I'd like to present house number over building area, see attached picture. House number is an attribute of building polygon. The same goes for building name. Off topic about address search: There exist better approach for point addressing, which is already used in some maps but not supported by mkgmap yet. The idea is to convert address point to a very short invisible road and then add this road to search index. This has advantage of precise location of address and also gives possibility to include house number with letters in street name. Maybe you could think about some kind of procedure, which would allow to convert poi to a line? Like an new option for mkgmap: add-lines-to-poi? Sounds interesting. I guess the algo for this is not very different from that which calculates the nearest road. Maybe WanMil knows more about this? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Possible-solution-for-deformed-polygons-tp5786064p5786983.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] IO-problem with actual trunk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Gerd, works as expected. Henning Am 23.11.2013 15:11, schrieb Gerd Petermann: Hi Henning, I was not able to reproduce the problem, but I found a potential error in the o5m write routine: it did not write enough reset bytes. I've changed that in r313. Please try if this helps. Gerd Date: Sat, 23 Nov 2013 10:26:07 +0100 From: o...@aighes.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] IO-problem with actual trunk Am 23.11.2013 09:36, schrieb Gerd Petermann: Hi Henning, okay, maybe it was an error in the update process. I see that e.g. OSM stats also had problems: http://osmstats.altogetherlost.com/index.php?item=nodes Anyway, it is obvious the code in splitter is missing a check, either in the o5m read or in the write routine (or both) :-( If you can reproduce the problem with the downloaded planet, maybe try to use --output=pbf first. Gerd Hi Gerd, I'm not that familiar with o5m-format, but it is possible,, that only a part of the world is corrupted? Maybe you remember, that I'm splitting all my maps at ones. And all other maps are correct. If it's not possible, I think splitter have a problem with this. Also I can update the used planet-file with osmupdate. 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) iQEcBAEBAgAGBQJSkSbBAAoJEPFgsWC7jOeTYnYH/Rjsy/qYyTw54lXzEarFdpj0 EBOxV53ug008pO6Bn1lv2NFochKU8WV4IVpYIxTWfQVTxc/XNvkuR1O45RpcoNki lnrvdeyKuCFyyfLqqeu5kzZ9Ed9YYufWf0IpaAnXGjvPYv0x2WAY5oLRa2A4q9Sx jVDhkQaYurBnCnTAjotYtVT7aqppi0CBRi5ZFLbHkhs/stXW5zemh5QekSZqub6a sCPUiyoixH7snTaWezQJQ5v19CBgEHlGa1Cl/KVyhNXob4LWhf9pqEoUXtIyrwL6 hP0S1rx+Ne5kkeBn2tG8no1bjZWK/nWVi3tiVZNnDwR6P25797uprkSoVvQCJFg= =0f7Q -END PGP SIGNATURE- ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] POI index issues
Hi Time to follow up on this issue from some time back as I have not found any solutions. It would be good to have the index search feature refined. Anyway here is it again. Thanks for your consideration. I have loaded my latest img made using 2800 of mkgmap and a custom style along with typ file on to a Garmin Rino 650. This unit has only ever had the OSM maps that I have created on it. The POI lookup has been causing me a few issues in the past with my 62S being much better but that might be due to it having Garmin's own Topo map loaded. I am at a loss how and what index from what img file my Garmins use. Anyway, the problem is nothing comes up when I select all POI so I went into geographical features and then water features to find a lake. No water features showed up. I then selected land features and then could find the lake that I was after. It appears that at least on the Rino 650 the POI index has issues. It the above a known problem with mkgmap or is their something wrong with my style and/or typ file? I use the following bat in Windows 7 to create the img. REM mkgmap command line REM --- java -Xmx8192m -Xms2048m -ea -jar mkgmap.jar ^ --max-jobs ^ --gmapsupp ^ --route --drive-on-left --check-roundabouts ^ --generate-sea ^ --remove-ovm-work-files ^ --add-pois-to-areas ^ --location-autofill=nearest ^ --index ^ --style-file=styles\mapnik\ ^ --description=Ent_World 20M Contours ^ --country-name=Australia --country-abbr=AU --region-name=Tasmania --region-abbr=TAS --draw-priority=25 Ent_World.osm.pbf ^ --family-name=contours --draw-priority=31 --transparent Ent_contours_20M\Ent_world*.osm.pbf ^ styles\mapnik\mapnik_play.typ Cheers Brett___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
