Re: [mkgmap-dev] max-speed and arbitrary values
I tested a lot with maps today. Setting maximum of *speed_class=2* works quite nice. However Routing over longer distances gets broken, not too bad but significantly. The lower you set the speeds, the straigther the route. Lowering speed_class thereby achieves similar routing like you can achieve by using shorter distance on a map that you build using all speed classes. I currently think that a good compromise would be going up to 3 or 4. Even when going for speed=2 as maximum, car/motorcycle produces slightly better results. Bicycle may be useful however to go a bit shorter distance (i.e. going down on a bike set GPS to bicycle, going up to motorcycle/car). Results are pretty similar however then to motorcar and shorter distance. Optimally we would need at least one more key like avoid toll however, which would be great for further refining your maps. Cgpsmapper now supports setting unpaved roads and carppol lanes - if we could set them too it would be great. On cyclemaps this would enable you to route all over Germany, if you avoid all non bicycle routes by enabling that key (as long as the route is not broken, sadly many are missing pieces in their relation). I did some tests and was able to route the Donauradwanderweg through it's complete Austrian territory by adding to all non route=bicycle the toll key. That would be nice, so if you simply wan't your GPS to follow the cycleroute, you enable the key and don't have to worry about the GPS deciding on other ways. As for* road_class*... I don't actually know wheter how 3 and 2 work differently. 0,1, and 4 have significant impact. Oh and not to forget. If someone could figure out how to set the *extended types* (also wrongly called 3byte tpyes), it would be great. Lines can currently be used up to 0x3f, 0x40 will show in Mapsource as 0x00, I think some GPS can differentiate upto 0x8f however. Extended types are NOT related to NT map format. There are many non NT maps with extended types. I'm now running out of all points, polygons and lines (many points are not usable, i.e. all marine points don't show up on my Vista HCx, others are not really stylable via typfile. Thilo Hannemann wrote: Hi Felix, Am 03.06.2009 um 12:06 schrieb Felix Hartmann: 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. That would be great indeed. 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. I have not really looked into the Garmin encoding part of the code, but I could invest some time if it helps. From what I know there are only those few road_speeds available in the format. *But* maybe there is some part in the header where one can set what actual speed each road_speed corresponds to (this is pure speculation). 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. Perhaps we can build a Wiki page somewhere where we can collect all "hard evidence" about the routing? How about setting up an artificial map that we can use to test the routing, ETAs and so on? Especially keeping in mind that there might be a difference between different GPS units, firmware revision and so on. If there are routing parameters that the GPS units "learn" about their users that would really f*ck up our tests. @Marco Certelli: You've already started some tests. If you could write down what you did on some Wiki page so that others can repeat your tests that would be really helpful. Regards Thilo ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH] Generate copies of ways using the relations style file *Experimental*
The attached patch allows to generate ways from a relation. To do so
simply write the way generating statement into your relations style
file, e.g.
type=route & route=bicycle & network=tcn { name 'Touristic
cycleroute' } [ 0x02 road_class=3 road_speed=6 level 3 ]
generate_ways_from_relations.patch
Description: Binary data
If one way is a member of several relations one copy of the way will
be generated for each relation (and also another one if the way
matches also in the lines style file).
The name of the generated way is the name of the relation. The access
tag must be set explicitly in the relations style file, as (except the
"oneway" tag) no tags are copied from the original way into the
generated way.
I consider this patch experimental, but as I have it in use now for
some days and it works fine I though I might publish it. It is really
useful for cycle maps.
Regards
Thilo___
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
Hi Felix, Am 03.06.2009 um 12:06 schrieb Felix Hartmann: 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. That would be great indeed. 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. I have not really looked into the Garmin encoding part of the code, but I could invest some time if it helps. From what I know there are only those few road_speeds available in the format. *But* maybe there is some part in the header where one can set what actual speed each road_speed corresponds to (this is pure speculation). 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. Perhaps we can build a Wiki page somewhere where we can collect all "hard evidence" about the routing? How about setting up an artificial map that we can use to test the routing, ETAs and so on? Especially keeping in mind that there might be a difference between different GPS units, firmware revision and so on. If there are routing parameters that the GPS units "learn" about their users that would really f*ck up our tests. @Marco Certelli: You've already started some tests. If you could write down what you did on some Wiki page so that others can repeat your tests that would be really helpful. Regards Thilo ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1059: New approach to the too many nodes in region problem - carry on regardless.
On Wed, Jun 3, 2009 at 5:41 PM, Mark Burton wrote: > > Let's see how this does - I have tried it out on 63660006.osm and the > resulting map loads into mapsource OK and is generally fine. Trying to > route through the broken region does cause mapsource to either draw a > straight line or pop up the "your map's broken" dialog. A real gps > would probably hang or crash if it tried to route through the region. Thanks! I'll try this out as soon as possible. I've noticed on my eTrex, when I encounter such broken areas, I usually simply get a "Routing Error" popup, but the device has not yet (recently) hung. Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1059: New approach to the too many nodes in region problem - carry on regardless.
Let's see how this does - I have tried it out on 63660006.osm and the resulting map loads into mapsource OK and is generally fine. Trying to route through the broken region does cause mapsource to either draw a straight line or pop up the "your map's broken" dialog. A real gps would probably hang or crash if it tried to route through the region. The fix is not very pleasing but if it allows the map to build with minimal damage to the routing then I guess it will do for now as an interim solution. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r1059: New approach to the too many nodes in region problem - carry on regardless.
Version 1059 was commited by markb on 2009-06-03 17:34:08 +0100 (Wed, 03 Jun 2009) New approach to the too many nodes in region problem - carry on regardless. Now, instead of croaking when too many nodes are in a region, it throws them away and tries to continue the best it can. The routing will be broken in that region but it would have been wacky anyway even if the nodes had been processed normally. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r1058: Add means to flag node as being discarded.
Version 1058 was commited by markb on 2009-06-03 17:34:04 +0100 (Wed, 03 Jun 2009) Add means to flag node as being discarded. The goal here is to be able to call getOffsetNod1() without bombing even though the routing will be broken because the node has been discarded. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1054: When subdivision fails to reduce number of nodes, report bbox and croak.
On Wed, Jun 03, 2009 at 03:12:59PM +0100, Mark Burton wrote: > > Hi Felix, > > > a) has something in mkgmap changed > > No, it has always (well at least as far as I have been involved with > it!) been capable of failing in this way. > > > b) is there some tool out that destructs osm data by mistake? > > Or is there some dumb mapper who generated the same ways 50 times? Tool or fool, isn't it the same thing? :-) Joking aside, finland.osm.bz2 compiled just fine with mkgmap -r1057 --max-jobs. While it was doing the job, I was editing a ride, removing orphaned points and merging a duplicated point. It's great that mkgmap can work around some forms of brokenness. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1054: When subdivision fails to reduce number of nodes, report bbox and croak.
b) is there some tool out that destructs osm data by mistake? Or is there some dumb mapper who generated the same ways 50 times? Just a thoght: May it have to do something with the new v0.6 interface? May this ways be old revisions or somthing similar? ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1054: When subdivision fails to reduce number of nodes, report bbox and croak.
On Tue, Jun 2, 2009 at 11:04 AM, svn commit wrote: > Version 1054 was commited by markb on 2009-06-02 10:04:38 +0100 (Tue, 02 Jun > 2009) > > When subdivision fails to reduce number of nodes, report bbox and croak. You know, I'm not too crazy about the "croak" part. For example, yesterday I attempted to compile a map of a large portion of Europe from Geofabrik.de, which provides daily extracts. The entire procedure took many hours (osmosis -> split -> mkgmap) on my antiquated (2 years old) hardware. Sometime in the middle of the night, I ended up with the "croak" and a polite apology that the map could not be compiled due to an invalid bbox somewhere. Now to correct this, I would have to figure out where the invalid data came from, try to correct it, upload it, and wait another day until the Geofabrik extract is available, and then start again. This may be a considerable incentive to correct the bad data ;-), but it is inconvenient, to say the least, when attempting to compile large areas. :-( Er... would it be possible to warn and continue with the compilation, knowing that parts of the map would be corrupt? (a "--force" option, or something?) Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1054: When subdivision fails to reduce number of nodes, report bbox and croak.
Hi Clinton, > You know, I'm not too crazy about the "croak" part. > > For example, yesterday I attempted to compile a map of a large portion > of Europe from Geofabrik.de, which provides daily extracts. The entire > procedure took many hours (osmosis -> split -> mkgmap) on my > antiquated (2 years old) hardware. Sometime in the middle of the > night, I ended up with the "croak" and a polite apology that the map > could not be compiled due to an invalid bbox somewhere. > > Now to correct this, I would have to figure out where the invalid data > came from, try to correct it, upload it, and wait another day until > the Geofabrik extract is available, and then start again. > > This may be a considerable incentive to correct the bad data ;-), but > it is inconvenient, to say the least, when attempting to compile large > areas. :-( > > Er... would it be possible to warn and continue with the compilation, > knowing that parts of the map would be corrupt? (a "--force" option, > or something?) It's a tricky situation because by the time the problem is detected lots of half built data structures are around some of which will refer to the nodes/ways that are going to have to be thrown away to be able to carry on without croaking. I will have a go a trying to find a means of continuing in this situation but it's likely that the resulting map will be broken as far as routing is concerned. Let's see what can be done. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1054: When subdivision fails to reduce number of nodes, report bbox and croak.
Hi Felix, > a) has something in mkgmap changed No, it has always (well at least as far as I have been involved with it!) been capable of failing in this way. > b) is there some tool out that destructs osm data by mistake? Or is there some dumb mapper who generated the same ways 50 times? Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1054: When subdivision fails to reduce number of nodes, report bbox and croak.
For me this is the same. However why did this problem not appear until now? a) has something in mkgmap changed or b) is there some tool out that destructs osm data by mistake? Clinton Gladstone wrote: On Tue, Jun 2, 2009 at 11:04 AM, svn commit wrote: Version 1054 was commited by markb on 2009-06-02 10:04:38 +0100 (Tue, 02 Jun 2009) When subdivision fails to reduce number of nodes, report bbox and croak. You know, I'm not too crazy about the "croak" part. For example, yesterday I attempted to compile a map of a large portion of Europe from Geofabrik.de, which provides daily extracts. The entire procedure took many hours (osmosis -> split -> mkgmap) on my antiquated (2 years old) hardware. Sometime in the middle of the night, I ended up with the "croak" and a polite apology that the map could not be compiled due to an invalid bbox somewhere. Now to correct this, I would have to figure out where the invalid data came from, try to correct it, upload it, and wait another day until the Geofabrik extract is available, and then start again. This may be a considerable incentive to correct the bad data ;-), but it is inconvenient, to say the least, when attempting to compile large areas. :-( Er... would it be possible to warn and continue with the compilation, knowing that parts of the map would be corrupt? (a "--force" option, or something?) Cheers. ___ 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 ha scritto: > Da: Felix Hartmann > Oggetto: [mkgmap-dev] max-speed and arbitrary values > A: "Development list for mkgmap" > 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
Re: [mkgmap-dev] Commit: r1057: Add --max-jobs option to request concurrent processing of maps.
Thanks a lot! Mark Burton wrote: Hi Lambertus, Specifying or specifically not specifying? I'm confused: What should be done to get one thread on a single core machine, or two threads on a dual core? Use --max-jobs. To summarise: If --max-jobs is not specified, you get 1 thread no matter how many cores you have. If --max-jobs is specified, you get as many threads as you have cores. If --max-jobs=N is specified, you get N threads. The help blurb says this in another way. 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] max-speed and arbitrary values
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
Re: [mkgmap-dev] Commit: r1057: Add --max-jobs option to request concurrent processing of maps.
Hi Lambertus, > Specifying or specifically not specifying? I'm confused: What should be > done to get one thread on a single core machine, or two threads on a > dual core? Use --max-jobs. To summarise: If --max-jobs is not specified, you get 1 thread no matter how many cores you have. If --max-jobs is specified, you get as many threads as you have cores. If --max-jobs=N is specified, you get N threads. The help blurb says this in another way. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1057: Add --max-jobs option to request concurrent processing of maps.
svn commit wrote: Version 1057 was commited by markb on 2009-06-03 11:26:34 +0100 (Wed, 03 Jun 2009) Add --max-jobs option to request concurrent processing of maps. Processing of the maps is handled concurrently by a pool of top-level threads. The number of threads in the pool can be specified explicitly with the --max-jobs=N option. Specifying just --max-jobs will set the number of threads equal to the number of CPUs available. Specifying or specifically not specifying? I'm confused: What should be done to get one thread on a single core machine, or two threads on a dual core? ___ 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] Parallel processing of maps now in trunk
Things are a bit quiet on the list this morning so I thought I would commit this patch as it has had a reasonable amount of testing with no problems reported recently. If you have a multi-core machine, specify --max-jobs to get some speedup when processing multiple maps. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r1057: Add --max-jobs option to request concurrent processing of maps.
Version 1057 was commited by markb on 2009-06-03 11:26:34 +0100 (Wed, 03 Jun 2009) Add --max-jobs option to request concurrent processing of maps. Processing of the maps is handled concurrently by a pool of top-level threads. The number of threads in the pool can be specified explicitly with the --max-jobs=N option. Specifying just --max-jobs will set the number of threads equal to the number of CPUs available. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] routing & rendering penalty with smaller tiles in splitter
On Wed, Jun 03, 2009 at 02:04:56PM +0800, maning sambale wrote: > Hi, > > I'm attempting to split the Philippines into smaller tiles using > splitter. This is to make rendering faster. > Currently I've tested with the following: > > --max-nodes=80 > --max-nodes=40 > --max-nodes=20 > > > On my tests with mapsource and roadtrip, no routing and rendering > problems so far. What do others experience when making smaller tiles? > What is the "optimum" tile size for very dense data areas with > minimal penalty for routing and rendering? I haven't experimented with tile sizes lately. Months ago, when mkgmap was in worse shape and I tried routing a 70 km journey through mostly rural areas (no cycleways), it looked like the Garmin Edge 705 can't look much across tile borders. It routed via a major road that ran parallel to the tile border, and finally turned 90 degrees, causing a 20 km detour. On a related note, I made a 93 km round-trip bicycle ride last Sunday, across the Helsinki metropolitan area. For the first 10+ km, the Edge 705 would tell me to use bicycle roads. But then it suddenly told me to switch to the car roads. I had to recalculate multiple times, and the route wasn't optimal. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
