Thank you Martin for the pointer to CoordinateOperationAuthorityFactory.
However, I've failed to instantiate it:
ServiceLoader<CoordinateOperationAuthorityFactory> loader =
(ServiceLoader<CoordinateOperationAuthorityFactory>)
ServiceLoader.load(CoordinateOperationAuthorityFactory.class);
CoordinateOperationAuthorityFactory factory = loader.iterator().next();
Then I get:
Exception in thread "main" java.util.NoSuchElementException
at
java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:365)
at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
at org.gvsig.sis_proj.AppSis.listOperations(AppSis.java:140)
at org.gvsig.sis_proj.AppSis.main(AppSis.java:99)
So the factory is not properly loaded.
I've successfully instantiated CRSAuthorityFactory using similar code:
ServiceLoader<CoordinateOperationAuthorityFactory> loader =
(ServiceLoader<CoordinateOperationAuthorityFactory>)
ServiceLoader.load(CoordinateOperationAuthorityFactory.class);
CoordinateOperationAuthorityFactory factory = loader.iterator().next();
Some more questions:
- 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
are currently using Java 8, so Java 7 is not a concern for us, but we would
not like to be rushed to migrate our code to Java 9 (or future versions)
because SIS enforces it.
-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? Do you have plans to implement
(some of) them?
Thanks for the support.
César
On 29 January 2018 at 20:13, Martin Desruisseaux <
martin.desruisse...@geomatys.com> wrote:
> Hello César
>
> Le 29/01/2018 à 19:25, César Martínez Izquierdo a écrit :
>
> I am evaluating using SIS as the basis for our CRS management libraries on
> gvSIG project (a desktop, Java-based GIS application).
>
> Yes, we know gvSIG :-)
>
>
> Currently, we offer the user the opportunity to choose the transformation
> method when transforming coordinates from a source CRS to a target CRS
> involving different datums (for instance from EPSG:23030 to EPSG:4326).
> However, I don't find a clear way to get this information from SIS API.
> Ideally, I would expect a method like:
>
> Set<CoordinateOperation> ops = CRS.findOperations(source, target, context);
>
> but it obviously doesn't exist at the moment.
>
> Actually something like that exists somewhere else.
> 'org.apache.sis.crs.CRS' is a convenience class targeting what look like
> the most commonly used operations. For getting more flexibility, we need to
> instantiate some more specific classes. The functionality you are looking
> for is provided by the CoordinateOperationAuthorityFactory interface:
>
> http://www.geoapi.org/3.0/javadoc/org/opengis/referencing/operation/
> CoordinateOperationAuthorityFactory.html
>
> To get an instance of this interface, you can use the following code:
>
> ServiceLoader.load(CoordinateOperationAuthorityFactory.class).findFirst():
>
>
> I have achieved a similar goal by diving a bit in the implementation and
> subclassing CoordinateOperationFinder and DefaultCoordinateOperationFactory
> (...snip...)
>
> - those classes have been designed to not being subclassed (declaring a
> lot of private or "friendly" methods) and I assume my implementation would
> be very sensitive to SIS version updates
>
> The method declared public or protected should be okay; we try to keep
> them stable. At the very least, they will not be removed without a
> deprecation cycle. The fact that lot of methods are private is a
> consequence of being careful about what we commit to keep stable.
>
>
> - we loose the heuristics internally used by SIS to use the right
> concatenation pipeline (in the example: EPSG:23030 to EPSG:4230, then
> EPSG:4326). Which means that we would need to replicate those heuristics in
> our library to take into account all the different scenarios, as it is
> currently done by SIS internally.
>
> Indeed, the proposed approach would list only operations explicitly
> defined by EPSG, which usually include only transformation between two
> GeographicCRS (not between ProjectedCRS). I presume that you need the later
> too?
>
>
> However, I believe that CRS.findOperations would not be extremely hard to
> implement if done within Apache SIS library (instead of doing it
> externally). Do you think it would be feasible?
>
> You mean in a way that list all transformations defined by EPSG even if
> some CRS are ProjectedCRS? It would be possible. Current implementation
> already iterates over all possibilities and apply some user-configurable
> rules for selecting the "best" operation. Those rules are based on the
> region of interest and desired accuracy.
>
>
> Would you be keen on accepting such contribution?
>
> Of course :-) The work would basically be to replace the above-cited
> filtering by a code storing visited operations in a list.
>
> Regards,
>
> Martin
>
>
>
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
César Martínez Izquierdo
GIS developer
- - - - - - - - - - - - - - - - - - - -
SCOLAB: http://www.scolab.es
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
