Hello César
Le 02/02/2018 à 21:08, César Martínez Izquierdo a écrit :
> Thanks Martin, the proposed workaround for
> CoordinateOperationAuthorityFactory works as expected.
>
Good, thanks for letting us know.
> 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).
>
This is an undocumented feature, but CRS.forCode(String) accepts names.
For example CRS.forCode("EPSG::WGS 84 / World Mercator") will work.
However this method intentionally fails if there is ambiguity. For
example CRS.forCode("EPSG::WGS 84") fails because it could apply to more
than one CRS.
> 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.
>
A less suboptimal approach is to get the list of available code with
CRSAuthorityFactory.getAuthorityCodes(CoordinateReferenceSystem.class),
then get the name of each of them by calls to
CRSAuthorityFactory.getDescriptionText(code). That later method is
lightweight; is returns the name without instantiating the object.
However it stay less efficient than a SQL query.
> As an alternative, is there a way to get the connection to the
> underlying EPSG database to directly launch queries?
>
No public API yet, but there is an internal class in
org.apache.sis.internal.metadata.sql:
DataSource ds = Initializer.getDataSource();
Everything under "org.apache.sis.internal" packages is non-committed API
(excluded from Javadoc); in Java 9, they would be inaccessible from
other modules. We have not yet determined what could be a public API for
fetching this DataSource, mostly because I'm not sure what would be the
most standard approach. A common answer is "use JNDI" (this is the way
to do in a container like Tomcat), but I'm not aware of a standard JNDI
implementation in standalone Java. Suggestions are welcome!
Martin
