Re: [mkgmap-dev] Error on MapSource with r1919
El 07/05/11 15:57, Steve Ratcliffe escribió: > > >> Is there a tool for download to analyse the imgfmt-structure? > > For the disk header I use: http://sourceforge.net/projects/garmin-img/ > The header is the first thing written so there is no need to let it > run to completion on a large file, nor worry if it crashes after > writing the *DSKIMG* file out. I use a patched version (patch > attached against 1.1). I tried to compile the source code from that link + your patch but get the following error: make g++ -c main.cc -g g++ -c garminimg.cc -g g++ -c imgfile.cc -g g++ -c subfile.cc -g g++ -c tre.cc -g g++ -c lbl.cc -g g++ -c rgn.cc -g g++ -c net.cc -g g++ -c nod.cc -g make: *** No hay ninguna regla para construir el objetivo `gmp.o', necesario para `imgdecode'. Alto. (There's no rule to build target `gmp.o' necessary for `imgdecode'. Halt. > > For almost everything else there is a program in > http://svn.mkgmap.org.uk/display/trunk/ that will print the sections. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] problems with rendering of long riverbank (multipolygons)
Recently someone noticed flooding on the openmtbmap in Belgium south of Maastricht: http://forum.gps.nl/viewtopic.php?f=109&t=34597&p=277200#p277200 I have noticed related issues with floodings west of Maastricht on Lambertus' maps and on my own Openfietsmap parts of the same Albertcanal are "dry". Main cause seems a very long multipolygon relation of the Albertcanal: http://www.openstreetmap.org/browse/relation/1424029 On places where the tile borders are crossing this multipolygon mkgmap has problems with rendering (because the ends of the multipolgygon are way outside the tiles). Splitting up the multipolygon in smaller parts in osm seems not the way to solve these rendering problems because I think it's a bug in mkgmap that should be solved here instead of on osm. Any ideas? ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] How do I get a blue sea?
i don't use mapTK, i use this online editor:
http://ati.land.cz/gps/typdecomp/editor.cgi
Am 18.05.2011 22:12, schrieb Roger Calvert:
Thanks for suggestions. No luck so far - please could you advise on
the points below.
Many thanks,
Roger
On 18/05/2011 07:03, michael lohr wrote:
style:
natural=land { name 'land' } [0x10100 resolution 14]
natural=sea { name 'sea' } [0x10f1d resolution 14]
typ:
both 0x10100 and 0x10f1d must be defined, with sea having the lower
drawing priority
Please can you advise me on the entries I should put in the MapTK prj
file to incorporate these in the typ file - I haven't done much with
these!
Am 17.05.2011 22:42, schrieb Carlos Dávila:
El 17/05/11 21:35, Roger Calvert escribió:
I'm using mkgmap to install OSM on my Garmin GPS.
Lakes and rivers come out in blue on both Mapsource and the GPS,
but the sea comes out white. The shoreline appears as a single thin
line.
I am using pbf files of England, Scotland and Wales downloaded from
geofabrik Download-Bereich.
I have the option
'--generate-sea=polygons,extend-sea-sectors,close-gaps=1000' in the
mkgmap command line. The 'polygons' file contains 'natural=sea
[0x32 resolution 18]'.
Any suggestions as to how I might get a blue sea?
Are you using a .TYP file? Do you have 0x32 defined in it?
Yes, both 0x32 and 0x28 are included, with the entry in the MapTK prj
file for 0x32 as
[Polygon]
Type=0x32
DrawOrder=3
String=4,Sea
Color=0,0xff
[END]
___
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
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problems with rendering of long riverbank (multipolygons)
On Thu, May 19, 2011 at 10:33:14AM +0200, Minko wrote: >On places where the tile borders are crossing this multipolygon mkgmap >has problems with rendering (because the ends of the multipolgygon are >way outside the tiles). Splitting up the multipolygon in smaller parts >in osm seems not the way to solve these rendering problems because I >think it's a bug in mkgmap that should be solved here instead of on >osm. Any ideas? I have understood that it is a splitter problem, not a mkgmap problem. I do not know the splitter. How many nodes are there along the multipolygon lines? Any nodes relatively near to the tile border? In Finland, I had a similar problem with Lake Päijänne, which is a single huge multipolygon. I have worked around this problem by moving my tile borders so that they do not cut through the lake. Best regards, Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Error on MapSource with r1919
Hi > I tried to compile the source code from that link + your patch but get > the following error: > make ... > make: *** No hay ninguna regla para construir el objetivo `gmp.o', > necesario para `imgdecode'. Alto. (There's no rule to build target > `gmp.o' necessary for `imgdecode'. Halt. Ah, I guess the patch was really against the cvs version which has a few extra files. Anyway, I've packaged my latest version of it up and you can get it here: URL: http://files.mkgmap.org.uk/download/17/imgdecode-sr-r10.zip Description: A modified version of the imgdecode program (http://sourceforge.net/projects/garmin-img/) that fixes bugs and works with a wider variety of files. The usual ./configure; make; sequence should build it. Thanks ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problems with rendering of long riverbank (multipolygons)
I haven't count them ;-) The multipoolygon stretches out on my map along three tiles (roughly 100km wide). Since this area is mapped quite well, moving the tiles wont help. And I'm talking about different maps that shows issues there (with different tiles) so I think it can only be solved by improving the splitter? Marko wrote: I have understood that it is a splitter problem, not a mkgmap problem. I do not know the splitter. How many nodes are there along the multipolygon lines? Any nodes relatively near to the tile border? In Finland, I had a similar problem with Lake Päijänne, which is a single huge multipolygon. I have worked around this problem by moving my tile borders so that they do not cut through the lake. Best regards, Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problems with rendering of long riverbank (multipolygons)
On Thu, May 19, 2011 at 01:57:43PM +0200, Minko wrote: >I haven't count them ;-) The multipoolygon stretches out on my map >along three tiles (roughly 100km wide). Since this area is mapped quite >well, moving the tiles wont help. And I'm talking about different maps >that shows issues there (with different tiles) so I think it can only >be solved by improving the splitter? From past discussions I have understood that there is a configureable "split radius" in the splitter. The splitter would include all nodes and ways within the tile, and near the tile borders within the split radius. Again, as far as I understand, what it really should do is close closed polygons along the tile borders, by adding imaginary nodes at the tile border. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problems with rendering of long riverbank (multipolygons)
How do I configure this split radius? I have examined the nodes close to the tile borders, they are within 500 m outside of the tile borders. I have splitted my maps with an overlap=3000. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problems with rendering of long riverbank (multipolygons)
Am 19.05.2011 16:43, schrieb Minko: How do I configure this split radius? I have examined the nodes close to the tile borders, they are within 500 m outside of the tile borders. I have splitted my maps with an overlap=3000. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev Hi --overlap is the parameter, which influence the split radius. But this wont help you solving your problem. I also think, that this problem have to be fixed in the splitter. E.g. process MP and other huge polygons in splitter and not in mkgmap. splitter should have all needed information. Another solution would be to keep all nodes and ways inside one tile, which belong to an objekte which has at least one node in the area. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] mkgmap_locator choking if --index not given
Mkgmap locator branch, chokes on compiling Albania... With the following command it just never finishes. It does create a 0bit 6414.img though. c:\OpenMTBMap\maps>start /low /b /wait java -ea -jar -Xmx6500M c:\openmtbmap\mkgmap_locator.jar "--style-file=c:\openmtbmap\new4" --max-jobs=4 --generate-sea=extend-sea-sector s,close-gaps=6000,floodblocker,fbgap=60,fbthres=200,fbratio=0.6 --latin1 "--boundsdirectory=c:\openmtbmap\maps\bounds" --reduce-point-density=4 --nsis --transparent --adjust- turn-headings --add-pois-to-areas --ignore-maxspeeds --x-reduce-point-density-polygon=8 --link-pois-to-ways --ignore-turn-restrictions --min-size-polygon=15 --remove-short-arc s=4 --description=openmtbmap_al --merge-lines --location-autofill=1 --route --country-abbr=al --country-name=albania --mapname=6414 --family-id=6414 --product-id=1 --seri es-name=openmtbmap_albania_19.05.2011 --family-name=mtbmap_al_19.05.2011 --tdbfile --overview-mapname=mapset --keep-going --area-name="albania_19.05.2011_openmtbmap.org" -c c: \openmtbmap\maps\template.albania Well the above wouldn't be really problematic, however last night mkgmap locator branch finished my map of Europe, but choked on creating the mdr.img because there existet three 0bit .img files. I stopped it and created the index within 10minutes after having deleted the offending 0bit files. Now I thought I'll just create all maps without --index, then clean up broken 0bit .img files, and create the index. This is not possible however, as the locator branch chokes when not providing --index. So there needs to be a change that mkgmap itself deletes the 0bit .img files, before creating the mdr.img and mdx files. (note I already used max-nodes 700.000, so Europe worked out at a whopping 1123 .img files, the biggest around 12MB - so I am sure (also seen nothing in log) that further reducing max-nodes won't solve mkgmap to create broken .img files -- on all three there was not a problem related to max-nodes. They simply did not compile. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mkgmap_locator choking if --index not given
Okay even worse, on some countries mkgmap_locator does not work at all. Downloaded today from Geofabrik and breaking up in eternety just producing a 0bit .img file: Serbia and Iceland, Is it possible that if the bounds are not covering the full country, mkgmap_locator crashes?? I'm using the latest "published" Europe boundaries. At least Serbia shouldn't be affected by missing boundaries though On 19.05.2011 18:26, Felix Hartmann wrote: > Mkgmap locator branch, chokes on compiling Albania... > > With the following command it just never finishes. It does create a > 0bit 6414.img though. > > c:\OpenMTBMap\maps>start /low /b /wait java -ea -jar -Xmx6500M > c:\openmtbmap\mkgmap_locator.jar "--style-file=c:\openmtbmap\new4" > --max-jobs=4 --generate-sea=extend-sea-sector > s,close-gaps=6000,floodblocker,fbgap=60,fbthres=200,fbratio=0.6 > --latin1 "--boundsdirectory=c:\openmtbmap\maps\bounds" > --reduce-point-density=4 --nsis --transparent --adjust- > turn-headings --add-pois-to-areas --ignore-maxspeeds > --x-reduce-point-density-polygon=8 --link-pois-to-ways > --ignore-turn-restrictions --min-size-polygon=15 --remove-short-arc > s=4 --description=openmtbmap_al --merge-lines --location-autofill=1 > --route --country-abbr=al --country-name=albania --mapname=6414 > --family-id=6414 --product-id=1 --seri > es-name=openmtbmap_albania_19.05.2011 > --family-name=mtbmap_al_19.05.2011 --tdbfile --overview-mapname=mapset > --keep-going --area-name="albania_19.05.2011_openmtbmap.org" -c c: > \openmtbmap\maps\template.albania > > > > Well the above wouldn't be really problematic, however last night > mkgmap locator branch finished my map of Europe, but choked on > creating the mdr.img because there existet three 0bit .img files. I > stopped it and created the index within 10minutes after having deleted > the offending 0bit files. > > Now I thought I'll just create all maps without --index, then clean up > broken 0bit .img files, and create the index. This is not possible > however, as the locator branch chokes when not providing --index. > > > > So there needs to be a change that mkgmap itself deletes the 0bit .img > files, before creating the mdr.img and mdx files. (note I already used > max-nodes 700.000, so Europe worked out at a whopping 1123 .img files, > the biggest around 12MB - so I am sure (also seen nothing in log) that > further reducing max-nodes won't solve mkgmap to create broken .img > files -- on all three there was not a problem related to max-nodes. > They simply did not compile. > ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problems with rendering of long riverbank (multipolygons)
> Recently someone noticed flooding on the openmtbmap in Belgium south of > Maastricht: > http://forum.gps.nl/viewtopic.php?f=109&t=34597&p=277200#p277200 > > I have noticed related issues with floodings west of Maastricht on Lambertus' > maps and on my own Openfietsmap parts of the same Albertcanal are "dry". Main > cause seems a very long multipolygon relation of the Albertcanal: > http://www.openstreetmap.org/browse/relation/1424029 > > On places where the tile borders are crossing this multipolygon mkgmap has > problems with rendering (because the ends of the multipolgygon are way > outside the tiles). Splitting up the multipolygon in smaller parts in osm > seems not the way to solve these rendering problems because I think it's a > bug in mkgmap that should be solved here instead of on osm. Any ideas? > If you assume that the multipolygon algorithm has a problem you should change the log level of the Multipolygon class: uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation.level=FINE Enabling the logging is described at http://wiki.openstreetmap.org/wiki/Mkgmap/dev#Enabling_Debugging You can search the logfiles for the relation id and check what the multipolygon code is doing. The logfiles get big so it might be good to compile the relevant tiles only. If you have questions just send the logfile. WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mkgmap_locator choking if --index not given
I haven't observed such a situation up to now. If you want to know what happens you might connect with jvisualvm and provide the stack trace of the situation when you think that mkgmap locator crashes. The locator branch still has pre alpha status so everything is possible. WanMil P.S.: By the way: did you solve your compile problems? P.P.S.: I cannot reproduce that the locator branch chokes when not providing --index. Did you apply any patches? > Okay even worse, on some countries mkgmap_locator does not work at all. > > Downloaded today from Geofabrik and breaking up in eternety just > producing a 0bit .img file: Serbia and Iceland, > Is it possible that if the bounds are not covering the full country, > mkgmap_locator crashes?? > > I'm using the latest "published" Europe boundaries. At least Serbia > shouldn't be affected by missing boundaries though > > On 19.05.2011 18:26, Felix Hartmann wrote: >> Mkgmap locator branch, chokes on compiling Albania... >> >> With the following command it just never finishes. It does create a >> 0bit 6414.img though. >> >> c:\OpenMTBMap\maps>start /low /b /wait java -ea -jar -Xmx6500M >> c:\openmtbmap\mkgmap_locator.jar "--style-file=c:\openmtbmap\new4" >> --max-jobs=4 --generate-sea=extend-sea-sector >> s,close-gaps=6000,floodblocker,fbgap=60,fbthres=200,fbratio=0.6 >> --latin1 "--boundsdirectory=c:\openmtbmap\maps\bounds" >> --reduce-point-density=4 --nsis --transparent --adjust- >> turn-headings --add-pois-to-areas --ignore-maxspeeds >> --x-reduce-point-density-polygon=8 --link-pois-to-ways >> --ignore-turn-restrictions --min-size-polygon=15 --remove-short-arc >> s=4 --description=openmtbmap_al --merge-lines --location-autofill=1 >> --route --country-abbr=al --country-name=albania --mapname=6414 >> --family-id=6414 --product-id=1 --seri >> es-name=openmtbmap_albania_19.05.2011 >> --family-name=mtbmap_al_19.05.2011 --tdbfile --overview-mapname=mapset >> --keep-going --area-name="albania_19.05.2011_openmtbmap.org" -c c: >> \openmtbmap\maps\template.albania >> >> >> >> Well the above wouldn't be really problematic, however last night >> mkgmap locator branch finished my map of Europe, but choked on >> creating the mdr.img because there existet three 0bit .img files. I >> stopped it and created the index within 10minutes after having deleted >> the offending 0bit files. >> >> Now I thought I'll just create all maps without --index, then clean up >> broken 0bit .img files, and create the index. This is not possible >> however, as the locator branch chokes when not providing --index. >> >> >> >> So there needs to be a change that mkgmap itself deletes the 0bit .img >> files, before creating the mdr.img and mdx files. (note I already used >> max-nodes 700.000, so Europe worked out at a whopping 1123 .img files, >> the biggest around 12MB - so I am sure (also seen nothing in log) that >> further reducing max-nodes won't solve mkgmap to create broken .img >> files -- on all three there was not a problem related to max-nodes. >> They simply did not compile. >> > ___ > 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] mkgmap_locator choking if --index not given
On 19.05.2011 19:08, WanMil wrote: I haven't observed such a situation up to now. If you want to know what happens you might connect with jvisualvm and provide the stack trace of the situation when you think that mkgmap locator crashes. The locator branch still has pre alpha status so everything is possible. WanMil P.S.: By the way: did you solve your compile problems? yes (though I really think that the jars should be included into the lib folder, it would be much easier - and solve eventual problems with newer/older versions). P.P.S.: I cannot reproduce that the locator branch chokes when not providing --index. Did you apply any patches? Yes - I attach them to this mail. But I don't think any of them should matter. I can retry tomorrow though with an mkgmap_locator.jar downloaded from mkgmap. BTW: can you try to compile Serbia from Geofabrik (todays extract) -- there is something which is definitely broken and stops mkgmap stall. I also have Serbia as missing tile on the map of Europe. Most countries seem to be going alright however (Out of 26 compiled so far, only Serbia and Iceland got mkgmap choking -- countries outside of Europe, I parse to normal mkgmap right now however - as I don't have any bounds for them anyhow). Okay even worse, on some countries mkgmap_locator does not work at all. Downloaded today from Geofabrik and breaking up in eternety just producing a 0bit .img file: Serbia and Iceland, Is it possible that if the bounds are not covering the full country, mkgmap_locator crashes?? I'm using the latest "published" Europe boundaries. At least Serbia shouldn't be affected by missing boundaries though On 19.05.2011 18:26, Felix Hartmann wrote: Mkgmap locator branch, chokes on compiling Albania... With the following command it just never finishes. It does create a 0bit 6414.img though. c:\OpenMTBMap\maps>start /low /b /wait java -ea -jar -Xmx6500M c:\openmtbmap\mkgmap_locator.jar "--style-file=c:\openmtbmap\new4" --max-jobs=4 --generate-sea=extend-sea-sector s,close-gaps=6000,floodblocker,fbgap=60,fbthres=200,fbratio=0.6 --latin1 "--boundsdirectory=c:\openmtbmap\maps\bounds" --reduce-point-density=4 --nsis --transparent --adjust- turn-headings --add-pois-to-areas --ignore-maxspeeds --x-reduce-point-density-polygon=8 --link-pois-to-ways --ignore-turn-restrictions --min-size-polygon=15 --remove-short-arc s=4 --description=openmtbmap_al --merge-lines --location-autofill=1 --route --country-abbr=al --country-name=albania --mapname=6414 --family-id=6414 --product-id=1 --seri es-name=openmtbmap_albania_19.05.2011 --family-name=mtbmap_al_19.05.2011 --tdbfile --overview-mapname=mapset --keep-going --area-name="albania_19.05.2011_openmtbmap.org" -c c: \openmtbmap\maps\template.albania Well the above wouldn't be really problematic, however last night mkgmap locator branch finished my map of Europe, but choked on creating the mdr.img because there existet three 0bit .img files. I stopped it and created the index within 10minutes after having deleted the offending 0bit files. Now I thought I'll just create all maps without --index, then clean up broken 0bit .img files, and create the index. This is not possible however, as the locator branch chokes when not providing --index. So there needs to be a change that mkgmap itself deletes the 0bit .img files, before creating the mdr.img and mdx files. (note I already used max-nodes 700.000, so Europe worked out at a whopping 1123 .img files, the biggest around 12MB - so I am sure (also seen nothing in log) that further reducing max-nodes won't solve mkgmap to create broken .img files -- on all three there was not a problem related to max-nodes. They simply did not compile. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev Index: resources/installer/license_template.txt === --- resources/installer/license_template.txt (revision 1947) +++ resources/installer/license_template.txt (working copy) @@ -1,6 +1,29 @@ -Map data (c) OpenStreetMap and contributors -http://www.openstreetmap.org/ +About the Openmtbmap.org & Velomap.org Maps - Please Read. -Map data licenced under Creative Commons Attribution ShareAlike 2.0 -See http://creativecommons.org/licenses/by-sa/2.0/ + Copyrights: +- Map Data +All maptiles are compiled with mkgmap (http://www.mkgmap.org.uk/) using map data from openstreetmap.org. OpenStreetMap data can be used freely under the terms of the http://creativecommons.org/licenses/by-sa/2.0/ You can use and edit the map data by visiting openstreetmap.org. All map data is published CCBYSA 2.0 by openstreetmap.org and Constributors. +-SRTM Contourlines Data +The Contourlines data is provided by Jonathan de Ferranti where available and SRTM3" where no files are provided by www.viewfinderpanoramas.org Compiled also with mkgmap. All Co
[mkgmap-dev] Commit: r1949: Add some names for ?\195?\150sterreich and Schweiz -- provided by Felix Hartmann
Version 1949 was commited by wanmil on 2011-05-19 18:50:51 +0100 (Thu, 19 May 2011) Add some names for ?\195?\150sterreich and Schweiz -- provided by Felix Hartmann ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] exclude words from city / state
Using the locator branch, I noticed that many cities in Austria are not findable anymore. The problem is that there are words like "Gemeinde Mödling" or "Bezirk Mödling" or "county XYZ". There should be a list where one can enter words that get deleted. That is because for the boundary it is the correct name, but not for searching a street. Also there are problems in Austria in Vienna. Vienna is a state and a city, and ideally it should be possible to enter either the district or the city into the city field, in order to find a street. Currently it is not possible to properly separate cities outside Vienna from districts inside Vienna, as they have the same admin_level. But for the ise tags, there is a correct specification telling you that districts are not cities (from the standpoint of the admin_level, it is correct however to classify them the same as small cities outside of Vienna). So in effect if one does not enter specific rules for Vienna, address search can never work as expected. Admin_level was never intended to be used for address searching, hence taking it is flawed and will not provide correct results. Ise is intended for address searching, but mkgmap does not use it. In general after using the locator branch, I more and more think, that the whole matching is completly the wrong way of doing. Much better to support real addresses as entered in OSM, and not do so much guessing. Especially support housenumbers, as at least in Germany and Austria housenumbers including full ise tags are becoming the norm, and not the exception. Only footways, pathes, or tracks should be matched, as they usually have no real address - but then it's rare that one searches for a specific path/track/footway, only real use would therefore be ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Slowness processing specific tile
I noticed a big hang/delay processing one tile in NC. Here's the generated IMG files for each tile: 05/19/2011 09:33 AM 4,230,144 63240001.img 05/19/2011 09:33 AM 2,450,432 63240002.img 05/19/2011 09:33 AM 2,893,824 63240003.img 05/19/2011 09:33 AM 2,170,880 63240004.img 05/19/2011 09:33 AM 2,173,952 63240005.img 05/19/2011 09:34 AM 2,518,016 63240006.img 05/19/2011 09:34 AM 2,553,856 63240007.img 05/19/2011 09:34 AM 1,730,560 63240008.img 05/19/2011 09:34 AM 2,041,856 63240009.img 05/19/2011 09:34 AM 3,491,328 63240010.img 05/19/2011 09:34 AM 6,999,552 63240011.img 05/19/2011 09:35 AM 4,713,984 63240012.img 05/19/2011 09:35 AM 2,435,072 63240013.img 05/19/2011 09:35 AM 3,771,392 63240014.img 05/19/2011 09:35 AM 6,385,152 63240015.img 05/19/2011 09:35 AM 3,237,376 63240016.img 05/19/2011 09:35 AM 3,420,160 63240017.img 05/19/2011 09:35 AM 2,976,768 63240018.img 05/19/2011 09:35 AM 3,629,056 63240019.img 05/19/2011 09:36 AM 3,863,552 63240020.img 05/19/2011 09:36 AM 3,583,488 63240021.img 05/19/2011 09:36 AM 1,553,408 63240022.img 05/19/2011 09:36 AM 3,411,456 63240023.img 05/19/2011 09:36 AM 3,038,208 63240024.img 05/19/2011 09:36 AM 7,901,696 63240025.img 05/19/2011 09:36 AM 3,146,752 63240026.img 05/19/2011 09:36 AM 4,070,400 63240027.img 05/19/2011 09:37 AM 2,481,664 63240028.img 05/19/2011 09:37 AM 3,462,656 63240029.img 05/19/2011 09:37 AM 4,033,536 63240030.img 05/19/2011 09:47 AM 8,536,576 63240031.img 05/19/2011 09:47 AM 1,745,408 63240032.img 05/19/2011 09:47 AM 4,779,008 63240033.img 05/19/2011 09:47 AM 3,905,024 63240034.img 05/19/2011 09:47 AM 5,238,272 63240035.img 05/19/2011 09:47 AM 3,605,504 63240036.img You can see that tile 31 took about 10 minutes to be generated while the rest was much quicker. Anyone seen anything similar? Here's the tile boundaries from the splitter output: 63240031: 1576960,-3932160 to 1597440,-3891200 # : 33.837891,-84.375000 to 34.277344,-83.496094 Just curious. Not a big deal but I thought I had caused it somehow with the PBF patch. Francisco ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Slowness processing specific tile
On 19.05.2011 20:20, Francisco Moraes wrote: > I noticed a big hang/delay processing one tile in NC. Here's the > generated IMG files for each tile: > > 05/19/2011 09:33 AM 4,230,144 63240001.img > 05/19/2011 09:33 AM 2,450,432 63240002.img > 05/19/2011 09:33 AM 2,893,824 63240003.img > 05/19/2011 09:33 AM 2,170,880 63240004.img > 05/19/2011 09:33 AM 2,173,952 63240005.img > 05/19/2011 09:34 AM 2,518,016 63240006.img > 05/19/2011 09:34 AM 2,553,856 63240007.img > 05/19/2011 09:34 AM 1,730,560 63240008.img > 05/19/2011 09:34 AM 2,041,856 63240009.img > 05/19/2011 09:34 AM 3,491,328 63240010.img > 05/19/2011 09:34 AM 6,999,552 63240011.img > 05/19/2011 09:35 AM 4,713,984 63240012.img > 05/19/2011 09:35 AM 2,435,072 63240013.img > 05/19/2011 09:35 AM 3,771,392 63240014.img > 05/19/2011 09:35 AM 6,385,152 63240015.img > 05/19/2011 09:35 AM 3,237,376 63240016.img > 05/19/2011 09:35 AM 3,420,160 63240017.img > 05/19/2011 09:35 AM 2,976,768 63240018.img > 05/19/2011 09:35 AM 3,629,056 63240019.img > 05/19/2011 09:36 AM 3,863,552 63240020.img > 05/19/2011 09:36 AM 3,583,488 63240021.img > 05/19/2011 09:36 AM 1,553,408 63240022.img > 05/19/2011 09:36 AM 3,411,456 63240023.img > 05/19/2011 09:36 AM 3,038,208 63240024.img > 05/19/2011 09:36 AM 7,901,696 63240025.img > 05/19/2011 09:36 AM 3,146,752 63240026.img > 05/19/2011 09:36 AM 4,070,400 63240027.img > 05/19/2011 09:37 AM 2,481,664 63240028.img > 05/19/2011 09:37 AM 3,462,656 63240029.img > 05/19/2011 09:37 AM 4,033,536 63240030.img > 05/19/2011 09:47 AM 8,536,576 63240031.img > 05/19/2011 09:47 AM 1,745,408 63240032.img > 05/19/2011 09:47 AM 4,779,008 63240033.img > 05/19/2011 09:47 AM 3,905,024 63240034.img > 05/19/2011 09:47 AM 5,238,272 63240035.img > 05/19/2011 09:47 AM 3,605,504 63240036.img > > You can see that tile 31 took about 10 minutes to be generated while the > rest was much quicker. Anyone seen anything similar? Here's the tile > boundaries from the splitter output: > > 63240031: 1576960,-3932160 to 1597440,-3891200 > # : 33.837891,-84.375000 to 34.277344,-83.496094 > > Just curious. Not a big deal but I thought I had caused it somehow with > the PBF patch. Noticed the same thing on Turkey (11min for one tile). I have to recheck if on Iceland and Serbia the same problem appears - and mkgmap is not completly choking. This happened also before the pbf patches/ or without locator branch, but now more often?? > Francisco > ___ > 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] [locator] Country specific rules
El 16/05/11 19:27, Minko escribió:
> Cool!
> I can use these locator rules also for the multiple language expressions in
> the 'default_name':
> http://www.mail-archive.com/mkgmap-dev@lists.mkgmap.org.uk/msg07697.html
>
> Example:
> leisure=pitch& sport=soccer& (mkgmap:country=NLD |
> mgkmap:region=Vlaanderen) [0x19 default_name="voetbalveld" resolution 23]
> leisure=pitch& sport=soccer& mkgmap:country=DEU [0x19
> default_name="Fussballfeld" resolution 23]
> leisure=pitch& sport=soccer& (mkgmap:country=FRA | mgkmap:region="Région
> Wallone") [0x19 default_name="terrain de football" resolution 23]
> leisure=pitch& sport=soccer [0x19 resolution 23]
I tried rules of type below, but it doesn't work for Morocco.
highway=primary & (mkgmap:country=ETH | mkgmap:country=MAR) [0x03
road_class=3 road_speed=5 resolution 16]
highway=primary [0x03 road_class=3 road_speed=5 resolution 18]
MapSouce shows "Morocco (MOR)" in the countries list, although
LocatorConfig.xml has the rule below and there's no occurrence of "MOR"
in the OSM data.
MA
MAR
I know I could use MOR instead of MAR in my style but, shouldn't it be
consistent with the LocatorConfig?
> "Région Wallone" is however not recognised, maybe the relation 90348 is not
> complete? JOSM is complaining about a few members without role.
>
> --
> Wanmil wrote:
>
>> Just wondering, maybe we can use the locator rules also for country or state
>> specific routing?
>> For instance in some countries (like Germany (?) according to the access
>> rules on osm, see
>> http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#Germany)
>> one is allowed to cycle on trunk roads, while in other countries like in
>> the Netherlands this is forbidden.
>>
>> In the style file maybe this is possible?
>>
>> mkgmap:country=NLD& highway=trunk {add bicycle=no}
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Splitter PBF support patch
On Thu, May 19, 2011 at 01:12:06PM -0400, Francisco Moraes wrote: >After much delay, here's the splitter patch. > >Enjoy. I would love to, but: >+ currentWriters[j] = pbfOutput ? new >BinaryMapWriter(area, fileOutputDir) : new OSMXMLWriter(area, >fileOutputDir); It appears that you forgot to include BinaryMapWriter.java in the patch. Please execute "svn status" in your working directory, and execute "svn add" for every file that is listed with a ? next to it. After that, "svn diff" should include all new files. (You would have to remember the "svn add" also before "svn commit".) Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Denmark: SEVERE (MapBuilder): ./63240348.osm.gz: FIXME - too many POIs in group
Hi! When I try to build a map of Denmark, I get a lot of "SEVERE (MapBuilder): ./63240348.osm.gz: FIXME - too many POIs in group" messages. Then the mkgmap processes exits without generating a map. What can I do? Dani ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Denmark: SEVERE (MapBuilder): ./63240348.osm.gz: FIXME - too many POIs in group
On Thu, May 19, 2011 at 09:21:01PM +0200, Daniela Duerbeck wrote: >Hi! > >When I try to build a map of Denmark, I get a lot of "SEVERE >(MapBuilder): ./63240348.osm.gz: FIXME - too many POIs in group" >messages. Then the mkgmap processes exits without generating a map. >What can I do? AFAIR from past discussions on this list, there are lots of node attributes in Denmark, originating from an import of a municipal data source. I guess that you could lower the splitter density parameter to make smaller tiles. (I cannot remember which it is; I am using manually created areas.list since a couple of years). Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [locator] Country specific rules
> El 16/05/11 19:27, Minko escribió:
>> Cool!
>> I can use these locator rules also for the multiple language expressions in
>> the 'default_name':
>> http://www.mail-archive.com/mkgmap-dev@lists.mkgmap.org.uk/msg07697.html
>>
>> Example:
>> leisure=pitch& sport=soccer& (mkgmap:country=NLD |
>> mgkmap:region=Vlaanderen) [0x19 default_name="voetbalveld" resolution 23]
>> leisure=pitch& sport=soccer& mkgmap:country=DEU [0x19
>> default_name="Fussballfeld" resolution 23]
>> leisure=pitch& sport=soccer& (mkgmap:country=FRA | mgkmap:region="Région
>> Wallone") [0x19 default_name="terrain de football" resolution 23]
>> leisure=pitch& sport=soccer [0x19 resolution 23]
> I tried rules of type below, but it doesn't work for Morocco.
> highway=primary& (mkgmap:country=ETH | mkgmap:country=MAR) [0x03
> road_class=3 road_speed=5 resolution 16]
> highway=primary [0x03 road_class=3 road_speed=5 resolution 18]
>
> MapSouce shows "Morocco (MOR)" in the countries list, although
> LocatorConfig.xml has the rule below and there's no occurrence of "MOR"
> in the OSM data.
>
> MA
> MAR
>
> I know I could use MOR instead of MAR in my style but, shouldn't it be
> consistent with the LocatorConfig?
It seems as if the LocatorConfig you changed is not used by mkgmap. Do
you use a downloaded mkgmap.jar? I am not sure where your changed
LocatorConfig.xml must be placed so that mkgmap does not use the bundled
LocatorConfig.xml.
>> "Région Wallone" is however not recognised, maybe the relation 90348 is not
>> complete? JOSM is complaining about a few members without role.
>>
>> --
>> Wanmil wrote:
>>
>>> Just wondering, maybe we can use the locator rules also for country or
>>> state specific routing?
>>> For instance in some countries (like Germany (?) according to the access
>>> rules on osm, see
>>> http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#Germany)
>>> one is allowed to cycle on trunk roads, while in other countries like in
>>> the Netherlands this is forbidden.
>>>
>>> In the style file maybe this is possible?
>>>
>>> mkgmap:country=NLD&highway=trunk {add bicycle=no}
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Slowness processing specific tile
>> I noticed a big hang/delay processing one tile in NC. Here's the >> generated IMG files for each tile: >> >> 05/19/2011 09:33 AM 4,230,144 63240001.img >> 05/19/2011 09:33 AM 2,450,432 63240002.img >> 05/19/2011 09:33 AM 2,893,824 63240003.img >> 05/19/2011 09:33 AM 2,170,880 63240004.img >> 05/19/2011 09:33 AM 2,173,952 63240005.img >> 05/19/2011 09:34 AM 2,518,016 63240006.img >> 05/19/2011 09:34 AM 2,553,856 63240007.img >> 05/19/2011 09:34 AM 1,730,560 63240008.img >> 05/19/2011 09:34 AM 2,041,856 63240009.img >> 05/19/2011 09:34 AM 3,491,328 63240010.img >> 05/19/2011 09:34 AM 6,999,552 63240011.img >> 05/19/2011 09:35 AM 4,713,984 63240012.img >> 05/19/2011 09:35 AM 2,435,072 63240013.img >> 05/19/2011 09:35 AM 3,771,392 63240014.img >> 05/19/2011 09:35 AM 6,385,152 63240015.img >> 05/19/2011 09:35 AM 3,237,376 63240016.img >> 05/19/2011 09:35 AM 3,420,160 63240017.img >> 05/19/2011 09:35 AM 2,976,768 63240018.img >> 05/19/2011 09:35 AM 3,629,056 63240019.img >> 05/19/2011 09:36 AM 3,863,552 63240020.img >> 05/19/2011 09:36 AM 3,583,488 63240021.img >> 05/19/2011 09:36 AM 1,553,408 63240022.img >> 05/19/2011 09:36 AM 3,411,456 63240023.img >> 05/19/2011 09:36 AM 3,038,208 63240024.img >> 05/19/2011 09:36 AM 7,901,696 63240025.img >> 05/19/2011 09:36 AM 3,146,752 63240026.img >> 05/19/2011 09:36 AM 4,070,400 63240027.img >> 05/19/2011 09:37 AM 2,481,664 63240028.img >> 05/19/2011 09:37 AM 3,462,656 63240029.img >> 05/19/2011 09:37 AM 4,033,536 63240030.img >> 05/19/2011 09:47 AM 8,536,576 63240031.img >> 05/19/2011 09:47 AM 1,745,408 63240032.img >> 05/19/2011 09:47 AM 4,779,008 63240033.img >> 05/19/2011 09:47 AM 3,905,024 63240034.img >> 05/19/2011 09:47 AM 5,238,272 63240035.img >> 05/19/2011 09:47 AM 3,605,504 63240036.img >> >> You can see that tile 31 took about 10 minutes to be generated while the >> rest was much quicker. Anyone seen anything similar? Here's the tile >> boundaries from the splitter output: >> >> 63240031: 1576960,-3932160 to 1597440,-3891200 >> # : 33.837891,-84.375000 to 34.277344,-83.496094 >> >> Just curious. Not a big deal but I thought I had caused it somehow with >> the PBF patch. > Noticed the same thing on Turkey (11min for one tile). I have to recheck > if on Iceland and Serbia the same problem appears - and mkgmap is not > completly choking. This happened also before the pbf patches/ or without > locator branch, but now more often?? >> Francisco Don't know if that's the reason for your case but you might check. If Java has too few memory the garbage collector needs so much time that it seems as if mkgmap blocks. I have seen such cases. You can check that either by connecting with jvisualvm and watch the CPU time used by the garbage collector or you can add -verbose:gc as java parameter: java -verbose:gc -jar mkgmap.jar ... In this case you see a log message each time the gc is running. In case mkgmap seems to block and low memory is the reason you should get tons of such messages. By the way: I suppose the mkgmap code still has some potential to reduce the memory footprint. All nodes, ways and relations are stored in HashMaps which might be changed to a less memory consuming implementation. It would be great if anyone tries to patch that. WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Slowness processing specific tile
On 19.05.2011 21:38, WanMil wrote: >>> I noticed a big hang/delay processing one tile in NC. Here's the >>> generated IMG files for each tile: >>> >>> 05/19/2011 09:33 AM 4,230,144 63240001.img >>> 05/19/2011 09:33 AM 2,450,432 63240002.img >>> 05/19/2011 09:33 AM 2,893,824 63240003.img >>> 05/19/2011 09:33 AM 2,170,880 63240004.img >>> 05/19/2011 09:33 AM 2,173,952 63240005.img >>> 05/19/2011 09:34 AM 2,518,016 63240006.img >>> 05/19/2011 09:34 AM 2,553,856 63240007.img >>> 05/19/2011 09:34 AM 1,730,560 63240008.img >>> 05/19/2011 09:34 AM 2,041,856 63240009.img >>> 05/19/2011 09:34 AM 3,491,328 63240010.img >>> 05/19/2011 09:34 AM 6,999,552 63240011.img >>> 05/19/2011 09:35 AM 4,713,984 63240012.img >>> 05/19/2011 09:35 AM 2,435,072 63240013.img >>> 05/19/2011 09:35 AM 3,771,392 63240014.img >>> 05/19/2011 09:35 AM 6,385,152 63240015.img >>> 05/19/2011 09:35 AM 3,237,376 63240016.img >>> 05/19/2011 09:35 AM 3,420,160 63240017.img >>> 05/19/2011 09:35 AM 2,976,768 63240018.img >>> 05/19/2011 09:35 AM 3,629,056 63240019.img >>> 05/19/2011 09:36 AM 3,863,552 63240020.img >>> 05/19/2011 09:36 AM 3,583,488 63240021.img >>> 05/19/2011 09:36 AM 1,553,408 63240022.img >>> 05/19/2011 09:36 AM 3,411,456 63240023.img >>> 05/19/2011 09:36 AM 3,038,208 63240024.img >>> 05/19/2011 09:36 AM 7,901,696 63240025.img >>> 05/19/2011 09:36 AM 3,146,752 63240026.img >>> 05/19/2011 09:36 AM 4,070,400 63240027.img >>> 05/19/2011 09:37 AM 2,481,664 63240028.img >>> 05/19/2011 09:37 AM 3,462,656 63240029.img >>> 05/19/2011 09:37 AM 4,033,536 63240030.img >>> 05/19/2011 09:47 AM 8,536,576 63240031.img >>> 05/19/2011 09:47 AM 1,745,408 63240032.img >>> 05/19/2011 09:47 AM 4,779,008 63240033.img >>> 05/19/2011 09:47 AM 3,905,024 63240034.img >>> 05/19/2011 09:47 AM 5,238,272 63240035.img >>> 05/19/2011 09:47 AM 3,605,504 63240036.img >>> >>> You can see that tile 31 took about 10 minutes to be generated while >>> the >>> rest was much quicker. Anyone seen anything similar? Here's the tile >>> boundaries from the splitter output: >>> >>> 63240031: 1576960,-3932160 to 1597440,-3891200 >>> # : 33.837891,-84.375000 to 34.277344,-83.496094 >>> >>> Just curious. Not a big deal but I thought I had caused it somehow with >>> the PBF patch. >> Noticed the same thing on Turkey (11min for one tile). I have to recheck >> if on Iceland and Serbia the same problem appears - and mkgmap is not >> completly choking. This happened also before the pbf patches/ or without >> locator branch, but now more often?? >>> Francisco > > Don't know if that's the reason for your case but you might check. If > Java has too few memory the garbage collector needs so much time that > it seems as if mkgmap blocks. I have seen such cases. > > You can check that either by connecting with jvisualvm and watch the > CPU time used by the garbage collector or you can add -verbose:gc as > java parameter: > java -verbose:gc -jar mkgmap.jar ... > In this case you see a log message each time the gc is running. In > case mkgmap seems to block and low memory is the reason you should get > tons of such messages. > > By the way: I suppose the mkgmap code still has some potential to > reduce the memory footprint. All nodes, ways and relations are stored > in HashMaps which might be changed to a less memory consuming > implementation. It would be great if anyone tries to patch that. > > WanMil > In my case with Turkey that is definitely not the problem. It happens on small maps with 8GB RAM attributed (the server got 12GB, so RAM shortage is highly unlikely). I'll try jvisualvm on Saturday or Sunday. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Slowness processing specific tile
I noticed a big hang/delay processing one tile in NC. Here's the generated IMG files for each tile: 05/19/2011 09:33 AM 4,230,144 63240001.img 05/19/2011 09:33 AM 2,450,432 63240002.img 05/19/2011 09:33 AM 2,893,824 63240003.img 05/19/2011 09:33 AM 2,170,880 63240004.img 05/19/2011 09:33 AM 2,173,952 63240005.img 05/19/2011 09:34 AM 2,518,016 63240006.img 05/19/2011 09:34 AM 2,553,856 63240007.img 05/19/2011 09:34 AM 1,730,560 63240008.img 05/19/2011 09:34 AM 2,041,856 63240009.img 05/19/2011 09:34 AM 3,491,328 63240010.img 05/19/2011 09:34 AM 6,999,552 63240011.img 05/19/2011 09:35 AM 4,713,984 63240012.img 05/19/2011 09:35 AM 2,435,072 63240013.img 05/19/2011 09:35 AM 3,771,392 63240014.img 05/19/2011 09:35 AM 6,385,152 63240015.img 05/19/2011 09:35 AM 3,237,376 63240016.img 05/19/2011 09:35 AM 3,420,160 63240017.img 05/19/2011 09:35 AM 2,976,768 63240018.img 05/19/2011 09:35 AM 3,629,056 63240019.img 05/19/2011 09:36 AM 3,863,552 63240020.img 05/19/2011 09:36 AM 3,583,488 63240021.img 05/19/2011 09:36 AM 1,553,408 63240022.img 05/19/2011 09:36 AM 3,411,456 63240023.img 05/19/2011 09:36 AM 3,038,208 63240024.img 05/19/2011 09:36 AM 7,901,696 63240025.img 05/19/2011 09:36 AM 3,146,752 63240026.img 05/19/2011 09:36 AM 4,070,400 63240027.img 05/19/2011 09:37 AM 2,481,664 63240028.img 05/19/2011 09:37 AM 3,462,656 63240029.img 05/19/2011 09:37 AM 4,033,536 63240030.img 05/19/2011 09:47 AM 8,536,576 63240031.img 05/19/2011 09:47 AM 1,745,408 63240032.img 05/19/2011 09:47 AM 4,779,008 63240033.img 05/19/2011 09:47 AM 3,905,024 63240034.img 05/19/2011 09:47 AM 5,238,272 63240035.img 05/19/2011 09:47 AM 3,605,504 63240036.img You can see that tile 31 took about 10 minutes to be generated while the rest was much quicker. Anyone seen anything similar? Here's the tile boundaries from the splitter output: 63240031: 1576960,-3932160 to 1597440,-3891200 # : 33.837891,-84.375000 to 34.277344,-83.496094 Just curious. Not a big deal but I thought I had caused it somehow with the PBF patch. >>> Noticed the same thing on Turkey (11min for one tile). I have to recheck >>> if on Iceland and Serbia the same problem appears - and mkgmap is not >>> completly choking. This happened also before the pbf patches/ or without >>> locator branch, but now more often?? Francisco >> >> Don't know if that's the reason for your case but you might check. If >> Java has too few memory the garbage collector needs so much time that >> it seems as if mkgmap blocks. I have seen such cases. >> >> You can check that either by connecting with jvisualvm and watch the >> CPU time used by the garbage collector or you can add -verbose:gc as >> java parameter: >> java -verbose:gc -jar mkgmap.jar ... >> In this case you see a log message each time the gc is running. In >> case mkgmap seems to block and low memory is the reason you should get >> tons of such messages. >> >> By the way: I suppose the mkgmap code still has some potential to >> reduce the memory footprint. All nodes, ways and relations are stored >> in HashMaps which might be changed to a less memory consuming >> implementation. It would be great if anyone tries to patch that. >> >> WanMil >> > In my case with Turkey that is definitely not the problem. It happens on > small maps with 8GB RAM attributed (the server got 12GB, so RAM shortage > is highly unlikely). I'll try jvisualvm on Saturday or Sunday. The tile that took so long is the biggest one of all. Important for memory considerations is the size of tiles and the number of threads. So 8GB *might* also be too low if you use big tiles and a high number of threads. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Slowness processing specific tile
On 19.05.2011 21:52, WanMil wrote: > I noticed a big hang/delay processing one tile in NC. Here's the > generated IMG files for each tile: > > 05/19/2011 09:33 AM 4,230,144 63240001.img > 05/19/2011 09:33 AM 2,450,432 63240002.img > 05/19/2011 09:33 AM 2,893,824 63240003.img > 05/19/2011 09:33 AM 2,170,880 63240004.img > 05/19/2011 09:33 AM 2,173,952 63240005.img > 05/19/2011 09:34 AM 2,518,016 63240006.img > 05/19/2011 09:34 AM 2,553,856 63240007.img > 05/19/2011 09:34 AM 1,730,560 63240008.img > 05/19/2011 09:34 AM 2,041,856 63240009.img > 05/19/2011 09:34 AM 3,491,328 63240010.img > 05/19/2011 09:34 AM 6,999,552 63240011.img > 05/19/2011 09:35 AM 4,713,984 63240012.img > 05/19/2011 09:35 AM 2,435,072 63240013.img > 05/19/2011 09:35 AM 3,771,392 63240014.img > 05/19/2011 09:35 AM 6,385,152 63240015.img > 05/19/2011 09:35 AM 3,237,376 63240016.img > 05/19/2011 09:35 AM 3,420,160 63240017.img > 05/19/2011 09:35 AM 2,976,768 63240018.img > 05/19/2011 09:35 AM 3,629,056 63240019.img > 05/19/2011 09:36 AM 3,863,552 63240020.img > 05/19/2011 09:36 AM 3,583,488 63240021.img > 05/19/2011 09:36 AM 1,553,408 63240022.img > 05/19/2011 09:36 AM 3,411,456 63240023.img > 05/19/2011 09:36 AM 3,038,208 63240024.img > 05/19/2011 09:36 AM 7,901,696 63240025.img > 05/19/2011 09:36 AM 3,146,752 63240026.img > 05/19/2011 09:36 AM 4,070,400 63240027.img > 05/19/2011 09:37 AM 2,481,664 63240028.img > 05/19/2011 09:37 AM 3,462,656 63240029.img > 05/19/2011 09:37 AM 4,033,536 63240030.img > 05/19/2011 09:47 AM 8,536,576 63240031.img > 05/19/2011 09:47 AM 1,745,408 63240032.img > 05/19/2011 09:47 AM 4,779,008 63240033.img > 05/19/2011 09:47 AM 3,905,024 63240034.img > 05/19/2011 09:47 AM 5,238,272 63240035.img > 05/19/2011 09:47 AM 3,605,504 63240036.img > > You can see that tile 31 took about 10 minutes to be generated while > the > rest was much quicker. Anyone seen anything similar? Here's the tile > boundaries from the splitter output: > > 63240031: 1576960,-3932160 to 1597440,-3891200 > # : 33.837891,-84.375000 to 34.277344,-83.496094 > > Just curious. Not a big deal but I thought I had caused it somehow > with > the PBF patch. Noticed the same thing on Turkey (11min for one tile). I have to recheck if on Iceland and Serbia the same problem appears - and mkgmap is not completly choking. This happened also before the pbf patches/ or without locator branch, but now more often?? > Francisco >>> >>> Don't know if that's the reason for your case but you might check. If >>> Java has too few memory the garbage collector needs so much time that >>> it seems as if mkgmap blocks. I have seen such cases. >>> >>> You can check that either by connecting with jvisualvm and watch the >>> CPU time used by the garbage collector or you can add -verbose:gc as >>> java parameter: >>> java -verbose:gc -jar mkgmap.jar ... >>> In this case you see a log message each time the gc is running. In >>> case mkgmap seems to block and low memory is the reason you should get >>> tons of such messages. >>> >>> By the way: I suppose the mkgmap code still has some potential to >>> reduce the memory footprint. All nodes, ways and relations are stored >>> in HashMaps which might be changed to a less memory consuming >>> implementation. It would be great if anyone tries to patch that. >>> >>> WanMil >>> >> In my case with Turkey that is definitely not the problem. It happens on >> small maps with 8GB RAM attributed (the server got 12GB, so RAM shortage >> is highly unlikely). I'll try jvisualvm on Saturday or Sunday. > > The tile that took so long is the biggest one of all. Important for > memory considerations is the size of tiles and the number of threads. > So 8GB *might* also be too low if you use big tiles and a high number > of threads. Well I use small tiles (max-nodes 900.000 on Turkey) plus only 4 threads. (I could use 8 due to Hyperthreading, but kept it at 4). I even have this problem on single tiles where the osm.gz is like 10MB. There shouldn't be a slow down due to memory in that case, should there? (I cannot check for memory use, as my user rights are too low). ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [locator] Country specific rules
El 19/05/11 21:29, WanMil escribió:
>> El 16/05/11 19:27, Minko escribió:
>>> Cool!
>>> I can use these locator rules also for the multiple language expressions in
>>> the 'default_name':
>>> http://www.mail-archive.com/mkgmap-dev@lists.mkgmap.org.uk/msg07697.html
>>>
>>> Example:
>>> leisure=pitch&sport=soccer&(mkgmap:country=NLD |
>>> mgkmap:region=Vlaanderen) [0x19 default_name="voetbalveld" resolution 23]
>>> leisure=pitch&sport=soccer&mkgmap:country=DEU [0x19
>>> default_name="Fussballfeld" resolution 23]
>>> leisure=pitch&sport=soccer&(mkgmap:country=FRA |
>>> mgkmap:region="Région Wallone") [0x19 default_name="terrain de football"
>>> resolution 23]
>>> leisure=pitch&sport=soccer [0x19 resolution 23]
>> I tried rules of type below, but it doesn't work for Morocco.
>> highway=primary& (mkgmap:country=ETH | mkgmap:country=MAR) [0x03
>> road_class=3 road_speed=5 resolution 16]
>> highway=primary [0x03 road_class=3 road_speed=5 resolution 18]
>>
>> MapSouce shows "Morocco (MOR)" in the countries list, although
>> LocatorConfig.xml has the rule below and there's no occurrence of "MOR"
>> in the OSM data.
>>
>> MA
>> MAR
>>
>> I know I could use MOR instead of MAR in my style but, shouldn't it be
>> consistent with the LocatorConfig?
> It seems as if the LocatorConfig you changed is not used by mkgmap. Do
> you use a downloaded mkgmap.jar? I am not sure where your changed
> LocatorConfig.xml must be placed so that mkgmap does not use the bundled
> LocatorConfig.xml.
I have not changed LocatorConfig.xml, I'm using the default one. I use a
self compiled jar.
>>> "Région Wallone" is however not recognised, maybe the relation 90348 is not
>>> complete? JOSM is complaining about a few members without role.
>>>
>>> --
>>> Wanmil wrote:
>>>
Just wondering, maybe we can use the locator rules also for country or
state specific routing?
For instance in some countries (like Germany (?) according to the access
rules on osm, see
http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#Germany)
one is allowed to cycle on trunk roads, while in other countries like in
the Netherlands this is forbidden.
In the style file maybe this is possible?
mkgmap:country=NLD& highway=trunk {add bicycle=no}
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
--
Por favor, no me envíe documentos con extensiones .doc, .docx, .xls, .xlsx,
.ppt, .pptx, .mdb, mdbx
Instale OpenOffice desde http://es.openoffice.org/programa/index.html
OpenOffice es libre: se puede copiar, modificar y redistribuir libremente.
Gratis y totalmente legal.
OpenOffice está en continuo desarrollo y no tendrá que pagar por las nuevas
versiones.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [locator] Country specific rules
> El 19/05/11 21:29, WanMil escribió:
>>> El 16/05/11 19:27, Minko escribió:
Cool!
I can use these locator rules also for the multiple language expressions
in the 'default_name':
http://www.mail-archive.com/mkgmap-dev@lists.mkgmap.org.uk/msg07697.html
Example:
leisure=pitch& sport=soccer& (mkgmap:country=NLD |
mgkmap:region=Vlaanderen) [0x19 default_name="voetbalveld" resolution 23]
leisure=pitch& sport=soccer& mkgmap:country=DEU [0x19
default_name="Fussballfeld" resolution 23]
leisure=pitch& sport=soccer& (mkgmap:country=FRA |
mgkmap:region="Région Wallone") [0x19 default_name="terrain de football"
resolution 23]
leisure=pitch& sport=soccer [0x19 resolution 23]
>>> I tried rules of type below, but it doesn't work for Morocco.
>>> highway=primary&(mkgmap:country=ETH | mkgmap:country=MAR) [0x03
>>> road_class=3 road_speed=5 resolution 16]
>>> highway=primary [0x03 road_class=3 road_speed=5 resolution 18]
>>>
>>> MapSouce shows "Morocco (MOR)" in the countries list, although
>>> LocatorConfig.xml has the rule below and there's no occurrence of "MOR"
>>> in the OSM data.
>>>
>>> MA
>>> MAR
>>>
>>> I know I could use MOR instead of MAR in my style but, shouldn't it be
>>> consistent with the LocatorConfig?
>> It seems as if the LocatorConfig you changed is not used by mkgmap. Do
>> you use a downloaded mkgmap.jar? I am not sure where your changed
>> LocatorConfig.xml must be placed so that mkgmap does not use the bundled
>> LocatorConfig.xml.
> I have not changed LocatorConfig.xml, I'm using the default one. I use a
> self compiled jar.
Oh, I am sorry. I mixed up some things.
Do you use the default-country parameter?
Do you have other maps installed in MapSource?
I have no idea at the moment why Morocco is abbreviated with MOR but I
will test that myself.
WanMil
"Région Wallone" is however not recognised, maybe the relation 90348 is
not complete? JOSM is complaining about a few members without role.
--
Wanmil wrote:
> Just wondering, maybe we can use the locator rules also for country or
> state specific routing?
> For instance in some countries (like Germany (?) according to the access
> rules on osm, see
> http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#Germany)
> one is allowed to cycle on trunk roads, while in other countries like in
> the Netherlands this is forbidden.
>
> In the style file maybe this is possible?
>
> mkgmap:country=NLD& highway=trunk {add bicycle=no}
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mkgmap_locator choking if --index not given
On 19.05.2011 22:28, WanMil wrote: >> BTW: can you try to compile Serbia from Geofabrik (todays extract) -- >> there is something which is definitely broken and stops mkgmap stall. I >> also have Serbia as missing tile on the map of Europe. Most countries >> seem to be going alright however (Out of 26 compiled so far, only Serbia >> and Iceland got mkgmap choking -- countries outside of Europe, I parse >> to normal mkgmap right now however - as I don't have any bounds for them >> anyhow). >>> > > Serbia is compiling well for me with the today Geofabrik extract and > the current locator branch release (r1950). Okay (and it did not take more than than 5-6 minutes or?). I'll check it this weekend to try to hunt down the problem. Maybe one of the jars that I'm using is not working well, dunno really. For me it splitted in 7 seconds, and after 8minutes compiling I broke the process - could be a case like in Denmark however??? - I'll let it run 30min one a single worker thread, and try out some stuff ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mkgmap_locator choking if --index not given
> On 19.05.2011 22:28, WanMil wrote: >>> BTW: can you try to compile Serbia from Geofabrik (todays extract) -- >>> there is something which is definitely broken and stops mkgmap stall. I >>> also have Serbia as missing tile on the map of Europe. Most countries >>> seem to be going alright however (Out of 26 compiled so far, only Serbia >>> and Iceland got mkgmap choking -- countries outside of Europe, I parse >>> to normal mkgmap right now however - as I don't have any bounds for them >>> anyhow). >> >> Serbia is compiling well for me with the today Geofabrik extract and >> the current locator branch release (r1950). > Okay (and it did not take more than than 5-6 minutes or?). I'll check it > this weekend to try to hunt down the problem. Maybe one of the jars that > I'm using is not working well, dunno really. > > For me it splitted in 7 seconds, and after 8minutes compiling I broke > the process - could be a case like in Denmark however??? - I'll let it > run 30min one a single worker thread, and try out some stuff I used the new PBF splitter posted by Francisco. Compiling was quite fast as I would expect. It would really be helpful if you can provide a stack trace of the point where mkgmap "hangs" and if you can check the memory consumption just to be sure that it is not the reason. You might also post your exact mkgmap parameters to avoid comparing apples and pears. WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Denmark: SEVERE (MapBuilder): ./63240348.osm.gz: FIXME - too many POIs in group
On 19-05-11 21:21, Daniela Duerbeck wrote: > Hi! > > When I try to build a map of Denmark, I get a lot of "SEVERE > (MapBuilder): ./63240348.osm.gz: FIXME - too many POIs in group" > messages. Then the mkgmap processes exits without generating a map. > What can I do? > I use a script that re-splits the tile for situations like where Mkgmap does not produce a map from initial Splitter results. The script reduces node count until splitter produces 2 or more 'sub'tiles, then tries to render those subtiles and repeat the process until all subtiles are rendered if necessary or until the node count reaches a lower limit. So the process goes like this: 1- Split your osm.pbf/bz2 file with an initial max-nodes setting (e.g. 1.2 million) 2- Attempt to render the tiles with Mkgmap into Garmin images 3- See if any of the new Garmin images failed (i.e. do not exist or 0 bytes in size) 4- Re-split the failed tiles with ever lower max-node counts until splitter produces 2 or more subtiles 5- Goto 2 (but render only the subtiles ofcourse) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problems with gmapi-builder
The other thing we noticed was that individual files which get too large can also fail. Is it possible to try with smaller map tiles? Or can I download your img files to reproduce the error? Cheers On May 19, 2011, at 4:29, maning sambale wrote: > Clinton, > > I used your attached script and the result is the same: > python gmapi-builder -v -t for_mapsource/4001.tdb -b > for_mapsource/4001.img -s for_mapsource/MINIMAL.TYP -i > for_mapsource/4001.mdx -m for_mapsource/4001_mdr.img > for_mapsource/4001.img for_mapsource/*.img > Unknown Block: 54, length: 20, > '\x00\x00\xa7\x00\x00\x00\x00\x00\x00\xa2\x00\x00\xab\x00\x00\x00\x00\xfc\x00\x00' > TDB Version:4.07 > Product ID: 1 > Family ID: 639 > Map Series: OSM_PHIL > Map Family: OSM_PHIL > Product Version:1.00 > > Copyright: OSM Street map > Copyright: http://www.openstreetmap.org/ > Copyright: Map data licenced under Creative Commons > Attribution ShareAlike 2.0 > Copyright: http://creativecommons.org/licenses/by-sa/2.0/ > Copyright: Map created with mkgmap-r1867 > Copyright: Program released under the GPL > > Trademark: Test preview map > > Overview map: >Map Number: 6324 >Parent Map: 0 >Latitude North: 21.5771 >Longitude East: 127.7930 >Latitude South: 4.5264 >Longitude West: 115.6201 >Description:Overview Map > > Processing for_mapsource/4001.img > Processing for_mapsource/4001_mdr.img > MDR file > Processing for_mapsource/63240001.img > Missing part: 0 of > S?.ϻ in IMG-file. > > > On Thu, May 19, 2011 at 3:21 AM, Clinton Gladstone > wrote: >> OK, That Wiki version is missing some things, such as index file support and >> latin-1 encoding. >> >> Try the attached file: It's a version which I sent to this list a few months >> ago. >> >> I'll try to update this version in a few days to include the TYP file fix >> from the Wiki too. >> >> Here's an example command line call, which includes index files: >> >> $ gmapi-builder.py -t 1400.tdb -b 1400.img -s 14.TYP -i 1400.mdx >> -m 1400_mdr.img *.img >> >> >> >> >> Cheers. >> >> >> On May 18, 2011, at 4:57, maning sambale wrote: >> >>> Here: >>> http://bitbucket.org/berteun/gmapibuilder/downloads/gmapi-builder.tar.gz >>> as stated here: >>> http://wiki.openstreetmap.org/wiki/Gmapibuilder/New_version >>> >>> On Wed, May 18, 2011 at 2:01 AM, Clinton Gladstone >>> wrote: On May 17, 2011, at 14:34, maning sambale wrote: > I downloaded the latest gmapi-builder and tried the following: Where did you download this? I made some corrections, but I'm not sure if they are in the version you downloaded. Cheers. ___ mkgmap-dev mailing list mkgmap-dev@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/ >>> -- >>> ___ >>> 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 >> > > > > -- > cheers, > maning > -- > "Freedom is still the most radical idea of all" -N.Branden > wiki: http://esambale.wikispaces.com/ > blog: http://epsg4253.wordpress.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] Slowness processing specific tile
Le 19/05/2011 22:05, Felix Hartmann a écrit : > > > On 19.05.2011 21:52, WanMil wrote: >> I noticed a big hang/delay processing one tile in NC. Here's the >> generated IMG files for each tile: Do not know whether or not that the same pb, but two or three months ago, when I run splitter and mkgmap to create a gmapsupp.img file, against france.osm data, it took 4 hours to create it. On the same machine, with the same scripts, it takes now 17 hours. My main pb is with splitter as for example, it began to run yesterday at 11pm and end its run today at 11.56am. 13 hours to split, but the machine is really not a big one :-) Francois -- ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Splitter PBF support patch
On Thu, May 19, 2011 at 03:37:19PM -0400, Francisco Moraes wrote: >Ok, take 2 on the splitter PBF patch. All new files should be present. I >also fixed the EOL mode, so the diffs should be better. That would explain why the new diff is shorter. I guess we should always "svn propset svn:eol-style native" on all non-binary files. >To enable the PBF output, I added the option --pbf. If omitted, it >should output the normal .osm.gz format. Doh, I missed this. I had the broken *.osm.pbf files lying around from a previous broken run, and was just about to complain that the patch fails to close the polygons, as your initial splitter.jar release did. I will try this one more time on today's finland.osm.pbf, but I will report the results tomorrow. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Slowness processing specific tile
On 19.05.2011 22:46, frmas wrote: > Le 19/05/2011 22:05, Felix Hartmann a écrit : >> >> On 19.05.2011 21:52, WanMil wrote: >>> I noticed a big hang/delay processing one tile in NC. Here's the >>> generated IMG files for each tile: > Do not know whether or not that the same pb, but two or three months > ago, when I run splitter and mkgmap to create a gmapsupp.img file, > against france.osm data, it took 4 hours to create it. On the same > machine, with the same scripts, it takes now 17 hours. My main pb is > with splitter as for example, it began to run yesterday at 11pm and end > its run today at 11.56am. 13 hours to split, but the machine is really > not a big one :-) > Francois > Well in that case your machine is the culprit. France splits in around 16 minutes for me. And takes bout 60minutes to compile (12GB Ram, Intel Core somthing (4 cores). ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Splitter PBF support patch
On Thu, May 19, 2011 at 11:46:57PM +0300, Marko Mäkelä wrote: >Doh, I missed this. I had the broken *.osm.pbf files lying around from >a previous broken run, and was just about to complain that the patch >fails to close the polygons, as your initial splitter.jar release did. >I will try this one more time on today's finland.osm.pbf The split time was reduced from 140ish (IIRC) to 102 seconds. There seems to be something wrong with the pbf output, because mkgmap is outputting this kind of messages: 2011/05/19 23:53:11 WARNING (OsmBinHandler): 63240005.osm.pbf: Way http://www.openstreetmap.org/browse/way/107168753 references undefined node 1231941341 2011/05/19 23:53:11 WARNING (OsmBinHandler): 63240005.osm.pbf: Way http://www.openstreetmap.org/browse/way/107168753 references undefined node 1232127462 2011/05/19 23:53:11 WARNING (OsmBinHandler): 63240005.osm.pbf: Way http://www.openstreetmap.org/browse/way/107168753 references undefined node 1232017145 Could it be that when you delete nodes outside the output tile, you forget to delete the node references from the way? I have not seen these messages before. Or is the osm.gz output of the splitter equally broken, but the mkgmap XML parser is not complaining about ways referencing deleted nodes? Apart from these warnings, I am still getting the warnings about unclosed polygons, like this: 2011/05/19 23:54:39 WARNING (StyledConverter): 63240008.osm.pbf: Unclosed way http://www.openstreetmap.org/browse/way/23679990 [natural=water] should be converted as shape but the start or end point lies inside the bbox. Skip it. For some reason, the pbf splitter workflow failed to issue the data error (one dead-end oneway) that I got reported for the same finland.osm.pbf when splitting it to osm.gz. Can you fix these issues? Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [locator] Country specific rules
El 19/05/11 22:12, WanMil escribió:
>> El 19/05/11 21:29, WanMil escribió:
El 16/05/11 19:27, Minko escribió:
> Cool!
> I can use these locator rules also for the multiple language expressions
> in the 'default_name':
> http://www.mail-archive.com/mkgmap-dev@lists.mkgmap.org.uk/msg07697.html
>
> Example:
> leisure=pitch& sport=soccer& (mkgmap:country=NLD |
> mgkmap:region=Vlaanderen) [0x19 default_name="voetbalveld" resolution 23]
> leisure=pitch& sport=soccer& mkgmap:country=DEU [0x19
> default_name="Fussballfeld" resolution 23]
> leisure=pitch& sport=soccer& (mkgmap:country=FRA |
> mgkmap:region="Région Wallone") [0x19 default_name="terrain de football"
> resolution 23]
> leisure=pitch& sport=soccer [0x19 resolution 23]
I tried rules of type below, but it doesn't work for Morocco.
highway=primary& (mkgmap:country=ETH | mkgmap:country=MAR) [0x03
road_class=3 road_speed=5 resolution 16]
highway=primary [0x03 road_class=3 road_speed=5 resolution 18]
MapSouce shows "Morocco (MOR)" in the countries list, although
LocatorConfig.xml has the rule below and there's no occurrence of "MOR"
in the OSM data.
MA
MAR
I know I could use MOR instead of MAR in my style but, shouldn't it be
consistent with the LocatorConfig?
>>> It seems as if the LocatorConfig you changed is not used by mkgmap. Do
>>> you use a downloaded mkgmap.jar? I am not sure where your changed
>>> LocatorConfig.xml must be placed so that mkgmap does not use the bundled
>>> LocatorConfig.xml.
>> I have not changed LocatorConfig.xml, I'm using the default one. I use a
>> self compiled jar.
> Oh, I am sorry. I mixed up some things.
Well, I'm must also say I'm sorry, as checking my parameters I've seen
MOR was coming from my --country-abbr:-[ , but changing it to the right
"MAR" didn't make the style work, although MapSource now lists "Morocco
(MAR)"
> Do you use the default-country parameter?
Using --country-name=MOROCCO
> Do you have other maps installed in MapSource?
Yes, more than 15
> I have no idea at the moment why Morocco is abbreviated with MOR but I
> will test that myself.
>
> WanMil
>
> "Région Wallone" is however not recognised, maybe the relation 90348 is
> not complete? JOSM is complaining about a few members without role.
>
> --
> Wanmil wrote:
>
>> Just wondering, maybe we can use the locator rules also for country or
>> state specific routing?
>> For instance in some countries (like Germany (?) according to the access
>> rules on osm, see
>> http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#Germany)
>> one is allowed to cycle on trunk roads, while in other countries like
>> in the Netherlands this is forbidden.
>>
>> In the style file maybe this is possible?
>>
>> mkgmap:country=NLD& highway=trunk {add bicycle=no}
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
--
Por favor, no me envíe documentos con extensiones .doc, .docx, .xls, .xlsx,
.ppt, .pptx, .mdb, mdbx
Instale OpenOffice desde http://es.openoffice.org/programa/index.html
OpenOffice es libre: se puede copiar, modificar y redistribuir libremente.
Gratis y totalmente legal.
OpenOffice está en continuo desarrollo y no tendrá que pagar por las nuevas
versiones.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [locator] Country specific rules
> El 19/05/11 22:12, WanMil escribió:
>>> El 19/05/11 21:29, WanMil escribió:
> El 16/05/11 19:27, Minko escribió:
>> Cool!
>> I can use these locator rules also for the multiple language expressions
>> in the 'default_name':
>> http://www.mail-archive.com/mkgmap-dev@lists.mkgmap.org.uk/msg07697.html
>>
>> Example:
>> leisure=pitch& sport=soccer& (mkgmap:country=NLD |
>> mgkmap:region=Vlaanderen) [0x19 default_name="voetbalveld" resolution 23]
>> leisure=pitch& sport=soccer& mkgmap:country=DEU [0x19
>> default_name="Fussballfeld" resolution 23]
>> leisure=pitch& sport=soccer& (mkgmap:country=FRA |
>> mgkmap:region="Région Wallone") [0x19 default_name="terrain de football"
>> resolution 23]
>> leisure=pitch& sport=soccer [0x19 resolution 23]
> I tried rules of type below, but it doesn't work for Morocco.
> highway=primary& (mkgmap:country=ETH | mkgmap:country=MAR) [0x03
> road_class=3 road_speed=5 resolution 16]
> highway=primary [0x03 road_class=3 road_speed=5 resolution 18]
>
> MapSouce shows "Morocco (MOR)" in the countries list, although
> LocatorConfig.xml has the rule below and there's no occurrence of "MOR"
> in the OSM data.
>
> MA
> MAR
>
> I know I could use MOR instead of MAR in my style but, shouldn't it be
> consistent with the LocatorConfig?
It seems as if the LocatorConfig you changed is not used by mkgmap. Do
you use a downloaded mkgmap.jar? I am not sure where your changed
LocatorConfig.xml must be placed so that mkgmap does not use the bundled
LocatorConfig.xml.
>>> I have not changed LocatorConfig.xml, I'm using the default one. I use a
>>> self compiled jar.
>> Oh, I am sorry. I mixed up some things.
> Well, I'm must also say I'm sorry, as checking my parameters I've seen
> MOR was coming from my --country-abbr:-[ , but changing it to the right
> "MAR" didn't make the style work, although MapSource now lists "Morocco
> (MAR)"
That's good because this question is answered :-)
The style can work only if the boundaries of Morocco are contained in
the precompiled boundary tiles. I think my europe compilation may
contain a small part of northern morocco.
So you should do the following steps:
1. Check that the boundary multipolygon of Morocco is complete and valid
2. Precompile the boundary tiles
3. Compile your map again using the precompiled boundary tiles
Then the style rules should work.
WanMil
>> Do you use the default-country parameter?
> Using --country-name=MOROCCO
>> Do you have other maps installed in MapSource?
> Yes, more than 15
>> I have no idea at the moment why Morocco is abbreviated with MOR but I
>> will test that myself.
>>
>
>> WanMil
>>
>> "Région Wallone" is however not recognised, maybe the relation 90348 is
>> not complete? JOSM is complaining about a few members without role.
>>
>> --
>> Wanmil wrote:
>>
>>> Just wondering, maybe we can use the locator rules also for country or
>>> state specific routing?
>>> For instance in some countries (like Germany (?) according to the
>>> access rules on osm, see
>>> http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#Germany)
>>> one is allowed to cycle on trunk roads, while in other countries like
>>> in the Netherlands this is forbidden.
>>>
>>> In the style file maybe this is possible?
>>>
>>> mkgmap:country=NLD&highway=trunk {add bicycle=no}
>> ___
>> 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] [locator] Country specific rules
El 19/05/11 23:15, WanMil escribió:
>> El 19/05/11 22:12, WanMil escribió:
El 19/05/11 21:29, WanMil escribió:
>> El 16/05/11 19:27, Minko escribió:
>>> Cool!
>>> I can use these locator rules also for the multiple language
>>> expressions in the 'default_name':
>>> http://www.mail-archive.com/mkgmap-dev@lists.mkgmap.org.uk/msg07697.html
>>>
>>> Example:
>>> leisure=pitch&sport=soccer&(mkgmap:country=NLD |
>>> mgkmap:region=Vlaanderen) [0x19 default_name="voetbalveld" resolution
>>> 23]
>>> leisure=pitch&sport=soccer&mkgmap:country=DEU [0x19
>>> default_name="Fussballfeld" resolution 23]
>>> leisure=pitch&sport=soccer&(mkgmap:country=FRA |
>>> mgkmap:region="Région Wallone") [0x19 default_name="terrain de
>>> football" resolution 23]
>>> leisure=pitch&sport=soccer [0x19 resolution 23]
>> I tried rules of type below, but it doesn't work for Morocco.
>> highway=primary& (mkgmap:country=ETH | mkgmap:country=MAR) [0x03
>> road_class=3 road_speed=5 resolution 16]
>> highway=primary [0x03 road_class=3 road_speed=5 resolution 18]
>>
>> MapSouce shows "Morocco (MOR)" in the countries list, although
>> LocatorConfig.xml has the rule below and there's no occurrence of "MOR"
>> in the OSM data.
>>
>> MA
>> MAR
>>
>> I know I could use MOR instead of MAR in my style but, shouldn't it be
>> consistent with the LocatorConfig?
> It seems as if the LocatorConfig you changed is not used by mkgmap. Do
> you use a downloaded mkgmap.jar? I am not sure where your changed
> LocatorConfig.xml must be placed so that mkgmap does not use the bundled
> LocatorConfig.xml.
I have not changed LocatorConfig.xml, I'm using the default one. I use a
self compiled jar.
>>> Oh, I am sorry. I mixed up some things.
>> Well, I'm must also say I'm sorry, as checking my parameters I've seen
>> MOR was coming from my --country-abbr:-[ , but changing it to the right
>> "MAR" didn't make the style work, although MapSource now lists "Morocco
>> (MAR)"
> That's good because this question is answered :-)
>
> The style can work only if the boundaries of Morocco are contained in
> the precompiled boundary tiles. I think my europe compilation may
> contain a small part of northern morocco.
> So you should do the following steps:
> 1. Check that the boundary multipolygon of Morocco is complete and valid
> 2. Precompile the boundary tiles
> 3. Compile your map again using the precompiled boundary tiles
>
> Then the style rules should work.
I had already compiled Morocco's boundary (extracted from Geofabrik
morocco.osm.pbf). What I didn't is converting bnd to gpx and checking
it, but that will be tomorrow...
PS: I tried to compile boundaries for all Africa, but there were errors
and it didn't complete. I fixed most multipolygon (boundary) errors
found in log and will try again tomorrow. As soon as I succeed I will
make them available.
> WanMil
>
>>> Do you use the default-country parameter?
>> Using --country-name=MOROCCO
>>> Do you have other maps installed in MapSource?
>> Yes, more than 15
>>> I have no idea at the moment why Morocco is abbreviated with MOR but I
>>> will test that myself.
>>>
>>> WanMil
>>>
>>> "Région Wallone" is however not recognised, maybe the relation 90348 is
>>> not complete? JOSM is complaining about a few members without role.
>>>
>>> --
>>> Wanmil wrote:
>>>
Just wondering, maybe we can use the locator rules also for country or
state specific routing?
For instance in some countries (like Germany (?) according to the
access rules on osm, see
http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#Germany)
one is allowed to cycle on trunk roads, while in other countries like
in the Netherlands this is forbidden.
In the style file maybe this is possible?
mkgmap:country=NLD& highway=trunk {add bicycle=no}
>>> ___
>>> 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
--
Por favor, no me envíe documentos con extensiones .doc, .docx, .xls, .xlsx,
.ppt, .pptx, .mdb, mdbx
Instale OpenOffice desde http://es.openoffice.org/programa/index.html
OpenOffice es libre: se puede copiar, modificar y redistribuir libremente.
Gratis y totalmente legal.
OpenOffice está en continuo desarrollo y no tendrá que pagar por las nuevas
versiones.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgma
Re: [mkgmap-dev] Splitter PBF support patch
On 5/19/2011 5:09 PM, mkgmap-dev-requ...@lists.mkgmap.org.uk wrote: > 2011/05/19 23:53:11 WARNING (OsmBinHandler): 63240005.osm.pbf: Way > http://www.openstreetmap.org/browse/way/107168753 references undefined > node 1231941341 > 2011/05/19 23:53:11 WARNING (OsmBinHandler): 63240005.osm.pbf: Way > http://www.openstreetmap.org/browse/way/107168753 references undefined > node 1232127462 > 2011/05/19 23:53:11 WARNING (OsmBinHandler): 63240005.osm.pbf: Way > http://www.openstreetmap.org/browse/way/107168753 references undefined > node 1232017145 > > Could it be that when you delete nodes outside the output tile, you > forget to delete the node references from the way? I have not seen > these messages before. Or is the osm.gz output of the splitter equally > broken, but the mkgmap XML parser is not complaining about ways > referencing deleted nodes? Can you check if the regular OSM XML path still works without these messages? > Apart from these warnings, I am still getting the warnings about > unclosed polygons, like this: > > 2011/05/19 23:54:39 WARNING (StyledConverter): 63240008.osm.pbf: > Unclosed way http://www.openstreetmap.org/browse/way/23679990 > [natural=water] should be converted as shape but the start or end > point lies inside the bbox. Skip it. > > For some reason, the pbf splitter workflow failed to issue the data > error (one dead-end oneway) that I got reported for the same > finland.osm.pbf when splitting it to osm.gz. > > Can you fix these issues? Can you tell me exactly what file you used for input and the settings you used? I can give it a try but I would like first to know if my patch broke anything on the old XML path. I could try to make the selection of XML or PBF output based on the input instead of the current default of XML. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Slowness processing specific tile
Le 19/05/2011 22:51, Felix Hartmann a écrit : >> Do not know whether or not that the same pb, but two or three months >> ago, when I run splitter and mkgmap to create a gmapsupp.img file, >> against france.osm data, it took 4 hours to create it. On the same >> machine, with the same scripts, it takes now 17 hours. My main pb is >> with splitter as for example, it began to run yesterday at 11pm and end >> its run today at 11.56am. 13 hours to split, but the machine is really >> not a big one :-) >> Francois >> > Well in that case your machine is the culprit. France splits in around > 16 minutes for me. And takes bout 60minutes to compile (12GB Ram, Intel > Core somthing (4 cores). Maybe, maybe, but tonight, using a backup of a splitter.jar file I compiled on february 19th, it took one hour to split France. The latest splitter code I compiled yesterday, took 17 hours to split France. Same data (osm data), same machine. ls splitter.jar* -rw-r--r-- 1 xx 286292 2011-02-19 22:59 splitter.jar.old -rw-r--r-- 1 xx 272603 2011-05-19 23:02 splitter.jar Francois -- ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Splitter PBF support patch
Hi Francisco,
On Thu, May 19, 2011 at 10:24:08PM -0400, Francisco Moraes wrote:
Can you check if the regular OSM XML path still works without these
messages?
I am checking that now, but with today's dump instead of yesterday's.
The splitting time is 199s for osm.gz vs 102s for osm.pbf.
The XML path seems to be unaffected by your patch. My filter only passed
two errors, which I will soon correct (so that they should not be in
tomorrow's finland.osm.pbf).
2011/05/20 08:27:10 WARNING (SeaGenerator): 63240001.osm.gz: Converting
anti-island starting at
http://www.openstreetmap.org/?mlat=59.96130&mlon=19.95804&zoom=17 into
an island as it is surrounded by water
2011/05/20 08:31:39 WARNING (RouteNode): 63240005.osm.gz: Oneway road
(http://www.openstreetmap.org/browse/way/36917351) goes nowhere at
http://www.openstreetmap.org/?mlat=62.27274&mlon=25.2&zoom=17
Can you tell me exactly what file you used for input and the settings
you used?
You can get my scripts at http://www.polkupyoraily.net/osm/. A patch
against my osm2img.sh is attached.
I can give it a try but I would like first to know if my patch
broke anything on the old XML path.
Could it make sense to use Osmosis for testing? Convert the split tiles
with Osmosis to a "canonical format", whatever that might be, and ensure
that the XML and Protobuf paths yield the same results. Steve should
have good ideas from the times when he implemented the osm.pbf parser in
mkgmap. One option would be to process the tiles with mkgmap and then
compare the mkgmap log output (after stripping timestamps and sorting
the messages, so that the different ordering of the messages does not
matter).
I could try to make the selection of XML or PBF output based on the
input instead of the current default of XML.
That is a good idea.
Best regards,
Marko
--- osm2imgpbf.sh 2011-05-20 08:29:56.0 +0300
+++ osm2img.sh 2011-04-20 11:39:18.0 +0300
@@ -31,7 +31,7 @@
wget -N http://download.geofabrik.de/osm/europe/"$OSM";
if [ -f "$ZIP" -a ! "$OSM" -nt "$ZIP" ]; then exit; fi
-$JAVACMD $JAVACMD_OPTIONS -jar splitter.jar --pbf --split-file=areas.list "$OSM"
+$JAVACMD $JAVACMD_OPTIONS -jar splitter.jar --split-file=areas.list "$OSM"
rm -f 6324*.img
mkgmap() {
@@ -44,23 +44,23 @@
mkgmap_tiles() {
mkgmap "$@" \
--description='L\304ntinen Suomenlahti' \
- --mapname=6324${L}001 --input-file=63240001.osm.pbf \
+ --mapname=6324${L}001 --input-file=63240001.osm.gz \
--description='Helsinki' \
- --mapname=6324${L}002 --input-file=63240002.osm.pbf \
+ --mapname=6324${L}002 --input-file=63240002.osm.gz \
--description='It\304inen Suomenlahti' \
- --mapname=6324${L}003 --input-file=63240003.osm.pbf \
+ --mapname=6324${L}003 --input-file=63240003.osm.gz \
--description='Lounainen Suomi' \
- --mapname=6324${L}004 --input-file=63240004.osm.pbf \
+ --mapname=6324${L}004 --input-file=63240004.osm.gz \
--description='Etel\304inen Suomi' \
- --mapname=6324${L}005 --input-file=63240005.osm.pbf \
+ --mapname=6324${L}005 --input-file=63240005.osm.gz \
--description='Kaakkois-Suomi' \
- --mapname=6324${L}006 --input-file=63240006.osm.pbf \
+ --mapname=6324${L}006 --input-file=63240006.osm.gz \
--description='Keskinen Suomi' \
- --mapname=6324${L}007 --input-file=63240007.osm.pbf \
+ --mapname=6324${L}007 --input-file=63240007.osm.gz \
--description='Oulu' \
- --mapname=6324${L}008 --input-file=63240008.osm.pbf \
+ --mapname=6324${L}008 --input-file=63240008.osm.gz \
--description='Lappi' $GL \
- --mapname=6324${L}009 --input-file=63240009.osm.pbf
+ --mapname=6324${L}009 --input-file=63240009.osm.gz
}
L1="--family-id=1 --family-name=$(date -r"$OSM" +"OSM-%x")"
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Splitter PBF support patch
Am 20.05.2011 07:37, schrieb Marko Mäkelä: > >> I could try to make the selection of XML or PBF output based on the >> input instead of the current default of XML. > > That is a good idea. I think this is a bad idea, because it will confuse the users. I would name the parameter --output=pbf or --output=xml. If no parameter --output is specified, splitter should write xml. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
