dissapearing roads
Hi! Today I've noticed a very strange behavior of mkgmap. Consider this road: http://www.openstreetmap.org/#map=16/52.0071/20.2446 it's a tertiary road. My rules for tertiary roads are: highway=tertiary {set mkgmap:no_name=yes} [0x1101d resolution 18-18 continue] highway=tertiary {set mkgmap:no_name=yes} [0x1101b resolution 20-20 continue] highway=tertiary {set mkgmap:no_name=yes} [0x1101b resolution 21-21 continue] highway=tertiary {set mkgmap:no_name=yes} [0x05 resolution 22-22 continue] highway=tertiary {name '${name}'} [0x05 road_class=1 road_speed=3 resolution 23] (if mkgmap:no_name is set, <finalize> scripts are not executed, so name for road is not assigned). As you may suppose, tertiary roads should be seen on almost any zoom level. MapSource on 300m (level 23) zoom: http://imgur.com/LHptaRJ MapSource on 500m (level 22) zoom: http://imgur.com/1Aa4SL9 Part of the road disappears...... This is not related to any possible MapSource or Garmin (tested on hardware) bug with road rendering. I opened IMG file in MapEdit and it really this lacks road on levels 18-22. I found that this bug is related to --preserve-element-order parameter. When it's set - everything is fine. Without it, road disappears. best regards Michal Rogala
Hi Michał,
Consider this road: http://www.openstreetmap.org/#map=16/52.0071/20.2446
There seems to be a bug in OSM data there, there are 2 ways overlaid, see: http://www.openstreetmap.org/way/176844915#map=15/52.0021/20.2465 http://www.openstreetmap.org/way/260842529#map=15/52.0022/20.2465 -- Best regards, Andrzej
-- View this message in context: http://gis.19327.n5.nabble.com/dissapearing-roads-tp5800690p5800695.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Andrzej,
There seems to be a bug in OSM data there, there are 2 ways overlaid, see: http://www.openstreetmap.org/way/176844915#map=15/52.0021/20.2465 http://www.openstreetmap.org/way/260842529#map=15/52.0022/20.2465
This might explain that the problem is related to --preserve-element-order, but it doesn't explain the problem itself. BTW: Way 176844915 was already removed. Gerd
Hi All I must admit I am an infrequent updater of the version of mkgmap and also use my own style and typ file that is gradually varying from the standard style and typ files. Also while subscribed to this group 99% of the posting are past my level of knowledge. Anyway, when upgrading from version r2718 to r3118 the following error message appeared with no img file been created. Error in style: Error: invalid type 0x6508 for POLYGON in style file inc\water_polygons, line 14 The type 0x6508 is a type that I added in the style file Waterfall [BER 01.07.2013]# --------------------------natural=waterfall | waterway=waterfall [0x6508 resolution 20] Also I modified the typ file "borrowing" on another's work so this appears [_point]Type=0x065SubType=0x08String1=0x04,WaterfallExtendedLabels=YFontStyle=NormalFontCustomColor=NoDayXpm="16 16 8 1" Colormode=16"! c #101010""# c #0065FF""% c #39CAD5""? c #FFFFFF""$ c #399541""* c #7BFFD5""= c #7B656A"" c none"" ""$$?????????$$$$$""=!!???????!!!!!!""!=!!?????!!=!=!=""=!=!!?%%?!=!=!=!""!=!=!?%%?=!=!=!=""=!=!!?%%?!=!=!=!""!=!=!?%%?!!=!=!=""=!=!??%*%?=!=!=!""!=!??%**%?!=!=!=""!!??****%%??=!=!""#??******???!!!!""##????????######""################""################""################";1234567890123456[end] I notice that the above is a point of interest (single node) but i have put it in the polygon file. With version r2718 everything worked well, but with r3118, or possibly earlier versions something has crept in that is producing the error. As always, any help or pointers would be handy. Cheers Brett RussellTasmania - Australia
Modern Garmin TOPOs do not seem to include subtypes if value is <&100. You have 65 with subtype 08 I am surprised 6508 got rendered before. I have seen examples of 4b01, 5002 etc in old topo typ files but I've never been able to use them with any version of mkgmap -- View this message in context: http://gis.19327.n5.nabble.com/dissapearing-roads-tp5800690p5800725.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi As mentioned the waterfall rendering of a 6508 worked a treat rendering as per the custom graphic. Need to see how it now looks as I can now generate a img. I use a Garmin 62s and Rino 650. Hopefully, the waterfalls will still show as POI. Cheers Brett Russell 237 Oldaker Street Devonport Tas 7310 Phone: (03) 6424 8033 Mobile: 0419 374 971
On 23 Mar 2014, at 9:36 pm, "nwillink" <osm@pinns.co.uk> wrote:
Modern Garmin TOPOs do not seem to include subtypes if value is <&100. You have 65 with subtype 08 I am surprised 6508 got rendered before.
I have seen examples of 4b01, 5002 etc in old topo typ files but I've never been able to use them with any version of mkgmap
-- View this message in context: http://gis.19327.n5.nabble.com/dissapearing-roads-tp5800690p5800725.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi all This has been mentioned before but hoping that someone has had a chance to investigate why POI searches work on some Garmins, and not on others. We have a growing collection of Garmins and have noticed the following. 62s the search works but slowly. Could be a unit slow processor issue. Fenix. Well anything can happen from the unit hanging to working. Me think that I am being rather ambitious expecting it to work on the searches. Rino 650, search does not work. Oregon 450, a new unit to us, but works well. Be great if the reversed engineering could examine why mkgmap works on some Garmins but not on others. At least identify "good" Garmins would be a start. We are also trying to identify routing issues between units but have held off until I updated to the latest version of mkgmap. Gradually getting my act together to update mkgmap more frequently so be better placed to test the releases. Cheers Brett Russell PO Box 94 Launceston Tas. 7250 Australia 0419 374 971
On 23 Mar 2014, at 11:37 pm, "Brett Russell" <brussell237@live.com.au> wrote:
Hi
As mentioned the waterfall rendering of a 6508 worked a treat rendering as per the custom graphic. Need to see how it now looks as I can now generate a img. I use a Garmin 62s and Rino 650. Hopefully, the waterfalls will still show as POI.
Cheers
Brett Russell 237 Oldaker Street Devonport Tas 7310
Phone: (03) 6424 8033 Mobile: 0419 374 971
On 23 Mar 2014, at 9:36 pm, "nwillink" <osm@pinns.co.uk> wrote:
Modern Garmin TOPOs do not seem to include subtypes if value is <&100. You have 65 with subtype 08 I am surprised 6508 got rendered before.
I have seen examples of 4b01, 5002 etc in old topo typ files but I've never been able to use them with any version of mkgmap
-- View this message in context: http://gis.19327.n5.nabble.com/dissapearing-roads-tp5800690p5800725.html Sent from the Mkgmap Development mailing list archive at Nabble.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
Hi, On Mon, Mar 24, Brett Russell wrote:
62s the search works but slowly. Could be a unit slow processor issue.
To me it looks like the 62s does not use the global index for POIs, but is looking in every single tile for all POIs, even the one which are not in the index. You can see that very nice if you compare the results with the same map on a 60CSx and a 62s. To make the search on a 62s faster: Do a reset after every map update. This does at least solved the problem for me in the past (but I used a firmware version without activity routing, I haven't looked at it with a current firmware version). 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 With the reset does it remove all maps? I have the unit also loaded with Garmin's maps and Shonkymaps, a project that used the 1:250,000 maps as a base. Would like to keep them without having to re-install them as I update mkgmaps frequently. Also might try the reset with the Rino 650. Brett Russell 237 Oldaker Street Devonport Tas 7310 Phone: (03) 6424 8033 Mobile: 0419 374 971
On 24 Mar 2014, at 5:15 pm, "Thorsten Kukuk" <kukuk@suse.de> wrote:
Hi,
On Mon, Mar 24, Brett Russell wrote:
62s the search works but slowly. Could be a unit slow processor issue.
To me it looks like the 62s does not use the global index for POIs, but is looking in every single tile for all POIs, even the one which are not in the index. You can see that very nice if you compare the results with the same map on a 60CSx and a 62s.
To make the search on a 62s faster: Do a reset after every map update. This does at least solved the problem for me in the past (but I used a firmware version without activity routing, I haven't looked at it with a current firmware version).
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 Mon, Mar 24, Brett Russell wrote:
Hi
With the reset does it remove all maps?
No, that's why I wrote "after updating the maps". The reset cleans up the internal, not accessible cache of the 62s. I know that the 62s is telling you that all user data will be removed, but that's wrong. Thorsten
I have the unit also loaded with Garmin's maps and Shonkymaps, a project that used the 1:250,000 maps as a base. Would like to keep them without having to re-install them as I update mkgmaps frequently.
Also might try the reset with the Rino 650.
Brett Russell 237 Oldaker Street Devonport Tas 7310
Phone: (03) 6424 8033 Mobile: 0419 374 971
On 24 Mar 2014, at 5:15 pm, "Thorsten Kukuk" <kukuk@suse.de> wrote:
Hi,
On Mon, Mar 24, Brett Russell wrote:
62s the search works but slowly. Could be a unit slow processor issue.
To me it looks like the 62s does not use the global index for POIs, but is looking in every single tile for all POIs, even the one which are not in the index. You can see that very nice if you compare the results with the same map on a 60CSx and a 62s.
To make the search on a 62s faster: Do a reset after every map update. This does at least solved the problem for me in the past (but I used a firmware version without activity routing, I haven't looked at it with a current firmware version).
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
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- 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 prompt reply and the means to speed things up. Much appreciated. I will give it a go and see how things improve. I am running the current firmware on the 62s. Thanks Brett
Date: Mon, 24 Mar 2014 10:23:32 +0100 From: kukuk@suse.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] POI search - Garmin model related.
On Mon, Mar 24, Brett Russell wrote:
Hi
With the reset does it remove all maps?
No, that's why I wrote "after updating the maps". The reset cleans up the internal, not accessible cache of the 62s. I know that the 62s is telling you that all user data will be removed, but that's wrong.
Thorsten
I have the unit also loaded with Garmin's maps and Shonkymaps, a project that used the 1:250,000 maps as a base. Would like to keep them without having to re-install them as I update mkgmaps frequently.
Also might try the reset with the Rino 650.
Brett Russell 237 Oldaker Street Devonport Tas 7310
Phone: (03) 6424 8033 Mobile: 0419 374 971
On 24 Mar 2014, at 5:15 pm, "Thorsten Kukuk" <kukuk@suse.de> wrote:
Hi,
On Mon, Mar 24, Brett Russell wrote:
62s the search works but slowly. Could be a unit slow processor issue.
To me it looks like the 62s does not use the global index for POIs, but is looking in every single tile for all POIs, even the one which are not in the index. You can see that very nice if you compare the results with the same map on a 60CSx and a 62s.
To make the search on a 62s faster: Do a reset after every map update. This does at least solved the problem for me in the past (but I used a firmware version without activity routing, I haven't looked at it with a current firmware version).
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
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- 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
thanks! I didn't notice this bug in OSM :) But I have similar situation here: http://www.openstreetmap.org/#map=17/52.18345/21.00293 those 2 one-way lanes of Domaniewska street. Problem appears in Garmin on resolution 21. Here it's ok: http://imgur.com/1HZgGEE Here it's not: http://imgur.com/qIP203L This also happens on secondary roads: http://imgur.com/rS6tYO5 Each time disputed road has two separate lanes. My theory is that at lower coordinate resolution those lanes appear at the same position and due to some conflict they're not put on a map. Regarding no_name tag - I did something like this: highway=tertiary {set mkgmap:no_name=yes} [0x05 resolution 22-22 continue] [a lot of other rules] <finalize> highway=* & mkgmap:no_name!=* {name '${name}' | '${ref}'} This allows me to control road labelling at each level so maps are not overloaded with text at lower levels. It's more convenient than creating custom lines with 'no label' in TYP. best regards Michal Rogala 2014-03-23 0:11 GMT+01:00 Andrzej Popowski <popej@poczta.onet.pl>:
Hi Gerd,
BTW: Way 176844915 was already removed.
Community at work. I'm not a mapper, but I have put a notice there and someone corrected.
-- Best regards, Andrzej
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Michal, I was not able to reproduce the problem. Please try if you can reproduce it with a few changes to the default style. If yes, please let us know how. Or post the mkgmap options you are using and a link to your style files. Gerd Michał Rogala wrote
thanks!
I didn't notice this bug in OSM :)
But I have similar situation here:
http://www.openstreetmap.org/#map=17/52.18345/21.00293
those 2 one-way lanes of Domaniewska street. Problem appears in Garmin on resolution 21.
Here it's ok:
Here it's not:
This also happens on secondary roads:
Each time disputed road has two separate lanes. My theory is that at lower coordinate resolution those lanes appear at the same position and due to some conflict they're not put on a map.
Regarding no_name tag - I did something like this:
highway=tertiary {set mkgmap:no_name=yes} [0x05 resolution 22-22 continue]
[a lot of other rules] <finalize> highway=* & mkgmap:no_name!=* {name '${name}' | '${ref}'}
This allows me to control road labelling at each level so maps are not overloaded with text at lower levels. It's more convenient than creating custom lines with 'no label' in TYP.
best regards
Michal Rogala
2014-03-23 0:11 GMT+01:00 Andrzej Popowski <
popej@.onet
>:
Hi Gerd,
BTW: Way 176844915 was already removed.
Community at work. I'm not a mapper, but I have put a notice there and someone corrected.
-- Best regards, Andrzej
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/dissapearing-roads-tp5800690p5800752.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Michał,
But I have similar situation here: http://www.openstreetmap.org/#map=17/52.18345/21.00293
This part of Domaniewska street doesn't exist in OSM data anymore. Weird. -- Best regards, Andrzej
Hi Andrzej, no problem, I have saved the data for the previous example before the error was fixed. I see only one routine which might remove a line: If the two equal roads are merged by the LineMergeFilter they form a spike. The RemoveObsoletePointsFilter has code to remove a spike, but this should only happen for shapes. Maybe it has an error, but it is difficult to find that without proper test case. I assume that it is important to have the same input data and style to reproduce the problem. Gerd popej wrote
Hi Michał,
But I have similar situation here: http://www.openstreetmap.org/#map=17/52.18345/21.00293
This part of Domaniewska street doesn't exist in OSM data anymore. Weird.
-- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/dissapearing-roads-tp5800690p5800756.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi! I indeed unintentionally deleted part of Domaniewska in OSM. It should be ok now. At lower Garmin resolutions I use custom line types - like 0x11010, 0x11011, 0x1101b and 0x1101d. That may be a reason why you can't reproduce this error. I'll try to reproduce it on default style using those codes. best regards Michal Rogala 2014-03-23 19:11 GMT+01:00 GerdP <gpetermann_muenchen@hotmail.com>:
Hi Andrzej,
no problem, I have saved the data for the previous example before the error was fixed. I see only one routine which might remove a line: If the two equal roads are merged by the LineMergeFilter they form a spike. The RemoveObsoletePointsFilter has code to remove a spike, but this should only happen for shapes. Maybe it has an error, but it is difficult to find that without proper test case. I assume that it is important to have the same input data and style to reproduce the problem.
Gerd
popej wrote
Hi Michał,
But I have similar situation here: http://www.openstreetmap.org/#map=17/52.18345/21.00293
This part of Domaniewska street doesn't exist in OSM data anymore. Weird.
-- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/dissapearing-roads-tp5800690p5800756.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Michal, You said that GPSMapEdit shows that the way is really missing. I saw lines with the types you use (0x1101b and 0x1101d), both with and without --preserve-element-order. My idea if mkgmap is not the problem: If two lines with identical points and types are rendered by Garmin tools, maybe they nullify each other. It is easy to detect that case in mkgmap, but probably CPU intensive. Gerd Michał Rogala wrote
Hi!
I indeed unintentionally deleted part of Domaniewska in OSM. It should be ok now. At lower Garmin resolutions I use custom line types - like 0x11010, 0x11011, 0x1101b and 0x1101d. That may be a reason why you can't reproduce this error. I'll try to reproduce it on default style using those codes.
best regards
Michal Rogala
2014-03-23 19:11 GMT+01:00 GerdP <
gpetermann_muenchen@
>:
Hi Andrzej,
no problem, I have saved the data for the previous example before the error was fixed. I see only one routine which might remove a line: If the two equal roads are merged by the LineMergeFilter they form a spike. The RemoveObsoletePointsFilter has code to remove a spike, but this should only happen for shapes. Maybe it has an error, but it is difficult to find that without proper test case. I assume that it is important to have the same input data and style to reproduce the problem.
Gerd
popej wrote
Hi Michał,
But I have similar situation here: http://www.openstreetmap.org/#map=17/52.18345/21.00293
This part of Domaniewska street doesn't exist in OSM data anymore. Weird.
-- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/dissapearing-roads-tp5800690p5800756.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/dissapearing-roads-tp5800690p5800765.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
2014-03-23 21:03 GMT+01:00 GerdP <gpetermann_muenchen@hotmail.com>:
Hi Michal,
You said that GPSMapEdit shows that the way is really missing. I saw lines with the types you use (0x1101b and 0x1101d), both with and without --preserve-element-order.
Hi! Here is part of Domaniewska street missing at Level 3: http://imgur.com/EhvRxqJ Selected (purple) roads are type 0x1101b. Missing part should also be 0x1101b (best seen when you force level by pressing "3" on the keyboard in MapEdit). best regards Michal Rogala
If you wan't to reproduce this bug, modify default style in that way: 1) Remove highway=tertiary [0x05 road_class=1 road_speed=3 resolution 23] 2) Replace it with: highway=tertiary [0x05 resolution 20-20 continue] highway=tertiary [0x05 resolution 21-21 continue] highway=tertiary [0x05 resolution 22-22 continue] highway=tertiary [0x05 road_class=1 road_speed=3 resolution 23] Proof: http://imgur.com/j4EdLUd http://imgur.com/NaQvmKV :) best regards Michal Rogala 2014-03-23 22:03 GMT+01:00 Michał Rogala <michal.rogala@gmail.com>:
2014-03-23 21:03 GMT+01:00 GerdP <gpetermann_muenchen@hotmail.com>:
Hi Michal,
You said that GPSMapEdit shows that the way is really missing. I saw lines with the types you use (0x1101b and 0x1101d), both with and without --preserve-element-order.
Hi!
Here is part of Domaniewska street missing at Level 3:
Selected (purple) roads are type 0x1101b. Missing part should also be 0x1101b
(best seen when you force level by pressing "3" on the keyboard in MapEdit).
best regards
Michal Rogala
Hi Michal, okay, now I was able to reproduce it, don't know what I did wrong before, the problem occurs also with the default style, typically for motorways in the overview map. This is what happens: You have two ways with equal attributes like name, type etc. Both ways share one or more points, but they are going in opposite directions, but they share not all points. The LineMergeFilter doesn't care about direction and merges the two lines. This creates a line with a spike, Simple case: Line1 : a->b->c Line2: b<-c Result after merge: a,b,c,b The DouglasPeuckerFilter removes the spike between a and the last b when the error is within the tolerance, so the remaining line is a->b instead of a->c In the worst case, a long way with an almost equal long spike is "simplified" to a much shorter way. In older releases this situation was handled by "preserving" the merge point in LineMergeFilter, so that the DP filter did not make this error. I removed that feature because the "preserved" flag was stored within the point object and was used for all higher resolutions and also for all other lines or shapes referencing that point. The effect is that the DP filter did not work as well as possible. Of course I did not think about the above problem :-( I am not yet sure how to fix this problem. I guess I should try to detect the spike before executing the DP filter, or find a better variant of the preserved points, or change LineMergeFilter to avoid merging lines when that creates a spike. Have to get some more sleep now... Gerd Date: Sun, 23 Mar 2014 23:14:10 +0100 From: michal.rogala@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] dissapearing roads If you wan't to reproduce this bug, modify default style in that way: 1) Remove highway=tertiary [0x05 road_class=1 road_speed=3 resolution 23] 2) Replace it with: highway=tertiary [0x05 resolution 20-20 continue] highway=tertiary [0x05 resolution 21-21 continue] highway=tertiary [0x05 resolution 22-22 continue] highway=tertiary [0x05 road_class=1 road_speed=3 resolution 23] Proof: http://imgur.com/j4EdLUd http://imgur.com/NaQvmKV :) best regards Michal Rogala 2014-03-23 22:03 GMT+01:00 Michał Rogala <michal.rogala@gmail.com>: 2014-03-23 21:03 GMT+01:00 GerdP <gpetermann_muenchen@hotmail.com>: Hi Michal, You said that GPSMapEdit shows that the way is really missing. I saw lines with the types you use (0x1101b and 0x1101d), both with and without --preserve-element-order. Hi! Here is part of Domaniewska street missing at Level 3: http://imgur.com/EhvRxqJ Selected (purple) roads are type 0x1101b. Missing part should also be 0x1101b (best seen when you force level by pressing "3" on the keyboard in MapEdit). best regards Michal Rogala _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
ok, thanks for any solution :) best regards Michal Rogala 2014-03-24 5:32 GMT+01:00 Gerd Petermann <gpetermann_muenchen@hotmail.com>:
Hi Michal,
okay, now I was able to reproduce it, don't know what I did wrong before, the problem occurs also with the default style, typically for motorways in the overview map.
This is what happens: You have two ways with equal attributes like name, type etc. Both ways share one or more points, but they are going in opposite directions, but they share not all points. The LineMergeFilter doesn't care about direction and merges the two lines. This creates a line with a spike, Simple case: Line1 : a->b->c Line2: b<-c Result after merge: a,b,c,b The DouglasPeuckerFilter removes the spike between a and the last b when the error is within the tolerance, so the remaining line is a->b instead of a->c
In the worst case, a long way with an almost equal long spike is "simplified" to a much shorter way.
In older releases this situation was handled by "preserving" the merge point in LineMergeFilter, so that the DP filter did not make this error. I removed that feature because the "preserved" flag was stored within the point object and was used for all higher resolutions and also for all other lines or shapes referencing that point. The effect is that the DP filter did not work as well as possible. Of course I did not think about the above problem :-(
I am not yet sure how to fix this problem. I guess I should try to detect the spike before executing the DP filter, or find a better variant of the preserved points, or change LineMergeFilter to avoid merging lines when that creates a spike. Have to get some more sleep now...
Gerd
------------------------------ Date: Sun, 23 Mar 2014 23:14:10 +0100 From: michal.rogala@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] dissapearing roads
If you wan't to reproduce this bug, modify default style in that way:
1) Remove
highway=tertiary [0x05 road_class=1 road_speed=3 resolution 23]
2) Replace it with:
highway=tertiary [0x05 resolution 20-20 continue] highway=tertiary [0x05 resolution 21-21 continue] highway=tertiary [0x05 resolution 22-22 continue] highway=tertiary [0x05 road_class=1 road_speed=3 resolution 23]
Proof:
http://imgur.com/j4EdLUd http://imgur.com/NaQvmKV
:)
best regards
Michal Rogala
2014-03-23 22:03 GMT+01:00 Michał Rogala <michal.rogala@gmail.com>:
2014-03-23 21:03 GMT+01:00 GerdP <gpetermann_muenchen@hotmail.com>:
Hi Michal,
You said that GPSMapEdit shows that the way is really missing. I saw lines with the types you use (0x1101b and 0x1101d), both with and without --preserve-element-order.
Hi!
Here is part of Domaniewska street missing at Level 3:
Selected (purple) roads are type 0x1101b. Missing part should also be 0x1101b
(best seen when you force level by pressing "3" on the keyboard in MapEdit).
best regards
Michal Rogala
_______________________________________________ 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,
The LineMergeFilter doesn't care about direction and merges the two lines.
In my opinion roads that create acute angle shouldn't be merged unless node has only 2 ways attached. I think processing of angle is essential for a good merging, see old discussion: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2013q3/018648.html BTW: does D-P algorithm remove spikes? -- Best regards, Andrzej
Hi Andrtzej, we are not talking about routable ways here, just lines at rather low resolutions. The problem is caused by the fact that our DP algo calculates the perpendicular distance to the line created by start and end point of a line. In case of a horizontal line with points a,b,c,d,c,b it calculates distance 0 for the points c and d and removes them. What we need is an algo that computes the shortest distance between a point and the line a. Working on that... Gerd
Date: Mon, 24 Mar 2014 19:03:17 +0100 From: popej@poczta.onet.pl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] dissapearing roads
Hi Gerd,
The LineMergeFilter doesn't care about direction and merges the two lines.
In my opinion roads that create acute angle shouldn't be merged unless node has only 2 ways attached. I think processing of angle is essential for a good merging, see old discussion: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2013q3/018648.html
BTW: does D-P algorithm remove spikes?
-- Best regards, Andrzej
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd,
we are not talking about routable ways here, just lines at rather low resolutions.
I think you could simply disable merging at lower resolution, since ways are already merged at layer 0. But if you want to get additional merging then still processing angle would be beneficial.
DP algo calculates the perpendicular distance to the line
I see, it is a problem there. -- Best regards, Andrzej
Hi Andrzej,
I think you could simply disable merging at lower resolution, since ways are already merged at layer 0. But if you want to get additional merging then still processing angle would be beneficial.
dont't think so :mkgmap starts to write the lowest resolution, ends with the highest. For each resolution we can see different combinations of lines. Anyway, the new algo seems to work, I'll post a patch soon. Gerd
Hi all, attached is a patch with a modified DouglasPeuckerFilter to solve the problem with "disappearing roads". I see only small differences in the maps, so I hope it doesn't introduce any side effects. The problem occured when - due the rounding of coordinates to low resolutions - a line is converted to a straight line with a spike. This is not directly related to mergeLines, but is more likely to happen with it. If I hear no complains I'll commit that patch on wednesday. Compiled binary based on trunk r3118: http://files.mkgmap.org.uk/download/191/mkgmap.jar Gerd From: gpetermann_muenchen@hotmail.com To: mkgmap-dev@lists.mkgmap.org.uk Date: Mon, 24 Mar 2014 19:50:52 +0100 Subject: Re: [mkgmap-dev] dissapearing roads Hi Andrzej,
I think you could simply disable merging at lower resolution, since ways are already merged at layer 0. But if you want to get additional merging then still processing angle would be beneficial.
dont't think so :mkgmap starts to write the lowest resolution, ends with the highest. For each resolution we can see different combinations of lines. Anyway, the new algo seems to work, I'll post a patch soon. Gerd _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Looks good Gerd, Havent noticed it before but there were quite a few roads with gaps on lower zoom levels and the gaps are gone now.
Hi all,
attached is a patch with a modified DouglasPeuckerFilter to solve the problem with "disappearing roads". I see only small differences in the maps, so I hope it doesn't introduce any side effects.
The problem occured when - due the rounding of coordinates to low resolutions - a line is converted to a straight line with a spike. This is not directly related to mergeLines, but is more likely to happen with it.
If I hear no complains I'll commit that patch on wednesday. Compiled binary based on trunk r3118: http://files.mkgmap.org.uk/download/191/mkgmap.jar
Gerd
Hi Minko, thanks for testing. I always noticed the gaps, but I assumed that the all these ways were too short to be rendered. I think for the default style this is still true for many of the gaps. Gerd
Date: Tue, 25 Mar 2014 11:00:21 +0100 From: ligfietser@online.nl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] dissapearing roads
Looks good Gerd, Havent noticed it before but there were quite a few roads with gaps on lower zoom levels and the gaps are gone now.
Hi all,
attached is a patch with a modified DouglasPeuckerFilter to solve the problem with "disappearing roads". I see only small differences in the maps, so I hope it doesn't introduce any side effects.
The problem occured when - due the rounding of coordinates to low resolutions - a line is converted to a straight line with a spike. This is not directly related to mergeLines, but is more likely to happen with it.
If I hear no complains I'll commit that patch on wednesday. Compiled binary based on trunk r3118: http://files.mkgmap.org.uk/download/191/mkgmap.jar
Gerd
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi! I've tested your patch on my maps and it works great :). Thanks a lot for fixing it. Best regards Michal Rogala 2014-03-25 12:49 GMT+01:00 Gerd Petermann <gpetermann_muenchen@hotmail.com>:
Hi Minko,
thanks for testing. I always noticed the gaps, but I assumed that the all these ways were too short to be rendered. I think for the default style this is still true for many of the gaps.
Gerd
Date: Tue, 25 Mar 2014 11:00:21 +0100 From: ligfietser@online.nl To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] dissapearing roads
Looks good Gerd, Havent noticed it before but there were quite a few roads with gaps on lower zoom levels and the gaps are gone now.
Hi all,
attached is a patch with a modified DouglasPeuckerFilter to solve the problem with "disappearing roads". I see only small differences in the maps, so I hope it doesn't introduce any side effects.
The problem occured when - due the rounding of coordinates to low resolutions - a line is converted to a straight line with a spike. This is not directly related to mergeLines, but is more likely to happen with it.
If I hear no complains I'll commit that patch on wednesday. Compiled binary based on trunk r3118: http://files.mkgmap.org.uk/download/191/mkgmap.jar
Gerd
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
Crap, probably JOSM unintentionally saved my changes. I'll try to fix it. Thaks for info. MR 23 mar 2014 18:56 "Andrzej Popowski" <popej@poczta.onet.pl> napisał(a):
Hi Michał,
But I have similar situation here: http://www.openstreetmap.org/#map=17/52.18345/21.00293
This part of Domaniewska street doesn't exist in OSM data anymore. Weird.
-- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
If you are using typviewer polygons like 6508 ,6507,6508 and ofcourse 6500 will have their draworder types set to 6500 and yet the draworder levels match the ones specified Perhaps a device looking for 6508 will settle for the first draworder found for a 6500 ...? More than likely its a Garmin bug corrected by typviewer and so the draworder defaults to zero. Polygons with out transparency can have zero draworders as seen in many city nav typ files and yours might have been correctly parsed. Also,in my experience,if your waterfall had transparency, giving this polygon a zero draworder can lead to unexpected results. However, no 2 devices are the same -- View this message in context: http://gis.19327.n5.nabble.com/dissapearing-roads-tp5800690p5800753.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Michal, Michał Rogala wrote
(if mkgmap:no_name is set, <finalize> scripts are not executed, so name for road is not assigned).
what does that mean? How does that section look like? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/dissapearing-roads-tp5800690p5800693.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
participants (8)
-
Andrzej Popowski -
Brett Russell -
Gerd Petermann -
GerdP
-
Michał Rogala -
Minko -
nwillink -
Thorsten Kukuk