Re: [mkgmap-dev] [Talk-de] continue statement and order of drawn ways?
Maybe the word 'transparent' is a bit confusing. With transparent I don't mean to omit line type 0x01 from the typ files at all. Like Henning said, you have to use a bitmap pattern without colours (=transparent) in the TYP file. On top of this, you use another bitmap with an arrow in the middle, for highways with oneway. This has to be a non routable line to avoid problems. For highways without oneway, you use another line type with a solid colour. This isn't stupid, it works, only if you know what you are doing. ___ 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
On May 2, 2011, at 21:46, WanMil wrote: So r1935 has fixed the bug. The compiled boundaries need not be downloaded again. Additionally I committed the changes in the trunk up to r1932. So far my tests with r1935 have been quite good. I do have one issue though: when I send the maps to a GPS device (Nüvi or eTrex), if there are several towns with the same same, the GPS device will only list one. Example: Walldorf in Germany. There is a Walldorf in Gross-Gerau, Rhein-Neckar-Kreis, and Schmalkalden-Meiningen. The GPS allows only Walldorf, Schmalkalden-Meiningen to be selected. The streets of the other Walldorf seem to be listed under this Walldorf, but the GPS cannot display them on the map. - The addresses are found correctly using Basecamp for Mac OS. - I send the maps to my devices using Garmin's MapInstall for Mac OS. Can anyone reproduce this? Cheers. ___ 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?
Minko (ligfiet...@online.nl) wrote: Maybe the word 'transparent' is a bit confusing. With transparent I don't mean to omit line type 0x01 from the typ files at all. Like Henning said, you have to use a bitmap pattern without colours (=transparent) in the TYP file. On top of this, you use another bitmap with an arrow in the middle, for highways with oneway. This has to be a non routable line to avoid problems. For highways without oneway, you use another line type with a solid colour. This isn't stupid, it works, only if you know what you are doing. The only thing to watch out for is what your GPS uses when it pops up a routing instruction. On mine, it shows the routeable lines. When I set routeable lines as transparent in the TYP file, then the GPS ignores the transparency and used a 1px grey line instead, which was a bit confusing. It would be even worse if it just displayed the roads transparently as the routing instruction would just show a routing arrow, and no roads. In the end, I set the routeable way as a thinner version of the display road, using the same colouring. This way, when browsing the map you see the display road (because it's wider), but when the routing instruction pops up you see road styles that correspond to the overall map style, rather than thin grey lines. -- Charlie ___ 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
Hi, I notice there is an extra - after /bin/osmosis --rx is that an error? Markus_g -Original Message- From: mkgmap-dev-boun...@lists.mkgmap.org.uk [mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk] On Behalf Of Lambertus Sent: Wednesday, 4 May 2011 1:19 AM To: Development list for mkgmap Subject: [mkgmap-dev] Splitter output files are nearly empty 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). In de commandline output I notice two things for which I seek input: - What does * Full GC * mean? - Is input from stdin still functional/supported for splitter? 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='-' | 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 Commandline output (where [...] are multiple similar lines removed for readability): cache=cache description= geonames-file=/home/lambertus/garmin/utils/cities15000.zip legacy-mode=false mapid=63240001 max-areas=255 max-nodes=140 max-threads=4 (auto) mixed=false no-trim=true output-dir= overlap=2000 resolution=13 split-file= status-freq=120 write-kml=world.kml Elapsed time: 0s Memory: Current 119MB (2MB used, 117MB free) Max MB Time started: Mon May 02 23:00:41 CEST 2011 Map is being split for resolution 13: - area boundaries are aligned to 0x800 map units - areas are multiples of 0x1000 map units wide and high Processing /dev/stdin May 2, 2011 11:00:42 PM org.openstreetmap.osmosis.core.Osmosis run INFO: Osmosis Version 0.39 May 2, 2011 11:00:43 PM org.openstreetmap.osmosis.core.Osmosis run INFO: Preparing pipeline. May 2, 2011 11:00:43 PM org.openstreetmap.osmosis.core.Osmosis run INFO: Launching pipeline execution. May 2, 2011 11:00:43 PM org.openstreetmap.osmosis.core.Osmosis run INFO: Pipeline executing, waiting for completion. Elapsed time: 2m 0s Memory: Current 119MB (4MB used, 115MB free) Max MB A bounds/ tag was found. Area covered is (-90.0,-180.0) to (90.0,180.0) 2,500,000 nodes processed... [...] 117,500,000 nodes processed... * Full GC * Elapsed time: 18m 0s Memory: Current 135MB (106MB used, 29MB free) Max MB [...] 267,500,000 nodes processed... * Full GC * Elapsed time: 38m 0s Memory: Current 152MB (121MB used, 31MB free) Max MB [...] 412,500,000 nodes processed... * Full GC * Elapsed time: 58m 0s Memory: Current 154MB (122MB used, 32MB free) Max MB [...] 567,500,000 nodes processed... * Full GC * Elapsed time: 1h 18m 0s Memory: Current 152MB (122MB used, 30MB free) Max MB [...] 717,500,000 nodes processed... * Full GC * Elapsed time: 1h 38m 0s Memory: Current 156MB (122MB used, 34MB free) Max MB [...] 875,000,000 nodes processed... * Full GC * Elapsed time: 1h 58m 0s Memory: Current 151MB (121MB used, 30MB free) Max MB [...] 1,060,000,000 nodes processed... Elapsed time: 2h 22m 0s Memory: Current 152MB (128MB used, 24MB free) Max MB 1,062,500,000 nodes processed... in 1 file Time: Tue May 03 01:22:59 CEST 2011 Exact map coverage is (-90.0,-180.0) to (90.0,180.0) Trimmed and rounded map coverage is (-84.990234375,-180.0) to (85.078125,180.0) Splitting nodes into areas containing a maximum of 1,400,000 nodes each... Area (-84.990234375,-180.0) to (16.083984375,-89.47265625) contains 748,264 nodes. DONE! [...] Area (50.009765625,132.1875) to (85.078125,180.0) contains 858,788 nodes. DONE! 1158 areas: Area 63240001 covers (0x201000,0xffbed000) to (0x20d000,0xffbff000) [...] Area 63241158 covers (0xffc39000,0xff80) to (0xb7000,0xffc06000) GT-Guatemala City Writing KML file to ./world.kml Writing out split osm files Tue May 03 01:23:04 CEST 2011 Processing 1158 areas in 5 passes, 232 areas at a time Starting pass 1 of 5, processing 232 areas (63240001 to 63240232) Making SparseMultiMap Making SparseMultiMap Processing /dev/stdin org.xmlpull.v1.XmlPullParserException: only whitespace content allowed before start tag and not a (position: START_DOCUMENT seen a... @1:1) at org.xmlpull.mxp1.MXParser.parseProlog(MXParser.java:1519) at org.xmlpull.mxp1.MXParser.nextImpl(MXParser.java:1395) at org.xmlpull.mxp1.MXParser.next(MXParser.java:1093) at uk.me.parabola.splitter.AbstractXppParser.parse(AbstractXppParser.java:62) at uk.me.parabola.splitter.Main.processMap(Main.java:399) at
Re: [mkgmap-dev] Splitter output files are nearly empty
On Wed, May 04, 2011 at 06:20:41PM +0930, Markus_g wrote: I notice there is an extra - after /bin/osmosis --rx is that an error? No, it tells osmosis to read from the standard input, which is being piped from bunzip2 -c. Marko ___ 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
Ok. Thanks Markus_g -Original Message- From: mkgmap-dev-boun...@lists.mkgmap.org.uk [mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk] On Behalf Of Marko Mäkelä Sent: Wednesday, 4 May 2011 6:28 PM To: Development list for mkgmap Subject: Re: [mkgmap-dev] Splitter output files are nearly empty On Wed, May 04, 2011 at 06:20:41PM +0930, Markus_g wrote: I notice there is an extra - after /bin/osmosis --rx is that an error? No, it tells osmosis to read from the standard input, which is being piped from bunzip2 -c. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Splitter output files are nearly empty
Hello * Full GC * Elapsed time: 18m 0s Memory: Current 135MB (106MB used, 29MB free) Max MB The 'Full GC' line is not a problem, it is a message printed by splitter every so often before it attempts to force a garbage collect. This is not usually a useful thing to do, but it can help make the printed memory usages more accurate, I suppose. Splitter can still read .osm.gz from stdin as long as there is a --split-file option, and as long as it doesn't have to use more than one pass through the data. You should just provide no file name on the command line though. (ie do not give /dev/stdin) However /dev/stdin should work as long as the input is uncompressed. Previously there was a --cache option which would copy and convert the input to a cache file, which would then be re-read if --split-file was not given or if more than one pass was needed. Since the newer pbf format is as or more efficient than the cache file format and osmosis is capable of producing it directly it seems best to just use osmosis to write it. Having splitter convert to pbf will not save any disk space and will probably be slower than overall than osmosis producing it directly. Best wishes ..Steve ___ 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
I have found a similar issue with the village of Achterveld, which boundaries lies in two Provinces: http://www.openstreetmap.org/browse/relation/302103 http://www.openstreetmap.org/browse/relation/310003 Only Achterveld in the province of Gelderland is listed on the device. Streets in Achterveld, Gelderland can be found and located, the other streets (in the center of the village for example, province Utrecht) are only listed but no loaction can be found on the GPS. In Mapsource everything works fine. Maybe a good test case to debug? -- Clinton wrote: On May 2, 2011, at 21:46, WanMil wrote: So r1935 has fixed the bug. The compiled boundaries need not be downloaded again. Additionally I committed the changes in the trunk up to r1932. So far my tests with r1935 have been quite good. I do have one issue though: when I send the maps to a GPS device (Nüvi or eTrex), if there are several towns with the same same, the GPS device will only list one. Example: Walldorf in Germany. There is a Walldorf in Gross-Gerau, Rhein-Neckar-Kreis, and Schmalkalden-Meiningen. The GPS allows only Walldorf, Schmalkalden-Meiningen to be selected. The streets of the other Walldorf seem to be listed under this Walldorf, but the GPS cannot display them on the map. - The addresses are found correctly using Basecamp for Mac OS. - I send the maps to my devices using Garmin's MapInstall for Mac OS. Can anyone reproduce this? Cheers. ___ 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 2011-05-04 07:44, Marko Mäkelä wrote: 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. Sure, but the machine has 8GB ram so it won't have to swap while doing multiple things at the same time and swapping did not take place (according to Munin). I'll run the script again with 5 or 6 GB heap, but I'm not convinced it will change the output or processing time significantly. 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. The script does a full cleanup before starting the processing. There is no cache directory lingering around. But I try to remember if I saw a cache directory while processing and I don't think I did, so maybe the option is already ignored. Anyway, I've generated a pbf planet file from the bz2 XML last night, so can test if splitting pbf will be successful this evening. ___ 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 2011-05-04 11:51, Steve Ratcliffe wrote: * Full GC * Elapsed time: 18m 0s Memory: Current 135MB (106MB used, 29MB free) Max MB The 'Full GC' line is not a problem, it is a message printed by splitter every so often before it attempts to force a garbage collect. This is not usually a useful thing to do, but it can help make the printed memory usages more accurate, I suppose. Thanks for clearing that up Steve. The newer splitter apparently needs only a fraction of the memory it needed before. Great work devs! Splitter can still read .osm.gz from stdin as long as there is a --split-file option, and as long as it doesn't have to use more than one pass through the data. Alright. I don't think splitter is able to only use one pass on a planet file so it's another reason to move to the pbf format. You should just provide no file name on the command line though. (ie do not give /dev/stdin) However /dev/stdin should work as long as the input is uncompressed. Thanks, the /dev/stdin ended up there because of other problems I had and it worked. I can't confirm or deny that it works without it ;-) Previously there was a --cache option which would copy and convert the input to a cache file, which would then be re-read if --split-file was not given or if more than one pass was needed. Since the newer pbf format is as or more efficient than the cache file format and osmosis is capable of producing it directly it seems best to just use osmosis to write it. Having splitter convert to pbf will not save any disk space and will probably be slower than overall than osmosis producing it directly. Again: thanks. It's clear I'll better migrate to pbf. ___ 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
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
OK the attached patch should now take into account the exact size of the
file when setting the 'partition size' in the header.
There is a minimum size of 2048 512 byte sectors, anything larger than
that is calculated just a little larger, so any mistake will cause a
problem. Works for me so far.
..Steve
Index: src/uk/me/parabola/imgfmt/sys/BlockManager.java
===
--- src/uk/me/parabola/imgfmt/sys/BlockManager.java (revision 1634)
+++ src/uk/me/parabola/imgfmt/sys/BlockManager.java (revision )
@@ -31,7 +31,7 @@
private int currentBlock;
private int maxBlock = 0xfffe;
- private int numberAllocated;
+ private int maxBlockAllocated;
BlockManager(int blockSize, int initialBlock) {
this.blockSize = blockSize;
@@ -57,7 +57,7 @@
blockSize * 2, blockSize * 4);
throw new MapFailedException(message);
}
- numberAllocated++;
+ maxBlockAllocated++;
return n;
}
@@ -74,8 +74,13 @@
}
public void setCurrentBlock(int n) {
- if (numberAllocated != 0)
+ if (maxBlockAllocated != 0)
throw new IllegalStateException(Blocks already allocated);
currentBlock = n;
+ maxBlockAllocated = n;
}
+
+ public int getMaxBlockAllocated() {
+ return maxBlockAllocated;
-}
+ }
+}
Index: src/uk/me/parabola/imgfmt/sys/ImgFS.java
===
--- src/uk/me/parabola/imgfmt/sys/ImgFS.java (revision 1932)
+++ src/uk/me/parabola/imgfmt/sys/ImgFS.java (revision )
@@ -239,7 +239,12 @@
public void close() {
try {
+ if (!readOnly) {
+int allocatedBlocks = fileBlockManager.getMaxBlockAllocated();
+System.out.println(max block + allocatedBlocks);
+header.setNumBlocks(allocatedBlocks);
- sync();
+sync();
+ }
} catch (IOException e) {
log.debug(could not sync filesystem);
} finally {
Index: src/uk/me/parabola/imgfmt/sys/ImgHeader.java
===
--- src/uk/me/parabola/imgfmt/sys/ImgHeader.java (revision 1932)
+++ src/uk/me/parabola/imgfmt/sys/ImgHeader.java (revision )
@@ -19,6 +19,7 @@
import java.io.IOException;
import java.nio.ByteBuffer;
import java.nio.ByteOrder;
+import java.util.Arrays;
import java.util.Calendar;
import java.util.Date;
@@ -104,6 +105,8 @@
private static final byte[] SIGNATURE = {
'D', 'S', 'K', 'I', 'M', 'G', '\0'};
+ private int numBlocks;
+
ImgHeader(ImgChannel chan) {
this.file = chan;
header.order(ByteOrder.LITTLE_ENDIAN);
@@ -115,6 +118,7 @@
*/
void createHeader(FileSystemParam params) {
this.fsParams = params;
+ System.out.println(file size + file.position());
header.put(OFF_XOR, (byte) 0);
@@ -148,17 +152,10 @@
// always assume it is 2 anyway.
header.put(OFF_DIRECTORY_START_BLOCK, (byte) fsParams.getDirectoryStartEntry());
- // This sectors, head, cylinders stuff appears to be used by mapsource
- // and they have to be larger than the actual size of the map. It
- // doesn't appear to have any effect on a garmin device or other software.
- int sectors = 0x20; // 0x3f is the max
- header.putShort(OFF_SECTORS, (short) sectors);
- int heads = 0x80;
- header.putShort(OFF_HEADS, (short) heads);
+ //writeSizeValues(bs);
+
int unknown = 0x400; // not known, doesn't appear to be related to fs size
header.putShort(OFF_UNK_2, (short) unknown);
- header.putShort(OFF_HEADS2, (short) heads);
- header.putShort(OFF_SECTORS2, (short) sectors);
header.position(OFF_CREATION_YEAR);
Utils.setCreationTime(header, creationTime);
@@ -166,44 +163,83 @@
// The last LBA number in the partition. We always claim a large partition without
// regard to what is actually stored. Total number of sectors is this plus one
// as sector numbers start at zero.
- int endBlock = 0x3f;
+ //int endBlock = numBlocks;
+
+ setDirectoryStartEntry(params.getDirectoryStartEntry());
+
+ // Set the times.
+ Date date = new Date();
+ setCreationTime(date);
+ setUpdateTime(date);
+ setDescription(params.getMapDescription());
+
+ // Checksum is not checked.
+ int check = 0;
+ header.put(OFF_CHECKSUM, (byte) check);
+
Re: [mkgmap-dev] Address search map information needed
El 04/05/11 01:43, Francisco Moraes escribió: 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? The way mkgmap (trunk) assigns streets to places takes into account information from nearest place, is_in, is_in:* and addr:* tags and also depends on the --location-autofill parameter value, but it is known to work not optimally. Currently a new way to assign addresses is being developded in locator branch, which is getting promising results, so I think in short you'll have your street in your city;-) 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] Error on MapSource with r1919
El 04/05/11 15:18, Steve Ratcliffe escribió: Hi 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 OK the attached patch should now take into account the exact size of the file when setting the 'partition size' in the header. There is a minimum size of 2048 512 byte sectors, anything larger than that is calculated just a little larger, so any mistake will cause a problem. Works for me so far. Using your patch I get the messages below and the map can't still be loaded in MapSource file size 0 file size 0 max block 42204 endSector=42204, from 42204 try 65472, for mb=42204 max block 50217 endSector=50217, from 50217 try 65472, for mb=50217 file size 0 max block 12004 endSector=12004, from 12004 try 65472, for mb=12004 file size 0 max block 21899 endSector=21899, from 21899 try 65472, for mb=21899 file size 0 max block 21345 endSector=21345, from 21345 try 65472, for mb=21345 file size 0 max block 38482 endSector=38482, from 38482 try 65472, for mb=38482 file size 0 max block 15235 endSector=15235, from 15235 try 65472, for mb=15235 file size 0 max block 20773 endSector=20773, from 20773 try 65472, for mb=20773 file size 0 max block 22445 endSector=22445, from 22445 try 65472, for mb=22445 file size 0 max block 17141 endSector=17141, from 17141 try 65472, for mb=17141 file size 0 max block 20432 endSector=20432, from 20432 try 65472, for mb=20432 file size 0 max block 28355 endSector=28355, from 28355 try 65472, for mb=28355 file size 0 file size 0 max block 11 endSector=2047, from 11 try 65472, for mb=2047 file size 0 max block 38682 endSector=309463, from 38682 try 65472, for mb=309463 try 130944, for mb=309463 try 261888, for mb=309463 try 523776, for mb=309463 max block 4871 endSector=38975, from 4871 try 65472, for mb=38975 ___ 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?
MarkS schrieb am 03.05.2011 22:58: 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. The problem is, that the oneway overlay is not only to motorways. So you would need two line styles for motorways, two linestyles for primaries, ... And if you want to add overlays for access restrictions, speed limits or what ever, th enumber of line styles required is growing exponentially. 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
Another issue: The locator r1935 can't find the national boundaries of Luxemburg: http://www.openstreetmap.org/browse/relation/28711 They belong to bounds_230_25.bnd but if I run the gpx converter they are not in it. And maybe add België as variant to the locator LocatorConfig.xml, as well as België - Belgique - Belgien ___ 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
Another issue: The locator r1935 can't find the national boundaries of Luxemburg: http://www.openstreetmap.org/browse/relation/28711 They belong to bounds_230_25.bnd but if I run the gpx converter they are not in it. And maybe add België as variant to the locator LocatorConfig.xml, as well as België - Belgique - Belgien To detect such holes automatically it would be very useful to have a tool which reads the bounds file (this is already implemented) and calculates the uncovered areas for each admin level (this has to be done but is not very difficult to implement). Anybody out there who is willing to do this? I have a lot of other things to do and this would help to speed up the development. 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
Another issue: The locator r1935 can't find the national boundaries of Luxemburg: http://www.openstreetmap.org/browse/relation/28711 The multipolygon of the border is incorrect. Way http://www.openstreetmap.org/browse/way/10674 is overlapping with http://www.openstreetmap.org/browse/way/10675 and therefore the polygon is not closed (in the way the multipolygon and all mkgmap algorithms check if a way is closed). You need to correct it and two days later I can recompile the boundary tiles. WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [locator] Country specific rules
I want to start to collect and commit your country specific rules. I know some of you have already posted them on the list but I have lost track of it. So please post your country specific rules as an answer in this thread. 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
I'm sorry, i'm not familiar with those complex border relations, maybe someone out there can fix it? -- WanMil wrote: Another issue: The locator r1935 can't find the national boundaries of Luxemburg: http://www.openstreetmap.org/browse/relation/28711 The multipolygon of the border is incorrect. Way http://www.openstreetmap.org/browse/way/10674 is overlapping with http://www.openstreetmap.org/browse/way/10675 and therefore the polygon is not closed (in the way the multipolygon and all mkgmap algorithms check if a way is closed). You need to correct it and two days later I can recompile the boundary tiles. 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
Am 04.05.2011 18:40, schrieb WanMil: Another issue: The locator r1935 can't find the national boundaries of Luxemburg: http://www.openstreetmap.org/browse/relation/28711 The multipolygon of the border is incorrect. Way http://www.openstreetmap.org/browse/way/10674 is overlapping with http://www.openstreetmap.org/browse/way/10675 and therefore the polygon is not closed (in the way the multipolygon and all mkgmap algorithms check if a way is closed). and with http://www.openstreetmap.org/browse/way/10676 For me 10675 and the other two can be deleted. Josef You need to correct it and two days later I can recompile the boundary tiles. -- 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] [locator] Country specific rules
Netherlands:
mkgmap:region!=* mkgmap:admin_level4=* { set
mkgmap:region='${mkgmap:admin_level4}' }
mkgmap:city!=* mkgmap:admin_level10=* { set
mkgmap:city='${mkgmap:admin_level10}' }
mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
For Belgium I'm not sure, seems a big mess there ;-)
Provinces are found in level 5 or 6, level 4 is for Flandres and Wallonie
But in level 5 you have something like the 'Flemish Community' too:
http://www.openstreetmap.org/browse/relation/53136
There is also the Flemish region (level 4), don't have any clue what the
difference is between those two:
http://www.openstreetmap.org/browse/relation/53134
Cities:
mkgmap:city!=* mkgmap:admin_level9=* { set
mkgmap:city='${mkgmap:admin_level9}' }
mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
___
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
Am 04.05.2011 19:38, schrieb Minko:
Netherlands:
mkgmap:region!=* mkgmap:admin_level4=* { set
mkgmap:region='${mkgmap:admin_level4}' }
mkgmap:city!=* mkgmap:admin_level10=* { set
mkgmap:city='${mkgmap:admin_level10}' }
mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
Thanks! They are committed in r1936
WanMil
___
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 04/05/2011 16:11, Torsten Leistikow wrote: MarkS schrieb am 03.05.2011 22:58: 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. The problem is, that the oneway overlay is not only to motorways. So you would need two line styles for motorways, two linestyles for primaries, ... And if you want to add overlays for access restrictions, speed limits or what ever, th enumber of line styles required is growing exponentially. Gruss Torsten I have seen a map which goes for another approach. That version used a single line/style for the motorway itself. They then added a second line/style for oneway roads. This second style looked a bit like an arrow but with a transparent bit down the middle so only the edges of the arrow head were visible. This reasulted in the arrow heads sitting outside the normal road and working whatever the the draw order. The drawback on this approach was that the road lines all needed to be a similar width, and it wasn't as pretty as arrows in the middle of the road. ___ 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
On Wed, May 04, 2011 at 07:02:41PM +0200, WanMil wrote: I want to start to collect and commit your country specific rules. I know some of you have already posted them on the list but I have lost track of it. So please post your country specific rules as an answer in this thread. http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative lists rules for many countries. Finland does not have that many boundaries defined, but the few should follow the rules in the wiki. 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
In Germany we have the same mess...
Actually I'm using this rules:
mkgmap:country!=* mkgmap:admin_level2=* { set
mkgmap:country='${mkgmap:admin_level2}' }
mkgmap:region!=* mkgmap:admin_level3=* { set
mkgmap:region='${mkgmap:admin_level3}' }
mkgmap:region!=* mkgmap:admin_level4=* { set
mkgmap:region='${mkgmap:admin_level4}' }
mkgmap:region!=* mkgmap:admin_level5=* { set
mkgmap:region='${mkgmap:admin_level5}' }
mkgmap:city!=* mkgmap:admin_level10=* { set
mkgmap:city='${mkgmap:admin_level10}' }
mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:city!=* mkgmap:admin_level7=* { set
mkgmap:city='${mkgmap:admin_level7}' }
mkgmap:city!=* mkgmap:admin_level6=* { set
mkgmap:city='${mkgmap:admin_level6}' }
I don't know if this makes sense, but referring to this page:
http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative
there are 2 options for the admin-boundaries:
10 and 11 admin levels :(
So actually I still playing with this setting, maybe somebody has better rules
for Germany.
Thanks and regards
Martin
Am 04.05.2011 um 19:38 schrieb Minko:
Netherlands:
mkgmap:region!=* mkgmap:admin_level4=* { set
mkgmap:region='${mkgmap:admin_level4}' }
mkgmap:city!=* mkgmap:admin_level10=* { set
mkgmap:city='${mkgmap:admin_level10}' }
mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
For Belgium I'm not sure, seems a big mess there ;-)
Provinces are found in level 5 or 6, level 4 is for Flandres and Wallonie
But in level 5 you have something like the 'Flemish Community' too:
http://www.openstreetmap.org/browse/relation/53136
There is also the Flemish region (level 4), don't have any clue what the
difference is between those two:
http://www.openstreetmap.org/browse/relation/53134
Cities:
mkgmap:city!=* mkgmap:admin_level9=* { set
mkgmap:city='${mkgmap:admin_level9}' }
mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
___
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
Possibly not what you have in mind, but how about an automatic drive-on-left for UK/Ireland/Japan/Australia/NZ/etc? On 04/05/2011 19:02, WanMil wrote: I want to start to collect and commit your country specific rules. I know some of you have already posted them on the list but I have lost track of it. So please post your country specific rules as an answer in this thread. WanMil ___ 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
This will not be fixed in the locator branch. But maybe someone else implement such rules in the style processor. WanMil Possibly not what you have in mind, but how about an automatic drive-on-left for UK/Ireland/Japan/Australia/NZ/etc? On 04/05/2011 19:02, WanMil wrote: I want to start to collect and commit your country specific rules. I know some of you have already posted them on the list but I have lost track of it. So please post your country specific rules as an answer in this thread. 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
El 04/05/11 16:57, Carlos Dávila escribió: El 04/05/11 15:18, Steve Ratcliffe escribió: Hi 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 OK the attached patch should now take into account the exact size of the file when setting the 'partition size' in the header. There is a minimum size of 2048 512 byte sectors, anything larger than that is calculated just a little larger, so any mistake will cause a problem. Works for me so far. Using your patch I get the messages below and the map can't still be loaded in MapSource file size 0 file size 0 max block 42204 endSector=42204, from 42204 try 65472, for mb=42204 max block 50217 endSector=50217, from 50217 try 65472, for mb=50217 file size 0 max block 12004 endSector=12004, from 12004 try 65472, for mb=12004 file size 0 max block 21899 endSector=21899, from 21899 try 65472, for mb=21899 file size 0 max block 21345 endSector=21345, from 21345 try 65472, for mb=21345 file size 0 max block 38482 endSector=38482, from 38482 try 65472, for mb=38482 file size 0 max block 15235 endSector=15235, from 15235 try 65472, for mb=15235 file size 0 max block 20773 endSector=20773, from 20773 try 65472, for mb=20773 file size 0 max block 22445 endSector=22445, from 22445 try 65472, for mb=22445 file size 0 max block 17141 endSector=17141, from 17141 try 65472, for mb=17141 file size 0 max block 20432 endSector=20432, from 20432 try 65472, for mb=20432 file size 0 max block 28355 endSector=28355, from 28355 try 65472, for mb=28355 file size 0 file size 0 max block 11 endSector=2047, from 11 try 65472, for mb=2047 file size 0 max block 38682 endSector=309463, from 38682 try 65472, for mb=309463 try 130944, for mb=309463 try 261888, for mb=309463 try 523776, for mb=309463 max block 4871 endSector=38975, from 4871 try 65472, for mb=38975 I realized MapSource error is different with the patched version, but don't know if this info is useful App: MapSource OS: Windows XP Service Pack 2 (actually debian+wine) Processor: x86, Processor Level: 16, Processors:2, Model: 6 Stepping: 2, RAM: 2097151 DSK_PRIVPARTITION.CPP-314-6.13.7.0 Language ID: 1034 Part Number: 006-A0041-00 Build Type: Release Extra: Opening map at (lat,lon): 40.0342, -2.41699 Resolution: 16 Stack Trace: 2072270818 9448702 8340466 ___ 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
Am 04.05.2011 20:32, schrieb Martin:
In Germany we have the same mess...
Actually I'm using this rules:
mkgmap:country!=* mkgmap:admin_level2=* { set
mkgmap:country='${mkgmap:admin_level2}' }
mkgmap:region!=* mkgmap:admin_level3=* { set
mkgmap:region='${mkgmap:admin_level3}' }
mkgmap:region!=* mkgmap:admin_level4=* { set
mkgmap:region='${mkgmap:admin_level4}' }
mkgmap:region!=* mkgmap:admin_level5=* { set
mkgmap:region='${mkgmap:admin_level5}' }
mkgmap:city!=* mkgmap:admin_level10=* { set
mkgmap:city='${mkgmap:admin_level10}' }
mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:city!=* mkgmap:admin_level7=* { set
mkgmap:city='${mkgmap:admin_level7}' }
mkgmap:city!=* mkgmap:admin_level6=* { set
mkgmap:city='${mkgmap:admin_level6}' }
I don't know if this makes sense, but referring to this page:
http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative
http://wiki.openstreetmap.org/wiki/Tag:boundary=administrative
there are 2 options for the admin-boundaries:
10 and 11 admin levels :(
So actually I still playing with this setting, maybe somebody has
better rules for Germany.
I would use:
mkgmap:country!=* mkgmap:admin_level2=* { set
mkgmap:country='${mkgmap:admin_level2}' }
mkgmap:region!=* mkgmap:admin_level4=* { set
mkgmap:region='${mkgmap:admin_level4}' }
mkgmap:country=DEU mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:country=DEU mkgmap:city!=* mkgmap:admin_level6=* { set
mkgmap:city='${mkgmap:admin_level6}' }
Henning
___
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
Am 04.05.2011 19:02, schrieb WanMil:
I want to start to collect and commit your country specific rules. I
know some of you have already posted them on the list but I have lost
track of it.
So please post your country specific rules as an answer in this thread.
WanMil
I took these out of wiki-definition of admin_level:
#address-search
mkgmap:country!=* mkgmap:admin_level2=* { set
mkgmap:country='${mkgmap:admin_level2}' }
mkgmap:region!=* mkgmap:admin_level4=* { set
mkgmap:region='${mkgmap:admin_level4}' }
mkgmap:country=AUT mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:country=BEL mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:country=CZE mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:country=CZE mkgmap:city!=* mkgmap:admin_level7=* { set
mkgmap:city='${mkgmap:admin_level7}' }
mkgmap:country=DNK mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:country=DNK mkgmap:city!=* mkgmap:admin_level7=* { set
mkgmap:city='${mkgmap:admin_level7}' }
mkgmap:country=FIN mkgmap:city!=* mkgmap:admin_level9=* { set
mkgmap:city='${mkgmap:admin_level9}' }
mkgmap:country=FIN mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:country=FRA mkgmap:city!=* mkgmap:admin_level9=* { set
mkgmap:city='${mkgmap:admin_level9}' }
mkgmap:country=FRA mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:country=DEU mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:country=DEU mkgmap:city!=* mkgmap:admin_level6=* { set
mkgmap:city='${mkgmap:admin_level6}' }
mkgmap:country=ISL mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:country=ITA mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:country=LUX mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:country=NLD mkgmap:city!=* mkgmap:admin_level10=* { set
mkgmap:city='${mkgmap:admin_level10}' }
mkgmap:country=NOR mkgmap:city!=* mkgmap:admin_level9=* { set
mkgmap:city='${mkgmap:admin_level9}' }
mkgmap:country=POL mkgmap:city!=* mkgmap:admin_level10=* { set
mkgmap:city='${mkgmap:admin_level10}' }
mkgmap:country=POL mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:country=PRT mkgmap:city!=* mkgmap:admin_level9=* { set
mkgmap:city='${mkgmap:admin_level9}' }
mkgmap:country=PRT mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:country=SVN mkgmap:city!=* mkgmap:admin_level10=* { set
mkgmap:city='${mkgmap:admin_level10}' }
mkgmap:country=ESP mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:country=SWE mkgmap:city!=* mkgmap:admin_level9=* { set
mkgmap:city='${mkgmap:admin_level9}' }
mkgmap:country=SWE mkgmap:city!=* mkgmap:admin_level7=* { set
mkgmap:city='${mkgmap:admin_level7}' }
mkgmap:country=CHE mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
___
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
I think only the city rules need to be tweaked in Germany:
# Germany = DEU cities
mkgmap:country=DEU mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:country=DEU mkgmap:city!=* mkgmap:admin_level7=* { set
mkgmap:city='${mkgmap:admin_level7}' }
mkgmap:country=DEU mkgmap:city!=* mkgmap:admin_level6=* { set
mkgmap:city='${mkgmap:admin_level6}' }
mkgmap:country=DEU mkgmap:city!=* mkgmap:admin_level9=* { set
mkgmap:city='${mkgmap:admin_level9}' }
mkgmap:country=DEU mkgmap:city!=* mkgmap:admin_level10=* { set
mkgmap:city='${mkgmap:admin_level10}' }
First use admin_level=8 for city names. This covers all cities with a
size up to 30. Bigger cities don't use admin_level=8 but
admin_level=9 and 10 (and 11) for suburbs. The appropriate name of the
bigger city should be contained then in the admin_level 7 or 6.
Please try it and give a feedback if that's ok. The upper rules are
committed in r1937.
Later on I will try your region settings.
WanMil
In Germany we have the same mess...
Actually I'm using this rules:
mkgmap:country!=* mkgmap:admin_level2=* { set
mkgmap:country='${mkgmap:admin_level2}' }
mkgmap:region!=* mkgmap:admin_level3=* { set
mkgmap:region='${mkgmap:admin_level3}' }
mkgmap:region!=* mkgmap:admin_level4=* { set
mkgmap:region='${mkgmap:admin_level4}' }
mkgmap:region!=* mkgmap:admin_level5=* { set
mkgmap:region='${mkgmap:admin_level5}' }
mkgmap:city!=* mkgmap:admin_level10=* { set
mkgmap:city='${mkgmap:admin_level10}' }
mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:city!=* mkgmap:admin_level7=* { set
mkgmap:city='${mkgmap:admin_level7}' }
mkgmap:city!=* mkgmap:admin_level6=* { set
mkgmap:city='${mkgmap:admin_level6}' }
I don't know if this makes sense, but referring to this page:
http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative
http://wiki.openstreetmap.org/wiki/Tag:boundary=administrative
there are 2 options for the admin-boundaries:
10 and 11 admin levels :(
So actually I still playing with this setting, maybe somebody has better
rules for Germany.
Thanks and regards
Martin
Am 04.05.2011 um 19:38 schrieb Minko:
Netherlands:
mkgmap:region!=* mkgmap:admin_level4=* { set
mkgmap:region='${mkgmap:admin_level4}' }
mkgmap:city!=* mkgmap:admin_level10=* { set
mkgmap:city='${mkgmap:admin_level10}' }
mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
For Belgium I'm not sure, seems a big mess there ;-)
Provinces are found in level 5 or 6, level 4 is for Flandres and Wallonie
But in level 5 you have something like the 'Flemish Community' too:
http://www.openstreetmap.org/browse/relation/53136
There is also the Flemish region (level 4), don't have any clue what
the difference is between those two:
http://www.openstreetmap.org/browse/relation/53134
Cities:
mkgmap:city!=* mkgmap:admin_level9=* { set
mkgmap:city='${mkgmap:admin_level9}' }
mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
___
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] Error on MapSource with r1919
DSK_PRIVPARTITION.CPP-314-6.13.7.0 This is the same error I had when the mdr-file exceded the former fixed limit of 256 MB. Maybe one file is larger than the adjusted C/H/S values now specify. Peter ___ 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
in addition to Minko: according to
http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Boundaries
Belgium provinces should all be in admin_level 6
For Luxembourg: the cities are all in admin_level 8, the provinces (I
think the Luxembourg name 'district' comes closest) are in admin_level 4
Cheers Johan
On Wed, 04 May 2011 21:03:00 +0200, WanMil wmgc...@web.de wrote:
I think only the city rules need to be tweaked in Germany:
# Germany = DEU cities
mkgmap:country=DEU mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:country=DEU mkgmap:city!=* mkgmap:admin_level7=* { set
mkgmap:city='${mkgmap:admin_level7}' }
mkgmap:country=DEU mkgmap:city!=* mkgmap:admin_level6=* { set
mkgmap:city='${mkgmap:admin_level6}' }
mkgmap:country=DEU mkgmap:city!=* mkgmap:admin_level9=* { set
mkgmap:city='${mkgmap:admin_level9}' }
mkgmap:country=DEU mkgmap:city!=* mkgmap:admin_level10=* { set
mkgmap:city='${mkgmap:admin_level10}' }
First use admin_level=8 for city names. This covers all cities with a
size up to 30. Bigger cities don't use admin_level=8 but
admin_level=9 and 10 (and 11) for suburbs. The appropriate name of
the
bigger city should be contained then in the admin_level 7 or 6.
Please try it and give a feedback if that's ok. The upper rules are
committed in r1937.
Later on I will try your region settings.
WanMil
In Germany we have the same mess...
Actually I'm using this rules:
mkgmap:country!=* mkgmap:admin_level2=* { set
mkgmap:country='${mkgmap:admin_level2}' }
mkgmap:region!=* mkgmap:admin_level3=* { set
mkgmap:region='${mkgmap:admin_level3}' }
mkgmap:region!=* mkgmap:admin_level4=* { set
mkgmap:region='${mkgmap:admin_level4}' }
mkgmap:region!=* mkgmap:admin_level5=* { set
mkgmap:region='${mkgmap:admin_level5}' }
mkgmap:city!=* mkgmap:admin_level10=* { set
mkgmap:city='${mkgmap:admin_level10}' }
mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:city!=* mkgmap:admin_level7=* { set
mkgmap:city='${mkgmap:admin_level7}' }
mkgmap:city!=* mkgmap:admin_level6=* { set
mkgmap:city='${mkgmap:admin_level6}' }
I don't know if this makes sense, but referring to this page:
http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative
http://wiki.openstreetmap.org/wiki/Tag:boundary=administrative
there are 2 options for the admin-boundaries:
10 and 11 admin levels :(
So actually I still playing with this setting, maybe somebody has
better
rules for Germany.
Thanks and regards
Martin
Am 04.05.2011 um 19:38 schrieb Minko:
Netherlands:
mkgmap:region!=* mkgmap:admin_level4=* { set
mkgmap:region='${mkgmap:admin_level4}' }
mkgmap:city!=* mkgmap:admin_level10=* { set
mkgmap:city='${mkgmap:admin_level10}' }
mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
For Belgium I'm not sure, seems a big mess there ;-)
Provinces are found in level 5 or 6, level 4 is for Flandres and
Wallonie
But in level 5 you have something like the 'Flemish Community' too:
http://www.openstreetmap.org/browse/relation/53136
There is also the Flemish region (level 4), don't have any clue
what
the difference is between those two:
http://www.openstreetmap.org/browse/relation/53134
Cities:
mkgmap:city!=* mkgmap:admin_level9=* { set
mkgmap:city='${mkgmap:admin_level9}' }
mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
___
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] Error on MapSource with r1919
El 04/05/11 21:42, Peter Lerner escribió: DSK_PRIVPARTITION.CPP-314-6.13.7.0 This is the same error I had when the mdr-file exceded the former fixed limit of 256 MB. Maybe one file is larger than the adjusted C/H/S values now specify. I don't think so. All my other maps, even the smallest ones are broken with the patched mkgmap. Did it fix the problem for you? ___ 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
The Luxembourg country border been fixed in JOSM (nice to have validator around!). However, still some validator errors for the France border relations. Hopefully some French mappers step in to update these borders. Cheers Johan On Wed, 04 May 2011 19:32:07 +0200, Josef Latt josef.l...@gmx.net wrote: Am 04.05.2011 19:19, schrieb Josef Latt: Am 04.05.2011 18:40, schrieb WanMil: Another issue: The locator r1935 can't find the national boundaries of Luxemburg: http://www.openstreetmap.org/browse/relation/28711 The multipolygon of the border is incorrect. Way http://www.openstreetmap.org/browse/way/10674 is overlapping with http://www.openstreetmap.org/browse/way/10675 and therefore the polygon is not closed (in the way the multipolygon and all mkgmap algorithms check if a way is closed). and with http://www.openstreetmap.org/browse/way/10676 For me 10675 and the other two can be deleted. And many relations must be checked. Not so easy. Josef You need to correct it and two days later I can recompile the boundary tiles. ___ 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
Hi Wanmil, some problems using the country specific cities, maybe the
locator config has to be slightly changed:
(1) Boundary name OSM (2) Locator name (3) Result
(1) Deutschland (2) Deutschland (3) positive, can be found in Garmin
(1) Nederland (2) Nederland(3) positive, can be found in Garmin
(1) Groussherzogtum Lëtzebuerg (2) Luxembourg (3) negative, can't be
found in Garmin
(1) België - Belgique - Belgien (2) Belgique (3) negative, can't be
found in Garmin
Cheers, Johan
On Wed, 04 May 2011 22:23:54 +0200, navmaps navm...@navmaps.eu wrote:
in addition to Minko: according to
http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Boundaries
Belgium provinces should all be in admin_level 6
For Luxembourg: the cities are all in admin_level 8, the provinces
(I
think the Luxembourg name 'district' comes closest) are in
admin_level 4
Cheers Johan
On Wed, 04 May 2011 21:03:00 +0200, WanMil wmgc...@web.de wrote:
I think only the city rules need to be tweaked in Germany:
# Germany = DEU cities
mkgmap:country=DEU mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:country=DEU mkgmap:city!=* mkgmap:admin_level7=* { set
mkgmap:city='${mkgmap:admin_level7}' }
mkgmap:country=DEU mkgmap:city!=* mkgmap:admin_level6=* { set
mkgmap:city='${mkgmap:admin_level6}' }
mkgmap:country=DEU mkgmap:city!=* mkgmap:admin_level9=* { set
mkgmap:city='${mkgmap:admin_level9}' }
mkgmap:country=DEU mkgmap:city!=* mkgmap:admin_level10=* { set
mkgmap:city='${mkgmap:admin_level10}' }
First use admin_level=8 for city names. This covers all cities with
a
size up to 30. Bigger cities don't use admin_level=8 but
admin_level=9 and 10 (and 11) for suburbs. The appropriate name of
the
bigger city should be contained then in the admin_level 7 or 6.
Please try it and give a feedback if that's ok. The upper rules are
committed in r1937.
Later on I will try your region settings.
WanMil
In Germany we have the same mess...
Actually I'm using this rules:
mkgmap:country!=* mkgmap:admin_level2=* { set
mkgmap:country='${mkgmap:admin_level2}' }
mkgmap:region!=* mkgmap:admin_level3=* { set
mkgmap:region='${mkgmap:admin_level3}' }
mkgmap:region!=* mkgmap:admin_level4=* { set
mkgmap:region='${mkgmap:admin_level4}' }
mkgmap:region!=* mkgmap:admin_level5=* { set
mkgmap:region='${mkgmap:admin_level5}' }
mkgmap:city!=* mkgmap:admin_level10=* { set
mkgmap:city='${mkgmap:admin_level10}' }
mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:city!=* mkgmap:admin_level7=* { set
mkgmap:city='${mkgmap:admin_level7}' }
mkgmap:city!=* mkgmap:admin_level6=* { set
mkgmap:city='${mkgmap:admin_level6}' }
I don't know if this makes sense, but referring to this page:
http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative
http://wiki.openstreetmap.org/wiki/Tag:boundary=administrative
there are 2 options for the admin-boundaries:
10 and 11 admin levels :(
So actually I still playing with this setting, maybe somebody has
better
rules for Germany.
Thanks and regards
Martin
Am 04.05.2011 um 19:38 schrieb Minko:
Netherlands:
mkgmap:region!=* mkgmap:admin_level4=* { set
mkgmap:region='${mkgmap:admin_level4}' }
mkgmap:city!=* mkgmap:admin_level10=* { set
mkgmap:city='${mkgmap:admin_level10}' }
mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
For Belgium I'm not sure, seems a big mess there ;-)
Provinces are found in level 5 or 6, level 4 is for Flandres and
Wallonie
But in level 5 you have something like the 'Flemish Community'
too:
http://www.openstreetmap.org/browse/relation/53136
There is also the Flemish region (level 4), don't have any clue
what
the difference is between those two:
http://www.openstreetmap.org/browse/relation/53134
Cities:
mkgmap:city!=* mkgmap:admin_level9=* { set
mkgmap:city='${mkgmap:admin_level9}' }
mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
___
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
___
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
Hi Carlos, it's my experience that skipping is_in, addr: and openGeoDB
works best for the Garmin index. What you'll then see is that some OSM
boundaries need to be improved. But getting that done will create a
perfectly working index (except for adresses, but it's always nice to
have some wishes for the future :-) )
Cheers, Johan
On Wed, 04 May 2011 23:48:34 +0200, Carlos Dávila
cdavi...@orangecorreo.es wrote:
This is what I'm using for Spain:
mkgmap:country!=* addr:country=* { set
mkgmap:country='${addr:country}' }
mkgmap:country!=* is_in:country=* { set
mkgmap:country='${is_in:country}' }
mkgmap:country!=* mkgmap:admin_level2=* { set
mkgmap:country='${mkgmap:admin_level2}' }
mkgmap:region!=* is_in:province=* { set
mkgmap:region='${is_in:province}' }
mkgmap:region!=* mkgmap:admin_level6=* { set
mkgmap:region='${mkgmap:admin_level6}' }
mkgmap:region!=* mkgmap:admin_level4=* { set
mkgmap:region='${mkgmap:admin_level4}' }
mkgmap:region!=* mkgmap:admin_level5=* { set
mkgmap:region='${mkgmap:admin_level5}' }
mkgmap:region!=* mkgmap:admin_level3=* { set
mkgmap:region='${mkgmap:admin_level3}' }
mkgmap:city!=* openGeoDB:name=* { set
mkgmap:city='${openGeoDB:name}' }
mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:city!=* mkgmap:admin_level7=* { set
mkgmap:city='${mkgmap:admin_level7}' }
mkgmap:city!=* mkgmap:admin_level9=* { set
mkgmap:city='${mkgmap:admin_level9}' }
mkgmap:city!=* mkgmap:admin_level10=* { set
mkgmap:city='${mkgmap:admin_level10}' }
___
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
Maybe one file is larger than the adjusted C/H/S values now specify. I don't think so. All my other maps, even the smallest ones are broken with the patched mkgmap. Did it fix the problem for you? Can you get me a compiled jar including the fix? I'm not a dev guy ... Peter ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
