Re: JTS support for transformation?

[Florian Micklich <fl...@disy.net>]

Hi Martin,

thanks for the response and info.

I tried something different and have therefore a general  question of the reprojection process.

I am using the maven dependencies  org.apache.sis.core (v.1.0) and org.apache.sis.non-free and I want to reproject a SIS DirectPosition2D point.

I assume that my WGS84 point is in lng / lat that's why I use a special axisConvention.


So here my example:

CoordinateReferenceSystem sourceCRS = CRS.forCode("EPSG:4326");
CoordinateReferenceSystem targetCRS = CRS.forCode("EPSG:32632");
CoordinateReferenceSystem alternativCRSsource = AbstractCRS.castOrCopy(sourceCRS).forConvention(AxesConvention.RIGHT_HANDED);


CoordinateOperation op = CRS.findOperation(alternativCRSsource, targetCRS, null);

DirectPosition2D sisPoint = new DirectPosition2D(8.4036527, 49.0068901);
DirectPosition2D projPoint = (DirectPosition2D) op.getMathTransform().transform(sisPoint, null);

System.out.println(projPoint.toString()); // POINT(456387.7786436868 5428393.033233286)



To get this run I need following packages:

import org.apache.sis.geometry.DirectPosition2D;
import org.apache.sis.referencing.CRS;
import org.apache.sis.referencing.crs.AbstractCRS;
import org.apache.sis.referencing.cs.AxesConvention;

import org.opengis.referencing.crs.CoordinateReferenceSystem;
import org.opengis.referencing.operation.CoordinateOperation;
import org.opengis.referencing.operation.TransformException;
import org.opengis.util.FactoryException;


I found a similar example on https://sis.apache.org/book/en/developer-guide.html

I am wondering off the org.opengis.* packades and why I have to cast the  op object result from org.opengis.geometry.DirectPosition; to org.apache.sis.geometry.DirectPosition2D;

The apache project I am working on is not allowed to use LGPL and I know this packages from another geotools project.

So is my example correct? Under which license do the org.opengis packages run which are apparently included in one of the sis dependencies (just to be save in this part)


Thanks!

Florian



Am 08.03.20 um 21:49 schrieb Martin Desruisseaux:

Hello Florian, and welcome!

Disy Informationssysteme GmbH
Florian Micklich
Lösungsentwickler
+49 721 16006 477,  florian.micklich@disy.net

Firmensitz: Ludwig-Erhard-Allee 6, 76131 Karlsruhe
Registergericht: Amtsgericht Mannheim, HRB 107964
Geschäftsführer: Claus Hofmann

Bitte beachten Sie folgende Informationen für Kunden, Lieferanten und Bewerber
- Datenschutz: www.disy.net/datenschutz
- Informationspflichten:  www.disy.net/informationspflichten


Le 08/03/2020 à 21:17, Florian Micklich a écrit :

I am pretty new to Apache SIS but did already some coordinate transformations like this example:

https://sis.apache.org/book/en/developer-guide.html#CoordinateOperations

Is there also a possibility to reproject other geometries like LineStrings and Polygons or do I have to use a CoordinateSequens to reproject such kind of types?

Yes, but not yet with a public, committed API. The support of geometries in Apache SIS is a work in progress. Geometries are defined by the ISO 19107 international standard, which supports up to three-dimensional geometries with curves. JTS can been seen as a subset of that standard for two-dimensional line strings in Cartesian space. Our plan is to define an API based on ISO 19107, then create wrappers around JTS objects for exposing those objects through that API. That way the same API can also be used with ESRI API (another library which can pretty much compete with JTS), and the API is ready for 3 dimensional objects in the future.

But we are not yet there. In the meantime it is possible to do some operations on JTS objects using the given class:

  *   org.apache.sis.internal.feature.jts.JTS

It has a static method like below:

  *   public static Geometry transform(Geometry geometry, CoordinateOperation operation)

However everything in "internal" packages are not committed API; they may change in any future SIS version. As said before we plan to provide this service in the future through an API which work with JTS as well as with ESRI API and future libraries. But we are not yet there and for now that internal API is the only way.


Is there an example to do a transformation with JTS geometry with SIS?

If "source" and "target" are two EPSG code as Strings, it could be:

CoordinateReferenceSystem sourceCRS = CRS.forCode(source);
CoordinateReferenceSystem targetCRS = CRS.forCode(target);
CoordinateOperation op = CRS.findOperation(sourceCRS, targetCRS, null);

Geometry original = ...;
Geometry converted = JRS.transform(original, op);       // WARNING: internal class, may change in any future version.


Regards,

    Martin

Re: JTS support for transformation?

[Martin Desruisseaux <ma...@geomatys.com>]

Hello Florian

Le 30/04/2020 à 09:27, Florian Micklich a écrit :

> I assume that my WGS84 point is in lng / lat that's why I use a 
> special axisConvention (…snip…).
> CoordinateReferenceSystem sourceCRS = CRS.forCode("EPSG:4326");
> CoordinateReferenceSystem targetCRS = CRS.forCode("EPSG:32632");
> CoordinateReferenceSystem alternativCRSsource = AbstractCRS.castOrCopy(sourceCRS).forConvention(AxesConvention.RIGHT_HANDED);

Just as a note, those 3 lines can be made a little bit simpler. OGC 
defines another code, which is similar to "EPSG:4326" but with (lon,lat) 
axis order. This is called "CRS:84" and should be understood by many GIS 
software, not just SIS. So those 3 lines can be written as below:

    CoordinateReferenceSystem sourceCRS = CRS.forCode("CRS:84");
    CoordinateReferenceSystem targetCRS = CRS.forCode("EPSG:32632");

Alternatively we also define some frequently used CRS in a CommonCRS 
class. So another way to get the same result is:

    CoordinateReferenceSystem sourceCRS = CommonCRS.WGS84.normalizedGeographic();
    CoordinateReferenceSystem targetCRS = CRS.forCode("EPSG:32632");

Javadoc: 
https://sis.apache.org/apidocs/org/apache/sis/referencing/CommonCRS.html


> (…snip…) I am wondering off the org.opengis.* packades and why I have 
> to cast the  op object result from 
> |org.opengis.geometry.|DirectPosition|; to 
> org.apache.sis.geometry.DirectPosition2D;
> |
>
It is not necessary to cast actually. The cast was done only for 
convenience, for direct access to the x and y fields. But the following 
code work as well:

    DirectPosition2D sisPoint = new DirectPosition2D(8.4036527, 49.0068901);
    DirectPosition projPoint = op.getMathTransform().transform(sisPoint, null);
    double x = projPoint.getOrdinate(0);
    double y = projPoint.getOrdinate(1);

Note that the getOrdinate(int) method may need to be renamed 
getCoordinate(int) in a future version of GeoAPI interfaces, for 
consistency with terminology used in ISO/OGC standards. In such case the 
old method would still be there as a deprecated method.


> The apache project I am working on is not allowed to use LGPL and I 
> know this packages from another geotools project.
>
Yes the main authors of GeoTools referencing module are now working on 
Apache SIS. That is why some classes are similar. A review of 
intellectual property has been done in order to port to SIS only the 
GeoTools codes that have been written by developers who have signed the 
Apache Individual Contributor License Agreement (ICLA), which is the 
vast majority of metadata and referencing code. Each of those classes 
are listed in the link below, with a list of commits for each class and 
actions taken for the few cases where a commit was not done by an author 
who signed ICLA:

    https://svn.apache.org/repos/asf/sis/ip-review/


> So is my example correct?
>
Yes the code is correct. It can be made a little bit more implementation 
neutral if you wish as below:

    // SIS-specifie code
    CRSAuthorityFactory crsFactory = getAuthorityFactory​(null);

    // Implementation neutral
    GeographicCRS sourceCRS = crsFactory.createGeographicCRS("CRS:84");
    ProjectedCRS  targetCRS = crsFactory.createProjectedCRS("EPSG:32632");

    // SIS-specific code for now (implementation neutral way to be provided in a future version)
    CoordinateOperation op = CRS.findOperation(alternativCRSsource, targetCRS, null);


> Under which license do the org.opengis packages run which are 
> apparently included in one of the sis dependencies (just to be save in 
> this part)
>
GeoAPI 3.0.1 interfaces in the org.opengis packages are under OGC 
Software License Version 1.0 which is BSD like:

    https://www.ogc.org/ogc/software/1.0

A discussion about this license can be viewed there:

    https://github.com/spdx/license-list-XML/issues/845

As discussed in above link, a future version of GeoAPI interfaces may 
need to move to a slightly different license, the OGC document license. 
No decision has been taken yet and the Apache foundation will be 
consulted first. In the context of GeoAPI, the OGC document license is 
the same than the current BSD like "OGC software license" with one 
additional constraint: if a user wants to modify an interface in the 
"org.opengis" package, then (s)he needs to rename "org.opengis" into 
something else. After (s)he has done this renaming, the interfaces fall 
into the BSD-like license. Note that this is similar to a similar 
constraints in Apache license, which said that if we modify an Apache 
software then we can not call it Apache anymore; we have to give it a 
new name. The "OGC document license" is simply more specific about the 
requirement to change the namespace (in the case of Java: package and 
module names) in order to avoid conflicts with other implementations of 
the standard.

    https://www.ogc.org/ogc/document

But this is for future. Current GeoAPI 3.0.1 is BSD-like, and I plan to 
have a discussion between OGC and Apache before to eventually move 
GeoAPI 3.1/4.0 to "OGC document license" for making sure that it is okay 
for Apache.

     Martin