Re: [mkgmap-dev] splitter r273 with --precomp-sea parameter

WanMil wrote > Please have a look at the attached image. > > The green area is the land data contained in the OSM data to be split. > The blue area is sea but the left coastline (grey) is not contained in > the OSM data. > > If you trim before merging the sea density the left border of the tile

[mkgmap-dev] There is not enough room in a single garmin map for all the input data

I still get this message in mkgmap when processing data that was created with splitter r275 and --precomp-sea option. It seems that it is not sufficient to count the nodes in the precompiled sea data, which leads me to the assumption that this is a general problem with polygons. I don't know wha

Re: [mkgmap-dev] Minor process-destination issue

Am 22.11.2012 16:05, schrieb WanMil: >> Do we have a style-function for this? >> >> item( ${destination}, 1 ) -> Bonn >> item( ${destination}, 2 ) -> Rodenkirchen > > No we don't and it will not be so easy to implement that because the > functions do not have any parameters yet at the moment. So

Re: [mkgmap-dev] Minor process-destination issue

Am 28.12.2012 12:57, schrieb Chris66: > Am 22.11.2012 16:05, schrieb WanMil: >>> Do we have a style-function for this? >>> >>> item( ${destination}, 1 ) -> Bonn >>> item( ${destination}, 2 ) -> Rodenkirchen >> No we don't and it will not be so easy to implement that because the >> functions do not

[mkgmap-dev] Input file has a different sort order

I am trying to creat a sample map with a custom TYP file. Running mkgmap.jar -c 5060.cfg 5060.TYP *.osm.pbf results in an error message which says: WARNING: input file ... has a different sort order (20007 rather than 0 The 5060.cfg file contains the following lines: description=Liechtenstein co

Re: [mkgmap-dev] Minor process-destination issue

> Am 22.11.2012 16:05, schrieb WanMil: >>> Do we have a style-function for this? >>> >>> item( ${destination}, 1 ) -> Bonn >>> item( ${destination}, 2 ) -> Rodenkirchen >> >> No we don't and it will not be so easy to implement that because the >> functions do not have any parameters yet at the mome

[mkgmap-dev] [PATCH v1] Rename internal mkgmap tag from display_name to mkgmap:display_name

The style uses a tag display_name. This is an internal mkgmap tag and should therefore be name mkgmap:display_name. Attached patch changes this but still accepts the old display_name (issuing a warning). WanMil Index: resources/styles/builtin-tag-list =

Re: [mkgmap-dev] Input file has a different sort order

Hi > WARNING: input file ... has a different sort order (20007 rather than 0 > I have read the thread started Dec. 22nd but the error message doesn't > disappear. It doesn't work with the patch applied? I will commit it now. I hesitated because, with the patch there would be no warning if the

[mkgmap-dev] installer/license_template.txt should be revised

Hi everybody, I noticed that with every img I create there is a *_license.txt file generated that reads: Map data (c) OpenStreetMap and contributors http://www.openstreetmap.org/ Map data licenced under Creative Commons Attribution ShareAlike 2.0 See http://creativecommons.org/li

[mkgmap-dev] Commit: r2427: When a typ file is first, before the map files, an incorrect message

Version 2427 was committed by steve on 2012-12-28 13:57:35 + (Fri, 28 Dec 2012) When a typ file is first, before the map files, an incorrect message is triggered about different sort-orders. Worse it uses the "no sort order" value for the generated index, and so the index will not work. ___

Re: [mkgmap-dev] Input file has a different sort order

Am 28.12.2012 14:54, schrieb Steve Ratcliffe: > I will commit it now. I hesitated because, with the patch there > would be no warning if the TYP file had a different code-page > to the maps (if that matters). Hi Steve, the code page is the same in the cfg-file (latin1) as well as in the binary t