Modifying Inpho satellite .PRJ files so Digi3D.NET does not request the vertical CRS

January 18, 2016 inpho rpc satellites coordinate reference system crs

Just yesterday we published an entry in which we announced the possibility of loading .PRJ files from Inpho with satellite RPC parameters, but the video had a trick to prevent Digi3D.NET from requesting the coordinate reference system (SRC from now on) vertical. The satellite sensor of Digi3D.NET is a 3D sensor, so it requires us to provide it with three coordinates: X, Y, Z or Longitude, Latitude, Altitude. In addition, Digi3D.NET needs to know the SRC of these coordinates. If the RPC parameters were obtained from any of the formats supported by the extension until yesterday (before adding the possibility of obtaining them from .PRJ files of Inpho), it was assumed that the SRC was the EPSG:4979, that the geographical SRC 3D (meaning that the Z coordinate is ellipsoidal) with name WGS 84. Do not confuse them with the much more famous EPSG:4326 with which it shares name: this other is 2D, and can only be part of a composite SRC, and in the composite SRC we cannot specify an ellipsoidal coordinate Z, it has to be orthometric if or not. When yesterday we implemented the possibility of loading .PRJ files, we made the SRC associated with the satellite sensor no longer always be the EPSG:4979, but be the one indicated in the .PRJ file. The problem is that the SRC that appear in the .PRJ files are 2D and not 3D. Below is a cut out of a .PRJ file with the geographic orientation:

$PROJECT 7.0.0
# generated using Version 7.0.1.49528 (64bit), build #36 of 2015-10-13 09:38
  $PROJECT_NAME : new_project
  $USER_ID : Jose Manuel
  $STARTING_DATE : mar ene 12 12:44:00 2016
  $LAST_CHANGE : Tue Jan 12 13:22:21 2016
  $IMAGE_TYPE : Satellite
  $REFRACT_CORR_DEFAULT : off
  $CURV_CORR_DEFAULT : off
  $COORDINATE_SYSTEM :
     GEOGCS["WGS 84",
         DATUM["WGS_1984",SPHEROID["WGS 84",6378137,298.257223563,AUTHORITY["EPSG",
                     "7030"]],
             AUTHORITY["EPSG","6326"]],
         PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],
         UNIT["degree",0.01745329251994328,AUTHORITY["EPSG","9122"]],
         AUTHORITY["EPSG","4326"]]
  $LINEAR_UNITS_OF_OBJECT : m
  $LINEAR_UNITS_OF_IMAGE : pixel
  $ANGULAR_UNITS : deg
  $REPORT_LOGFILE : C:\Users\Jose Manuel\new_report.log
$END

As you can see, the SRC provided is the EPSG:4326, at first glance you can see that it is 2D, because the SRC that are defined as GEOGCS are 2D, so simple. The same happens with a .PRJ file with coordinates in UTM as you can see below:

$PROJECT 7.0.0
# generated using Version 7.0.1.49528 (64bit), build #36 of 2015-10-13 09:43
  $PROJECT_NAME : new_project
  $USER_ID : Jose Manuel
  $STARTING_DATE : mié nov 18 14:03:18 2015
  $LAST_CHANGE : Tue Dec 15 14:09:15 2015
  $IMAGE_TYPE : Satellite
  $STD_DEV_OBJECT_POINTS : 0.200000
  $STD_DEV_OBJECT_Z_POINTS : 0.400000
  $STD_DEV_IMAGE_POINTS : 0.500000
  $STD_DEV_IMAGE_GC_POINTS : 0.500000
  $SDS_OBJ_GROUP_XY :  -1.000000 -1.000000 -1.000000 -1.000000
  $SDS_OBJ_GROUP_Z :  -1.000000 -1.000000 -1.000000 -1.000000
  $REFRACT_CORR_DEFAULT : off
  $CURV_CORR_DEFAULT : off
  $COORDINATE_SYSTEM :
     PROJCS["WGS 84 / UTM zone 18S",
         GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS 84",6378137,298.257223563,
                     AUTHORITY["EPSG","7030"]],
                 AUTHORITY["EPSG","6326"]],
             PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],
             UNIT["degree",0.01745329251994328,AUTHORITY["EPSG","9122"]],
             AUTHORITY["EPSG","4326"]],
         UNIT["metre",1,AUTHORITY["EPSG","9001"]],
         PROJECTION["Transverse_Mercator"],
         PARAMETER["latitude_of_origin",0],
         PARAMETER["central_meridian",-75],18S
         PARAMETER["scale_factor",0.9996],
         PARAMETER["false_easting",500000],
         PARAMETER["false_northing",10000000],
         AUTHORITY["EPSG","32718"],
         AXIS["Easting",EAST],
         AXIS["Northing",NORTH]]
  $LINEAR_UNITS_OF_OBJECT : m
  $LINEAR_UNITS_OF_IMAGE : pixel
  $ANGULAR_UNITS : deg
  $REPORT_LOGFILE : C:\Users\Jose Manuel\new_report.log
$END

This system is also 2D, because the projected are always 2D. If we try to load a file of these, Digi3D.NET will ask us for the SRC of the vertical component showing the following dialog box: Select vertical CRS and this is going to do every time we load the model. If we want to prevent this from happening, we can modify the WKT strings that appear in the .PRJ files and put one that provides vertical SRC information. To do this we will follow the following steps:

  1. Select the menu option Tools/coordinate reference system...
  2. We select the SRC that interests us.
  3. We press the button Copy to copy the string WKT to the clipboard.
  4. We open the .PRJ file with our favorite text editor and modify the WKT string that appears there by the one we have in the clipboard.

With this we will have achieved that Digi3D.NET does not ask us every time for the vertical SRC of the model.

Also this is fundamental if we want to work with ellipsoidal Z coordinates, in which case we will have to select as the Geographic SRC 3D WGS 84, because as I indicated before, we can not assign an ellipsoidal SRC to a compound SRC.

You can see a video in which I explain all this below:

Back to the blog