Re: [mkgmap-dev] IO-problem with actual trunk
Hi Henning, I still don't understand why this change is important for mkgmap, maybe I did not fix the real problem. It would be great if you could reproduce it again with r312 and --output=o5m . The problem was e.g. in file 10100011.o5m. Next, execute splitter r312(or r311) with --output=pbf and post a link to both files. Gerd > Date: Sat, 23 Nov 2013 23:05:54 +0100 > From: o...@aighes.de > To: mkgmap-dev@lists.mkgmap.org.uk > Subject: 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 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
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?
So instead of using Garmins housenumber search you want to add a small
road for each POI named with "${streetname} ${housenumber}'?
Technically this sounds quite easy to implement.
Some questions about that:
* Wouldn't that blow up the index size?
* Must each invisible road be connected to the rest of the road network?
Otherwise I expect that Garmin is not able to route to the housenumbered
streets and we get thousands of routing islands?
* mkgmap would have to modify/create a TYP file with one invisible road
type. Should this be processed by mkgmap or is that a task of the map
generator to ensure that the additional road type is invisible?
WanMil
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] POI index issues
Hi Brett, an issue with the index on a Garmin device is that it requires specific codes for specific items. For a comparison of Garmin models and the use/appearance of codes, see http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/POI_Types - In most cases, the meaning is the same for different models. In your command, you use --style-file=styles\mapnik\ ^ i.e. a relative path to the style, and a final backslash. Are you sure that the "correct" style was used (e.g. when you inspect your map with QLandkarte)? I use absolute path, without a final backslash, but that might be irrelevant. It is also my impression that Garmin uses all maps (even those which were switched off) when a POI search is performed - try to remove them as much as possible (I change the extension from *.IMG to *.IM) - I haven't tried that with the base map yet... Regards, Bernhard Am 24.11.2013 00:51, schrieb Brett Russell: 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
Re: [mkgmap-dev] POI index issues
On Sun, Nov 24, Bernhard Hiller wrote: > It is also my impression that Garmin uses all maps (even those which were > switched off) when a POI search is performed Correct, Garmin uses always all maps, even if deaktivated. And depending on the firmware, it ignores the index and reads the POI directly from the img tiles. You can see that very nice if you compare the POIs of the same map on a 60CSx and a 62s. The 60CSx is twice faster and only shows POIs from the index, the 62s shows all POIs, even the ones not in the index. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base 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
Re: [mkgmap-dev] TYP-file can't be written
On 23/11/13 22:12, Henning Scholland wrote: In the header of my txt-TYP-source I have written CP1252. Converting this to CP1250 and CP1254 is done without problems. So I don't understand, why it's a problem for CP1251 and CP1256. Any guesses? I will need a few more details if you think there is a bug and you think that the labels could be written in CP1251 and 56. But in general there is no transliteration, so the characters you use must be in the target character set. cp1250 and cp1254 share many of the common characters from cp1252 that you are likely to be using and so might work, whereas 1251 and 1256 are very different and may not contain the characters you are using. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] TYP-file can't be written
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Steve, in the end of August it worked without any problems. I've just read here that something was changed with TYP-files and code-page. My TYP-file you'll find here: https://github.com/aighes/RadReiseKarte/blob/master/resources/rrk_typ.txt It's containing ö,ü,ä and ß. Henning Am 24.11.2013 15:01, schrieb Steve Ratcliffe: > On 23/11/13 22:12, Henning Scholland wrote: >> In the header of my txt-TYP-source I have written CP1252. >> Converting this to CP1250 and CP1254 is done without problems. So >> I don't understand, why it's a problem for CP1251 and CP1256. Any >> guesses? > > I will need a few more details if you think there is a bug and you > think that the labels could be written in CP1251 and 56. > > But in general there is no transliteration, so the characters you > use must be in the target character set. > > cp1250 and cp1254 share many of the common characters from cp1252 > that you are likely to be using and so might work, whereas 1251 and > 1256 are very different and may not contain the characters you are > using. > > ..Steve > > ___ 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) iQEcBAEBAgAGBQJSkg7qAAoJEPFgsWC7jOeTCDoH/RY05Dukbx2/JCLCPpg57Zph wReqNpeJPTnd5doboxmIOa6NJGtlS7AkMKA/2pmM6Rl5CbFcYQQQ9ZEl3eZ5uWLh pKm33R3yGZE6xGvbX3BKnPQ1Map2o79chzwNj6pgu8a/admXtm/z1umyuRJu5jvz C7V5606ffLOxp0/OH37eZYdUoUVgeT2iry8Vmm9E3Skr+hNTi08QZPRA6t3w++fz U/W9NWc9EEU7foWiCoyWZtI5wprUI6CYbnXk699SEjzMhUvyyxPtxjfC2E9pmFZd 36L99tLUPEdOo8TyEFQt9Xe8yNMnzyUyqmbWetUQDihYLvMF0oy0XyOS7ACx3iw= =yB0C -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] IO-problem with actual trunk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Gerd Here it is: http://www.aighes.de/data/mkgmap.zip Henning Am 24.11.2013 09:02, schrieb Gerd Petermann: > Hi Henning, > > I still don't understand why this change is important for mkgmap, > maybe I did not fix the real problem. It would be great if you > could reproduce it again with r312 and --output=o5m . The problem > was e.g. in file 10100011.o5m. Next, execute splitter r312(or r311) > with --output=pbf and post a link to both files. > > Gerd > >> Date: Sat, 23 Nov 2013 23:05:54 +0100 From: o...@aighes.de To: >> mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] >> IO-problem with actual trunk >> > 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 >> >> ___ 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) iQEcBAEBAgAGBQJSkisgAAoJEPFgsWC7jOeT90UH/i8z82v8ysHXuw8iOK4+OrWk FMMz7lWY/E6ngsijFUijWxflA8NZDkavwuc08QSyg+7x6y+cSa53u31hQYTzIYhc FZGz47NRSWc/pkSC9I2BNu6uFdRDjOQgPP/1HKVzHfcwXvTNn4C4cr1CXdOMGOD3 pKOjhSP9N1y1htGGCyg5ujTcLmQjRlbjzbL3cvg0TYqDYjYucnzxTUzRCopMn3cL f6Ew/QcBIc/wF3pHkl9oEaKoLb60AXl/4o1apJrZF12mxNFpM/ffyI8nTn8AAJZc fHs91VS4QrQkWppX1OidPhVpRj9HbGUNke2Ne+qBL+Jxs6CIDWy9EadfsLz0qlE= =kkbL -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] IO-problem with actual trunk
Hi Henning, I am confused now. None of the o5m files contains the error that was in yesterdays data, and the file sizes are very different (new files are smaller). Do you have an idea why? Gerd Henning Scholland wrote > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi Gerd > Here it is: http://www.aighes.de/data/mkgmap.zip > > Henning > > Am 24.11.2013 09:02, schrieb Gerd Petermann: >> Hi Henning, >> >> I still don't understand why this change is important for mkgmap, >> maybe I did not fix the real problem. It would be great if you >> could reproduce it again with r312 and --output=o5m . The problem >> was e.g. in file 10100011.o5m. Next, execute splitter r312(or r311) >> with --output=pbf and post a link to both files. >> >> Gerd >> >>> Date: Sat, 23 Nov 2013 23:05:54 +0100 From: > osm@ > To: >>> > mkgmap-dev@.org > Subject: Re: [mkgmap-dev] >>> IO-problem with actual trunk >>> >> 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: > osm@ >> To: > mkgmap-dev@.org > 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@.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 > >>> >>> ___ 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 >> > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.14 (GNU/Linux) > > iQEcBAEBAgAGBQJSkisgAAoJEPFgsWC7jOeT90UH/i8z82v8ysHXuw8iOK4+OrWk > FMMz7lWY/E6ngsijFUijWxflA8NZDkavwuc08QSyg+7x6y+cSa53u31hQYTzIYhc > FZGz47NRSWc/pkSC9I2BNu6uFdRDjOQgPP/1HKVzHfcwXvTNn4C4cr1CXdOMGOD3 > pKOjhSP9N1y1htGGCyg5ujTcLmQjRlbjzbL3cvg0TYqDYjYucnzxTUzRCopMn3cL > f6Ew/QcBIc/wF3pHkl9oEaKoLb60AXl/4o1apJrZF12mxNFpM/ffyI8nTn8AAJZc > fHs91VS4QrQkWppX1OidPhVpRj9HbGUNke2Ne+qBL+Jxs6CIDWy9EadfsLz0qlE= > =kkbL > -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/IO-problem-with-actual-trunk-tp5786885p5787070.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
Hi Henning, GerdP wrote > Hi Henning, > > I am confused now. None of the o5m files contains the error that was in > yesterdays > data, and the file sizes are very different (new files are smaller). > Do you have an idea why? A few more details: Executing osmconvert with yesterdays data always shows this: c:\temp>osmconvert 1011.o5m -o=1011.o5m.osm osmconvert Warning: wrong sequence at relation 305138 osmconvert Warning: next object is node 10216945201 osmconvert Warning: osmconvert Warning: unexpected contents after logical end of file: 1011.o5m c:\temp>osmconvert 1012.o5m -o=1012.o5m.osm osmconvert Warning: wrong sequence at relation 383908 osmconvert Warning: next object is node 10204620185 osmconvert Warning: osmconvert Warning: unexpected contents after logical end of file: 1012.o5m and more errors for 10100011.o5m: c:\temp>osmconvert 10100011.o5m -o=10100011.o5m.osm osmconvert Warning: wrong sequence at relation 152458 osmconvert Warning: next object is node 10221551320 osmconvert Warning: invalid .o5m string reference: 70->131436542 osmconvert Warning: invalid .o5m string reference: 70->88921963 osmconvert Warning: invalid .o5m string reference: 70->506 With the new data I see only the expected messages: c:\temp\henning>osmconvert 1011.o5m -o=1011.o5m.osm osmconvert Warning: wrong sequence at relation 305138 osmconvert Warning: next object is node 10216945201 c:\temp\henning>osmconvert 1012.o5m -o=1012.o5m.osm osmconvert Warning: wrong sequence at relation 383908 osmconvert Warning: next object is node 10204620185 Some of the converted .osm files are equal, but the o5m files are different (garbage at the end of the file). So, in other words, it seems that your file system was corrupted. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/IO-problem-with-actual-trunk-tp5786885p5787076.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] TYP-file can't be written
Hi Henning in the end of August it worked without any problems. I've just read here that something was changed with TYP-files and code-page. The change was that the --code-page parameter overrides the CodePage that is in the typ txt file. That may well have been a bad idea. It certainly is in this case. Previously you would have had a cp1252 TYP file with the tiles being in a different code page (unless you changed the CodePage in the typ txt file too). You should be able to work around the problem by using --code-page=1252 just before the .txt file and then setting it back to what it should be just after. I am tempted to revert that part of the change, but will have to look at why I made it in the first place. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
