Re: [mkgmap-dev] POIs without POI-search
Sorry, clicked to fast The customs types, 0x011500-0x01161f, are not shown on my Oregon, searchable only over a complete search. Bernd Am Freitag, 5. Juni 2015, 09:36:02 schrieb Bernd Weigelt: Am Freitag, 5. Juni 2015, 08:46:36 schrieb Arndt: Hi Arndt you can use these types 0x2900-?, they are visible in 'all POIs', but not in other categories We, Franco and i, made a lot of tests to make sure how POIs types are sorted by the garmin devices. Bernd Hello experts, there are many POIs like barrier, traffic lights, trees an so on. Is it possible to show them in the map, but without a hit in the poi-search? Best regards Arndt -- amarok2 now playing: ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] POIs without POI-search
Thanks, is it possibel too, that the POIs NOT visible in AllPois? Arndt div Ursprüngliche Nachricht /divdivVon: Bernd Weigelt weigelt.be...@web.de /divdivDatum:05.06.2015 09:36 (GMT+01:00) /divdivAn: Arndt ar...@speichenkarte.de, Development list for mkgmap mkgmap-dev@lists.mkgmap.org.uk /divdivBetreff: Re: [mkgmap-dev] POIs without POI-search /divdiv /divAm Freitag, 5. Juni 2015, 08:46:36 schrieb Arndt: Hi Arndt you can use these types 0x2900-?, they are visible in 'all POIs', but not in other categories We, Franco and i, made a lot of tests to make sure how POIs types are sorted by the garmin devices. Bernd Hello experts, there are many POIs like barrier, traffic lights, trees an so on. Is it possible to show them in the map, but without a hit in the poi-search? Best regards Arndt -- amarok2 now playing: ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] process-exits and Oregon 600
Much better.
Micha
Am 05.06.2015 um 10:32 schrieb Gerd Petermann:
Hi Micha,
please check if the docu in r3607 is better.
Have a look at
http://www.mkgmap.org.uk/websvn/diff.php?repname=mkgmappath=%2Ftrunk%2Fresources%2Fhelp%2Fen%2Foptionsrev=3607peg=3607
Feel free to suggest improvements.
Gerd
Date: Thu, 4 Jun 2015 12:04:02 +0200
From: micha.l...@web.de
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] process-exits and Oregon 600
Hi Gerd
yes all fine - we should just update the documentation: I didn't know
08 and 09 are special and had to find out the hard way...
Micha
Am 04.06.2015 um 11:57 schrieb Gerd Petermann:
Hi Micha,
okay, same effect: no 0x09 type for the motorway_link.
My understanding is that the types 0x08 and 0x09 are special
as they tell Garmin to use the name of the next road which doesn't
have 0x08 or 0x09 as the hint.
So, you need a part of the link that is 0x08/0x09 and
the hint on the next part of the link which is NOT 0x08/0x09.
That's what the default style does. OK?
Gerd
Date: Thu, 4 Jun 2015 11:51:26 +0200
From: micha.l...@web.de mailto:micha.l...@web.de
To: mkgmap-dev@lists.mkgmap.org.uk
mailto:mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] process-exits and Oregon 600
Hi Gerd,
in 3602 (which i used) these are lines 118/119.
I meant changing
highway=motorway_link [0x09 road_class=3 road_speed=2 resolution 20]
to
highway=motorway_link { name 'generic_exit' } [0x02 road_class=3
road_speed=2 resolution 20]
Micha
Am 04.06.2015 um 11:47 schrieb Gerd Petermann:
Hi Micha,
lines 119 and 120 in lines (r3605) are:
highway=motorway_link (mkgmap:exit_hint=true |
mkgmap:dest_hint=true) [0x06 road_class=3 road_speed=2
resolution 20]
highway=motorway_link [0x09 road_class=3 road_speed=2
resolution 20]
If you change line 119 as suggested the rule in line 120
is never triggered, therefore you will not have a type 0x09
for the
motorway_link.
Gerd
Date: Thu, 4 Jun 2015 11:36:01 +0200
From: micha.l...@web.de mailto:micha.l...@web.de
To: mkgmap-dev@lists.mkgmap.org.uk
mailto:mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] process-exits and Oregon 600
Hi Gerd,
trying to reproduce the problem with the default style made
things clearer. If you change line 119 in lines to:
highway=motorway_link { name 'generic_exit' } [0x02
road_class=3 road_speed=2 resolution 20]
routing hints point to generic_exit. I did a few more test,
and it seems that there's two ways to get proper routing:
1. Make segments 1 3 polyline 0x09 (named or not doesn't
matter), and segment 2 any type except 0x08 or 0x09 (didn't
test that, taken from the documentation)
2. If segments 1 3 are not 0x09 then don't name them, and
again segment 2 any type except 0x08 or 0x09
Micha
Am 04.06.2015 um 09:30 schrieb Gerd Petermann:
Hi Micha,
it's hard to understand without seeing your complete style.
Maybe you can post a link to it?
If not, please describe in detail how to reproduce the problem
with the default style and give an example route
that shows what you get with and without the modification.
thanks,
Gerd
Date: Thu, 4 Jun 2015 09:20:23 +0200
From: micha.l...@web.de mailto:micha.l...@web.de
To: mkgmap-dev@lists.mkgmap.org.uk
mailto:mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] process-exits and Oregon 600
Hi Gerd,
my style did (in this order) assign hints to exits, and at
the very end, assign generic names to all leftover
unnamed roads. This produced exits in 3 segments named
GENERIC_NAME, EXIT_HINT, GENERIC_NAME - so mkgmap
worked just as expected. But: the Oregon now shows
GENERIC_NAME during routing, not EXIT_HINT. After
removing the generic names from the 1st and the 3rd
segment, everything workes fine.
So I draw two conclusions from this:
Either: mkgmap simly assigns the exit hints to all 3
segments (do we need 3 segments at all, then?), though I
don't know what else might be influenced by this
Or: documentation needs to be updated concerning the
exit_hints
Re: [mkgmap-dev] process-exits and Oregon 600
Hi Micha,
please check if the docu in r3607 is better.
Have a look at
http://www.mkgmap.org.uk/websvn/diff.php?repname=mkgmappath=%2Ftrunk%2Fresources%2Fhelp%2Fen%2Foptionsrev=3607peg=3607
Feel free to suggest improvements.
Gerd
Date: Thu, 4 Jun 2015 12:04:02 +0200
From: micha.l...@web.de
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] process-exits and Oregon 600
Hi Gerd
yes all fine - we should just update the documentation: I didn't
know 08 and 09 are special and had to find out the hard way...
Micha
Am 04.06.2015 um 11:57 schrieb Gerd
Petermann:
Hi Micha,
okay, same effect: no 0x09 type for the motorway_link.
My understanding is that the types 0x08 and 0x09 are special
as they tell Garmin to use the name of the next road which
doesn't
have 0x08 or 0x09 as the hint.
So, you need a part of the link that is 0x08/0x09 and
the hint on the next part of the link which is NOT 0x08/0x09.
That's what the default style does. OK?
Gerd
Date: Thu, 4 Jun 2015 11:51:26 +0200
From: micha.l...@web.de
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] process-exits and Oregon 600
Hi Gerd,
in 3602 (which i used) these are lines 118/119.
I meant changing
highway=motorway_link [0x09 road_class=3 road_speed=2
resolution 20]
to
highway=motorway_link { name 'generic_exit' } [0x02
road_class=3 road_speed=2 resolution 20]
Micha
Am 04.06.2015 um 11:47 schrieb
Gerd Petermann:
Hi Micha,
lines 119 and 120 in lines (r3605) are:
highway=motorway_link (mkgmap:exit_hint=true |
mkgmap:dest_hint=true) [0x06 road_class=3 road_speed=2
resolution 20]
highway=motorway_link [0x09 road_class=3 road_speed=2
resolution 20]
If you change line 119 as suggested the rule in line 120
is never triggered, therefore you will not have a type
0x09 for the
motorway_link.
Gerd
Date: Thu, 4 Jun 2015 11:36:01
+0200
From: micha.l...@web.de
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] process-exits and Oregon 600
Hi Gerd,
trying to reproduce the problem with the default style
made things clearer. If you change line 119 in lines
to:
highway=motorway_link { name 'generic_exit' } [0x02
road_class=3 road_speed=2 resolution 20]
routing hints point to generic_exit. I did a few more
test, and it seems that there's two ways to get proper
routing:
1. Make segments 1 3 polyline 0x09 (named or not
doesn't matter), and segment 2 any type except 0x08 or
0x09 (didn't test that, taken from the documentation)
2. If segments 1 3 are not 0x09 then don't name
them, and again segment 2 any type except 0x08 or 0x09
Micha
Am 04.06.2015 um 09:30
schrieb Gerd Petermann:
Hi Micha,
it's hard to understand without seeing your complete
style.
Maybe you can post a link to it?
If not, please describe in detail how to reproduce
the problem
with the default style and give an example route
that shows what you get with and without the
modification.
thanks,
Gerd
Date: Thu, 4 Jun 2015
09:20:23 +0200
From: micha.l...@web.de
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] process-exits and Oregon
600
Hi Gerd,
my style did (in this order) assign hints to
exits, and at the very end, assign generic names
to all leftover unnamed roads.
Re: [mkgmap-dev] POIs without POI-search
Am Freitag, 5. Juni 2015, 08:46:36 schrieb Arndt: Hi Arndt you can use these types 0x2900-?, they are visible in 'all POIs', but not in other categories We, Franco and i, made a lot of tests to make sure how POIs types are sorted by the garmin devices. Bernd Hello experts, there are many POIs like barrier, traffic lights, trees an so on. Is it possible to show them in the map, but without a hit in the poi-search? Best regards Arndt -- amarok2 now playing: ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] POIs without POI-search
Hi POIs on Garmin sdevices are really complicate things. To get them on the display is simplier as to remove them from the POI-list or sort them in the right cat there are some groups invisible if there is no such POI in the OSM-data. # additional Cat Convenience before Florist, use with care ## ok # [0x2e0e resolution 24] but it is also possible that a POI is in more then one group, # Convenience # Bedarfsartikel shop=convenience[0x2e06 resolution 24] is also below Fuel/Convenience But IMHO it is impossible to remove a POI completly from lists without side effects. Please take a look to my inc/points, maybe it helps you Bernd Am Freitag, 5. Juni 2015, 10:27:06 schrieb Gerd Petermann: Hi Arndt, AFAIK it depends on the Garmin device. Some show only indexed POI, others show all. I think that makes sense, a Point Of Interest must be something that you want to be able to find ;-) Gerd Date: Fri, 5 Jun 2015 09:59:02 +0200 From: ar...@speichenkarte.de To: weigelt.be...@web.de; mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] POIs without POI-search Thanks,is it possibel too, that the POIs NOT visible in AllPois? Arndt Ursprüngliche Nachricht Von: Bernd Weigelt Datum:05.06.2015 09:36 (GMT+01:00) An: Arndt , Development list for mkgmap Betreff: Re: [mkgmap-dev] POIs without POI-search Am Freitag, 5. Juni 2015, 08:46:36 schrieb Arndt: Hi Arndt you can use these types 0x2900-?, they are visible in 'all POIs', but not in other categories We, Franco and i, made a lot of tests to make sure how POIs types are sorted by the garmin devices. Bernd Hello experts, there are many POIs like barrier, traffic lights, trees an so on. Is it possible to show them in the map, but without a hit in the poi-search? Best regards Arndt -- amarok2 now playing: ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] POIs without POI-search
Hello experts, there are many POIs like barrier, traffic lights, trees an so on. Is it possible to show them in the map, but without a hit in the poi-search? Best regards Arndt___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r3607: - exit-from-link-v1.patch : use also primary_link ways in options --process-exits and --process-destination
Version mkgmap-r3607 was committed by gerd on Fri, 05 Jun 2015 - exit-from-link-v1.patch : use also primary_link ways in options --process-exits and --process-destination Update and improve documentation of the options ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Water polygons in default style
You are right. This bug is also present in default style. El 05/06/15 a las 13:59, GerdP escribió: Hi Carlos, please check, I think the rules landuse=basin|landuse=reservoir area_size()125000 [0x3f resolution 18] landuse=basin|landuse=reservoir area_size()35000 [0x3f resolution 20] landuse=basin|landuse=reservoir [0x3f resolution 22] are missing brakets. (landuse=basin|landuse=reservoir) ... Gerd Carlos Dávila-2 wrote According to wiki [1] landuse=reservoir and natural=water+water=reservoir are equivalent, but the latter (and preferred) form is missing in default style. Another thing to comment is that all water bodies are treated the same in default style, despite they can vary from a few square meters (ponds) to thousands hectares. I've been playing a bit with area_size() and found some values that avoid too small water polygons at certain zoom levels in MapSource (it may require some more test though). Below is current water_polygons file in my style. Do you think it's worth including such rules in default style? landuse=basin|landuse=reservoir area_size()125000 [0x3f resolution 18] landuse=basin|landuse=reservoir area_size()35000 [0x3f resolution 20] landuse=basin|landuse=reservoir [0x3f resolution 22] natural=bay [0x3d resolution 18] natural=glacier [0x4d resolution 18] natural=marsh [0x51 resolution 20] natural=mud [0x51 resolution 20] natural=wetland [0x51 resolution 20] natural=water water=reservoir area_size()125000 [0x3f resolution 18] natural=water water=reservoir area_size()35000 [0x3f resolution 20] natural=water water=reservoir [0x3f resolution 22] natural=water area_size()125000 [0x3c resolution 18] natural=water area_size()35000 [0x3c resolution 20] natural=water [0x3c resolution 22] natural=waterfall | waterway=waterfall [0x47 resolution 21] natural=sea [0x32 resolution 10] waterway=riverbank [0x46 resolution 20] [1] http://wiki.openstreetmap.org/wiki/Key:water ___ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- View this message in context: http://gis.19327.n5.nabble.com/Water-polygons-in-default-style-tp5847228p5847230.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Water polygons in default style
El 05/06/15 a las 14:11, Carlos Dávila escribió: This bug is also present in default style. Not really, sorry ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Water polygons in default style
According to wiki [1] landuse=reservoir and natural=water+water=reservoir are equivalent, but the latter (and preferred) form is missing in default style. Another thing to comment is that all water bodies are treated the same in default style, despite they can vary from a few square meters (ponds) to thousands hectares. I've been playing a bit with area_size() and found some values that avoid too small water polygons at certain zoom levels in MapSource (it may require some more test though). Below is current water_polygons file in my style. Do you think it's worth including such rules in default style? landuse=basin|landuse=reservoir area_size()125000 [0x3f resolution 18] landuse=basin|landuse=reservoir area_size()35000 [0x3f resolution 20] landuse=basin|landuse=reservoir [0x3f resolution 22] natural=bay [0x3d resolution 18] natural=glacier [0x4d resolution 18] natural=marsh [0x51 resolution 20] natural=mud [0x51 resolution 20] natural=wetland [0x51 resolution 20] natural=water water=reservoir area_size()125000 [0x3f resolution 18] natural=water water=reservoir area_size()35000 [0x3f resolution 20] natural=water water=reservoir [0x3f resolution 22] natural=water area_size()125000 [0x3c resolution 18] natural=water area_size()35000 [0x3c resolution 20] natural=water [0x3c resolution 22] natural=waterfall | waterway=waterfall [0x47 resolution 21] natural=sea [0x32 resolution 10] waterway=riverbank [0x46 resolution 20] [1] http://wiki.openstreetmap.org/wiki/Key:water ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Water polygons in default style
Hi Carlos, please check, I think the rules landuse=basin|landuse=reservoir area_size()125000 [0x3f resolution 18] landuse=basin|landuse=reservoir area_size()35000 [0x3f resolution 20] landuse=basin|landuse=reservoir [0x3f resolution 22] are missing brakets. (landuse=basin|landuse=reservoir) ... Gerd Carlos Dávila-2 wrote According to wiki [1] landuse=reservoir and natural=water+water=reservoir are equivalent, but the latter (and preferred) form is missing in default style. Another thing to comment is that all water bodies are treated the same in default style, despite they can vary from a few square meters (ponds) to thousands hectares. I've been playing a bit with area_size() and found some values that avoid too small water polygons at certain zoom levels in MapSource (it may require some more test though). Below is current water_polygons file in my style. Do you think it's worth including such rules in default style? landuse=basin|landuse=reservoir area_size()125000 [0x3f resolution 18] landuse=basin|landuse=reservoir area_size()35000 [0x3f resolution 20] landuse=basin|landuse=reservoir [0x3f resolution 22] natural=bay [0x3d resolution 18] natural=glacier [0x4d resolution 18] natural=marsh [0x51 resolution 20] natural=mud [0x51 resolution 20] natural=wetland [0x51 resolution 20] natural=water water=reservoir area_size()125000 [0x3f resolution 18] natural=water water=reservoir area_size()35000 [0x3f resolution 20] natural=water water=reservoir [0x3f resolution 22] natural=water area_size()125000 [0x3c resolution 18] natural=water area_size()35000 [0x3c resolution 20] natural=water [0x3c resolution 22] natural=waterfall | waterway=waterfall [0x47 resolution 21] natural=sea [0x32 resolution 10] waterway=riverbank [0x46 resolution 20] [1] http://wiki.openstreetmap.org/wiki/Key:water ___ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- View this message in context: http://gis.19327.n5.nabble.com/Water-polygons-in-default-style-tp5847228p5847230.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r3608: change type 0x2b03 to 0x2b05 for camping, 0x2b03 is not
0x2b03 is not listed in POI search on modern devices I don't understand that statement. Are you saying that type 0x2b03 cannot be displayed on modern devices? If it's not listed in POI search, how is that determined? On Fri, Jun 5, 2015 at 9:38 AM, svn commit s...@mkgmap.org.uk wrote: Version mkgmap-r3608 was committed by gerd on Fri, 05 Jun 2015 change type 0x2b03 to 0x2b05 for camping, 0x2b03 is not listed in POI search on modern devices ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r3608: change type 0x2b03 to 0x2b05 for camping, 0x2b03 is not
Version mkgmap-r3608 was committed by gerd on Fri, 05 Jun 2015 change type 0x2b03 to 0x2b05 for camping, 0x2b03 is not listed in POI search on modern devices ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] index problem camp_site
Hi, I've almost forgotten this issue. I've changed the default style with r3608. Gerd GerdP wrote Hi all, ligfietser wrote So what is better? A wrong symbol could be corrected with a typ file. Better than not findable at all. I would suggest to replace 0x2b03 for 0x2b05 +1 Gerd -- View this message in context: http://gis.19327.n5.nabble.com/index-problem-camp-site-tp5844807p5847271.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] POIs without POI-search
I've been able to find out which POIs on my Oregon 450 and 600 are searchable and which are not using the following method: 1) Create a 'fictitious' mp file with POIs ranging from say 2a00 to 7F00 and an another one from 11500 to 14400 2) Use the type number as labels 3) Have the coordinates fairly close together so it can be scanned easily in Basecamp etc as well. 4) use mkgmap to parse the files and dump on device. You will notice the search differences between your device and say Basecamp You will also discover new search categories, ie Book Store. You also discover which types as yet not used by Garmin -- View this message in context: http://gis.19327.n5.nabble.com/POIs-without-POI-search-tp5847187p5847264.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] POIs without POI-search
Hi Gerd Will do this gladly. Will have to extract the code from another program and create a separate GUI so the user can specify the range - should be ready tomorrow. r Nick -- View this message in context: http://gis.19327.n5.nabble.com/POIs-without-POI-search-tp5847187p5847266.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] POIs without POI-search
Hi Nick, I think we should add such a file to the mkgmap dist. Would you mind to post a link to yours? Gerd Date: Fri, 5 Jun 2015 09:19:07 -0700 From: o...@pinns.co.uk To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] POIs without POI-search I've been able to find out which POIs on my Oregon 450 and 600 are searchable and which are not using the following method: 1) Create a 'fictitious' mp file with POIs ranging from say 2a00 to 7F00 and an another one from 11500 to 14400 2) Use the type number as labels 3) Have the coordinates fairly close together so it can be scanned easily in Basecamp etc as well. 4) use mkgmap to parse the files and dump on device. You will notice the search differences between your device and say Basecamp You will also discover new search categories, ie Book Store. You also discover which types as yet not used by Garmin -- View this message in context: http://gis.19327.n5.nabble.com/POIs-without-POI-search-tp5847187p5847264.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] IndexOutOfBoundsException in US map with mkgmap 3605
Hi Gerd, Thanks for the quick fix - r3606 worked! Ben On Thu, Jun 4, 2015 at 5:10 PM, GerdP gpetermann_muenc...@hotmail.com wrote: Hi Ben, please try again with r3606. It should either report errors with the tile name or run without problems. Gerd Ben Konrath wrote Hi, I have a IndexOutOfBoundsException while generating a map of the United States with mkgmap 3605. I think this is related to the recent house number merge because 3598 worked fine and the problem seems to come from house number related code. java.lang.IndexOutOfBoundsException: bitIndex 0: -1 at java.util.BitSet.get(BitSet.java:615) at uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberGenerator$RoadSegmentIndex.createHousenumberMatch(HousenumberGenerator.java:2055) at uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberGenerator.findClosestRoadsToHouse(HousenumberGenerator.java:794) at uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberGenerator.generate(HousenumberGenerator.java:621) at uk.me.parabola.mkgmap.osmstyle.StyledConverter.end(StyledConverter.java:619) at uk.me.parabola.mkgmap.reader.osm.ElementSaver.convert(ElementSaver.java:250) at uk.me.parabola.mkgmap.reader.osm.o5m.O5mBinMapDataSource.load(O5mBinMapDataSource.java:53) at uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.load(OsmMapDataSource.java:130) at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:154) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:52) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:255) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:251) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Here's how I'm calling mkgamp: java -Xmx14000M -jar -Dlog.config=/home/ben/osm/confs/logging.properties /home/ben/osm/mkgmap/dist/mkgmap.jar --latin1 --gmapsupp --index --route --min-size-polygon --series-name=United States 2015.06.03 --family-name=United States 2015.06.03 --location-autofill=bounds,is_in,nearest --remove-ovm-work-files --bounds=/home/ben/osm/data/bounds --precomp-sea=/home/ben/osm/data/sea_20150602.zip --generate-sea --add-pois-to-areas --process-destination --process-exits --pois-to-areas-placement=entrance=main;entrance=yes;building=entrance --check-roundabout-flares --remove-short-arcs --family-id=14244 --product-id=1 --make-opposite-cycleways --drive-on=detect,right --check-roundabouts --housenumbers -c template.args --description=United States 2015.06.03 /home/ben/osm/confs/typ.txt Obviously a full US map is big so I don't know exactly where the problem is. What's the best way to help narrow done the problem? Let me know what I can do. Thanks, Ben ___ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- View this message in context: http://gis.19327.n5.nabble.com/IndexOutOfBoundsException-in-US-map-with-mkgmap-3605-tp5847079p5847116.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r3608: change type 0x2b03 to 0x2b05 for camping, 0x2b03 is not
Hi Dave, sorry, I tried to find a short statement for the problem discussed here: http://gis.19327.n5.nabble.com/index-problem-camp-site-tp5844807.html Gerd Dave Swarthout wrote 0x2b03 is not listed in POI search on modern devices I don't understand that statement. Are you saying that type 0x2b03 cannot be displayed on modern devices? If it's not listed in POI search, how is that determined? On Fri, Jun 5, 2015 at 9:38 AM, svn commit lt; svn@.org gt; wrote: Version mkgmap-r3608 was committed by gerd on Fri, 05 Jun 2015 change type 0x2b03 to 0x2b05 for camping, 0x2b03 is not listed in POI search on modern devices ___ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- View this message in context: http://gis.19327.n5.nabble.com/Commit-r3608-change-type-0x2b03-to-0x2b05-for-camping-0x2b03-is-not-tp5847269p5847280.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r3609: revert unintended changes in comments
Version mkgmap-r3609 was committed by gerd on Sat, 06 Jun 2015 revert unintended changes in comments ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
