Re: [mkgmap-dev] No roads near target bug in Schwabmünchen

GerdP wrote Hi, I can reproduce the problem now, but in opposite to your experiences I see them anywhere near Schwabmünchen. Very strange, I did not yet manage to find other locations for the bug. I tried different maps covering this area, I always see the same result: I can create a

Re: [mkgmap-dev] highway=track with no road_class and road_speed set breaks routing ## was ## No roads near target bug in Schwabmünchen

I just noticed another fact. It seems that only the index are broken. The POI index as well as the address search index. If i select Schönwetter Automobile from the POI list routing fails. If I tap the exact same position on the map and hit GO, routing works. I do not know how the road_class

Re: [mkgmap-dev] highway=track with no road_class and road_speed set breaks routing ## was ## No roads near target bug in Schwabmünchen

Just to give you an impression on how bad the routing might get I made a few Screenshots on the nüvi. In over 90% of the problematic cases the nüvi just displays Calculating xx% forever, but sometimes it comes up with a route proposal that is just insane. It takes 147km for an effective distance

Re: [mkgmap-dev] highway=track with no road_class and road_speed set breaks routing ## was ## No roads near target bug in Schwabmünchen

Minko-2 wrote Problem with the nüvi's is that the underlying basemap is routable too. This often clashes with the routable OSM map. Don't know if it helps or if it possible to rename the basemap? The basemap is not shown in the list of maps on the nüvi. It could only be disabled by renaming

Re: [mkgmap-dev] highway=track with no road_class and road_speed set breaks routing ## was ## No roads near target bug in Schwabmünchen

GerdP wrote Hi Franco, I am not sure that --no-housenumbers works. Looking at the code I think it will have the same effect as --x-housenumbers or any other option ending with housenumbers. Please try also without that option. Gerd I did not use a no-housenumbers otpion, I just put

Re: [mkgmap-dev] highway=track with no road_class and road_speed set breaks routing ## was ## No roads near target bug in Schwabmünchen

Minko-2 wrote How can I do this with the Oregon? Hi Gerd, there are two ways to do this. See http://gpsinformation.info/penrod/oregon/oregon.html When you are in Demo Mode (simulator) you can change your simulated location. We discovered this on our own, as there is no tab to press on

Re: [mkgmap-dev] highway=track with no road_class and road_speed set breaks routing ## was ## No roads near target bug in Schwabmünchen

GerdP wrote Reg. r2460: Maybe I got you wrong. In SVN, r2460 existed only in the exit_hints branch, so I compiled the sources contained in that branch. Maybe you did not use r2460, but the trunk version that was available when r2460 was committed, which was probably r2459. It was 2460 - I

Re: [mkgmap-dev] highway=track with no road_class and road_speed set breaks routing ## was ## No roads near target bug in Schwabmünchen

Hi Gerd, the actual tests I will do tonight, but I prepared the tgz archive containing my test environment for you. You can get it here http://francobez.bplaced.net/files/mkgmap/test_cases.tgz Ciao, Franco -- View this message in context:

Re: [mkgmap-dev] highway=track with no road_class and road_speed set breaks routing ## was ## No roads near target bug in Schwabmünchen

Hi Gerd, I assume that I can skip the tests with the two versions 2447 and 2459 ? I tested with the patched binary you provided. with the bogus style there is no big difference On the Oregon I get no roads near target both for the POI and for the address, just like before. On the Nüvi I get

Re: [mkgmap-dev] highway=track with no road_class and road_speed set breaks routing ## was ## No roads near target bug in Schwabmünchen

Hi Gerd, I identified the second trigger of the routing bug to Robert-Bosch-Straße 14. It is the overlays file of the basemap_style. I composed a tgz archive of the style for you http://francobez.bplaced.net/files/mkgmap/mystyles.tgz Using the style from the archive, together with the map.conf

Re: [mkgmap-dev] highway=track with no road_class and road_speed set breaks routing ## was ## No roads near target bug in Schwabmünchen

GerdP wrote Hi, yes, I can confirm that mkgmap works as you describe it, my understanding of the code was wrong. I've coded an additional test for this with the list-styles method, it issues Warning: routable type 0x00c06 is used for non-routable line with resolution 24. This may break

Re: [mkgmap-dev] process-exits vs process-destination

Hi WanMil, thank you very much. This is really good news. i will try this as soon as possible. Ciao, Franco -- View this message in context: http://gis.19327.n5.nabble.com/process-exits-vs-process-destination-tp5756464p5756549.html Sent from the Mkgmap Development mailing list archive at

Re: [mkgmap-dev] highway=track with no road_class and road_speed set breaks routing ## was ## No roads near target bug in Schwabmünchen

GerdP wrote Hi Franco, I did a few more tests now. I am able to reproduce the problem with a small input file: franco1.osm.pbf http://gis.19327.n5.nabble.com/file/n5756490/franco1.osm.pbf My result with an Oregon 450t , software version 5.50: version 2447: routing to POI Schönwetter

Re: [mkgmap-dev] Translation system proposal

Hi Carlos, Carlos Dávila-2 wrote Currently we have the English word Exit in the default lines style file, which is used by the exit_hint option. Obviously it isn't appropriate for all languages, This already bothered me too. I was wondering if it weren't possible to use the built-in

Re: [mkgmap-dev] Translation system proposal

Marko Mäkelä wrote On Wed, Apr 10, 2013 at 10:04:20PM -0700, franco_bez wrote: I was wondering if it weren't possible to use the built-in translations of the Garmin Device itself. I mean the translations in the *.gtt Files from the GARMIN/Text directory on the Garmin device. Exit would

Re: [mkgmap-dev] highway=track with no road_class and road_speed set breaks routing ## was ## No roads near target bug in Schwabmünchen

Hi Gerd, I tested your binary. With the old style files, the buggy ones, I get the warnings during --list-styles and the errors during buid. With the new style Bernd has composed there are neither warnings nor errors about Non-routable way with routable type. So far it looks good to me.

Re: [mkgmap-dev] highway=track with no road_class and road_speed set breaks routing ## was ## No roads near target bug in Schwabmünchen

map. This leads to routing errors. Use --list-styles to check the style. Ciao, Franco franco_bez wrote Hi Gerd, I tested your binary. With the old style files, the buggy ones, I get the warnings during --list-styles and the errors during buid. With the new style Bernd has composed

Re: [mkgmap-dev] highway=track with no road_class and road_speed set breaks routing ## was ## No roads near target bug in Schwabmünchen

Hi Gerd, I compiled another tgz archive to demonstrate the bug, in case you need it. http://francobez.bplaced.net/files/mkgmap/test_cases_errors.tgz Ciao, Franco -- View this message in context: http://gis.19327.n5.nabble.com/No-roads-near-target-bug-in-Schwabmunchen-tp5753364p5757102.html

Re: [mkgmap-dev] highway=track with no road_class and road_speed set breaks routing ## was ## No roads near target bug in Schwabmünchen

Minko-2 wrote I got the same warnings, probably because 0x16 is not considered as routable (which should be)? In the basemap_style I used the type 0x16 isn't used at all. The strange thing is that --list-styles tells me everything OK, while building a map throws the Errors. Now what's right ?

Re: [mkgmap-dev] highway=track with no road_class and road_speed set breaks routing ## was ## No roads near target bug in Schwabmünchen

GerdP wrote I've used Bernds style to reproduce the problem: https://github.com/berndw1960/aiostyles Attached is a patch that replaces the mkgmap:check_connected feature with a mkgmap:set_unconnected_type feature. routable_types_v3.patch

Re: [mkgmap-dev] highway=track with no road_class and road_speed set breaks routing ## was ## No roads near target bug in Schwabmünchen

franco_bez wrote I tested your binary with the proposed change on the Style, and now I still get precisely 1 Error Message in my test case. Before there were plenty (maybe 100) of them. The message confuses me its: SEVERE (MapBuilder): /home/franco/map_build/test_cases/tiles/63360004.o5m

Re: [mkgmap-dev] highway=track with no road_class and road_speed set breaks routing ## was ## No roads near target bug in Schwabmünchen

GerdP wrote Hi, I noticed that type 0x00 is a valid line type, so it's not a good idea to use this as a flag for delete the line. Also I was not able to get the unit tests running when the --list-styles option performs the checks. Therefore I've added a new option --check-styles.

Re: [mkgmap-dev] highway=track with no road_class and road_speed set breaks routing ## was ## No roads near target bug in Schwabmünchen

GerdP wrote Hi all, today I've committed routable_types_v6.patch + a few small mods. I would really like to know if a routable map from Garmin contains lines with routable types in resolution 24 which do not appear in the NOD section. I don't own any City Navigator map, so I can't check

Re: [mkgmap-dev] New filter function trim

franco_bez wrote so ${destination|part} must be ${destination|part:} i missed the colon ;-) -- View this message in context: http://gis.19327.n5.nabble.com/New-filter-function-trim-tp5757768p5757838.html Sent from the Mkgmap Development mailing list archive at Nabble.com

Re: [mkgmap-dev] New filter function trim

Also in the rule-filters.txt I missed the colon in the example. Here's the new diff: part_filter_src.diff http://gis.19327.n5.nabble.com/file/n5757839/part_filter_src.diff -- View this message in context: http://gis.19327.n5.nabble.com/New-filter-function-trim-tp5757768p5757839.html Sent

Re: [mkgmap-dev] New filter function trim

Sorry for all this confusion. I need to do more debugging. This java languague is a little strange to me. I'll post the Filter once I have it thoroughly tested. Ciao, Franco -- View this message in context: http://gis.19327.n5.nabble.com/New-filter-function-trim-tp5757768p5757847.html

Re: [mkgmap-dev] New filter function trim

Hi all, has anyone yet had the time to do a little testing. Any, comments or change requests ? With my tests everything worked fine. @WanMil if you think the patch is OK and the new part filter function is useful, would you commit it ? Me myself, I do not have write access to the svn. Ciao,

[mkgmap-dev] mergeroads sometimes breaks routing

I found a very strange routing behaviour connected to the mergeroads-patch. The Problem area is here: http://www.openstreetmap.org/#map=17/47.89307/10.63390 When I try to route ( Automobile-mode, minimize-time ) from corner Liegnitzer-Straße/Glogauer-Straße to Beuthener-Straße Nr. 11, I get

Re: [mkgmap-dev] mergeroads sometimes breaks routing

here's the testcase: http://files.mkgmap.org.uk/download/162/mergeroads_routing_bug.tgz Test case for mergeroads routing bug containing build-script and osm Sample-Data. -- View this message in context:

Re: [mkgmap-dev] mergeroads sometimes breaks routing

Hi Gerd and WanMil, the bug really is NOT related to mergeroads. I joined the Beuthener Straße and the Allensteiner Straße in OSM as they were split in several ways for no reason. Now the routing has changed, not for the better I'm affraid ;-) ( see screenshots ) But anyway now both mergeroads

Re: [mkgmap-dev] mergeroads sometimes breaks routing

GerdP wrote Hi, I forgot to report that changing the order of nodes did not change the result in MapSource, so this is a different problem. Gerd The case is really strange. When I build a DACH map - the routing is OK When I try a data extract from JOSM with just this part of Kaufbeuren -

Re: [mkgmap-dev] mergeroads sometimes breaks routing

Hi Gerd, the KML files were generated while splitting, just forgot to put them in the archive. just in case they might be helpful http://files.mkgmap.org.uk/download/168/bayern.kml http://files.mkgmap.org.uk/download/169/dach.kml -- View this message in context:

Re: [mkgmap-dev] mergeroads sometimes breaks routing

The problem still persists, just switched from a bayern map to dach map. just yesterday I built a dach map with mkgmap-r2998 withe the strange routing. I could provide a new tile if this helps. -- View this message in context:

[mkgmap-dev] Finalize section not working as expected

I got a very nasty bug here. IMHO it must be somehow related to the finalize section in the lines file of the style. http://www.openstreetmap.org/#map=16/47.9114/10.5862 When routing along the bicycleway along the OAL12 from the roundabout to Irsee. Choosing Mountainbike or Tourbike as Activity

Re: [mkgmap-dev] Finalize section not working as expected

Some additional hints: I get this problem in 100% of the cases I tested, on ORGON 550. Did not matter what map was built. Bernd tried to reproduce the bug with a bayern map but did not get the bug neither on his OREGON 650 nor in BASECAMP. For faster testing I created a test-area called xx, and

Re: [mkgmap-dev] Finalize section not working as expected

the rules in question are: / highway=path ( smoothness~'.*(horrible|impassable)' | smoothness=very_bad | mtb:scale0 | mtb:scale:imba0 ) { set bicycle=no } highway=path (

Re: [mkgmap-dev] Finalize section not working as expected

the xx.o5m is not in the test_case. I just sent it to Bernd directly. But in the test case there is a very small osm file that contains just the problematic area. On my Oregon this produced the bug in 100% of the cases. -- View this message in context:

Re: [mkgmap-dev] Finalize section not working as expected

I just made a few more tests. Steve Ratcliffe wrote On 24/03/14 11:42, Gerd Petermann wrote: @Steve: Can you have a look at it? I used each set of rules with the file test_area_irsee.osm The resulting files were identical apart from the timestamps. So I am unable to replicate any

[mkgmap-dev] delete name not working

Hi all, I'm facing a very strange problem with the style function delete. in the points file I have the following rule In the past this removed unwanted labels on post boxes in the map. Since quite some time, I assume since the change to the new style rules a few month ago, the labels

Re: [mkgmap-dev] delete name not working

Just a question for my understanding of the problem: This rule not only sets the name but also mkgmap:label:1 ? I thought that calling - delete name - would erase the name, no matter what it was assigned before. would it make any difference having a rule with the set command instead ?

Re: [mkgmap-dev] delete name not working

Hi Gerd, thank you very much for the clarification. -- View this message in context: http://gis.19327.n5.nabble.com/delete-name-not-working-tp5804145p5804196.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___ mkgmap-dev

[mkgmap-dev] Occasional header corruption in gmapsupp.img

Hi all, once again I stumbled over a really weird problem: In rare cases mkgmap produces a gmasupp.img that shows up as Map data (c) OpenSt in the list of maps on my Oregon 550. Screenshots: http://gis.19327.n5.nabble.com/file/n5825759/bad_01.png

Re: [mkgmap-dev] Occasional header corruption in gmapsupp.img

Hi Steve, sounds great :-) Just in case you need any further information or files, just let me know. I'll try my best to provide them. --- The procedure of creating the to samples was identical save to the slightly different italy-extracts ( one or two days appart ) . So if the MPS file is

Re: [mkgmap-dev] Occasional header corruption in gmapsupp.img

Hi Steve, good work :-) using your pre-built mkgmak.jar both my test-cases produce error-free gmapsupp.img files. seems fixed to me. Ciao, Franco Steve Ratcliffe wrote Hi once again I stumbled over a really weird problem: I have a patch for this problem. A size calculation was

Re: [mkgmap-dev] Occasional header corruption in gmapsupp.img

Hi Steve, Could you occasionally commit this fix to svn ? Ciao, Franco -- View this message in context: http://gis.19327.n5.nabble.com/Occasional-header-corruption-in-gmapsupp-img-tp5825759p5826271.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

[mkgmap-dev] Question about the overview map

Is it true that the overview map is only used by Mapsource and Bascamp on the PC, but does not work on the mobile devices themselves ? I'm looking for a solution for the following problem: When you zoom out to a really big scale ( 100km for instance ) the Oregon will not be able to render all of

Re: [mkgmap-dev] Question about the overview map

Hi Andrzej, my map reaches up to zoom level 16. I just tested, and you are right, starting from a certain Zoom level the Basemap takes over if enabled. With my map the 50km Zoom still shows my map, no basemap visible. Beginning from 80km there is only the Basemap, and the device becomes reactive

Re: [mkgmap-dev] Question about the overview map

Hi Thorsten and Andrzej, thanks for the feedback. In the map style I use there are no details on the top level. Only Motorways and Major Cities. Zooming out to the scale "30km" works fine, but zooming further out does not really work. Here's a sample:

Re: [mkgmap-dev] Question about the overview map

popej wrote > have you enabled base map in GPS? It should be item like "Worldwide DEM > Basemap" in menu of your GPS. Hi Andrzej, No I do not have the Basemap enabled, anyway it's really old. Maybe it would show up in the blank spaces, maybe not. But even if I enable the GARMIN Basemap my OSM

Re: [mkgmap-dev] Recent Garmin Firmware "cannot authenticate maps" when they are unicode

One last thought: maybe it's not a bug in mkgmap, and maybe there is no way to fix this on our side. But in any way there will be more and more people affected as the number of new Garmin devices increases. So we should issue a warning message when maps are built with the unicode option.

[mkgmap-dev] Recent Garmin Firmware "cannot authenticate maps" when they are unicode

Hi all, maybe it's already a know bug. I just stumbled over this one: On a new Oregon750 I got the Error "cannot authenticate maps", while on the old Oregon550 the maps worked like always. I found out that changing the option "unicode" to "latin1" in my style did the trick, the resulting maps

Re: [mkgmap-dev] Recent Garmin Firmware "cannot authenticate maps" when they are unicode

Hi Gerd and Andrzej, I do not see any reason why GARMIN should only require UNICODE maps to be signed, while LATIN1 maps can remain unsigned. I suspect that there is a flag in the file header, maybe a new and undocumented one, that marks the file as "check for signature". When the Oregon checks

Re: [mkgmap-dev] Recent Garmin Firmware "cannot authenticate maps" when they are unicode

Waxy wrote > Hi, > > I tested the dach_boundary_gmapsupp_error.img… > > On a etrex 30 : no message "cannot authenticate maps" and boundaries are > visible. > On a GPSMAP64s : error message "cannot authenticate maps" and the map is > not listed. > > Steph Hi Steph, this is exactly what happens

Re: [mkgmap-dev] DEM-file generation from geo-tiff sources ?

Hi Frank, thanks for the new hints, this sounds much simpler than my approach. Especially the "virtual" tif-File should save a lot of time and disk space. But anyway there will be more than 1000 tiles for all the copernicus data. 1000 times a few seconds - it's still over one hour. But

Re: [mkgmap-dev] DEM-file generation from geo-tiff sources ?

Frank Stinner-2 wrote > Hi Franco, > > i have seen an silly error in my area. Europa is a little bit greater ;) > Just i have "$lattop = 70". The split create 3608 tif's with 4,5 GB in 85 > min. gdal4hgt create 1171 zipped hgt's with 5,8 GB in 3 h :(( > And then i rebuild the tif's from the hgt's

Re: [mkgmap-dev] DEM-file generation from geo-tiff sources ?

Hi Frank, so these are the steps I used on my ubuntu machine: 1. Download the Copernicus Data and unzip 2. create the virtual tif-image gdalbuildvrt all.vrt *.TIF 3. cut the 1°x1° tiles with the perl script this results in almost 65GB of uncompressed tif tiles 4. convert every tif-tile to hgt

Re: [mkgmap-dev] DEM-file generation from geo-tiff sources ?

I don't know why my "raw-text" blocks got eaten by the nabble.com web interface franco_bez wrote > I got the following warnings gdalwarp $GDAL_TRANSLATE_OPT -te -24.0001389 26.9998611 -22.9998611 28.0001389 ../all.vrt N27W024.tif Creating output file that is 3601P x 3601L. Warn

Re: [mkgmap-dev] DEM-file generation from geo-tiff sources ?

Hi Frank, I tried to adapt your perl script to my Ubuntu System I got the following warnings Here's my Ubuntu-script Frank Stinner-2 wrote > Hi Franco, > > i have little bit "played" with copernicus-files. > > I have build a win-command-file with this perl-file: > > -- cut --- > > Yes, i

[mkgmap-dev] Strange error in mkgmap

Hi all, I stumbled over a problem in mkgmap when I build a map with my bikeroute style (an overlay-map to highlight bicycle routes) I get a non-functional map for bigger areas. There is no error message during the build process, just the resulting map file is faulty. When I remove some tiles the

Re: [mkgmap-dev] Creating a map with contour lines and DEM

the easiest way to create a contourlines map is phyghtmap this tool is for creating osm Files containing the contourlines. In a second step you build the Garmin map with mkgmap like this: phyghtmap --start-node-id=1 -start-way-id=1

Re: [mkgmap-dev] Strange error in mkgmap

Hi Steve and Andrzej, now it works as intended again. Thanks for the fix :-) Ciao, Franco -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk

Re: [mkgmap-dev] Strange error in mkgmap

now hrer's the link to the data: test_cases.tar.gz No, the map is not that big at all, some 200 tiles. I build several maps from the same tiles, and only two of them have issues. One that is drawing the administrative

Re: [mkgmap-dev] Strange error in mkgmap

a resulting bad map : bad_gmapsupp.img Just one tile less - no problem - good_gmapsupp.img -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html

Re: [mkgmap-dev] DEM and "holes"

See this tutorial for converting tif to hgt http://www.oruxmaps.com/foro/viewtopic.php?t=3612# I just created a linux shell script to replace the "tif2hgt.bat" tif2hgt.sh PS: Just

Re: [mkgmap-dev] DEM-file generation from geo-tiff sources ?

Frank Stinner wrote > At the moment we have to translate the tiffs from EPSG:3035 to EPSG:4326, > then the segmentation in 1°x1° tiffs an at last the conversion to hgt > files. This should not be a very great problem with gdal-tools or so, but > it is additional work. Hi Frank, thanks for the

Re: [mkgmap-dev] Any examples for routing with DEM data ? Anyone ?

I had a discussion on the Garmin Forum about this topic. It seems that DEM data is never used for routing on the Oregon. "minimal ascent" will only work together with commercial Topo-Pro maps. Most likely they contain additional information. thread on Garmin Forum

[mkgmap-dev] Any examples for routing with DEM data ? Anyone ?

happy GNU year ! now that we have the possibility to build maps with dem-data I wanted to find out how the Oregon makes use of this data for routing. I tried very hard to find an example where the Oregon would calculate a different route for "minimal ascent" and "minimal distance". I did not

[mkgmap-dev] DEM-file generation from geo-tiff sources ?

I'm using phygtmap http://katze.tfiu.de/projects/phyghtmap/ for the creation of contourlines maps. phygtmap automatically downloads the elevation data from several sources. Some sources provide the data in the geo-tiff format, others in the hgt

Re: [mkgmap-dev] Performance of POI search on the Device

Hi Gerd, thank you so much. That did the trick. If I only have the one map file on my SD Card the POI search is incredibly fast. Now I try to identify the offending map(s) Ciao, Franco -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html

[mkgmap-dev] Performance of POI search on the Device

Hi all, searching for POIs on my Oregon often is very frustrating. It virtually takes forever. Yesterday I noticed that some POI types are reasonably fast, while others are 10 times slower. I assume that this is some sort of index Problem. For example using my DACH map, built with

Re: [mkgmap-dev] Performance of POI search on the Device

Joris Bo wrote > Same for me. Even indexes of maps not 'enabed' are searched and if > covering the same area even displays duplicate results. > Where I first copied big maps to my Oregon just because there was space > enough on the 32GB SSD, now I build smaller maps and rename them if not > used

Re: [mkgmap-dev] Performance of POI search on the Device

Hi Gerd, I'm a little lost. I don't know how to proceed with the testing. I just tried a small map of the offensive "housenumber" layer. This makes no measurable difference in POI search. When I use a large "housenumber" map (covering DACH) the effect is significant. So I assume a single tile

Re: [mkgmap-dev] Performance of POI search on the Device

Gerd Petermann wrote > I also thought that the missing index of the overlay map might cause the > problem. I added an (empty) index to that map but that didn't help. > Maybe it helps to add a single (invisible) named POI to each tile. If that > helps it would prove that the bug is in the Oregon

Re: [mkgmap-dev] Performance of POI search on the Device

Hi Gerd, thanks for the binary. I did a lot of testing. I do not get any difference. As soon as I have a transparent layer, like housenumbers or bundaries the POI search is slow. not matter if I have "route" and "index" in the options or not. I also tried with and without

Re: [mkgmap-dev] Performance of POI search on the Device

476/dach_boundary_gmapsupp.img> the previous file (see below) triggers the problem. Ciao, Franco franco_bez wrote > Hi Gerd, > thanks for the binary. > I did a lot of testing. I do not get any difference. As soon as I have a > transparent layer, like housenumbers or bundaries the

Re: [mkgmap-dev] Performance of POI search on the Device

Hi Gerd, probabally I tried the "route" and "index" options with the patched version to see if it helps. (it didn't) I just tried the default center-POI type and 0x3200 - made no difference. I can do further testing in the evening. Ciao, Franco Gerd Petermann wrote > Hi Franco, > >

Re: [mkgmap-dev] Performance of POI search on the Device

Hi Gerd, here's the bondary-layer with x-center-poi-type=0x2f01 It slows down the search to the same extent as the other poi-types do. The option does not seem to have any impact. http://files.mkgmap.org.uk/download/477/dach_boundary_gmapsupp.img