Etrex sea floods tile unless well zoomed out
I just noticed on my etrex that tiles that touch the coastline are flooded when zoomed in less than about 30Km. Neither mapsource or the nuvi show the same problem with the same map (this is with --generate-sea=polygons). When zoomed out, the coastline looks fine. Anyone else seen this? got a fix? Mark
OK - I think I found what was wrong. I recently removed the 0x4b poly from the TYP file and that was the only poly on level 1. What I didn't realise is that all the polys on higher levels then got shifted down one level so that the sea poly was now on level 1 (I guess the etrex does something funky with polys at level 1). Fortunately, I could revert the commit that removed the 0x4b poly from the TYP file and so I didn't have to tediously change the levels of all the polys again. Hurrah for version control software! Mark
On 01.03.2010 18:51, Mark Burton wrote:
OK - I think I found what was wrong. I recently removed the 0x4b poly from the TYP file and that was the only poly on level 1. What I didn't realise is that all the polys on higher levels then got shifted down one level so that the sea poly was now on level 1 (I guess the etrex does something funky with polys at level 1).
Fortunately, I could revert the commit that removed the 0x4b poly from the TYP file and so I didn't have to tediously change the levels of all the polys again. Hurrah for version control software!
Doesn't sound right to me. There is no need for 0x4b at all (my maps do not contain 0x4b). The only thing that I could imagine that happenend based on your above description is that both sea and land were at the same level, or that the polygon for land was not correctly set. Try using maptk for Typfiles, ati.land makes too many errors. There is definitely neither a need to have 0x4b inside typfile, or map. So here is my take on transparency. transparency switch tells the GPS to use a color for the background polygon (usually 0x4b). The assumption is that all maps do contain 0x4b. So transparency switch only works corrctly if map contains 0x4b polygon. If a map were created without any polygons at all, it would always be transparent. Setting it opaque would not work and it would look and work exactly like a map with only 0x4b polygon set to transparent. Therefore when using mkgmap with --generate-sea=polygons we can drop 0x4b polygon alltogether. We even could draw sea only where it really is, and draw land for the rest. There is no need for sea polygon to span the whole background. 1 Polygon is enough.
Mark _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Felix,
Doesn't sound right to me. There is no need for 0x4b at all (my maps do not contain 0x4b). The only thing that I could imagine that happenend based on your above description is that both sea and land were at the same level, or that the polygon for land was not correctly set. Try using maptk for Typfiles, ati.land makes too many errors. There is definitely neither a need to have 0x4b inside typfile, or map.
Sea and land were not at the same level but I wonder if because the sea poly ended up on level 1 when I removed the 0x4b poly, it had some odd effect. So, tell me, do you have any polys at a higher priority than your sea poly or is the sea poly on level 1? Mark
On 01.03.2010 19:15, Mark Burton wrote:
Felix,
Doesn't sound right to me. There is no need for 0x4b at all (my maps do not contain 0x4b). The only thing that I could imagine that happenend based on your above description is that both sea and land were at the same level, or that the polygon for land was not correctly set. Try using maptk for Typfiles, ati.land makes too many errors. There is definitely neither a need to have 0x4b inside typfile, or map.
Sea and land were not at the same level but I wonder if because the sea poly ended up on level 1 when I removed the 0x4b poly, it had some odd effect.
So, tell me, do you have any polys at a higher priority than your sea poly or is the sea poly on level 1?
Well according to maptk, sea is the only poly on DP level 0 (maptk counts from 0), while land is on 1, and all other polygons are on 2 or higher. Maptk makes no automatic adjustions to the levels, so if were to remove sea at 0, then all other polys would stay at their DP level. The sourcecode for my typfiles is available (like my styles) here: https://svn.origo.ethz.ch/openmtbmap Really bin ati.land if you don't want to have a lot of trouble and things going wrong. ati.land sucks regarding to extended types, and makes some more mistakes. If you feed my typfiles into ati.land, they come out completely crashed.
Mark _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Felix,
Well according to maptk, sea is the only poly on DP level 0 (maptk counts from 0), while land is on 1, and all other polygons are on 2 or higher. Maptk makes no automatic adjustions to the levels, so if were to remove sea at 0, then all other polys would stay at their DP level. The sourcecode for my typfiles is available (like my styles) here: https://svn.origo.ethz.ch/openmtbmap
Really bin ati.land if you don't want to have a lot of trouble and things going wrong. ati.land sucks regarding to extended types, and makes some more mistakes. If you feed my typfiles into ati.land, they come out completely crashed.
OK - thanks again for the wisdom. Mark
On 01.03.2010 17:02, Mark Burton wrote:
I just noticed on my etrex that tiles that touch the coastline are flooded when zoomed in less than about 30Km. Neither mapsource or the nuvi show the same problem with the same map (this is with --generate-sea=polygons). When zoomed out, the coastline looks fine.
Anyone else seen this? got a fix?
Mark _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
I don't have any probs (at least when simply looking at the map), not tried with actual GPS reception or demo mode, but with GPS off. I can't believe that there are any differences though. Here's my take: Tiles with sea inside: When zooming around, then often in the rendering process, blue intermittently flashes up, before normal map is drawn. I will experiment a bit, to find out why no yellow flashes. Tiles with no sea inside: Sometimes yellow background flashes up on map panning. I assume this is because the map has no 0x4b background (I use --transparent, but make maps opaque with gmt.exe after creation). This means: a) either your typfile has draw priority for land not higher than sea (remember that GPS draws opposite order from mapsource on same DP). b) typfile is not correctly associated to map. You should try to set some really strange colors for roads inside typfile to verify that typfile is actually used. If you can rule out a) and b), then try --transparent on map creation, but afterwards making maps opaque with gmaptool and see if there is any difference (though there should not be one).
Hi Felix, Many thanks for taking the time to respond - I believe the problem was caused by me removing the 0x4b poly from the TYP file (see last post). Mark
On 01.03.2010 19:11, Mark Burton wrote:
Hi Felix,
Many thanks for taking the time to respond - I believe the problem was caused by me removing the 0x4b poly from the TYP file (see last post).
No it is not, because neither do my TYPfiles contain 0x4b, nor does my maps contain 0x4b. You're somehow working around another bug in your typfile. (maybe related to ati.land??).
Mark
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On 01.03.2010 19:11, Mark Burton wrote:
Hi Felix,
Many thanks for taking the time to respond - I believe the problem was caused by me removing the 0x4b poly from the TYP file (see last post).
Mark
Just another thought. Are you using single color or pattern for land? Try using a pattern for land (set both colors the same, or for maptk set just one pixel to a different color). Using single color instead of pattern, does definitely sometimes lead to problems. Garmin modern tpyfiles use patterns for all polys.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Felix,
Just another thought. Are you using single color or pattern for land? Try using a pattern for land (set both colors the same, or for maptk set just one pixel to a different color).
Using single color instead of pattern, does definitely sometimes lead to problems. Garmin modern tpyfiles use patterns for all polys.
OK - noted. You will be pleased to know that I have taken your advice and started looking at using MapTk to generate the typ file. I can generate a file but, weirdly, mapsource is ignoring my polyline styles. The couple of POIs I have and the polygons appear to be working OK, it's just the polylines it is ignoring. The file isn't huge so I have attached it to this email, please take a quick look at the polylines in case there is something obvious I am doing wrong. BTW - I can edit those polyline styles in MapTk and they look just as they should. Mark
On 01.03.2010 22:15, Mark Burton wrote:
Felix,
Just another thought. Are you using single color or pattern for land? Try using a pattern for land (set both colors the same, or for maptk set just one pixel to a different color).
Using single color instead of pattern, does definitely sometimes lead to problems. Garmin modern tpyfiles use patterns for all polys.
OK - noted.
You will be pleased to know that I have taken your advice and started looking at using MapTk to generate the typ file.
I can generate a file but, weirdly, mapsource is ignoring my polyline styles. The couple of POIs I have and the polygons appear to be working OK, it's just the polylines it is ignoring. The file isn't huge so I have attached it to this email, please take a quick look at the polylines in case there is something obvious I am doing wrong.
BTW - I can edit those polyline styles in MapTk and they look just as they should.
Mark
Well *first* there is one problem, that I took quite some time to find out. If you have transparent symbol for bridges/tunnels, you will need to use for all lines that have even line number, bitmap lines, else they are not put into the middle. *Second*, and here the author of maptk does not agree to my opinion. If you set polygons to one single color (for both single color and bitmap) maptk sets the second color to transparent (only when using GUI). I do go into the .prj with text editor and change second color to the same color. This is only important for the background polygon. Else in Mapsource 6.13 map panning is slower. A second nuisance with maptk is that it sets all colors to the 256 color palette for polygons and polylines when clicking on "edit" for a polygon/line. So if you differentiate further (e.g. to have more differentiation in Mapsource, but know to which color the etrex rounds a polygon) then you are not allowed to use the GUI to edit the colors. POI are fine and not modified. Also setting polygons to be invisible is strange on GUI edit. The good thing is, the .prj file will be compiled as it is, without those GUI corrections which are supposedly meant to help you do less errors. So if you don't agree to maptk GUI behaviour when editing single objects, you can easily just do it with text editor.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (2)
-
Felix Hartmann -
Mark Burton