[mkgmap-dev] routing rendering penalty with smaller tiles in splitter
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? -- 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
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
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
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
[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: 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
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 ma...@ordern.com 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] 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
[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
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
