Another Nodata issue... maybe?

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

Another Nodata issue... maybe?

Andyjo

So I was processing some imagery near the coast, and everything has been working fine, but when I started looking at the end product I realized… something’s not right! The projected images are HUGE (compared to just projecting on the ellipsoid). So a little more digging, and I found that some of our imagery is over the ocean, which means I should be getting null values from our DEM, and the elevation manager should drop down to the EGM grid….

 

So of course I run ossim-info –height w/ the coordinates, and get this:

Opened cell:            D:\ossim_data\elevation\srtm\jp2_90m\cut_n00w090_geographic_wgs84.jp2

MSL to ellipsoid delta: 14.1252937808422

Height above MSL:       -32767

Height above ellipsoid: -32752.8747062192

Geoid value:            14.1252937808425

 

That makes sense for how large the projections come out but obviously I don’t want to use -32k as a elevation value… so I was curious to see what it looks like with ossim-info and gdalinfo (their dumps are below), and it looks like the min_value and null_value are not the same in my DEM… if I choose a point over the ocean shouldn’t I get null? And then the elevation manager should drop down to the next level, etc….?

 

So, is my DEM screwed up? Other tools I’m using (like global mapper) display the DEM fine, and don’t report -32767 in the oceans…

 

ossim-info.exe -p D:\ossim_data\elevation\srtm\jp2_90m\cut_n00w090_geographic_wgs84.jp2

image0.band0.max_value:  32767

image0.band0.min_value:  -32767

image0.band0.null_value:  -32768

image0.entry:  0

image0.geometry.decimal_degrees_per_pixel_lat:  0.000833333353511989

image0.geometry.decimal_degrees_per_pixel_lon:  0.000833333353511989

image0.geometry.decimations:  (1,1) (0.5,0.5) (0.25,0.25) (0.125,0.125) (0.0625,

0.0625) (0.03125,0.03125) (0.015625,0.015625) (0.0078125,0.0078125) (0.00390625,0.00390625) (0.001953125,0.001953125) (0.0009765625,0.0009765625)

image0.geometry.gsd:  (92.6625455586233,92.6625455586233)

image0.geometry.image_size:  (36023,36023)

image0.geometry.ll_lat:  -0.00916669110296066

image0.geometry.ll_lon:  -90.0091666668886

image0.geometry.lr_lat:  -0.00916669110296066

image0.geometry.lr_lon:  -59.9908326066797

image0.geometry.meters_per_pixel_x:  92.6625455586233

image0.geometry.meters_per_pixel_y:  92.6625455586233

image0.geometry.projection.central_meridian:  0

image0.geometry.projection.datum:  WGE

image0.geometry.projection.elevation_lookup_flag:  0

image0.geometry.projection.ellipse_code:  WE

image0.geometry.projection.ellipse_epsg_code:  7030

image0.geometry.projection.ellipse_name:  WGS 84

image0.geometry.projection.false_easting_northing:  (0,0)

image0.geometry.projection.false_easting_northing_units:  meters

image0.geometry.projection.major_axis:  6378137

image0.geometry.projection.minor_axis:  6356752.3142

image0.geometry.projection.origin_latitude:  0

image0.geometry.projection.pcs_code:  4326

image0.geometry.projection.pixel_scale_units:  degrees

image0.geometry.projection.pixel_scale_xy:  (0.000833333353511989,0.000833333353511989)

image0.geometry.projection.srs_name:  EPSG:4326

image0.geometry.projection.tie_point_units:  degrees

image0.geometry.projection.tie_point_xy:  (-90.0091666668886,30.0091673691059)

image0.geometry.projection.type:  ossimEquDistCylProjection

image0.geometry.target_rrds:  0

image0.geometry.tie_point_lat:  30.0091673691059

image0.geometry.tie_point_lon:  -90.0091666668886

image0.geometry.type:  ossimImageGeometry

image0.geometry.ul_lat:  30.0091673691059

image0.geometry.ul_lon:  -90.0091666668886

image0.geometry.ur_lat:  30.0091673691059

image0.geometry.ur_lon:  -59.9908326066797

number_entries:  1

 

gdalinfo D:\ossim_data\elevation\srtm\jp2_90m\cut_n00w090_geographic_wgs84.jp2

Driver: JP2OpenJPEG/JPEG-2000 driver based on OpenJPEG library

Files: D:\ossim_data\elevation\srtm\jp2_90m\cut_n00w090_geographic_wgs84.jp2

Size is 36023, 36023

Coordinate System is:

GEOGCS["WGS 84",

    DATUM["WGS_1984",

        SPHEROID["WGS 84",6378137,298.257222932867,

            AUTHORITY["EPSG","7030"]],

        AUTHORITY["EPSG","6326"]],

    PRIMEM["Greenwich",0],

    UNIT["degree",0.0174532925199433],

    AUTHORITY["EPSG","4326"]]

Origin = (-90.009166666888603,30.009167369105899)

Pixel Size = (0.000833333353512,-0.000833333353512)

Corner Coordinates:

Upper Left  ( -90.0091667,  30.0091674) ( 90d 0'33.00"W, 30d 0'33.00"N)

Lower Left  ( -90.0091667,  -0.0100000) ( 90d 0'33.00"W,  0d 0'36.00"S)

Upper Right ( -59.9899993,  30.0091674) ( 59d59'24.00"W, 30d 0'33.00"N)

Lower Right ( -59.9899993,  -0.0100000) ( 59d59'24.00"W,  0d 0'36.00"S)

Center      ( -74.9995830,  14.9995837) ( 74d59'58.50"W, 14d59'58.50"N)

Band 1 Block=1024x1024 Type=Int16, ColorInterp=Undefined


------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer
Reply | Threaded
Open this post in threaded view
|

Re: Another Nodata issue... maybe?

Garrett Potts-2
<base href="x-msg://248/">Hello Andrew:

I am not sure if you have updated to the latest OSSIM but was curious about your debug output:

ossim-info --cg --ci -T .* <input-file>

Change the <input-file> to yours and see what your output is.  Can you paste here?  the --cg is center ground and --ci is center image so this will print the center ground of your image and the trace will tell us what database and plugins are loaded.   

If the NULL value is not detected in an elevation cell then it will think it's valid. 


Take care

Garrett


On Jun 17, 2013, at 10:19 AM, Andrew D. Johnson <[hidden email]> wrote:

So I was processing some imagery near the coast, and everything has been working fine, but when I started looking at the end product I realized… something’s not right! The projected images are HUGE (compared to just projecting on the ellipsoid). So a little more digging, and I found that some of our imagery is over the ocean, which means I should be getting null values from our DEM, and the elevation manager should drop down to the EGM grid….
 
So of course I run ossim-info –height w/ the coordinates, and get this:
Opened cell:            D:\ossim_data\elevation\srtm\jp2_90m\cut_n00w090_geographic_wgs84.jp2
MSL to ellipsoid delta: 14.1252937808422
Height above MSL:       -32767
Height above ellipsoid: -32752.8747062192
Geoid value:            14.1252937808425
 
That makes sense for how large the projections come out but obviously I don’t want to use -32k as a elevation value… so I was curious to see what it looks like with ossim-info and gdalinfo (their dumps are below), and it looks like the min_value and null_value are not the same in my DEM… if I choose a point over the ocean shouldn’t I get null? And then the elevation manager should drop down to the next level, etc….?
 
So, is my DEM screwed up? Other tools I’m using (like global mapper) display the DEM fine, and don’t report -32767 in the oceans…
 
ossim-info.exe -p D:\ossim_data\elevation\srtm\jp2_90m\cut_n00w090_geographic_wgs84.jp2
image0.band0.max_value:  32767
image0.band0.min_value:  -32767
image0.band0.null_value:  -32768
image0.entry:  0
image0.geometry.decimal_degrees_per_pixel_lat:  0.000833333353511989
image0.geometry.decimal_degrees_per_pixel_lon:  0.000833333353511989
image0.geometry.decimations:  (1,1) (0.5,0.5) (0.25,0.25) (0.125,0.125) (0.0625,
0.0625) (0.03125,0.03125) (0.015625,0.015625) (0.0078125,0.0078125) (0.00390625,0.00390625) (0.001953125,0.001953125) (0.0009765625,0.0009765625)
image0.geometry.gsd:  (92.6625455586233,92.6625455586233)
image0.geometry.image_size:  (36023,36023)
image0.geometry.ll_lat:  -0.00916669110296066
image0.geometry.ll_lon:  -90.0091666668886
image0.geometry.lr_lat:  -0.00916669110296066
image0.geometry.lr_lon:  -59.9908326066797
image0.geometry.meters_per_pixel_x:  92.6625455586233
image0.geometry.meters_per_pixel_y:  92.6625455586233
image0.geometry.projection.central_meridian:  0
image0.geometry.projection.datum:  WGE
image0.geometry.projection.elevation_lookup_flag:  0
image0.geometry.projection.ellipse_code:  WE
image0.geometry.projection.ellipse_epsg_code:  7030
image0.geometry.projection.ellipse_name:  WGS 84
image0.geometry.projection.false_easting_northing:  (0,0)
image0.geometry.projection.false_easting_northing_units:  meters
image0.geometry.projection.major_axis:  6378137
image0.geometry.projection.minor_axis:  6356752.3142
image0.geometry.projection.origin_latitude:  0
image0.geometry.projection.pcs_code:  4326
image0.geometry.projection.pixel_scale_units:  degrees
image0.geometry.projection.pixel_scale_xy:  (0.000833333353511989,0.000833333353511989)
image0.geometry.projection.srs_name:  EPSG:4326
image0.geometry.projection.tie_point_units:  degrees
image0.geometry.projection.tie_point_xy:  (-90.0091666668886,30.0091673691059)
image0.geometry.projection.type:  ossimEquDistCylProjection
image0.geometry.target_rrds:  0
image0.geometry.tie_point_lat:  30.0091673691059
image0.geometry.tie_point_lon:  -90.0091666668886
image0.geometry.type:  ossimImageGeometry
image0.geometry.ul_lat:  30.0091673691059
image0.geometry.ul_lon:  -90.0091666668886
image0.geometry.ur_lat:  30.0091673691059
image0.geometry.ur_lon:  -59.9908326066797
number_entries:  1
 
gdalinfo D:\ossim_data\elevation\srtm\jp2_90m\cut_n00w090_geographic_wgs84.jp2
Driver: JP2OpenJPEG/JPEG-2000 driver based on OpenJPEG library
Files: D:\ossim_data\elevation\srtm\jp2_90m\cut_n00w090_geographic_wgs84.jp2
Size is 36023, 36023
Coordinate System is:
GEOGCS["WGS 84",
    DATUM["WGS_1984",
        SPHEROID["WGS 84",6378137,298.257222932867,
            AUTHORITY["EPSG","7030"]],
        AUTHORITY["EPSG","6326"]],
    PRIMEM["Greenwich",0],
    UNIT["degree",0.0174532925199433],
    AUTHORITY["EPSG","4326"]]
Origin = (-90.009166666888603,30.009167369105899)
Pixel Size = (0.000833333353512,-0.000833333353512)
Corner Coordinates:
Upper Left  ( -90.0091667,  30.0091674) ( 90d 0'33.00"W, 30d 0'33.00"N)
Lower Left  ( -90.0091667,  -0.0100000) ( 90d 0'33.00"W,  0d 0'36.00"S)
Upper Right ( -59.9899993,  30.0091674) ( 59d59'24.00"W, 30d 0'33.00"N)
Lower Right ( -59.9899993,  -0.0100000) ( 59d59'24.00"W,  0d 0'36.00"S)
Center      ( -74.9995830,  14.9995837) ( 74d59'58.50"W, 14d59'58.50"N)
Band 1 Block=1024x1024 Type=Int16, ColorInterp=Undefined
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer


------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer
Reply | Threaded
Open this post in threaded view
|

Re: Another Nodata issue... maybe?

Andyjo
<base href="x-msg://248/">

Thanks Garrett,

I did a little more digging into the DEM we’re using, all the way back to the CGIAR SRTM Model, turns out the geotiffs we got were only ‘sort of’ georeferenced, no coordinate system defined, so I loaded all of the data up into global mapper and re-exported w/ the correct projection information, but when I re-exported the data the NoData value changed… not sure if the underlying data did as well..

 

Original File:

Files: SRTM_4-1\cut_n00w090.tif

Driver: GTiff/GeoTIFF

Size is 36023, 36023

Coordinate System is `'

Origin = (-90.009583333565388,30.009584035782609)

Pixel Size = (0.000833333353512,-0.000833333353512)

Image Structure Metadata:

  INTERLEAVE=BAND

Corner Coordinates:

Upper Left  ( -90.0095833,  30.0095840)

Lower Left  ( -90.0095833,  -0.0095834)

Upper Right ( -59.9904159,  30.0095840)

Lower Right ( -59.9904159,  -0.0095834)

Center      ( -74.9999996,  15.0000003)

Band 1 Block=36023x1 Type=Int16, ColorInterp=Gray

  NoData Value=-32768

 

New File:

Driver: GTiff/GeoTIFF

Files: <a href="file:///\\nas2\gis\ref\dem\SRTM_4-1\projected\cut_n00w090_geographic_wgs84.tif"> SRTM_4-1\projected\cut_n00w090_geographic_wgs84.tif

Size is 36023, 36023

Coordinate System is:

GEOGCS["WGS 84",

    DATUM["WGS_1984",

        SPHEROID["WGS 84",6378137,298.257223560493,

            AUTHORITY["EPSG","7030"]],

        AUTHORITY["EPSG","6326"]],

    PRIMEM["Greenwich",0],

    UNIT["degree",0.0174532925199433],

    AUTHORITY["EPSG","4326"]]

Origin = (-90.009583333565388,30.009584035782609)

Pixel Size = (0.000833333353512,-0.000833333353512)

Metadata:

  AREA_OR_POINT=Point

  TIFFTAG_MAXSAMPLEVALUE=5778

  TIFFTAG_MINSAMPLEVALUE=65185

Image Structure Metadata:

  INTERLEAVE=BAND

Corner Coordinates:

Upper Left  ( -90.0095833,  30.0095840) ( 90d 0'34.50"W, 30d 0'34.50"N)

Lower Left  ( -90.0095833,  -0.0095834) ( 90d 0'34.50"W,  0d 0'34.50"S)

Upper Right ( -59.9904159,  30.0095840) ( 59d59'25.50"W, 30d 0'34.50"N)

Lower Right ( -59.9904159,  -0.0095834) ( 59d59'25.50"W,  0d 0'34.50"S)

Center      ( -74.9999996,  15.0000003) ( 75d 0' 0.00"W, 15d 0' 0.00"N)

Band 1 Block=36023x1 Type=Int16, ColorInterp=Gray

  NoData Value=-32767

 

So.. not sure if that’s the problem, but I also attached the dump from ossim info on the file, and on the –height cmd

From looking at it the logs… the only thing that looks interesting to me is this:

unding rect: ( 30.009167369105899, -90.009166666888603, nan, WGE ), ( -0.009166691102961, -59.990832606679739, nan, WGE )

 

Thanks!

-Andy

 


------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer

height.txt (25K) Download Attachment
10001.txt (54K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Another Nodata issue... maybe?

Garrett Potts-2
<base href="x-msg://248/">Hello Andy:

Can you also give me your preference file?


Take care

Garrett

On Jun 17, 2013, at 2:51 PM, Andrew D. Johnson <[hidden email]> wrote:

Thanks Garrett,
I did a little more digging into the DEM we’re using, all the way back to the CGIAR SRTM Model, turns out the geotiffs we got were only ‘sort of’ georeferenced, no coordinate system defined, so I loaded all of the data up into global mapper and re-exported w/ the correct projection information, but when I re-exported the data the NoData value changed… not sure if the underlying data did as well..
 
Original File:
Files: SRTM_4-1\cut_n00w090.tif
Driver: GTiff/GeoTIFF
Size is 36023, 36023
Coordinate System is `'
Origin = (-90.009583333565388,30.009584035782609)
Pixel Size = (0.000833333353512,-0.000833333353512)
Image Structure Metadata:
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  ( -90.0095833,  30.0095840)
Lower Left  ( -90.0095833,  -0.0095834)
Upper Right ( -59.9904159,  30.0095840)
Lower Right ( -59.9904159,  -0.0095834)
Center      ( -74.9999996,  15.0000003)
Band 1 Block=36023x1 Type=Int16, ColorInterp=Gray
  NoData Value=-32768
 
New File:
Driver: GTiff/GeoTIFF
Files: <a href="file:///\\nas2\gis\ref\dem\SRTM_4-1\projected\cut_n00w090_geographic_wgs84.tif" style="color: purple; text-decoration: underline; ">SRTM_4-1\projected\cut_n00w090_geographic_wgs84.tif
Size is 36023, 36023
Coordinate System is:
GEOGCS["WGS 84",
    DATUM["WGS_1984",
        SPHEROID["WGS 84",6378137,298.257223560493,
            AUTHORITY["EPSG","7030"]],
        AUTHORITY["EPSG","6326"]],
    PRIMEM["Greenwich",0],
    UNIT["degree",0.0174532925199433],
    AUTHORITY["EPSG","4326"]]
Origin = (-90.009583333565388,30.009584035782609)
Pixel Size = (0.000833333353512,-0.000833333353512)
Metadata:
  AREA_OR_POINT=Point
  TIFFTAG_MAXSAMPLEVALUE=5778
  TIFFTAG_MINSAMPLEVALUE=65185
Image Structure Metadata:
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  ( -90.0095833,  30.0095840) ( 90d 0'34.50"W, 30d 0'34.50"N)
Lower Left  ( -90.0095833,  -0.0095834) ( 90d 0'34.50"W,  0d 0'34.50"S)
Upper Right ( -59.9904159,  30.0095840) ( 59d59'25.50"W, 30d 0'34.50"N)
Lower Right ( -59.9904159,  -0.0095834) ( 59d59'25.50"W,  0d 0'34.50"S)
Center      ( -74.9999996,  15.0000003) ( 75d 0' 0.00"W, 15d 0' 0.00"N)
Band 1 Block=36023x1 Type=Int16, ColorInterp=Gray
  NoData Value=-32767
 
So.. not sure if that’s the problem, but I also attached the dump from ossim info on the file, and on the –height cmd
From looking at it the logs… the only thing that looks interesting to me is this:
unding rect: ( 30.009167369105899, -90.009166666888603, nan, WGE ), ( -0.009166691102961, -59.990832606679739, nan, WGE )
 
Thanks!
-Andy
 
<height.txt><10001.txt>


------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer
Reply | Threaded
Open this post in threaded view
|

Re: Another Nodata issue... maybe?

Garrett Potts-2
In reply to this post by Andyjo
<base href="x-msg://248/">Hello Andrew:

 see that your cell is a Jp2 image.  I don't think any of the min max and null values are written to a jp2 image.  You may have to try and create and external .cmd file that overrides the defaults.

run ossim-cmm on the jp2 image.  It should generate an associated .cmd file.  Open the CMD file and adjust the null pixel, and in max values as appropriate.  Then run you ossim-info --height example again.


Take care

Garrett

On Jun 17, 2013, at 2:51 PM, Andrew D. Johnson <[hidden email]> wrote:

Thanks Garrett,
I did a little more digging into the DEM we’re using, all the way back to the CGIAR SRTM Model, turns out the geotiffs we got were only ‘sort of’ georeferenced, no coordinate system defined, so I loaded all of the data up into global mapper and re-exported w/ the correct projection information, but when I re-exported the data the NoData value changed… not sure if the underlying data did as well..
 
Original File:
Files: SRTM_4-1\cut_n00w090.tif
Driver: GTiff/GeoTIFF
Size is 36023, 36023
Coordinate System is `'
Origin = (-90.009583333565388,30.009584035782609)
Pixel Size = (0.000833333353512,-0.000833333353512)
Image Structure Metadata:
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  ( -90.0095833,  30.0095840)
Lower Left  ( -90.0095833,  -0.0095834)
Upper Right ( -59.9904159,  30.0095840)
Lower Right ( -59.9904159,  -0.0095834)
Center      ( -74.9999996,  15.0000003)
Band 1 Block=36023x1 Type=Int16, ColorInterp=Gray
  NoData Value=-32768
 
New File:
Driver: GTiff/GeoTIFF
Files: <a href="file:///\\nas2\gis\ref\dem\SRTM_4-1\projected\cut_n00w090_geographic_wgs84.tif" style="color: purple; text-decoration: underline; ">SRTM_4-1\projected\cut_n00w090_geographic_wgs84.tif
Size is 36023, 36023
Coordinate System is:
GEOGCS["WGS 84",
    DATUM["WGS_1984",
        SPHEROID["WGS 84",6378137,298.257223560493,
            AUTHORITY["EPSG","7030"]],
        AUTHORITY["EPSG","6326"]],
    PRIMEM["Greenwich",0],
    UNIT["degree",0.0174532925199433],
    AUTHORITY["EPSG","4326"]]
Origin = (-90.009583333565388,30.009584035782609)
Pixel Size = (0.000833333353512,-0.000833333353512)
Metadata:
  AREA_OR_POINT=Point
  TIFFTAG_MAXSAMPLEVALUE=5778
  TIFFTAG_MINSAMPLEVALUE=65185
Image Structure Metadata:
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  ( -90.0095833,  30.0095840) ( 90d 0'34.50"W, 30d 0'34.50"N)
Lower Left  ( -90.0095833,  -0.0095834) ( 90d 0'34.50"W,  0d 0'34.50"S)
Upper Right ( -59.9904159,  30.0095840) ( 59d59'25.50"W, 30d 0'34.50"N)
Lower Right ( -59.9904159,  -0.0095834) ( 59d59'25.50"W,  0d 0'34.50"S)
Center      ( -74.9999996,  15.0000003) ( 75d 0' 0.00"W, 15d 0' 0.00"N)
Band 1 Block=36023x1 Type=Int16, ColorInterp=Gray
  NoData Value=-32767
 
So.. not sure if that’s the problem, but I also attached the dump from ossim info on the file, and on the –height cmd
From looking at it the logs… the only thing that looks interesting to me is this:
unding rect: ( 30.009167369105899, -90.009166666888603, nan, WGE ), ( -0.009166691102961, -59.990832606679739, nan, WGE )
 
Thanks!
-Andy
 
<height.txt><10001.txt>


------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer
Reply | Threaded
Open this post in threaded view
|

Re: Another Nodata issue... maybe?

David Burken
Hi guys,

Garrett, you mean a dot.omd (ossim meta data) I think.  Andy you can do with "ossim-cmm" (compute min max) and specify the null values like:

ossim-cmm --null -32768 <your-input-image>

It will write a dot.omd file.

I wonder if the jp2 was lossy and introduce a -32767.  If so you could use ossim-pixel-flipper on your tiffs.  It was written to fix null/nodata issues.

Also it looks like you could just use ossim-icp to convert from jp2 to tif (if that's what you wanted).

ossim-icp tiff_tiled_band_separate <in-file> <out-file>

Hope that helps,
Dave

On 6/17/2013 2:56 PM, Garrett Potts wrote:
<base href="x-msg://248/">Hello Andrew:

 see that your cell is a Jp2 image.  I don't think any of the min max and null values are written to a jp2 image.  You may have to try and create and external .cmd file that overrides the defaults.

run ossim-cmm on the jp2 image.  It should generate an associated .cmd file.  Open the CMD file and adjust the null pixel, and in max values as appropriate.  Then run you ossim-info --height example again.


Take care

Garrett

On Jun 17, 2013, at 2:51 PM, Andrew D. Johnson <[hidden email]> wrote:

Thanks Garrett,
I did a little more digging into the DEM we’re using, all the way back to the CGIAR SRTM Model, turns out the geotiffs we got were only ‘sort of’ georeferenced, no coordinate system defined, so I loaded all of the data up into global mapper and re-exported w/ the correct projection information, but when I re-exported the data the NoData value changed… not sure if the underlying data did as well..
 
Original File:
Files: SRTM_4-1\cut_n00w090.tif
Driver: GTiff/GeoTIFF
Size is 36023, 36023
Coordinate System is `'
Origin = (-90.009583333565388,30.009584035782609)
Pixel Size = (0.000833333353512,-0.000833333353512)
Image Structure Metadata:
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  ( -90.0095833,  30.0095840)
Lower Left  ( -90.0095833,  -0.0095834)
Upper Right ( -59.9904159,  30.0095840)
Lower Right ( -59.9904159,  -0.0095834)
Center      ( -74.9999996,  15.0000003)
Band 1 Block=36023x1 Type=Int16, ColorInterp=Gray
  NoData Value=-32768
 
New File:
Driver: GTiff/GeoTIFF
Size is 36023, 36023
Coordinate System is:
GEOGCS["WGS 84",
    DATUM["WGS_1984",
        SPHEROID["WGS 84",6378137,298.257223560493,
            AUTHORITY["EPSG","7030"]],
        AUTHORITY["EPSG","6326"]],
    PRIMEM["Greenwich",0],
    UNIT["degree",0.0174532925199433],
    AUTHORITY["EPSG","4326"]]
Origin = (-90.009583333565388,30.009584035782609)
Pixel Size = (0.000833333353512,-0.000833333353512)
Metadata:
  AREA_OR_POINT=Point
  TIFFTAG_MAXSAMPLEVALUE=5778
  TIFFTAG_MINSAMPLEVALUE=65185
Image Structure Metadata:
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  ( -90.0095833,  30.0095840) ( 90d 0'34.50"W, 30d 0'34.50"N)
Lower Left  ( -90.0095833,  -0.0095834) ( 90d 0'34.50"W,  0d 0'34.50"S)
Upper Right ( -59.9904159,  30.0095840) ( 59d59'25.50"W, 30d 0'34.50"N)
Lower Right ( -59.9904159,  -0.0095834) ( 59d59'25.50"W,  0d 0'34.50"S)
Center      ( -74.9999996,  15.0000003) ( 75d 0' 0.00"W, 15d 0' 0.00"N)
Band 1 Block=36023x1 Type=Int16, ColorInterp=Gray
  NoData Value=-32767
 
So.. not sure if that’s the problem, but I also attached the dump from ossim info on the file, and on the –height cmd
From looking at it the logs… the only thing that looks interesting to me is this:
unding rect: ( 30.009167369105899, -90.009166666888603, nan, WGE ), ( -0.009166691102961, -59.990832606679739, nan, WGE )
 
Thanks!
-Andy
 
<height.txt><10001.txt>



------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev


_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer


------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer
Reply | Threaded
Open this post in threaded view
|

Re: Another Nodata issue... maybe?

Andyjo
In reply to this post by Garrett Potts-2
<base href="x-msg://248/">

Making and modifying the omd file doesn’t seem to help, also tried dave’s suggestion of specifying --null:

cut_n00w090_geographic_wgs84.omd

band1.max_value:  5778

band1.min_value:  -32767

band1.null_value:  -32768

number_bands:  1

scalar_type:  ossim_sint16

 

tried -32767 for null, tried playing w/ the min value making it -100, no dice, ran ossim-info on it and the min/null values are changing but the height is still screwy

Also, it doesn’t look like jp2 is introducing the -32767, it is introduced when I added the projection information w/ global mapper: “Global Mapper uses the same no-data value of -32767 for all 16-bit elevation GeoTIFF exports. The inputs to the export could have any combination of no-data values, so a single standard one is chosen. It really doesn't matter what value you choose for the no-data value, so long as it is outside of the valid data range and you store that no-data value in the GeoTIFF tags in the file header.”

 

Prefs file is attached

I guess I should try converting the DEMs with GDAL to add the projection

 

-Andy

 

From: Garrett Potts [mailto:[hidden email]]
Sent: Monday, June 17, 2013 2:57 PM
To: Andrew D. Johnson
Cc: [hidden email]
Subject: Re: [OSSIM] Another Nodata issue... maybe?

 

Hello Andrew:

 

 see that your cell is a Jp2 image.  I don't think any of the min max and null values are written to a jp2 image.  You may have to try and create and external .cmd file that overrides the defaults.

 

run ossim-cmm on the jp2 image.  It should generate an associated .cmd file.  Open the CMD file and adjust the null pixel, and in max values as appropriate.  Then run you ossim-info --height example again.

 

 

Take care

 

Garrett

 

On Jun 17, 2013, at 2:51 PM, Andrew D. Johnson <[hidden email]> wrote:



Thanks Garrett,

I did a little more digging into the DEM we’re using, all the way back to the CGIAR SRTM Model, turns out the geotiffs we got were only ‘sort of’ georeferenced, no coordinate system defined, so I loaded all of the data up into global mapper and re-exported w/ the correct projection information, but when I re-exported the data the NoData value changed… not sure if the underlying data did as well..

 

Original File:

Files: SRTM_4-1\cut_n00w090.tif

Driver: GTiff/GeoTIFF

Size is 36023, 36023

Coordinate System is `'

Origin = (-90.009583333565388,30.009584035782609)

Pixel Size = (0.000833333353512,-0.000833333353512)

Image Structure Metadata:

  INTERLEAVE=BAND

Corner Coordinates:

Upper Left  ( -90.0095833,  30.0095840)

Lower Left  ( -90.0095833,  -0.0095834)

Upper Right ( -59.9904159,  30.0095840)

Lower Right ( -59.9904159,  -0.0095834)

Center      ( -74.9999996,  15.0000003)

Band 1 Block=36023x1 Type=Int16, ColorInterp=Gray

  NoData Value=-32768

 

New File:

Driver: GTiff/GeoTIFF

Files: <a href="file:///\\nas2\gis\ref\dem\SRTM_4-1\projected\cut_n00w090_geographic_wgs84.tif">SRTM_4-1\projected\cut_n00w090_geographic_wgs84.tif

Size is 36023, 36023

Coordinate System is:

GEOGCS["WGS 84",

    DATUM["WGS_1984",

        SPHEROID["WGS 84",6378137,298.257223560493,

            AUTHORITY["EPSG","7030"]],

        AUTHORITY["EPSG","6326"]],

    PRIMEM["Greenwich",0],

    UNIT["degree",0.0174532925199433],

    AUTHORITY["EPSG","4326"]]

Origin = (-90.009583333565388,30.009584035782609)

Pixel Size = (0.000833333353512,-0.000833333353512)

Metadata:

  AREA_OR_POINT=Point

  TIFFTAG_MAXSAMPLEVALUE=5778

  TIFFTAG_MINSAMPLEVALUE=65185

Image Structure Metadata:

  INTERLEAVE=BAND

Corner Coordinates:

Upper Left  ( -90.0095833,  30.0095840) ( 90d 0'34.50"W, 30d 0'34.50"N)

Lower Left  ( -90.0095833,  -0.0095834) ( 90d 0'34.50"W,  0d 0'34.50"S)

Upper Right ( -59.9904159,  30.0095840) ( 59d59'25.50"W, 30d 0'34.50"N)

Lower Right ( -59.9904159,  -0.0095834) ( 59d59'25.50"W,  0d 0'34.50"S)

Center      ( -74.9999996,  15.0000003) ( 75d 0' 0.00"W, 15d 0' 0.00"N)

Band 1 Block=36023x1 Type=Int16, ColorInterp=Gray

  NoData Value=-32767

 

So.. not sure if that’s the problem, but I also attached the dump from ossim info on the file, and on the –height cmd

From looking at it the logs… the only thing that looks interesting to me is this:

unding rect: ( 30.009167369105899, -90.009166666888603, nan, WGE ), ( -0.009166691102961, -59.990832606679739, nan, WGE )

 

Thanks!

-Andy

 

<height.txt><10001.txt>

 


------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer

ossim_prefs (19K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Another Nodata issue... maybe?

Andyjo
<base href="x-msg://248/">

So I reprocessed my entire elevation set with gdal_translate, and ossim-icp, and now it looks like it’s going to work, I’ll have to do some more investigation into why my original DEMs didn’t work at a later point.

Thanks for your help!

 

-Andy

 

From: Andrew D. Johnson [mailto:[hidden email]]
Sent: Monday, June 17, 2013 3:19 PM
To: Garrett Potts
Cc: [hidden email]
Subject: Re: [OSSIM] Another Nodata issue... maybe?

 

Making and modifying the omd file doesn’t seem to help, also tried dave’s suggestion of specifying --null:

cut_n00w090_geographic_wgs84.omd

band1.max_value:  5778

band1.min_value:  -32767

band1.null_value:  -32768

number_bands:  1

scalar_type:  ossim_sint16

 

tried -32767 for null, tried playing w/ the min value making it -100, no dice, ran ossim-info on it and the min/null values are changing but the height is still screwy

Also, it doesn’t look like jp2 is introducing the -32767, it is introduced when I added the projection information w/ global mapper: “Global Mapper uses the same no-data value of -32767 for all 16-bit elevation GeoTIFF exports. The inputs to the export could have any combination of no-data values, so a single standard one is chosen. It really doesn't matter what value you choose for the no-data value, so long as it is outside of the valid data range and you store that no-data value in the GeoTIFF tags in the file header.”

 

Prefs file is attached

I guess I should try converting the DEMs with GDAL to add the projection

 

-Andy

 

From: Garrett Potts [[hidden email]]
Sent: Monday, June 17, 2013 2:57 PM
To: Andrew D. Johnson
Cc: [hidden email]
Subject: Re: [OSSIM] Another Nodata issue... maybe?

 

Hello Andrew:

 

 see that your cell is a Jp2 image.  I don't think any of the min max and null values are written to a jp2 image.  You may have to try and create and external .cmd file that overrides the defaults.

 

run ossim-cmm on the jp2 image.  It should generate an associated .cmd file.  Open the CMD file and adjust the null pixel, and in max values as appropriate.  Then run you ossim-info --height example again.

 

 

Take care

 

Garrett

 

On Jun 17, 2013, at 2:51 PM, Andrew D. Johnson <[hidden email]> wrote:

 

Thanks Garrett,

I did a little more digging into the DEM we’re using, all the way back to the CGIAR SRTM Model, turns out the geotiffs we got were only ‘sort of’ georeferenced, no coordinate system defined, so I loaded all of the data up into global mapper and re-exported w/ the correct projection information, but when I re-exported the data the NoData value changed… not sure if the underlying data did as well..

 

Original File:

Files: SRTM_4-1\cut_n00w090.tif

Driver: GTiff/GeoTIFF

Size is 36023, 36023

Coordinate System is `'

Origin = (-90.009583333565388,30.009584035782609)

Pixel Size = (0.000833333353512,-0.000833333353512)

Image Structure Metadata:

  INTERLEAVE=BAND

Corner Coordinates:

Upper Left  ( -90.0095833,  30.0095840)

Lower Left  ( -90.0095833,  -0.0095834)

Upper Right ( -59.9904159,  30.0095840)

Lower Right ( -59.9904159,  -0.0095834)

Center      ( -74.9999996,  15.0000003)

Band 1 Block=36023x1 Type=Int16, ColorInterp=Gray

  NoData Value=-32768

 

New File:

Driver: GTiff/GeoTIFF

Files: <a href="file:///\\nas2\gis\ref\dem\SRTM_4-1\projected\cut_n00w090_geographic_wgs84.tif">SRTM_4-1\projected\cut_n00w090_geographic_wgs84.tif

Size is 36023, 36023

Coordinate System is:

GEOGCS["WGS 84",

    DATUM["WGS_1984",

        SPHEROID["WGS 84",6378137,298.257223560493,

            AUTHORITY["EPSG","7030"]],

        AUTHORITY["EPSG","6326"]],

    PRIMEM["Greenwich",0],

    UNIT["degree",0.0174532925199433],

    AUTHORITY["EPSG","4326"]]

Origin = (-90.009583333565388,30.009584035782609)

Pixel Size = (0.000833333353512,-0.000833333353512)

Metadata:

  AREA_OR_POINT=Point

  TIFFTAG_MAXSAMPLEVALUE=5778

  TIFFTAG_MINSAMPLEVALUE=65185

Image Structure Metadata:

  INTERLEAVE=BAND

Corner Coordinates:

Upper Left  ( -90.0095833,  30.0095840) ( 90d 0'34.50"W, 30d 0'34.50"N)

Lower Left  ( -90.0095833,  -0.0095834) ( 90d 0'34.50"W,  0d 0'34.50"S)

Upper Right ( -59.9904159,  30.0095840) ( 59d59'25.50"W, 30d 0'34.50"N)

Lower Right ( -59.9904159,  -0.0095834) ( 59d59'25.50"W,  0d 0'34.50"S)

Center      ( -74.9999996,  15.0000003) ( 75d 0' 0.00"W, 15d 0' 0.00"N)

Band 1 Block=36023x1 Type=Int16, ColorInterp=Gray

  NoData Value=-32767

 

So.. not sure if that’s the problem, but I also attached the dump from ossim info on the file, and on the –height cmd

From looking at it the logs… the only thing that looks interesting to me is this:

unding rect: ( 30.009167369105899, -90.009166666888603, nan, WGE ), ( -0.009166691102961, -59.990832606679739, nan, WGE )

 

Thanks!

-Andy

 

<height.txt><10001.txt>

 


------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer
Reply | Threaded
Open this post in threaded view
|

Re: Another Nodata issue... maybe?

David Burken
Hi Andy,

Glad you got it but I thought your original ossim-info -p (projection) of your jp2 looked good.  I think it's a lossy jp2 or min,max,null issue.  I just icp'd a srtm to a jp2 and the min, max, null looks good.  Anyway if you figure it out let us know.

Take care,
Dave


On 6/17/2013 6:52 PM, Andrew D. Johnson wrote:
<base href="x-msg://248/">

So I reprocessed my entire elevation set with gdal_translate, and ossim-icp, and now it looks like it’s going to work, I’ll have to do some more investigation into why my original DEMs didn’t work at a later point.

Thanks for your help!

 

-Andy

 

From: Andrew D. Johnson [[hidden email]]
Sent: Monday, June 17, 2013 3:19 PM
To: Garrett Potts
Cc: [hidden email]
Subject: Re: [OSSIM] Another Nodata issue... maybe?

 

Making and modifying the omd file doesn’t seem to help, also tried dave’s suggestion of specifying --null:

cut_n00w090_geographic_wgs84.omd

band1.max_value:  5778

band1.min_value:  -32767

band1.null_value:  -32768

number_bands:  1

scalar_type:  ossim_sint16

 

tried -32767 for null, tried playing w/ the min value making it -100, no dice, ran ossim-info on it and the min/null values are changing but the height is still screwy

Also, it doesn’t look like jp2 is introducing the -32767, it is introduced when I added the projection information w/ global mapper: “Global Mapper uses the same no-data value of -32767 for all 16-bit elevation GeoTIFF exports. The inputs to the export could have any combination of no-data values, so a single standard one is chosen. It really doesn't matter what value you choose for the no-data value, so long as it is outside of the valid data range and you store that no-data value in the GeoTIFF tags in the file header.”

 

Prefs file is attached

I guess I should try converting the DEMs with GDAL to add the projection

 

-Andy

 

From: Garrett Potts [[hidden email]]
Sent: Monday, June 17, 2013 2:57 PM
To: Andrew D. Johnson
Cc: [hidden email]
Subject: Re: [OSSIM] Another Nodata issue... maybe?

 

Hello Andrew:

 

 see that your cell is a Jp2 image.  I don't think any of the min max and null values are written to a jp2 image.  You may have to try and create and external .cmd file that overrides the defaults.

 

run ossim-cmm on the jp2 image.  It should generate an associated .cmd file.  Open the CMD file and adjust the null pixel, and in max values as appropriate.  Then run you ossim-info --height example again.

 

 

Take care

 

Garrett

 

On Jun 17, 2013, at 2:51 PM, Andrew D. Johnson <[hidden email]> wrote:

 

Thanks Garrett,

I did a little more digging into the DEM we’re using, all the way back to the CGIAR SRTM Model, turns out the geotiffs we got were only ‘sort of’ georeferenced, no coordinate system defined, so I loaded all of the data up into global mapper and re-exported w/ the correct projection information, but when I re-exported the data the NoData value changed… not sure if the underlying data did as well..

 

Original File:

Files: SRTM_4-1\cut_n00w090.tif

Driver: GTiff/GeoTIFF

Size is 36023, 36023

Coordinate System is `'

Origin = (-90.009583333565388,30.009584035782609)

Pixel Size = (0.000833333353512,-0.000833333353512)

Image Structure Metadata:

  INTERLEAVE=BAND

Corner Coordinates:

Upper Left  ( -90.0095833,  30.0095840)

Lower Left  ( -90.0095833,  -0.0095834)

Upper Right ( -59.9904159,  30.0095840)

Lower Right ( -59.9904159,  -0.0095834)

Center      ( -74.9999996,  15.0000003)

Band 1 Block=36023x1 Type=Int16, ColorInterp=Gray

  NoData Value=-32768

 

New File:

Driver: GTiff/GeoTIFF

Size is 36023, 36023

Coordinate System is:

GEOGCS["WGS 84",

    DATUM["WGS_1984",

        SPHEROID["WGS 84",6378137,298.257223560493,

            AUTHORITY["EPSG","7030"]],

        AUTHORITY["EPSG","6326"]],

    PRIMEM["Greenwich",0],

    UNIT["degree",0.0174532925199433],

    AUTHORITY["EPSG","4326"]]

Origin = (-90.009583333565388,30.009584035782609)

Pixel Size = (0.000833333353512,-0.000833333353512)

Metadata:

  AREA_OR_POINT=Point

  TIFFTAG_MAXSAMPLEVALUE=5778

  TIFFTAG_MINSAMPLEVALUE=65185

Image Structure Metadata:

  INTERLEAVE=BAND

Corner Coordinates:

Upper Left  ( -90.0095833,  30.0095840) ( 90d 0'34.50"W, 30d 0'34.50"N)

Lower Left  ( -90.0095833,  -0.0095834) ( 90d 0'34.50"W,  0d 0'34.50"S)

Upper Right ( -59.9904159,  30.0095840) ( 59d59'25.50"W, 30d 0'34.50"N)

Lower Right ( -59.9904159,  -0.0095834) ( 59d59'25.50"W,  0d 0'34.50"S)

Center      ( -74.9999996,  15.0000003) ( 75d 0' 0.00"W, 15d 0' 0.00"N)

Band 1 Block=36023x1 Type=Int16, ColorInterp=Gray

  NoData Value=-32767

 

So.. not sure if that’s the problem, but I also attached the dump from ossim info on the file, and on the –height cmd

From looking at it the logs… the only thing that looks interesting to me is this:

unding rect: ( 30.009167369105899, -90.009166666888603, nan, WGE ), ( -0.009166691102961, -59.990832606679739, nan, WGE )

 

Thanks!

-Andy

 

<height.txt><10001.txt>

 



------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev


_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer


------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
www.ossim.org
Ossim-developer mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/ossim-developer