Hi Martin, Thanks for the information. I’ll look into making the switch over to SIS from GeoTools.
Thanks again, Greg From: Martin Desruisseaux <martin.desruisse...@geomatys.com> Sent: 28 August 2018 22:18 To: greg_albis...@hotmail.com Cc: users@jena.apache.org Subject: Re: RE: GeoSPARQL modules Was: Spatial distance in Fuseki Hello Greg On 2018/08/28 15:25:42, Greg Albiston <greg_albis...@hotmail.com><mailto:greg_albis...@hotmail.com> wrote: It's not clear to me whether JTS can be used with Apache SIS for point 3 and perhaps Martin can help? It let users choose between JTS, ESRI API (under Apache 2 license) or Java2D as a fallback. If using JTS, the version is 1.15+ (org.locationtech.jts-core). It may require SIS 1.0 however (not yet released), I did not checked if the change from JTS 1.14 to 1.15 was effective at SIS 0.8 release time. The functionality provided by GeoTools seems to be covered by Apache SIS. However, the relevant sections of the Developer Guide (http://sis.apache.org/book/en/developer-guide.html#GetCRS) are marked as TODO. The main requirements fulfilled by GeoTools are: 1) Look up CRS from authority by URI. Yes, it supports EPSG codes, URI and URL including the "crs-compound" form (used for letting users assemble their own horizontal + vertical systems). Examples are provided here: http://sis.apache.org/apidocs/org/apache/sis/referencing/CRS.html#forCode-java.lang.String- Note: GeoTools has a flag for forcing the (longitude, latitude) axis order. This flag has been removed in Apache SIS because such alterations result in CRS that are not compliant with the authoritative definitions. If (longitude, latitude) order is really wanted, the CRS can be changed after construction as below: crs = AbstractCRS.castOrCopy(crs).forConvention(AxesConvention.RIGHT_HANDED); 2) Look up math transformation between source and target CRS. Yes, in a better way than GeoTools: http://sis.apache.org/apidocs/org/apache/sis/referencing/CRS.html#findOperation-org.opengis.referencing.crs.CoordinateReferenceSystem-org.opengis.referencing.crs.CoordinateReferenceSystem-org.opengis.metadata.extent.GeographicBoundingBox- A first difference compared to GeoTools is that Apache SIS method also take an optional GeographicBounding box in argument. Specifying the source and target CRS are not sufficient; in USA there is about 80 transformations from NAD27 to WGS84. To pick-up the right transform, we need to specify if we want to transform coordinates in Texas, or in Alaska, or in Canada, etc. A GeoTools bug a few years ago was to select the most accurate transformation regardless its domain of validity, which happen to be a transformation for Cuba because it covers a small surface. Consequently users were applying to USA a transformation designed for Cuba. Another bug was to select the transformation valid in the widest area, which happen to be a transformation for Canada. Consequently users were applying to USA a transformation designed for Canada. A second difference is that Apache SIS does not return the MathTransfom directly, but the ISO 19111 CoordinateOperation instead. The coordinate operation contains additional metadata, in particular the domain of validity and the transformation accuracy. Those metadata give a way to avoid the errors cited in previous paragraph (applying in a country a transformation designed for another country). It also reduce the risk that users miss the fact that MathTransform are not accurate up to rounding errors. For example transforming from NAD27 to WGS84 in Canada has a 30 meters errors (when not using datum shift grid) for reasons unrelated to computer accuracy. The CoordinateOperation returned by Apache SIS tries to make those facts more visible. Getting the MathTransform from a CoordinateOperation is one method call (operation.getMathTransform()). An additional feature that Apache SIS MathTransform has compared to GeoTools is the capability to compute Jacobian matrices. 3) Apply the math transformation to a source Geometry to produce a target Geometry (i.e. JTS Geometry). Not directly in Apache SIS, but we have this code in another project and could easily port it to SIS. It is an easy functionality to code anyway. 4) Provide unit of measures (GeoTools uses javax.measure.unit) support derived from the CRS to allow conversions of distances (SI and non-SI units). Actually the javax.measure.unit package come from JSR-275, which has been rejected by the JCP. The replacement is JSR-363, which has been approved by the JCP and uses the javax.measure package. Apache SIS implements JSR-363: http://sis.apache.org/apidocs/org/apache/sis/measure/Units.html SIS provides SI and non-SI units together with their EPSG codes. It supports arithmetic operations - for example it detects by itself that the result of NEWTON.multiply(METRE).divide(SECOND) is Watt - can parse many of the units used by the World Meteorological Organisation (K*m s-1, μg m-3, etc.). The CRS definitions contain the unit of measurements in their axes, and unit conversions are taken in account when transforming from a source CRS to a target CRS. Martin
