- mkgmap-dev - The mkgmap lists

Re: [mkgmap-dev] Address search Slovakia and Czech Republic
by Marek Greško 06 Aug '13

06 Aug '13

As of this page http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative the administrative levels in Slovakia are: admin level 6: Borders of Bratislava and Košice admin level 8: district borders (because of this you see okres.... you see only district capital cities) admin level 9: town, village or autonomous town in Bratislava or Košice. So you should probably use something like that for Slovakia: mkgmap:country=SVK & mkgmap:city!=* & mkgmap:admin_level6=* { set mkgmap:city='${mkgmap:admin_level6}' } mkgmap:country=SVK & mkgmap:city!=* & mkgmap:admin_level9=* { set mkgmap:city='${mkgmap:admin_level9}' } mkgmap:country=SVK & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } I tested it. It worked, but several streets are missing in the index. I have no idea why. In Czech Republic probably mkgmap:country=CZE & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } mkgmap:country=CZE & mkgmap:city!=* & mkgmap:admin_level7=* { set mkgmap:city='${mkgmap:admin_level7}' } would be the best option. I did not test. Marek

1 0

Re: [mkgmap-dev] Address search Slovakia and Czech Republic
by Marek Greško 06 Aug '13

06 Aug '13

s of this page http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative the administrative levels in Slovakia are: admin level 6: Borders of Bratislava and Košice admin level 8: district borders (because of this you see okres.... you see only district capital cities) admin level 9: town, village or autonomous town in Bratislava or Košice. So you should probably use something like that for Slovakia: mkgmap:country=SVK & mkgmap:city!=* & mkgmap:admin_level6=* { set mkgmap:city='${mkgmap:admin_level6}' } mkgmap:country=SVK & mkgmap:city!=* & mkgmap:admin_level9=* { set mkgmap:city='${mkgmap:admin_level9}' } If you prefer to see autonomous parts of Bratislava and Košice, ignore also admin_level 6. You should completely ignore admin levels 7 and 8 to ignore district borders and district names. I will test and let you know whether I was succesful. I was also struggling with it and today I found the URL above. Marek

1 0

Commit: r2661: Add sort source file for the cp1250 code page
by svn commit 03 Aug '13

03 Aug '13

Version 2661 was committed by steve on Tue, 30 Jul 2013 Add sort source file for the cp1250 code page

2 1

Address search problems with CP1250
by Andrzej Popowski 30 Jul '13

30 Jul '13

Hi, I observe following problems when using CP1250 in mkgmap options: - Address search in nuvi requires upper case characters input. If keyword contains lower case characters, no results are found. - If I use option "lower-case" in mkgmap, address search doesn't work in Mapsource. Mapsource accept only single character as an input in search form, subsequent characters are deleted. This could be mismatch in lower-upper case too. If I use CP1252 all works correctly. Note: CP1252 is hard-coded in TDB, but probably it doesn't matter. -- Best regards, Andrzej

3 9

Commit: r2660: Tdb file codepage was hardcoded, make it not.
by svn commit 30 Jul '13

30 Jul '13

Version 2660 was committed by steve on Tue, 30 Jul 2013 Tdb file codepage was hardcoded, make it not.

1 0

Re: [mkgmap-dev] Problems with --code-page=1251
by Лис 27 Jul '13

27 Jul '13

I did some tests. If street name starts with one of these letters “г д к л м н у х ц ч ш щ ъ ы ь э ю я”, they are not shown at the search results. There is no such problem with other letters “а б в е ё ж з и й о п р с т ф”. In the list all streets are present. 2013/7/27 Лис <horonitel(a)gmail.com> > On 26/07/13 16:29, Steve Ratcliffe wrote: > > > Could you try without --lower-case and see if that helps? > > > Best wishes > > ..Steve > > The problem there is > All was good on older versions, but I've updated the program and did not > keep the old version >

1 0

Problems with --code-page=1251
by Лис 26 Jul '13

26 Jul '13

On 26/07/13 16:29, Steve Ratcliffe wrote: > Could you try without --lower-case and see if that helps? > Best wishes > ..Steve The problem there is All was good on older versions, but I've updated the program and did not keep the old version

1 0

Problems with --code-page=1251
by Лис 26 Jul '13

26 Jul '13

I have a problems with search streets and adresses on my device in gmapsupp.img when i make it with --code-page=1251. I have: openSUSE 12.3 x64, java-1_7_0-openjdk, Garmin Dakota 20. My options for mkgmap: --style-file=default --gmapsupp --bounds=world-boundarys --route --index --add-pois-to-areas --tdbfile --lower-case --drive-on-right --code-page=1251 -c splitted/template.args default/openstreetmap.TYP I have no problem when I specify the option - code-page = 1252 Many streets in search not available when I specify the option - code-page = 1251 I tried the version r2659 r2656 r2654 r2653 r2648 r2643. Everywhere there is this problem. I do not have older versions.

2 1

misshapen roundabouts
by Kay F. Jahnke 26 Jul '13

26 Jul '13

I think I finally found what the problem is: the garmin devices can't handle the precise data I want them to display, look at these two quotes: 1. from http://www.cgpsmapper.com/download/GM8DocV2.pdf When declaring the location of objects in the world, the highest precision available uses 24 bits of resolution, which resolves to an accuracy of about 2.5 meters. 2. in 'Garmin IMG File Format' by John Mechalas: The reference coordinates in the TRE section are given as 24-bit integers (three bytes). This implies that the maximum granularity for map elements in the image file is approximately .0000214576721 degrees of latitude or longitude. At the equator, a degree of latitude is roughly 365228.16 feet, making the highest resolution for map points about 7.8369461 feet. So even if we have precise coordinates in OSM, in the garmin image they will be rounded to the nearest(?) grid point. In fact, everything on the garmin map looks like it's been snapped-to-grid, if you look at it closely. Sorry for the noise; maybe my posting is still helpful for others facing the same problem. Kay

3 2

Splitter Crash
by News 25 Jul '13

25 Jul '13

I'm getting the following error when trying to split some large .osm files containing contour data. After generating the contour files I preprocess them and then split them so it's most likely an error in my preprocesing but I can't track it down. Additionally this only happens if the input file needs splitting i.e if I tweak the contour file size and the --max-nodes option to the point that the input file doesn't actually need splitting then splitter continues through the file and all is well but this approach isn't feasible for what I need to achieve. Command line is:- java -Xmx1024M -jar splitter.jar --mapid=12345001 --max-nodes=200000 --output=xml input.osm Any pointers as to where to look would be appreciated. Thanks Paul Exception in thread "main" java.lang.IndexOutOfBoundsException: Index: 2147483647, Size: 6 at java.util.ArrayList.rangeCheck(ArrayList.java:604) at java.util.ArrayList.get(ArrayList.java:382) at uk.me.parabola.splitter.WriterDictionaryInt.getBitSet(WriterDictionaryInt.java:85) at uk.me.parabola.splitter.SplitProcessor.writeNode(SplitProcessor.java:297) at uk.me.parabola.splitter.SplitProcessor.processNode(SplitProcessor.java:102) at uk.me.parabola.splitter.OSMParser.endElement(OSMParser.java:219) at uk.me.parabola.splitter.AbstractXppParser.parse(AbstractXppParser.java:61) at uk.me.parabola.splitter.Main.processMap(Main.java:831) at uk.me.parabola.splitter.Main.writeAreas(Main.java:769) at uk.me.parabola.splitter.Main.split(Main.java:277) at uk.me.parabola.splitter.Main.start(Main.java:162) at uk.me.parabola.splitter.Main.main(Main.java:146)

4 11