does default crs WGS84(DD) have an EPSG code?

I was wondering: does the default SNAP CRS WGS84(DD) have an EPSG code?
If so: which one?

Can’t find the EPSG code in the dim files?

<Coordinate_Reference_System>

GEOGCS[“WGS84(DD)”,
DATUM[“WGS84”,
SPHEROID[“WGS84”, 6378137.0, 298.257223563]],
PRIMEM[“Greenwich”, 0.0],
UNIT[“degree”, 0.017453292519943295],
AXIS[“Geodetic longitude”, EAST],
AXIS[“Geodetic latitude”, NORTH]]

</Coordinate_Reference_System>

the EPSG code of WGS84(DD) is 4326: https://epsg.io/4326

On this page you find the corresponding WKT

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.0174532925199433,
        AUTHORITY["EPSG","9122"]],
    AUTHORITY["EPSG","4326"]]

Yes THANK YOU, found both in SNAP.

See below 2 listings from SNAP.
These values are the same, which gave me confidence.

HOWEVER, the values in your answer above are slightly different… ??? iex?

What SNAP puts in the .DIM file when using default LatLon on WGS84 (without EPSG number)
<Coordinate_Reference_System>

GEOGCS[“WGS84(DD)”,
DATUM[“WGS84”,
SPHEROID[“WGS84”, 6378137.0, 298.257223563]],
PRIMEM[“Greenwich”, 0.0],
UNIT[“degree”, 0.017453292519943295],
AXIS[“Geodetic longitude”, EAST],
AXIS[“Geodetic latitude”, NORTH]]

</Coordinate_Reference_System>

What SNAP puts in the .DIM file when using LatLon on WGS84 (EPSG 4326)
<Coordinate_Reference_System>

GEOGCS[“WGS 84”,
DATUM[“World Geodetic System 1984”,
SPHEROID[“WGS 84”, 6378137.0, 298.257223563, AUTHORITY[“EPSG”,“7030”]],
AUTHORITY[“EPSG”,“6326”]],
PRIMEM[“Greenwich”, 0.0, AUTHORITY[“EPSG”,“8901”]],
UNIT[“degree”, 0.017453292519943295],
AXIS[“Geodetic longitude”, EAST],
AXIS[“Geodetic latitude”, NORTH],
AUTHORITY[“EPSG”,“4326”]]

</Coordinate_Reference_System>

which operator are you using?

Dear Andreas,

Running Radar Range Doppler Terrain Correction in a script/graph.

The 2 CRS’s in SNAP look exactly the same (!)
But the site you mentioned gave a slightly different value for Pixelspacing in degrees namely UNIT[“degree”,0.0174532925199433,
against UNIT[“degree”, 0.017453292519943295] in SNAP’s "WGS 84” and
UNIT[“degree”, 0.017453292519943295] in SNAP’s “WGS84(DD)”

I know nitty-gritty.

Anyways we chose for SNAP’s "WGS 84” in our script. Just to be sure to have an EPSG in our output…
(We’re supposed to run the thing over entire Indonesia… / All output will need to fit together…)

Thanks, Petra.

so SNAP has an even higher accuracy regarding the decimal places. If you project all data to WGS84, you can go sure it aligns well with other data at the national scale.

As an alternative, you can use UTM zones for all your data to have an ever higher local-scale accuracy.

Yes, that’s right (slightly better resolution), but it is not entirely the same then…

We need to process an area over multiple UTM zones and we would ideally like to use a single file with parameters (xml) to process the stuff. Do you agree? Or would you strongly recommend UTM zones?

I see no problem with combining WGS84 data either, despite of these slight differences.

What is your general concern about it?
Your spatial resolution is probably several meters so these decimals won’t makes a difference.

The UNIT attribute does not describe the pixel-spacing, it just describes the unit of your output CRS.
The value 0.0174532925199433 is just the conversion factor between radian and degree (PI/180). It is a bit strange that it is shown in WKT.
The pixel spacing is defined by your input or by the parameter you specify.

You should use UTM only if your area lies completely within one zone, or just overlaps a bit with the next one. The distortion can be significant when applying reprojection parameters of one UTM zone on an area which is in another zone.

1 Like