You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@sis.apache.org by Thierry Danard <th...@int.com> on 2020/01/06 15:58:58 UTC
Re: Conversion from WGS 84 to NAD27 / Alaska Albers
Thank you for the answer
I'd like to build from the master
On Sat, Dec 21, 2019 at 10:18 AM Martin Desruisseaux <
martin.desruisseaux@geomatys.com> wrote:
> Hello Thierry
>
> This one was a bug in SIS. The problem occurred when the longitude to
> project (176°) and the longitude of the central meridian (-154°) are on
> two opposite sides of the anti-meridian (±180°). The problem does not
> occur with all map projection methods, but "only" for Albers Equal Area,
> Lambert Conic Conformal and Oblique Stereographic. I just pushed a fix
> on development branch, and now your test case produces the expected
> results on my machine.
>
> How would you like to get the fix? I presume that you are using the SIS
> 1.0 release. Do you want to wait for 1.1 release or is it okay for you
> to build from master? Note: if you choose to build from master, please
> let me know so that I merge the fix - for now it is on a different branch.
>
> JIRA issue: https://issues.apache.org/jira/browse/SIS-486
>
> Martin
>
>
>
Re: Conversion from WGS 84 to NAD27 / Alaska Albers
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Le 08/01/2020 à 00:09, Martin Desruisseaux a écrit :
> (…snip…) that file seems to contain 114 grids. (…snip…) To fix this
> issue we need to read all sub-grids in NTv2 files.
>
I just remembered that we had a JIRA issue for that created 2 years ago:
https://issues.apache.org/jira/browse/SIS-409
Martin
Re: Conversion from WGS 84 to NAD27 / Alaska Albers
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Hello Thierry
Le 15/01/2020 à 14:53, Thierry Danard a écrit :
> (…snip…) we have one error that appears on some of the tests:
>
> InvalidGeodeticParameterException: Unit conversion from “DMS” to “°”
> is non-linear.
>
This test uses the Coordinate Operation EPSG::1473, which is marked as
deprecated in EPSG database. The reason may be that this operation uses
the Coordinate System EPSG::6402 ("Ellipsoidal 2D CS. Axes: latitude,
longitude. Orientations: north, east. UoM: DMSH.") in its source CRS,
which is itself marked as deprecated. The reason for this deprecation
may be the unit of measurement of latitude/longitude values, which is
DMSH in that particular coordinate system. DMSH is sexagesimal degrees
encoded as floating point numbers. In this representation, 10°30'N is
encoded as 10.3, not 10.5.
Sexagesimal degrees are difficult to use in a software. Those values
have to be converted to decimal degrees (e.g. 10.3 → 10.5) before they
can be used in computation. This conversion is non-linear since it has
many discontinuities (e.g. value after 10.599999… is 11.0). Nevertheless
Apache SIS can handle them to some extend. We handle them in map
projection parameters because EPSG is still using sexagesimal degrees in
those places, but we currently do not support them as coordinate system
axis unit (i.e. the latitude/longitude values given to transform method).
In principle the lack of support of sexagesimal degrees in coordinate
system axis should not be an issue since, to my knowledge, EPSG
deprecated many years ago all Coordinate Systems, Coordinate Reference
Systems and Coordinate Operations that were using them — maybe because
of above-cited difficulty. New EPSG codes for the same CRS/operations
but using decimal degrees should exist, but I have not checked what
would be the replacement for EPSG::1473. It should be possible to find
the replacement with a search in EPSG database, or alternatively by
writing some code using Apache SIS.
If the support of those deprecated coordinate operations is needed, this
is doable but would require some developments in SIS. Apache SIS handles
conversions of axis units as affine transforms: this is convenient for
converting all axes in a single operation and also allows efficient
concatenation with other linear operations like axis swapping. But
affine transforms can do only linear conversions, which is the reason
for the error message that you got. If DMSH units in coordinate system
axis is desired, it would have to be handled as a step separated from
other unit conversions. Alternatively we could also ignore the DMSH
units and handle them as if they were decimal degrees, but I'm not sure
if it is the best thing to do.
Regards,
Martin
Re: Conversion from WGS 84 to NAD27 / Alaska Albers
Posted by Thierry Danard <th...@int.com>.
Thanks for helping with the multiple grid files issue. Let us know if there
is anything we can do to help. In the meantime, we have one error that
appears on some of the tests:
InvalidGeodeticParameterException: Unit conversion from “DMS” to “°” is
non-linear.
The code to reproduce is below:
public void NAD_1983_CSRS_Quebec_AlbersTest() throws FactoryException,
NoninvertibleTransformException, MismatchedDimensionException,
TransformException {
double latitude = 53;
double longitude = -68;
double x = 33320.3957334436;
double y = 1004126.36457275;
CRSAuthorityFactory crsFactory = CRS.getAuthorityFactory("EPSG");
CoordinateOperationAuthorityFactory opFactory =
(CoordinateOperationAuthorityFactory) crsFactory;
// NAD_1983_CSRS_Quebec_Albers
CoordinateReferenceSystem targetCRS =
crsFactory.createCoordinateReferenceSystem("6624");
// This is the transformation we want to use
NAD_1983_CSRS_To_WGS_1984
CoordinateOperation datumOperation =
opFactory.createCoordinateOperation("1473");
// normalize the axis for the target
targetCRS =
AbstractCRS.castOrCopy(targetCRS).forConvention(AxesConvention.DISPLAY_ORIENTED);
CoordinateOperation targetOperation =
CRS.findOperation(datumOperation.getSourceCRS(), targetCRS, null);
/*
* concatenate two operations
*/
MathTransform step1 = datumOperation.getMathTransform().inverse();
MathTransform step2 = targetOperation.getMathTransform();
MathTransform completeTransform = MathTransforms.concatenate(step1,
step2);
/*
* transform to x,y in one step
*/
DirectPosition source = new DirectPosition2D(latitude, longitude);
DirectPosition target = completeTransform.transform(source, null);
double[] coordinate = target.getCoordinate();
Assert.assertEquals(x, coordinate[0], 1);
Assert.assertEquals(y, coordinate[1], 1);
}
On Mon, Jan 13, 2020 at 5:33 AM Martin Desruisseaux <
martin.desruisseaux@geomatys.com> wrote:
> Le 08/01/2020 à 00:09, Martin Desruisseaux a écrit :
>
> > To fix this issue we need to read all sub-grids in NTv2 files. The
> > NTv2 reader of SIS is actually already capable of that, but to finish
> > that work cleanly we need an R-Tree or QuadTree. I may try to
> > implement a "raw" approach this weekend without R-Tree/QuadTree for
> > now, at the sacrifice of performance, and revisit later when we have
> > better index. I will see if I can do that Saturday or Sunday and keep
> > you informed.
> >
> I did some work on this issue this weekend. I changed my mind and try to
> go the "right" way (using a QuadTree or RTree) from the beginning. But
> it will take me a few more weekends before to complete this task. I will
> keep this list informed about the progress.
>
> Martin
>
>
>
Re: Conversion from WGS 84 to NAD27 / Alaska Albers
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Le 08/01/2020 à 00:09, Martin Desruisseaux a écrit :
> To fix this issue we need to read all sub-grids in NTv2 files. The
> NTv2 reader of SIS is actually already capable of that, but to finish
> that work cleanly we need an R-Tree or QuadTree. I may try to
> implement a "raw" approach this weekend without R-Tree/QuadTree for
> now, at the sacrifice of performance, and revisit later when we have
> better index. I will see if I can do that Saturday or Sunday and keep
> you informed.
>
I did some work on this issue this weekend. I changed my mind and try to
go the "right" way (using a QuadTree or RTree) from the beginning. But
it will take me a few more weekends before to complete this task. I will
keep this list informed about the progress.
Martin
Re: Conversion from WGS 84 to NAD27 / Alaska Albers
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Hello Thierry
Le 06/01/2020 à 23:02, Thierry Danard a écrit :
> We have one more below that gives a bigger error (still in Alaska!)
> than we expected. Do you have any idea?
>
Just tested. That transformation uses the NTv2_0.gsb datum shift grid
file. The NTv2 format can contain many grids inside the same file.
Sometime the first grid covers the whole country with a coarse
resolution, and other grids cover smaller areas with finer resolution.
The NTv2 support in Apache SIS is currently built on this assumption: it
only reads the first grid contained in an NTv2 file assuming that it is
the one covering the larger area. In the case of NTv2_0.gsb file, this
assumption is not valid: that file seems to contain 114 grids, and I'm
not sure it has one covering the whole country. Apache SIS pickup the
first grid, which appear to be further on the East side of Canada, and
the tested point is outside that grid.
To fix this issue we need to read all sub-grids in NTv2 files. The NTv2
reader of SIS is actually already capable of that, but to finish that
work cleanly we need an R-Tree or QuadTree. I may try to implement a
"raw" approach this weekend without R-Tree/QuadTree for now, at the
sacrifice of performance, and revisit later when we have better index. I
will see if I can do that Saturday or Sunday and keep you informed.
Regards,
Martin
Re: Conversion from WGS 84 to NAD27 / Alaska Albers
Posted by Thierry Danard <th...@int.com>.
We built with the latest code and it fixes the error that we reported.
Thanks!
We have one more below that gives a bigger error (still in Alaska!) than we
expected. Do you have any idea?
public void Transform2964_1693_Test() throws FactoryException,
MismatchedDimensionException, TransformException {
double latitude = 61;
double longitude = -135;
double x = 3314991.01765517;
double y = 4493850.4355215;
CRSAuthorityFactory crsFactory = CRS.getAuthorityFactory("EPSG");
CoordinateOperationAuthorityFactory opFactory =
(CoordinateOperationAuthorityFactory) crsFactory;
// This is the transformation we want to go from Nad27 to WGS84 -
NAD_1927_To_WGS_1984_33
CoordinateOperation datumOperation =
opFactory.createCoordinateOperation("1693");
// NAD_1927_Alaska_Albers_Feet
CoordinateReferenceSystem targetCRS =
crsFactory.createCoordinateReferenceSystem("2964");
// normalize the axis for the target
targetCRS =
AbstractCRS.castOrCopy(targetCRS).forConvention(AxesConvention.DISPLAY_ORIENTED);
CoordinateOperation targetOperation =
CRS.findOperation(datumOperation.getSourceCRS(), targetCRS, null);
/*
* We have two operations: WGS84 -> Nad27 and Nad27 to X,Y to
concatenate
*/
MathTransform step1 = datumOperation.getMathTransform().inverse();
MathTransform step2 = targetOperation.getMathTransform();
MathTransform completeTransform = MathTransforms.concatenate(step1,
step2);
/*
* transform to x,y in one step
*/
DirectPosition source = new DirectPosition2D(latitude, longitude);
DirectPosition target = completeTransform.transform(source, null);
double[] coordinate = target.getCoordinate();
Assert.assertEquals(x, coordinate[0], 10);
Assert.assertEquals(y, coordinate[1], 10);
}
On Mon, Jan 6, 2020 at 12:08 PM Martin Desruisseaux <
martin.desruisseaux@geomatys.com> wrote:
>
> Hello Thierry
>
> Le 06/01/2020 à 16:58, Thierry Danard a écrit :
>
> > Thank you for the answer
> >
> > I'd like to build from the master
> >
> I just pushed a cherry-pick of geoapi-4.0 branch to master. You should
> be able to run "mvn install" and test again (note: building requires
> Java 13, even if the resulting JAR files are Java 8 compatible). Please
> let me know if there is any issue.
>
> Martin
>
Re: Conversion from WGS 84 to NAD27 / Alaska Albers
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Hello Thierry
Le 06/01/2020 à 16:58, Thierry Danard a écrit :
> Thank you for the answer
>
> I'd like to build from the master
>
I just pushed a cherry-pick of geoapi-4.0 branch to master. You should
be able to run "mvn install" and test again (note: building requires
Java 13, even if the resulting JAR files are Java 8 compatible). Please
let me know if there is any issue.
Martin