[X] My Assistant

[Yadgar]

Hi(gh)!

I would like to generate POV-Ray meshes from PDS altimetry data files (for example the global Vesta file from Dawn Public Data) - but I have no clue what data format they contain... obviously, its binary, simple cylindrical projection, based on a 255 x 255 x 255 kms sphere (Vesta), 32 bits per data point. But what data format - int or float? Signed or unsigned? Big or little endian? Where do I get detailed information on the format of these PDF files?

See you in Khyberspace!

Yadgar

[djellison]

Probably better to link to a web-page rather than directly to a 500+,mb .pds file.
http://dawndata.igpp.ucla.edu/tw.jsp?secti...Ms/DLR_HAMO_DTM

Simply opening the file in a text editor reveals.....

CODE

PDS_VERSION_ID                    = PDS3

/* FILE DATA ELEMENTS */

RECORD_TYPE                       = FIXED_LENGTH
RECORD_BYTES                      = 69124
FILE_RECORDS                      = 8644
LABEL_RECORDS                     = 2

/* POINTERS TO DATA OBJECTS */

^IMAGE_HEADER                     = 3
^IMAGE                            = 4

/* DATA OBJECT DEFINITIONS */

OBJECT                            = IMAGE
  INTERCHANGE_FORMAT              = BINARY
  LINES                           = 8641
  LINE_SAMPLES                    = 17281
  SAMPLE_TYPE                     = IEEE_REAL
  SAMPLE_BITS                     = 32
  BANDS                           = 1
  BAND_STORAGE_TYPE               = BAND_SEQUENTIAL
  MINIMUM                         = -21527
  MAXIMUM                         = 19005
END_OBJECT                        = IMAGE

/* MAP OBJECT DEFINITIONS */

OBJECT                            = IMAGE_MAP_PROJECTION
  A_AXIS_RADIUS                   = 255.0
  B_AXIS_RADIUS                   = 255.0
  C_AXIS_RADIUS                   = 255.0
  CENTER_LATITUDE                 = 0.0
  CENTER_LONGITUDE                = 180.0
  COORDINATE_SYSTEM_NAME          = PLANETOCENTRIC
  EASTERNMOST_LONGITUDE           = 359.9999991462263
  LINE_PROJECTION_OFFSET          = 4320.0
  MAP_PROJECTION_TYPE             = SIMPLE_CYLINDRICAL
  MAP_RESOLUTION                  = 48.00000026515721
  MAP_SCALE                       = 0.09272061600000001 <km/pixel>
  MAXIMUM_LATITUDE                = 90.0
  MINIMUM_LATITUDE                = -90.0
  POSITIVE_LONGITUDE_DIRECTION    = EAST
  SAMPLE_PROJECTION_OFFSET        = 8640.0
  WESTERNMOST_LONGITUDE           = 0.0
END_OBJECT                        = IMAGE_MAP_PROJECTION

/* MISCELLANEOUS */

TARGET_NAME                       = VESTA
PRODUCER_INSTITUTION_NAME         = "German Aerospace Center (DLR)"
PRODUCT_CREATION_TIME             = 2013-05-24T13:27:30.000
MISSING_CONSTANT                  = -32768
DESCRIPTION                       = "DTM: Height [m] equals DN. Vertical
                                     reference: Height above
                                     sphere/ellipsoid (as defined by map
                                     axis)."

/* IMAGE HEADER DATA ELEMENTS */

OBJECT                         = IMAGE_HEADER
HEADER_TYPE                   = VICAR2
INTERCHANGE_FORMAT            = ASCII
BYTES                         = 69124
^DESCRIPTION                  = "VICAR2.TXT"
END_OBJECT                     = IMAGE_HEADER
END

That data is enough to open it as a raw file in Photoshop, Gimp or ImageJ etc. and then use it as a displacement map on a mesh.

[Yadgar]

INTERCHANGE_FORMAT = BINARY

O.k., it's binary...

LINES = 8641
LINE_SAMPLES = 17281

...17281 by 8641 sample points...

SAMPLE_BITS = 32

...4 bytes per sample, which would be either standard-precision float or int...

MINIMUM = -21527
MAXIMUM = 19005

Obviously, the sample values range from -21527 to 19005 metres relative to the rotation ellipsoid - which means that they are in fact integer! But why do they use signed int rather than signed short int? And which bit order - big oder small endian?

A_AXIS_RADIUS = 255.0
B_AXIS_RADIUS = 255.0
C_AXIS_RADIUS = 255.0

...the underlying ellipsoid, here a perfect sphere...

MAP_PROJECTION_TYPE = SIMPLE_CYLINDRICAL

...so spacing of points can be calculated from the x and y dimensions of the data array...

SAMPLE_PROJECTION_OFFSET = 8640.0

Is this a value to be added to or subtracted from the sample values?

MISSING_CONSTANT = -32768

Missing data code...

That data is enough to open it as a raw file in Photoshop, Gimp or ImageJ etc. and then use it as a displacement map on a mesh.

When I try to open it, I just get a strange noisy thing which, when zoomed in, appears like vague rastered interference shapes...
perhaps I better should try writing a C++ program which extracts the sample data and stores them as an uncompressed TGA image file!

See you in Khyberspace!

Yadgar

[mcaplinger]

...4 bytes per sample, which would be either standard-precision float or int...
Obviously, the sample values range from -21527 to 19005 metres relative to the rotation ellipsoid - which means that they are in fact integer!

Nope. It says SAMPLE_TYPE = IEEE_REAL, that's a single-precision float.

[Yadgar]

Hi(gh)!

Nope. It says SAMPLE_TYPE = IEEE_REAL, that's a single-precision float.

I started with a small C++ program (using g++ under Linux) to at least get a sense of the data stored in global.pds - but the data I got were far beyond the limits given in the header!

Here is the code:

#include <cstdlib>
#include <fstream>
#include <iostream>

using namespace std;

int main()
{
ifstream Rawdata;
Rawdata.open("global.pds", ios::binary);

if (!Rawdata)
{
cerr << "File cannot be read!\n";
exit(-1);
}

float h;
int i=0;

while (Rawdata.read((char*)&h, sizeof(h)))
{
i++;
if (i > 2585) // skipping the ASCII header
cout << i << "\t" << h << endl;
}
Rawdata.close();
}

and this is an example of what it read from global.pds:

592609 1.08726e-38
592610 1.08726e-38
592611 -1.07807e-38
592612 -1.07807e-38
592613 -1.07807e-38
592614 -1.07807e-38
592615 1.07807e-38
592616 1.07807e-38
592617 -1.06889e-38
592618 -1.06889e-38
592619 1.06889e-38
592620 1.06889e-38
592621 -1.05971e-38
592622 -1.05971e-38
592623 1.05971e-38
592624 1.05971e-38
592625 -1.05052e-38
592626 -1.05052e-38
592627 1.05052e-38
592628 1.05052e-38
592629 -1.04134e-38
592630 -1.04134e-38
592631 1.04134e-38
592632 1.04134e-38

Clueless,

Yadgar

[mcaplinger]

Most likely a byte-ordering problem. PDS files are usually in network order. I'd take Bjorn's advice and not reinvent the wheel.