[#GEOTK-23] PropertyAuthorityFactory incorrectly uses CRS name as its code - Geotoolkit JIRA

Details

Type: Bug
Status: Closed
Priority: Major
Resolution: Fixed
Affects Version/s: 3.00, 3.01
Fix Version/s: 3.02
Component/s: Referencing
Labels:
- Correctness

Description

Let's say I parse this line with PropertyAuthorityFactory

48000=PROJCS["bug", ... ,AUTHORITY["EPSG","48000"]]

PropertyAuthorityFactory uses WKTParsingAuthorityFactory. PROJCS element is parsed to Properties which are passed to NamedIdentifier. NamedIdentifier then uses the name as code. Resulting CRS is EPSG:bug instead of EPSG:48000.

Activity

Ascending order - Click to sort in descending order

Hide

Permalink

Martin Desruisseaux added a comment - 24/Jul/2009 16:24

I added more tests in PropertyAuthorityFactoryTest and got the result we would expect. Which method is returning "EPSG:bug" when "EPSG:48000' would be expected? Is it CoordinateReferenceSystem.getName().getCode()? If so, then "bug" would be the expected result (the "EPSG:" prefix is strange and would need investigation). In order to get "EPSG:48000", the method to use is CoordinateReferenceSystem.getIdentifiers(), or the CRS.toSRS(...) convenience method (fixed as of ~~GEOTK-21~~).

I admit that getCode() may be a misleading method name for getting the string representation of the CRS name, but this is the way ISO 19111 and 19115 are written (unless I'm misunderstanding them) where the CRS name is considered itself as a kind of identifier...

Show

Martin Desruisseaux added a comment - 24/Jul/2009 16:24 I added more tests in PropertyAuthorityFactoryTest and got the result we would expect. Which method is returning "EPSG:bug" when "EPSG:48000' would be expected? Is it CoordinateReferenceSystem.getName().getCode()? If so, then "bug" would be the expected result (the "EPSG:" prefix is strange and would need investigation). In order to get "EPSG:48000", the method to use is CoordinateReferenceSystem.getIdentifiers(), or the CRS.toSRS(...) convenience method (fixed as of ~~GEOTK-21~~). I admit that getCode() may be a misleading method name for getting the string representation of the CRS name, but this is the way ISO 19111 and 19115 are written (unless I'm misunderstanding them) where the CRS name is considered itself as a kind of identifier...

Hide

Permalink

Anonymous added a comment - 24/Jul/2009 18:22

It's NamedIdentifier.getName.toString, call stack:

{{
NamedIdentifier.getName() line: 521
NamedIdentifier.toString() line: 746
String.valueOf(Object) line: 2827
StringBuilder.append(Object) line: 115
FilterFactoryImpl.bbox(Expression, BoundingBox) line: 296
}}

I think toString() of NamedIdentifier is OK, but I don't like how NamedIdentifier is constructed. It takes "bug" from PROJCS WKT element as its code, but should take key 48000 from properties file (or [perhaps from AUTHORITY element).

Show

Anonymous added a comment - 24/Jul/2009 18:22 It's NamedIdentifier.getName.toString, call stack: {{ NamedIdentifier.getName() line: 521 NamedIdentifier.toString() line: 746 String.valueOf(Object) line: 2827 StringBuilder.append(Object) line: 115 FilterFactoryImpl.bbox(Expression, BoundingBox) line: 296 }} I think toString() of NamedIdentifier is OK, but I don't like how NamedIdentifier is constructed. It takes "bug" from PROJCS WKT element as its code, but should take key 48000 from properties file (or [perhaps from AUTHORITY element).

Hide

Permalink

Martin Desruisseaux added a comment - 27/Jul/2009 14:25

Actually the bug was in FilterFactoryImpl.bbox(...) method, which should ask for the CRS identifier rather than the name. This has been fixed on Geotoolkit-pending:

http://hg.geotoolkit.org/geotoolkit-pending/rev/e163b94fadc9

In a WKT like {{PROJCS["bug", ... ,AUTHORITY["EPSG","48000"]]}}, the text right after PROJCS is the name (as returned by crs.getName()), and the text inside AUTHORITY is the identifier (as returned by crs.getIdentifiers()). From my memory, if the Geotoolkit test suite is working properly, the Namedidentifier constructor dispatches the content of the Properties map that way.

Maybe an issue is that the NamedIdentifier object itself could be a cause of confusion, since it is both a GenericName and a ReferenceIdentifier.

I'm closing this issue as "resolved" for now, pending confirmation that the fix is appropriate. Please let us know if it is not.

Show

Martin Desruisseaux added a comment - 27/Jul/2009 14:25 Actually the bug was in FilterFactoryImpl.bbox(...) method, which should ask for the CRS identifier rather than the name. This has been fixed on Geotoolkit-pending:

http://hg.geotoolkit.org/geotoolkit-pending/rev/e163b94fadc9

In a WKT like {{PROJCS["bug", ... ,AUTHORITY["EPSG","48000"]]}}, the text right after PROJCS is the name (as returned by crs.getName()), and the text inside AUTHORITY is the identifier (as returned by crs.getIdentifiers()). From my memory, if the Geotoolkit test suite is working properly, the Namedidentifier constructor dispatches the content of the Properties map that way. Maybe an issue is that the NamedIdentifier object itself could be a cause of confusion, since it is both a GenericName and a ReferenceIdentifier. I'm closing this issue as "resolved" for now, pending confirmation that the fix is appropriate. Please let us know if it is not.

Geotoolkit

PropertyAuthorityFactory incorrectly uses CRS name as its code

Details

Description

Activity

People

Dates

Time Tracking