[mkgmap-dev] Errors details needed
Hello, Is anybody able to understand, explain and maybe give a guideline for correction of these 3 errors occurring during Italian Map compiling? GRAVE (Polyline): 66923040.osm.gz: Problem writing line (class uk.me.parabola.imgfmt.app.trergn.Polyline) of type 0x1e containing 2 points and starting at http://www.openstreetmap.org/?mlat=40.73263mlon=10.02642zoom=17 GRAVE (Polyline): 66923040.osm.gz: Subdivision shift is 0 and its centre is at http://www.openstreetmap.org/?mlat=40.80872mlon=8.94656zoom=17 GRAVE (Polyline): 66923040.osm.gz: deltaLong = 50325 Ciao, Marco.___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] R: [PATCH v1] - fix Table C size bug + allow Table B to contain up to 255 entries
Hi Mark, I've tested the patch on today's geofabrick extract of Italy. It seems to work! Great. I've tested the produced img on mapsource and nuvi255 and both works fine. Let me thank you for your work on this ancient bug. Rome thanks you too... Ciao, Marco. --- Mer 10/2/10, Mark Burton ma...@ordern.com ha scritto: Da: Mark Burton ma...@ordern.com Oggetto: [mkgmap-dev] [PATCH v1] - fix Table C size bug + allow Table B to contain up to 255 entries A: mkgmap-dev@lists.mkgmap.org.uk Data: Mercoledì 10 febbraio 2010, 01:37 Hopefully, this patch will fix Marco's routing problem in Rome. The bug is ancient (almost as old as Rome) but it hasn't shown itself much before now because it only causes a problem when one of the routing tables gets to a certain size which only occurs when there are quite a few turn restrictions within a small area. The patch also contains a mod to allow another of the routing tables to grow larger than it does now. Please could as many people as possible test this patch to check that routing doesn't bomb when using mapsource or a Nuvi in city areas with lots of roads and turn restrictions. Mark -Segue allegato- ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Bad routing error here in Rome...
Hello, Mark is trying to reproduce the error I got on my PC but He couldn't so far. I'm now trying to rebuild img on another PC. I'll let you know about my new tests as soon as I have news. Ciao, Marco. --- Lun 8/2/10, Lambertus o...@na1400.info ha scritto: Da: Lambertus o...@na1400.info Oggetto: Re: [mkgmap-dev] Bad routing error here in Rome... A: Development list for mkgmap mkgmap-dev@lists.mkgmap.org.uk Data: Lunedì 8 febbraio 2010, 10:27 Just fyi: I've also received questions about bad routing errors in MapSource after my latest update as well. I'm asking for additional information in order to make them reproducible. Mkgmap is latest snapshot from last Thursday, splitter is latest (afaik r105). I'll report back later. Marco Certelli wrote: Hello. I'll re-test the situation every week. Compiled italy.osm.bz2 from download.geofabrik.de 1) latest mkgmap + latest splitter: Routing Error in Mapsource and Nuvi 255 2) mkgmap 1188 + oldest splitter (51kB): No Error in Mapsource and No error in Nuvi 255 Ciao, Marco. --- Dom 31/1/10, Marco Certelli marco_certe...@yahoo.it ha scritto: Da: Marco Certelli marco_certe...@yahoo.it Oggetto: Re: [mkgmap-dev] Bad routing error here in Rome... A: Development list for mkgmap mkgmap-dev@lists.mkgmap.org.uk Data: Domenica 31 gennaio 2010, 16:43 Hi Mark. No way. I reduced maxnode to 50 (Italy is splitted in 42 tiles) I tested latest splitter and latest mkgmap: exactly same error as before in mapsource routing. Ciao, Marco. --- Sab 30/1/10, Mark Burton ma...@ordern.com ha scritto: Da: Mark Burton ma...@ordern.com Oggetto: Re: [mkgmap-dev] Bad routing error here in Rome... A: mkgmap-dev@lists.mkgmap.org.uk Data: Sabato 30 gennaio 2010, 17:00 Hi Marco, Here is the part of the cmd script doing the actual job: java -enableassertions -Xmx1000m -jar ..\bin\splitter.jar --mapid=66%FID%001 --max-nodes=100 ..\OSM-Data\%osmfile% java -enableassertions -Xmx1000m -jar ..\bin\mkgmap.jar --code-page=1252 --country-name=%country% --latin1 --family-id=%FID% --mapname=66%FID%001 --overview-mapname=66%FID%000 --tdbfile --series-name=OSM-%country% --family-name=OpenStreetMap: %country% --road-name-pois --add-pois-to-areas --no-poi-address --ignore-maxspeeds --remove-short-arcs --preserve-element-order --style-file=..\bin\resources\styles\ --style=%style% --description=%country% --route --net --gmapsupp -c template.args OK - thanks. Have you tried using smaller tile sizes? i.e. does the same problem exist if you use, say, 50 for max nodes? Also, does the map show any other problems in that area apart from routing not working? Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Bad routing error here in Rome...
--- Lun 8/2/10, Johann Gail johann.g...@gmx.de ha scritto: Da: Johann Gail johann.g...@gmx.de Oggetto: Re: [mkgmap-dev] Bad routing error here in Rome... A: Development list for mkgmap mkgmap-dev@lists.mkgmap.org.uk Data: Lunedì 8 febbraio 2010, 20:00 Have you tried compile a map with the default style files? Hi Jonas. Yes I did, with the same result. Anyway Mark has been able to reproduce the issue on WinXP and he told me he is working on it. Ciao, Marco. Regards, Johann Marco Certelli schrieb: Hello, Mark is trying to reproduce the error I got on my PC but He couldn't so far. I'm now trying to rebuild img on another PC. I'll let you know about my new tests as soon as I have news. Ciao, Marco. --- Lun 8/2/10, Lambertus o...@na1400.info ha scritto: Da: Lambertus o...@na1400.info Oggetto: Re: [mkgmap-dev] Bad routing error here in Rome... A: Development list for mkgmap mkgmap-dev@lists.mkgmap.org.uk Data: Lunedì 8 febbraio 2010, 10:27 Just fyi: I've also received questions about bad routing errors in MapSource after my latest update as well. I'm asking for additional information in order to make them reproducible. Mkgmap is latest snapshot from last Thursday, splitter is latest (afaik r105). I'll report back later. Marco Certelli wrote: Hello. I'll re-test the situation every week. Compiled italy.osm.bz2 from download.geofabrik.de 1) latest mkgmap + latest splitter: Routing Error in Mapsource and Nuvi 255 2) mkgmap 1188 + oldest splitter (51kB): No Error in Mapsource and No error in Nuvi 255 Ciao, Marco. --- Dom 31/1/10, Marco Certelli marco_certe...@yahoo.it ha scritto: Da: Marco Certelli marco_certe...@yahoo.it Oggetto: Re: [mkgmap-dev] Bad routing error here in Rome... A: Development list for mkgmap mkgmap-dev@lists.mkgmap.org.uk Data: Domenica 31 gennaio 2010, 16:43 Hi Mark. No way. I reduced maxnode to 50 (Italy is splitted in 42 tiles) I tested latest splitter and latest mkgmap: exactly same error as before in mapsource routing. Ciao, Marco. --- Sab 30/1/10, Mark Burton ma...@ordern.com ha scritto: Da: Mark Burton ma...@ordern.com Oggetto: Re: [mkgmap-dev] Bad routing error here in Rome... A: mkgmap-dev@lists.mkgmap.org.uk Data: Sabato 30 gennaio 2010, 17:00 Hi Marco, Here is the part of the cmd script doing the actual job: java -enableassertions -Xmx1000m -jar ..\bin\splitter.jar --mapid=66%FID%001 --max-nodes=100 ..\OSM-Data\%osmfile% java -enableassertions -Xmx1000m -jar ..\bin\mkgmap.jar --code-page=1252 --country-name=%country% --latin1 --family-id=%FID% --mapname=66%FID%001 --overview-mapname=66%FID%000 --tdbfile --series-name=OSM-%country% --family-name=OpenStreetMap: %country% --road-name-pois --add-pois-to-areas --no-poi-address --ignore-maxspeeds --remove-short-arcs --preserve-element-order --style-file=..\bin\resources\styles\ --style=%style% --description=%country% --route --net --gmapsupp -c template.args OK - thanks. Have you tried using smaller tile sizes? i.e. does the same problem exist if you use, say, 50 for max nodes? Also, does the map show any other problems in that area apart from routing not working? Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev . ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Bad routing error here in Rome...
Hello. I'll re-test the situation every week. Compiled italy.osm.bz2 from download.geofabrik.de 1) latest mkgmap + latest splitter: Routing Error in Mapsource and Nuvi 255 2) mkgmap 1188 + oldest splitter (51kB): No Error in Mapsource and No error in Nuvi 255 Ciao, Marco. --- Dom 31/1/10, Marco Certelli marco_certe...@yahoo.it ha scritto: Da: Marco Certelli marco_certe...@yahoo.it Oggetto: Re: [mkgmap-dev] Bad routing error here in Rome... A: Development list for mkgmap mkgmap-dev@lists.mkgmap.org.uk Data: Domenica 31 gennaio 2010, 16:43 Hi Mark. No way. I reduced maxnode to 50 (Italy is splitted in 42 tiles) I tested latest splitter and latest mkgmap: exactly same error as before in mapsource routing. Ciao, Marco. --- Sab 30/1/10, Mark Burton ma...@ordern.com ha scritto: Da: Mark Burton ma...@ordern.com Oggetto: Re: [mkgmap-dev] Bad routing error here in Rome... A: mkgmap-dev@lists.mkgmap.org.uk Data: Sabato 30 gennaio 2010, 17:00 Hi Marco, Here is the part of the cmd script doing the actual job: java -enableassertions -Xmx1000m -jar ..\bin\splitter.jar --mapid=66%FID%001 --max-nodes=100 ..\OSM-Data\%osmfile% java -enableassertions -Xmx1000m -jar ..\bin\mkgmap.jar --code-page=1252 --country-name=%country% --latin1 --family-id=%FID% --mapname=66%FID%001 --overview-mapname=66%FID%000 --tdbfile --series-name=OSM-%country% --family-name=OpenStreetMap: %country% --road-name-pois --add-pois-to-areas --no-poi-address --ignore-maxspeeds --remove-short-arcs --preserve-element-order --style-file=..\bin\resources\styles\ --style=%style% --description=%country% --route --net --gmapsupp -c template.args OK - thanks. Have you tried using smaller tile sizes? i.e. does the same problem exist if you use, say, 50 for max nodes? Also, does the map show any other problems in that area apart from routing not working? Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Bad routing error here in Rome...
Mark, I can confirm the problem in mapsource with today's data and mkgmap/splitter versions (see also my latest post for other details). I can send you a snapshot with the mapsource error. Let me know what can I try more (your style, etc.), or if you want me to send you my data/style/results etc. Ciao, Marco. --- Dom 7/2/10, Mark Burton ma...@ordern.com ha scritto: Da: Mark Burton ma...@ordern.com Oggetto: Re: [mkgmap-dev] Bad routing error here in Rome... A: mkgmap-dev@lists.mkgmap.org.uk Data: Domenica 7 febbraio 2010, 16:00 Marco, I now have a map of Italy in mapsource. Rome is all contained within a single tile. I have tried lots of routes within that tile without any problems. I shall also try the map on a Nuvi. For your information, here's the mkgmap options I used: java -Xmx2000m -Dlog.config=/home/markb/OSM/logging.properties -ea -jar /home/markb/OSM/mkgmap.jar --adjust-turn-headings --country-abbr=GBR --country-name=GBR --check-roundabouts --check-roundabout-flares --description=A fine map --draw-priority=28 --family-id=909 --family-name=Burto Maps --gmapsupp --generate-sea=polygons,no-sea-sectors,close-gaps=2000 --ignore-maxspeeds --index --link-pois-to-ways --make-all-cycleways --max-jobs=1 --nsis --product-id=6324 --region-abbr=UK --remove-bogus-nodes --report-dead-ends=2 --region-name=UK --route --remove-short-arcs --series-name=OSM map --style-file=/home/markb/OSM/mkgmap-burto-style --style=marine --tdbfile -c template.args /home/markb/OSM/M38d.TYP I'll let you know how the Nuvi copes with the map... Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Bad routing error here in Rome...
Well, now the routing issue seems more systematic. Starting from italy.osm.bz2 from geofabrick... A) using latest splitter 105, compiling with latest mkgmap 1537 - trying a route in Rome, you got an error in mapsource. B) using latest splitter 105, compiling with mkgmap 1187 - trying a route in Rome, mapsource routing works. - loaded gmapsupp.img in nuvi255: nuvi says UNABLE TO FIND A ROUTE C) using oldest splitter (ver ?, .jar is 51 kbyte), compiling with mkgmap 1187 - trying a route in Rome, mapsource routing works. - loaded gmapsupp.img in nuvi255: nuvi routing works. This issue is more or less the same since months. There should be some osm data in Rome that makes splitter/mkgmap making this bad error. I've not been able to reduce the osm file and reproduce the same issue on a smaller map. Ciao, Marco. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Bad routing error here in Rome...
--- Sab 30/1/10, Mark Burton ma...@ordern.com ha scritto: Da: Mark Burton ma...@ordern.com Oggetto: Re: [mkgmap-dev] Bad routing error here in Rome... A: mkgmap-dev@lists.mkgmap.org.uk Data: Sabato 30 gennaio 2010, 14:25 Hello Marco, Please confirm that you are enabling assertions in both the splitter and mkgmap. Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev Ciao Mark. Here is the part of the cmd script doing the actual job: java -enableassertions -Xmx1000m -jar ..\bin\splitter.jar --mapid=66%FID%001 --max-nodes=100 ..\OSM-Data\%osmfile% java -enableassertions -Xmx1000m -jar ..\bin\mkgmap.jar --code-page=1252 --country-name=%country% --latin1 --family-id=%FID% --mapname=66%FID%001 --overview-mapname=66%FID%000 --tdbfile --series-name=OSM-%country% --family-name=OpenStreetMap: %country% --road-name-pois --add-pois-to-areas --no-poi-address --ignore-maxspeeds --remove-short-arcs --preserve-element-order --style-file=..\bin\resources\styles\ --style=%style% --description=%country% --route --net --gmapsupp -c template.args Ciao, Marco. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Routing Errors: mapsource fails to find a route
Hello. It's some months I noticed a problem. Very often building Italy and using lates splitter (97..103) and lates mkgmap (varies) the map has some routing problem. In fact trying complex routes (example: from a side of Rome to the other), mapsource is sometimes unable to find the route and stops with an error. If I take the same italy OSM data file and I split with the very old splitter (I do not know the version, it's the 51 Kbyte jar). The problem does not appear. It is not related to style (my stile and default presents the same issue). This is the command line I use (part of a cmd script on Windows XP): ... java -enableassertions -Xmx1000m -jar ..\bin\splitter.jar --mapid=66%FID%001 --max-nodes=100 ..\OSM-Data\%osmfile% java -enableassertions -Xmx1000m -jar ..\bin\mkgmap.jar --code-page=1252 --country-name=%country% --latin1 --family-id=%FID% --mapname=66%FID%001 --overview-mapname=66%FID%000 --tdbfile --series-name=OSM-%country% --family-name=OpenStreetMap: %country% --road-name-pois --add-pois-to-areas --no-poi-address --ignore-maxspeeds --remove-short-arcs --preserve-element-order --style-file=..\bin\resources\styles\ --style=%style% --description=%country% --route --net --gmapsupp -c template.args ... Is is a known problem? Ciao, Marco. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Possible maxspeed patch
Hello, as I said some months ago, deciding the right speed to set in the garmin map for each way shoud be a new mkgmap function. The function should take into consideration: the assigned OSM highway tag the assigned OSM maxspeed the number of crosses per km (maybe the number of routing nodes / lenght) the number of traffic_lights per km the curves ((for each node, add the angle) / lenght)) All these info shoud be properly combined to tell how fast a vehicle can run on that road. We should experiment a lot... But maybe this is too far away ;-) Ciao, Marco. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] R: Progressing patches
--- Lun 17/8/09, Mark Burton ma...@ordern.com ha scritto: Da: Mark Burton ma...@ordern.com Oggetto: Re: [mkgmap-dev] R: Progressing patches A: mkgmap-dev@lists.mkgmap.org.uk Data: Lunedì 17 agosto 2009, 11:28 Hi Marco, Hi Mark, I did not follow very well last discussions. I agree in enabling remove-short-arcs by default, but with no min length (i.e. min lenght=0). Could you please explain why arcs shorter than 5m should be collapsed? Arc lengths appear to be encoded in units of 16 feet. That is equal to approx 4.8m. i.e. an arc that is less than 4.8m is encoded as length 0. So if we want all arcs to have a non-zero length, they must be at least 4.8 metres, rounding up to an integer gives 5m. Very strange about the 16 feet units. As far as I kew garmin utilizes MKSA And even if the 16feet units is true, maybe during the encoding a rouding is appied: - an arc 2.4m is encoded as zero 16feet units - between 2.5m and 7.6m is one 16feet units. - etc. At last, in my experience with mkgmap never had problems with --remove-short-arcs without min arc length (i.e. remove only zero length arcs) Ciao, Marco. Personally, I am not convinced that having zero length arcs really makes a difference. However, some people report that the minimum length needs to be greater than 0 otherwise routing is broken in some places. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] R: Progressing patches
--- Lun 17/8/09, Mark Burton ma...@ordern.com ha scritto: Da: Mark Burton ma...@ordern.com Oggetto: [mkgmap-dev] Progressing patches A: Development list for mkgmap mkgmap-dev@lists.mkgmap.org.uk Data: Lunedì 17 agosto 2009, 01:13 I have 3 patches currently out for evaluation: mb-min-arc-length-v4.patch various tweaks related to short arcs including making remove-short-arcs enabled by default with a min arc length of 5m - could effect any map that has routing Hi Mark, I did not follow very well last discussions. I agree in enabling remove-short-arcs by default, but with no min length (i.e. min lenght=0). Could you please explain why arcs shorter than 5m should be collapsed? Ciao, Marco. Naturally, I believe them all to be completely sound and worthy of inclusion in mkgmap. Shall I commit them? or is more testing/discussion required? No hurry here, just seeing what people think. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Administrative boundaries
--- Lun 3/8/09, maning sambale emmanuel.samb...@gmail.com ha scritto: Da: maning sambale emmanuel.samb...@gmail.com Oggetto: Re: [mkgmap-dev] Administrative boundaries A: Development list for mkgmap mkgmap-dev@lists.mkgmap.org.uk Data: Lunedì 3 agosto 2009, 10:44 May I also add, most admin_level boundaries around my area use relations. How do I use a relation style to show admin level boundaries i.e. (or something similar) admin_level = 6-8 resolution 15 admin_level= 10-15 resolution 2o Hi, I use this in my style: #boundaries boundary=administrative admin_level3 [0x1e resolution 14] boundary=administrative admin_level5 [0x1d resolution 16] boundary=administrative admin_level7 [0x1d resolution 20] boundary=administrative [0x1c resolution 22] boundary=political [0x1c resolution 22] boundary=national [0x1e resolution 14] It looks nice for Italy. Ciao, Marco. On 8/3/09, Lambertus o...@na1400.info wrote: It appears that very low level administrative boundaries are rendered quite prominently using the default Mkgmap style. An example is shown here: http://forum.openstreetmap.org/viewtopic.php?pid=31404#p31404 What are the options to reduce the visibility of those boundaries? ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
R: [mkgmap-dev] [PATCH v1] - beware of the bollards!
--- Mar 7/7/09, Mark Burton ma...@ordern.com ha scritto: Da: Mark Burton ma...@ordern.com Oggetto: [mkgmap-dev] [PATCH v1] - beware of the bollards! A: mkgmap-dev@lists.mkgmap.org.uk Data: Martedì 7 luglio 2009, 15:30 Fed up of being routed in your car down city streets only to find the way is blocked by a bollard? Well, if so, this is the patch for you. If a way has a bollard on a point, the segments of the way that connect to the bollard have access restrictions placed on them. By default, a bollard implies: access=no, foot=yes, bicycle=yes. Testing using mapsource shows that it generally works as expected although if the destination cannot be reached by any other route, it routes straight through the bollard rather than failing! If the destination can be reached by some other route, even if the route is really long, it will avoid the bollard. I have chosen Garmin code 0x660f (pillar) for the bollard. On my etrex it appears as a small dot in the way. As usual, all feedback is welcome. Mark, I read on wiki that cycle_barrier has no default access rule. I think you should be more conservative and, in absence of explicit tags, let bicycles passing through (wiki says that cycle_barrier should only imply motor_vehicle=no) Ciao. Cheers, Mark -Segue allegato- ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: R: [mkgmap-dev] [PATCH v2] - beware of the bollards!
--- Mar 7/7/09, Mark Burton ma...@ordern.com ha scritto: Da: Mark Burton ma...@ordern.com Oggetto: Re: R: [mkgmap-dev] [PATCH v2] - beware of the bollards! A: mkgmap-dev@lists.mkgmap.org.uk Data: Martedì 7 luglio 2009, 17:50 Hi Marco, Mark, may I suggest a totally different approach? why not to use a couple of restriction relations? a no_straight_on between the segment before (from) and after (to) the bollard node (via) and a second no_straight_on relation the way round. Of course with the right except: bicycle, foot, ... You could also invent an internal relation restriction like no_passage The issue here seems that the except key does not foresees foot. Would it be feasible? I don't think so because turn restrictions affect all traffic except foot so you could not distinguish between a car and a bicycle. Mark, the wiki page about restrictions http://wiki.openstreetmap.org/wiki/Relation:restriction says I can put a key except with the following values/meaning: except - psv/bicycle/hgv/motorcar - The restriction does not apply to these vehicle types (more than one: except=bicycle;psv) So do you mean that mkgmap does not actually support/handle the except key in a relation restriction? Ciao, Marco. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: R: [mkgmap-dev] [PATCH v2] - beware of the bollards!
-- Mar 7/7/09, Mark Burton ma...@ordern.com ha scritto: Da: Mark Burton ma...@ordern.com Oggetto: Re: R: [mkgmap-dev] [PATCH v2] - beware of the bollards! A: mkgmap-dev@lists.mkgmap.org.uk Data: Martedì 7 luglio 2009, 18:38 Hi Marco, Mark, the wiki page about restrictions http://wiki.openstreetmap.org/wiki/Relation:restriction says I can put a key except with the following values/meaning: except - psv/bicycle/hgv/motorcar - The restriction does not apply to these vehicle types (more than one: except=bicycle;psv) So do you mean that mkgmap does not actually support/handle the except key in a relation restriction? Err, no - sorry. Almost certainly, there is some Garmin magic to express such an exception but we don't know about it! Mark, my last post about this issue, since I really know too little about garmin IMG and mkgmap. I thought that the restriction relations were utilized in the routing IMG data base exacly as the way access tags. I thought both were utilized by mkgmap to build the same access vector (the per vehicle access vector). Maybe I'm wrong in this and access restrictions and turn restrictions are used in different parts of the IMG file stucture. Ciao. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Option preserve-element-order
--- Mer 1/7/09, Tomas Straupis tomasstrau...@gmail.com ha scritto: 2009/7/1 Felix Hartmann extremecar...@googlemail.com: Drawing order on GPS: 1. Polygons (doesn't matter which layer nor map-id,) -- polygons themselves by draw order in typfile. How exactly can I control that (where/what is that typfile)? In exact, I want to have lakes on top of forests. Moreover: do you know what is the default GPS drawing order for polygons when a TYP file is not present? At least for the standard Garmin polygon types. Marco. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] motorcycle=no
Unfortunately, motorcar and motorcycle share the same access bit in IMG...
From MKGMAP SOURCE:
StyledConverter.java:
private final AccessMapping[] accessMap = {
new AccessMapping(access, RoadNetwork.NO_MAX), // must be
first in list
new AccessMapping(bicycle,RoadNetwork.NO_BIKE),
new AccessMapping(foot, RoadNetwork.NO_FOOT),
new AccessMapping(hgv,RoadNetwork.NO_TRUCK),
new AccessMapping(motorcar, RoadNetwork.NO_CAR),
new AccessMapping(motorcycle, RoadNetwork.NO_CAR),
new AccessMapping(psv,RoadNetwork.NO_BUS),
new AccessMapping(taxi, RoadNetwork.NO_TAXI),
new AccessMapping(emergency, RoadNetwork.NO_EMERGENCY),
new AccessMapping(delivery, RoadNetwork.NO_DELIVERY),
new AccessMapping(goods, RoadNetwork.NO_DELIVERY),
};
.
if (type.equals(motorcar) ||
type.equals(motorcycle)) {
road.setNoThroughRouting();
.
I guess there is no way to make a way good for cars and not for bykes
Ciao, Marco.
--- Dom 21/6/09, Mark Burton ma...@ordern.com ha scritto:
Da: Mark Burton ma...@ordern.com
Oggetto: Re: [mkgmap-dev] motorcycle=no
A: mkgmap-dev@lists.mkgmap.org.uk, marco_certe...@yahoo.it
Data: Domenica 21 giugno 2009, 21:35
Hi Marco,
From: Marco Certelli marco_certe...@yahoo.it
Subject: [mkgmap-dev] motorcycle=no
Date: Sun, 21 Jun 2009 15:03:32 + (GMT)
The question is: how mkgmap compiles a motocycle=no
tag?
I am away from home this week and can't look at the source
but, from
memory, I think it will ignore that tag.
And is there a way in mkgmap/IMG to make a road
routable for cars but not for motorcycles?
I don't know of any way to do that.
Cheers,
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] motorcycle=no
Unfortunately I've not been able to find a better solution than putting as
first row in style:
motorcycle=no {set motorcycle=yes}
It works, but the resulting map is only good for cars, not for motorcycles...
Good Night.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Overview map: tiny patch/review series
--- Mar 16/6/09, Mark Burton ma...@ordern.com ha scritto:
Da: Mark Burton ma...@ordern.com
Oggetto: Re: [mkgmap-dev] Overview map: tiny patch/review series
A: mkgmap-dev@lists.mkgmap.org.uk
Data: Martedì 16 giugno 2009, 18:19
Hi Thilo,
At the distances we're (mostly) interested in,
the curvature of the
earth's surface has a tiny effect (much less than
the effect of
hills
valleys) so I guess (hope) that leaving out that
factor is OK.
The curvature may have a tiny effect, but nonetheless
you should
consider the coordinate system you are using.
Interpreting lat and lon
as cartesian coordinates (don't know whether you are
really doing
that) will give large errors at high latitudes.
I have to admit that I'm not much of a mathematician so I
am quite
happy to take advice as to the soundness of the current
algorithm. I
did test it against what we were using before and for the
latitudes I
was using, it appeared to work OK.
I know that this isn't your code but it's as good
a place as any
to comment about it: looking at the DP code (for
the first time), I
immediately see that the loop that finds the max
distance is
(potentially) doing many more sqrts and divisions
than it needs to. So
even if the code is correct, it could be somewhat
faster which would
be
worthwhile given that it gets called for every
line. Eg, it could be
changed to look like this:
// Find
point with highest distance.
// Loop
runs downwards, as the list length gets modified while
running
for(int i =
endIndex-1; i startIndex; i--) {
Coord p = points.get(i);
double ap = p.distance(a);
double bp = p.distance(b);
double abpa = (ab+ap+bp)/2;
double dd = abpa * (abpa-ab) * (abpa-ap)
* (abpa-bp);
if (dd maxDistance) {
maxDistance = dd;
maxIndex = i;
}
}
maxDistance
= 2 * Math.sqrt(maxDistance) / ab;
Also - you get a division by zero if ab is 0,
perhaps adding a test
for that before the loop would be advisable.
Do you understand that formula for the distance
calculation? If so
could you explain it for me? I don't get it.
Sorry, no.
Just speculation:
I've a and b that defines a line. I look for the distance between a point p and
the line.
Given the triangle p-a-b where p is the vertex and a-b is the base, the area
of the triangle can be calculated from the lenght of its 3 sides (pa, pb, ab).
After that, since the area is also base x height / 2 we can calculate the
height = area / base * 2
well, the height is exactly the distance of the point p from the line a-b
Maybe...
Another minor nit - the comment is inaccurate as
the list length
doesn't change in this loop.
It is accurate, because the list length does get
changed by the way
the recursion works. It is not obvious, therefore this
comment is
really needed!
The loop I mention does not contain any recursion. The loop
in
doFilter() does (it is adorned with a similar comment).
Another question, just out of curiosity: Does it
really mattern in
Java how many sqrts or sin or cos I do? Doesn't that
kind of
difference get swamped by all that interpretation and
memory
allocation things etc. going on? With modern FPUs that
kind of
operation isn't that expensive (if it is done
native).
You're quite possibly right but some maths ops are
hideously slow (i.e.
acos which is used in the original distance() method). In
the example
above, I would argue that taking the sqrt and division
outside of the
loop doesn't make the code harder to understand and may
yield some
speedup.
I would start working on the DP code if it makes
sense. If somebody
understands that distance formula and could explain it
it would be
very much appreciated. Otherwise I will have to make
up my own formula
(sigh...)
Well, I think Johann wrote the code so maybe he will
enlighten you!
Cheers,
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Search for address
Sorry if I ask something already discussed. How can I make a map that is serchable for addresses? Is there a specific tagging in OSM to make search working (the search for address in Italy in my nuvi 255 always find no address match). And what about street numbers: is it supported in any way? Many thanks Marco. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Search for address
--- Sab 13/6/09, Mark Burton ma...@ordern.com ha scritto: Da: Mark Burton ma...@ordern.com Oggetto: Re: [mkgmap-dev] Search for address A: mkgmap-dev@lists.mkgmap.org.uk Data: Sabato 13 giugno 2009, 11:00 Hi Marco, How can I make a map that is serchable for addresses? Is there a specific tagging in OSM to make search working (the search for address in Italy in my nuvi 255 always find no address match). By default, maps are generated with as much address info as we know how to encode. It's far from perfect and how well it works depends on which gps you have. I just wonder if there is an OSM tagging scheme for ways that is better to use for coding of address search info. Can you show me a city or an area where the address search works? Or an OSM file example? Ciao. And what about street numbers: is it supported in any way? No, street numbers are not yet supported as we don't know how to encode them. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] route recalculation senstivity bug found
Nuvi 255 here. Route recalculation works very well now (25/30m). I remember a month ago (+/-) it was much worse (say 100m). Mark, do you have some advice about OSM tagging for address search? Ciao. --- Sab 13/6/09, Mark Burton ma...@ordern.com ha scritto: Da: Mark Burton ma...@ordern.com Oggetto: Re: [mkgmap-dev] route recalculation senstivity bug found A: mkgmap-dev@lists.mkgmap.org.uk Data: Sabato 13 giugno 2009, 20:26 Hi Felix, I found out the problem associated to route recalculation not working (well working but only far too late). We currently set the TRE header at 1,3,17 IF we change this over to 1,4,23 route recalculation kicks in at around 25-30m instead of 300-400 (as it happens with 1,3,17 we currently use) on my Vista HCx. I don't know how this is set because the value introduced with the patch about this seems to be organized differently. I changed this with gmaptool and now it works very well. Would be great if these values could be set directly by mkgmap. With my vista hcx and using the current value of 0x110301, the route recalculates if I go off course by no more than about 25m. I believe other people are also getting similar results. Perhaps people could confirm that? Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] route recalculation senstivity bug found
I tried also adding tag is_in: no way. What happen is that I search for an address, I insert the name, it founds the address name I look for and shows me a short list of names starting with the chars I input, as soon as I select the address I look for, it says no match found. :-( I don't know if it may help you: If I search for a city (any city), it doesn't find any city. Ciao. --- Sab 13/6/09, Mark Burton ma...@ordern.com ha scritto: Da: Mark Burton ma...@ordern.com Oggetto: Re: [mkgmap-dev] route recalculation senstivity bug found A: mkgmap-dev@lists.mkgmap.org.uk Data: Sabato 13 giugno 2009, 23:31 Hi Marco, Mark, do you have some advice about OSM tagging for address search? If a road has a name or reference it will have an entry in the address search data structure. It needs also to have a city associated with it which can either be the nearest city (town, village, etc.) or the road can be tagged explicitly using an is_in tag. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1061: Don't use SizeFilter or DouglasPeuckerFilter for resolution 24.
I Tried today the new mkgmap. I confirm the problem I noticed regarding the short arcs lost in Rome is solved. Routing is consistent. The short arc is back. Ciao, Marco. --- Dom 7/6/09, Johann Gail johann.g...@gmx.de ha scritto: Da: Johann Gail johann.g...@gmx.de Oggetto: Re: [mkgmap-dev] Commit: r1061: Don't use SizeFilter or DouglasPeuckerFilter for resolution 24. A: Development list for mkgmap mkgmap-dev@lists.mkgmap.org.uk Data: Domenica 7 giugno 2009, 13:59 Version 1061 was commited by markb on 2009-06-06 17:18:47 +0100 (Sat, 06 Jun 2009) Don't use SizeFilter or DouglasPeuckerFilter for resolution 24. This fixes the bug where the SizeFilter was zapping tiny ways at that resolution. Also, the DP filter was a no-op at that resolution so there's no point in invoking it. Yes, I have seen this lack of optimization before but had not had time to create a patch for it. I had the same idea in not inserting the filters in the chain at highest resolution. But I was not aware that there was a bug in it. Thank you! Regards, Johann ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] - extend --replace-short-arcs option to take min arc length
Hi Mark, I've experienced the same problem: a short arc disappered in Rome (I'm still looking for it...). And the routing gets broken. Did you understand why those short arcs (with no collapsing end nodes) get deleted? Ciao, Marco. --- Gio 4/6/09, Mark Burton ma...@ordern.com ha scritto: Da: Mark Burton ma...@ordern.com Oggetto: Re: [mkgmap-dev] [PATCH v1] - extend --replace-short-arcs option to take min arc length A: mkgmap-dev@lists.mkgmap.org.uk Data: Giovedì 4 giugno 2009, 19:57 Hi Felix, Shame on me, I had in my batch the call for the unpatched mkgmap version, which of course did not. OK. What can I say about the patch? Get it into TRUNK I will commit it soon as it won't affect the default operation. Finally Routing over longer distances IS possible. Route calculation time decreased in mapsource by up to 50%, and possible route length increased about 20-25%. Also no single Mapsource Crash since! Good. At least in Austria where because of the import, many roads are not connected, this patch is absolutely essential! The patch only merges nodes that are close and already connected. It doesn't merge nodes that are close and not connected. On my Vista HCx also many destinations that previously took 2-3 minutes to calculate just calculated only 20-30 seconds! Great. Maybe don't enable it by default, I have not really tested whether now there are any problems with roads connected that should not be connected, but so far it has been working great! I will commit something that has the same effect as the patch you have tried. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] - extend --replace-short-arcs option to take min arc length
The disappearing way id is 25774907 Sorry, I'm leaving now. See you later. Ciao. --- Sab 6/6/09, Mark Burton ma...@ordern.com ha scritto: Da: Mark Burton ma...@ordern.com Oggetto: Re: [mkgmap-dev] [PATCH v1] - extend --replace-short-arcs option to take min arc length A: mkgmap-dev@lists.mkgmap.org.uk Data: Sabato 6 giugno 2009, 15:40 Hi Marco, 41°52.367' N 12°30.477' E I attach a small zipped osm file that compiles with that problem (it is between two tracks at a cross in the center of the osm). I'm looking at that but can't identify the problem - do you have the OSM ids for nodes/ways where it is failing? Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] - extend --replace-short-arcs option to take min arc length
Great Job, Mark. Making the best possible Gramin map with the available OSM Data That should be the mkgmap driver, and you actively support that intent. I'll give a try to the new version tomorrow... Thanks again. Ciao, Marco. --- Sab 6/6/09, Mark Burton ma...@ordern.com ha scritto: Da: Mark Burton ma...@ordern.com Oggetto: Re: [mkgmap-dev] [PATCH v1] - extend --replace-short-arcs option to take min arc length A: mkgmap-dev@lists.mkgmap.org.uk Data: Sabato 6 giugno 2009, 17:25 Hi Marco, I've experienced the same problem: a short arc disappered in Rome (I'm still looking for it...). And the routing gets broken. Did you understand why those short arcs (with no collapsing end nodes) get deleted? Bug found, fix committed. The min arc length can still be specified with --remove-short-arcs (note correct name!) but it shouldn't be needed any more. Zero length arcs must still be removed so you do need to specify --remove-short-arcs (but without the min length). Once this has proven to be trustworthy, we could think about making the zero length arc removal the default behaviour when routing is enabled. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] max-speed and arbitrary values
I Think I have garmin nuvi 255, SW version 5.00 --- Ven 5/6/09, Carlos Dávila cdavi...@jemila.jazztel.es ha scritto: Da: Carlos Dávila cdavi...@jemila.jazztel.es Oggetto: Re: [mkgmap-dev] max-speed and arbitrary values A: Development list for mkgmap mkgmap-dev@lists.mkgmap.org.uk Data: Venerdì 5 giugno 2009, 16:23 Wolfgang v. Hansen escribió: On Thu, 4 Jun 2009, Carlos Dávila wrote: Marco Certelli escribió: I think I can confirm what said here. My nuvi 255 seems to learn the speed I drive on each road (with impact on routing decision next time I drive the same area). I think nuvi 300 doesn't have this behaviour. I have driven many times my road to work and it continues calculating about twice the time it really takes me from home to work (about 50 km trip). Using city navigator for the same route, time calculation is correct. That is really strange. What's your firmware version? What I have in SystemAbout is: nüvi 300 Software Version 5.30 GPS SW Version: 2.90 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] change default name OSM map in mapsource
In my script (http://mce66.altervista.org/software.html) I use the mkgmap switch --series-name=OSM-%country% Hope this help. --- Ven 5/6/09, maning sambale emmanuel.samb...@gmail.com ha scritto: Da: maning sambale emmanuel.samb...@gmail.com Oggetto: Re: [mkgmap-dev] change default name OSM map in mapsource A: Development list for mkgmap mkgmap-dev@lists.mkgmap.org.uk Data: Venerdì 5 giugno 2009, 16:29 Thanks! But this is not an optimal solution especially when you distribute the map to other users. 2009/6/5 Carlos Dávila cdavi...@jemila.jazztel.es: maning sambale escribió: Hi, In mapsource you can select different maps. I want to compile various maps. How do I change default name OSM map? For instance I have a different map name for contour, osm-cycle, and osm-default. I use MapSetToolKit to install osm maps in MapSource. It has a Edit button that you can use to change map name to whatever you want. Cheers Carlos ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] max-speed and arbitrary values
I think I can confirm what said here. My nuvi 255 seems to learn the speed I drive on each road (with impact on routing decision next time I drive the same area). Also I confirm that many roads has a max speed info that is shown on the screen while I drive the road. --- Gio 4/6/09, Wolfgang v. Hansen wvhan...@fom.fgan.de ha scritto: Da: Wolfgang v. Hansen wvhan...@fom.fgan.de Oggetto: Re: [mkgmap-dev] max-speed and arbitrary values A: Development list for mkgmap mkgmap-dev@lists.mkgmap.org.uk Data: Giovedì 4 giugno 2009, 16:24 On Wed, 3 Jun 2009, Thilo Hannemann wrote: Somebody mentioned also that the GPS units will learn the speed you are actually driving and use that for their calculation. If this is speculation or based on facts I don't know. At least with my Oregon 300 I doubt it: As I use it all the time with my maps I'm cycling always in the car mode. So far the ETAs are still very wrong. If the GPS would learn the speed they should become more realistic over time. At least the car navs (StreetPilot, nüvi) do learn your speed profile -- don't know about the outdoor navs though. These are probably the same set of speeds that you can set in MapSource. In addition, there should also be a slot for the max. speed for each road in the maps. Newer devices (I don't have one of them though) along with current maps tell you when you are driving too fast. This is a feature that had been introduced by Garmin/Navteq quite recently. -Wolfgang ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
R: [mkgmap-dev] max-speed and arbitrary values
Hi, As far as I know the map only stores the road_speed and road_class (not the speed in km/h: association road_speed vs. speed is demanded to Garmin devices or mapsource). The turn time penalties I tested was depending on the road_speed (but I presume the penalty is proportional to the speed). Anyway it was not related to the road_class. Do you have other results about those turn time penalties? for bikers, just put only road_speed=0 or 1 to all roads (maybe road_speed 2 for downward roads...) Ciao, Marco. --- Mer 3/6/09, Felix Hartmann extremecar...@googlemail.com ha scritto: Da: Felix Hartmann extremecar...@googlemail.com Oggetto: [mkgmap-dev] max-speed and arbitrary values A: Development list for mkgmap mkgmap-dev@lists.mkgmap.org.uk Data: Mercoledì 3 giugno 2009, 12:06 Is it possible to encode arbitrary maxspeed values or can we only set in steps of 10km/h? For example having road road_speed=7 associated with 35km/h, road road_speed=6 with 27, road_speed=5 with 23, road_speed=4 with 20, road_speed=3 with 17, road_speed=2 with 10 and road_speed=1 with 5km/h. The difference this should make would be enough to only set road_class=2, 1 and 0 and avoid the big time penalties for sharp turns that happen in road_class 4 and 3. This would be great for bicycle maps. In Mapsource one can change the speed oneself, I noticed that dividing default speeds by a factor of 3.5 produces pretty good estimation of arrival times for bicylces (when using the car/motorcycle setting, as bicycle produces rubbish routes) but on the GPS this is not possible. @Thilo, do you understand the code good enough to write a patch for this if possible.? I have problems understanding in which files the maxspeed is handled. Cheers, Felix ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
R: [mkgmap-dev] [PATCH v1] - merge nodes to remove evil short arcs
Mark, I'd like to help but I've no way to build mkgmap. Could you please send me a compiled mkgmap.jar to test the patch? Please, don't give up in searching for the BUG. I'm reading the code and I suspect the error is in the NET/NOD info calculations. In fact the issue appears when the 2 collapsing nodes has = 3 arcs. Nodes with = 3 arcs are route nodes (nodes were routing decision has to be taken) and a NOD record is to be calculated for each one. All NOD records are connected each other with pointers to build the routing network. If two connected routing nodes with 3 arcs each collapses into one with 4 arcs, I guess that all pointers structure shall be recalculated to take care of the missing routing node, and the fact the new node has now 4 arcs instead of 3 implies the NOD record is different and has to be updated. Of course my are just assumptions. Do you know who wrote the parts of the code that calculate the routing structures (src\uk\me\parabola\imgfmt\app\net\...) and how to contact them? In some file I read Robert Vollmert, Steve Ratcliffe,... Ciao, Marco. --- Mer 27/5/09, Mark Burton ma...@ordern.com ha scritto: Da: Mark Burton ma...@ordern.com Oggetto: [mkgmap-dev] [PATCH v1] - merge nodes to remove evil short arcs A: Development list for mkgmap mkgmap-dev@lists.mkgmap.org.uk Data: Mercoledì 27 maggio 2009, 11:12 The attached patch is a first stab at a solution for this problem. Please test. It is implemented in an iterative fashion and it should terminate after a few passes. If 10 passes are executed it will give up, please report if you see it doing that. It would be nice if the diagnostics reported the OSM id of the nodes rather than their coordinates but I haven't worked out the best way of achieving that yet. Cheers, Mark -Segue allegato- ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
R: [mkgmap-dev] road_speed parameter
This is what I know: Road_speed: 0 to 7 Default values: 7=128Km/h, 6=108Km/h, 5=93km/h, 4=72km/h, 3=56km/h, 2=40km/h, 1=20km/h, 0=8km/h. In Mapsource you can change speeds for levels 2 to 6. My garmin nuvi 255 does not allow any change respect the default speeds. I don't know about other devices. The speed is used for route calculation (shorter time). But for best route calculation, garmin gives also a time penalty to each turn you are required to do in a given route. Road_class: 0 to 4 cGPSmapper says it is the main driver for the route calculation (but does't explain how it is used. maybe is also used to decide if a cross is a turn for you or you are just proceeding on the main road... I don't now but I'll made some experiments Ciao. --- Mer 27/5/09, gyp...@gmx.eu gyp...@gmx.eu ha scritto: Da: gyp...@gmx.eu gyp...@gmx.eu Oggetto: [mkgmap-dev] road_speed parameter A: Development list for mkgmap mkgmap-dev@lists.mkgmap.org.uk Data: Mercoledì 27 maggio 2009, 14:43 Somewhere in style files there are road_speed parameters. Today I know that the speeds for 5 different road classes can be set in Mapsource. I assume that the road_speed values in style file represent these 5 Garmin road classes. But how does the GPS device know what speed is referred to by what road class? Is there a speed table in gmapsupp.img file? How can I change these speed values for the GPS device? Since these speeds are surely used by the routing algorithm to weight alternative routes, I would like to get influence on that, especially for preferring cycleways and residential streets for cyclists. Markus ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] (almost) duplicated node issue
Mark, the easiest patch could be to avoid routing towards the short arc. If, after encoding, an arc is zero length, no routing should be allowd ito that arc (as the arc weren't there...) what do yo think about it? Ciao. --- Mar 26/5/09, Mark Burton ma...@ordern.com ha scritto: Da: Mark Burton ma...@ordern.com Oggetto: Re: [mkgmap-dev] (almost) duplicated node issue A: mkgmap-dev@lists.mkgmap.org.uk Data: Martedì 26 maggio 2009, 09:17 I may be wrong here, but I don't believe there is a problem with 2 nodes being close together unless they are connected by a single arc. If I am correct, then we only have to worry about making sure that we don't end up with any arcs that are too short. As I mentioned previously, we can carry out an early pass on the data and merge nodes to remove short arcs but that still doesn't help when the ways are subsequently clipped as the clipping creates new nodes which could create new short arcs. It's true that this is quite unlikely to happen so it's probably a good idea to fix up the bulk of the map and then think about some way around the latter issue. Perhaps it would be better if we did the clipping earlier but that would require a big rewrite so I am not keen to go down that route (ho ho) Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Precision circle
Just a little bit of info. I made some experiments with a GPS72 with other maps (POI only, not OSM) a couple of years ago. I remember the radius of the circle precision is something like GPS real-time in-accuracy + displayed level map in-accuracy. The map in-accuracy depends on the garmin level. If a map shows a level 24 (the most possible accurate level), the map precision is 3/4 meters. If the map has only levels up to 23, the precision is 6/8 meters. If the map has a maximum level of 22, precision is 10/15 meters, and so on. Ciao, Marco. P.S. Level 24 means using 24 bits to store coordinates (lat/lon). And so on... --- Lun 25/5/09, Felix Hartmann extremecar...@googlemail.com ha scritto: Da: Felix Hartmann extremecar...@googlemail.com Oggetto: Re: [mkgmap-dev] Precision circle A: Development list for mkgmap mkgmap-dev@lists.mkgmap.org.uk Data: Lunedì 25 maggio 2009, 08:48 For me on Vista HCx it's working as well. Once position is accurate, precision circle is very small. Nop wrote: Hi! Ralf Kleineisel schrieb: Nop wrote: The discussion over at the GPS forum points towards a setting inside the map, too. It seems mkgmap marks the maps as terribly inaccurate so the maximum precision is an inaccuracy of 260m. With my maps generated with mkgmap my eTrex Legend HCx shows the circle correctly, i.e. it disappears when the GPS position precision is good enough. Ok, so we have 2 with the problem, one without. Let's try to figure out the difference. Does anybody have any idea where in the map this setting is stored? bye Nop ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[PATCH v1] Re: [mkgmap-dev] maxspeed tag vs road_speed preset
Hi, and thaks for your answer. I'm not a developer so I really have some problem in applying the patch locally... I just would like to keep control over the map generation. For example: in Italy the maxspeed out of the city is 90km/h. It applies to unclassified roads up to trunk roads (well, some trunks has 110 km/h). I would like to code in the map in a way that a tertiary with 90km/h speed limit gets road_speed 3 (i.e 60 km effective speed), while a trunk with the same 90km/h limit gets road_speed 5 (i.e 90 km/h effective speed). You can immagine for the secondary and primary. I looked at the source and you coded: if maxspeed40 then road_speed=3 It means that in the Italian cities (limit=50) the average speed coded in the map is 60km/h. It looks strange to me and carries to very optimistic city ETA calculations (and maybe not optimal route selection). Moreover, I sow other map makers (DE:All_in_one_Garmin_Map) making maps including the maxspeed tag management in their styles (but maybe they use a patched mkgmap). So, if it counts I do vote for the switch --ignore-maxspeed and I vote to integrate the patch in the mainstream mkgmap (again, I'm not able to compile the code). As you may have understood, I'm using Windo.%$/$£/$=)(/$))%$()% Sorry, my PC crashed while I was writing Windo.=)/(/£%(//($/=)30/()/89 Ciao, Marco. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
