Temporal CRS Unit Conversion Factor Unhandled

[snowman2]

Example of problem

projinfo  'TIMECRS[“GPS milliseconds”,TDATUM[“GPS time origin”,TIMEORIGIN[1980-01-01T00:00:00.0Z]],CS[TemporalCount,1],AXIS["(T)“,future,TIMEUNIT[”millisecond (ms)",0.001]]]'
input string: parsing of user string failed: unhandled axis direction: 0.001

Problem description

WKT string from example 2: http://docs.opengeospatial.org/is/18-010r7/18-010r7.html#105

Expected Output

No error.

Environment Information

• PROJ version - latest master
• Operation System Information - Ubuntu 18

Installation method

• From source

[rouault]

Actually, this is more a bug of the example than PROJ.

The examples in the WKT standard tend to use Unicode printing open quote (“) and Unicode printing closing quote (”), but this isn't even allowed by the standard. Probably an artifact of the standard being written in a text editor that does the substitution for ASCII double-quote automatically. So the PROJ parser nominally supports ASCII double quote, and as a convenience a correct balancing of Unicode printing open quote (“) and Unicode printing closing quote (”), but in that example the AXIS name starts with ASCII double quote, which is terminated after the (ms) of TIMEUNIT.

For me, this is a wont fix situation

[rouault]

Note: I've raised the issue to the OGC CRS WG mailing list

[RogerLott]

I agree, and that was certainly the intention, in both 2015 and 2019 versions. As editor of OGC 18-010r7 I will look at fixing the source Word document. I guess there could be similar problem with other characters that appear in multiple Unicode planes indistinuishable to humans reading a text document. Any easy way of checking for this in a text document?

But in the comment above @Roualt said

For me, this is a wont fix situation
What did you mean by that?

[rouault]

Any easy way of checking for this in a text document?

With really a text (.txt) document, that is not a Word one, yes, with Unix utilities it is easy:

$ echo 'TIMECRS[“GPS milliseconds”,TDATUM[“GPS time origin”,TIMEORIGIN[1980-01-01T00:00:00.0Z]],CS[TemporalCount,1],AXIS["(T)“,future,TIMEUNIT[”millisecond (ms)",0.001]]]' > out.txt

$ file out.txt
out.txt: UTF-8 Unicode text

vs

$ echo 'TIMECRS["GPS milliseconds",TDATUM["GPS time origin",TIMEORIGIN[1980-01-01T00:00:00.0Z]],CS[TemporalCount,1],AXIS["(T)",future,TIMEUNIT["millisecond (ms)",0.001]]]' > out.txt

$ file out.txt
out.txt: ASCII text

For me, this is a wont fix situation
What did you mean by that?

I just mean that I don't think there is anything to change in PROJ regarding this. The issue is with the WKT provided as input, not with the software implementation

[desruisseaux]

I think Even means that PROJ current behaviour should not be modified (accept matching quotes, but report mixing of ASCII quotes with Unicode quotes as an error). Apache SIS has the same policy.

Alternatively, the examples could also be copied in plain text files, one file per WKT, and committed on an OGC Github.

[desruisseaux]

For information, examples from ISO 19162:2015 are available as GeoAPI tests executable by PROJ using the JNI bindings (I did not had the time to upgrade to ISO 19162:2019 yet). I have just executed the tests. Many of them pass, the following ones may need investigation:

• testTemporal() (from OGC 12-063r5 §14.4): PROJ said "Missing EDATUM / ENGINEERINGDATUM node"
• testCompoundWithTime() (from OGC 12-063r5 §16.2 example 3): PROJ said "unexpected TIMEUNIT"
• testDerivedEngineeringFromGeodetic() (from OGC 12-063r5 §15.5.2 example 2): PROJ said "Missing EDATUM / ENGINEERINGDATUM node"
• testDerivedEngineeringFromProjected() (from OGC 12-063r5 §15.5.2 example 1): PROJ said "Missing EDATUM / ENGINEERINGDATUM node"
• testProjectedWithImplicitParameterUnits() (from OGC 12-063r5 §9.5 example 3): PROJ said "Parsing error : syntax error, unexpected PRIMEM, expecting ID"

[rouault]

• testTemporal() and testCompoundWithTime() warnings addressed by WKT parser: do not raise warning when parsing a WKT2:2015 TIMECRS whose TIMEUNIT is at the CS level, and not inside #2276
• testDerivedEngineeringFromGeodetic() and testDerivedEngineeringFromProjected(): those constructs are not supported by PROJ. This is the remark of WKT:2019 "Subclause 14.6, derived engineering CRS (ISO 19162:2015, 15.5): This was incorrectly described in 19162:2015. The type of base CRS as either projected or geographic or engineering allowed in 19162:2015 was wrong. It has been entirely remodelled in two distinct parts: a derived engineering CRS is to have a base CRS of type engineering (base CRS of projected or geodetic no longer permitted); derived projected CRS is to have a base CRS of type projected and hence a geodetic datum."
• testProjectedWithImplicitParameterUnits(): this WKT construct is not strictly compliant with the WKT:2015 BNF. The PRIMEM shoud be before ANGLEUNIT, and another issue is the ID of the CONVERSION is just after the name, instead of being at the end. The C++ WKTParser is in strict mode by default (that it it does a pre-check using a parser closely aligned with the BNF, whereas the ingestion of the WKT nodes to C++ objects is done in a laxer way). This can be changed by calling the setStrict(false) method. The C API uses non-strict mode.

[RogerLott]

The problem with non-ASCII characters in OGC 18-010r7 is in the html document at http://docs.opengeospatial.org/is/18-010r7/18-010r7.html. The Word version at https://portal.opengeospatial.org/files/18-010r7/docx and the pdf at https://portal.opengeospatial.org/files/18-010r7 do not appear to have the problem. It appears to have been caused in the Pandoc conversion. The html document will be corrected - I don't have a timeframe.

[RogerLott]

Hopefully the html document now fixed.

I suggest that this issue could now be closed.