July 2011 - mkgmap-dev - The mkgmap lists

A few default stylesheet tweaks
by Lambertus 19 Jul '11

19 Jul '11

Hello list, Marko, Would it be possible that the default stylesheet does not show: - Admin levels 8, 9, 10 (admin_level=) - Communication (GSM/Broadband) towers (type=communication) - Powerlines (power=line) These do not add much functionality but clutter the map and confuse people. What do you think?

5 8

Re: [mkgmap-dev] Level and Resolution
by Roger Calvert 19 Jul '11

19 Jul '11

Greg, Good idea. I don't think I have write access to any of the databases, so I have placed a summary of my outcomes at http://www.rogercalvert.me.uk/mkgmap. I hope this will prove helpful, and have no objection to anyone incorporating them into other documentation. Regards, Roger ------------------------------------------------------------------------ Roger Calvert ------------------------------------------------------------------------ On 18/07/2011 13:00, Greg Troxel wrote: > If you have figured out things, please do either find a way to merge the > info to one of the databases about how this works, or put it on a web > page, or send a note to the list with a concise description of the new > info. >

2 1

[locator] Precompiled europe boundaries
by WanMil 18 Jul '11

18 Jul '11

.. can be downloaded from http://www.navmaps.eu/wanmil/europe_bounds_20110515.zip The format has slightly changed so you need to use the latest jar file from the locator branch. WanMil

2 1

Level and Resolution
by Roger Calvert 18 Jul '11

18 Jul '11

I am having a problem with level/resolution, and would appreciate advice. I have mapped 'barrier=gate' to an unused Garmin code using the instruction barrier=gate {add name = 'gate'} [0x1600 level 2] in the 'points' style file, with a corresponding entry defining a graphic in the TYP file. This works, except that it appears at all magnifications in MapSource, but only at very high resolution (scale = 120ft) in the GPS. Changing the 'level' or using 'resolution' instead seems to make no difference. I have a very similar problem with 'railway=rail'. Whatever the resolution in the 'lines' file, it appears all the time in MapSource, but only below 0.3 miles resolution in the GPS. But other lines - e.g. 'highway=track' appear much earlier, even when they have the same resolution or level. It appears that both MapSource and the GPS are ignoring the resolution/level in the style files and imposing their own (different) defaults. Any advice would be appreciated. Many thanks, Roger Calvert -- ------------------------------------------------------------------------ Roger Calvert ------------------------------------------------------------------------

3 3

Using exit refs in routing directions
by Charlie Ferrero 17 Jul '11

17 Jul '11

Hello list, Is there any way to get mkgmap to embed exit refs (where they exist) in the routing directions, so that instead of getting: "Exit right onto ramp" you get "Take exit 32 right onto ramp" or something similar? Is this something that official Garmin maps can do? -- Charlie

8 9

Index and equally named cities
by maning sambale 14 Jul '11

14 Jul '11

Dear steve, Here's a bit of explanation from one of our colleagues. > So can you explain exactly what is better and worse between the > city-region-index branch r1867 and r1870. > Do the different "San Fernando's" have different regions? If not how do > you tell them apart? ---------- Forwarded message ---------- tested on "Find Places - City" of Mapsource v6.13.7 have not tested mkgmap r1870 Note: there are 7 San Fernando towns and cities in different provinces in philippines.osm -We don't have (and we don't use) is_in:region in philippines.osm (at the moment) -We primarily use is_in:state to tag the 'province' of a specific town or city -There are no 2 similarly-named city or town within the same province in Philippines. -But there are hamlets & villages that may have the same name as town or city within the same province. -Since villages & hamlets are treated as 'small cities or towns' by hex code assignments in Garmin, we demoted all villages and hamlets to ordinary Amenity-POI's to prevent complications with similarly-named cities. OBSERVATIONS on mkgmap r1867: It can index and differentiate "similarly named towns & cities" if and only if: 1. we remove all country tags by: name=* { delete is_in:country } and replace it with place=* & is_in:state=* add is_in='${is_in:state},,Philippines' (eg. essential tags for mkgmapr1867---> name=San Fernando place=city is_in='Pampanga,,Philippines') 2. is_in='<province_name>,<blank_space>,Philippines' ---->magically assigns all town/s and cities to their respective Provinces in the Philippines. BUT, it has a conflict with is_in:country (which tends to disassociates the POI from the town & province). This was discovered by trial & error. No explanation for this weird behavior. 3. is_in='${is_in:state},,Philippines' on city-POI makes that city 'unique' (within a given radius. not sure of the exact figure, but it looks like 30km). All amenity-POI within that given radius are associated and searchable under that city, as long as you tag said amenity with addr:city 4. is_in:state on a city-POI has no effect on indexing, unless we combine it with is_in='${is_in:state},,Philippines' addr:state on an amenity-POI has no observed effect on indexing. 5. the 'address-search' on works on older Garmin model such as marine handhelds, outdoor models and nuvi 255W 6. the 'address-search' does not work on Nuvi 1310 (and most 4digit models) - No Map Data Available OBSERVATIONS on mkgmap-city-region-index-r1984.jar and all the latest mkgmap 1. under the same condition as above, the "address-search" on works on Nuvi 1310, but missing similarly-named cities. (eg. only 2 San Fernando appears - which are located on separate tile) On Sun, Jul 10, 2011 at 5:32 AM, Steve Ratcliffe <steve(a)parabola.me.uk> wrote: > > On 07/07/11 09:35, maning sambale wrote: > > Testing this version, > > Uploading via mac mapinstall is a bit longer but not too long > > > > I only get two "San Fernando"s that are in a separate tile. The other > > "San Fernando"s within one tile is not included in the search results. > > So can you explain exactly what is better and worse between the > city-region-index branch r1867 and r1870. > > Do the different "San Fernando's" have different regions? If not how do > you tell them apart? > > ..Steve > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev(a)lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- cheers, maning ------------------------------------------------------ "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ ------------------------------------------------------

6 15

Multipolygon/boundary relations and subrelations
by WanMil 13 Jul '11

13 Jul '11

Today I observed that the boundary relation of Luxembourg was changed in a way that it does not contain the boundary ways itself but links to other relations that contain parts of the boundary (Luxembourg/Belgium; Luxembourg/Netherlands etc.). I am not sure if that's an accepted scheme for mps/boundaries. Does anyone know if that's correct and accepted? Should mkgmap support this? WanMil

2 4

[locator] Option change
by WanMil 12 Jul '11

12 Jul '11

I have committed a change to the locator branch (r1994) affects some location specific mkgmap options in the branch. 1. boundsdirectory has been renamed to bounds 2. location-autofill now contains a list of parameters location-autofill=[option1,[option2]] Controls how country, region, city and zip info is gathered for cities, streets and pois. Default: bounds bounds The preprocessed boundaries are used. The assignment of boundary type => country, region etc. is configured in the style file is_in The is_in tag is analyzed for country and region information if these information is not already set nearest If all methods before failed the city/hamlet points that are closest to the element are used to assign the missing information. The old location-autofill values (0 to 3) are autoconverted to the new options although some buggy and bad coded functionality has been removed from the Locator and has to be reimplemented (e.g. fuzzy search - need to be reimplemented by a good soundslike algorithm). So now anybody can control with the mkgmap options if the time costly usage of the preprocessed boundaries should happen or not. WanMil

1 0

problem with splitter
by Henning Scholland 11 Jul '11

11 Jul '11

Hi, I discovered a problem with splitter.jar when using a areas.list with more then 255 tiles. If there are e.g. 256 tiles in one areas.list then splitter processes only half of the tiles e.g. 128. If there are 255 or less tiles inside, all tiles were processed. Is this a bug or a feature? It would be great, if there were no tilelimit because it is more effective to run splitter once with all tiles for all my maps and not run splitter two times. Without limit I would save 50% splittingtime. Henning

1 0

city_index -- map export with Mapsource only working for full maps, not single tiles
by Felix Hartmann 11 Jul '11

11 Jul '11

Well the title says it all. For this map update after reading the positive stuff about the city branch working, I used it (well tested by exporting one full country and thinking well it works). Sadly though, if you only choose one tile, or a few, then you get the usual mdr trim error. (to try out, if your maps don't show it: ftp://ftp5.gwdg.de/pub/misc/openstreetmap/openmtbmap/mtbaustria.exe (from 8.7.2011 in case I update it). Error: MDR_TRIMMER.H-1017-6.16.1.0 (6.16.1.0 is the mapsource version, so plain error is h-1017)

2 8