correct gdal version with osgEarth 3.1...

classic Classic list List threaded Threaded
10 messages Options
2LR 2LR
Reply | Threaded
Open this post in threaded view
|

correct gdal version with osgEarth 3.1...

Can anyone tell me what version of gdal is required with osgEarth 3.1?

The reason I ask is that we've upgraded to gdal/3.2.1 and proj/8.0.1 in our dependency tree and now terrain layers are no longer being rendered in osgEarth 3.1.

Thanks

Shayne
gwaldron gwaldron
Reply | Threaded
Open this post in threaded view
|

Re: correct gdal version with osgEarth 3.1...

Any more information? Console messages? Earth file?
Glenn Waldron / Pelican Mapping
plevy plevy
Reply | Threaded
Open this post in threaded view
|

Re: correct gdal version with osgEarth 3.1...

In reply to this post by 2LR
Strange, I use vcpkg which is using a later version:
GDAL Version:      3.2.2



On Wed, May 26, 2021 at 11:28 AM 2LR [via osgEarth] <[hidden email]> wrote:
Can anyone tell me what version of gdal is required with osgEarth 3.1?

The reason I ask is that we've upgraded to gdal/3.2.1 and proj/8.0.1 in our dependency tree and now terrain layers are no longer being rendered in osgEarth 3.1.

Thanks

Shayne


If you reply to this email, your message will be added to the discussion below:
http://forum.osgearth.org/correct-gdal-version-with-osgEarth-3-1-tp7593860.html
To start a new topic under osgEarth, email [hidden email]
To unsubscribe from osgEarth, click here.
NAML
2LR 2LR
Reply | Threaded
Open this post in threaded view
|

Re: correct gdal version with osgEarth 3.1...

In reply to this post by gwaldron
Since the machine running osgEarth is on a different computer with no internet access, I'm hand-jamming the console output so I apologize for the late reply...

The message I get out of the console is:

"ERROR 1: PROJ: proj_identify: Cannot find proj.db"

I also get the following terrain-related output from osgEarth:

[Layer] Layer "DTED0" Cache bin is [DTED0-aa9067ba]
[GDAL] Layer "DTED0" Resolution= 0.020232x0.00833333 max=0.00833333
[GDAL] Layer "DTED0" D:/osgEarthTerrainDT0/osgETerrain.tif max Data Level: 7
[ElevationLayer] "DTED0" : Override vdatum = egm96 (was geodetic)
[TileLayer] Layer "DTED0" [srs=unknown, min=-180,-90 max=180,90 lod0=2, 1 vdatum=EGM96] [cache=FileSystemCache; policy=read-write; bin=yes]
[engine_rex] Activated!
[TerrainResources] Texture unit 0 reserved for Terrain Color
[TerrainResources] Texture unit 1 reserved for Terrain Elevation
[TerrainResources] Texture unit 2 reserved for Terrain Normals
[TerrainResources] Texture unit 3 reserved for Terrain Parent Color
[TerrainResources] Texture unit 4 reserved for Terrain Land Cover
[RexTerrainEngineNode] Creating 2 root keys.
[ElevationLayer] "DTED0" : Override vdatum = egm96 (was egm96)

Capabilities output is:

[Capabilities] osgEarth Version: 3.1.0 build 100
[Capabilities] OSG Version: 3.6.5
[Capabilities] GDAL Version: 3.2.1
[Capabilities] GEOS Version: 3.9.1dev

Earthfile entry for terrain is:

<GDALElevation name="DTED0">
<url>D:/osgEarthTerrainDT0/osgETerrain.tif</url>
<vdatum>egm96</vdatum>
</GDALElevation>

Let me know if you need more information...

Shayne

plevy plevy
Reply | Threaded
Open this post in threaded view
|

Re: correct gdal version with osgEarth 3.1...

I would address this:  "ERROR 1: PROJ: proj_identify: Cannot find proj.db"
by setting PROJ_LIB= to the path to the folder containing proj.db

Make sure it is the proj8 folder not an older gdal 2.4/proj folder.

Second, that usually fixes this srs=unknown you see in "[TileLayer] Layer "DTED0" [srs=unknown, min=-180,-90 max=180,90 lod0=2, 1 vdatum=EGM96] [cache=FileSystemCache; policy=read-write; bin=yes]"
but if it does not, we may have to take a look at why that srs is not being resolved.




--



On Wed, May 26, 2021 at 4:20 PM 2LR [via osgEarth] <[hidden email]> wrote:
Since the machine running osgEarth is on a different computer with no internet access, I'm hand-jamming the console output so I apologize for the late reply...

The message I get out of the console is:

"ERROR 1: PROJ: proj_identify: Cannot find proj.db"

I also get the following terrain-related output from osgEarth:

[Layer] Layer "DTED0" Cache bin is [DTED0-aa9067ba]
[GDAL] Layer "DTED0" Resolution= 0.020232x0.00833333 max=0.00833333
[GDAL] Layer "DTED0" D:/osgEarthTerrainDT0/osgETerrain.tif max Data Level: 7
[ElevationLayer] "DTED0" : Override vdatum = egm96 (was geodetic)
[TileLayer] Layer "DTED0" [srs=unknown, min=-180,-90 max=180,90 lod0=2, 1 vdatum=EGM96] [cache=FileSystemCache; policy=read-write; bin=yes]
[engine_rex] Activated!
[TerrainResources] Texture unit 0 reserved for Terrain Color
[TerrainResources] Texture unit 1 reserved for Terrain Elevation
[TerrainResources] Texture unit 2 reserved for Terrain Normals
[TerrainResources] Texture unit 3 reserved for Terrain Parent Color
[TerrainResources] Texture unit 4 reserved for Terrain Land Cover
[RexTerrainEngineNode] Creating 2 root keys.
[ElevationLayer] "DTED0" : Override vdatum = egm96 (was egm96)

Capabilities output is:

[Capabilities] osgEarth Version: 3.1.0 build 100
[Capabilities] OSG Version: 3.6.5
[Capabilities] GDAL Version: 3.2.1
[Capabilities] GEOS Version: 3.9.1dev

Earthfile entry for terrain is:

<GDALElevation name="DTED0">
<url>D:/osgEarthTerrainDT0/osgETerrain.tif</url>
,vdatum>egm96</vdatum>
</GDALElevation>

Let me know if you need more information...

Shayne




If you reply to this email, your message will be added to the discussion below:
http://forum.osgearth.org/correct-gdal-version-with-osgEarth-3-1-tp7593860p7593866.html
To start a new topic under osgEarth, email [hidden email]
To unsubscribe from osgEarth, click here.
NAML
2LR 2LR
Reply | Threaded
Open this post in threaded view
|

Re: correct gdal version with osgEarth 3.1...

I did set the PROJ_LIB per your recommendations. It did resolve the PROJ error message but still no terrain being paged in.

The "srs=unknown" still resides in the [TileLayer] Layer "DTED0" message coming out.

I know the tif file is good because I've used the same file for terrain in previous versions of osgEarth.

Thanks for your feedback!
plevy plevy
Reply | Threaded
Open this post in threaded view
|

Re: correct gdal version with osgEarth 3.1...

First, is the data publically available where we can try it?  
Second, can you gdalinfo.exe on the file and paste the result?

--



On Wed, May 26, 2021 at 5:50 PM 2LR [via osgEarth] <[hidden email]> wrote:
I did set the PROJ_LIB per your recommendations. It did resolve the PROJ error message but still no terrain being paged in.

The "srs=unknown" still resides in the [TileLayer] Layer "DTED0" message coming out.

I know the tif file is good because I've used the same file for terrain in previous versions of osgEarth.

Thanks for your feedback!



If you reply to this email, your message will be added to the discussion below:
http://forum.osgearth.org/correct-gdal-version-with-osgEarth-3-1-tp7593860p7593869.html
To start a new topic under osgEarth, email [hidden email]
To unsubscribe from osgEarth, click here.
NAML
2LR 2LR
Reply | Threaded
Open this post in threaded view
|

Re: correct gdal version with osgEarth 3.1...

In reply to this post by plevy
As a follow-up to my previous post, I just ran osgEarth 3.0 which is using OSG 3.6.4 and GDAL 2.4.1. Using the same terrain tif file, it works...and the "srs=WGS 84" in the TileLayer for DTED0.

I think we may be on to something here...
2LR 2LR
Reply | Threaded
Open this post in threaded view
|

Re: correct gdal version with osgEarth 3.1...

In reply to this post by plevy
The tif file can be shared.

Here's the report from gdalinfo on the tif file:

Driver: GTiff/GeoTIFF
Files: osgETerrain.tif
Size is 17796, 20881
Coordinate System is:
GEOGCS["WGS 84",
    DATUM["WGS_1984",
        SPHEROID["WGS 84",6378137,298.257223563,
            AUTHORITY["EPSG","7030"]],
        AUTHORITY["EPSG","6326"]],
    PRIMEM["Greenwich",0],
    UNIT["degree",0.0174532925199433],
    AUTHORITY["EPSG","4326"]]
Origin = (-180.025000000000006,84.004166666666677)
Pixel Size = (0.020231955406214,-0.008333333333332)
Metadata:
  AREA_OR_POINT=Area
Image Structure Metadata:
  COMPRESSION=LZW
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  (-180.0250000,  84.0041667) (180d 1'30.00"W, 84d 0'15.00"N)
Lower Left  (-180.0250000, -90.0041667) (180d 1'30.00"W, 90d 0'15.00"S)
Upper Right ( 180.0228784,  84.0041667) (180d 1'22.36"E, 84d 0'15.00"N)
Lower Right ( 180.0228784, -90.0041667) (180d 1'22.36"E, 90d 0'15.00"S)
Center      (  -0.0010608,  -3.0000000) (  0d 0' 3.82"W,  3d 0' 0.00"S)
Band 1 Block=256x256 Type=Int16, ColorInterp=Gray
  NoData Value=-32767
2LR 2LR
Reply | Threaded
Open this post in threaded view
|

Re: correct gdal version with osgEarth 3.1...

In reply to this post by gwaldron
So...as a sanity check, I built osgEarth 3.1 using vcpkg given the instructions provided at http://docs.osgearth.org/en/latest/build.html.

I'm seeing the exact same results I reported earlier with my terrain dataset (which is global coverage of DTED level 0) not being displayed or being paged in. Using the exact same dataset, it works perfectly fine using osgEarth 3.0.

To test further, I decided to try and convert both the .vrt file and the tiled tiff file of the terrain source data to the MBTiles format using the osgearth_conv utility. Doing both yields the same strange behavior out of this tool...

osgearth_conv --in driver GDALElevation --in url osgETerrain.vrt --out driver MBTilesElevation --out filename osgETerrain.mbtiles --out format tif --threads 12
[osgEarth]  [GDAL] Layer "GDALElevation" Resolution= 0.020232x0.00833333 max=0.00833333
[osgEarth]  [GDAL] Layer "GDALElevation" osgETerrain.vrt max Data Level: 7
[osgEarth]  [TileLayer] Layer "GDALElevation" [srs=WGS 84, min=-180,-90 max=180,90 lod0=2,1 vdatum=geodetic] [no cache]
[osgEarth]  [osgearth_conv] FROM:
{
   "GDALElevation" : {
      "driver" : "GDALElevation",
      "url" : "osgETerrain.vrt"
   }
}

[osgEarth]  [osgearth_conv] TO:
{
   "MBTilesElevation" : {
      "driver" : "MBTilesElevation",
      "filename" : "osgETerrain.mbtiles",
      "format" : "tif",
      "profile" : {
         "num_tiles_high_at_lod_0" : 1.0,
         "num_tiles_wide_at_lod_0" : 2.0,
         "srs" : "+proj=longlat +datum=WGS84 +no_defs",
         "vdatum" : {},
         "xmax" : "180",
         "xmin" : "-180",
         "ymax" : "90",
         "ymin" : "-90"
      }
   }
}

[osgEarth]  [osgearth_conv] Calculated max level = 7
Working...
[osgEarth]  Starting 12 threads
[osgEarth]  484 tasks in the queue.
484/248 195% complete, 304m43s projected, -289m-59s remaining
Complete. Time = 36096.4 seconds.


When I run osgearth_conv utility built in 3.0 using the exact same dataset, I get the exact same output except the number of tiles processes is 42346/42346 100% complete which is what I would expect.

Should I submit a ticket to have this problem investigated further?