Re: [mkgmap-dev] splitter removes multipolygon-tags
Hi Henning, I tried with the areas.list from your homepage. It is not exactly like the one you used to produce the log, but I was able to reproduce the problem. It is caused by overlapping tiles in this area. I am now looking for a correction. Gerd From: gpetermann_muenc...@hotmail.com To: mkgmap-dev@lists.mkgmap.org.uk Date: Thu, 8 May 2014 07:18:12 +0200 Subject: Re: [mkgmap-dev] splitter removes multipolygon-tags Hi Henning, please post the areas.list for the planet.I hope I can reproduce the problem with a smaller input like Germany . Gerd Date: Wed, 7 May 2014 23:39:18 +0200 From: o...@aighes.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] splitter removes multipolygon-tags Hi Gerd, sorry for delay. I've continued investigation. If I only split the single tile (6211), everything seems to be fine. single tile: http://www.aighes.de/data/mkgmap/6211.o5m http://www.aighes.de/data/mkgmap/splitter_6211.log all ~1500 maptiles at once: http://www.aighes.de/data/mkgmap/1211.o5m http://www.aighes.de/data/mkgmap/splitter_1211.log Henning ___ 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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] splitter r325: improved split algo and new option
Thanks Gerd! This is valuable information for those of us processing large areas of the planet. Unfortunately there is no additional speedup for me because I already use o5m because of osmupdate (to keep a local planet copy up-to-date). On 07/05/2014 11:59, Gerd Petermann wrote: Hi Felix, try o5m for both input and output, it is much faster. The command osmcovert --drop-version europe-latest.osm.pbf -o=europe.o5m runs quite fast (~70 seconds on my machine), the o5m file is ~2.430 MB, the pbf file has 2.104 MB. Splitter is much faster reading from o5m when the keep-complete option is in use. (210 secs for the o5m, 441 for pbf) With --output=pbf both are slower, and mkgmap is also much slower. All times with I/O on one normal hard disk. Even better results if you have two different disks for reading and writing. Gerd Date: Wed, 7 May 2014 11:37:58 +0200 From: extremecar...@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] splitter r325: improved split algo and new option Well I still use pbf and not o5m. First pbf is smaller.. Second - Geofabrik only offers pbf - that's why I stayed with it. I don't think I can cut a lot of time by first converting to 05m, then hand it over to splitter... Actually I also let splitter output pbf... Maybe I could change that in future to 05m.. On 07.05.2014 11:36, Gerd Petermann wrote: Hi Felix, well, nowadays splitter performance mostly depends on I/O if you use o5m format for input and output and give enough heap. Reg. mkgmap performance improvements: yes, that's what I expected. In short, the branch improved the evaluation of tags and the creation of the NOD file. Gerd Date: Wed, 7 May 2014 11:29:10 +0200 From: extremecar...@gmail.com mailto:extremecar...@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk mailto:mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] splitter r325: improved split algo and new option Well - I'll update all my maps on Thursday again, to recheck. Maybe it has to do with increasing-maxnodes? Though I thought the higher the max-nodes, the faster... And I only meant splitter. I upgraded mkgmap at the same time (now integrating performance branch changes) - so mkgmap by itself got faster (though it depends on the country - seems like well mapped countries profit a lot more (e.g. Austria like 30% time off), than countries where few continue commands will be in action cause their mapping is basic like Asia). I'm not using any pre-split files or cached files of any sort either... On 07.05.2014 06:49, Gerd Petermann wrote: Hi Felix, reg. speed: I can't reproduce that. I compared a split of Germany, both versions (r321 and r325) are more or less running the same time. (I've executed both programs two times to make sure that disk caches are not causing big differences) Or did you mean the combination of splitter + mkgmap to process e.g. Asia? Gerd Date: Tue, 6 May 2014 18:22:00 +0200 From: extremecar...@gmail.com mailto:extremecar...@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk mailto:mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] splitter r325: improved split algo and new option Seems to be much better now. I don't think I can increase the max-nodes value though, but for most maps the new algo creates less tiles for the same max-nodes value (e.g. Austria from 43 down to 35 for me, with the smallest tile now around 5MB instead of 2.8, and the biggest 12MB instead of 11MB, for Asia I simultaneously increased max-nodes from 800k to 900k- so I'm down from 624 tiles to 493 and size from 970KB-16MB to now ). So it still seems to depend on the country, but it's already a lot better... It's a bit slower (about 10% more time) On 06.05.2014 13:56, Gerd Petermann wrote: Hi all, I've applied num-tiles-v1.patch and improved the split algo, see http://gis.19327.n5.nabble.com/mkgmap-ToDo-list-tp5803388p5805165.html It is now less likely that splitter creates tiles with a low number of nodes, it is more likely that all tiles have nearly the same number of nodes, and typically you will see fewer tiles. Maybe this also means that you can increase the max-nodes value. I hope this also reduces the need for complex interactions between spltter and mkgmap. Gerd
Re: [mkgmap-dev] splitter r325: improved split algo and new option
Hi Lambertus, maybe also look at https://wiki.openstreetmap.org/wiki/Mkgmap/help/splitter#Tuning (the page needs some updates, but that part is correct) Gerd Date: Thu, 8 May 2014 09:31:28 +0200 From: o...@na1400.info To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] splitter r325: improved split algo and new option Thanks Gerd! This is valuable information for those of us processing large areas of the planet. Unfortunately there is no additional speedup for me because I already use o5m because of osmupdate (to keep a local planet copy up-to-date). On 07/05/2014 11:59, Gerd Petermann wrote: Hi Felix, try o5m for both input and output, it is much faster. The command osmcovert --drop-version europe-latest.osm.pbf -o=europe.o5m runs quite fast (~70 seconds on my machine), the o5m file is ~2.430 MB, the pbf file has 2.104 MB. Splitter is much faster reading from o5m when the keep-complete option is in use. (210 secs for the o5m, 441 for pbf) With --output=pbf both are slower, and mkgmap is also much slower. All times with I/O on one normal hard disk. Even better results if you have two different disks for reading and writing. Gerd Date: Wed, 7 May 2014 11:37:58 +0200 From: extremecar...@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] splitter r325: improved split algo and new option Well I still use pbf and not o5m. First pbf is smaller.. Second - Geofabrik only offers pbf - that's why I stayed with it. I don't think I can cut a lot of time by first converting to 05m, then hand it over to splitter... Actually I also let splitter output pbf... Maybe I could change that in future to 05m.. On 07.05.2014 11:36, Gerd Petermann wrote: Hi Felix, well, nowadays splitter performance mostly depends on I/O if you use o5m format for input and output and give enough heap. Reg. mkgmap performance improvements: yes, that's what I expected. In short, the branch improved the evaluation of tags and the creation of the NOD file. Gerd Date: Wed, 7 May 2014 11:29:10 +0200 From: extremecar...@gmail.com mailto:extremecar...@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk mailto:mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] splitter r325: improved split algo and new option Well - I'll update all my maps on Thursday again, to recheck. Maybe it has to do with increasing-maxnodes? Though I thought the higher the max-nodes, the faster... And I only meant splitter. I upgraded mkgmap at the same time (now integrating performance branch changes) - so mkgmap by itself got faster (though it depends on the country - seems like well mapped countries profit a lot more (e.g. Austria like 30% time off), than countries where few continue commands will be in action cause their mapping is basic like Asia). I'm not using any pre-split files or cached files of any sort either... On 07.05.2014 06:49, Gerd Petermann wrote: Hi Felix, reg. speed: I can't reproduce that. I compared a split of Germany, both versions (r321 and r325) are more or less running the same time. (I've executed both programs two times to make sure that disk caches are not causing big differences) Or did you mean the combination of splitter + mkgmap to process e.g. Asia? Gerd Date: Tue, 6 May 2014 18:22:00 +0200 From: extremecar...@gmail.com mailto:extremecar...@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk mailto:mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] splitter r325: improved split algo and new option Seems to be much better now. I don't think I can increase the max-nodes value though, but for most maps the new algo creates less tiles for the same max-nodes value (e.g. Austria from 43 down to 35 for me, with the smallest tile now around 5MB instead of 2.8, and the biggest 12MB instead of 11MB, for Asia I simultaneously increased max-nodes from 800k to 900k- so I'm down from 624 tiles to 493 and size from 970KB-16MB to now ). So it still seems to depend on the country, but it's already a lot better... It's a bit slower (about 10% more time) On 06.05.2014 13:56, Gerd Petermann wrote: Hi all, I've applied num-tiles-v1.patch and improved the split algo, see
Re: [mkgmap-dev] problem with address search and --code-page
Thanks for the hint with city search/address search difference - I've found a nasty bug in my style :). Sorry for your trouble. best regards Michal Rogala 2014-05-07 15:27 GMT+02:00 Steve Ratcliffe st...@parabola.me.uk: On 05/05/14 13:45, Michał Rogala wrote: Unfortunately, I've found an error with sort2 patch - many towns and villages are gone from index. This is not related to any map tile - it seems to be randomly distributed. MapSource/BaseCamp works fine. If you still have my map files - you can try to find towns like Mielnik, Czeremcha or Marysinek. I can find these in MapSource if I use city search, but they do not show up in the city field of address search. I believe this is because those cities do not contain any named streets. If that is so, then it is expected behaviour, unless you think that it worked with a previous version. ..Steve ___ 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] splitter removes multipolygon-tags
Hi Henning, the problem is fixed with latest splitter (r327). It was introduced with r316. Gerd Date: Wed, 7 May 2014 23:39:18 +0200 From: o...@aighes.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] splitter removes multipolygon-tags Hi Gerd, sorry for delay. I've continued investigation. If I only split the single tile (6211), everything seems to be fine. single tile: http://www.aighes.de/data/mkgmap/6211.o5m http://www.aighes.de/data/mkgmap/splitter_6211.log all ~1500 maptiles at once: http://www.aighes.de/data/mkgmap/1211.o5m http://www.aighes.de/data/mkgmap/splitter_1211.log Henning ___ 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
[mkgmap-dev] Java tuning hint
Hi all, today I found a hint that seems to help mkgmap: http://java-performance.info/string-intern-in-java-6-7-8/ In short, try java run time parameter -XX:StringTableSize=13 for mkgmap. Gerd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Java tuning hint
Am Donnerstag, 8. Mai 2014, 17:13:43 schrieb Gerd Petermann: In short, try java run time parameter -XX:StringTableSize=13 for mkgmap. IMHO you forgot a Zero ;-) -XX:StringTableSize=103 Bernd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Java tuning hint
Hi Bernd, I tried both, and the smaller values seemed to work better for mkgmap. I guess it depends on the input files what value is best, but at least the default 1009 doesn't work well, so any much higher prime value should help. Gerd From: weigelt.be...@web.de To: mkgmap-dev@lists.mkgmap.org.uk Date: Thu, 8 May 2014 17:30:48 +0200 Subject: Re: [mkgmap-dev] Java tuning hint Am Donnerstag, 8. Mai 2014, 17:13:43 schrieb Gerd Petermann: In short, try java run time parameter -XX:StringTableSize=13 for mkgmap. IMHO you forgot a Zero ;-) -XX:StringTableSize=103 Bernd ___ 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] Java tuning hint
Am Donnerstag, 8. Mai 2014, 17:33:22 schrieb Gerd Petermann: Hello Gerd I've made three tests with my bonn extract without -XX:StringTableSize Time started: Thu May 08 17:57:43 CEST 2014 Time finished: Thu May 08 18:04:54 CEST 2014 Total time taken: 430804ms with -XX:StringTableSize=13 Time started: Thu May 08 18:07:33 CEST 2014 Time finished: Thu May 08 18:14:20 CEST 2014 Total time taken: 406425ms with -XX:StringTableSize=103 time started: Thu May 08 18:16:20 CEST 2014 Time finished: Thu May 08 18:23:06 CEST 2014 Total time taken: 405556ms This are tests on my small laptop with 3.6 GB RAM with 64bit Linux Bernd I tried both, and the smaller values seemed to work better for mkgmap. I guess it depends on the input files what value is best, but at least the default 1009 doesn't work well, so any much higher prime value should help. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Java tuning hint
Hi Bernd, I got similar results for a larger set on my PC. I think the large value is no improvement, and if I got that right it means that some MB can't be used for something else. I assume your Bonn extract will not even contain 103 different strings. Gerd From: weigelt.be...@web.de To: mkgmap-dev@lists.mkgmap.org.uk Date: Thu, 8 May 2014 18:28:22 +0200 Subject: Re: [mkgmap-dev] Java tuning hint Am Donnerstag, 8. Mai 2014, 17:33:22 schrieb Gerd Petermann: Hello Gerd I've made three tests with my bonn extract without -XX:StringTableSize Time started: Thu May 08 17:57:43 CEST 2014 Time finished: Thu May 08 18:04:54 CEST 2014 Total time taken: 430804ms with -XX:StringTableSize=13 Time started: Thu May 08 18:07:33 CEST 2014 Time finished: Thu May 08 18:14:20 CEST 2014 Total time taken: 406425ms with -XX:StringTableSize=103 time started: Thu May 08 18:16:20 CEST 2014 Time finished: Thu May 08 18:23:06 CEST 2014 Total time taken: 405556ms This are tests on my small laptop with 3.6 GB RAM with 64bit Linux Bernd I tried both, and the smaller values seemed to work better for mkgmap. I guess it depends on the input files what value is best, but at least the default 1009 doesn't work well, so any much higher prime value should help. ___ 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
[mkgmap-dev] finalize and some ways with overlays
Hi
i have a problem, that the finalize section to often calls inc/access, in my
case for every overlay and the routable way.
IMHO it should call it only for the routable way(s) with road_speed and
road_class.
an example
lines:
highway=cycleway[0x1200a resolution 23-23 continue]
highway=cycleway[0x1100a resolution 24 continue]
highway=cycleway[0x0a resolution 24 road_class=0 road_speed=1]
finalize
# The finalizer section is executed for each element when a rule with an
element type matches
# calculate the access rules
include 'inc/access' ;
--
inc/access includes for testing some ways this additional test
highway=* bicycle=official { echo ' 1 ${highway} | ${bicycle} |
${mkgmap:bicycle} ' }
output for this way
http://www.openstreetmap.org/way/243198140
243198140: 1 cycleway | official | null
243198140: 1 cycleway | official | null
243198140: 1 cycleway | official | null
..
How can i fix this?
Or is there something wrong in my style?
Bernd
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] finalize and some ways with overlays
Hi Bernd,
I think that's the idea of the finalize section. It is called for
each added element.
Gerd
From: weigelt.be...@web.de
To: mkgmap-dev@lists.mkgmap.org.uk
Date: Thu, 8 May 2014 19:34:49 +0200
Subject: [mkgmap-dev] finalize and some ways with overlays
Hi
i have a problem, that the finalize section to often calls inc/access, in my
case for every overlay and the routable way.
IMHO it should call it only for the routable way(s) with road_speed and
road_class.
an example
lines:
highway=cycleway [0x1200a resolution 23-23 continue]
highway=cycleway [0x1100a resolution 24 continue]
highway=cycleway [0x0a resolution 24 road_class=0 road_speed=1]
finalize
# The finalizer section is executed for each element when a rule with an
element type matches
# calculate the access rules
include 'inc/access' ;
--
inc/access includes for testing some ways this additional test
highway=* bicycle=official { echo ' 1 ${highway} | ${bicycle} |
${mkgmap:bicycle} ' }
output for this way
http://www.openstreetmap.org/way/243198140
243198140: 1 cycleway | official | null
243198140: 1 cycleway | official | null
243198140: 1 cycleway | official | null
..
How can i fix this?
Or is there something wrong in my style?
Bernd
___
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] finalize and some ways with overlays
Am Donnerstag, 8. Mai 2014, 19:42:54 schrieb Gerd Petermann: Hi but now there are a lot of loops for tests that do nothing, except heating my CPU ;-) I don't know, how can this be done better Bernd I think that's the idea of the finalize section. It is called for each added element. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] finalize and some ways with overlays
Hi,
maybe we can add the garmin-id, road class etc. as tags before the
finalize section is started so it is possible to add checks to the
rules, that only routable elements execute the inc/access rules.
Indeed this would be much easier if conditional includes are possible,
so something like:
isRoutable() { include 'inc/access'; }
WanMil
Hi
but now there are a lot of loops for tests that do nothing, except heating my
CPU ;-)
I don't know, how can this be done better
Bernd
I think that's the idea of the finalize section. It is called for
each added element.
___
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
[mkgmap-dev] Problem with barrier=gate and access=no
Hi!
I am creating a local map with mkgmap (r3262), with the default style
and the following relevant options:
--add-pois-to-areas \
--add-pois-to-lines \
--adjust-turn-headings \
--check-roundabout-flares \
--check-roundabouts \
--code-page=1252 \
--drive-on-right \
--gmapsupp \
--housenumbers \
--index \
--latin1 \
--levels=0:24,1:22,2:20,3:18,4:16,5:14 \
--location-autofill=is_in,nearest \
--make-poi-index \
--merge-lines \
--min-size-polygon=8 \
--name-tag-list=int_name,name,alt_name \
--poi-address \
--pois-to-areas-placement=entrance=main;entrance=yes;building=entrance
\
--polygon-size-limits=24:12,18:10,16:8,12:4,10:0 \
--preserve-element-order \
--process-destination \
--process-exits \
--reduce-point-density=3 \
--reduce-point-density-polygon=8 \
--remove-short-arcs \
--report-dead-ends \
--report-similar-arcs \
--route
From what I see at points (from the default style), we have:
barrier=gate
{ add mkgmap:bicycle=yes;
add mkgmap:foot=yes;
addaccess no;
set mkgmap:road-speed=0; }
If I properly understand this, by default we will have an access=no
for vehicles when it finds a barrier=gate (and it should have the same
effect where we have barrier=gate + access=no).
But I am seeing an user saying that on places where there are
barrier=gate + acess=no (like this node
http://www.openstreetmap.org/node/2702166795), his GPS Garmin nüvi 40
is still routing him through this way (while OSRM properly understands
the acess restriction).
How can I verify if mkgmap is properly creating a restriction on
barriers that have acess=no, please? (I don't own a Garmin to test,
just in case)
Thank you!
Best regards,
Nelson
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Problem with barrier=gate and access=no
Hi Nelson,
you have to add option --link-pois-to-ways to get what you want.
Gerd
Nelson A. de Oliveira wrote
Hi!
I am creating a local map with mkgmap (r3262), with the default style
and the following relevant options:
--add-pois-to-areas \
--add-pois-to-lines \
--adjust-turn-headings \
--check-roundabout-flares \
--check-roundabouts \
--code-page=1252 \
--drive-on-right \
--gmapsupp \
--housenumbers \
--index \
--latin1 \
--levels=0:24,1:22,2:20,3:18,4:16,5:14 \
--location-autofill=is_in,nearest \
--make-poi-index \
--merge-lines \
--min-size-polygon=8 \
--name-tag-list=int_name,name,alt_name \
--poi-address \
--pois-to-areas-placement=entrance=main;entrance=yes;building=entrance
\
--polygon-size-limits=24:12,18:10,16:8,12:4,10:0 \
--preserve-element-order \
--process-destination \
--process-exits \
--reduce-point-density=3 \
--reduce-point-density-polygon=8 \
--remove-short-arcs \
--report-dead-ends \
--report-similar-arcs \
--route
From what I see at points (from the default style), we have:
barrier=gate
{ add mkgmap:bicycle=yes;
add mkgmap:foot=yes;
addaccess no;
set mkgmap:road-speed=0; }
If I properly understand this, by default we will have an access=no
for vehicles when it finds a barrier=gate (and it should have the same
effect where we have barrier=gate + access=no).
But I am seeing an user saying that on places where there are
barrier=gate + acess=no (like this node
http://www.openstreetmap.org/node/2702166795), his GPS Garmin nüvi 40
is still routing him through this way (while OSRM properly understands
the acess restriction).
How can I verify if mkgmap is properly creating a restriction on
barriers that have acess=no, please? (I don't own a Garmin to test,
just in case)
Thank you!
Best regards,
Nelson
___
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/Problem-with-barrier-gate-and-access-no-tp5805656p5805660.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] Problem with barrier=gate and access=no
Hi Gerd! On Thu, May 8, 2014 at 5:15 PM, GerdP gpetermann_muenc...@hotmail.com wrote: you have to add option --link-pois-to-ways to get what you want. Right. Good to know :-) Thank you very much! Best regards, Nelson ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r3263: Performance: create a polygon in MultipolygonRelation processing only if required and reuse it - no functional change.
Version mkgmap-r3263 was committed by wanmil on Thu, 08 May 2014 Performance: create a polygon in MultipolygonRelation processing only if required and reuse it - no functional change. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] splitter removes multipolygon-tags
Am 08.05.2014 08:38, schrieb Gerd Petermann: Hi Henning, I tried with the areas.list from your homepage. It is not exactly like the one you used to produce the log, but I was able to reproduce the problem. It is caused by overlapping tiles in this area. I am now looking for a correction. Hi Gerd, thanks for taking a look into it. I'm actually let splitter and mkgmap do their jobs and will take a look into the maps tomorrow. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
