Thanks Martin, the proposed workaround for CoordinateOperationAuthorityFactory works as expected.
One last question, I don't find a way to query/search the existing CRSs by name (for instance retrieving a list of CRSs having ETRS89 in the name). Of course I could get the full list of available CRSs on the authority, try to instantiate each of them and apply the filter then, but seems a suboptimal approach. As an alternative, is there a way to get the connection to the underlying EPSG database to directly launch queries? This would allow very different user cases to be implemented without requiring exposing everything on SIS API. I understand that probably you don't want to assume that there is an underlying database at all (in the general API), but maybe it is something that could be available on a lower level API. Regards, César On 31 January 2018 at 20:01, Martin Desruisseaux < martin.desruisse...@geomatys.com> wrote: > Hello César > > Le 31/01/2018 à 16:35, César Martínez Izquierdo a écrit : > > Thank you Martin for the pointer to CoordinateOperationAuthorityFactory. > However, I've failed to instantiate it: (...snip...) java.util. > NoSuchElementException > > Indeed, my mistake. After verification I saw that > CoordinateOperationAuthorityFactory is not registered in META-INF/services. > I filled a JIRA task on this issue: > > https://issues.apache.org/jira/browse/SIS-393 > > In the meantime, the following trick should work. It is fragile because of > the cast, but this is a temporary solution (more on it below): > > CoordinateOperationAuthorityFactory factory = > (CoordinateOperationAuthorityFactory) CRS.getAuthorityFactory("EPSG"); > > A more permanent solution will be to rely on the upcoming ISO 19111 > revision. All those FooFactory interfaces where not derived from ISO > 19111; they are GeoAPI additions. But latest ISO 19111 draft defines a > RegisterOperations interface with a findCoordinateOperations(…) method. > Once this standard is officially adopted, we plan to align on it. > > > The documentation states that Java 7 is required, but I've seen that you > are adapting the code now to Java 8 (in trunk), and removing Java 7 support > (if I correctly understood the changes). What are your plans for the > future? Will you move to Java 9 and drop Java 8 support? Have you > considered keeping compatibility with several versions (e.g. 7 to 9)? > > We try to keep compatibility with several versions. Despite having > branches for different JDK versions, Apache SIS should be runnable on all > Java versions above the target version except Java 9 (actually not yet > tested). The purpose of those branches is only to be ready when we decide > to upgrade the Java requirement, by allowing immediate use of new Java > features. > > The reason for upgrading to Java 8 is for allowing the use of following > packages in public API. If it was not for this need (or if we needed those > packages only in non-public API), we could have stayed on Java 7 longer: > > - java.time > - java.util.stream > > Regarding Java 9, I'm not aware of any new classes or interfaces that we > would need to leverage in public API. Consequently we have no reason to > force the use of Java 9 at runtime any time soon (we may require Java 9 for > building SIS, but not for using in other projects). My proposal is to > deploy either Java 8 files, or maybe multi-version JAR files for Java 8 and > 9. > > > I've seen that some projections are defined on EPSG but they are not > currently supported on SIS (for instance Lambert azimuthal equal-area > projection). Do you have a list of them? > > The coordinate operation methods published in EPSG guidance notes are > listed there, together with an indication of whether it is implemented in > SIS or remain to be done: > > https://issues.apache.org/jira/browse/SIS-212 > > In a few cases we have code pending in the Geotk project, but we need to > continue the intellectual property review (http://svn.apache.org/repos/ > asf/sis/ip-review/) before to port them to Apache SIS. > > > Do you have plans to implement (some of) them? > > At least the easy ones (a few coordinate operations there are merely > affine transforms with parameters expressed in a different way) and the > projections we can port from Geotk. When I will be able to do that however > is uncertain. > > Regards, > > Martin > > > -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - César Martínez Izquierdo GIS developer - - - - - - - - - - - - - - - - - - - - SCOLAB: http://www.scolab.es - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
