Re: [mkgmap-dev] [locator] Europe boundary data for download
Cool, r1935 solved a lot of issues, I see a lot of streetnames now that are
located to places.
On the nuvi 310 and on the Dakota this seem to work. Congratulations and thanks
Wanmil!
About the finetuning per country, you could try some regular expression:
mkgmap:admin_level2 ~ '\bN\w*\b' which means everything that starts with N
will match
Do'nt know if this will work, I have to test it for the Benelux:
mkgmap:city!=* mkgmap:admin_level2 ~ '\bN\w*\b' mkgmap:admin_level10=* { set
mkgmap:city='${mkgmap:admin_level10}' }
mkgmap:city!=* mkgmap:admin_level2 ~ '\bB\w*\b' mkgmap:admin_level9=* { set
mkgmap:city='${mkgmap:admin_level9}' }
mkgmap:city!=* mkgmap:admin_level2 ~ '\bD\w*\b' mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:city!=* mkgmap:admin_level2 ~ '\bL\w*\b' mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
In Belgium the streetnames are in level 9 I think?
Waht about regions, In Belgium Provinces seem to be in either 5 or 6 (depending
if its in Vlaanderen or Wallonie?)
In the Netherlands in 4.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [locator] Osmosis parameters required
El 01/05/11 19:44, WanMil escribió: Am 30.04.2011 14:19, schrieb Carlos Dávila: El 30/04/11 13:00, Henning Scholland escribió: Am 30.04.2011 12:58, schrieb Henning Scholland: osmosis --read-pbf europe.osm.pbf --tf accept-ways boundary=administrative --used-node --tf accept-relations boundary=administrative --used-way --write-xml boundary.osm Sorry, I've forgotten an --used-node osmosis --read-pbf europe.osm.pbf --tf accept-ways boundary=administrative --used-node --tf accept-relations boundary=administrative --used-way --used-node --write-xml boundary.osm I get exactly the same file than without the extra --used-node in the ways --tf task. I've posted a question to the osmosis mailing list: http://lists.openstreetmap.org/pipermail/osmosis-dev/2011-April/001019.html The osmosis list has the answer: The osmosis call has to be split to 3 calls (it is possible to use the merge command and to make it in one call but the following works for sure): osmosis.bat --rb europe.osm.pbf --tf accept-ways boundary=administrative --used-node --wb bways.osm.pbf osmosis.bat --rb europe.osm.pbf --tf accept-relations boundary=administrative --used-way --used-node --wb brels.osm.pbf osmosis.bat --rb bways.osm.pbf outPipe.0=W --rb brels.osm.pbf outPipe.0=R --merge inPipe.0=W inPipe.1=R --wb europe-boundaries.osm.pbf Warning: This really needs a long time to finish. WanMil Just to complete the information, this is the only osmosis call that worked for me to extract relations: osmosis --rb europe.osm.pbf --tf accept-relations boundary=administrative --used-node idTrackerType=BitSet --used-way idTrackerType=BitSet --wb boundary_relations.osm.pbf Without the idTrackerType=BitSet java heap space errors stop the process. It complains I should have used omitmetadata=true, but completed the task. I don't know if it is because I had previously extracted a bounding box from the original europe.osm.pbf ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [locator] Europe boundary data for download
El 03/05/11 13:40, Carlos Dávila escribió: El 02/05/11 22:33, WanMil escribió: Do somebody know, what this error means: Ccode == null name=BELGI? - BELGIQUE - BELGIEN I have seen them too. The border of belgium is tagged with boundary=administrative, admin_level=2, name=BELGIE - BELGIQUE - BELGIEN The name is not contained in the LocatorConfig.xml so the Locator does not know the 3 letter ISO code for it. The error message is not good but it was meant only for me for debugging purposes. I get the error below, but Gibraltar / United Kingdom is in the LocatorConfig.xml. What's the reason in this case? Ccode == null name=GIBRALTAR / UNITED KINGDOM What about the Highway X has no region (define a default region to zap this warning)? Does it mean highway X is not inside any of the boundary polygons? In such case, how to locate highway X to debug it? Only the ref is supplied and there can be lots of ways with such ref. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] set name and Address search
It is really practical for driving instructions, to add stuff like
/{set name='snowpark ${name}' | 'snowpark'}/
However in most cases, this is not wanted to be taken over to the
address search. There ideal solution would be to have 3 modi:
1. set mkgmap:name =meaning, this name will only be used for the
streetname, but not for the address search index
2. set name ...= current behaviour
3. set copy:name ...=take both the original and the new name into the
address search.
For 1. 2. I hope they are easy to implement, and think it is really
needed.
For 3. I think there would need to be some more thought - probably more
complicated, but could be nice to have. I would want to use it to have
multilingual address search, but I don't know how much and what is
possible. Currently I use this for cities, so cities are findable in the
city poi search both under their local name, and under their english
name. Even better would be of course, If I were able to find 12
Teststreet, Vienna, Austria, but also 12 Teststraße, Wien, Österreich
but dunno whether this is acutally possible and won't blow up the index
too much.
___
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
El 27/04/11 20:33, Steve Ratcliffe escribió: Hello and out. All fine, but as soon as you select one tile Mapsosurce crashes. Ahh, that is a useful observation, thanks. Just another thought ... could it be that C/H/S information should be calculated dynamically based on the actual size of a .img-file? Maybe this could save memory on a GPS when the tiles are loaded ... this is speculation since I don't know exactly how this is implemented. Yes it should be. I just hoped that it would not be required, as it always worked when the max size was smaller. ;) I'll see what it would take to get the size into the header. After merging changes from trunk to locator branch I have the same problem with the mkgmap-locator. Is there any other information I can supply or any test to run to help debugging this issue? ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [locator] Europe boundary data for download
El 02/05/11 22:33, WanMil escribió: Do somebody know, what this error means: Ccode == null name=BELGI? - BELGIQUE - BELGIEN I have seen them too. The border of belgium is tagged with boundary=administrative, admin_level=2, name=BELGIE - BELGIQUE - BELGIEN The name is not contained in the LocatorConfig.xml so the Locator does not know the 3 letter ISO code for it. The error message is not good but it was meant only for me for debugging purposes. I get the error below, but Gibraltar / United Kingdom is in the LocatorConfig.xml. What's the reason in this case? Ccode == null name=GIBRALTAR / UNITED KINGDOM Don't know. I have to check that. WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [locator] Osmosis parameters required
El 01/05/11 19:44, WanMil escribió: Am 30.04.2011 14:19, schrieb Carlos Dávila: El 30/04/11 13:00, Henning Scholland escribió: Am 30.04.2011 12:58, schrieb Henning Scholland: osmosis --read-pbf europe.osm.pbf --tf accept-ways boundary=administrative --used-node --tf accept-relations boundary=administrative --used-way --write-xml boundary.osm Sorry, I've forgotten an --used-node osmosis --read-pbf europe.osm.pbf --tf accept-ways boundary=administrative --used-node --tf accept-relations boundary=administrative --used-way --used-node --write-xml boundary.osm I get exactly the same file than without the extra --used-node in the ways --tf task. I've posted a question to the osmosis mailing list: http://lists.openstreetmap.org/pipermail/osmosis-dev/2011-April/001019.html The osmosis list has the answer: The osmosis call has to be split to 3 calls (it is possible to use the merge command and to make it in one call but the following works for sure): osmosis.bat --rb europe.osm.pbf --tf accept-ways boundary=administrative --used-node --wb bways.osm.pbf osmosis.bat --rb europe.osm.pbf --tf accept-relations boundary=administrative --used-way --used-node --wb brels.osm.pbf osmosis.bat --rb bways.osm.pbf outPipe.0=W --rb brels.osm.pbf outPipe.0=R --merge inPipe.0=W inPipe.1=R --wb europe-boundaries.osm.pbf Warning: This really needs a long time to finish. WanMil Just to complete the information, this is the only osmosis call that worked for me to extract relations: osmosis --rb europe.osm.pbf --tf accept-relations boundary=administrative --used-node idTrackerType=BitSet --used-way idTrackerType=BitSet --wb boundary_relations.osm.pbf Without the idTrackerType=BitSet java heap space errors stop the process. It complains I should have used omitmetadata=true, but completed the task. I don't know if it is because I had previously extracted a bounding box from the original europe.osm.pbf The warning with omitmetadata=true seems to be a known osmosis warning without any effect. I have just ignored it. As it is documented the idTrackerType is an option that can be used to optimize the used-node and used-way implementation. If you give osmosis more memory it will definitely work without the option. But in some configurations it might be faster and less memory intensive. WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [locator] Europe boundary data for download
El 03/05/11 13:40, Carlos Dávila escribió: El 02/05/11 22:33, WanMil escribió: Do somebody know, what this error means: Ccode == null name=BELGI? - BELGIQUE - BELGIEN I have seen them too. The border of belgium is tagged with boundary=administrative, admin_level=2, name=BELGIE - BELGIQUE - BELGIEN The name is not contained in the LocatorConfig.xml so the Locator does not know the 3 letter ISO code for it. The error message is not good but it was meant only for me for debugging purposes. I get the error below, but Gibraltar / United Kingdom is in the LocatorConfig.xml. What's the reason in this case? Ccode == null name=GIBRALTAR / UNITED KINGDOM What about the Highway X has no region (define a default region to zap this warning)? Does it mean highway X is not inside any of the boundary polygons? In such case, how to locate highway X to debug it? Only the ref is supplied and there can be lots of ways with such ref. I don't understand what you are talking about. Please be more specific what your problem is. WanMil ___ 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'll see what it would take to get the size into the header. After merging changes from trunk to locator branch I have the same problem with the mkgmap-locator. Is there any other information I can supply or any test to run to help debugging this issue? The puzzle is why no one else sees this (or do they?!). What version of MapSource are you using? Currently the header information is written before the size is known, so I might have to make a temporary fix, that allows the gmapsupp and similar files to be larger while reducing the max size of tiles. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Non way element X in multipolygon Y
Charlie Ferrero schrieb am 28.04.2011 09:46: Why is the warning correct? The wiki says that a boundary multipolygon can contain a node tagged admin_centre. Isn't this mkgmap warning a false positive? Actually this is depending on the type of the relation. With type=multipolygon there shouldn't be any non-way member in the relation, with type=boundary the role admin_centre is defined. There is no such thing as a boundary multipolygon, you have either one or the other. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [locator] Europe boundary data for download
El 03/05/11 17:54, WanMil escribió: El 03/05/11 13:40, Carlos Dávila escribió: El 02/05/11 22:33, WanMil escribió: Do somebody know, what this error means: Ccode == null name=BELGI? - BELGIQUE - BELGIEN I have seen them too. The border of belgium is tagged with boundary=administrative, admin_level=2, name=BELGIE - BELGIQUE - BELGIEN The name is not contained in the LocatorConfig.xml so the Locator does not know the 3 letter ISO code for it. The error message is not good but it was meant only for me for debugging purposes. I get the error below, but Gibraltar / United Kingdom is in the LocatorConfig.xml. What's the reason in this case? Ccode == null name=GIBRALTAR / UNITED KINGDOM What about the Highway X has no region (define a default region to zap this warning)? Does it mean highway X is not inside any of the boundary polygons? In such case, how to locate highway X to debug it? Only the ref is supplied and there can be lots of ways with such ref. I don't understand what you are talking about. Please be more specific what your problem is. Perhaps I did a wrong guess, but I supposed region for any highway should be supplied by the new locator algorithm. If that's right, the warning implies the affected way falls within an area not covered by any boundary polygon. So I would like to be able to locate that way to search why there is no boundary for that area. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [locator] Europe boundary data for download
El 03/05/11 17:54, WanMil escribió: El 03/05/11 13:40, Carlos Dávila escribió: El 02/05/11 22:33, WanMil escribió: Do somebody know, what this error means: Ccode == null name=BELGI? - BELGIQUE - BELGIEN I have seen them too. The border of belgium is tagged with boundary=administrative, admin_level=2, name=BELGIE - BELGIQUE - BELGIEN The name is not contained in the LocatorConfig.xml so the Locator does not know the 3 letter ISO code for it. The error message is not good but it was meant only for me for debugging purposes. I get the error below, but Gibraltar / United Kingdom is in the LocatorConfig.xml. What's the reason in this case? Ccode == null name=GIBRALTAR / UNITED KINGDOM What about the Highway X has no region (define a default region to zap this warning)? Does it mean highway X is not inside any of the boundary polygons? In such case, how to locate highway X to debug it? Only the ref is supplied and there can be lots of ways with such ref. I don't understand what you are talking about. Please be more specific what your problem is. Perhaps I did a wrong guess, but I supposed region for any highway should be supplied by the new locator algorithm. If that's right, the warning implies the affected way falls within an area not covered by any boundary polygon. So I would like to be able to locate that way to search why there is no boundary for that area. Please provide the excat error message and your complete mkgmap options and your mkgmap version. WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [locator] Europe boundary data for download
El 02/05/11 22:33, WanMil escribió: Do somebody know, what this error means: Ccode == null name=BELGI? - BELGIQUE - BELGIEN I have seen them too. The border of belgium is tagged with boundary=administrative, admin_level=2, name=BELGIE - BELGIQUE - BELGIEN The name is not contained in the LocatorConfig.xml so the Locator does not know the 3 letter ISO code for it. The error message is not good but it was meant only for me for debugging purposes. I get the error below, but Gibraltar / United Kingdom is in the LocatorConfig.xml. What's the reason in this case? Ccode == null name=GIBRALTAR / UNITED KINGDOM I have compiled spain with a geofabrik dump of today and did not get this error message. WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Non way element X in multipolygon Y
Torsten Leistikow (de_m...@gmx.de) wrote: Charlie Ferrero schrieb am 28.04.2011 09:46: Why is the warning correct? The wiki says that a boundary multipolygon can contain a node tagged admin_centre. Isn't this mkgmap warning a false positive? Actually this is depending on the type of the relation. With type=multipolygon there shouldn't be any non-way member in the relation, with type=boundary the role admin_centre is defined. There is no such thing as a boundary multipolygon, you have either one or the other. You're right - I wrote boundary multipolygon but I meant boundary relation. -- Charlie ___ 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
El 03/05/11 17:56, Steve Ratcliffe escribió: Hi I'll see what it would take to get the size into the header. After merging changes from trunk to locator branch I have the same problem with the mkgmap-locator. Is there any other information I can supply or any test to run to help debugging this issue? The puzzle is why no one else sees this (or do they?!). What version of MapSource are you using? 6.13.7 on debian under wine Currently the header information is written before the size is known, so I might have to make a temporary fix, that allows the gmapsupp and similar files to be larger while reducing the max size of tiles. As I only have this problem with Spain map, which I compile from tiles obtained with a high maxnodes, I tried reducing it in splitter and now I can open the map in MapSource, so the problem seems to be in the size of the input data. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [locator] Europe boundary data for download
El 03/05/11 18:24, WanMil escribió: El 03/05/11 17:54, WanMil escribió: El 03/05/11 13:40, Carlos Dávila escribió: El 02/05/11 22:33, WanMil escribió: Do somebody know, what this error means: Ccode == null name=BELGI? - BELGIQUE - BELGIEN I have seen them too. The border of belgium is tagged with boundary=administrative, admin_level=2, name=BELGIE - BELGIQUE - BELGIEN The name is not contained in the LocatorConfig.xml so the Locator does not know the 3 letter ISO code for it. The error message is not good but it was meant only for me for debugging purposes. I get the error below, but Gibraltar / United Kingdom is in the LocatorConfig.xml. What's the reason in this case? Ccode == null name=GIBRALTAR / UNITED KINGDOM What about the Highway X has no region (define a default region to zap this warning)? Does it mean highway X is not inside any of the boundary polygons? In such case, how to locate highway X to debug it? Only the ref is supplied and there can be lots of ways with such ref. I don't understand what you are talking about. Please be more specific what your problem is. Perhaps I did a wrong guess, but I supposed region for any highway should be supplied by the new locator algorithm. If that's right, the warning implies the affected way falls within an area not covered by any boundary polygon. So I would like to be able to locate that way to search why there is no boundary for that area. Please provide the excat error message just a few ones: 2011/05/03 16:09:31 ADVERTENCIA (MapBuilder): 55140001.osm.gz: Highway CV-35 has no region (define a default region to zap this warning) 2011/05/03 16:09:31 ADVERTENCIA (MapBuilder): 55140001.osm.gz: Highway A-3 has no region (define a default region to zap this warning) 2011/05/03 16:09:31 ADVERTENCIA (MapBuilder): 55140001.osm.gz: Highway A-7 has no region (define a default region to zap this warning) 2011/05/03 16:09:31 ADVERTENCIA (MapBuilder): 55140001.osm.gz: Highway Ma-13 has no region (define a default region to zap this warning) 2011/05/03 16:09:31 ADVERTENCIA (MapBuilder): 55140001.osm.gz: Highway AP-7 has no region (define a default region to zap this warning) and your complete mkgmap options java -Xmx1500m -enableassertions -Dlog.config=logging.properties -jar mkgmap-locator.jar --createboundsfile=boundaries-peninsula.osm --max-jobs --generate-sea=polygons,extend-sea-sectors --route --latin1 --code-page=1252 --gmapsupp --country-name=ESPAÑA --country-abbr=ESP --area-name=España --family-name=OpenStreetMap España --family-id=39 --product-id=1 --series-name=OSM-España-index --index --ignore-maxspeeds --remove-short-arcs --add-pois-to-areas --adjust-turn-headings --report-similar-arcs --link-pois-to-ways --location-autofill=0 --drive-on-right --check-roundabouts --check-roundabout-flares --style=mio -c spain.args and your mkgmap version. r1935 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [locator] Europe boundary data for download
El 03/05/11 18:25, WanMil escribió: El 02/05/11 22:33, WanMil escribió: Do somebody know, what this error means: Ccode == null name=BELGI? - BELGIQUE - BELGIEN I have seen them too. The border of belgium is tagged with boundary=administrative, admin_level=2, name=BELGIE - BELGIQUE - BELGIEN The name is not contained in the LocatorConfig.xml so the Locator does not know the 3 letter ISO code for it. The error message is not good but it was meant only for me for debugging purposes. I get the error below, but Gibraltar / United Kingdom is in the LocatorConfig.xml. What's the reason in this case? Ccode == null name=GIBRALTAR / UNITED KINGDOM I have compiled spain with a geofabrik dump of today and did not get this error message. I got it with the same mkgmap version and parameters sent in my previous mail ___ 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
El 03/05/11 18:56, Carlos Dávila escribió: El 03/05/11 17:56, Steve Ratcliffe escribió: Hi I'll see what it would take to get the size into the header. After merging changes from trunk to locator branch I have the same problem with the mkgmap-locator. Is there any other information I can supply or any test to run to help debugging this issue? The puzzle is why no one else sees this (or do they?!). What version of MapSource are you using? 6.13.7 on debian under wine Currently the header information is written before the size is known, so I might have to make a temporary fix, that allows the gmapsupp and similar files to be larger while reducing the max size of tiles. As I only have this problem with Spain map, which I compile from tiles obtained with a high maxnodes, I tried reducing it in splitter and now I can open the map in MapSource, so the problem seems to be in the size of the input data. __ Forget it, I used the wrong jar file. The problem persists. Sorry for the false information. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Splitter output files are nearly empty
On Tue, May 03, 2011 at 05:48:55PM +0200, Lambertus wrote: Recently I've upgraded upgraded all my Garmin map making tools to the latest versions: Osmosis 0.39 Splitter r171 Mkgmap r1926 Since then I'm having a problem while splitting the planet file: all output files are empty (~160 bytes). It looks like a splitter problem. In de commandline output I notice two things for which I seek input: - What does * Full GC * mean? I assume that GC means garbage collection. Which JVM are you using? An educated guess is that the memory runs out and a full garbage collection cycle is started as a last resort. - Is input from stdin still functional/supported for splitter? I am not sure. I am using pbf output. Below is the commandline and output. Commandline: bunzip2 -d -c -k /home/lambertus/planet.openstreetmap.org/world.osm.bz2 | ~/garmin/utils/osmosis/bin/osmosis --rx - --tf reject-ways building=* --tf reject-nodes type=communication --tf reject-ways admin_level=8 --tf reject-ways admin_level=9 --tf reject-ways admin_level=10 --wx file='-' Why not use osmosis --rb world.osm.pbf ... --wb filtered-world.osm.pbf and ... splitter.jar filtered-world.osm.pbf | java -Xmx7500m -ea -jar ~/garmin/utils/splitter/splitter.jar --no-trim --cache=cache --mapid=63240001 --max-nodes=140 --write-kml=world.kml --geonames-file=/home/lambertus/garmin/utils/cities15000.zip /dev/stdin I am not sure if the --cache option still works. It was sort of superceded or made unnecessary by the Protobuf input format support. Best regards, Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] continue statement and order of drawn ways?
Hi, I tried to create a map where you can see arrows for oneway streets. For this I have the normal street, and wanted to create an overlay containing an arrow and a transparent background. I tried this with the continue statement. I tried the following statements: highway=motorway oneway=yes [0x01 road_class=4 road_speed=7 level 6 continue] highway=motorway oneway=yes [0x10f01 level 6] and highway=motorway oneway=yes [0x10f01 level 6 continue] highway=motorway oneway=yes [0x01 road_class=4 road_speed=7 level 6] But with both statements, the arrow is always drawn below the street. Is it somehow possible to have the arrow on top of the street? Thanks, Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] continue statement and order of drawn ways?
Thorsten Kukuk schrieb am 03.05.2011 20:53: But with both statements, the arrow is always drawn below the street. Is it somehow possible to have the arrow on top of the street? The drawing order of the lines in a single map is not really understood and can not be set via the style file. For such tasks I use multiple map layers (base layer + overlay layer), the display order of the complete maps can be defined via mkgmap command line parameter (draw-priotrity) Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Address search map information needed
Hi, I've used the --index (and related options) to generate a map with address search for North Carolina. It worked in Map Source but the city relation is not present. What's the appropriate way for data to be marked as in a given city/state/country in OSM? I also was not able to perform any searches from my Oregon 450 with the generated map. Is this actually supported? It asked for the State/Province, but no matter what I typed, I always got an empty result. Francisco ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] continue statement and order of drawn ways?
On Tue, May 03, Torsten Leistikow wrote: Thorsten Kukuk schrieb am 03.05.2011 20:53: But with both statements, the arrow is always drawn below the street. Is it somehow possible to have the arrow on top of the street? The drawing order of the lines in a single map is not really understood and can not be set via the style file. Ok, thanks. That was the impression I got meanwhile, too. For such tasks I use multiple map layers (base layer + overlay layer), the display order of the complete maps can be defined via mkgmap command line parameter (draw-priotrity) I'm working already with several overlay layers, too. I wanted to avoid to create yet another one, but looks like that's the way to go. Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address search map information needed
El 03/05/11 21:46, Francisco Moraes escribió: Hi, I've used the --index (and related options) to generate a map with address search for North Carolina. It worked in Map Source but the city relation is not present. What's the appropriate way for data to be marked as in a given city/state/country in OSM? Any place tagged as city/town/village should be in the cities list. I also was not able to perform any searches from my Oregon 450 with the generated map. Is this actually supported? It asked for the State/Province, but no matter what I typed, I always got an empty result. You need to send the map to the device from MapSource. The gmapsupp.img generated by mkgmap doesn't (yet) include the address index. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] continue statement and order of drawn ways?
On 03/05/2011 21:13, Thorsten Kukuk wrote: On Tue, May 03, Torsten Leistikow wrote: Thorsten Kukuk schrieb am 03.05.2011 20:53: But with both statements, the arrow is always drawn below the street. Is it somehow possible to have the arrow on top of the street? The drawing order of the lines in a single map is not really understood and can not be set via the style file. Ok, thanks. That was the impression I got meanwhile, too. For such tasks I use multiple map layers (base layer + overlay layer), the display order of the complete maps can be defined via mkgmap command line parameter (draw-priotrity) I'm working already with several overlay layers, too. I wanted to avoid to create yet another one, but looks like that's the way to go. Thorsten Would something like this work? highway=motorway [0x01 road_class=4 road_speed=7 level 6 continue] highway=motorway oneway=yes [0x10f01 level 6] highway=motorway oneway!=yes [0x10f02 level 6] Then style 0x01 with no style (so nothing is drawn) - 0x01 would be used for the routing information. Then style 0x10f02 as plain motorway and 0x10f01 as motorway with arrows. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Splitter output files are nearly empty
On 03-05-11 20:01, Marko Mäkelä wrote: On Tue, May 03, 2011 at 05:48:55PM +0200, Lambertus wrote: I assume that GC means garbage collection. Which JVM are you using? An educated guess is that the memory runs out and a full garbage collection cycle is started as a last resort. Ok, Garbage Collection sounds reasonable, but I gave Java 7.5 GB heap space while it used only a few hundred megabytes. I've got no idea why it would run out of memory. java version 1.6.0_24 Java(TM) SE Runtime Environment (build 1.6.0_24-b07) Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode) - Is input from stdin still functional/supported for splitter? I am not sure. I am using pbf output. Yeah, I'm slow in moving to pbf, but is OSM XML really not functional/supported anymore? Splitter seems to accept the XML in the first phase without complaints. It's only in the step where it starts to write-out the tiles that is starts to complain. It would be better if Splitter rejects the input if it can't handle it properly later on? Why not use osmosis --rb world.osm.pbf ... --wb filtered-world.osm.pbf and ... splitter.jar filtered-world.osm.pbf Well I wanted to run multiple processes at the same time to utilize the quadcore CPU better and reduce processing time (but, then I shouldn't have used bz2 XML in the first place). Ok, I'll try this next. I am not sure if the --cache option still works. It was sort of superceded or made unnecessary by the Protobuf input format support. Oh, if it's not working anymore then I assume it will ignore the option. Or is this too simple thinking? Thanks for the response Marko. I'll start a new run using Osmosis pbf output. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Splitter output files are nearly empty
On Tue, May 03, Lambertus wrote: On 03-05-11 20:01, Marko Mäkelä wrote: On Tue, May 03, 2011 at 05:48:55PM +0200, Lambertus wrote: I assume that GC means garbage collection. Which JVM are you using? An educated guess is that the memory runs out and a full garbage collection cycle is started as a last resort. Ok, Garbage Collection sounds reasonable, but I gave Java 7.5 GB heap space while it used only a few hundred megabytes. I've got no idea why it would run out of memory. Do you really have so much free memory available? If you tell Java it should use 7.5GB heap space, it will use that, even if not available, and fail. I run Java with 4GB heap space (machine had more), but since other processes allocated memory, too, it did fail sometimes with similar symptoms. After I reduced the memory to 2.5 GB heap space, it runs fine. -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] continue statement and order of drawn ways?
Yes, that is also a good alternative, 0x01 as a transparent line and on top either 0x10f01 or 0x10f02 MarkS wrote: Would something like this work? highway=motorway [0x01 road_class=4 road_speed=7 level 6 continue] highway=motorway oneway=yes [0x10f01 level 6] highway=motorway oneway!=yes [0x10f02 level 6] Then style 0x01 with no style (so nothing is drawn) - 0x01 would be used for the routing information. Then style 0x10f02 as plain motorway and 0x10f01 as motorway with arrows. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] continue statement and order of drawn ways?
On 03.05.2011 23:27, Minko wrote: Yes, that is also a good alternative, 0x01 as a transparent line and on top either 0x10f01 or 0x10f02 you cannot make a line transparent by omitting it from the typfile, but go ahead and do your tries. MarkS wrote: Would something like this work? highway=motorway [0x01 road_class=4 road_speed=7 level 6 continue] highway=motorway oneway=yes [0x10f01 level 6] highway=motorway oneway!=yes [0x10f02 level 6] Then style 0x01 with no style (so nothing is drawn) - 0x01 would be used for the routing information. Then style 0x10f02 as plain motorway and 0x10f01 as motorway with arrows. ___ 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] Error on MapSource with r1919
What version of MapSource are you using? 6.16.3 on Win7_x64 Peter ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Splitter output files are nearly empty
On 03-05-11 23:25, Thorsten Kukuk wrote: On Tue, May 03, Lambertus wrote: Ok, Garbage Collection sounds reasonable, but I gave Java 7.5 GB heap space while it used only a few hundred megabytes. I've got no idea why it would run out of memory. Do you really have so much free memory available? If you tell Java it should use 7.5GB heap space, it will use that, even if not available, and fail. I run Java with 4GB heap space (machine had more), but since other processes allocated memory, too, it did fail sometimes with similar symptoms. After I reduced the memory to 2.5 GB heap space, it runs fine. The machine's got 8 GB ram and 8 GB swap. There were other processes running as well, like bunzip and Osmosis but those don't use much ram. Even so, the logs say it's using only 250 MB ram, that should not cause problems right? If the logs said it was using more then 6GB then, ok, I could accept such an explanation, but 250 MB ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] continue statement and order of drawn ways?
Am 03.05.2011 23:37, schrieb Felix Hartmann: On 03.05.2011 23:27, Minko wrote: Yes, that is also a good alternative, 0x01 as a transparent line and on top either 0x10f01 or 0x10f02 you cannot make a line transparent by omitting it from the typfile, but go ahead and do your tries. Yes, but you can use a transparent png-file ;) Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] continue statement and order of drawn ways?
Am 03.05.2011 22:10, schrieb Josef Latt: Hi, Am 03.05.2011 20:53, schrieb Thorsten Kukuk: Hi, I tried to create a map where you can see arrows for oneway streets. For this I have the normal street, and wanted to create an overlay containing an arrow and a transparent background. I tried this with the continue statement. I tried the following statements: highway=motorway oneway=yes [0x01 road_class=4 road_speed=7 level 6 continue] highway=motorway oneway=yes [0x10f01 level 6] and highway=motorway oneway=yes [0x10f01 level 6 continue] highway=motorway oneway=yes [0x01 road_class=4 road_speed=7 level 6] But with both statements, the arrow is always drawn below the street. Is it somehow possible to have the arrow on top of the street? I use these statements: highway=tertiary[0x05 level 3 continue] highway=tertiary oneway=yes [0x18 level 3] Type 0x05 is the highway, type 0x18 are only the signs for oneway. They are drawn middle over the way. highway=tertiary[0x05 level 3 continue] highway=tertiary oneway=yes [0x18 level 3 continue] highway=tertiary (cycleway=track | cycleway=lane | cycleway:left=* | cycleway:right=*)[0x2e level 3] The third line drawes left and right the way blue rectangles additional to the oneway signs. Josef -- PGP Schlüssel: 311D1055 http://keyserver.pgp.com ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [Talk-de] continue statement and order of drawn ways?
Am 04.05.2011 00:08, schrieb Felix Hartmann: On 04.05.2011 00:05, Henning Scholland wrote: Am 03.05.2011 23:37, schrieb Felix Hartmann: On 03.05.2011 23:27, Minko wrote: Yes, that is also a good alternative, 0x01 as a transparent line and on top either 0x10f01 or 0x10f02 you cannot make a line transparent by omitting it from the typfile, but go ahead and do your tries. Yes, but you can use a transparent png-file ;) Henning And then you have streetnames shown, but no street If you remove the streetnames on 0x01, you remove streetnames on the broken Oregon, edge 800, gpsmaps 62 series, for all maps (until hard reset) The streetnames should be at 0x01, because this is rendered on top. 0x10f01 or 2 were rendered below and will be visible because of 0x01 is transparent. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [Talk-de] continue statement and order of drawn ways?
On 04.05.2011 00:41, Henning Scholland wrote: Am 04.05.2011 00:08, schrieb Felix Hartmann: On 04.05.2011 00:05, Henning Scholland wrote: Am 03.05.2011 23:37, schrieb Felix Hartmann: On 03.05.2011 23:27, Minko wrote: Yes, that is also a good alternative, 0x01 as a transparent line and on top either 0x10f01 or 0x10f02 you cannot make a line transparent by omitting it from the typfile, but go ahead and do your tries. Yes, but you can use a transparent png-file ;) Henning And then you have streetnames shown, but no street If you remove the streetnames on 0x01, you remove streetnames on the broken Oregon, edge 800, gpsmaps 62 series, for all maps (until hard reset) The streetnames should be at 0x01, because this is rendered on top. 0x10f01 or 2 were rendered below and will be visible because of 0x01 is transparent. Henning What is rendered on top and what not depends on GPS Firmware. For old GPS it is opposite to Mapsource 6.16 if you use a .TYPfile. If you omit entries from typfile, it changes order. There are quite a lot of variables, and in general stuff on top of each other is stupid. Better use transparency wisely, it's much more powerful than layers or top/down drawings, and it works consitstent on all GPS except Zumo (all that is all that are able to use .TYP-files). ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address search map information needed
On 5/3/2011 6:41 PM, mkgmap-dev-requ...@lists.mkgmap.org.uk wrote: Any place tagged as city/town/village should be in the cities list. Not sure what that means. I searched for my street and it showed a near by area with a different name than the city the street is located at. Is there anything written on how the relationship of streets to city/state/country works for mkgmap purposes? You need to send the map to the device from MapSource. The gmapsupp.img generated by mkgmap doesn't (yet) include the address index. Ok, I will have to try that again then. I tried to install the gmapsupp.img file and didn't use MapSource to do it. Good to know so that next time I try, I will use MapSource. Francisco ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Splitter output files are nearly empty
On Tue, May 03, 2011 at 11:12:25PM +0200, Lambertus wrote: Well I wanted to run multiple processes at the same time to utilize the quadcore CPU better and reduce processing time The processing time probably won't be reduced if the machine starts swapping. Like Thorsten pointed out, it is good to leave some breathing room for the computer. I am not sure if the --cache option still works. It was sort of superceded or made unnecessary by the Protobuf input format support. Oh, if it's not working anymore then I assume it will ignore the option. Or is this too simple thinking? I do not know. I never used the --cache option myself. One more possibility (a wild guess) is that the format of the cache directory changed and you had some old-format stuff there that was being misinterpreted. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
