As far as I know, -32768 is "no data available" marker and does not indicate water.
>1) use the old way and have everything below 0m as water Does not work. 0m or -10m does not indicate water. Netherlands is an example, but not the only one. England and Italy, and probably many other areas and most lakes do not have 0m altitude. Not using SRTM data at least. > 2) use an additional bitmap just for the water areas (Max's favorite) Not derived from SRTM I suppose. > 3) lift the entire source image by 1000m, then define -31768m = 0m to > solve the interpolation problems and subtract 1000m from all elevations > read in XCSoar. See (1) > 4) use more then just one JPEG2000 image file. Those including coastline > with lossless compression. See (1) > 5) use lossless compression for all maps See (1). There are only two possible solutions for this: 1) use a separated raster terrain data for water 2) use topology vectorial data for water I have solved water coverage problem long ago using the second approach. Netherlands, england, italy and many cost areas previously under water are now correctly painted. All other solutions will not work. See the source code of LK to understand why and how the topology solution is working. ----- Original Message ----- From: "Tobias Bieniek" <tobias.bien...@gmx.de> To: <martin.kopp...@gmx.de> Cc: <xcsoar-user@lists.sourceforge.net> Sent: Wednesday, December 29, 2010 12:26 AM Subject: Re: [Xcsoar-user] WATER > Well... I'll try to describe the problem as easy as possible... > > We have SRTM terrain data, which means a big picture file with a > resolution of 3 arc-seconds per pixel. The pixel value is the terrain > height in meters and for larger water areas like the atlantic the value > is -32768. > That means we actually do have a picture with a very clear coastline. > But that picture is an uncompressed TIFF file and you really don't want > to download that onto your SD card. Instead of that TIFF file we use a > converted JPEG2000 file, that has several advantages. In principle it > can be lossless, which means that though compressed, the information is > still the same. However, as decided by Max we use even further > compression which leads to so-called lossy compression. That means that > some values are possibly changed, but are still close to the original. > As you can imagine the coastlines are now a little blurry since they are > interpolated between -32768 and something like 5m. Unfortunatly in this > interpolation step unsigned values are used, which converts -32768 to > 65535 and therefore the interpolation is going from 5m up to 65535m. > This results in quite high but narrow "mountains" directly at the > coast... The old approach was replacing the -32768m value with 0m and > like that you don't have such big problems with interpolation at the > coastlines, but at the same time you define everything beneath 0m as > water which is still a problem in the netherlands for example. > > So much for the problem, now some possible solutions: > 1) use the old way and have everything below 0m as water > 2) use an additional bitmap just for the water areas (Max's favorite) > 3) lift the entire source image by 1000m, then define -31768m = 0m to > solve the interpolation problems and subtract 1000m from all elevations > read in XCSoar. > 4) use more then just one JPEG2000 image file. Those including coastline > with lossless compression. > 5) use lossless compression for all maps > > As you can see it's not that easy because all methods have their pros > and cons. Personally I would prefer the third solution, given that it > would work... > > Turbo > > > > Am 28.12.2010 23:29, schrieb martin.kopp...@gmx.de: >> Hi Turbo, >> >> not being a programmer, I will most probably not be of much help here >> with the details. >> >> I can only try to ask helpful questions, if there are such. >> So: Apart from the altitude above MSL, is there any property a terrain >> point can have that would allow a guess whether it is land or sea? >> Could it be a certain range of proximity to topology items? Railroads and >> populated areas aren't usually under the sea. Or maybe a check on the >> relationship with neighboring points can reveal useful information: Could >> it be that to make a point "sea", with the sea being generally considered >> level, all n surrounding points within a certain radius must also be >> exactly zero MSL? I don't know, but if the terrain data does not have a >> "land" or "sea" flag, then a good guess must do the trick ... >> >> Martin >> --- >> >> >> >> Am 28.12.2010 um 23:01 schrieb Tobias Bieniek: >> >>> Hi Martin >>> >>> There are definitly plans to fix this, but unfortunatly the problem is a >>> bit more complicated than it may seem. I will spare you the details for >>> now, but we do know that this is a big problem and we are working on a >>> fix. >>> >>> Ask me on IRC for more details if you want. >>> >>> Turbo >> ------------------------------------------------------------------------------ >> Learn how Oracle Real Application Clusters (RAC) One Node allows >> customers >> to consolidate database storage, standardize their database environment, >> and, >> should the need arise, upgrade to a full multi-node Oracle RAC database >> without downtime or disruption >> http://p.sf.net/sfu/oracle-sfdevnl >> _______________________________________________ >> Xcsoar-user mailing list >> Xcsoar-user@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/xcsoar-user >> > > ------------------------------------------------------------------------------ > Learn how Oracle Real Application Clusters (RAC) One Node allows customers > to consolidate database storage, standardize their database environment, > and, > should the need arise, upgrade to a full multi-node Oracle RAC database > without downtime or disruption > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Xcsoar-user mailing list > Xcsoar-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xcsoar-user ------------------------------------------------------------------------------ Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Xcsoar-user mailing list Xcsoar-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcsoar-user
