ETRS89 - WGS94 Export Slower than NAD83 - WGS84

[digitalaviator]

Hi Mike,

I have some scripts where I have the same data types (i.e. 1 deg lat x 1 deg lon) that get assembled from 8x8 quads (i.e. rows a-h and columns 1-8)...

On processing my NAD83 to WGS84 based data (same data provider) the export takes only 24 hours or so for an entire state say the size of Arizona...

On processing my ETRS89 to WGS84 based data (same data provider) the export takes up to 7 days for a country the size of France/Germany...

Should I be seeing such a huge time difference between a NAD83 to WGS84 conversion and the ETRS89 to WGS84 conversion of data or is this a likely bug that is slowing conversion to a crawl for the ETRS89 data?

Cheers,
Digital Aviator...

[global_mapper]

Dean,

The datums really shouldn't make any significant difference in speed, but France and Germany are quite a bit larger than Arizona, so could that be the source of the difference? Another possibility is the input data format. That can have a big impact on speed.

Let me know if I can be of further assistance.

Thanks,

Mike
Global Mapper Support
support@globalmapper.com

[digitalaviator]

Hi Mike,

Both formats are BIL...

A better example is probably California or Texas (NAD83), I had those done in about 3 days or less each, whereas France and Germany (ETRS89) are taking over 7 days to render...

I seem to remember a bug that was fixed in one version during GM10 that addressed a similar issue, but not sure if this one is related...

Cheers,

[global_mapper]

Dean,

Are the resolutions of the exports comparable? How much data is being created by each export?

Thanks,

Mike
Global Mapper Support
support@globalmapper.com

[digitalaviator]

Yes, they're both exactly the same, similar lattitudes N35-45...

5m post spacing, everything in them is exactly the same except for the projection.

The largest outputted source files are 2.03GB and that's pretty much standard across the board. (i.e. for a complete 1 deg x 1 deg tile)...

Here's the sample output master I use for final rendering:

FILENAME=H:\pathto\directory\n46e002.tif
DESCRIPTION=n46e002.tif
UPPER LEFT X=1.0000005409
UPPER LEFT Y=46.9999994582
LOWER RIGHT X=2.0000138621
LOWER RIGHT Y=45.9999861370
WEST LONGITUDE=1° 00' 0.0019" E
NORTH LATITUDE=46° 59' 59.9980" N
EAST LONGITUDE=2° 00' 0.0499" E
SOUTH LATITUDE=45° 59' 59.9501" N
PROJ_DESC=Geographic (Latitude/Longitude) / WGS84 / arc degrees
PROJ_DATUM=WGS84
PROJ_UNITS=arc degrees
COVERED AREA=3287 sq mi
NUM COLUMNS=23394
NUM ROWS=23394
NUM_BANDS=1
PIXEL WIDTH=0.0000427 arc degrees
PIXEL HEIGHT=0.0000427 arc degrees
MIN ELEVATION=70.515 meters
MAX ELEVATION=699.054 meters
ELEVATION UNITS=meters
PHOTOMETRIC=Greyscale (Min is Black)
BIT_DEPTH=32
ROWS_PER_STRIP=1
COMPRESSION=None
PIXEL_SCALE=( 4.27484e-005, 4.27484e-005, 1 )
TIEPOINTS=( 0.00, 0.00, 0.00 ) --> ( 1.0000005409, 46.9999994582, 0.0000000000 )
MODEL_TYPE=Geographic lat-long system
RASTER_TYPE=Pixel is Point
VERT_DATUM=Unknown Datum Code: 0

U.S. Source Metadata:

Spatial_Data_Organization_Information:
  Direct_Spatial_Reference_Method: Raster
  Raster_Object_Information:
    Raster_Object_Type: Grid Cell
    Row_Count: 3001
    Column_Count: 3001
Spatial_Reference_Information:
  Horizontal_Coordinate_System_Definition:
    Geographic:
      Latitude_Resolution: 0.0000416667
      Longitude_Resolution: 0.0000416667
      Geographic_Coordinate_Units: Decimal degrees
    Geodetic_Model:
      Horizontal_Datum_Name: NAD83
      Ellipsoid_Name: GRS80
      Semi-major_Axis: 6378137.0
      Denominator_of_Flattening_Ratio: 298.257222101
  Vertical_Coordinate_System_Definition:
    Altitude_System_Definition:
      Altitude_Datum_Name: NAVD88(Geoid99)
      Altitude_Resolution: 0.01 m
      Altitude_Distance_Units: meter
      Altitude_Encoding_Method: Implicit coordinate
Entity_and_Attribute_Information:
  Detailed_Description:
    Entity_Type:
      Entity_Type_Label: 5 meter posting grid cell
      Entity_Type_Definition: The DEM is a 32 bit IEEE floating point value organized in a one-channel Band Interleaved by Line file (BIL) on a 7.5-minute by 7.5-minute geographic (lat/long) grid. The origin of the post is center center.

Europe Source MetaData:

Spatial_Data_Organization_Information:
  Direct_Spatial_Reference_Method: Raster
  Raster_Object_Information:
    Raster_Object_Type: Grid Cell
    Row_Count: 3001
    Column_Count: 3001
Spatial_Reference_Information:
  Horizontal_Coordinate_System_Definition:
    Geographic:
      Latitude_Resolution: 0.0000416667
      Longitude_Resolution: 0.0000416667
      Geographic_Coordinate_Units: Decimal degrees
    Geodetic_Model:
      Horizontal_Datum_Name: ETRS89
      Ellipsoid_Name: GRS80
      Semi-major_Axis: 6378137
      Denominator_of_Flattening_Ratio: 298.257
  Vertical_Coordinate_System_Definition:
    Altitude_System_Definition:
      Altitude_Datum_Name: EVRS2000
      Altitude_Resolution: 0.01 m
      Altitude_Distance_Units: meter
      Altitude_Encoding_Method: Implicit coordinate
Entity_and_Attribute_Information:
  Detailed_Description:
    Entity_Type:
      Entity_Type_Label: 5 meter posting grid cell
      Entity_Type_Definition: The DEM is a 32 bit IEEE floating point value organized in a one-channel Band Interleaved by Line file (BIL) on a 7.5-minute by 7.5-minute geographic (lat/long) grid. The origin of the post is center center.

[global_mapper]

Dean,

I can't see anything that would cause the Europe data to be much slower, other than of course the data being larger so there is just more data to process. I would expect a linear increase in time to process a larger data area though. I could see a performance difference if for the US the datum was WGS84 for both input and output and you used different datums and it was ETRS89->WGS84 in Europe as the datum conversion code could be skipped altogether and it could be a bit faster.

One note, the NAD83 and ETRS89 datums are basically identical to WGS84 (to the sub-mm level in most cases) so you can likely do without the datum conversion if you want with no noticeable difference, especially at a 5m post spacing.

Thanks,

Mike
Global Mapper Support
support@globalmapper.com

[digitalaviator]

Thanks Mike,

I'll run some benchmark tests and get back to you on this with the results...

Cheers,
Dean.