osgEarth3.0: Problems with TMS elevation data

classic Classic list List threaded Threaded
9 messages Options
FloKow FloKow
Reply | Threaded
Open this post in threaded view
|

osgEarth3.0: Problems with TMS elevation data

We’ve been using osgearth 2.10 for a long time.
Input data is in the TMS format. Tiff for elevation, PNG for image data.
The TMS structures for elevation is created with osgearth_package from a single big geotiff-file as input.
 
The layer definitions in the earth-file (geocentric map) look like this:
 
                <elevation name="Elevation" driver="tms">
                               <url>http://x.x.x.x/geoserver/www/Elevation/Map1/tms.xml</url>
                </elevation>
                <image name="Map2"
                       driver="tms"
                                  max_data_level="8">
                               <url>http://x.x.x.x/geoserver/gwc/service/tms/1.0.0/rme:Map2@EPSG%3A4326@png/</url> 
                </image>
 
Everything works as expected. Now I tried osgEarth3.0. I changed the elevation definitions according to the docs to:
 
                <TMSElevation name="Elevation">
                               <url>http://x.x.x.x/geoserver/www/Elevation/Map1/tms.xml</url>
                </TMSElevation>
               
               <TMSImage name="Map2" max_data_level="8">
                               <url>http://x.x.x.x/geoserver/gwc/service/tms/1.0.0/rme:Map2@EPSG%3A4326@png/</url> 
                </TMSImage>
 
I hope it’s correct and I made no error. The image layer looks OK, but there’s no sign of elevation at all.


I’ve noticed, that osgearth_package will not be build any more in osgEarth3.0 at the moment, so I can’t rebuild the TMS structure with this version.
 
When I start the program at a high notify level, it shows the world looking approximately at the line of day-change.
For this area, I haven’t elevation data, so i can see some tries for tiles, which results in getting at the blacklist.
When I jump to Europe, where I have elevation data, I cannot even see the program trying to load something.
 
Where is the fault? What am I doing wrong or is this not supposed to work in  osgearth3.0 anymore?
gwaldron gwaldron
Reply | Threaded
Open this post in threaded view
|

Re: osgEarth3.0: Problems with TMS elevation data

I don't see anything wrong with your earth file, so not sure what the problem is. Are you able to fetch the xml file in a web browser? Are there are errors or warnings on the console is you run osgearth_toc?

osgearth_package is gone. You can use osgearth_conv instead. Some usage examples here.

Glenn Waldron / Pelican Mapping
FloKow FloKow
Reply | Threaded
Open this post in threaded view
|

Re: osgEarth3.0: Problems with TMS elevation data

Yes we can get the xml-file by browser. As I told you yet, it’s the same configuration/data that ist working with osgEarth2.10.

I’ve run osg_toc, as you suggested and do attach it at this message. As you could maybe see, we start with a view of south America. For this region, we have to elevation data. So it might be ok, that the program blacklists the elevation tiles. Then i moved to Europe and zoom in. The log shows no more tries to get elevation data anymore.

Lastly,  I tried the new conversion method:

.\osgearth_conv.exe --in driver GDALImage --in url K:\Map1.tif --out driver TMSImage --out url C:\tmp\Map1\tms.xml --out format tif

[osgEarth]  [GDAL] This is a BigTIFF file.  BigTIFF is not supported by this version of GDAL and libtiff. (error 4)
[osgEarth]  [GDAL] This is a BigTIFF file.  BigTIFF is not supported by this version of GDAL and libtiff. (error 4)
[osgEarth]* [osgearth_conv] Error initializing input: Failed to open K:\Map1.tif
[osgEarth]  Closed GDAL Driver on thread 2424
[osgEarth]  [Layer] Layer "GDALImage" ~Layer
[osgEarth]  [StateSetCache] Pruned 0 attributes, 0 statesets
[osgEarth]  [Registry] Registry shutting down...
[osgEarth]  [Registry] Registry shutdown complete.
[osgEarth]  [StateSetCache] Pruned 0 attributes, 0 statesets

Compiling osgEarth3.0 I use a newer build of gdal2 and libtiff. Maybe I need to configure them differently? I’ll have to investigate …
gwaldron gwaldron
Reply | Threaded
Open this post in threaded view
|

Re: osgEarth3.0: Problems with TMS elevation data

Interesting, what version of GDAL (and libtiff) are you using?

Also - if you are writing a TMS repo, I suggest using jpeg as the format (unless you have an alpha channel, in which case use png).

Writing an MBTilesImage in another option if you want to keep the data in a single local file.
Glenn Waldron / Pelican Mapping
FloKow FloKow
Reply | Threaded
Open this post in threaded view
|

Re: osgEarth3.0: Problems with TMS elevation data

It would be nice, if you can grant post-rights my colleague “JP”, so he can join the discussion.
JP JP
Reply | Threaded
Open this post in threaded view
|

Re: osgEarth3.0: Problems with TMS elevation data

In reply to this post by gwaldron
I'll answer your Question and try to clarify our problems as good as i can ..

Glenn, we’re using GDAL Version 2.4.2 and libtiff 4.1.0. OS is Windows 10 64Bit. Both build via conan.

But nothing of that caused the problem - we missed manually defining a Compiler-Define activating bigtiff for gdal. So this error message is gone, but …

Bear in mind:
  1) our first intension was using the existing TMS TIFF Elevation data!!!
  2) just because we couldn’t get this to work, we tried to generate a new structure hoping to bypass the  problem
  3)with osgEarth2.10 TMS elevation data in TIFF-file format was the only format, I found working, apart from using the very big source elevation file in geoTiff format. We had no luck in getting JPG/PNG to work. In this case the tiles merely contained image data instead of elevation. Naturally, In elevation there’s nothing like alpha …


Now a little bit more concerning the above points:

1) I increased the verbosity to debug level. If i start the test application, it starts with a view at about equator/south america, as usally.
We have just generated elevation data for swiss. So the programm tries to load elevation tiles, that don't exist. That's just that, i was expecting.
I change the view to look at about swiss. Now the programm tried to load in the first lod level (1-3): 1/3/0, 2/7/0 and 3/15/1.
I dont't know why? osgearth 2.10 generated via osgearth_packager 1/2/1, 2/4/5 and 3/8/6 for this region and does also use them with the application. These keys correspond to the definition at osgeo.org, also.
The keys of osgEarth3.0 would be somewhere in the pacific ..
Unfortunately i don't know where they were calculated and if/why there wrong! Can you give us some hint? It seems to be more than just a vertical or horizontal difference?

2) Under the assumption, that generation and using in osgEarth use the same algorithmen, we tried to regenerate the tiff elevation tree and found osgearth_package gone.

So I tried this:

.\osgearth_convd.exe --in driver GDALImage --in url K:\elevation_src.tif --out driver TMSImage --out url C:\tmp\elevation\tms.xml --out format tif --elevation --extents 5 45 10.6 48

“elevation_src.tif” is a very big file (~180GB). I tried to limit time/data with the extents (appr. Swiss-Area)

I get this after a very long time:

[osgEarth]  [osgearth_conv] Calculated max level = 10
Working...
[osgEarth]  [ImageLayer] "GDALImage" create image for "0/1/0", ext= SW=0,-90 NE=180,90, SRS=WGS 84
[osgEarth]  Intersection of SW=0,-90 NE=180,90, SRS=WGS 84 and SW=179.989583468,-90 NE=-179.989583199,90, SRS=WGS84  is: SW=179.989583468,-90 NE=180,90, SRS=WGS 84
[osgEarth]  [GDAL] Layer "GDALImage" ReadWindow 432000,0 13x216000
[osgEarth]  [GDAL] Layer "GDALImage" DestWindow 255,0 1x256
[osgEarth]  [GDAL] TIFFSetField:outputstream: Unknown tag 317 (error 1)
1/820 0% complete, 0m0s projected, 0m0s remaining
Complete. Time = 35511.1 seconds.
[

Tag 317 is the predict-Tag, I suppose. Don’t know yet, what the problem is at this point and if this error is the reason getting just one part of a file. Besides the xml-File it generates just part of one tile … and this has the wrong format, as "tiffinfo" told me (image data (4x8Bit Int) and not elevation data (1x32Bit float));

Can you tell me, what we're doing wrong? Maybe we've to use another kind of out driver ...
JP JP
Reply | Threaded
Open this post in threaded view
|

Re: osgEarth3.0: Problems with TMS elevation data

No answer at all. Nobody who can give us a hint about using/creating elevation TMS tiles ???
gwaldron gwaldron
Reply | Threaded
Open this post in threaded view
|

Re: osgEarth3.0: Problems with TMS elevation data

Have patience, JP. It is a national holiday weekend here in the US and people are taking some much-needed time off.

You should be using --in driver GDALElevation and --out driver TMSElevation (not *Image). If you plan to access this data locally, you can also try --out driver MBTilesElevation for a single-file repository. (The --elevation flag is no longer necessary.)

I recommend trying your conversion on a small file first, or restricting the LOD with "--max-level 1" or the like just to make sure things work. Since your file is huge, and it not internally tiled, this will still take a while but at least you will know if it is working.
Glenn Waldron / Pelican Mapping
JP JP
Reply | Threaded
Open this post in threaded view
|

Re: osgEarth3.0: Problems with TMS elevation data

Hello Glenn,

i've normally got much of patience, but i didn't realised that there was a holly weekend, sorry. Sadly, in Germany there was no one ..

Unforrtunatly i just got a message of my employer, that i have do to something else. I think the project will stay at 2.10 and nobody, even "FloKo" will persue the matter on our side at the moment.

Its been a rather short time, thanks for your support and likely Bye

Jens