Hi all, I've created a new branch NOD127 : http://www.mkgmap.org.uk/download/mkgmap-NOD127-r3086.zip This is used to test the latest findings regarding the NOD file format. Most of it is understood now, thanks to Steve and his display tool :-) Changes in r3086 compared to trunk r3081: - nodes are grouped by classes and additional arcs are written to connect nodes. This seems to improve routing, at least it is much closer to what real maps contain. - avoid roundabouts works in Basecamp (only with "shorter distance") - avoid toll roads works as expected, is trunk it has to be switched on to allow routing on major roads A few open questions remain at this point: - the carpool bit seems to have no effect, it is likely that there is a bit in the NOD header that has to be switched on or off to change that, but we don't know where. - some original maps contain extra info for route restrctions, we don't know yet what they mean. Gerd
Hi Gerd, This looks like a major improvement in routing, well done guys! I've done a few small tests in Basecamp with the default style: -Cars are not routed on bike paths anymore (and I dont have to set carpool avoidance on) -Bikes are not sent on footways (bicycle=no seems respected?) -Cycling profile, car profile and pedestrian now finally behave as expected So it seems the issues with the carpool bit are solved too. Havent tested it yet on my devices but this branch looks very promising!
Hi Minko, great! I only looked at the car routing so far. Gerd
Date: Thu, 6 Mar 2014 14:26:06 +0100 From: ligfietser@online.nl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] new branch NOD127
Hi Gerd,
This looks like a major improvement in routing, well done guys!
I've done a few small tests in Basecamp with the default style: -Cars are not routed on bike paths anymore (and I dont have to set carpool avoidance on) -Bikes are not sent on footways (bicycle=no seems respected?) -Cycling profile, car profile and pedestrian now finally behave as expected
So it seems the issues with the carpool bit are solved too.
Havent tested it yet on my devices but this branch looks very promising! _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, I have tested your branch a bit. I have noticed some weird routing, see pictures at: http://files.mkgmap.org.uk/download/183/nod-routingi.7z There is unexpected detour for longer route, you can see it on nod-long.png. On trunk r3087 the some route is correct. I have replaced roundabouts with object 0x0B but routing remained the same, so probably it is not due bits connected with roundabouts. Other note: could you add a message with version at the start of mkgmap? I already have so many version that I'm not always sure which one is running. -- Best regards, Andrzej
Hi Andrzej, yes, that looks wrong. Please report also the settings and version of the Garmin program you are using. Gerd popej wrote
Hi Gerd,
I have tested your branch a bit. I have noticed some weird routing, see pictures at: http://files.mkgmap.org.uk/download/183/nod-routingi.7z
There is unexpected detour for longer route, you can see it on nod-long.png. On trunk r3087 the some route is correct.
I have replaced roundabouts with object 0x0B but routing remained the same, so probably it is not due bits connected with roundabouts.
Other note: could you add a message with version at the start of mkgmap? I already have so many version that I'm not always sure which one is running.
-- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/new-branch-NOD127-tp5798806p5798888.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd,
Please report also the settings and version of the Garmin program you are using.
Sorry, not a good testing. Screen shots are form Mapsource with settings: car/motorcycle, shorter distance, avoid unpaved roads and ferries. I thought it was faster time.
you can use option --version, but mkgmap will then only print the version. If you have an img file you can use grep or findstr and search for the string mkgmap.
I often use own license text and then there is no mkgmap version in img. Which leads to another suggestion: map license probably should be written inside LBL subfile, leaving TRE subfile for compiler message. -- Best regards, Andrzej
Hi Andrzej, if I got that right you use your own style. Can you reproduce the results with the default style? If yes, what options do you use? Gerd
Date: Thu, 6 Mar 2014 20:41:05 +0100 From: popej@poczta.onet.pl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] new branch NOD127
Hi Gerd,
Please report also the settings and version of the Garmin program you are using.
Sorry, not a good testing. Screen shots are form Mapsource with settings: car/motorcycle, shorter distance, avoid unpaved roads and ferries. I thought it was faster time.
you can use option --version, but mkgmap will then only print the version. If you have an img file you can use grep or findstr and search for the string mkgmap.
I often use own license text and then there is no mkgmap version in img. Which leads to another suggestion: map license probably should be written inside LBL subfile, leaving TRE subfile for compiler message.
-- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Andrzej, forget it. Just found a similar case by inverting a good route, the inverted tour leaves a major road and is 4km longer. I'll try to find out what goes wrong. Gerd From: gpetermann_muenchen@hotmail.com To: mkgmap-dev@lists.mkgmap.org.uk Date: Fri, 7 Mar 2014 08:42:53 +0100 Subject: Re: [mkgmap-dev] new branch NOD127 Hi Andrzej, if I got that right you use your own style. Can you reproduce the results with the default style? If yes, what options do you use? Gerd
Date: Thu, 6 Mar 2014 20:41:05 +0100 From: popej@poczta.onet.pl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] new branch NOD127
Hi Gerd,
Please report also the settings and version of the Garmin program you are using.
Sorry, not a good testing. Screen shots are form Mapsource with settings: car/motorcycle, shorter distance, avoid unpaved roads and ferries. I thought it was faster time.
you can use option --version, but mkgmap will then only print the version. If you have an img file you can use grep or findstr and search for the string mkgmap.
I often use own license text and then there is no mkgmap version in img. Which leads to another suggestion: map license probably should be written inside LBL subfile, leaving TRE subfile for compiler message.
-- Best regards, Andrzej _______________________________________________ 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
Hi Andrzej, I am quite clueless. I can reproduce your results with a map for Poland. In BaseCamp results are even more strange. For both trunk and branch, I see a big detour depending on the start point, so something is weird with road 6. I've disabled writing of restrictions : same result. with or without --adjust-turn-headings: same result I am running out of ideas ... Gerd
Date: Thu, 6 Mar 2014 20:41:05 +0100 From: popej@poczta.onet.pl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] new branch NOD127
Hi Gerd,
Please report also the settings and version of the Garmin program you are using.
Sorry, not a good testing. Screen shots are form Mapsource with settings: car/motorcycle, shorter distance, avoid unpaved roads and ferries. I thought it was faster time.
you can use option --version, but mkgmap will then only print the version. If you have an img file you can use grep or findstr and search for the string mkgmap.
I often use own license text and then there is no mkgmap version in img. Which leads to another suggestion: map license probably should be written inside LBL subfile, leaving TRE subfile for compiler message.
-- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd,
For both trunk and branch, I see a big detour depending on the start point, so something is weird with road 6.
I'm afraid it could be quite difficult to get good routing in Poland with default style. especially in BaseCamp. That's because our road network miss highways and Garmin programs need class 4 roads, when calculating long route. I have tested my maps, which I know best, but maybe you could find similar behavior in other area? If not, I can send you my style for road map. I will try investigate a bit, maybe I will be able to isolate this problem. -- Best regards, Andrzej
Hi Gerd, I have tested routing with trunk r3093 and nod127 r3095. I have used default style, car/motorcycle routing, fastest route. I can confirm, that both version show a detour on Polish road 6. It seems to depend on many factor so it is difficult to isolate a meaningful example. Some notices: In Mapsource route depends on "Road selection" option in route preferences. I usually set it in the middle but when set to 75% of "Prefer Highways", routing becomes better. For nod127 branch there is difference in routing, when I set avoidances to unpaved road. It doesn't clear the problem, only detour is different. In BaseCamp I got the same detour in both version of mkgmap. For nod127 detour changes, when I set avoidance to unpaved road, no change in trunk. In both version detour changes the same way if I set avoidances to residential streets. Any of highway avoidances changes detour and when I use avoid State Highways, route is correct. I'm not sure what is "State Highway" for BaseCamp, it could be primary road, which actually is used for route. BaseCamp is not able to calculate longer route with trunk, the same route is calculated with nod127 (including detour). Please write if you have any suggestion what could I test or what data could be useful for you. -- Best regards, Andrzej
Hi Andrzej, The part of road 6 that is avoided has many roundabouts. Maybe the Garmin algo doesn't like them? I'll try to find out if we can use the new knowledge regarding roundabouts to avoid using type 0x0c for them. Gerd
Date: Sat, 8 Mar 2014 22:56:47 +0100 From: popej@poczta.onet.pl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] new branch NOD127
Hi Gerd,
I have tested routing with trunk r3093 and nod127 r3095. I have used default style, car/motorcycle routing, fastest route. I can confirm, that both version show a detour on Polish road 6. It seems to depend on many factor so it is difficult to isolate a meaningful example.
Some notices:
In Mapsource route depends on "Road selection" option in route preferences. I usually set it in the middle but when set to 75% of "Prefer Highways", routing becomes better.
For nod127 branch there is difference in routing, when I set avoidances to unpaved road. It doesn't clear the problem, only detour is different.
In BaseCamp I got the same detour in both version of mkgmap. For nod127 detour changes, when I set avoidance to unpaved road, no change in trunk. In both version detour changes the same way if I set avoidances to residential streets. Any of highway avoidances changes detour and when I use avoid State Highways, route is correct. I'm not sure what is "State Highway" for BaseCamp, it could be primary road, which actually is used for route.
BaseCamp is not able to calculate longer route with trunk, the same route is calculated with nod127 (including detour).
Please write if you have any suggestion what could I test or what data could be useful for you.
-- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi, here are my findings: If I comment the roundabout block in the lines file # Roundabouts #junction=roundabout & highway=trunk [0x0c road_class=3 road_speed=2 resolution 18] #junction=roundabout & highway=primary [0x0c road_class=3 road_speed=2 resolution 19] #junction=roundabout & highway=secondary [0x0c road_class=2 road_speed=2 resolution 20] #junction=roundabout & highway=tertiary [0x0c road_class=1 road_speed=1 resolution 21] #junction=roundabout & highway=unclassified [0x0c road_class=1 road_speed=1 resolution 21] #junction=roundabout [0x0c road_class=0 road_speed=1 resolution 22] both MapSource and Basecamp stay on road 6, but you'll not see any hints for the roundabouts, so that's no solution. If I only change the road_speed for primary roads to the same value of normal primary roads (4): junction=roundabout & highway=primary [0x0c road_class=3 road_speed=4 resolution 19] the roundabouts are still avoided. So, I agree with Andrzej: If you prefer major roads, you have to change default settings in Basecamp to avoid unpaved and resedential roads, in MapSource move the road selection closer to "prefer Highways" (75%) Gerd From: gpetermann_muenchen@hotmail.com To: mkgmap-dev@lists.mkgmap.org.uk Date: Sun, 9 Mar 2014 09:29:46 +0100 Subject: Re: [mkgmap-dev] new branch NOD127 Hi Andrzej, The part of road 6 that is avoided has many roundabouts. Maybe the Garmin algo doesn't like them? I'll try to find out if we can use the new knowledge regarding roundabouts to avoid using type 0x0c for them. Gerd
Date: Sat, 8 Mar 2014 22:56:47 +0100 From: popej@poczta.onet.pl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] new branch NOD127
Hi Gerd,
I have tested routing with trunk r3093 and nod127 r3095. I have used default style, car/motorcycle routing, fastest route. I can confirm, that both version show a detour on Polish road 6. It seems to depend on many factor so it is difficult to isolate a meaningful example.
Some notices:
In Mapsource route depends on "Road selection" option in route preferences. I usually set it in the middle but when set to 75% of "Prefer Highways", routing becomes better.
For nod127 branch there is difference in routing, when I set avoidances to unpaved road. It doesn't clear the problem, only detour is different.
In BaseCamp I got the same detour in both version of mkgmap. For nod127 detour changes, when I set avoidance to unpaved road, no change in trunk. In both version detour changes the same way if I set avoidances to residential streets. Any of highway avoidances changes detour and when I use avoid State Highways, route is correct. I'm not sure what is "State Highway" for BaseCamp, it could be primary road, which actually is used for route.
BaseCamp is not able to calculate longer route with trunk, the same route is calculated with nod127 (including detour).
Please write if you have any suggestion what could I test or what data could be useful for you.
-- Best regards, Andrzej _______________________________________________ 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
Hi Gerd,
If I comment the roundabout block in the lines file
See my first mail, I have tested roundabouts. Commenting the roundabout block clears problem, but if you instead change objects 0x0c into some other road, then problem remains. More precisely, I think route is correct, when roundabout get the same object as main road, but if roundabout is a different object (not necessary 0x0C), then calculation is wrong. Maybe reason is a turn angle? In my test detours contain roundabouts too. And if I set avoidance to roundabouts in BaseCamp, then detour changes, which suggest that roundabouts aren't the main reason of detour. I think mkgmap processes tag "junction=roundabout", even if there is no roundabout object 0x0C. After commenting the roundabout block, avoidance in BaseCamp still works. But avoidance doesn't work with following line in style: junction=roundabout & highway=* {delete junction} Side note: there is no verification of "class=" value. If I set "class=6" then mkgmap crashes with array index out of bounds exception. -- Best regards, Andrzej
Hi Andrzej, yes, mkgmap evaluates the tag "junction=roundabout", no matter what type the road gets. In trunk this is only used to decide if check-roundabout must be used, in the branch it is used to group all roundabouts at the beginning of table A. That's why I hoped that the type 0xc is not needed to get hints for the right exit point,but it did not work. Steve is looking at this. I'll add a check to make sure that class is in the range of 0-4 and speed goes from 0-7 . Gerd
Date: Sun, 9 Mar 2014 15:53:37 +0100 From: popej@poczta.onet.pl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] new branch NOD127
Hi Gerd,
If I comment the roundabout block in the lines file
See my first mail, I have tested roundabouts. Commenting the roundabout block clears problem, but if you instead change objects 0x0c into some other road, then problem remains.
More precisely, I think route is correct, when roundabout get the same object as main road, but if roundabout is a different object (not necessary 0x0C), then calculation is wrong. Maybe reason is a turn angle?
In my test detours contain roundabouts too. And if I set avoidance to roundabouts in BaseCamp, then detour changes, which suggest that roundabouts aren't the main reason of detour.
I think mkgmap processes tag "junction=roundabout", even if there is no roundabout object 0x0C. After commenting the roundabout block, avoidance in BaseCamp still works. But avoidance doesn't work with following line in style:
junction=roundabout & highway=* {delete junction}
Side note: there is no verification of "class=" value. If I set "class=6" then mkgmap crashes with array index out of bounds exception.
-- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, the reason of all this problems at Polish road 6 is a roundabout created as primary_link: http://www.openstreetmap.org/way/185413048 Sorry for waisting your time. The solution is to add links to roundabout block definition. -- Best regards, Andrzej
Hi Andrzej, I see. So the block should look like this? # Roundabouts junction=roundabout & (highway=trunk | highway=trunk_link) [0x0c road_class=3 road_speed=2 resolution 18] junction=roundabout & (highway=primary | highway=primary_link) [0x0c road_class=3 road_speed=2 resolution 19] junction=roundabout & (highway=secondary | highway=secondary_link) [0x0c road_class=2 road_speed=2 resolution 20] junction=roundabout & (highway=tertiary | highway=tertiary_link) [0x0c road_class=1 road_speed=1 resolution 21] junction=roundabout & highway=unclassified [0x0c road_class=1 road_speed=1 resolution 21] junction=roundabout [0x0c road_class=0 road_speed=1 resolution 22] Gerd
Date: Sun, 9 Mar 2014 17:54:32 +0100 From: popej@poczta.onet.pl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] new branch NOD127
Hi Gerd,
the reason of all this problems at Polish road 6 is a roundabout created as primary_link: http://www.openstreetmap.org/way/185413048
Sorry for waisting your time. The solution is to add links to roundabout block definition.
-- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd,
(highway=trunk | highway=trunk_link)
Yes, I have done exactly the same. I would like to see another change in default style, file "address". Maybe you could add this line before default mkgmap:region processing: mkgmap:country=POL & mkgmap:region!=* & mkgmap:admin_level4=* { set mkgmap:region='${mkgmap:admin_level4|subst:województwo =>}' } There is national character in "województwo", in UTF-8 this is C3h B3h. -- Best regards, Andrzej
Hi Andrzej, okay, done for the branch. Gerd
Date: Sun, 9 Mar 2014 18:40:29 +0100 From: popej@poczta.onet.pl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] new branch NOD127
Hi Gerd,
(highway=trunk | highway=trunk_link)
Yes, I have done exactly the same.
I would like to see another change in default style, file "address". Maybe you could add this line before default mkgmap:region processing:
mkgmap:country=POL & mkgmap:region!=* & mkgmap:admin_level4=* { set mkgmap:region='${mkgmap:admin_level4|subst:województwo =>}' }
There is national character in "województwo", in UTF-8 this is C3h B3h.
-- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd,
done for the branch.
Thanks! Style included in example\styles works correctly. Embedded default style works partially, mkgmap:region is set correctly but substitution for "województwo" doesn't work. It looks like internal style lost UTF-8 encoding. "Województwo" means voivodeship or province. -- Best regards, Andrzej
Hi Andrzej, please try the attached patch. Gerd
Date: Mon, 10 Mar 2014 18:14:32 +0100 From: popej@poczta.onet.pl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] new branch NOD127
Hi Gerd,
done for the branch.
Thanks!
Style included in example\styles works correctly. Embedded default style works partially, mkgmap:region is set correctly but substitution for "województwo" doesn't work. It looks like internal style lost UTF-8 encoding.
"Województwo" means voivodeship or province.
-- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Andrzej, good, committed with r3102. Gerd
Date: Mon, 10 Mar 2014 20:23:31 +0100 From: popej@poczta.onet.pl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] new branch NOD127
Hi Gerd,
please try the attached patch.
You make me learn java ;) Yes, this is the right correction.
-- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, On Mon, Mar 10, Gerd Petermann wrote:
good, committed with r3102.
Looks like r3102 does not compile: [javac] /usr/src/packages/BUILD/mkgmap-r3102/src/uk/me/parabola/mkgmap/osmstyle/JarFileLoader.java:133: error: unreported exception UnsupportedEncodingException; must be caught or declared to be thrown [javac] return new InputStreamReader(new BufferedInputStream(stream), "UTF-8"); [javac] ^ -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Hi Thorsten, thanks for reporting. Fixed with r3104. I'll probably commit another patch today regarding routing. Gerd
Date: Tue, 11 Mar 2014 09:10:12 +0100 From: kukuk@suse.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] new branch NOD127
Hi Gerd,
On Mon, Mar 10, Gerd Petermann wrote:
good, committed with r3102.
Looks like r3102 does not compile: [javac] /usr/src/packages/BUILD/mkgmap-r3102/src/uk/me/parabola/mkgmap/osmstyle/JarFileLoader.java:133: error: unreported exception UnsupportedEncodingException; must be caught or declared to be thrown [javac] return new InputStreamReader(new BufferedInputStream(stream), "UTF-8"); [javac] ^
-- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Andrzej, regarding version: you can use option --version, but mkgmap will then only print the version. If you have an img file you can use grep or findstr and search for the string mkgmap. Gerd popej wrote
Other note: could you add a message with version at the start of mkgmap? I already have so many version that I'm not always sure which one is running.
-- View this message in context: http://gis.19327.n5.nabble.com/new-branch-NOD127-tp5798806p5798894.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
I have generated a map using NOD127 branch - for me the routing results are about the same, if not slightly worse. Using shorter distance option, there seems to be a bit higher focus on using fast roads. Also there are more turns than on trunk in the routes - and more often little detours to get on a "better" road. But well, my styles are anything but standard. Else I couldn't notice anything. Just like using trunk - Mapsource produced some crashes - this didn't hapen for me using mkgmap as of mid December (didn't update since then till now). It's not crashing Mapsource fully, but Error Code 3 and go again... I cannot find out any reason for it however (happens about 1 in 10 long distance routes. If I change the split or something in the style, then it will happen somewhere else).
Hi Felix, it seems that we write invalid or wrong turn restriction in the branch. I can't say much more until now, but maybe a restriction is simply used at the wrong crossing. This can cause all kinds weird results. I am also not sure if this branch works as well with styles like yours which creates multiple routable ways for one street, as this is not used in the Garmin maps that I know. Gerd Felix Hartmann-2 wrote
I have generated a map using NOD127 branch - for me the routing results are about the same, if not slightly worse. Using shorter distance option, there seems to be a bit higher focus on using fast roads. Also there are more turns than on trunk in the routes - and more often little detours to get on a "better" road.
But well, my styles are anything but standard.
Else I couldn't notice anything. Just like using trunk - Mapsource produced some crashes - this didn't hapen for me using mkgmap as of mid December (didn't update since then till now). It's not crashing Mapsource fully, but Error Code 3 and go again... I cannot find out any reason for it however (happens about 1 in 10 long distance routes. If I change the split or something in the style, then it will happen somewhere else). _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/new-branch-NOD127-tp5798806p5799018.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi, On Thu, Mar 06, Gerd Petermann wrote:
Hi all,
I've created a new branch NOD127 : http://www.mkgmap.org.uk/download/mkgmap-NOD127-r3086.zip
This is used to test the latest findings regarding the NOD file format. Most of it is understood now, thanks to Steve and his display tool :-)
I made quite some tests the last two days with it. In principle the result is much better then with trunk, but sometimes I see really bad choices, like leaving a highway and using a primary/secondary street only to go back to the highway a little bit later. Or using highways which are much longer then the direct highway. What I found out: this happens always if the direct route would cross a tile border. And I'm not sure if this is really only a problem of the branch, because I can now see similar problems on trunk, too :( I have two styles: "streets", which contains only bigger routes and very few POIs, thus has really big tiles. Here the routing is very good. The second style, "basemap", contains all streets and a huge amount of POIs, thus small tiles. Here I suddenly see similar problems. So looks like at some point we introduced a problem with routing via tile borders, at least with MapSource. I'm currently trying to find out when this got worse. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Hi Thorsten, thanks for the info. Please make sure to use r3095 or newer for your tests, previous versions contained a serious bug regarding route restrictions. Gerd
Date: Sun, 9 Mar 2014 09:26:55 +0100 From: kukuk@suse.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] new branch NOD127
Hi,
On Thu, Mar 06, Gerd Petermann wrote:
Hi all,
I've created a new branch NOD127 : http://www.mkgmap.org.uk/download/mkgmap-NOD127-r3086.zip
This is used to test the latest findings regarding the NOD file format. Most of it is understood now, thanks to Steve and his display tool :-)
I made quite some tests the last two days with it.
In principle the result is much better then with trunk, but sometimes I see really bad choices, like leaving a highway and using a primary/secondary street only to go back to the highway a little bit later. Or using highways which are much longer then the direct highway. What I found out: this happens always if the direct route would cross a tile border. And I'm not sure if this is really only a problem of the branch, because I can now see similar problems on trunk, too :(
I have two styles: "streets", which contains only bigger routes and very few POIs, thus has really big tiles. Here the routing is very good. The second style, "basemap", contains all streets and a huge amount of POIs, thus small tiles. Here I suddenly see similar problems. So looks like at some point we introduced a problem with routing via tile borders, at least with MapSource. I'm currently trying to find out when this got worse.
Thorsten
-- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Thorsten, Steve saw similar problems regarding tile boundaries. He used an older version of MapSource (6.10.?) and maybe tiles that were not split properly. His problems were gone after updating to MapSource 6.16.3 and using a new split. Gerd
Date: Sun, 9 Mar 2014 09:26:55 +0100 From: kukuk@suse.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] new branch NOD127
Hi,
On Thu, Mar 06, Gerd Petermann wrote:
Hi all,
I've created a new branch NOD127 : http://www.mkgmap.org.uk/download/mkgmap-NOD127-r3086.zip
This is used to test the latest findings regarding the NOD file format. Most of it is understood now, thanks to Steve and his display tool :-)
I made quite some tests the last two days with it.
In principle the result is much better then with trunk, but sometimes I see really bad choices, like leaving a highway and using a primary/secondary street only to go back to the highway a little bit later. Or using highways which are much longer then the direct highway. What I found out: this happens always if the direct route would cross a tile border. And I'm not sure if this is really only a problem of the branch, because I can now see similar problems on trunk, too :(
I have two styles: "streets", which contains only bigger routes and very few POIs, thus has really big tiles. Here the routing is very good. The second style, "basemap", contains all streets and a huge amount of POIs, thus small tiles. Here I suddenly see similar problems. So looks like at some point we introduced a problem with routing via tile borders, at least with MapSource. I'm currently trying to find out when this got worse.
Thorsten
-- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On Sun, Mar 09, Gerd Petermann wrote:
Hi Thorsten,
Steve saw similar problems regarding tile boundaries. He used an older version of MapSource (6.10.?) and maybe tiles that were not split properly. His problems were gone after updating to MapSource 6.16.3 and using a new split.
Ah, ok, then you can ignore my findings and I will redo the tests. I used MapSource 6.15.7, because 6.16.x had quite some problems when I installed it ages ago. With 6.16.3 it looks pretty good now. But I wonder why I see the problems with MapSource 6.15.7 only now suddenly, it worked very good for me for a long time. Between, I used splitter r319 and mkgmap r3095. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Hi Thorsten, great! Trunk already contains some major fixes regarding routing, because I used the high-prec-coord branch to test them. I guess that it is also a good idea to update the firmware on the device. Gerd Thorsten Kukuk wrote
On Sun, Mar 09, Gerd Petermann wrote:
Hi Thorsten,
Steve saw similar problems regarding tile boundaries. He used an older version of MapSource (6.10.?) and maybe tiles that were not split properly. His problems were gone after updating to MapSource 6.16.3 and using a new split.
Ah, ok, then you can ignore my findings and I will redo the tests. I used MapSource 6.15.7, because 6.16.x had quite some problems when I installed it ages ago. With 6.16.3 it looks pretty good now. But I wonder why I see the problems with MapSource 6.15.7 only now suddenly, it worked very good for me for a long time.
Between, I used splitter r319 and mkgmap r3095.
Thorsten
-- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/new-branch-NOD127-tp5798806p5799168.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
participants (6)
-
Andrzej Popowski -
Felix Hartmann -
Gerd Petermann -
GerdP
-
Minko -
Thorsten Kukuk