Re: [mkgmap-dev] --make-cycleways labels invisible
Op 16-02-11 15:46, Felix Hartmann schreef:
highway=* oneway=yes cycleway=opposite {set oneway=-1; set
access=no; set bicycle=yes} [0x?? road_speed=? road_class=? continue]
What about the other oneway options? I.e. oneway could be 1, yes, -1
(and no, but that probably doesn't matter) as valid and/or legacy
options? I suppose for oneway=-1 one would need another {set oneway=1}
rule? (I'm not quite a rule specialist, as you may notice from my
ignorant questions).
I personally would hate to see the --make-cycleways option go; it's a
nice shortcut (hack if you like) for a pretty large style change.
Best regards,
Valentijn
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] crash. Too many tiles?
Hi list, This should have been a bit of an experimental map, with as much tiles as possible, by having splitter do --max-nodes=15 In the end, however, I don't get a map at all: java -enableassertions -Xmx1700m -jar ../mkgmap/dist/mkgmap.jar --make-opposite-cycleways --mapname=3168 --latin1 --remove-short-arcs=2.8 --reduce-point-density=5.4 --lower-case --route --preserve-element-order --max-jobs --location-autofill=1 --link-pois-to-ways --description=Nederland --style=1430 --family-name=Openstreetmap 29 jan 11 --series-name=OSM-Valentijn --gmapsupp --tdbfile --net -c template.args Exception in thread main java.lang.IllegalArgumentException at java.nio.ByteBuffer.allocate(ByteBuffer.java:311) at uk.me.parabola.imgfmt.sys.Directory.sync(Directory.java:176) at uk.me.parabola.imgfmt.sys.ImgFS.sync(ImgFS.java:230) at uk.me.parabola.imgfmt.sys.ImgFS.close(ImgFS.java:240) at uk.me.parabola.mkgmap.combiners.GmapsuppBuilder.onFinish(GmapsuppBuilder.java:119) at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:413) at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:126) at uk.me.parabola.mkgmap.main.Main.main(Main.java:127) This is in the Netherlands, so nodes all over the place, and in fact, I'm getting lots and lots of Area (51.8994140625,6.6357421875) to (52.0751953125,6.8994140625) contains 209.578 nodes but can't be split further messages. The resulting cut has 265 tiles. A few weeks ago, I remember having made such a map - but that could just be because there were a bit fewer nodes somewhere and the number of tiles was below 256 - could just be, I don't know. (The reason for this many tiles was the idea that a Nüvi might get better bike performance on long distances if the number of data to unpack (i.e. individual tiles) would be smaller - because of the smaller tiles. Might be just a stupid idea, I don't know, I was going to check but we might never know now... ;) So I'm just passing this on, for the sake of it, don't look too long at it because it's probably not worth it; but if there's an easy fix, it is welcome ;-) Best regards, Valentijn ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1709: Recognise operators such as = and = that have two characters.
svn commit schreef: Recognise operators such as = and = that have two characters. The != operator happened to work or else this would have been spotted sooner. Tests written for = and =. As far as I can see, r1709 chokes on the following: smoothness ~ '.*(bad|horrible|impassable)' | sac_scale ~ '.*(mountain|alpine)_hiking' | The error is: Error in style: Error: (lines:NN): Unrecognised operation . where NN is the line number. While r1708 seems to understand these without a problem. Best regards, Valentijn ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Routing does not work since December.
Hi Paul, Op 09-08-10 09:32, Paul Ortyl schreef: I wanted to report that routing through Europe is broken. I have noticed it in December 2009, but did not report it then because I thought that my nüvi got broken. [...] I realise that much has been said about routing not working. But there is something I'd like to add. Since r1431 (2009-12-10) bike routing has, IMHO and for my situation, degraded. When I'm building biking maps for the Amsterdam region, I'm using a style file from r1430. Please note that this is for the Netherlands (which has many, many roads and and abundance of bicycle paths on OSM) and for bike routing, which has it's peculiarities on it's own. So I'm not blaming anyone or anything, it's just what I'm noticing for my own maps. Also, please note that your problem does not sound like the problem I'm describing, as the bike routing not working can be tracked back to the style file changes in r1431 - and it seems a bit different from your problem. But apart from the tips and hints that others gave you, you might also want to check if revision 1430 (or it's style files) help you route better. And just in case your svn knowledge is as bad as mine: $ cd resources/styles/default/ $ svn up -r 1430 (Then, if you like, you can copy .../styles/default/ to .../styles/something/, then run $ svn up to get the styles up to date again, compile mkgmap and run it with --style=something to get the r1430 style in your map). Best regards, Valentijn ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] family-id Co.
Christian H. Bruhn schreef:
Hi!
I haven't really understand what are the following mkgmap-options are
for:
[ cut family-stuff options, VS]
I only knew that the map should have the same family-id (or was it the
product-id?) as in the TYP-file.
But what about the others? Which are really necessary? And where will
these informations be displayed?
java -jar mkgmap.jar --help=options tells you a bit about it:
--family-id
This is an integer that identifies a family of products.
--family-name
If you build several maps, this option describes the
family name of all of your maps. Garmin will display this
in the map selection screen.
Example: --family-name=OpenStreetmap mkgmap XL 2019
TODO: at least the - character seems to have a strange
effect on the family name; latin-alphabet and digits seem
safe, but other characters should be checked.
--product-id
This is an integer that identifies a product within a family.
It is often just 1.
--series-name
This name will be displayed in MapSource in the map selection
drop-down. The default is OSM map.
The country-names etc. seem to have an effect on the country a map is
in, i.e. if you set country-name=Molvania, all your places will be in
Molvania. However, I could be wrong here.
For myself, I use
--mapname=3100${mapid} (I increment this, as my Nuvi crashes if I put a
different map on it with the same mapID as the previous one, could be
some sort of caching mechanism)
--description=$land (this is just a textual description in the Nüvi)
--family-name=Openstreetmap `date +'%d %b %y'` (this is the map family
name, also displayed)
--series-name=OSM-Valentijn (I don't think this is displayed anywhere)
I don't use any other options on your list.
Valentijn
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] reduce-point-density vs. remove-short-arcs
Hi, I was wondering what is the difference between --remove-short-arcs and --reduce-point-density. Their description differs (short-arcs says it removes things that cause routing problems, while point-density seems some sort of general simplification), but I'd think that using --reduce-point-density would mean that there's no short-arcs left afterwards, or are there? I.e. is there any cross effect between the two? (I now have -remove-short-arcs=5.5, but that's probably purely for historical reasons). Best regards, Valentijn ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] garmin directives in different blocks?
Op 16-04-10 09:34, Felix Hartmann schreef:
[...]
highway=motorway {add bicycle = no; add foot = no} [0x16 road_class=4
road_speed=1 resolution 14 continue]
highway=motorway {add access = no; add bicycle = yes; add foot = yes}
[0x16 road_class=4 road_speed=1 resolution 14]
Well you have continue vs continue_with_actions, I don't see where your
[...]
Thanks. I now understand how it works. (Before, I didn't).
Best regards,
Valentijn
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Java crash - any idea?
Hi list, Mkgmap seems to crash on my brand new Ubuntu 10.04 installation with OpenJDK and I can't make anything of it (not being a Java wizard, that is). What does the attachment say? (I just hope it doesn't say Switch to Oracle Java for €1,837,838 per seat ;) Best regards, Valentijn # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x010df786, pid=2517, tid=1161292656 # # JRE version: 6.0_18-b18 # Java VM: OpenJDK Server VM (14.0-b16 mixed mode linux-x86 ) # Derivative: IcedTea6 1.8 # Distribution: Ubuntu lucid (development branch), package 6b18-1.8-0ubuntu1 # Problematic frame: # V [libjvm.so+0x4f1786] # # If you would like to submit a bug report, please include # instructions how to reproduce the bug and visit: # https://bugs.launchpad.net/ubuntu/+source/openjdk-6/ # --- T H R E A D --- Current thread (0x09dff800): GCTaskThread [stack: 0x452fe000,0x4537f000] [id=2520] siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0xccd94790 Registers: EAX=0xccd94790, EBX=0x0125cff4, ECX=0x09e5c768, EDX=0x4537e070 ESP=0x4537de30, EBP=0x4537de48, ESI=0x4d415b64, EDI=0x01276638 EIP=0x010df786, CR2=0xccd94790, EFLAGS=0x00210206 Top of Stack: (sp=0x4537de30) 0x4537de30: 45639578 45639450 4537de68 0125cff4 0x4537de40: 4d415b60 4537df6c 4537ded8 00e985ae 0x4537de50: 4537e070 4d415b64 4537e070 4537e070 0x4537de60: 4537df40 b785bf80 4537ded8 00e9956d 0x4537de70: 0398c608 4537df84 01858fc8 456a5430 0x4537de80: 01a4 09dff800 0001 09dffdc0 0x4537de90: 456a5430 45370025 0005 0x4537dea0: 0001 b785bf78 Instructions: (pc=0x010df786) 0x010df776: 73 08 8d 65 f4 5b 5e 5f 5d c3 8b 55 08 8b 4a 0c 0x010df786: 8b 10 83 e2 03 83 fa 03 74 50 52 31 d2 8a 51 78 Stack: [0x452fe000,0x4537f000], sp=0x4537de30, free space=511k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x4f1786] V [libjvm.so+0x2aa5ae] V [libjvm.so+0x2aaa69] V [libjvm.so+0x57fba0] V [libjvm.so+0x4f10c3] V [libjvm.so+0x2cf42e] V [libjvm.so+0x4a6621] C [libpthread.so.0+0x596e] --- P R O C E S S --- Java Threads: ( = current thread ) 0x44f18400 JavaThread Low Memory Detector daemon [_thread_blocked, id=2527, stack(0x44d1d000,0x44d6e000)] 0x44f16000 JavaThread CompilerThread1 daemon [_thread_blocked, id=2526, stack(0x44d6e000,0x44def000)] 0x44f14800 JavaThread CompilerThread0 daemon [_thread_blocked, id=2525, stack(0x44def000,0x44e7)] 0x44f13000 JavaThread Signal Dispatcher daemon [_thread_blocked, id=2524, stack(0x44e7,0x44ec1000)] 0x44f00800 JavaThread Finalizer daemon [_thread_blocked, id=2523, stack(0x45016000,0x45067000)] 0x09e80800 JavaThread Reference Handler daemon [_thread_blocked, id=2522, stack(0x45067000,0x450b8000)] 0x09df7400 JavaThread main [_thread_blocked, id=2518, stack(0xb780c000,0xb785d000)] Other Threads: 0x09e7d800 VMThread [stack: 0x450b8000,0x45139000] [id=2521] 0x44f1a000 WatcherThread [stack: 0x44c9c000,0x44d1d000] [id=2528] =0x09dff800 (exited) GCTaskThread [stack: 0x452fe000,0x4537f000] [id=2520] VM state:at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: ([mutex/lock_event]) [0x09df51e0] Threads_lock - owner thread: 0x09e7d800 [0x09df55f0] Heap_lock - owner thread: 0x09df7400 Heap PSYoungGen total 154432K, used 128880K [0xabb2, 0xb75f, 0xb780) eden space 117952K, 100% used [0xabb2,0xb2e5,0xb2e5) from space 36480K, 29% used [0xb2e5,0xb38fc030,0xb51f) to space 35008K, 13% used [0xb53c,0xb5846080,0xb75f) PSOldGentotal 407680K, used 176324K [0x4d40, 0x6622, 0xabb2) object space 407680K, 43% used [0x4d40,0x580312a0,0x6622) PSPermGen total 16384K, used 8274K [0x4540, 0x4640, 0x4d40) object space 16384K, 50% used [0x4540,0x45c14b98,0x4640) Dynamic libraries: 0011-00263000 r-xp 08:01 14401813 /lib/tls/i686/cmov/libc-2.11.1.so 00263000-00264000 ---p 00153000 08:01 14401813 /lib/tls/i686/cmov/libc-2.11.1.so 00264000-00266000 r--p 00153000 08:01 14401813 /lib/tls/i686/cmov/libc-2.11.1.so 00266000-00267000 rw-p 00155000 08:01 14401813 /lib/tls/i686/cmov/libc-2.11.1.so 00267000-0026a000 rw-p 00:00 0 0026a000-0028e000 r-xp 08:01 14401819 /lib/tls/i686/cmov/libm-2.11.1.so 0028e000-0028f000 r--p 00023000 08:01 14401819 /lib/tls/i686/cmov/libm-2.11.1.so 0028f000-0029 rw-p 00024000 08:01 14401819 /lib/tls/i686/cmov/libm-2.11.1.so 0029-00297000 r-xp 08:01 14401831 /lib/tls/i686/cmov/librt-2.11.1.so 00297000-00298000 r--p 6000 08:01 14401831 /lib/tls/i686/cmov/librt-2.11.1.so 00298000-00299000 rw-p 7000 08:01 14401831 /lib/tls/i686/cmov/librt-2.11.1.so 00299000-002b rwxp 00:00 0 002b-00359000 rwxp 00:00 0
[mkgmap-dev] question about styles and routing
Hello list,
I'm trying to get better bicycle routing in my Garmin map; however, I
don't know much about styles and the Garmin mapping, so I thought it
might be wise to ask questions first (and shoot later):
What I thought I'd do is make a sort of double routing for bicycles:
when a road is on national biking paths (at least in the Netherlands,
this means a tag network=ncn) or regional bike paths (network=rcn), I
might want an extra road with higher routing preference, only for bikes.
This would mean a sort of double road; but I'm hoping it will only
affect bicycle routing:
highway=unclassified network!=ncn network!=rcn [0x06 road_class=1
road_speed=2 resolution 21]
highway=unclassified [0x06 road_class=1 road_speed=2 resolution 21 continue]
highway=unclassified network=ncn {set access=no; set bicycle=yes }
[0x06 road_class=3 road_speed=1 resolution 18 continue]
highway=unclassified network=rcn {set access=no; set bicycle=yes }
[0x06 road_class=2 road_speed=1 resolution 19]
(This should probably be done for other types of highway as well, but I
did not think the chances of a bike path going through a highway=primary
too high ;)
Also, in the same way, get different bicycle paths:
highway=cycleway network=ncn {add access = no; add bicycle = yes; add
foot = yes} [0x16 road_class=3 road_speed=1 resolution 18]
highway=cycleway network=rcn {add access = no; add bicycle = yes; add
foot = yes} [0x16 road_class=2 road_speed=1 resolution 19]
highway=cycleway {add access = no; add bicycle = yes; add foot = yes}
[0x16 road_class=2 road_speed=1 resolution 23]
Would this, theoretically, work? (And if not, why not?)
Best regards,
Valentijn
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] regression in r1431
Hi list, I found a grave routing difference between mkgmap r1430 and r1431, when I set routing to bicycle, shortest route. r1430 (and older) sends me right to my target; r1432 (and newer) meanders around like there's no other things to do than pedaling around in the countryside. Really: a mere 15 kilometer trip will increase to 57 kilometers! I'd guess this is mainly because of: -highway=unclassified [0x06 road_class=1 road_speed=2 resolution 21] +highway=unclassified [0x06 road_class=0 road_speed=3 resolution 21] ... but other factors in r1431 may add to this. As far as I can see from the mailing list, r1431 patch *improves* routing over large distances (see mailing list, messages with subject Patch for better Autorouting, 2009-12-01 and further). Now what to do? (Maybe it's time to have a separate bicycle routing style in mkgmap?) Best regards, Valentijn ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Recommended version?
Hi Steve, hi list, Steve Ratcliffe schreef: But how do we coordinate across all the languages? We now have English, French, German, Dutch and Japanese translations of the main page on the wiki. The version number could probably be made a template so that it can be updated in one place, but if we want to offer a list of changes then this will have to be translated. Even the English wiki page does not seem to reflect the mkgmap-usage. (if http://wiki.openstreetmap.org/wiki/MkgmapAlso, is what we're talking about; but I'm not sure, as http://wiki.openstreetmap.org/wiki/DE:Mkgmap works for me) Also, for a couple of options, there's no information about the sensible default and/or the problems that one may run into. A couple of examples could be of use here. V. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] grok unpavedness
Mark Burton schreef: Is everyone happy with that? If so, I will make the change and commit it. Shouldn't the default style then have a mkgmap:ferry so the default works as the regular Garmin map? Has anyone confirmed that the ferry part works yet? Works as expected. Thanks! V. -- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1423: Tests did not compile due to change in StyledConvter, changed back.
Steve, r1423 and further do not work for me; r1422 does. r1423 and later say: java -enableassertions -Xmx1700m -jar ../bin/mkgmap.jar --make-opposite-cycleways --mapname=3182 --latin1 --remove-short-arcs=5.5 --lower-case --route --preserve-element-order --max-jobs --link-pois-to-ways --location-autofill-1 --link-pois-to-ways --description=Nederland --family-name=Openstreetmap\ 09\ dec\ 09 --series-name=OSM-Valentijn --gmapsupp --tdbfile --net -c template.args java.lang.NoSuchMethodError: uk.me.parabola.mkgmap.osmstyle.StyledConverter.init(Luk/me/parabola/mkgmap/reader/osm/Style;Luk/me/parabola/mkgmap/general/MapCollector;Luk/me/parabola/util/EnhancedProperties;)V at uk.me.parabola.mkgmap.reader.osm.xml.Osm5MapDataSource.createStyler(Osm5MapDataSource.java:124) at uk.me.parabola.mkgmap.reader.osm.xml.Osm5MapDataSource.load(Osm5MapDataSource.java:80) at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:148) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:56) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:187) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:185) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) Best regards, Valentijn svn commit schreef: Version 1423 was commited by steve on 2009-12-08 23:37:29 + (Tue, 08 Dec 2009) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] grok unpavedness
Hi, I'm not sure I understand the mkgmap:tag stuff after all. The mkgmap:ferry is an internal mkgmap tag, isn't it? I.e. it's a sort of intermediate tag, meaning the OSM input map should *never* have the mkgmap:whatever tags present? As far as I read Steve Hosgood's remarks, it looks like anyone could be tempted into adding mkgmap:ferry tags to OSM, but that sounds at least a bit odd to me. Or don't I understand Steve's remarks here? Best regards, Valentijn ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] grok unpavedness
Steve Hosgood schreef: Look - I'll just wear a paper bag over my head for the rest of the day, OK? :-) I don't think tagging yourself like that does any good ;) V. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v2] grok unpavedness + ferry nature
Mark Burton wrote: v3 - turns out they handle ferry routes in a similar fashion as to unpaved roads so I've added support for avoiding them (when route=ferry tag is present) - untested here due to paucity of ferries in Cheshire but I have verified that the unpaved stuff still works. Aha, aha. That's just something I did not get to work and I didn't know why - and still don't, but you do and I'll insert your patch shortly and give it a try. Report will follow. V. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] routing oddity
Hi list, A routing oddity on Mapsource and my Garmin Nuvi: http://osm.org/go/0E6U9XKEb-?layers=0B00FTF When I'm driving on the A1 highway, it always sends me down the motorway_link, then up on the motorway_llink again. Could this be because the bridge over the Weteringweg makes the A1 consist of 3 parts, while driving over the motorway_llink has only 2 (or maybe they're connected in mkgmap, so it's only 1 part?) I'm just guessing wildly here; the routing oddity is always there though, so you might want to take a brief look. Best regards, Valentijn ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Compiling Mkgmap failes
Lambertus schreef: I'm having problems compiling Mkgmap, maybe someone here is able to help [...] What does sudo update-alternatives --config java tell you? V. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Compiling Mkgmap failes
Lambertus, * 0/usr/bin/gij-4.4 1044 auto mode 1/usr/bin/gij-4.4 1044 manual mode Which one should I choose? Number 2 I suspect? Yep. Numbers 0 and 1 are the Gnu Java runtime. You probably have the Gnu java compiler as well. You did not completely remove all java before installing sun's java. Please remove gij-4.4 and related: probably gcj-4.4-jdk, gcj, gcj-4.4-jre and/or other gcj-related stuff. And you might as well check update-alternatives --config javac (which should be the Sun version as well). Best regards, Valentijn ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] weird: file missing when # of files 10?
Mark Burton schreef:
Yes, that's good enough. I was wondering if you were using something
exotic. But no.
Good to hear from someone who agrees Ubuntu is not exotic :)
Actually, I'm using Ubuntu 8.04 and I get:
java version 1.6.0_16
After adding hardy-proposed to my sources.list:
java -version
java version 1.6.0_17
And... it fixes the problem. I ran a full build and it seems to be OK.
Now I'm still stumped though - I think now Sun (Oracle?) is the only one
who can fix that? ;)
Thanks for your help.
Best regards,
Valentijn
p.s. If you really, really want to know what happened, then just
downgrade your Java version - something like sudo apt-get install
sun-java6-{jre,bin,jdk}=6-06-0ubuntu1 should do.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] weird: file missing when # of files 10?
Hi list, I wrote about this before: my first map in the mapset, 63240001.img, is missing. I tracked this down to revision r1363 (which is a merge from the mapset branch) and today even further tracked it down to revision 1323 within the (deleted) mapset branch. However, I can't find any clues in r1323 as to what causes this. Further experiments showed even weirder results: as I compile my maps from a template.args file, it showed that having 63240001-63240009 in there would give me the correct map; having a 10th file in there made the first one missing. (Currently, while compiling the Netherlands, my template.args file has 14 entries. Any number above 9 makes the first one disappear). And indeed, when I duplicated the first file like so: mapname: input-file: 63240001.osm.gz mapname: 63240001 input-file: 63240001.osm.gz mapname: 63240002 [...] ... the map would be correct (with the void probably missing, and 63240001 included). Now I'm stumped. Would anyone know what's going on here? I thought of a race condition and removed the --max-jobs option, but that makes no difference. Best regards, Valentijn ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Overview Map still broken
Felix, I just had an issue where one of the submaps goes missing. Could my problem be the same as yours? Could you check rendering the same map with mkgmap r1362 and see if this restores your overview map? And if r1363 makes it go wrong? Best regards, Valentijn Felix Hartmann schreef: I am not sure if you are aware, that the overview map still is not correct (this causes on my compile of Asia large parts of the map to be invisible in Mapsource).[...] -- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Map missing from r1363++ (Re: Commit: r1363: Merge the mapset branch back to trunk.)
Clinton Gladstone schreef:
Hm... I can't reproduce this: my map of Germany appears to generate all tiles
correctly. Perhaps there is something else going on.
Logging did not show anything peculiar. Or showed lots and lots of data
and I didn't know what to look for :)
What I do:
#!/bin/sh
memory=1700m
land=Nederland
landfile=netherlands.osm.bz2
wget http://download.geofabrik.de/osm/europe/$landfile;
bzcat $landfile unpacked.osm
java -enableassertions -Xmx$memory -jar ../splitter/dist/splitter.jar
--description=$land --max-nodes=60 unpacked.osm
mapid=`sed 's/^0*//' mapid`
mapid=`printf '%d' $mapid`
mapid=$(( $mapid + 1 ))
mapid=`printf '%04d' $mapid`
echo $mapid mapid
echo Rendering map number $mapid...
set -x
java -enableassertions -Xmx$memory -jar ../mkgmap/dist/mkgmap.jar
--make-opposite-cycleways --mapname=3100${mapid} --latin1
--remove-short-arcs=5.5 --lower-case --route --preserve-element-order
--max-jobs --location-autofill-1 --link-pois-to-ways
--description=$land --family-name=Openstreetmap `date +'%d %b %y'`
--series-name=OSM-Valentijn --gmapsupp --tdbfile --net -c template.args
This gives me a map where the left lower corner of the Netherlands is
missing (Rotterdam and around it). This is 63240001 and yes, it could be
a coincidence that it's the first map in the template. It's size:
63240001: 2383872,153600 to 2424832,202752
# : 51.152344,3.295898 to 52.031250,4.350586
The map itself renders all right, i.e. there's a 63240001.img afterwards
that shows all the info I want.
Best regards,
Valentijn
--
Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v2] - fix routing problems caused by way's bbox being too large
Mark, (Right after I compiled a map with your v1 patch, a 2nd version shows up...) If the map does not complain in any way (i.e. no assertions), does that mean I don't hit the bbox problem? (Your patch v2 is now included in my mkgmap, so I'll test it for a bit next days). Valentijn Mark Burton schreef: v2 - added some assertions to catch out of bound line start coordinates - Increased size of line bbox - reduced size of polygon bbox. [...] ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] tweezing-arcs: success
Mark, list, Today I had the chance of biking with an arc tweezed map on a route that went wrong, previously. The tweezing really makes routing much, much, much better. There is of course the occasional why-do-you-send-me-this-silly-way routing decision, but generally, bicycle routing has suddenly improved to a useful state; some of the routing decisions are probably even the result of lacking cycleway=opposite tags. Really good. Occasionally, there was an odd direction, but that, too, was probably the result of mapping oddities. So, thanks again for the wonderful job mkgmap.jar does :) Valentijn ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Anyone tried the arc tweezing patches?
Mark Burton schreef: I have received zero feedback on the recent arc tweezing patch. Ehrm, eh, yes. Whatever destination I have in mind lately, I always seem to end up in the baby room. There's no computer there, you know. Anyway, tested your patch and it shows a huge improvement on a couple of weird routes I've come across so far. Like this one: http://www.yournavigation.org/?flat=52.445382flon=4.80525tlat=52.404858tlon=4.922044v=bicyclefast=1layer=mapnik ... where the Nuvi sent me all around on a 30km journey, it now has quite a decent route, roughly comparable to the yournavigation.org one. The improvement seems especially visible with the shortest route setting; shortest time seems less affected (but I could be wrong here). (And I'm testing bicycle routing here, which cannot work correctly by design as has been pointed out on the list before). I did not find any broken routes (failure as you call it). As your patch is now in my mkgmap, I will test some more and I shall report any oddities. Best regards, Valentijn ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1246: Impelent mdr 4 and 9 as best as we know.
svn commit schreef: no matter what category you select you always get a couple of pubs and a bus stop included in the results. Good. That's Don't drink and drive implemented in software, right? V. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] - Reduce number of Table A entries required
Bennie, Du Plessis, Bennie schreef: [...] Making Southern Africa in one tile I can route maximum approx 1400km.(870m) I can approve slightly by increasing --remove_short_arcs=50, but that distorts the map :( ... because you essentially remove every detail that's less than 50 meters :-( Making SA in 2 tiles routing capability reduces to approx. 700km (435m) roughly half? I would dearly love to try this patch, I just applied the patch. I'll send you a compiled mkgmap.jar per separate e-mail (as sending 500K over the mailing list feels a bit rude). (although I feel like the only non-tech around and in that case its propably too much trouble;( Actually, if you have the machinery in place, applying the patch is quite easy. However, if you don't have the machinery, setting it all up (Subversion, Java environment, patch, ant, ...) on a Windows machine is probably not for the faint of heart. Best regards, Valentijn ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] - Reduce number of Table A entries required
Mark, As far as I can see, it works well. I haven't tested it very thoroughly, but I don't find immediate oddities. There's still the various routing oddities. Mapsource sometimes doesn't find a route; my Nuvi sometimes finds weird routes (and sometimes does it right). Anyway, your patch makes the image file a bit smaller and does not seem to change routing (not better, not worse). Best regards, Valentijn Mark Burton schreef: Reduce number of Table A entries. [...] ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] - Route centre tweaks
Mark Burton schreef: Today's offering includes the table A tweak but it also increases one of the limits that determine when a route centre needs to be sub-divided.[...] So please test this patch (it replaces the previous patch) and let me know if their are any issues. No issues found with just simple tests. By the way, Mark, please try the following route and be surprised: http://www.yournavigation.org/?flat=52.445382flon=4.80525tlat=52.404858tlon=4.922044v=bicyclefast=1layer=mapnik Mapsource sends me through Oostzaan but has a sensible route. It's a bit longer than what Yournavigation makes of it, but it's understandable, given the turning penalties Garmin seems to have. But the Nuvi does really really strange things: it routes me through Krommenie http://osm.org/go/0E5sYyYM--?layers=0B00FTF, then Purmerend http://osm.org/go/0E7Ea66?layers=0B00FTF ... and only then to Amsterdam. Is this reproducable in your brand new Nuvi? Best regards, Valentijn ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1198: Merge in the sea polygon patch from the multipolygon branch.
Hello list,
svn commit schreef:
Version 1198 was commited by steve on 2009-09-17 10:27:24 +0100 (Thu, 17 Sep
2009)
Hmm. While it is generally known that much of the Netherlands is sub sea
level, the map that's currently resulting from mkgmap --generate-sea
feels like a Greenpeace-ad (rising sea levels! Save the environment!)
My 63240007 tile is completely flooded. Some other tiles are too, but
63240007 is in the middle of the map, which makes a Geofabrik cutoff
fault less likely. Here's the setup:
areas.list:
63240001: 2383872,153600 to 2424832,202752
63240002: 2392064,202752 to 2424832,235520
63240003: 2363392,235520 to 2396160,292864
63240004: 2396160,235520 to 2424832,260096
63240005: 2396160,260096 to 2424832,321536
63240006: 2424832,178176 to 2437120,223232
63240007: 2424832,223232 to 2437120,256000
63240008: 2437120,206848 to 2445312,256000
63240009: 2445312,198656 to 2494464,256000
63240010: 2424832,256000 to 2453504,329728
63240011: 2453504,256000 to 2494464,288768
63240012: 2453504,288768 to 2502656,337920
(Generated from java -enableassertions -Xmx$memory -jar
../splitter/dist/splitter.jar --max-nodes=60 --description=$land
unpacked.osm)
java -enableassertions -Xmx$memory -jar ../mkgmap/dist/mkgmap.jar
--make-opposite-cycleways --mapname=3100${mapid} --latin1
--remove-short-arcs=5.5 --lower-case --route --preserve-element-order
--max-jobs --link-pois-to-ways --location-autofill-1 --generate-sea
--description=$land --family-name=Openstreetmap `date +'%d %b %y'`
--series-name=OSM-Valentijn --gmapsupp --tdbfile --net -c template.args
Any ideas?
Best regards,
Valentijn
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] access times?
Hello list, There's a street in the center of my town where access is forbidden on thursday and saturday. Now there seems no good way to enter such information in Openstreetmap (but that's a wholly different discussion). The reason I'm writing here is: do Garmin maps have a way to encode time-dependent access schemes? And, if yes, does mkgmap? (And if yes still, is there a way to use this information - as OSM is lacking it currently?) Best regards, Valentijn ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Auto-Merge
Mark Burton schreef: The fact that other routing services choose to do that does not make me any more enthusiastic about the idea. IMHO, if people want specific changes to their OSM data before rendering a map, it's pretty easy to do so. Merging different nodes on basis of some rule (the rule in this case being coordinates are the same) could be one of these pre-processors. I agree that this should not be mkgmap's job. Another nice preprocessor I just made is (remove extra line feeds): sed 's/k=name v=[^]*\(straat\|plein\|hof\|dijk\|laan\|weg\|gracht\|vaart\| museum\|pad\|school\|college\|zicht\|groeve\|park\| Museum\| weide\|sluis\|singel\|haven\|sloot\|plantsoen\|kanaal\|kade\)/k=name v=Name Of Collegue\1/' unpacked.osm specialmap.osm This made a nice birthday map of the Netherlands; we had a good laugh over it. (Bonus is the fact that card and map are the same word in Dutch, so birthday card is the same as birthday map :) Replacing these words with their English (or other language) equivalent is left as an excercise to the reader. Also: if you can't find your way home afterwards, you'll have a great excuse. Best regards, Valentijn ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] New splitter version, big memory savings
Chris, thanks for al the good work. Just a small and unrelated remark. The script that builds my map first unpacks the osm.bz2 file, then runs splitter. Still, Splitter complains about no --cache being used, while as far as I understand, there's no real advantage using --cache if you're using uncompressed files, or is there? Best regards, Valentijn Chris Miller schreef: I've just checked in a new version of the splitter (r84) that requires far less memory and also performs slightly better during the first stage of the split. [...] ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Which Nuvi?
Mark Burton schreef: As I want the Nuvi primarily for navigation, I don't really mind if logging isn't possible or, if possible, not good quality. The fact that it works well with our maps is enough. Just one small remark (at the moment you have probably ordered your Nuvi already): if you're going to use it on a (motor)bike, you might want to check the availability of a mounting kit for it. V. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Which Nuvi?
Thilo Hannemann schreef: So I think at least the Nüvi 2xx series is useless for mapping. My Nuvi 205T has an option to show/hide the tracklog. I bought it quite recently, but it has an older map (2008). I'll ask a collegue, who just got a 205, if he has the tracklog option as well. V. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] address search problem due to required State value
Hi Steve, At Sun, Aug 30, 2009 at 11:29:16PM +0100, Steve Hosgood wrote: We could really use a wiki page on stuff like this. I do have an apparently-OK copy of 'mapsource' but it won't start because I don't have an installed map. Yeah, that's a bit weird: I have one MapSource that does have the base map, the other doesn't. While both were installed through the trick with the training software... I guess it has something to do with the version for older OS'es and/or the regular version. (I'm running the former, because I'm running it under emulation software: Wine). Anyway, here's how to install a map: 1. Download mapsettoolkit from http://cypherman1.googlepages.com/ 2. start it. Now do the following: 3. Press Install 4. Choose your TDB file 5. For IMG file, choose the same name as your TDB file (if you have mkgmap.jar defaults, both would be 6324). Now IIRC you press install and then you're done: your generated map is now in the list. You can exit mapsettoolkit and start mapsource. Best regards, Valentijn ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] --make-all-cycleways oddity
Marko Mäkelä schreef: On Sat, Aug 29, 2009 at 07:29:08AM +0200, Valentijn Sessink wrote: http://onroute.nl/ Can you please explain how that link is relevant to the Garmin SDK? It probably isn't. I know them for making a cycle map for the Netherlands. But they could be using anything to build their map. Valentijn ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v5] - min arc length fixes
Mark, I'm afraid I lost track when you wrote Blast, just discovered that clipping all ways before doing short arc removal breaks polygons that straddle tile boundaries - afterwards, the discussion wandered off to Massachusetts. If I understand you correctly, your v4 patch is in svn now, so if I run into strange routing, I should report and/or check if v5 performs any better? (In fact, I mainly run into perfectly working routing, my Garmin even told me a *better* route for a track I'm riding every day for 1,5 years now :) Best regards, Valentijn -- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] --make-all-cycleways oddity
Hi list, hi Mark, First, a remark. Since the oneway=yes/cycleway=opposite roads have (cycleway) attached to their names, a GPS unit will randomly show either the regular name, or the (cycleway) name. Which isn't too bad for testing, I'd suggest you leave it this way until we're set and done with it, because now you can see *why* a certain road is accessible or inaccessible (i.e. it tells you where you're driving). Namely, here's one occasion where it came in handy: Yesterday I drove by car to one of those cycleway=opposite ways and to my surprise, my Garmin told me to turn right to Hembrugstraat (cycleway). I'm absolutely sure that the unit was set to car and not bike. So is there a bug in the opposite-way-code? (Or is this the strange idea of a Garmin that you can route the wrong way for some meters??) I had another Garmin unit with me with a regular Garmin map, that showed the right route; also, the route is nothing special, just about this: http://www.yournavigation.org/?flat=52.392997flon=4.871082tlat=52.391864tlon=4.87679v=motorcarfast=1layer=mapnik Any ideas? (I'll recheck the routing later on, to see if this will also happen with positions further away in one-way-streets). Best regards, Valentijn -- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] --make-all-cycleways oddity
Mark, Mark Burton schreef: http://www.yournavigation.org/?flat=52.392997flon=4.871082tlat=52.391864tlon=4.87679v=motorcarfast=1layer=mapnik Any ideas? (I'll recheck the routing later on, to see if this will also happen with positions further away in one-way-streets). I think that (at least with mapsource) the routing restrictions are considered advisory at times rather than absolute prohibitions. If you start a route close to a road that has a synthesised cycleway I can quite believe that the gps would grab the cycleway instead of the road. If it routes down the cycleway from another way and a road is also available at the same point, that's not good. In this case, it does: see the route above (the correct one); my Nuvi sends me right to the corner Spaarndammerdijk/Hembrugstraat and wants me to turn right to Hembrugstraat (cycleway). I know that accessibility is only advisory when there's no other way, but in this case, there's a clear route to the destination, but with the cycleway option turned on, it sends me in the wrong direction. I'll check what it does without the cycleways first. V. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] --make-all-cycleways oddity
Hi Mark, Without the all-cycleways option, it behaves normally. There must be some sort of Garmin rule in action here. I'll check if there's a better way (haha) to build the cycleway. Valentijn ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] make-cycleways
Valentijn Sessink schreef: there's no real need to build an extra way here - or is there? Ahem. It's optional, I see. V. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] make-cycleways
Hi, Mark Burton schreef: However, if there's no access restriction for cyclists, there's no real need to build an extra way here - or is there? You have a point. Of course, an access restriction could be added later by the style rules but that's pretty unlikely? I'm not sure altogether. The thing is, I myself wouldn't tag a road with the combination bicycle=no/cycleway=lane, as this feels wrong. (You can't have a bike lane on a road that allows no bikes, as the lane is part of the very road). But that doesn't mean it's not possible. I simply don't know. So actually, for me, the opposite cycleways are enough and I simply should use that option. I'm not sure what the other option could do. If others find it useful - leave it as is. Best regards, Valentijn ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] --make-all-cycleways oddity
Mark, I've tried a couple of different methods to build opposite-cycleways, namely forbid all motoring traffic, make a real cycleway, but all of them make the Garmin turn to the last part of the oneway Hembrugstraat. So I conclude it's a Garmin issue. I'm sure we could come up with all sorts of nasty tricks to work around it, but I'd suggest we leave it this way. Valentijn ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] --make-all-cycleways oddity
Mark, I think the following could be what happens. The GPS unit tries to route you to $dest, which is on a non accessible road. As non accessible has no access, it makes no sense trying other directions. If there's a crossing, that's a reason to try other directions so the oneway street will come up. I was thinking: are the oneway street and the fake route interconnected automatically? I know they share the nodes, is that the same as being able to skip between them? I.e. is it: | | +--++-++ a street +--++-++ a street (cycleway) | | ... or | | +--..-+. a street +--..-+. a street (cycleway) | | ? Valentijn -- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] board ferry mystery not a mystery after all
Hello list,
The current ferry routes don't tell me to board the ferry (I've written
about that before).
However, if I use ferry type 0x1b instead of 0x1a, my Garmin Nüvi shows
a nice boat icon on the track, it tells me to board ferry. The other
behaviour so far seems identical to type 0x1a.
So I would kindly recommend the attached one-bit (it's even the least
significant one) patch, changing the ferry route type from 0x1a to 0x1b.
Best regards,
Valentijn
--
Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579
Index: resources/styles/default/lines
===
--- resources/styles/default/lines (revision 1147)
+++ resources/styles/default/lines (working copy)
@@ -69,7 +69,7 @@
railway=tram [0x14 resolution 18]
railway=platform {add access = no; add foot = yes} [0x16 road_class=0 road_speed=0 resolution 23]
-route=ferry [0x1a road_class=0 road_speed=0 resolution 18]
+route=ferry [0x1b road_class=0 road_speed=0 resolution 18]
waterway=canal [0x1f resolution 21]
waterway=drain [0x1f resolution 22]
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] options: description
Hi all, Marko Mäkelä schreef: on on should be or on Fixed (see attachment) +Please note: if you use splitter.jar to build a template.args file +and use -c template.args, then that file may contain a [...] I think that this is a general remark that would better be documented with the -c option, something like this: I think your explanation to the -c is very useful, too. Please feel free to improve the wording. I wouldn't mention splitter.jar in the help text, because the config file may be edited by hand. I agree. However, the --description not working gave me headaches, that's why I mentioned it at the --description description. Revised (and combined) patch attached. Better? Valentijn Index: resources/help/en/options === --- resources/help/en/options (revision 1144) +++ resources/help/en/options (working copy) @@ -26,6 +26,10 @@ line can be used, however you omit the leading '--'. The short option names with a single '-' cannot be used, simply use the long name instead. + Note: mkgmap will process options from left to right. Options given + in the command line after -c filename will override any options + given in the file. Likewise, command line options specified before + -c filename will be overridden by the option file. -n name --mapname=name @@ -36,7 +40,10 @@ --description=text Sets the descriptive text for the map. This may be displayed in - QLandkarte, MapSource on on a GPS etc. + QLandkarte, MapSource or on a GPS etc, where it is normally shown + below the family name. Example: --description=Germany, Denmark + Please note: if you use -c template.args, then that file may + contain a description that will override this option. --country-name=name Sets the map's country name. The default is COUNTRY. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] options: description
Steve Ratcliffe schreef: Perhaps it belongs in the splitter doc then? Or the splitter could leave out (or comment out) the description lines by default, unless the --description option is given. I agree. Although then still a remark about the -c filename description could be useful. (As you see, I dropped the referral to splitter already). V. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] options: description
Steve, list, This may be a better description of --description, it sort of warns for the description that splitter puts in the args file. Best regards, Valentijn -- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579 Index: resources/help/en/options === --- resources/help/en/options (revision 1144) +++ resources/help/en/options (working copy) @@ -36,7 +36,12 @@ --description=text Sets the descriptive text for the map. This may be displayed in - QLandkarte, MapSource on on a GPS etc. + QLandkarte, MapSource on on a GPS etc, where it is normally shown + below the family name. Example: --description=Germany, Denmark + Please note: if you use splitter.jar to build a template.args file + and use -c template.args, then that file may contain a + description that will override this option. Use --description in + splitter.jar to change the description in the template.args file. --country-name=name Sets the map's country name. The default is COUNTRY. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] bug or feature?
Hi list, I guess I found out that --description does not work when using a -c template-file. Is this a bug or a feature, i.e. does the source need to be patched or should I patch the documentation? (I'm willing to do the latter, but not if a fix in the source is really easy). Best regards, Valentijn -- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mistake in options?
Hi Carlos, Carlos Dávila schreef: --description=OpenStreetMap-Iberia --family-name=Open Street Map --series-name=OSM-Iberia-s That's what I use, except for the --series-name. I copy generated gmapsupp.img directly to the nuvi's SD. In the map selection menu I get: [ ]Open Street Map (from --family-name) [1] OpenStreetMap-Iberia (from description) Carlos: do you use -c template.args or are you rendering the map directly? (I.e. could it be that, when you use template.args, the description is read from the template file?) Best regards, Valentijn -- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Does anyone have a genuine garmin routable map tile that is unlocked?
Mark, Mark Burton schreef: Not a basemap, but a real routable tile. I don't have one, but I could buy something, *if* that gives you an unlocked, routable tile. And I'm not sure about the unlocked property - if I buy, for example, a bicycle map of the Netherlands, on SDcard (something I've been thinking about anyway, to compare the differences with the OSM map), would that give me an unlocked map? Or a locked one? V. -- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] splitter: small patch and wishlist
Chris, Chris Miller schreef: VS My own code has a private boolean deleted that is added to VS SplitParser, and in endElement() it says if (!deleted) [...] That's not too horrible, The idea might not be, trust me: the code was :) In fact, when I woke up this morning, I realised that probably the state machine in startElement could just be bypassed - and that's what you did already(*). I've committed a fix for this. Thanks. V. (*) I hope Rupert Sheldrake doesn't find out ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Inter-tile routing failures - not all our fault?
Mark Burton schreef: There is a particular failure of inter-tile routing that we have seen quite often which is that it fails to find a route when the source and destination are in the same tile and the only (sensible) route is via another tile. (If a sub-optimal route that only uses the source tile is available that will get used.) Maybe we should investigate one such problem really thoroughly? I've also been thinking that a map with all of these problems would be a good idea, but I don't know if that would be feasible. Pro: have all problems in one, easily compilable, easily editable map; this map being small and exchangeable (by e-mail or svn). Con: the need to maintain this map; in fact, many of the corner cases will only be transferrable to this testmap once you know what to transfer, which is probably 90% of the investigation. What do you think? Well, I naturally assumed that this was caused by mkgmap doing something wrong but I'm not so sure now because I have been looking at the free nz mapset that is generated using cgpsmapper and that exhibits exactly the same behaviour as our maps do in this respect. They're built on the same reverse engineered information, aren't they? So, either the bug is in mapsource (and all Garmin GPS units?) or mkgmap and cgpsmapper are both getting it wrong in the same way. As said before (in the first A, B, C routing problem), my Garmin Nuvi will take routes that Mapsource won't. Also, the first problem had to do with three tiles, MapSource unwilling to route from tile A to tile C through tile B on a specific road. So we're not sure if it's Mapsource, mkgmap cpsmapper, or some subtle interaction between all three. V. -- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v2] - min arc length fixes
Mark, Sorry for the misunderstanding. Without looking, I assumed the SEVERE error had been introduced by your patch, while it was probably somewhere between r1127 and r1131 (not sure, did not look again). Without your patch, the same errors show up. However, experimenting a bit with the Fransiscusdreef I sent, I think I have a small, simple, reproducable (in MapSource that is, so no guarantees) routing problem where A to C goes wrong, while A to B, B to C and A to B via C go right. I thought you might be interested, the MapSource file is attached. This goes wrong both with and without your patch (but both of them were compiled *without* any remove-short-arcs options, so I guess there is a chance that the unpatched version *with* remove-short-arcs behaves totally different from the new version without any remove-short-arcs (as r-s-arcs is default now), right? Best regards, Valentijn Mark Burton schreef: The patch should actually reduce the number of short arcs. The remaining arcs that it is now complaining about were there already, the new patch hasn't created them, it's just now detecting them! -- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579 Fransicusdreef version 2.gdb Description: Binary data ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] mistake in options
Hi list, hello Steve, I made a mistake in my options file, thinking the overview-mapname made it to the Garmin screen (which is a bit stupid, now I think about it). Anyway, here's the revised options patch. Valentijn --- options 2009-08-12 11:09:48.0 +0200 +++ options.new 2009-08-13 14:00:30.0 +0200 @@ -140,11 +140,7 @@ --overview-mapname=name If --tdbfile is enabled, this gives the name of the overview - .img and .tdb files. The default map name is OSM_map. - On Garmin maps, this option describes the area of your - map, for example Germany_and_Belgium. - TODO: underscores seem to render as spaces, not sure if this - is mandatory. + .img and .tdb files. The default map name is OSM_map --overview-mapnumber=8 digit number If --tdbfile is enabled, this gives the internal 8 digit ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] mistake in options?
I found two strange things: - if you don't set --overview-mapname, the tdbfile will have the name of the overview-mapnumber, 6324.tdb, (instead of OSM_map). The source reads OSM_map, so I can't find where it goes wrong. - the --description option seems not to work, there must be something wrong with the getDescription method, as changing it to BLAH in the source code will work, but using a nice --description=Nederland shows a map with the description of OSM Map. I also couldn't find out what went wrong here. I did notice that most of the options have a args.get(option-name,default), while description seems to have its own args.getDescription(). I wouldn't know where the description of OSM Map comes from, though. V. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mistake in options?
Felix Hartmann schreef: it's --family-name that you want to use. See above example. Family name is the generic map family name. description should show up at the place where it says OSM Map, but it did not - so far. A hard coded description did, however. The source code just says: overallDescription = args.getDescription(); in src/uk/me/parabola/mkgmap/combiners/GmapsuppBuilder.java ... and I don't know why that doesn't work for me. Setting overallDescription = Something Else; // hard coded does work. series, family and description -- that's all three. So you're saying that description only works if you set family name? I can't see this in the source code, but I could be mistaken. Do you transfer directly the gmapsupp Yep. I'm a Linux user and MapSource will run happily under Wine, but I don't think the USB connection will work out (did try once, did not succeed, and I'm not too interested anyway). V. -- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] Better rounding in mkgmap
Hi Elrond, hello list, ... I did *not* yet test the patch, but, while biking around with a Garmin this morning, I realised that getting the rounding correct is an improvement, because your position is more precise. This could help in cases where a subtle rounding error will just put you on another road. You won't notice the difference as an end user, because there's many places where the choice of two parallel roads is difficult and any GPS unit will make some mistakes. My guess is that you could only see the difference when you would try to gather data on how many times you are on the right track and how many times you're 0.5 off... So if you ask me, better rounding is better and we should use anything that rounds better :) V. Clinton Gladstone schreef: Elrondelrond+openstreetmap@samba-tng.org wrote: incorrect is probably too hard (except for the very special case, where I needed the better rounding). suboptimal would be a better term. I tested your patch, and could see differences in the map. However, I could not really determine which would be more 'optimal'. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] ... and a success report
Steve Ratcliffe schreef: So was that with --remove-short-arcs=5.4 (or 5) in the end then? And have you done previous maps of the same area that didn't work without that option? No, this is a completely unrelated success report (hence the new message), and I did not try any other maps. It just seems to work, magically. That's how we want it, isn't it? (And it was done with ...rt-arcs=4) (And it was not thoroughly tested anyway). V. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v2] - min arc length fixes
Hi Mark, Mark Burton schreef: v2 of this patch not only enables remove-short-arcs by default when routing is in use (as previously discussed on ML) but it also fixes some problems in the way splitting code. I would be grateful if people could test this patch because it could possibly cure some routing failures. Fast check with the 29-07-09 14:32 a routing problem problem, with r1127 the problem is still there. Updated to revision 1131, used your patch which (unfortunately) doesn't solve the problem *and* now there's loads (well, 28 entries) of SEVERE (RoadNetwork): Road Kasteeltuin (OSM id 7003822) contains a bad arc of length 2,94m SEVERE (RoadNetwork): http://www.openstreetmap.org/?lat=52.02526lon=5.18550zoom=17 SEVERE (RoadNetwork): Road E 30 (OSM id 7004900) contains a bad arc of length 2,94m SEVERE (RoadNetwork): http://www.openstreetmap.org/?lat=52.09266lon=5.18550zoom=17 A couple of these are on the edge of a map, but this one for example does not: Road Franciscusdreef (OSM id 7066146) contains a bad arc of length 2,39m http://www.openstreetmap.org/?lat=52.11912lon=5.08551zoom=17 I did not check other routes. Please remember that the strange a,b,c routing problem showed up in Mapsource but did not in my Garmin. I didn't check my Garmin Nuvi here. Oh, and I don't know (so I can't test) any other routing problems now but I wouldn't call that a problem :-) :-) List follows below. Best regards, Valentijn Here is the list, abbreviated so it fits in a mail: Kasteeltuin (OSM id 7003822) bad arc of length 2,94m http://www.openstreetmap.org/?lat=52.02526lon=5.18550zoom=17 E 30 (OSM id 7004900) bad arc of length 2,94m http://www.openstreetmap.org/?lat=52.09266lon=5.18550zoom=17 Einsteindreef (OSM id 7059335) bad arc of length 2,80m http://www.openstreetmap.org/?lat=52.11912lon=5.11283zoom=17 Franciscusdreef (OSM id 7066146) bad arc of length 2,39m http://www.openstreetmap.org/?lat=52.11914lon=5.08564zoom=17 Franciscusdreef (OSM id 7066570) bad arc of length 2,39m http://www.openstreetmap.org/?lat=52.11912lon=5.08551zoom=17 Schonauwenseweg (OSM id 7096292) bad arc of length 1,47m http://www.openstreetmap.org/?lat=52.01011lon=5.18553zoom=17 Kanaaldijk Zuid (OSM id 7096366) bad arc of length 1,47m http://www.openstreetmap.org/?lat=52.00514lon=5.18555zoom=17 Schalkwijkseweg (OSM id 7096378) bad arc of length 2,80m http://www.openstreetmap.org/?lat=52.01011lon=5.18553zoom=17 null (OSM id 23086095) bad arc of length 2,80m http://www.openstreetmap.org/?lat=52.11914lon=5.04436zoom=17 null (OSM id 23086101) bad arc of length 3,78m http://www.openstreetmap.org/?lat=52.11914lon=5.04442zoom=17 N203 Provincialeweg (OSM id 6605992) bad arc of length 4,78m http://www.openstreetmap.org/?lat=52.47066lon=4.80536zoom=17 Staalhavenweg (OSM id 6632824) bad arc of length 2,39m http://www.openstreetmap.org/?lat=52.47070lon=4.62602zoom=17 Zwarte Pad (OSM id 7495148) bad arc of length 3,78m http://www.openstreetmap.org/?lat=52.11916lon=4.29286zoom=17 null (OSM id 30611242) bad arc of length 2,39m http://www.openstreetmap.org/?lat=52.11916lon=4.30825zoom=17 Vlotgrasweg (OSM id 6544034) bad arc of length 2,80m http://www.openstreetmap.org/?lat=52.47070lon=5.54116zoom=17 Lisdoddeweg (OSM id 6544035) bad arc of length 3,76m http://www.openstreetmap.org/?lat=52.47070lon=5.54123zoom=17 null (OSM id 6589537) bad arc of length 1,46m http://www.openstreetmap.org/?lat=52.43262lon=5.00979zoom=17 Prinsenweg (OSM id 6958461) bad arc of length 1,46m http://www.openstreetmap.org/?lat=52.20274lon=5.62500zoom=17 Hogeweg (OSM id 6965686) bad arc of length 1,46m http://www.openstreetmap.org/?lat=52.34878lon=5.62498zoom=17 Drieseweg (OSM id 6967746) bad arc of length 2,92m http://www.openstreetmap.org/?lat=52.25984lon=5.62500zoom=17 null (OSM id 7059063) bad arc of length 2,80m http://www.openstreetmap.org/?lat=52.11916lon=5.11821zoom=17 Neckardreef (OSM id 7059064) bad arc of length 3,78m http://www.openstreetmap.org/?lat=52.11916lon=5.11821zoom=17 Einsteindreef (OSM id 7059335) bad arc of length 2,80m http://www.openstreetmap.org/?lat=52.11914lon=5.11285zoom=17 Colombiadreef (OSM id 7059453) bad arc of length 3,78m http://www.openstreetmap.org/?lat=52.11916lon=5.09669zoom=17 Japuradreef (OSM id 7059454) bad arc of length 3,78m http://www.openstreetmap.org/?lat=52.11916lon=5.09669zoom=17 Valkenkamp (OSM id 7070206) bad arc of length 2,80m http://www.openstreetmap.org/?lat=52.14041lon=5.00977zoom=17 Valkenkamp (OSM id 7070266) bad arc of length 1,47m http://www.openstreetmap.org/?lat=52.14038lon=5.00979zoom=17 null (OSM id 29894188) bad arc of length 4,78m http://www.openstreetmap.org/?lat=52.47066lon=5.02457zoom=17 -- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v2] - min arc length fixes
Hi Mark, At Wed, Aug 12, 2009 at 09:19:36PM +0100, Mark Burton wrote: I can see where the problem is occuring. Wherever you have a node that is within the minimum arc length from a tile boundary you will get an error message. Your mail now sounds much less SEVERE than the error message :-) The question is: Is the routing actually broken at those locations? Will check. Tomorrow. V. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v2] - min arc length fixes
Mark, Again, a quick check, but I can't seem to route on the Fransiscusdreef: F'dreef to Vechtdijk sends me on a 1.2km odyssee :) Here's the data: 63240003: 0x24d000,0x34000 to 0x251000,0x3b000 63240008: 0x251000,0x25000 to 0x255000,0x39000 63240009: 0x251000,0x39000 to 0x255000,0x4 java -Xmx1600m -enableassertions -jar ~/garmintest/splitter/dist/splitter.jar --split-file=areas.list netherlands.osm I used: java -enableassertions -Xmx1800m -jar ~/garmintest/mkgmap/dist/mkgmap.jar --country-name=Nederland --country-abbr=NL --latin1 --lower-case --preserve-element-order --location-autofill=1 --gmapsupp --route --net --tdbfile -c template.args See attached gdb-file. For now, I'll stop testing, but if you want me to test anything else, please tell me so. Best regards, Valentijn Mark Burton schreef: So, I would like to know if those ways it is griping about are routable or not. If possible, please test a few to see if you can route over them. -- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579 Fransicusdreef.gdb Description: Binary data ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Rounding bug in splitter?
Chris Miller schreef: but my impression is that the conclusion was that the splitter should be rounding areas off to boundaries in multiples of 4096 rather than 2048? As far as I've seen - thanks to Steve Ratcliffe's findings - divisible by 2048 is enough, if you make sure that the difference is a multiple of 4096. (i.e. if your bounds are 0x123800 and 0x456800, that is OK; but 0x123800 and 0x456000 is not OK). Anyway, dividing by 4096 is a good method of achieving this. V. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Rounding bug in splitter?
Chris, to behave? My understanding is that it is taking the area passed in and rounding the edges *outwards* to the nearest multiple of 0x0800. Not _completely_ unrelated, I'm not sure if you know about this: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2009q3/002789.html As far as I know, this has not been implemented in Splitter due to it's recent discovery. But maybe I'm mistaken. Best regards, Valentijn -- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Garmin Nuvi asks province
Hi, A bit of a strange thing: my Garmin mkgmap maps ask the provincie (Province? State? County? Whatever you guys call it over there ;) when I want to route to an address. I normally build my map with country=Netherlands and country-abbr=NL, I also tried no country and abbrev, but it keeps asking for a Provincie. Whatever I enter, Garmin can't find it and this makes routing to an address pretty much infeasible. On the regular map, it just asks me if I'm in the Netherlands and then I can enter street and city names. java -enableassertions -Xmx1800m -jar ~/garmintest/mkgmap/dist/mkgmap.jar --country-name= --country-abbr= --family-name=Openstreetmap Netherlands `date -I` --latin1 --remove-short-arcs --lower-case --preserve-element-order --location-autofill=1 --gmapsupp --route --net --tdbfile -c template.args What am I doing wrong? I guess this is just a wrong option somewhere? Valentijn ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] vanishing map
Hey you incredible wizzard :) Seems you fixed it :) I cannot find any places where things go wrong now. Found a routing problem while looking though, but that was not induced by your patch (I reversed your patch it and it's still there). I'll send a report shortly. (Have your netherlands.osm ready for some splitting ;) So the patch works! Wonderful! V. Steve Ratcliffe schreef: Could everyone who is interested in this please try the attached patch. It seems to work on the example I was looking at, but of course problems may just have moved elsewhere so please check thing are OK more widely. It would be good to know if it makes a difference to inter tile routing as well. -- http://www.openoffice.nl/ Open Office - Linux Office Solutions Valentijn Sessink v.sess...@openoffice.nl +31(0)20-4214059 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] a routing problem
Hello list, The following inter tile routing gives nice and unexpected results. areas.list: 63240001: 0x241000,0x25000 to 0x24d000,0x3b000 63240002: 0x24d000,0x25000 to 0x251000,0x34000 63240003: 0x24d000,0x34000 to 0x251000,0x3b000 63240004: 0x241000,0x3b000 to 0x24b000,0x42000 63240005: 0x241000,0x42000 to 0x24b000,0x53000 63240006: 0x24b000,0x3b000 to 0x251000,0x41000 63240007: 0x24b000,0x41000 to 0x251000,0x53000 63240008: 0x251000,0x25000 to 0x255000,0x39000 63240009: 0x251000,0x39000 to 0x255000,0x4 63240010: 0x255000,0x25000 to 0x263000,0x4 63240011: 0x251000,0x4 to 0x259000,0x49000 63240012: 0x251000,0x49000 to 0x259000,0x53000 63240013: 0x259000,0x4 to 0x263000,0x48000 63240014: 0x259000,0x48000 to 0x263000,0x53000 (You don't need all areas, but I don't know a trivial way to know which map part is which split). Then run: java -Xmx1600m -enableassertions -jar ../splitter/dist/splitter.jar --split-file=areas.list netherlands.osm java -enableassertions -Xmx1800m -jar ~/garmintest/mkgmap/dist/mkgmap.jar --country-name=Nederland --country-abbr=NL --latin1 --remove-short-arcs --lower-case --preserve-element-order --location-autofill=1 --gmapsupp --route --net --tdbfile -c template.args Then load the attached tdb-file in MapSource.exe. You'll notice three waypoints, A, B and C, all three on a different tile, A and B being adjacent and B and C also. Mapsource will route from A to B, from B to C and from A to B via C, but it will not route from A to C. I don't have my Garmin Nüvi at hand, so I can't test it there - if you want me to, I'll be able to do that in the evening if you want me to. Best regards, Valentijn routing problem.gdb Description: Binary data ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] a routing problem
Valentijn Sessink schreef: The following inter tile routing gives nice and unexpected results. areas.list: You only need: 63240003: 0x24d000,0x34000 to 0x251000,0x3b000 63240008: 0x251000,0x25000 to 0x255000,0x39000 63240009: 0x251000,0x39000 to 0x255000,0x4 Just found out: the trivial way to know which map part is which split is using the Map button in the tool bar. It has an icon that vaguely resembles a Cubism sort of Pac Man (what if... Picasso would have been a game developer?) Also: trying to route back (just put points D, E and F on the opposite lane of the A2 highway) shows the same problems: routing from D to E and E to F is OK, but D to F fails. V. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] a routing problem
Mark, For me, routing to the Plutoniumweg doesn't work at all - but my Mapsource is older than yours, I could not read your Plutoniumweg.gdb (MapSource complains about the file being newer). Utrecht, we have a problem ;) I was thinking about trying to synchronize the vertical split line (i.e. have both maps split at 0x39000, just to make sure that's not the problem. Oh, btw: the reason I found this strange route is that a much longer inter-tile route, from my home in Zaandam to my parents in Houten, made a weird deviation half way (went off the A2 for no reason, somewhere above point A); also, a route to my wife's family in Culemborg could not be calculated at all. Just to be sure, I'll check my Nüvi this evening. Best regards, Valentijn Mark Burton schreef: What's really fascinating about your example is that mapsource will happily route from A to a point within the tile containing B passing right past point C. For example, route from A to the end of Plutoniumweg (damn it, why can't we have funky road names like that instead of the canonical Acacia Avenue!), but if you move the destination a little to the S so that it is in the lower tile, it fails to route - see attached gdb. It's almost as if having traversed B tile it then is happy to locate a destination in it but, for some reason, it's unhappy with a destination in C tile. -- http://www.openoffice.nl/ Open Office - Linux Office Solutions Valentijn Sessink v.sess...@openoffice.nl +31(0)20-4214059 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] a routing problem
Hi Mark, Mark Burton schreef: I am using the latest version (as downloaded by the check for software updates option on the help menu). I can't run a later version, I use the version for older operating systems, as that is what runs nicely under Linux under Wine. I could not get the Splendid New version to work. Oh well, it says that De MapSource versie 6.15.6.0 update is voor downloaden beschikbaar. But I'd really rather not try it, actually. I'll put the map in my Nüvi instead. I was thinking about trying to synchronize the vertical split line (i.e. have both maps split at 0x39000, just to make sure that's not the problem. Could be worth trying to see if it changes anything. Makes no difference (please note that 0003 is out of bounds but that doesn't matter as it is not used). 63240003: 0x24d000,0x34000 to 0x251000,0x39000 63240006: 0x24d000,0x39000 to 0x251000,0x41000 63240008: 0x251000,0x25000 to 0x255000,0x39000 63240009: 0x251000,0x39000 to 0x255000,0x4 Same routing for A, B and C. V. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] a routing problem
Hi Mark, I'm not sure if this is good or bad news, but the Nuvi works! Just to be sure, I'll check my Nüvi this evening. Please do, it would be useful to know if a real GPS has the same problem (my guess is that it will). It also works out of the box, routing perfectly, when I route from home to my parents (MapSource didn't do that correctly) and to my wife's family (where MapSource did not route at all). So this seems a MapSource issue with the map, not a generic mapping issue. I could check/doublecheck the MapSource settings (i.e. check if there's any caching, remove and reload the TDB file again etc etc). Will do that, but as my Nuvi works, it's not high on the list. And now for something completely different: I think the mailing list noticed some time ago that bike routing is a wholly different thing on the Garmin, right? I'm still getting weird results when I let the Nuvi route by bicycle - simple routes will have the weirdest deviations, letting you drive 35 kilometers where the regular Garmin map has a 14 kilometer route. Now this regular map has no knowledge of bicycle paths, so sometimes the routing is wrong because of that. Anyway, I'm pretty confident now that the routing by car is pretty much as expected. I will keep using my Garmin for reference testing, however, and tell my experiences here on the mailing list. Back to the original topic: if you want me to do anything on the weird route, please tell me so. Thanks for your great work again! Best regards, Valentijn ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] The .GMP subfile.
Hi Steve, I'm trying to find out why certain parts of the map blank and I did not get far. However, I'm noticing that the blanking issue seems not to depend on certain ways or nodes, nor does it depend on the size of the tiles. It seems a generic issue of a sub-map. Here your GMP file could come in. Maybe there's som subtle sort of caching going on, where the maps should only have a certain size of should only contain ... ? Having a container that can divide an area seems just the right way to do it, then. Best regards, Valentijn Steve Hosgood schreef: I just added info on the .GMP subfile that I discovered whilst dismantling an official Garmin .IMG file. It seems to be a container for the .TRE, .RGN, .LBL, .NET and .NOD files that handle a subtile of the area covered by the .IMG file itself. Not sure why they bother to do this... surely the individual files could just be just be present individually? [...] ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] vanishing map
Hello list, After a long search, here's the (lacking of) results. Eventually, I found a single node on the map that would stop the map from blanking. However, when I made the map just be a tiny bit larger, it would vanish again - with or without the node. So the blanking is probably the result of a subtle interaction between (sub)map element count and tile position. Or something like it. Or something completely different. Best regards, Valentijn ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] trying to pin down missing tooltips
Hello List, I'm still trying to pin down the missing tooltips/blanking map issue. Here's what I managed to find so far. But now I'm sort of stuck. I have a map that has the problem. Decreasing or increasing the map boundaries would lose the problem. So instead I tried to find out if there is certain data on the map that will trigger the problem, by going through it with Splitter, then after running Splitter I would restore the map size to the original boundaries. This will give you a partially empty map, that will or will not have problems at the lower boundary. At this moment, there's a single digit that will trigger the error: Having (hexadecimal) 251000,25000 252280,33dbc (with map size artificially restored to 251000,25000,255000,39000) will show all right at the bottom; 251000,25000 252280,33dbd (map size restored as well) will blank when you zoom into the bottom part. These maps differ by about 55 nodes and 15 ways, which is still a bit too much to go over by hand. Does anyone have an idea about the next step? Would you like to get the resulting osm map? (It's 1.1M large, I shal put it up for download somewhere if someone is interested). Attached is the script I ran, it's crude and silly and the texts are in a strange language for most of you, but you get the idea of what I did. The 0x251000 - 0x252280 latitude is derived from a previous run of the script where I would change latitude instead of longitude. If it is silly or plain stupid what I'm doing, please say so. I'm not entirely sure anymore that this random grepping of data does any good (while the only thing I was trying is to get the map to show at boundaries on high zooming levels). Also, as a side note, (and to complicate things) I'm seeing a ghost road pop up at about 3.6663 lon 52.119140625 lat. It's a straight line that runs down the boundary of the map, i.e. the road is larger than the map boundary! As it is not 180 degrees down but a bit tilted, it is *not* a longitude line. The line disappears when you zoom out, or go up or down in the map. It shows up in maps that work (i.e. do not blank); when the map blanks, I cannot find the line anywhere (i.e. probably the line itself blanks out and when zoom level is lower so that the map is not blanked, it's also too low to show this ghost road). Any ideas appreciated. Best regards, Valentijn testscript2.sh Description: Bourne shell script ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] routing and cycleway=track
Mark Burton schreef: if(currentWay.getTag(bicycle) == null) currentWay.addTag(bicycle, no); so that if the original way doesn't already have the bicycle routing defined, it will be disallowed. In the Netherlands that would be right, too: the bicycle-paths are mandatory. My feeling is that the above code would generally be a good idea. Best regards, Valentijn ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] splitter: small patch and wishlist
Hello list,
A small wish list for splitter:
- honour action='deleted' in the input file. Rather trivial to write,
but I don't send a patch because you would be horrified by my code.
- make it possible to use hex data in areas.list (trivial patch, see below).
Best regards,
Valentijn
Index: AreaList.java
===
--- AreaList.java (revision 37)
+++ AreaList.java (working copy)
@@ -97,8 +97,8 @@
ListSubArea list = new ArrayListSubArea();
Pattern pattern = Pattern.compile(([0-9]{8}): +
- ([\\p{Digit}-]+),([\\p{Digit}-]+) +
- to ([\\p{Digit}-]+),([\\p{Digit}-]+));
+ ([\\p{XDigit}x-]+),([\\p{XDigit}x-]+) +
+ to ([\\p{XDigit}x-]+),([\\p{XDigit}x-]+));
try {
r = new FileReader(filename);
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v3] - fix clipping when node falls on tile boundary
Mark Burton schreef: OK, so it's proving to be a little harder to fix than I thought but I have high hopes for this version. BTW - Valentijn, this version could help routing through the tunnel. Yes! Yes! Also, V1 and V2 had a couple of these ... contains 0 arc, and this version does not show any of these (checking patch if the code is still there... it is). Thanks! And thanks to Maning, who gave a better analysis than I did! Best regards, Valentijn -- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problems at map intersections?
Mark Burton schreef: OK - I have looked at your example and can confirm there is a problem in that mapsource doesn't display the region near the tile boundary, it has a gap of 200m or so. Don't know whether this is just mapsource being it's usual crap self, or the problem also exists on the gps. It will route through the tunnel (as the attached picture shows) but Yes, I noticed that - but could not reproduce it yesterday. Please notice however, that the route you found has both starting points at the lower map. That may or may not have anything to do with it. Your picture also shows that the upper map vanishes (which you confirmed already). Now, this may be because mapsource thinks that using the tunnel and then looping back to the S again is not a good route so it decides you're better off going to the E. If that's the case, I don't think there is anything we can do about it. If you could recheck with a map without the split, you'll see that routing through the tunnel is no problem at all. Just download some surroundings of the tunnel and build a map to try it. Valentijn -- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problems at map intersections?
Steve Ratcliffe schreef: So you will probably also find that in the area that disapears, if you hover over a road you do not also get the usual pop-up that tells you the name of the road. Yes, but actually I blamed Wine instead of you ;-) (I feel I actually can safely blame whoever I want, being in an unroutable part of the world - if you come to get me by bike, that is ;-) But now you mention the pop-up, did you notice that the pop-ups work just above (so within) the (shifted, see previous post) bounds of a map and when you hover outside the (grey lined) bounds, they immediately don't work? And that they do start to work again some 250 meters below the actual split and *that* is again the precise point where the map will not vanish anymore? So for the lower part of the split: the part of the map that will always show, is also the part of the map that has these pop-ups again. Since you know what you're talking about: is there a discussion, explanation or otherwise for the reason that you did not let the maps overlap? An overlap of 300 meters sounds like a good idea for the routing - but as said before, I'm saying this from a position of blessful ignorance. Best regards, Valentijn -- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579 -- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problems at map intersections?
Hi all, I tried to line up Splitter with the map boundaries; instead of having (hexadecimal showing) 63240008: 251000,25800 254800,38800, I had to use 63240008: XX,X 254c00,X). Now the tool tips would not show up in the +-250 meters around the boundary. Then I used: 63240008: 251000,25800 254c80,38800 63240010: 254b80,25800 262800,4 ... now the tool tips show *and* the map does not disappear anymore around the boundary. But - as Mark predicted - now inter tile routing does not work anymore. Just another idea: could be possible to line up the boundary nodes, then add some surroundings to have an extra overlap, right? Like so (ascii art alert) (maps below should be joined horizontally, not vertically) map 1--+-- 1 11 1 1B 1 1 11 B1 ---+-- --+map 2--- 2 2 B 2 22 B2 --+--- (It you can't, for any reason, please feel free to ignore my mail - as we say here: a fool can ask more questions than 100 wise man could answer) Best regards, Valentijn -- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problems at map intersections?
Steve Ratcliffe schreef: 0010: 52.470703,3.339844 53.701172,5.668945 0008: 52.163086,3.339844 52.470703,5.009766 So top matches bottom, but not the same as the bounds. This could explain mapsource, but as it is not used on the device can't explain the problem in the GPS. In fact, I think it's two related, but different, problems: 1) the overview map is out of sync with the actual bounds. Please see my e-mail about a splitting area that will have these synchronised (*); it's a sort of rounding issue, as far as I understand. 2) the fact that, around a map split, some things do not work as they work on the rest of the map. An overlapping map helps here - and you wizards will probably know if it's possible to have a map overlap and still have the routing nodes in place. [...] So the conclusion is that the definition areas in the overview map are wrong. This would explain problems in mapsource, but not on the device. Yes, that's what I think, too. [...] Best regards, Valentijn (*) Use splitter with: 63240008: 2428928,153600 to 2444288,231424 63240010: 2444288,153600 to 2500608,262144 Please note that 2444288 is the only number I changed, the other corners aren't lined up, but since we only use 2 maps here, 2444288 is the only number that is at a map intersection. -- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problems at map intersections?
Hello list, I'm having a great time corresponding to myself here :) but these are my observations so far. Running Splitter, then Mkgmap.jar, then MapSetToolKit.exe, then Mapsource, the resulting submaps are shifted from their bounding box: they are about 2.4 kilometers left, up, from the map itself. (So you have a bounding box that does not bound the map). The resulting submaps have no overlap now, which results in strange behaviour around the edges of the map: 1) It looks like sometimes Mapsource doesn't know how to get to the other map - a sort of short-arc between maps; it will refuse to take certain ways and will stubbornly route you around something, even if it's a trivial, 50 meters route on the map. 2) Also, sometimes Mapsource (and my Garmin Nuvi) seem to choose the wrong submap to display data from - resulting in a blank screen instead of mapping information. This is best seen at high zooming levels. Now I tried to get around this. If I use splitter to output a header of writer.append(String.valueOf(Utils.toDegrees(extendedBounds.getMinLat(; instead of the regular bounds.getMinLat(), I'm getting better results - the maps now overlap. I decreased the bounds size in addToOverviewMap in mkgmap. But is probably not be the correct way, as the bounding box still seems a bit off - I'm guessing that now the map itself grows, which will only work as long as the result will round down to a value within the map itself? If I'm unlucky, the new bounding box will - again - be larger than the map? If I knew Java, I would try to get Splitter to output something like Utils.toDegrees(bounds.getMinLat() + (extra / 2)), but as I don't know enough about scope of variables, I will leave that to more knowledgeable people. And maybe it's a stupid idea after all. I'll stop hacking around in unknown code now and have a beer, but my feeling is that 1) something should be done about the bounds in the overview map 2) I'm guessing that Garmin wants some overlap in submaps, so it can choose from what file to display the data from. Maybe 1 and 2 are the same problem (i.e. if the bounds are right, the choice of map will be right as well). I realise that I should have tried to hack an area.list with overlap, then use --split-file=areas.list, which is easier than randomly hacking around the source. Anyway. Maybe someone with knowledge of Mkgmap could say something about it? Best regards, Valentijn -- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problems at map intersections?
Hi Mark, Mark Burton schreef: I believe (because the ML is not showered with emails complaining about it failing) that inter-tile routing is generally working OK. It really does work great. In fact, it took me quite a while to come to the conclusion that the map edge seemed to be involved and that there might be a routing problem after all. At first I thought it was the tagging of tunnel, the fact that I tried to send a bike through a tunnel, the fact that I chose a bicycle for routing at all (Garmin doesn't do a really good job there - or maybe they like biking so much that they send you for 30 kilometer trips when 11 could do). But a few days ago I noticed that the map dissapeared at the same spot where the routing went wrong when I biked around with my Garmin Nuvi. Oh, and yes: I really think there aren't enough people riding around on their bicycles at OSM/splitter map edges, while looking at their Garmin Nuvis loaded with Openstreetmap-data in Driving Direction Up (i.e. non-3D), Highest Detail, Highest zoom mode. I really should start a support group ;-) Please provide an example of it failing so we can study it. memory=1700m maxn=50 wget 'http://download.geofabrik.de/osm/europe/netherlands.osm.bz2' bzcat netherlands.osm.bz2 netherlands.osm wget 'http://www.mkgmap.org.uk/snapshots/mkgmap-latest.tar.gz' tar -zxf mkgmap-latest.tar.gz wget 'http://www.mkgmap.org.uk/splitter/splitter.jar' java -Xmx$memory -jar ./splitter.jar --max-nodes=$maxn netherlands.osm java -enableassertions -Xmx$memory -jar mkgmap*/mkgmap.jar \ --country-name=Nederland --country-abbr=NL --latin1 \ --remove-short-arcs --lower-case --route --preserve-element-order \ --location-autofill-1 --gmapsupp --net 63240008.osm.gz 63240010.osm.gz Then load the resulting map in MapSource; to be sure, select Edit-Preferences-Routing, Bicycle, shortest distance. (Set detail to Highest if you want to see the biking path). Then route from N52.42701 E4.82707 to N52.42625 E4.82736, they are on the same biking path, some 80 metres apart. You'll see the route deviate 3 kilometers. Also, if you try to zoom on one of the points above, you'll see a blank map. (This is Mapsource 6.11.5 running under Wine, but as said before: my Garmin Nuvi does the same - only on highest zooming level though, and only around the edges on the OSM map - it does not do that on the Garmin native map - I did check that). I hope you can reproduce my findings - that would be a help. Thanks so far, best regards, Valentijn -- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] problems at map intersections?
Hello list, When trying to use a built map, I'm getting a bit odd results around the edges of tiles - at least, I think it's the edges. It's not exactly on the boundaries, but about 2.5 kilometers below the grey lines that show up in Mapsource (I assume these are the tiles). But strangely, the Splitter arealist has other numbers than Mapsource tells me. You can see tiny interconnections where the roads meet on the tiles; on the highest zoom levels, parts of the map start to dissapear. For example: wget 'http://download.geofabrik.de/osm/europe/netherlands.osm.bz2' bzcat netherlands.osm.bz2 netherlands.osm Then use Splitter: java -Xmx1700m -jar ./splitter.jar --max-nodes=50 --overlap=8000 netherlands.osm It produced the following list of areas (you may want to test with this list instead of the automated --max-nodes) 63240001: 2363392,153600 to 2412544,239616 63240002: 2412544,153600 to 2428928,212992 63240003: 2412544,212992 to 2428928,239616 63240004: 2363392,239616 to 2402304,268288 63240005: 2363392,268288 to 2402304,337920 63240006: 2402304,239616 to 2428928,266240 63240007: 2402304,266240 to 2428928,337920 63240008: 2428928,153600 to 2443264,231424 63240009: 2428928,231424 to 2443264,262144 63240010: 2443264,153600 to 2500608,262144 63240011: 2428928,262144 to 2459648,296960 63240012: 2428928,296960 to 2459648,337920 63240013: 2459648,262144 to 2500608,294912 63240014: 2459648,294912 to 2500608,337920 (Splitter says, for example, that it splits 2428928,153600 to 2443264,231424, which would be 52.119141,3.295898 to 52.426758,4.965820, but Mapsource shows a grey line around 52.07145) Anyway: when you load the resulting map into Mapsource and go to 52.07149/5.02083 (or 52.07149/anywhere ), you'll notice small interconnection traces on the more important roads (N230 and A2 in this example), but from zoom level 50 meters and higher, parts of the map will disappear. And if you experiment a bit, you'll notice that the map will vanish at even lower zoom levels. For example - see attached lower part of Mapsource. java -enableassertions -Xmx1700m -jar mkgmap-r1087/mkgmap.jar --country-name=Nederland --country-abbr=NL --latin1 --remove-short-arcs --lower-case --preserve-element-order --location-autofill-1 --tdbfile -c template.args (I removed the routing information that I usually include, just to make sure it's not a routing issue) (And as you can see, I learned from my mistakes and used -enableassertions for map making). The 52.07149 is an example, the same thing happens around 52.25606 (another 2.5 kilometers below a tile). You can see the problem best at locations that are busy with roads and stuff; also, having a main road (a thick one) nearby helps. I was wondering if it has anything to do with areas that are cut of at the edge, but that's pure guessing. My Gærmïn Nüvï also has problems with these sites, refusing to route and/or not showing the map at the lowest zoom levels. If I can do anything to test, please say so. Best regards, Valentijn inline: mapsource.jpg___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Fwd: OpenStreetMap e-mail - mkgmap bug report
Hi Mark, (Let me introduce myself: hi, I'm the original problem submitter :) Mark Burton schreef: Well, that's a bit odd. If you download this area into JOSM, it looks similar(ish) but by no means exactly the same. Yep, that's what I did last night: open just the area around the problem site and it shows like it should in my Garmin. And what's more: running splitter like in my script, then just building a map of the isolated map number 1 produces the same results, while JOSM shows the correct map. The A27 highway in this area also disconnects. I did not picture this fact, but on my garmin, there's a gap in the bridge. But now, after more checking, we have a winner! Using the same OSM file, with --routing enabled will produce a map with gaps; having --routing disabled will show a map with correctly connected ways. So the right map is produced with: java -Xmx$memory -jar mkgmap*/mkgmap.jar --country-name=Nederland --country-abbr=NL --latin1 --lower-case --preserve-element-order --location-autofill-1 --gmapsupp --net 1001.osm.gz And the wrong map is produced by: java -Xmx$memory -jar mkgmap*/mkgmap.jar --country-name=Nederland --country-abbr=NL --latin1 --lower-case --route --preserve-element-order --location-autofill-1 --gmapsupp --net 1001.osm.gz Gentlemen, start your engines! (You won't know where to route, but do we care? ;) If you're interested in the OSM file I'm using, I could mail it to you, but you could also easily build it yourself: wget 'http://download.geofabrik.de/osm/europe/netherlands.osm.bz2' bunzip2 netherlands.osm.bz2 java -Xmx$memory -jar $SPLITTERPATH/splitter.jar --max-nodes=100 \ mapid=1000 netherlands.osm Then use 1001.osm.gz to build your map. Best regards, Valentijn -- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579 -- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Fwd: OpenStreetMap e-mail - mkgmap bug report
Clarification: Valentijn Sessink schreef: running splitter like in my script, then just building a map of the isolated map number 1 produces the same results ... produces a wrong map is what I meant to say. Valentijn ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Fwd: OpenStreetMap e-mail - mkgmap bug report
Mark, Mark Burton schreef: I grabbed the source as you suggested but could not successfully create a map when the splitter had max-nodes = 100. One of the tiles failed in mkgmap (exception - NET1 offset too big, I think). Shame on me. Yes, the offset too large was just what I encountered 5 minutes ago and I was going to write a new mail... Sorry for the confusion, this seems to be the very problem. I promise to never again turn assertions off. [...] Can you load your broken map into mapsource and see if it is also broken there? I did that, and broken on Garmin means broken in Mapsource, so your checking was good. Thanks for your help and sorry for the confusion. Valentijn ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
