MAPCSLIBRARY Errors and Omissions

[Pointdump]

This is an attempt to list errors and omissions in MAPCSLIBRARY.
The Tern Island 1961 Datum, Code: Tern61, shows an EPSG Code of 6707. It should be >>>EPSG:4707<<<. The EPSG site erroneously also lists the Tern Island 1961 Datum as >>>EPSG:6707-datum<<<, so it's not completely Autodesk's fault. EPSG:6707 should be >>>RDN2008 / UTM zone 32N (N-E)<<<.
To be honest, I don't understand the distinction between a Datum and a GCS(Geographic Coordinate System) in MAPCSLIBRARY. Feel free to school me.

[cputnam]

Hi Dave,
Good idea for a forum post.

EPSG codes are not globally unique across different categories of items.  A Coordinate Reference System can have the same code number as a Datum.
Generally, EPSG.org is the authoritative source, and a search for 6709 returns both results:

There is a pending ticket to add the Italian RDN2008 UTM zones and updated transformations.   

[cputnam]

Hi Dave,

For historical reasons, Datum in the CS Dictionaries is used a bit like a GCS in the modern EPSG definitions when determining transformations.   For example, transformations are registered between two Datums instead of two GCSs.  So I understand the confusion.   
GCS is a geographic CRS (Lat/Lon) in the CS Dictionaries.

In this specific case:

Tern61 is a Datum and the corresponding EPSG code 6707 matches the Tern Island 1961 datum.
EPSG 6707 also matches Italian RDN 2008 UTM Zone 32N, because EPSG codes are only unique within a given category of item.  (The codes aren't globally unique)
Tern61.LL is the Geographic Coordinate system with EPSG Code 4707 corresponding to Tern Island 1961.

Apologies for the long time to reply, I've only recently become aware of this thread.  Thanks for capturing these items.

[cputnam]

Hi Dave,

There are two different conventions in use for 7 parameter transformations: Position Vector and Coordinate Frame.  The difference between them is that rotation signs are flipped.
The seven parameter transformation method should expect the Position Vector form, so it looks like you're correct.  I've logged a problem report.

[cputnam]

Hi Dave,

There is a ticket to add the remaining RDN2008 UTM zones and improve the transformations.

[cputnam]

Logged a ticket for this request to add ESRI:102766 for Guam.

[cputnam]

Logged a ticket to add EPSG:29700, "Tananarive (Paris) / Laborde Grid" and
EPSG:29702, "Tananarive (Paris) / Laborde Grid approximation"

[cputnam]

Logged a ticket to add EPSG:7415 Amersfoort / RD New + NAP Height

[cputnam]

Logged a ticket to address TMBLI-B.RSOBorneo.m definition as oblique Mercator (Variant B)

[cputnam]

There is an open ticket for adding the new US / North American reference frames and corresponding CRS (SPCS2022,etc.)

[cputnam]

Hi Dave,

Point well taken that NSRS is not a Datum and that the current naming is a source of confusion.   Agree that NAD83(2011) and NAD83(2007) would be better.
The existing names need to be maintained for compatibility with previous versions, but I've logged a ticket to consider ways to improve the naming.

[cputnam]

Hi Dave,

We have considered this, but I've added a ticket to support Earth Centered Cartesian Coordinates.

Most products could not use ECEF for their model coordinate reference system, but being able to display and convert coordinates would be useful.

[cputnam]

Agree with the point about naming.  Could you explain more about using EPSG codes for the NSRS11 coordinate reference systems?  I believe these should be correct.

[cputnam]

Hi Dave,

EPSG 6350 NAD83(2011)/Conus Albers was added as NSRS11.US48.

[Pointdump]

Hi Chris,
Thanks for your posts. Greatly appreciated.
"EPSG codes are not globally unique across different categories of items."
Sadly, they should be.
"Datum in the CS Dictionaries is used a bit like a GCS in the modern EPSG definitions"
I think a Datum is basically just a name, and a GCS has a realization. I might be alone in that view.
"...NSRS is not a Datum...NAD83(2011) and NAD83(2007) would be better."
I kinda understand why Autodesk uses names like "NSRS11.AL-E", because a parenthesis isn't allowed in the Code Name. It should be.
"being able to display and convert [ECEF]coordinates would be useful."
Would be a nice addition to MAPCSLIBRARY.
"EPSG 6350 NAD83(2011)/Conus Albers was added as NSRS11.US48."
Thank you. I've seen this one come up many times on the ReCap Forum.
Dave

[cputnam]

Hi Dave,

No problem.  I'll continue to work through the rest of these over time to make sure they are all recorded.

Chris

[Pointdump]

The 7-Parameter Geodetic Transformation PDOSurvey93b_to_WGS84 is not the same as >>>EPSG:1439 PSD93 to WGS 84(1)<<<. Signs are reversed.

Edit: From >>>This Civil 3D Forum Thread<<<.

Further Edit: Bing Live Maps Extents not using the EPSG:3440 definition:

WGS84 bounds:
51.99 16.59
59.91 26.58

[cputnam]

Re: PDOSurvey93b_to_WGS84

In general, the EPSG 7 parameter transformations have 2 forms: position-vector and coordinate frame.  The difference between the two is direction of rotation.  It looks there were a few changes on this - there is an "obsolete" PDOSurvey93a transformation with matching rotation sign that can be used via "PSD93a.UTM-39N" and "PSD93a.UTM-40N" CRS.
I've logged a ticket for this.