order of lines / roads
Hi all, beginning with r2448 I've committed changes which had an influence on the order of lines and and roads. This was not intended, just a side effect. I was not aware that this has an effect on overlaid objects, see e.g. http://gis.19327.n5.nabble.com/Commit-r2567-roads-first-v1-patch-Make-sure-t... The problems occurs because we have to colllect all roads first and separate them from other lines. Up to r2448 the option --preserve-element-order probably worked as expected: all objects were processed by the style in the order of appearance and they were also written in this order. Since r2448 the roads were either all written after the other lines or before. The "mkgmap:set_unconnected_type" feature is also likely to mix the order. Polygons were never effected by any of these changes. It looks quite complicated to implement the behaviour of r2448 again (also because the housenumber code needs the separation), so I wonder if it is acceptable to implement --preserve-element-order like this: we keep the order of roads and we keep the order of other ways, and we make sure that roads are added after the other ways. It would also be possible to add an option so that we add roads first if that is needed. Is this limitation a problem for anybody? Gerd
Hi, a few more remarks: 1) the relation processing also adds ways (those with the fake ids like 4611686018427387918). These are added after the normal OSM ways and the order is determined by algorithmns. 2) another possible solution might be to sort the lines by type before they are written to the img file. This would require an additional file giving the draw order of line types. Gerd From: gpetermann_muenchen@hotmail.com To: mkgmap-dev@lists.mkgmap.org.uk Date: Wed, 8 May 2013 10:09:21 +0200 Subject: [mkgmap-dev] order of lines / roads Hi all, beginning with r2448 I've committed changes which had an influence on the order of lines and and roads. This was not intended, just a side effect. I was not aware that this has an effect on overlaid objects, see e.g. http://gis.19327.n5.nabble.com/Commit-r2567-roads-first-v1-patch-Make-sure-t... The problems occurs because we have to colllect all roads first and separate them from other lines. Up to r2448 the option --preserve-element-order probably worked as expected: all objects were processed by the style in the order of appearance and they were also written in this order. Since r2448 the roads were either all written after the other lines or before. The "mkgmap:set_unconnected_type" feature is also likely to mix the order. Polygons were never effected by any of these changes. It looks quite complicated to implement the behaviour of r2448 again (also because the housenumber code needs the separation), so I wonder if it is acceptable to implement --preserve-element-order like this: we keep the order of roads and we keep the order of other ways, and we make sure that roads are added after the other ways. It would also be possible to add an option so that we add roads first if that is needed. Is this limitation a problem for anybody? Gerd _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Be careful with changing this all, the draw order of lines are very unpredicatable, and it also varies between different GPS units.
a few more remarks: 1) the relation processing also adds ways (those with the fake ids like 4611686018427387918). These are added after the normal OSM ways and the order is determined by algorithmns. 2) another possible solution might be to sort the lines by type before they are written to the img file. This would require an additional file giving the draw order of line types.
Gerd
Hi Gerd, Of course it would be great if you can make it more predictable. Until sofar it took me a lot of time to figure out how to get a dotted bicycle route relation on top of all other roads. The only way it worked on all units is to use a routable road type of high order (0x02) and put this after all other line rules with a lot of continue statements. I'm afraid if you change a little of code I have to redesign my maps totally. I also added some overlay types to mask some nasty artefacts (so called spaghetti effect on older units, see http://forum.openstreetmap.org/viewtopic.php?id=10032) and changing the draw order of lines might also have a negative impact. But if the code gets more predictable and consistent, for instance by adding a file that exactly sets the draw order of lines, that would be perfect. I only doubt if it will work on every unit the same.
Do you mean I should not care at all or should I try to make at least the result of mkgmap predictable?
Gerd
but devices do it opposite to Basecamp/Mapsource 6.14 or newer - or did you (Minko) circumvent this? Because of that, I think it doesn't matter at all, you should better use transparency and create the layout in such a way, that it works no matter the order... On 08.05.2013 05:38, Minko wrote:
Hi Gerd,
Of course it would be great if you can make it more predictable. Until sofar it took me a lot of time to figure out how to get a dotted bicycle route relation on top of all other roads. The only way it worked on all units is to use a routable road type of high order (0x02) and put this after all other line rules with a lot of continue statements. I'm afraid if you change a little of code I have to redesign my maps totally. I also added some overlay types to mask some nasty artefacts (so called spaghetti effect on older units, see http://forum.openstreetmap.org/viewtopic.php?id=10032) and changing the draw order of lines might also have a negative impact.
But if the code gets more predictable and consistent, for instance by adding a file that exactly sets the draw order of lines, that would be perfect. I only doubt if it will work on every unit the same.
Do you mean I should not care at all or should I try to make at least the result of mkgmap predictable?
Gerd
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Transparency doesn't solve the problem because then you can only use bitmap images instead of vector images. I would like to draw a dotted bitmap on top and in the centre of a road which is a vector image (vectors are rendered much smoother in Mapsource/basecamp and the newer devices). Not all devices draw it opposite to Basecamp/Mapsource, in many cases left / right side is indeed switched but which line is on top or bottom is often the same (but not always, I had to make holes in my extended (overlay) line types to make sure that the cycle route 0x02 is visible on the older devices).
but devices do it opposite to Basecamp/Mapsource 6.14 or newer - or did you (Minko) circumvent this? Because of that, I think it doesn't matter at all, you should better use transparency and create the layout in such a way, that it works no matter the order...
Hi Minko, if I got this right your problem is solved if roads are added after other lines, and other mappers don't care. Since r2588 this is again the case, and the overlayed_lines_v1.patch doesn't change that. So for now I don't want to add much logic for this as long as we don't understand how different devices or programs use the data. OK? Gerd Minko-2 wrote
Transparency doesn't solve the problem because then you can only use bitmap images instead of vector images. I would like to draw a dotted bitmap on top and in the centre of a road which is a vector image (vectors are rendered much smoother in Mapsource/basecamp and the newer devices). Not all devices draw it opposite to Basecamp/Mapsource, in many cases left / right side is indeed switched but which line is on top or bottom is often the same (but not always, I had to make holes in my extended (overlay) line types to make sure that the cycle route 0x02 is visible on the older devices).
but devices do it opposite to Basecamp/Mapsource 6.14 or newer - or did you (Minko) circumvent this? Because of that, I think it doesn't matter at all, you should better use transparency and create the layout in such a way, that it works no matter the order...
mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/order-of-lines-roads-tp5760103p5760276.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd, Reverting the roads first patch solved my issues so I think it's fine now.
if I got this right your problem is solved if roads are added after other lines, and other mappers don't care. Since r2588 this is again the case, and the overlayed_lines_v1.patch doesn't change that. So for now I don't want to add much logic for this as long as we don't understand how different devices or programs use the data.
OK? Gerd
participants (4)
-
Felix Hartmann -
Gerd Petermann -
GerdP
-
Minko