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
