GeoAPI provides a set of interfaces in programming languages (currently Java and Python) for geospatial applications. The GeoAPI interfaces closely follow OGC specifications, adaptated to match the expectations of programmers.
The src/main/asciidoc/informative/metadata/departures.adoc file said that MD_ReferenceSystemTypeCode is omitted because considered redundant with typing system of object-oriented languages. This is not true; that code list is present in GeoAPI 3.1 and is not fully redundant because of additional information such as the type of components in a CompoundCRS. We need to revisit that paragraph and also revisit the discussion about MD_ReferenceSystem in light of ISO 19111:2019 revision.
Consider also adding a ReferenceSystemType[] components() method in ReferenceSystemType code list, so for example COMPOUND_GEOGRAPHIC2D_TEMPORAL.components() would return {GEOGRAPHIC2D, TEMPORAL}.
Above proposal may require to change ReferenceSystemType.valueOf(String) with addition of a ReferenceSystemType... components argument. An IllegalArgumentException would be throw if the given code list name exists and is associated to a different array of components.
Above proposal may require to change the CodeList.valueOf(..., String nameIfNew) method signature in GeoAPI 3.1 (not yet released), replacing String nameIfNew by Supplier<T> creator. This change is desirable anyway for security reason, for avoiding call of private constructor by reflection.
Finally, AuthorityFactory.getAuthorityCodes(Class) could replace the Class argument by ReferenceSystemType. It would be both safer (avoid the possibility that users specify an implementation class instead than a neutral interface) and more accurate (make possible to specify the desired components of CompoundCRS).
The
src/main/asciidoc/informative/metadata/departures.adoc
file said thatMD_ReferenceSystemTypeCode
is omitted because considered redundant with typing system of object-oriented languages. This is not true; that code list is present in GeoAPI 3.1 and is not fully redundant because of additional information such as the type of components in aCompoundCRS
. We need to revisit that paragraph and also revisit the discussion aboutMD_ReferenceSystem
in light of ISO 19111:2019 revision.Consider also adding a
ReferenceSystemType[]
components() method inReferenceSystemType
code list, so for exampleCOMPOUND_GEOGRAPHIC2D_TEMPORAL.components()
would return{GEOGRAPHIC2D, TEMPORAL}
.Above proposal may require to change
ReferenceSystemType.valueOf(String)
with addition of aReferenceSystemType... components
argument. AnIllegalArgumentException
would be throw if the given code list name exists and is associated to a different array of components.Above proposal may require to change the
CodeList.valueOf(..., String nameIfNew)
method signature in GeoAPI 3.1 (not yet released), replacingString nameIfNew
bySupplier<T> creator
. This change is desirable anyway for security reason, for avoiding call of private constructor by reflection.Finally,
AuthorityFactory.getAuthorityCodes(Class)
could replace theClass
argument byReferenceSystemType
. It would be both safer (avoid the possibility that users specify an implementation class instead than a neutral interface) and more accurate (make possible to specify the desired components ofCompoundCRS
).