Automatic: Many datasets can figure out and construct their CRS automatically from the data files.

Predefined: Some common coordinate reference systems are predefined as static properties of the Crs class (for example Wgs84LongLat), or available via the static Wgs84Utm method. In Carmenta Studio, all these are available in the drop-down list when you choose a CRS for a view or a dataset.

Manually: Construct a Projection and a GeodeticDatum first, and use them as arguments to one of the Crs constructors. Or in Carmenta Studio, assign them as properties of a new Crs instance.

Authority and code: You can construct a Crs from the name of an authority like EPSG and a unique code that the authority has assigned to that CRS. See CRS Authorities for more background. From an application, you can call the static FromAuthorityAndCode method. In Carmenta Studio, you would make a new Crs instance as above, but only specify the Authority and AuthorityCode. Sometimes, you will have to let DatumShiftChoice be Lenient.

Well-Known Text: An application can use the FromWellKnownText method to construct a CRS from Well-Known Text syntax. (Carmenta Studio does not support this syntax.)

Area of use: The FromArea method constructs a reasonable CRS for a given area. This method is mainly intended to simplify calculations in a ScriptOperator or a custom operator.

A vehicle is not always on sea level altitude. If an airplane flies at an altitude of 10 km, the distance it covers is 0.16 percent longer than the distance along the ellipsoid surface.

If the geodetic datum is old (let us say, measured before the 1960s), its graticule will have significant irregularities due to measuring errors. For example, if your Crs uses the British datum OSGB36, the result from Length may be wrong by 5 - 10 meters. (It would help to transform the coordinates to WGS84 first, but only if you use a GridFileDatumShift to remove the irregularities; an ordinary HelmertDatumShift cannot remove them.)

Continental drift may be significant. For example, the European geodetic datum ETRS89 was defined to be equal to WGS84 on 1 January, 1989. But ETRS89 is attached to the European continent, and follows it on its journey towards northeast (about 2.5 cm per year), whereas WGS84 does not. Coordinates in ETRS89 are often said to be in WGS84, in a loose sense of the word. The same is true for the North American datum NAD83, which is attached to the North American continent. So, a Carmenta Engine user would normally identify both ETRS89 and NAD83 with WGS84, which is quite reasonable. Nevertheless, if Wgs84LongLat.Length gets one point which is really in ETRS89, and another point which is really in NAD83, it is clear that the accuracy will not be 1 millimeter. (If such accuracy is needed, you must distinguish carefully between ETRS89 and WGS84. There is a formula that, given a date, gives the best 7-parameter transform between ETRS89 and WGS84 for that date, thereby modelling the continental drift since 1989).

Automatic: Many datasets can figure out and construct their CRS automatically from the data files.

Predefined: Some common coordinate reference systems are predefined as static properties of the Crs class (for example wgs84LongLat), or available via the static wgs84Utm method. In Carmenta Studio, all these are available in the drop-down list when you choose a CRS for a view or a dataset.

Manually: Construct a Projection and a GeodeticDatum first, and use them as arguments to one of the Crs constructors. Or in Carmenta Studio, assign them as properties of a new Crs instance.

Authority and code: You can construct a Crs from the name of an authority like EPSG and a unique code that the authority has assigned to that CRS. See CRS Authorities for more background. From an application, you can call the static fromAuthorityAndCode method. In Carmenta Studio, you would make a new Crs instance as above, but only specify the authority and authorityCode. Sometimes, you will have to let datumShiftChoice be Lenient.

Well-Known Text: An application can use the fromWellKnownText method to construct a CRS from Well-Known Text syntax. (Carmenta Studio does not support this syntax.)

Area of use: The fromArea method constructs a reasonable CRS for a given area. This method is mainly intended to simplify calculations in a ScriptOperator or a custom operator.

A vehicle is not always on sea level altitude. If an airplane flies at an altitude of 10 km, the distance it covers is 0.16 percent longer than the distance along the ellipsoid surface.

If the geodetic datum is old (let us say, measured before the 1960s), its graticule will have significant irregularities due to measuring errors. For example, if your Crs uses the British datum OSGB36, the result from length may be wrong by 5 - 10 meters. (It would help to transform the coordinates to WGS84 first, but only if you use a GridFileDatumShift to remove the irregularities; an ordinary HelmertDatumShift cannot remove them.)

Continental drift may be significant. For example, the European geodetic datum ETRS89 was defined to be equal to WGS84 on 1 January, 1989. But ETRS89 is attached to the European continent, and follows it on its journey towards northeast (about 2.5 cm per year), whereas WGS84 does not. Coordinates in ETRS89 are often said to be in WGS84, in a loose sense of the word. The same is true for the North American datum NAD83, which is attached to the North American continent. So, a Carmenta Engine user would normally identify both ETRS89 and NAD83 with WGS84, which is quite reasonable. Nevertheless, if Wgs84LongLat.length gets one point which is really in ETRS89, and another point which is really in NAD83, it is clear that the accuracy will not be 1 millimeter. (If such accuracy is needed, you must distinguish carefully between ETRS89 and WGS84. There is a formula that, given a date, gives the best 7-parameter transform between ETRS89 and WGS84 for that date, thereby modelling the continental drift since 1989).

Automatic: Many datasets can figure out and construct their CRS automatically from the data files.

Predefined: Some common coordinate reference systems are predefined as static properties of the Crs class (for example wgs84LongLat), or available via the static wgs84Utm method. In Carmenta Studio, all these are available in the drop-down list when you choose a CRS for a view or a dataset.

Manually: Construct a Projection and a GeodeticDatum first, and use them as arguments to one of the Crs constructors. Or in Carmenta Studio, assign them as properties of a new Crs instance.

Authority and code: You can construct a Crs from the name of an authority like EPSG and a unique code that the authority has assigned to that CRS. See CRS Authorities for more background. From an application, you can call the static fromAuthorityAndCode method. In Carmenta Studio, you would make a new Crs instance as above, but only specify the authority and authorityCode. Sometimes, you will have to let datumShiftChoice be Lenient.

Well-Known Text: An application can use the fromWellKnownText method to construct a CRS from Well-Known Text syntax. (Carmenta Studio does not support this syntax.)

Area of use: The fromArea method constructs a reasonable CRS for a given area. This method is mainly intended to simplify calculations in a ScriptOperator or a custom operator.

A vehicle is not always on sea level altitude. If an airplane flies at an altitude of 10 km, the distance it covers is 0.16 percent longer than the distance along the ellipsoid surface.

If the geodetic datum is old (let us say, measured before the 1960s), its graticule will have significant irregularities due to measuring errors. For example, if your Crs uses the British datum OSGB36, the result from length may be wrong by 5 - 10 meters. (It would help to transform the coordinates to WGS84 first, but only if you use a GridFileDatumShift to remove the irregularities; an ordinary HelmertDatumShift cannot remove them.)

Continental drift may be significant. For example, the European geodetic datum ETRS89 was defined to be equal to WGS84 on 1 January, 1989. But ETRS89 is attached to the European continent, and follows it on its journey towards northeast (about 2.5 cm per year), whereas WGS84 does not. Coordinates in ETRS89 are often said to be in WGS84, in a loose sense of the word. The same is true for the North American datum NAD83, which is attached to the North American continent. So, a Carmenta Engine user would normally identify both ETRS89 and NAD83 with WGS84, which is quite reasonable. Nevertheless, if Wgs84LongLat.length gets one point which is really in ETRS89, and another point which is really in NAD83, it is clear that the accuracy will not be 1 millimeter. (If such accuracy is needed, you must distinguish carefully between ETRS89 and WGS84. There is a formula that, given a date, gives the best 7-parameter transform between ETRS89 and WGS84 for that date, thereby modelling the continental drift since 1989).

Automatic: Many datasets can figure out and construct their CRS automatically from the data files.

Predefined: Some common coordinate reference systems are predefined as static properties of the Crs class (for example wgs84LongLat), or available via the static wgs84Utm method. In Carmenta Studio, all these are available in the drop-down list when you choose a CRS for a view or a dataset.

Manually: Construct a Projection and a GeodeticDatum first, and use them as arguments to one of the Crs constructors. Or in Carmenta Studio, assign them as properties of a new Crs instance.

Authority and code: You can construct a Crs from the name of an authority like EPSG and a unique code that the authority has assigned to that CRS. See CRS Authorities for more background. From an application, you can call the static fromAuthorityAndCode method. In Carmenta Studio, you would make a new Crs instance as above, but only specify the authority and authorityCode. Sometimes, you will have to let datumShiftChoice be Lenient.

Well-Known Text: An application can use the fromWellKnownText method to construct a CRS from Well-Known Text syntax. (Carmenta Studio does not support this syntax.)

Area of use: The fromArea method constructs a reasonable CRS for a given area. This method is mainly intended to simplify calculations in a ScriptOperator or a custom operator.

A vehicle is not always on sea level altitude. If an airplane flies at an altitude of 10 km, the distance it covers is 0.16 percent longer than the distance along the ellipsoid surface.

If the geodetic datum is old (let us say, measured before the 1960s), its graticule will have significant irregularities due to measuring errors. For example, if your Crs uses the British datum OSGB36, the result from length may be wrong by 5 - 10 meters. (It would help to transform the coordinates to WGS84 first, but only if you use a GridFileDatumShift to remove the irregularities; an ordinary HelmertDatumShift cannot remove them.)

Continental drift may be significant. For example, the European geodetic datum ETRS89 was defined to be equal to WGS84 on 1 January, 1989. But ETRS89 is attached to the European continent, and follows it on its journey towards northeast (about 2.5 cm per year), whereas WGS84 does not. Coordinates in ETRS89 are often said to be in WGS84, in a loose sense of the word. The same is true for the North American datum NAD83, which is attached to the North American continent. So, a Carmenta Engine user would normally identify both ETRS89 and NAD83 with WGS84, which is quite reasonable. Nevertheless, if Wgs84LongLat.length gets one point which is really in ETRS89, and another point which is really in NAD83, it is clear that the accuracy will not be 1 millimeter. (If such accuracy is needed, you must distinguish carefully between ETRS89 and WGS84. There is a formula that, given a date, gives the best 7-parameter transform between ETRS89 and WGS84 for that date, thereby modelling the continental drift since 1989).