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
