Hello I've noticed strange problem with lakes (natural=water) in a middle of forests (landuse=forest). Some of them are displayed on Garmin (Colorado), some are not. The only difference in data I can see is that the ones displayed have source=Yahoo tag (in addition to natural=water and created_by=...). Strangely enough this is only happening when rendering forest areas as 0x50, if I change it to 0x17 (park) all lakes are visible. Affected area: http://www.openstreetmap.org/?lat=55.2085&lon=25.7473&zoom=13&layers=B000FTF (data taken from http://download.geofabrik.de/osm/europe/lithuania.osm.bz2) Has anybody noticed such behaviour? Is it Colorado or mkgmap problem? Thank you P.S. I will try later to add source=Yahoo to missing lakes and check if that makes them appear on the map. -- Tomas Straupis
Hello Tomas,
I've noticed strange problem with lakes (natural=water) in a middle of forests (landuse=forest).
Do you use a custom typ file for your map? If yes you can define the drawing order of the polygons. In your case you should give the lakes a higher order than the forests so that the lakes are drawn on top of the forest. This can result in another problem: If you have a lake with an island and the island has a forest then the forest is invisible because the lake has a higher priority. In this case you can define a multipolygon. See the mailing list archive for a discussion about this topic. I didn't test your region and I don't know why some of lakes are displayed while others are not. Maybe lakes and forests have the same priority so the drawing order is dependent on the order of the objects in the img file. I strongly doubt it has something to do with the source=yahoo tag. Regards, Rudi
Hello 2009-07-27 Rudi <drahtesel42@web.de>:
Do you use a custom typ file for your map? No, I am not. And some lakes marked the same way ARE visible on the map...
I strongly doubt it has something to do with the source=yahoo tag. This was just my guess - maybe some tiny bug in code... But I've tried adding that source tag to osm xml file directly and it had no effect.
I will try to get hold of some other Garmin device (maybe Oregon and/or Nuvi) and check if it has the same problem. It should then be clear if a problem is in Colorado or .img file. Another interesting detail is that if I put pointer over the "invisible lake" a tip does show "Lake" while forest is actually displayed. -- Tomas Straupis
the data is wrong in the first place. a lake and a forest can't be in the same place. the forest should be created as multipolygon with all the lakes as inner ways. if you ask the software to fix bad data it will fail on some corner cases and will succeed in some places. but then random effects like order of elements or names can play a role. bottom line better fix the data than debug the software. On Jul 27, 2009, at 1:44 PM, Tomas Straupis wrote:
Hello
2009-07-27 Rudi <drahtesel42@web.de>:
Do you use a custom typ file for your map? No, I am not. And some lakes marked the same way ARE visible on the map...
I strongly doubt it has something to do with the source=yahoo tag. This was just my guess - maybe some tiny bug in code... But I've tried adding that source tag to osm xml file directly and it had no effect.
I will try to get hold of some other Garmin device (maybe Oregon and/or Nuvi) and check if it has the same problem. It should then be clear if a problem is in Colorado or .img file.
Another interesting detail is that if I put pointer over the "invisible lake" a tip does show "Lake" while forest is actually displayed.
-- Tomas Straupis _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Assuming that the data is correct, I can confirm that you need to set draw order in a typ file. I encountered a similar issue with building and landuse polygons. I had to set a higher draw order so that buildings are drawn over landuse. On 7/28/09, Apollinaris Schoell <aschoell@gmail.com> wrote:
the data is wrong in the first place. a lake and a forest can't be in the same place. the forest should be created as multipolygon with all the lakes as inner ways.
if you ask the software to fix bad data it will fail on some corner cases and will succeed in some places. but then random effects like order of elements or names can play a role.
bottom line better fix the data than debug the software.
On Jul 27, 2009, at 1:44 PM, Tomas Straupis wrote:
Hello
2009-07-27 Rudi <drahtesel42@web.de>:
Do you use a custom typ file for your map? No, I am not. And some lakes marked the same way ARE visible on the map...
I strongly doubt it has something to do with the source=yahoo tag. This was just my guess - maybe some tiny bug in code... But I've tried adding that source tag to osm xml file directly and it had no effect.
I will try to get hold of some other Garmin device (maybe Oregon and/or Nuvi) and check if it has the same problem. It should then be clear if a problem is in Colorado or .img file.
Another interesting detail is that if I put pointer over the "invisible lake" a tip does show "Lake" while forest is actually displayed.
-- Tomas Straupis _______________________________________________ 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
-- cheers, maning ------------------------------------------------------ "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ ------------------------------------------------------
Hi! Apollinaris Schoell schrieb:
the data is wrong in the first place. a lake and a forest can't be in the same place. the forest should be created as multipolygon with all the lakes as inner ways.
I agree. The areas on the Garmin should be drawn by the drawing priority defined in the type file, completely disregarding any layer tags. With proper multipolygons, everything should look good. But if you start changing around drawing priorities to get lakes on top of wood, then probably some wooded islands in lakes will disappear where somebody thought wood needs to go on top of water. Adding proper multipolygons to the data instead of relying on any drawing order is the only useful solution. bye Nop
Hello 2009/7/28 Nop <ekkehart@gmx.de>:
Adding proper multipolygons to the data instead of relying on any drawing order is the only useful solution.
OK. Thank you all for answers! I will try fixing the data (while fixing 4500 lakes in tiny territory of Lithuania will not be a small task:). Just from my experience adding multipolygons is quite a challenging task for beginners, so I will have to come up with some automated way of at least identifying such forest+water combinations (keepright?:). -- Tomas Straupis
I will try fixing the data (while fixing 4500 lakes in tiny territory of Lithuania will not be a small task:). Just from my experience adding multipolygons is quite a challenging task for beginners, so I will have to come up with some automated way of at least identifying such forest+water combinations (keepright?:).
sure it's work, but isn't our target to make the best gis database :) someone else pointed out in an older thread on talk why this is important. imagine you need to calculate the area of the forest. this way it's tagging for the renderer. but renderer can change
-- Tomas Straupis _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
2009-07-28 Apollinaris Schoell <aschoell@gmail.com>:
sure it's work, but isn't our target to make the best gis database :) someone else pointed out in an older thread on talk why this is important. imagine you need to calculate the area of the forest. this way it's tagging for the renderer. but renderer can change
Cha. I just found out that it is extremely easy to add such relation using JOSM. I do not have to "draw" any new nodes/ways. Just select forest and lakes, create/modify relation and add corresponding outer/inner tags :) -- Tomas Straupis
Hi! Tomas Straupis schrieb:
Cha. I just found out that it is extremely easy to add such relation using JOSM. I do not have to "draw" any new nodes/ways. Just select forest and lakes, create/modify relation and add corresponding outer/inner tags :)
I have not tried it yet, but there is a plugin that should simplify the job. bye Nop
Hello Do I understand correctly, that there are still problems with multipolygons? Lakes marked as inner ways of multipolygon having forest as outer way are still not rendered. Some of those lakes appear as a hole in forest, some have no influence on rendering (lakes are displayed as forest regardless of being inner way of forest). Should I create a bug for this? Or should I just wait? Thank you -- Tomas Straupis
Hi Tomas, may first guess would be that a multipolygon relation (with role=outer for the forrest and role=inner for the lake) is missing. Best wishes Christian Tomas Straupis schrieb:
Hello
I've noticed strange problem with lakes (natural=water) in a middle of forests (landuse=forest). Some of them are displayed on Garmin (Colorado), some are not. The only difference in data I can see is that the ones displayed have source=Yahoo tag (in addition to natural=water and created_by=...). Strangely enough this is only happening when rendering forest areas as 0x50, if I change it to 0x17 (park) all lakes are visible. Affected area: http://www.openstreetmap.org/?lat=55.2085&lon=25.7473&zoom=13&layers=B000FTF (data taken from http://download.geofabrik.de/osm/europe/lithuania.osm.bz2)
Has anybody noticed such behaviour? Is it Colorado or mkgmap problem?
Thank you
P.S. I will try later to add source=Yahoo to missing lakes and check if that makes them appear on the map.
Hello 2009-07-28 Christian Gawron <christian.gawron@googlemail.com>:
may first guess would be that a multipolygon relation (with role=outer for the forrest and role=inner for the lake) is missing.
Yes, thank you, I've added that relation and will test the map generation tomorrow (after geofabrik publishes todays data)! -- Tomas Straupis
participants (6)
-
Apollinaris Schoell -
Christian Gawron -
maning sambale -
Nop -
Rudi -
Tomas Straupis