August 2011 - mkgmap-dev - The mkgmap lists

Compiling mkgmap without support for pbf?
by Michael Prinzing 04 Aug '11

04 Aug '11

Hello, mkgmap rev 2008 and 2009 do not compile if there is no protobuf support installed. This is because OsmBinBoundaryDataSource.java does not compile in this case. I think there should be an exclude for "**/reader/osm/boundary/OsmBinBoundaryDataSource.java" in the "compile" target, and a corresponding include in the "compile-pbf" target of build.xml. Is this right, or what elso do I have to do in order to compile without pbf? Thanks, Michael

2 1

Commit: r2010: Reenable compiling without PBF support
by svn commit 04 Aug '11

04 Aug '11

Version 2010 was commited by wanmil on 2011-08-04 16:47:09 +0100 (Thu, 04 Aug 2011) Reenable compiling without PBF support The new OsmBinBoundaryDataSource.java file is now added to the pbf only classes and not compiled if PBF is not available.

1 0

Missing cities in gps
by Carlos Dávila 04 Aug '11

04 Aug '11

I've been reported from a user of my maps that some cities are missing in the Address search options on a nuvi 1410 and I could confirm on my nuvi 300. For example, for the map [1] you can find the following cities in MapSource, but only the last two on device. Jerez de la Frontera Jerez de los Caballeros Jesús Jesús Pobre Jete Jérica Jerte [1] http://mapas.alternativaslibres.es/MapSource_spain.zip

1 0

Re: [mkgmap-dev] How to track an error in OSM data ? (and style's behavior, error) (David)
by David 01 Aug '11

01 Aug '11

To Chris and Wanmill, I know the need to add "continue" rule to apply the next filter on data. But the fact is it does not seem to work as expected at least with "landuse=forest" and "natural=wood" with Ireland PBF file (splitted with splitter r2009 and compiled with mkgmap r2009). I do not have any clue, only a temporary solution. But the biggest trouble is still the corrupted map generated for Northern Ireland around Belfast with a huge commercial area polygon displayed in levels 0 and 1. Basecamp can display the map without any problem at all zoom and detail levels. My first idea was an error in OSM file, but I cannot find bad data. It looks like a bad result with early generate-sea option development (at least one year ago). Regards, David Le 01/08/2011 13:00, mkgmap-dev-request(a)lists.mkgmap.org.uk a écrit : > Am 31.07.2011 12:32, schrieb WanMil: > >>> >> I also found an error in a style file for forest polygons. You have to >>> >> write the rules like this if you want the result expected : >>> >> >>> >> landuse=forest& wood=coniferous [0x54 resolution 18] >>> >> landuse=forest& wood=decideous [0x50 resolution 18] >>> >> landuse=forest& wood=mixed [0x55 resolution 18] >>> >> landuse=forest& wood !=* [0x50 resolution 18] /*this line is applied if >>> >> no data matches the ones above*/ >>> >> >>> >> and not like that : >>> >> >>> >> landuse=forest& wood=coniferous [0x54 resolution 18] >>> >> landuse=forest& wood=decideous [0x50 resolution 18] >>> >> landuse=forest& wood=mixed [0x55 resolution 18] >>> >> landuse=forest [0x50 resolution 18]/*this line overrides the ones above*/ >> > As far as I know all rules after the first >> > matching line with a garmin id are skipped unless you add a continue >> > statement. So the default style should be correct. > Yes. mkgmap stops at the first matching rule. > > Exeptions: > > Action rules ( example : maxspeed=DE:urban {set maxspeed=50} ) > and the continue-statement: > > barrier=fence [0x34 resolution 24 continue] > > Chris > >

3 2