[PROJ] (Angular/Linear/Scale) speed in C++ API

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

[PROJ] (Angular/Linear/Scale) speed in C++ API

Martin Desruisseaux-3

Hello

The C++ API defines the following enumeration:

osgeo::proj::common::UnitOfMeasure::Type

With the following values:

UNKNOWN, NONE, ANGULAR, LINEAR, SCALE, TIME, PARAMETRIC

The METRE unit for instance is of type LINEAR, which is fine. But I find the following more surprising:

  • METRE_PER_YEAR declared of type LINEAR
  • ARC_SECOND_PER_YEAR declared of type ANGULAR
  • PPM_PER_YEAR declared of type SCALE

I do not see an API for declaring that above units are rates of change (speed, angular velocity, etc.) rather than classic linear or angular units. Shouldn't the API contain something for that?

    Martin



_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: (Angular/Linear/Scale) speed in C++ API

Even Rouault-2
Martin,

> But I find
> the following more surprising:
>
>   * METRE_PER_YEAR declared of type LINEAR
>   * ARC_SECOND_PER_YEAR declared of type ANGULAR
>   * PPM_PER_YEAR declared of type SCALE
>
> I do not see an API for declaring that above units are rates of change
> (speed, angular velocity, etc.) rather than classic linear or angular
> units. Shouldn't the API contain something for that?

Yes, that's indeed odd. I just followed what EPSG does:

  unit_of_meas_name (String) = metre per second
  unit_of_meas_type (String) = length
  target_uom_code (Integer) = 1026

  unit_of_meas_name (String) = arc-seconds per year
  unit_of_meas_type (String) = angle
  target_uom_code (Integer) = 1035

  unit_of_meas_name (String) = parts per million per year
  unit_of_meas_type (String) = scale
  target_uom_code (Integer) = 1036

As far as I can remember, there's no real functional impact of that arguable choice.
What matters for PROJ is that the factor_b/factor_c ratio is correct so that it
can normalize to the rate units it expects for the Helmert operator, which are,
unsurprisingly, the above ones :-) The only use of the unit type I can think
about now is when exporting to WKT: you need to know if you need to generate
a LENGTHUNIT[] vs ANGLEUNIT[] vs SCALE[] node.
Couldn't find in http://docs.opengeospatial.org/is/18-010r7/18-010r7.html an
example for a time-dependant operation nor more formal requirements, but
https://www.epsg-registry.org/export.htm?wkt=urn:ogc:def:coordinateOperation:EPSG::8070
uses those type of nodes for the units of the rate of changes

Could perhaps be worth a clarification in 18-010r7.
CC'ing Roger in case he has anything to add about that.

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: (Angular/Linear/Scale) speed in C++ API

Martin Desruisseaux-3
Le 28/11/2019 à 00:19, Even Rouault a écrit :

> Couldn't find in
> http://docs.opengeospatial.org/is/18-010r7/18-010r7.html an example
> for a time-dependant operation nor more formal requirements, but
> https://www.epsg-registry.org/export.htm?wkt=urn:ogc:def:coordinateOperation:EPSG::8070 
> uses those type of nodes for the units of the rate of changes
>
Just for information (not a request for change), Units of Measurements
in ISO 19111 are defined by ISO 19103:2015 figure C.4. In addition of
Length, Angle and Scale measures, that standard defines also Speed and
AngularSpeed (and more). I'm not sure why the EPSG database does not use
them.

But anyway this email is for another question. In the C++ API, class
WKTParser provides a guessDialect(string) method. But I do not see a way
to tell WKTParser::createFromWKT(string) that the given string is known
to be a GDAL flavor of WKT 1, or the OGC 01-009 standard WKT 1. Both of
them differ in the interpretation of unit of measurement in PRIMEM and
PARAMETER elements, and it seems to me hazardous to guess the flavor
automatically (I realize that it the case of PRIMEM we may rely on the
prime meridian name, but it is not guaranteed to work and it may not
solve the PARAMETER case). Did I missed something?

     Thanks

         Martin


_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: (Angular/Linear/Scale) speed in C++ API

Even Rouault-2
Martin,

> But anyway this email is for another question. In the C++ API, class
> WKTParser provides a guessDialect(string) method. But I do not see a way
> to tell WKTParser::createFromWKT(string) that the given string is known
> to be a GDAL flavor of WKT 1, or the OGC 01-009 standard WKT 1. Both of
> them differ in the interpretation of unit of measurement in PRIMEM and
> PARAMETER elements, and it seems to me hazardous to guess the flavor
> automatically (I realize that it the case of PRIMEM we may rely on the
> prime meridian name, but it is not guaranteed to work and it may not
> solve the PARAMETER case). Did I missed something?

No, you didn't miss anything. Only the GDAL flavor/interpretation of WKT1 has
been implemented in createFromWKT()

(For readers not familar with the issue discussed, historical considerations
can be found in https://gdal.org/tutorials/wktproblems.html )

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: (Angular/Linear/Scale) speed in C++ API

Martin Desruisseaux-3
Le 02/12/2019 à 19:42, Even Rouault a écrit :

> No, you didn't miss anything. Only the GDAL flavor/interpretation of
> WKT1 has been implemented in createFromWKT()
>
Thanks, I will adjust the API accordingly in Java bindings.

Is OGC 01-009 version of WKT 1 unsupported at formatting time too? If
yes, what is the difference between WKTFormatter::Convention::WKT1_GDAL
and WKTFormatter::Convention::WKT1_ESRI?

     Martin


_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: (Angular/Linear/Scale) speed in C++ API

Even Rouault-2
On lundi 2 décembre 2019 19:51:24 CET Martin Desruisseaux wrote:
> Le 02/12/2019 à 19:42, Even Rouault a écrit :
> > No, you didn't miss anything. Only the GDAL flavor/interpretation of
> > WKT1 has been implemented in createFromWKT()
>
> Thanks, I will adjust the API accordingly in Java bindings.
>
> Is OGC 01-009 version of WKT 1 unsupported at formatting time too?

Yes. But is there really an un-ambiguous interpretation of OGC 01-009... ? I
doubt so: isn't that the reason for WKT2 ? Everyone has understood it as it
could, sometimes "rightly", somes "wrongly" and stick with it.

> If yes, what is the difference between WKTFormatter::Convention::WKT1_GDAL
> and WKTFormatter::Convention::WKT1_ESRI?

A lot... CRS names, datum names, ellipsoid names, projection method names,
parameter names. No AUTHORITY[] or AXIS[] nodes in WKT1_ESRI.
Basically WKT1_ESRI is what you find in shapefile .prj files

PROJ also makes an effort to use the names found in the proj.db under the ESRI
authority when it can match the CRS object with an existing entry.

Example:

$ projinfo EPSG:2225 -o WKT1_GDAL,WKT1_ESRI
WKT1:GDAL string:
PROJCS["NAD83 / California zone 1 (ftUS)",
    GEOGCS["NAD83",
        DATUM["North_American_Datum_1983",
            SPHEROID["GRS 1980",6378137,298.257222101,
                AUTHORITY["EPSG","7019"]],
            TOWGS84[0,0,0,0,0,0,0],
            AUTHORITY["EPSG","6269"]],
        PRIMEM["Greenwich",0,
            AUTHORITY["EPSG","8901"]],
        UNIT["degree",0.0174532925199433,
            AUTHORITY["EPSG","9122"]],
        AUTHORITY["EPSG","4269"]],
    PROJECTION["Lambert_Conformal_Conic_2SP"],
    PARAMETER["latitude_of_origin",39.3333333333333],
    PARAMETER["central_meridian",-122],
    PARAMETER["standard_parallel_1",41.6666666666667],
    PARAMETER["standard_parallel_2",40],
    PARAMETER["false_easting",6561666.667],
    PARAMETER["false_northing",1640416.667],
    UNIT["US survey foot",0.304800609601219,
        AUTHORITY["EPSG","9003"]],
    AXIS["Easting",EAST],
    AXIS["Northing",NORTH],
    AUTHORITY["EPSG","2225"]]


WKT1:ESRI string:
PROJCS["NAD_1983_StatePlane_California_I_FIPS_0401_Feet",GEOGCS["GCS_North_American_1983",DATUM["D_North_American_1983",SPHEROID["GRS_1980",
6378137.0,298.257222101]],PRIMEM["Greenwich",0.0],UNIT["Degree",
0.0174532925199433]],PROJECTION["Lambert_Conformal_Conic"],PARAMETER["False_Easting",
6561666.667],PARAMETER["False_Northing",
1640416.667],PARAMETER["Central_Meridian",-122.0],PARAMETER["Standard_Parallel_1",
41.6666666666667],PARAMETER["Standard_Parallel_2",
40.0],PARAMETER["Latitude_Of_Origin",39.3333333333333],UNIT["US survey foot",
0.304800609601219]]


I selfishly implemented "only" those 2 variants to accommodate GDAL needs.

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: (Angular/Linear/Scale) speed in C++ API

Martin Desruisseaux-3
Le 02/12/2019 à 20:06, Even Rouault a écrit :

> Yes. But is there really an un-ambiguous interpretation of OGC
> 01-009... ? I doubt so: isn't that the reason for WKT2 ?
>
I think it is mostly (not completely) unambiguous. At least the units of
measurements of PRIMEM and PARAMETER elements were clearly defined [1].
Some confusion that I saw in the past was caused by the fact that GEOGCS
(for GeographicCRS) and GEOCCS (for GeocentricCRS) keywords are too
similar (they differ only by a "G" versus "C" letter). The difference is
so easy to miss that a past GDAL/PROJ maintainer concluded that OGC
01-009 was self-contradicting, and thus went away with his
interpretation in GDAL. But it was an (understandable) misreading of the
specification rather than a specification inconsistency.

OGC 01-009 was ambiguous in some aspects, for example the projection
parameter names were not defined except for a short list of map
projections, but units of measurements was not an OGC 01-009 ambiguity
(it was an OGC 99-049 ambiguity however - I think this is the origin of
the problem). But the reality was that no matter what OGC 01-009 said,
the software implementations were heterogeneous regarding their
compliance to that specification. Because we had no way to distinguish
whether a WKT 1 string is compliant with OGC O1-009 or not, we had to
create new keywords for making clear that a WKT is using the OGC 01-009
rules for units of measurements. Other reasons for creating WKT 2 were
because WKT 1 was based on a conceptual model that predated ISO 19111,
for erasing the use of WGS84 as an universal hub, and because of WKT 1
ambiguities other than units of measurements.


>> If yes, what is the difference between
>> WKTFormatter::Convention::WKT1_GDAL and
>> WKTFormatter::Convention::WKT1_ESRI?
>>
> A lot... CRS names, datum names, ellipsoid names, projection method
> names, parameter names. No AUTHORITY[] or AXIS[] nodes in WKT1_ESRI.
> Basically WKT1_ESRI is what you find in shapefile .prj files
>
Ah okay, the differences are in the naming and in the presence of
AUTHORITY/AXIS elements. Thanks, I will update documentation. Thanks
also for the example.

     Martin

[1] http://www.geoapi.org/3.0/javadoc/org/opengis/referencing/doc-files/WKT.html#PRIMEM - this is copied verbatim from OGC 01-009.

_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj