[sis] 02/02: Fix type and wrong path to a runtime dependency.
This is an automated email from the ASF dual-hosted git repository.
desruisseaux pushed a commit to branch geoapi-4.0
in repository https://gitbox.apache.org/repos/asf/sis.git
commit 2bdcb9145c5b4b258b0f5a739c6d71f91b83ef3f
Author: Martin Desruisseaux
AuthorDate: Fri Sep 17 17:44:52 2021 +0200
Fix type and wrong path to a runtime dependency.
---
.../src/main/java/org/apache/sis/internal/setup/FXFinder.java | 2 +-
ide-project/NetBeans/nbproject/project.properties | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git
a/application/sis-javafx/src/main/java/org/apache/sis/internal/setup/FXFinder.java
b/application/sis-javafx/src/main/java/org/apache/sis/internal/setup/FXFinder.java
index 2f6dae4..27798d8 100644
---
a/application/sis-javafx/src/main/java/org/apache/sis/internal/setup/FXFinder.java
+++
b/application/sis-javafx/src/main/java/org/apache/sis/internal/setup/FXFinder.java
@@ -31,7 +31,7 @@ import java.util.zip.ZipFile;
/**
* Ask user to specify the path to JavaFX installation directory.
- * This is used one JavaFX can not be found on the classpath.
+ * This is used when JavaFX can not be found on the classpath.
*
* @author Martin Desruisseaux (Geomatys)
* @version 1.1
diff --git a/ide-project/NetBeans/nbproject/project.properties
b/ide-project/NetBeans/nbproject/project.properties
index 2187e55..d218403 100644
--- a/ide-project/NetBeans/nbproject/project.properties
+++ b/ide-project/NetBeans/nbproject/project.properties
@@ -159,7 +159,7 @@ javac.test.classpath=\
javac.test.processorpath=\
${javac.test.classpath}
run.jaxb.classpath=\
-
${maven.repository}/javax/activation/activation/${activation.version}/activation-${activation.version}.jar:\
+
${maven.repository}/jakarta/activation/jakarta.activation-api/${activation.version}/jakarta.activation-api-${activation.version}.jar:\
${maven.repository}/org/glassfish/jaxb/jaxb-runtime/${jaxb.version}/jaxb-runtime-${jaxb.version}.jar:\
${maven.repository}/org/glassfish/jaxb/txw2/${jaxb.version}/txw2-${jaxb.version}.jar:\
${maven.repository}/com/sun/istack/istack-commons-runtime/${istack.version}/istack-commons-runtime-${istack.version}.jar
[sis] 01/02: Add JAXB dependency (required for avoiding a ClassNotFoundError). Update debug instruction, reformat license text on multi-lines.
This is an automated email from the ASF dual-hosted git repository.
desruisseaux pushed a commit to branch geoapi-4.0
in repository https://gitbox.apache.org/repos/asf/sis.git
commit 7dead6c42b9824fdd13820c0503156be131f052a
Author: Martin Desruisseaux
AuthorDate: Fri Sep 17 17:29:35 2021 +0200
Add JAXB dependency (required for avoiding a ClassNotFoundError).
Update debug instruction, reformat license text on multi-lines.
---
application/sis-openoffice/pom.xml | 5 +
.../src/main/unopkg/build-instruction.html | 18 ++
.../sis-openoffice/src/main/unopkg/license.txt | 21 +
3 files changed, 36 insertions(+), 8 deletions(-)
diff --git a/application/sis-openoffice/pom.xml
b/application/sis-openoffice/pom.xml
index b2138f2..4e2f8a2 100644
--- a/application/sis-openoffice/pom.xml
+++ b/application/sis-openoffice/pom.xml
@@ -100,6 +100,11 @@
sis-utility
${project.version}
+
+ jakarta.xml.bind
+ jakarta.xml.bind-api
+ compile
+
diff --git a/application/sis-openoffice/src/main/unopkg/build-instruction.html
b/application/sis-openoffice/src/main/unopkg/build-instruction.html
index 27fffa1..0f6af24 100644
--- a/application/sis-openoffice/src/main/unopkg/build-instruction.html
+++ b/application/sis-openoffice/src/main/unopkg/build-instruction.html
@@ -26,9 +26,6 @@
OpenOffice add-in build instructions
-
- This page is adapted from the http://www.geoapi.org/geoapi-openoffice/build.html;>GeoAPI build page.
-
All XFoo Java interfaces are generated from IDL files with
the same name.
As long as XFoo Java/IDL interfaces are not modified, there
is no need for the OpenOffice SDK.
@@ -101,9 +98,22 @@ mvn install
Test in Apache OpenOffice:
+Launch:
cd target
unopkg add apache-sis-1.0-SNAPSHOT.oxt --log-file log.txt
-scalc -Xdebug -env:RTL_LOGFILE=log.txt
+scalc -env:RTL_LOGFILE=log.txt
+
+If not already done, configure Java runtime with
+ Tools → Options… → Advanced → Java options →
Parameters
+ and specify the following parameters:
+
+-agentlib:jdwp=transport=dt_socket,server=y,address=8000,suspend=n
+
+
+ It allows to attach the IDE debugger to the Java virtual machine running in
LibreOffice.
+ For example with NetBeans, use Debug → Attach debugger…,
+ select "Socket attach" as the transport and 8000 as the port number.
+
diff --git a/application/sis-openoffice/src/main/unopkg/license.txt
b/application/sis-openoffice/src/main/unopkg/license.txt
index 43547b5..a42b118 100644
--- a/application/sis-openoffice/src/main/unopkg/license.txt
+++ b/application/sis-openoffice/src/main/unopkg/license.txt
@@ -1,13 +1,26 @@
-Licensed under the Apache License, Version 2.0 (the "License"); you may not
use this file except in compliance with the License. You may obtain a copy of
the License at
+Licensed under the Apache License, Version 2.0 (the "License");
+you may not use this file except in compliance with the License.
+You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
-Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
License for the specific language governing permissions and limitations under
the License.
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND,
+either express or implied. See the License for the specific
+language governing permissions and limitations under the
+License.
───
-This software may contain geodetic dataset distributed under EPSG terms of
use. You may not use the EPSG Facilities or any of them in whole or in part
unless you agree to these Terms of Use. You may obtain a copy of EPSG terms of
use at
+This software may contain geodetic dataset distributed under
+EPSG terms of use. You may not use the EPSG Facilities or any of
+them in whole or in part unless you agree to these Terms of Use.
+You may obtain a copy of EPSG terms of use at
https://epsg.org/terms-of-use.html
-Data and information provided in the EPSG facilities are provided "as is"
without warranty of any kind, either expressed or implied, including but not
limited to the implied warranties of merchantability and/or fitness for a
particular purpose.
+Data and information provided in the EPSG facilities are provided
+"as is" without warranty of any kind, either expressed or implied,
+including but not limited to the implied warranties of
+merchantability and/or fitness for a particular purpose.
[sis] branch geoapi-4.0 updated (f05d801 -> 2bdcb91)
This is an automated email from the ASF dual-hosted git repository. desruisseaux pushed a change to branch geoapi-4.0 in repository https://gitbox.apache.org/repos/asf/sis.git. from f05d801 Upgrade OpenOffice dependency. Four JAR files are replaced by a single one. new 7dead6c Add JAXB dependency (required for avoiding a ClassNotFoundError). Update debug instruction, reformat license text on multi-lines. new 2bdcb91 Fix type and wrong path to a runtime dependency. The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .../org/apache/sis/internal/setup/FXFinder.java | 2 +- application/sis-openoffice/pom.xml | 5 + .../src/main/unopkg/build-instruction.html | 18 ++ .../sis-openoffice/src/main/unopkg/license.txt | 21 + ide-project/NetBeans/nbproject/project.properties | 2 +- 5 files changed, 38 insertions(+), 10 deletions(-)
[jira] [Resolved] (SIS-505) Upgrade OpenOffice/LibreOffice dependency
[
https://issues.apache.org/jira/browse/SIS-505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux resolved SIS-505.
-
Assignee: Martin Desruisseaux
Resolution: Fixed
> Upgrade OpenOffice/LibreOffice dependency
> -
>
> Key: SIS-505
> URL: https://issues.apache.org/jira/browse/SIS-505
> Project: Spatial Information Systems
> Issue Type: New Feature
> Components: OpenOffice
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Minor
> Fix For: 1.1
>
>
> The four Java jars {{juh.jar}}, {{jurt.jar}}, {{ridl.jar}}, and {{unoil.jar}}
> are now combined into a single {{libreoffice.jar}}.
> Source: https://wiki.documentfoundation.org/ReleaseNotes/7.0/en#Java_support
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[sis] branch geoapi-4.0 updated (32936ed -> f05d801)
This is an automated email from the ASF dual-hosted git repository. desruisseaux pushed a change to branch geoapi-4.0 in repository https://gitbox.apache.org/repos/asf/sis.git. from 32936ed Following removal of "sis-gdal" module in previous commit, remove (for now) the `SpecializedOperationFactory` interface. Remove also the code for loading a native library (not used anymore). new c2bc991 Document that derivative is not yet supported. new f05d801 Upgrade OpenOffice dependency. Four JAR files are replaced by a single one. The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: application/sis-openoffice/pom.xml | 30 +++--- .../projection/ModifiedAzimuthalEquidistant.java | 6 + 2 files changed, 10 insertions(+), 26 deletions(-)
[sis] 02/02: Upgrade OpenOffice dependency. Four JAR files are replaced by a single one.
This is an automated email from the ASF dual-hosted git repository.
desruisseaux pushed a commit to branch geoapi-4.0
in repository https://gitbox.apache.org/repos/asf/sis.git
commit f05d801cef2c165dda813fc83cdc8ce3296537eb
Author: Martin Desruisseaux
AuthorDate: Fri Sep 17 16:17:59 2021 +0200
Upgrade OpenOffice dependency. Four JAR files are replaced by a single one.
https://issues.apache.org/jira/browse/SIS-505
---
application/sis-openoffice/pom.xml | 30 --
1 file changed, 4 insertions(+), 26 deletions(-)
diff --git a/application/sis-openoffice/pom.xml
b/application/sis-openoffice/pom.xml
index db8dc5e..b2138f2 100644
--- a/application/sis-openoffice/pom.xml
+++ b/application/sis-openoffice/pom.xml
@@ -80,10 +80,6 @@
We must declare transitive dependencies explicitly,
otherwise they will not be included by sis-unopkg.
=== -->
-
-4.1.2
-
-
org.opengis
@@ -105,29 +101,11 @@
${project.version}
-
-
- org.openoffice
- juh
- ${openoffice.version}
- provided
-
-
- org.openoffice
- jurt
- ${openoffice.version}
- provided
-
-
- org.openoffice
- ridl
- ${openoffice.version}
- provided
-
+
- org.openoffice
- unoil
- ${openoffice.version}
+ org.libreoffice
+ libreoffice
+ 7.2.1
provided
[sis] 01/02: Document that derivative is not yet supported.
This is an automated email from the ASF dual-hosted git repository. desruisseaux pushed a commit to branch geoapi-4.0 in repository https://gitbox.apache.org/repos/asf/sis.git commit c2bc991edb435103951effec7398919c6dcd74d2 Author: Martin Desruisseaux AuthorDate: Fri Sep 17 15:48:37 2021 +0200 Document that derivative is not yet supported. https://issues.apache.org/jira/browse/SIS-237 --- .../operation/projection/ModifiedAzimuthalEquidistant.java | 6 ++ 1 file changed, 6 insertions(+) diff --git a/core/sis-referencing/src/main/java/org/apache/sis/referencing/operation/projection/ModifiedAzimuthalEquidistant.java b/core/sis-referencing/src/main/java/org/apache/sis/referencing/operation/projection/ModifiedAzimuthalEquidistant.java index 652e4f2..331eef7 100644 --- a/core/sis-referencing/src/main/java/org/apache/sis/referencing/operation/projection/ModifiedAzimuthalEquidistant.java +++ b/core/sis-referencing/src/main/java/org/apache/sis/referencing/operation/projection/ModifiedAzimuthalEquidistant.java @@ -37,6 +37,12 @@ import static org.apache.sis.internal.referencing.provider.ModifiedAzimuthalEqui * This is an approximation of the oblique form of the Azimuthal Equidistant projection. * For distances under 800 kilometres this modification introduces no significant error. * + * Limitation + * This class does not support derivative (Jacobian matrix) yet. + * See https://issues.apache.org/jira/browse/SIS-237;>SIS-237 on issues tracker. + * + * @todo Add Jacobian matrix formulas. + * * @author Martin Desruisseaux (Geomatys) * @version 1.1 *
[jira] [Updated] (SIS-469) Remove support for JAXB internal implementation (JDK 8)
[
https://issues.apache.org/jira/browse/SIS-469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-469:
Fix Version/s: (was: 1.1)
1.2
Affects Version/s: 1.1
> Remove support for JAXB internal implementation (JDK 8)
> ---
>
> Key: SIS-469
> URL: https://issues.apache.org/jira/browse/SIS-469
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Metadata, Referencing, Storage
>Affects Versions: 1.0, 1.1
>Reporter: Martin Desruisseaux
>Priority: Minor
> Fix For: 1.2
>
>
> Apache SIS 1.0 uses the JAXB implementation found in the
> {{com.sun.xml.internal.bind}} package, if presents, because this package is
> provided with Java 8. That JAXB implementation can optionally be replaced by
> the one in {{com.sun.xml.bind}} package (without {{internal}}), but we still
> want to use the internal implementation as a fallback.
> Starting with Java 11, the internal JAXB implementation is no longer
> available. Consequently there is no point in continuing to support that
> package after Apache SIS upgraded its requirement to Java 11. The codes to
> delete will be:
> * {{Implementation.INTERNAL}}
> * {{Implementation.toInternal(String)}}
> * {{Pooled.internal}}
> * Maybe more, to be investigated.
> Then, the {{provided}} scope of {{jakarta.xml.bind-api}} dependency in root
> {{pom.xml}} file should be removed. Since the default scope {{compile}} is
> transitive, {{jakarta.xml.bind-api}} dependencies declared downstream
> {{sis-metadata}} module can be removed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (SIS-447) NumericCoverage as a parent of GridCoverage
[
https://issues.apache.org/jira/browse/SIS-447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux resolved SIS-447.
-
Resolution: Fixed
The class name is {{BandedCoverage}} instead of {{NumericCoverage}}, but the
rest is about as described in this issue.
> NumericCoverage as a parent of GridCoverage
> ---
>
> Key: SIS-447
> URL: https://issues.apache.org/jira/browse/SIS-447
> Project: Spatial Information Systems
> Issue Type: New Feature
> Components: Features
>Affects Versions: 1.0
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Minor
> Fix For: 1.1
>
>
> The base type of all coverage (including raster) data is {{Coverage}}, which
> is defined by ISO 19123. A {{Coverage}} is not necessarily a grid (raster).
> It is rather a collection of "geometry - record" pairs where the geometries
> are pixels in the particular case of rasters. ISO 19123 defines many
> {{Coverage}} subtypes: {{DiscreteCoverage}}, {{ContinuousCoverage}}, _etc._.
> The types which seem closest to a raster are
> {{ContinuousQuadrilateralGridCoverage}} and {{DiscreteGridPointCoverage}}.
> However even those types are more complex than the majority of the needs to
> be handled by Apache SIS. For now SIS defines only one class,
> {{GridCoverage}}, which is simpler (at the cost of being less powerful) than
> ISO 19123 classes. We tried to define {{GridCoverage}} in a way that should
> not conflict with future ISO 19123 compliant development.
> A key simplification done in SIS {{GridCoverage}} compared to ISO 19123
> {{Coverage}} is that, in addition of assuming that values are distributed on
> a grid, it also assumes that all values are stored as numbers. Those numbers
> may be associated to categories (e.g. _1 = clouds_), but they still numbers.
> By contrast ISO 19123 allows the storage of more complex structures:
> {{Record}} where each record may contain other records. An ISO 19123
> {{Record}} may be seen as a simple {{Feature}}, i.e. a feature where the
> multiplicity of all attributes is constrained to [1…1].
> In the same way than ISO 19123 allows various coverage types (not necessarily
> gridded) and defines subclasses for the particular case of coverage using a
> grid, we may want a more general class in Apache SIS for any coverage storing
> data as numbers (as a simplification of the more general {{Record}} type).
> The methods could be:
> {code:java}
> public abstract class NumericCoverage {
> public abstract CoordinateReferenceSystem getCoordinateReferenceSystem();
> public abstract List getSampleDimensions();
> }
> {code}
> {{GridCoverage}} would extend that class and add a {{getGridGeometry()}}
> method. The main difference between this proposed {{NumericCoverage}}
> compared to ISO 19123 {{Coverage}} is the {{getSampleDimensions()}} method,
> which can be seen as a specialization of the following method:
> {code:java}
> public interface Coverage {
> RecordType getRangeType();
> }
> {code}
> The class name is difficult to chose. Current proposal is
> {{NumericCoverage}}. We found usage of that term on a web page about
> [Atmospheric Dispersion
> Index|http://cwfis.cfs.nrcan.gc.ca/background/summary/adi]: _"The coverage
> descriptions, which indicate few, scattered, broken, or overcast, are
> translated into numeric coverage classes."_ — while I'm not sure it describes
> the same thing. We searched also {{NumericalCoverage}} but found less
> relevant usages.
> This {{NumericCoverage}} class would be a complement of ISO 19123 classes. It
> should not prevent us to implement more fully ISO 19123 in the future. The
> "Numeric" part in {{NumericCoverage}} describes a characteristic of the
> _range_ (ISO 19123 coverages have two parts: _domain_ and _range_), in the
> same way than the "Discrete" and "Continuous" parts in ISO 19123
> {{DiscreteCoverage}} and {{ContinuousCoverage}} also refer to the range.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (SIS-447) NumericCoverage as a parent of GridCoverage
[
https://issues.apache.org/jira/browse/SIS-447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux reassigned SIS-447:
---
Assignee: Martin Desruisseaux
> NumericCoverage as a parent of GridCoverage
> ---
>
> Key: SIS-447
> URL: https://issues.apache.org/jira/browse/SIS-447
> Project: Spatial Information Systems
> Issue Type: New Feature
> Components: Features
>Affects Versions: 1.0
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Minor
> Fix For: 1.1
>
>
> The base type of all coverage (including raster) data is {{Coverage}}, which
> is defined by ISO 19123. A {{Coverage}} is not necessarily a grid (raster).
> It is rather a collection of "geometry - record" pairs where the geometries
> are pixels in the particular case of rasters. ISO 19123 defines many
> {{Coverage}} subtypes: {{DiscreteCoverage}}, {{ContinuousCoverage}}, _etc._.
> The types which seem closest to a raster are
> {{ContinuousQuadrilateralGridCoverage}} and {{DiscreteGridPointCoverage}}.
> However even those types are more complex than the majority of the needs to
> be handled by Apache SIS. For now SIS defines only one class,
> {{GridCoverage}}, which is simpler (at the cost of being less powerful) than
> ISO 19123 classes. We tried to define {{GridCoverage}} in a way that should
> not conflict with future ISO 19123 compliant development.
> A key simplification done in SIS {{GridCoverage}} compared to ISO 19123
> {{Coverage}} is that, in addition of assuming that values are distributed on
> a grid, it also assumes that all values are stored as numbers. Those numbers
> may be associated to categories (e.g. _1 = clouds_), but they still numbers.
> By contrast ISO 19123 allows the storage of more complex structures:
> {{Record}} where each record may contain other records. An ISO 19123
> {{Record}} may be seen as a simple {{Feature}}, i.e. a feature where the
> multiplicity of all attributes is constrained to [1…1].
> In the same way than ISO 19123 allows various coverage types (not necessarily
> gridded) and defines subclasses for the particular case of coverage using a
> grid, we may want a more general class in Apache SIS for any coverage storing
> data as numbers (as a simplification of the more general {{Record}} type).
> The methods could be:
> {code:java}
> public abstract class NumericCoverage {
> public abstract CoordinateReferenceSystem getCoordinateReferenceSystem();
> public abstract List getSampleDimensions();
> }
> {code}
> {{GridCoverage}} would extend that class and add a {{getGridGeometry()}}
> method. The main difference between this proposed {{NumericCoverage}}
> compared to ISO 19123 {{Coverage}} is the {{getSampleDimensions()}} method,
> which can be seen as a specialization of the following method:
> {code:java}
> public interface Coverage {
> RecordType getRangeType();
> }
> {code}
> The class name is difficult to chose. Current proposal is
> {{NumericCoverage}}. We found usage of that term on a web page about
> [Atmospheric Dispersion
> Index|http://cwfis.cfs.nrcan.gc.ca/background/summary/adi]: _"The coverage
> descriptions, which indicate few, scattered, broken, or overcast, are
> translated into numeric coverage classes."_ — while I'm not sure it describes
> the same thing. We searched also {{NumericalCoverage}} but found less
> relevant usages.
> This {{NumericCoverage}} class would be a complement of ISO 19123 classes. It
> should not prevent us to implement more fully ISO 19123 in the future. The
> "Numeric" part in {{NumericCoverage}} describes a characteristic of the
> _range_ (ISO 19123 coverages have two parts: _domain_ and _range_), in the
> same way than the "Discrete" and "Continuous" parts in ISO 19123
> {{DiscreteCoverage}} and {{ContinuousCoverage}} also refer to the range.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-398) MI_PolarizationOrientationCode as an alias of MI_PolarisationOrientationCode
[
https://issues.apache.org/jira/browse/SIS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-398:
Fix Version/s: (was: 1.1)
1.2
Affects Version/s: 1.1
> MI_PolarizationOrientationCode as an alias of MI_PolarisationOrientationCode
>
>
> Key: SIS-398
> URL: https://issues.apache.org/jira/browse/SIS-398
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Metadata
>Affects Versions: 1.0, 1.1
>Reporter: Martin Desruisseaux
>Priority: Minor
> Labels: JAXB
> Fix For: 1.2
>
>
> The {{MI_PolarizationOrientationCode}} code list in ISO 19139:2007 has been
> renamed {{MI_PolarisationOrientationCode}} in ISO 19115-3:2016 ("z" changed
> into "s"). We should:
> * (minor) rename the class name in {{org.apache.sis.internal.jaxb.code}}
> package. This require an update of at least the GeoAPI annotation in order to
> all {{AllMetadataTest}} to pass. See
> https://github.com/opengeospatial/geoapi/issues/23
> * (major) adapt our XML (un)marshalling process for using both spelling
> depending on the ISO version used. We already have a renaming mechanism for
> properties, but not yet for types.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-384) (Affine → Passthrough → Affine) should be simplified as (Affine → Passthrough) or (Passthrough → Affine)
[
https://issues.apache.org/jira/browse/SIS-384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-384:
Fix Version/s: (was: 1.1)
1.2
Affects Version/s: 1.1
1.0
> (Affine → Passthrough → Affine) should be simplified as (Affine →
> Passthrough) or (Passthrough → Affine)
>
>
> Key: SIS-384
> URL: https://issues.apache.org/jira/browse/SIS-384
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Referencing
>Affects Versions: 0.5, 0.6, 0.7, 0.8, 1.0, 1.1
>Reporter: Martin Desruisseaux
>Priority: Minor
> Labels: performance
> Fix For: 1.2
>
>
> Below is an example of concatenated math transform. An "Affine" operation
> appears twice: before and after the "Passthrough" operation:
> {noformat}
> Concat_MT[
> Param_MT["Affine",
> Parameter["num_row", 5],
> Parameter["num_col", 5],
> Parameter["elt_0_0", 0.025],
> Parameter["elt_0_4", 3.0125],
> Parameter["elt_1_1", -0.025],
> Parameter["elt_1_4", 44.9875]],
> PassThrough_MT[2, 1, Param_MT["Interpolation 1D",
> Parameter["values", {2.0, 10.0, 20.0, 35.0, 50.0, 75.0, 100.0}]]],
> Param_MT["Affine",
> Parameter["num_row", 5],
> Parameter["num_col", 5],
> Parameter["elt_3_3", 360.0],
> Parameter["elt_3_4", 1.5127128E12]]]
> {noformat}
> The last "Affine" operates only on passthrough coordinates. Consequently it
> could be moved before the "Passthrouh" operation, which would allow
> concatenation with the first "Affine" operation. It should not change the
> operation result, but can improve performance.
> This optimization is possible only for "Affine" that operate only on
> pass-through coordinates. If the last "Affine" does not comply with this
> condition, maybe the first "Affine" does. So we will need to test both.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-369) Better selection of datum shift method depending on desired accuracy
[
https://issues.apache.org/jira/browse/SIS-369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-369:
Fix Version/s: (was: 1.1)
1.2
Affects Version/s: 1.1
1.0
> Better selection of datum shift method depending on desired accuracy
>
>
> Key: SIS-369
> URL: https://issues.apache.org/jira/browse/SIS-369
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Referencing
>Affects Versions: 0.8, 1.0, 1.1
>Reporter: Martin Desruisseaux
>Priority: Minor
> Fix For: 1.2
>
>
> Coordinate operations may be slow, especially when datum shifts are involved.
> When not using datum shift grid files, the most common method is _geocentric
> translation_. The _Molodensky_ method is a little bit faster at the expanse
> of accuracy, but that accuracy lost may be acceptable for example if the
> scale on a map is not sufficient for seeing the difference. At very small
> scale where each pixel is 10 km wide, we can even skip the datum shift
> operation completely. The question is where to put the threshold. 5 meters
> for _Molodensky_, 10 meters for _Abridged Molodensky_, 3 km for none? This
> need to be measured, for example by trying all _geocentric translation_
> operations in the EPSG database. Once thresholds have been determined, the
> {{DatumShiftMethod.forAccuracy(double)}} method should be updated accordingly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-370) Improve CoordinateOperation WKT for axis changes and Molodensky parameters
[
https://issues.apache.org/jira/browse/SIS-370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-370:
Fix Version/s: (was: 1.1)
1.2
Affects Version/s: 1.1
1.0
> Improve CoordinateOperation WKT for axis changes and Molodensky parameters
> --
>
> Key: SIS-370
> URL: https://issues.apache.org/jira/browse/SIS-370
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Referencing
>Affects Versions: 0.7, 0.8, 1.0, 1.1
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Minor
> Fix For: 1.2
>
>
> The Well Known Text (WKT) formatting of {{CoordinateOperation}} objects have
> the following shortcomings:
> In the formatting of Molodensky Parameters, _Semi-major axis length
> difference_ and _Flattening difference_ parameters are wrongly set to NaN.
> Note that this issue happen only for {{CoordinateOperation}} WKT, not for
> {{MathTransform}} WKT.
> Operation steps inserted for changing axis order are shown as affine
> transform, which is difficult to read for most users. The formatter should
> detect automatically when a matrix is square, of size 3×3 or 4×4 and having 1
> value on anti-diagonal (except last row) and show instead one of the
> following operations:
> * EPSG::15498 — axis order change (2D)
> * EPSG::15499 — axis order change (geographic3D horizontal)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-365) CRS.findOperation(…) should take current locale in account when there is ambiguity
[
https://issues.apache.org/jira/browse/SIS-365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-365:
Fix Version/s: (was: 1.1)
Affects Version/s: 1.1
1.0
> CRS.findOperation(…) should take current locale in account when there is
> ambiguity
> --
>
> Key: SIS-365
> URL: https://issues.apache.org/jira/browse/SIS-365
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Referencing
>Affects Versions: 0.7, 0.8, 1.0, 1.1
>Reporter: Martin Desruisseaux
>Priority: Minor
>
> The {{CRS.findOperation(…)}} method expects 3 arguments: a source CRS, a
> target CRS, and an optional area of interest (as a geographic bounding box).
> The area of interest is sometime necessary because more than one operation
> may exists for the same pair of CRS, depending on the area of interest. For
> example the EPSG database contains about 85 different operations between
> NAD27 and WGS84. There is an operation for East of Texas, an other operation
> (with different parameters) for West of Texas, one operation for the
> continental USA as a whole, one operation for Canada as a whole,_etc._
> If the user does not provide any area of interest, then Apache SIS default
> behavior is to select the operation which is valid in the widest area.
> However, this criterion means that when asking for a transformation from
> NAD27 to WGS84, Apache SIS will select by default the operation for Canada
> because it covers a wider geographic area than the operation for continental
> USA. This may not be the default choice than many users would expect.
> We can try to improve this situation by taking the locale in account. If no
> geographic area is specified, then:
> * If the default locale is {{Locale.US}}, give precedence to the operation
> for USA.
> * If the default locale is {{Locale.CANADA}}, give precedence to the
> operation for Canada.
> * For any other locale, keep the current behavior (select widest area).
> While we used USA and Canada as an example, we actually want to apply the
> same approach for any country. Technically, we can use the {{Area}} table in
> the EPSG database. That table contains 3 columns for ISO codes: one for the
> two-letters codes, one for the three-letters codes and another one for
> numerical codes. The approach is:
> * When creating a {{GeographicExtent}} from EPSG database, include ISO codes
> (if present) as identifiers.
> * When searching for a coordinate operation, if and only if the users did not
> specified explicitly a geographic area, use the ISO codes associated with
> {{GeographicExtent}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-359) Support coordinate transformations between CRS having duplicated axis orientations
[
https://issues.apache.org/jira/browse/SIS-359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-359:
Fix Version/s: (was: 1.1)
1.2
Affects Version/s: 1.1
1.0
> Support coordinate transformations between CRS having duplicated axis
> orientations
> --
>
> Key: SIS-359
> URL: https://issues.apache.org/jira/browse/SIS-359
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Referencing
>Affects Versions: 0.6, 0.7, 0.8, 1.0, 1.1
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Minor
> Fix For: 1.2
>
>
> Coordinate systems are usually not allowed to have two axes with the same
> orientation. For example it is considered an error to have two axes oriented
> toward East. But there is at least two exceptions to this rule:
> * {{AxisDirection.OTHER}}: there is actually no way to know which direction
> it is, so two {{OTHER}} orientations may be actually different directions.
> * {{AxisDirection.FUTURE}}: meteorological data can have two time axes. For
> more information, see [OGC Best Practice for using Web Map Services (WMS)
> with Time-Dependent or Elevation-Dependent
> Data|http://www.opengis.net/doc/bp/wms-tnz/1.0] (OGC 12-111r1).
> Currently, attempt to transform two CRS having duplicated axis orientation
> produces an exception like below:
> {noformat}
> org.opengis.util.FactoryException: Ne peut pas créer l’objet géodétique pour
> « CompoundCRS[“grib-lonlat-crs+Java…”] → CompoundCRS[“grib-lonlat-crs+Java…”]
> ».
> at
> org.apache.sis.referencing.operation.CoordinateOperationFinder.createOperation(CoordinateOperationFinder.java:206)
> at
> org.apache.sis.referencing.operation.DefaultCoordinateOperationFactory.createOperation(DefaultCoordinateOperationFactory.java:750)
> at org.apache.sis.referencing.CRS.findOperation(CRS.java:610)
> ... 22 more
> Caused by: java.lang.IllegalArgumentException: Les directions d’axes
> Other et Other sont colinéaires.
> at
> org.apache.sis.referencing.operation.matrix.Matrices.createTransform(Matrices.java:267)
> at
> org.apache.sis.referencing.operation.matrix.Matrices.createTransform(Matrices.java:440)
> at
> org.apache.sis.referencing.cs.CoordinateSystems.swapAndScaleAxes(CoordinateSystems.java:280)
> at
> org.apache.sis.referencing.operation.CoordinateOperationFinder.createOperation(CoordinateOperationFinder.java:204)
> ... 26 more
> {noformat}
> One possible approach may be to remember the indirect association between
> axes and CRS during the computation performed by
> {{Matrices.createTransform(…)}}. If two axes have the same axis direction but
> we can still distinguish the axes by the enclosing CRS instance, then we can
> avoid throwing the exception.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-357) EPSG factory should be able to create geocentric CRS as derived CRS
[
https://issues.apache.org/jira/browse/SIS-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-357:
Fix Version/s: (was: 1.1)
1.2
Affects Version/s: 1.1
1.0
> EPSG factory should be able to create geocentric CRS as derived CRS
> ---
>
> Key: SIS-357
> URL: https://issues.apache.org/jira/browse/SIS-357
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Referencing
>Affects Versions: 0.7, 0.8, 1.0, 1.1
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Minor
> Fix For: 1.2
>
>
> The {{EPSGDataAccess.createCoordinateReferenceSystem(String)}} queries the
> EPSG {{"Coordinate Reference System"}} table with more than 10 columns. Some
> relevant columns for this tasks are:
> * {{COORD_REF_SYS_KIND}} (may be "geographic 2D", "geographic 3D",
> "geocentric", "projected", _etc._)
> * {{SOURCE_GEOGCRS_CODE}} (EPSG code of a {{GeographicCRS}})
> * {{PROJECTION_CONV_CODE}} (EPSG code of a {{CoordinateOperation}})
> Current {{EPSGDataAccess}} implementation uses the {{SOURCE_GEOGCRS_CODE}}
> and {{PROJECTION_CONV_CODE}} columns only if the {{COORD_REF_SYS_KIND}} is
> {{"projected"}}. But the EPSG database sometime uses those columns for other
> kind of CRS. For example with WGS 84 coordinate reference systems:
> * EPSG:4326 (geographic 2D) is derived from EPSG:4979 (geographic 3D) with
> conversion EPSG:15593 (geographic3D to geographic2D).
> * EPSG::4979 (geographic 3D) is derived from EPSG::4978 (geocentric) with
> conversion EPSG:15592 (geocentric to geographic3D).
> We could modify {{EPSGDataAccess}} as below:
> * Unconditionally build a coordinate operation from {{SOURCE_GEOGCRS_CODE}}
> and {{PROJECTION_CONV_CODE}} columns instead than only in the projected CRS
> case.
> * Above operation is mandatory for projected CRS case, optional for all other.
> * If an operation was found, use it for creating a derived CRS like below:
> {code:java}
> CoordinateOperation op = …,
> CoordinateReferenceSystem base = ...;
> if (op instanceof Conversion && base instanceof SingleCRS) {
> crs = DefaultDerivedCRS.create(properties, (SingleCRS) base, (Conversion)
> op, cs);
> }
> {code}
> However we may want to keep _Well Known Text_ (WKT) outputs simple by
> formatting the CRS as if it was a non-derived CRS. How to handle that is an
> open question.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-339) Feature attribute should verify the CRS of geometric value
[
https://issues.apache.org/jira/browse/SIS-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-339:
Fix Version/s: (was: 1.1)
1.2
Affects Version/s: 1.1
1.0
> Feature attribute should verify the CRS of geometric value
> --
>
> Key: SIS-339
> URL: https://issues.apache.org/jira/browse/SIS-339
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Features
>Affects Versions: 0.7, 0.8, 1.0, 1.1
>Reporter: Martin Desruisseaux
>Priority: Minor
> Fix For: 1.2
>
>
> In the {{org.apache.sis.feature}} package, a {{DefaultFeature}} can contains
> an attribute which itself contains a characteristic having the
> {{AttributeConvention.CRS_CHARACTERISTIC}} name. The value of that
> characteristic is the Coordinate Reference System (CRS) of the geometry that
> this attribute can contains. However there is currently no verification that
> a geometry given to that attribute has the expected CRS. We should add a
> verification mechanism, compatible with both JTS and ESRI API. This may
> require Java reflection code, since those two libraries are optional.
> One open question is where to store the CRS information in the geometry
> object. JTS has a SRID property, but it is only an {{int}} type. It could be
> decided that the integer value is the EPSG code, but this is an arbitrary
> (while common) decision. Alternatively we could use the JTS user object for
> storing the full {{CoordinateReferenceSystem}} object, but this is another
> arbitrary decision.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-319) Read CSV file conform to OGC Moving Features syntax
[
https://issues.apache.org/jira/browse/SIS-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-319:
Fix Version/s: (was: 1.1)
1.0
> Read CSV file conform to OGC Moving Features syntax
> ---
>
> Key: SIS-319
> URL: https://issues.apache.org/jira/browse/SIS-319
> Project: Spatial Information Systems
> Issue Type: New Feature
> Components: Storage
>Affects Versions: 0.7, 0.8
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Minor
> Fix For: 1.0
>
>
> Implement a reader for the OGC® Moving Features Encoding Extension:
> Simple Comma Separated Values (CSV) specification:
> * http://docs.opengeospatial.org/is/14-084r2/14-084r2.html
> Example:
> {noformat}
> @stboundedby,urn:ogc:def:crs:CRS:1.3:84,2D,50.23 9.23,50.31
> 9.27,2012-01-17T12:33:41Z,2012-01-17T12:37:00Z,sec
> @columns,mfidref,trajectory,state,xsd:token,"type code",xsd:integer
> a,10,150,11.0 2.0 12.0 3.0,walking,1
> b,10,190,10.0 2.0 11.0 3.0,walking,2
> a,150,190,12.0 3.0 10.0 3.0,walking,2
> c,10,190,12.0 1.0 10.0 2.0 11.0 3.0,vehicle,1
> {noformat}
> Implementing this is a relatively simple format allow us to test the
> following Apache SIS capabilities in a real use-case scenario:
> * {{CRS.forCode(String)}} which create a Coordinate Reference System object
> from an authority code.
> * {{org.apache.sis.feature}} implementation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-336) URL to EPSG installation instructions should be customizable
[ https://issues.apache.org/jira/browse/SIS-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux updated SIS-336: Fix Version/s: (was: 1.1) 1.2 Affects Version/s: 1.1 1.0 > URL to EPSG installation instructions should be customizable > > > Key: SIS-336 > URL: https://issues.apache.org/jira/browse/SIS-336 > Project: Spatial Information Systems > Issue Type: Task > Components: Referencing >Affects Versions: 0.7, 0.8, 1.0, 1.1 >Reporter: Martin Desruisseaux >Priority: Minor > Fix For: 1.2 > > > When SIS failed to create a Coordinate Reference System because the EPSG > geodetic dataset is not installed, the error message contains a link to the > http://sis.apache.org/epsg.html page for guiding the user to the installation > process. However applications that use Apache SIS may have their own EPSG > installation process. Those application should have the possibility to > replace the above-cited URL by their own URL. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SIS-318) Support PassThroughTransform directly into AbstractMathTransform
[
https://issues.apache.org/jira/browse/SIS-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-318:
Fix Version/s: (was: 1.1)
1.2
Affects Version/s: 1.1
1.0
> Support PassThroughTransform directly into AbstractMathTransform
>
>
> Key: SIS-318
> URL: https://issues.apache.org/jira/browse/SIS-318
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Referencing
>Affects Versions: 0.5, 0.6, 0.7, 0.8, 1.0, 1.1
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Minor
> Labels: performance
> Fix For: 1.2
>
>
> Add the 4 variants (for {{float[]}} and {{double[]}} arrays) of the following
> method in {{AbstractMathTransform}}:
> {code:java}
> protected void transform(double[] srcPts, int srcOff, int srcInc,
> double[] dstPts, int dstOff, int dstInc, int numPts)
> throws TransformException;
> {code}
> The difference compared to existing methods is the addition of {{srcInc}} and
> {{dstInc}} parameters. Then, move the {{AbstractMathTransform}} default
> implementations of {{transform(…)}} methods under those 4 new methods. The
> default implementation of previous methods would redirect to the new ones
> like below:
> {code:java}
> @Override
> public void transform(double[] srcPts, int srcOff,
> double[] dstPts, int dstOff, int numPts) throws
> TransformException
> {
> transform(srcPts, srcOff, getSourceDimensions(),
> dstPts, dstOff, getTargetDimensions(), numPts);
> }
> {code}
> This approach should ensure {{MathTransform}} methods consistency no matter
> if a sub-class override the old methods or the new ones. Modify all Apache
> SIS implementations that override the old methods for overriding the new ones
> instead.
> With those news methods, we can modify {{PassThroughTransform}}
> implementation for invoking those methods on the sub-transform with
> {{srcInc}} and {{dstInc}} values increased by {{firstAffectedOrdinate}} +
> {{numTrailingOrdinates}}. The performance benefit may be important since
> {{PassThroughTransform}} can hardly implement the {{transform}} method in an
> efficient way otherwise. We will still need the current
> {{transformOverlapping}} private method however as a fallback when array
> regions overlap.
> This approach would also make easier to concatenate the matrices of linear
> transforms. In the current implementation we lost a concatenation opportunity
> if one linear transform is the last {{MathTransform}} (in a chain of a
> concatenated transforms) inside the {{PassThroughTransform}}, while the other
> linear transform is the first {{MathTransform}} outside the
> {{PassThroughTransform}}. We could move the former linear transform outside
> the {{PassThroughTransform}}, but it cause confusing WKT to be formatted if
> the transforms inside the {{PassThroughTransform}} have a
> {{ContextualParameters}}. We expect that this problem would be solved with
> the fix proposed in this issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-300) Complete the information provided in Citations constants
[
https://issues.apache.org/jira/browse/SIS-300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-300:
Fix Version/s: (was: 1.1)
1.2
Affects Version/s: 1.1
> Complete the information provided in Citations constants
>
>
> Key: SIS-300
> URL: https://issues.apache.org/jira/browse/SIS-300
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Metadata
>Affects Versions: 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 1.0, 1.1
>Reporter: Martin Desruisseaux
>Priority: Minor
> Fix For: 1.2
>
>
> The {{org.apache.sis.metadata.iso.citation.Citations}} class contains various
> instances of {{Citation}} as static final constants, but those constants
> contain only the citation title at this time. We need to complete them with
> more information like the responsible party. In particular, we need to make
> sure that the constants contain enough information for forming a valid GML
> document when marshalled in XML (currently, they do not pass validation
> tests).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (SIS-237) Modified Azimuthal Equidistant (EPSG:9832)
[ https://issues.apache.org/jira/browse/SIS-237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux resolved SIS-237. - Resolution: Fixed > Modified Azimuthal Equidistant (EPSG:9832) > -- > > Key: SIS-237 > URL: https://issues.apache.org/jira/browse/SIS-237 > Project: Spatial Information Systems > Issue Type: Sub-task > Components: Referencing >Reporter: Martin Desruisseaux >Assignee: Martin Desruisseaux >Priority: Minor > Fix For: 1.1 > > > For various islands in Micronesia. See §1.3.16.1 in IOGP Publication 373-7-2 > – Geomatics Guidance Note number 7, part 2 – April 2015. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SIS-210) Enforce precedence of EPSG codes over names at parsing time
[
https://issues.apache.org/jira/browse/SIS-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-210:
Fix Version/s: (was: 1.1)
1.2
Affects Version/s: 1.1
1.0
> Enforce precedence of EPSG codes over names at parsing time
> ---
>
> Key: SIS-210
> URL: https://issues.apache.org/jira/browse/SIS-210
> Project: Spatial Information Systems
> Issue Type: Sub-task
> Components: Referencing
>Affects Versions: 0.6, 0.7, 0.8, 1.0, 1.1
>Reporter: Martin Desruisseaux
>Priority: Minor
> Fix For: 1.2
>
>
> The specification §9.3.2 said:
> {quote}
> If an identifier is provided as an attribute within the conversion> object, because it is expected to describe a complete collection
> of zone name, method, parameters and parameter values, it shall override any
> identifiers given within the map projection method and map projection
> parameter objects.
> {quote}
> However this would require the {{GeodeticObjectParser}} to hold a
> {{CoordinateOperationAuthorityFactory}}, which we do not yet implement.
> Likewise, EPSG code in {{Parameter}} elements are also supposed to have
> precedence over the parameter name. This is not yet implemented in SIS, but
> may be less critical since SIS implementation is quite lenient (without
> introducing ambiguities) regarding parameter names.
> For now, the only place where EPSG codes take precedence over names is when
> fetching the {{OperationMethod}} objects, which is the most critical place
> where we observed ambiguities in our experience.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-207) Support Bearing element in axes
[
https://issues.apache.org/jira/browse/SIS-207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-207:
Fix Version/s: (was: 1.1)
1.2
Affects Version/s: 1.1
1.0
> Support Bearing element in axes
> ---
>
> Key: SIS-207
> URL: https://issues.apache.org/jira/browse/SIS-207
> Project: Spatial Information Systems
> Issue Type: Sub-task
> Components: Referencing
>Affects Versions: 0.4, 0.5, 0.6, 0.7, 0.8, 1.0, 1.1
>Reporter: Martin Desruisseaux
>Priority: Minor
> Fix For: 1.2
>
>
> Polar coordinate systems may have a "{{clockwise}}" or "{{counterClockwise}}"
> axis direction followed by a {{BEARING\[angle, ANGLEUNIT\[...\]\]}} element.
> The bearing gives the specified direction from which the rotation is
> measured. Those axis directions are not yet supported in Apache SIS. If we
> wish to support them in a future version, we could adopt a strategy similar
> to the {{DirectionAlongMeridian}} package-private class.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-193) Remove the workaround for ServiceLoader bug
[
https://issues.apache.org/jira/browse/SIS-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-193:
Fix Version/s: (was: 1.1)
1.2
Affects Version/s: 1.1
1.0
> Remove the workaround for ServiceLoader bug
> ---
>
> Key: SIS-193
> URL: https://issues.apache.org/jira/browse/SIS-193
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Referencing
>Affects Versions: 0.6, 0.7, 0.8, 1.0, 1.1
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Minor
> Labels: JDK9
> Fix For: 1.2
>
>
> As of 1.8.0_31-b13, {{java.util.ServiceLoader}} does not support usage of a
> second {{Iterator}} in the middle of a previous iteration. The following Java
> code provides two simple tests with a {{ServiceLoader}} iterating over two
> elements.
> {code:java}
> import java.util.Iterator;
> import java.util.ServiceLoader;
> public class ServiceLoaderTest {
> public static class I1 extends ServiceLoaderTest {} // A dummy provider.
> public static class I2 extends ServiceLoaderTest {} // An other provider.
> public static void main(String[] args) {
> test1();
> test2();
> }
> private static void test1() {
> System.out.println();
> System.out.println(" TEST 1 ");
> ServiceLoader loader =
> ServiceLoader.load(ServiceLoaderTest.class);
> Iterator it1 = loader.iterator();
> System.out.println("it1.hasNext() = " + it1.hasNext());
> System.out.println("it1.next()= " + it1.next());
> Iterator it2 = loader.iterator();
> System.out.println("it2.hasNext() = " + it2.hasNext());
> System.out.println("it2.next()= " + it2.next());
> System.out.println("it1.hasNext() = " + it1.hasNext());
> System.out.println("it1.next()= " + it1.next());
> System.out.println("it2.hasNext() = " + it2.hasNext()); // Expected
> "true" here, but get "false".
> }
> private static void test2() {
> System.out.println();
> System.out.println(" TEST 2 ");
> ServiceLoader loader =
> ServiceLoader.load(ServiceLoaderTest.class);
> Iterator it1 = loader.iterator();
> System.out.println("it1.hasNext() = " + it1.hasNext());
> System.out.println("it1.next()= " + it1.next());
> Iterator it2 = loader.iterator();
> System.out.println("it1.hasNext() = " + it1.hasNext());
> System.out.println("it2.hasNext() = " + it2.hasNext());
> System.out.println("it1.next()= " + it1.next());
> System.out.println("it2.next()= " + it2.next()); //
> ConcurrentModificationException here.
> }
> }
> {code}
> The second test throws the following exception:
> {noformat}
> Exception in thread "main" java.util.ConcurrentModificationException
> at
> java.util.LinkedHashMap$LinkedHashIterator.nextNode(LinkedHashMap.java:711)
> at
> java.util.LinkedHashMap$LinkedEntryIterator.next(LinkedHashMap.java:744)
> at
> java.util.LinkedHashMap$LinkedEntryIterator.next(LinkedHashMap.java:742)
> at java.util.ServiceLoader$1.next(ServiceLoader.java:479)
> at test.ServiceLoaderTest.test2(ServiceLoaderTest.java:47)
> at test.ServiceLoaderTest.main(ServiceLoaderTest.java:12)
> {noformat}
> The workaround applied in Apache SIS has been to add a {{LazySet}} internal
> class which wraps an {{Iterable}} and caches its values. But this is a little
> bit unfortunate since {{ServiceLoader}} already caches its values.
> {{ServiceLoader}} is probably going to be significantly rewritten in JDK9 as
> a side effect of the Jigsaw project. So we should revisit if our {{LazySet}}
> workaround is still needed on a JDK9 branch.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-206) Verify axis name, abbreviation and direction constraints at format time
[
https://issues.apache.org/jira/browse/SIS-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-206:
Fix Version/s: (was: 1.1)
1.2
Affects Version/s: 1.1
1.0
> Verify axis name, abbreviation and direction constraints at format time
> ---
>
> Key: SIS-206
> URL: https://issues.apache.org/jira/browse/SIS-206
> Project: Spatial Information Systems
> Issue Type: Sub-task
> Components: Referencing
>Affects Versions: 0.4, 0.5, 0.6, 0.7, 0.8, 1.0, 1.1
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Minor
> Fix For: 1.2
>
>
> ISO 19162 puts many constraints on axis names, abbreviations and directions.
> Some of those constraints are inherited from ISO 19111, and some others are
> specific to ISO 19162. Apache SIS verifies some of those constraints at
> {{CoordinateSystem}} construction time, but not all. Constraints *not*
> verified by Apache SIS includes:
> * Axis names of geographic CRS shall be ‘_latitude_’, ‘_longitude_’ and (in
> 3D case) ‘_ellipsoidal height_’.
> * For other kind of CRS axis names shall be as documented in ISO 19111.
> * Abbreviation of ellipsoidal height shall be _h_.
> * Abbreviations of geocentric CRS axes shall be _X_, _Y_, _Z_.
> * Axis directions are restricted to _north_, _east_ and _up_ for geographic
> CRS (no _south_, _west_ or _down_).
> Apache SIS does not verify those constraints at formatting time. We may argue
> that this is not formatter job.
> {color:red}Update (May 2015):{color} on-the-fly renaming of "Geodetic
> longitude/latitude" into "longitude/latitude" now supported.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-136) Fused multiply-add in org.apache.sis.referencing.operation
[
https://issues.apache.org/jira/browse/SIS-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-136:
Fix Version/s: (was: 1.1)
1.2
Affects Version/s: 1.1
1.0
> Fused multiply-add in org.apache.sis.referencing.operation
> --
>
> Key: SIS-136
> URL: https://issues.apache.org/jira/browse/SIS-136
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Referencing
>Affects Versions: 0.7, 0.8, 1.0, 1.1
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Minor
> Labels: JDK9
> Fix For: 1.2
>
>
> This issue is for tracking the progress on the two following Oracle tasks:
> * [JDK-4851642 : Add FMA to Java math
> library|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4851642]
> * [JDK-4919337 : Augment Java math libraries with more methods from C libm
> and IEEE 754|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4919337]
> If _Fused Multiply-Add_ (FMA) are added to the Java language, we should
> leverage them in coordinate operations. In some cases (e.g. {{MatrixSIS}}
> subclasses), the main goal is not performance, but rather accuracy. Matrix
> inversions usually have rounding errors, and those rounding errors may be
> propagated in every corners of SIS library because of the central role played
> by matrices in SIS. While rounding errors can not be completely avoided,
> reducing them as much as possible may reduce the risk of surprising
> behaviour, especially when converting the pixel coordinates between two _Grid
> Coverages_.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (SIS-513) When rounding grids, allow per axis strategy instead of a single global one.
[
https://issues.apache.org/jira/browse/SIS-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17416696#comment-17416696
]
Martin Desruisseaux edited comment on SIS-513 at 9/17/21, 1:41 PM:
---
The strategy described in above comment is used instead of per-axis rounding
mode.
was (Author: desruisseaux):
The strategy described in above comment is used instead if per-axis rounding
mode.
> When rounding grids, allow per axis strategy instead of a single global one.
>
>
> Key: SIS-513
> URL: https://issues.apache.org/jira/browse/SIS-513
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Coverage
>Affects Versions: 1.0
>Reporter: Alexís Manin
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.1
>
>
> Related to the usage of
> `{color:#00}org.apache.sis.coverage.grid.GridRoundingMode{color}` :
>
> At the moment, its usage is often considered as a global configuration for
> every axes treated (Example:
> [GridDerivation.rounding()).|https://sis.apache.org/apidocs/org/apache/sis/coverage/grid/GridDerivation.html#rounding(org.apache.sis.coverage.grid.GridRoundingMode)]
>
> A possible improvement would be to specify the rounding strategy
> independently for each axis of the grid. One possible use-case would be to
> ease management of 2D resample over 3D+ datasets.
>
> For example, if the source coverage of a resample defines a grid [ 0..99,
> 0..99, 0..0 ], with the axes being respectively longitude, latitude and time,
> the pipeline of operation over the grid could extend all axes, even time
> slice depending on chosen rounding mode. Such behavior can fail resampling
> operation, but would be easily avoidable if we can specify that time is a
> special axis to round using NEAREST strategy.
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-125) ModifiableMetadata.nonNullCollection(...) should determine more accuratly if the metadata object is being marshalled
[
https://issues.apache.org/jira/browse/SIS-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-125:
Fix Version/s: (was: 1.1)
Affects Version/s: 1.1
1.0
> ModifiableMetadata.nonNullCollection(...) should determine more accuratly if
> the metadata object is being marshalled
>
>
> Key: SIS-125
> URL: https://issues.apache.org/jira/browse/SIS-125
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Metadata
>Affects Versions: 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 1.0, 1.1
>Reporter: Martin Desruisseaux
>Priority: Minor
>
> Despite its name, the {{ModifiableMetadata.nonNullCollection(...)}} method
> may return {{null}} in the special case of XML marshalling if and only if the
> marshalled element is optional. This is a hack for preventing JAXB to create
> empty nodes for empty properties. However in current implementation, the
> decision to return null or not is set by a thread-local flag, which apply to
> the {{ModifiableMetadata}} instances being marshalled in that particular
> thread. This approach does not work well when the user provides its own
> metadata subclass which create new elements in the collection on the fly.
> We may need to make the {{ModifiableMetadata.canReturnNull()}} method more
> accurate in order to not only use a thread-local flag, but also check for the
> particular metadata instance being marshalled. This would require storing
> somewhere a reference to the element being marshalled, and cleaning that
> reference after the marshalling of that particular element finished.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (SIS-513) When rounding grids, allow per axis strategy instead of a single global one.
[
https://issues.apache.org/jira/browse/SIS-513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux resolved SIS-513.
-
Resolution: Won't Fix
The strategy described in above comment is used instead if per-axis rounding
mode.
> When rounding grids, allow per axis strategy instead of a single global one.
>
>
> Key: SIS-513
> URL: https://issues.apache.org/jira/browse/SIS-513
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Coverage
>Affects Versions: 1.0
>Reporter: Alexís Manin
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.1
>
>
> Related to the usage of
> `{color:#00}org.apache.sis.coverage.grid.GridRoundingMode{color}` :
>
> At the moment, its usage is often considered as a global configuration for
> every axes treated (Example:
> [GridDerivation.rounding()).|https://sis.apache.org/apidocs/org/apache/sis/coverage/grid/GridDerivation.html#rounding(org.apache.sis.coverage.grid.GridRoundingMode)]
>
> A possible improvement would be to specify the rounding strategy
> independently for each axis of the grid. One possible use-case would be to
> ease management of 2D resample over 3D+ datasets.
>
> For example, if the source coverage of a resample defines a grid [ 0..99,
> 0..99, 0..0 ], with the axes being respectively longitude, latitude and time,
> the pipeline of operation over the grid could extend all axes, even time
> slice depending on chosen rounding mode. Such behavior can fail resampling
> operation, but would be easily avoidable if we can specify that time is a
> special axis to round using NEAREST strategy.
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (SIS-510) Remove sis-gdal module
[
https://issues.apache.org/jira/browse/SIS-510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux resolved SIS-510.
-
Resolution: Fixed
Two commits in order:
* {{97fcad5dc0fe393da7e8ef315498164609e5a8e7}} removes the "sis-gdal" module.
* {{32936ed8d4bcec29f82d0c302b0a3bcf031127f0}} removes support types.
Support types removed by last commit are:
* {{SpecializedOperationFactory}} (used for finding the coordinate operation
between a pair of CRS should be determined by an external library).
* {{OS}} (used for loading native libraries).
> Remove sis-gdal module
> --
>
> Key: SIS-510
> URL: https://issues.apache.org/jira/browse/SIS-510
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Referencing
>Affects Versions: 0.8, 1.0
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.1
>
>
> Development and maintenance of GeoAPI wrappers for PROJ moved to a separated
> project:
> [https://github.com/Kortforsyningen/PROJ-JNI]
> {color:#de350b}Edit (September 2021):{color} project moved to
> [https://github.com/OSGeo/PROJ-JNI]
> The PROJ native bindings in Apache SIS should be removed. Maybe we will
> recreate that module in the future if we want to add GDAL bindings instead of
> only PROJ, but current implementation did not reach that level. Furthermore
> the [JEP 191: Foreign Function Interface|http://openjdk.java.net/jeps/191]
> may change the way to do that. Alternatively we may also do this binding by
> expanding above-cited Kortforsyningen project instead of doing this work in
> SIS.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[sis] 02/02: Following removal of "sis-gdal" module in previous commit, remove (for now) the `SpecializedOperationFactory` interface. Remove also the code for loading a native library (not used anymor
This is an automated email from the ASF dual-hosted git repository.
desruisseaux pushed a commit to branch geoapi-4.0
in repository https://gitbox.apache.org/repos/asf/sis.git
commit 32936ed8d4bcec29f82d0c302b0a3bcf031127f0
Author: Martin Desruisseaux
AuthorDate: Fri Sep 17 15:15:49 2021 +0200
Following removal of "sis-gdal" module in previous commit,
remove (for now) the `SpecializedOperationFactory` interface.
Remove also the code for loading a native library (not used anymore).
---
.../referencing/SpecializedOperationFactory.java | 55 --
.../operation/CoordinateOperationFinder.java | 19 --
.../operation/CoordinateOperationRegistry.java | 9 +-
.../DefaultCoordinateOperationFactory.java | 28 ---
.../java/org/apache/sis/internal/system/OS.java| 196 -
.../apache/sis/util/logging/MonolineFormatter.java | 3 +-
ide-project/NetBeans/build.xml | 7 -
7 files changed, 2 insertions(+), 315 deletions(-)
diff --git
a/core/sis-referencing/src/main/java/org/apache/sis/internal/referencing/SpecializedOperationFactory.java
b/core/sis-referencing/src/main/java/org/apache/sis/internal/referencing/SpecializedOperationFactory.java
deleted file mode 100644
index a036ce9..000
---
a/core/sis-referencing/src/main/java/org/apache/sis/internal/referencing/SpecializedOperationFactory.java
+++ /dev/null
@@ -1,55 +0,0 @@
-/*
- * Licensed to the Apache Software Foundation (ASF) under one or more
- * contributor license agreements. See the NOTICE file distributed with
- * this work for additional information regarding copyright ownership.
- * The ASF licenses this file to You under the Apache License, Version 2.0
- * (the "License"); you may not use this file except in compliance with
- * the License. You may obtain a copy of the License at
- *
- * http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing, software
- * distributed under the License is distributed on an "AS IS" BASIS,
- * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- * See the License for the specific language governing permissions and
- * limitations under the License.
- */
-package org.apache.sis.internal.referencing;
-
-import java.util.Set;
-import org.opengis.util.FactoryException;
-import org.opengis.referencing.crs.CoordinateReferenceSystem;
-import org.opengis.referencing.operation.CoordinateOperation;
-
-
-/**
- * Implemented by extension modules capable to provide coordinate operations
for some particular pairs of CRS.
- * Implementations of this interface are not general-purpose factories;
- * they should not process any pair of CRS other than the one for which they
are designed.
- *
- * Example:
- * a module doing the bindings between Apache SIS and another map projection
library may create wrappers
- * around the transformation method of that other library when {@code
findOperations(…)} recognizes the
- * given CRS as wrappers around their data structures.
- *
- * @author Martin Desruisseaux (Geomatys)
- * @version 0.8
- * @since 0.8
- * @module
- */
-public interface SpecializedOperationFactory {
-/**
- * Returns operations between the given pair of CRS, or an empty set if
this factory does not recognize them.
- * Non-empty sets have precedence over EPSG geodetic dataset or other
mechanism used by Apache SIS, so should
- * be used sparsely.
- *
- * @param sourceCRS the coordinate reference system of source points
(before transformation).
- * @param targetCRS the coordinate reference system of target points
(after transformation).
- * @return the coordinate operations from source to target CRS, or an
empty set if this factory
- * does not recognize the given pair of CRSs.
- * @throws FactoryException if this factory recognizes the CRSs given in
arguments,
- * but an error occurred while creating the coordinate operation.
- */
-Set findOperations(CoordinateReferenceSystem
sourceCRS, CoordinateReferenceSystem targetCRS)
-throws FactoryException;
-}
diff --git
a/core/sis-referencing/src/main/java/org/apache/sis/referencing/operation/CoordinateOperationFinder.java
b/core/sis-referencing/src/main/java/org/apache/sis/referencing/operation/CoordinateOperationFinder.java
index a3ab4b1..94f9495 100644
---
a/core/sis-referencing/src/main/java/org/apache/sis/referencing/operation/CoordinateOperationFinder.java
+++
b/core/sis-referencing/src/main/java/org/apache/sis/referencing/operation/CoordinateOperationFinder.java
@@ -48,7 +48,6 @@ import
org.apache.sis.internal.referencing.provider.Geographic3Dto2D;
import org.apache.sis.internal.referencing.provider.GeographicToGeocentric;
import org.apache.sis.internal.referencing.provider.GeocentricToGeographic;
import org.apache.sis.internal.referencing.provider.GeocentricAffine;
-import
[sis] branch geoapi-4.0 updated (9d36a8d -> 32936ed)
This is an automated email from the ASF dual-hosted git repository. desruisseaux pushed a change to branch geoapi-4.0 in repository https://gitbox.apache.org/repos/asf/sis.git. from 9d36a8d Move `InternationalString` implementations to `org.apache.sis.util` package. This is in anticipation for Jigsaw modularization. new 97fcad5 Remove the sis-gdal module. It is replaced by the https://github.com/OSGeo/PROJ-JNI project. new 32936ed Following removal of "sis-gdal" module in previous commit, remove (for now) the `SpecializedOperationFactory` interface. Remove also the code for loading a native library (not used anymore). The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: application/sis-console/pom.xml| 6 - .../referencing/SpecializedOperationFactory.java | 55 -- .../main/java/org/apache/sis/referencing/CRS.java | 1 - .../operation/CoordinateOperationFinder.java | 19 - .../operation/CoordinateOperationRegistry.java | 9 +- .../DefaultCoordinateOperationFactory.java | 28 - .../org/apache/sis/internal/system/Modules.java| 5 - .../java/org/apache/sis/internal/system/OS.java| 196 - .../apache/sis/util/logging/MonolineFormatter.java | 3 +- ide-project/NetBeans/build.xml | 11 - ide-project/NetBeans/nbproject/build-impl.xml | 56 +- ide-project/NetBeans/nbproject/genfiles.properties | 4 +- ide-project/NetBeans/nbproject/project.properties | 3 - ide-project/NetBeans/nbproject/project.xml | 3 - storage/pom.xml| 1 - storage/sis-gdal/pom.xml | 120 --- storage/sis-gdal/src/main/c/Makefile | 77 -- .../src/main/c/org_apache_sis_storage_gdal_PJ.c| 321 .../src/main/c/org_apache_sis_storage_gdal_PJ.h| 85 -- .../internal/storage/gdal/OperationFactory.java| 57 -- .../sis/internal/storage/gdal/package-info.java| 26 - .../main/java/org/apache/sis/storage/gdal/PJ.java | 361 - .../java/org/apache/sis/storage/gdal/Proj4.java| 401 -- .../org/apache/sis/storage/gdal/Proj4Factory.java | 886 - .../org/apache/sis/storage/gdal/Proj4Parser.java | 185 - .../org/apache/sis/storage/gdal/Transform.java | 247 -- .../org/apache/sis/storage/gdal/package-info.java | 90 --- ...nternal.referencing.SpecializedOperationFactory | 1 - ...org.opengis.referencing.crs.CRSAuthorityFactory | 1 - .../resources/native/darwin/libproj-binding.so | Bin 14016 -> 0 bytes .../main/resources/native/linux/libproj-binding.so | Bin 13504 -> 0 bytes .../apache/sis/storage/gdal/IntegrationTest.java | 63 -- .../org/apache/sis/storage/gdal/MTFactory.java | 201 - .../java/org/apache/sis/storage/gdal/PJTest.java | 181 - .../apache/sis/storage/gdal/Proj4FactoryTest.java | 148 .../apache/sis/storage/gdal/Proj4ParserTest.java | 83 -- .../org/apache/sis/storage/gdal/Proj4Test.java | 46 -- .../org/apache/sis/storage/gdal/TransformTest.java | 102 --- .../org/apache/sis/test/suite/GDALTestSuite.java | 50 -- 39 files changed, 18 insertions(+), 4114 deletions(-) delete mode 100644 core/sis-referencing/src/main/java/org/apache/sis/internal/referencing/SpecializedOperationFactory.java delete mode 100644 core/sis-utility/src/main/java/org/apache/sis/internal/system/OS.java delete mode 100644 storage/sis-gdal/pom.xml delete mode 100644 storage/sis-gdal/src/main/c/Makefile delete mode 100644 storage/sis-gdal/src/main/c/org_apache_sis_storage_gdal_PJ.c delete mode 100644 storage/sis-gdal/src/main/c/org_apache_sis_storage_gdal_PJ.h delete mode 100644 storage/sis-gdal/src/main/java/org/apache/sis/internal/storage/gdal/OperationFactory.java delete mode 100644 storage/sis-gdal/src/main/java/org/apache/sis/internal/storage/gdal/package-info.java delete mode 100644 storage/sis-gdal/src/main/java/org/apache/sis/storage/gdal/PJ.java delete mode 100644 storage/sis-gdal/src/main/java/org/apache/sis/storage/gdal/Proj4.java delete mode 100644 storage/sis-gdal/src/main/java/org/apache/sis/storage/gdal/Proj4Factory.java delete mode 100644 storage/sis-gdal/src/main/java/org/apache/sis/storage/gdal/Proj4Parser.java delete mode 100644 storage/sis-gdal/src/main/java/org/apache/sis/storage/gdal/Transform.java delete mode 100644 storage/sis-gdal/src/main/java/org/apache/sis/storage/gdal/package-info.java delete mode 100644 storage/sis-gdal/src/main/resources/META-INF/services/org.apache.sis.internal.referencing.SpecializedOperationFactory delete mode 100644 storage/sis-gdal/src/main/resources/META-INF/services/org.opengis.referencing.crs.CRSAuthorityFactory delete mode 100755
[jira] [Updated] (SIS-510) Remove sis-gdal module
[
https://issues.apache.org/jira/browse/SIS-510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-510:
Description:
Development and maintenance of GeoAPI wrappers for PROJ moved to a separated
project:
[https://github.com/Kortforsyningen/PROJ-JNI]
{color:#de350b}Edit (September 2021):{color} project moved to
[https://github.com/OSGeo/PROJ-JNI]
The PROJ native bindings in Apache SIS should be removed. Maybe we will
recreate that module in the future if we want to add GDAL bindings instead of
only PROJ, but current implementation did not reach that level. Furthermore the
[JEP 191: Foreign Function Interface|http://openjdk.java.net/jeps/191] may
change the way to do that. Alternatively we may also do this binding by
expanding above-cited Kortforsyningen project instead of doing this work in SIS.
was:
Development and maintenance of GeoAPI wrappers for PROJ moved to a separated
project:
[https://github.com/Kortforsyningen/PROJ-JNI]
{color:#de350b}*Edit (September 2021):*{color} project moved to
[https://github.com/OSGeo/PROJ-JNI]
The PROJ native bindings in Apache SIS should be removed. Maybe we will
recreate that module in the future if we want to add GDAL bindings instead of
only PROJ, but current implementation did not reach that level. Furthermore the
[JEP 191: Foreign Function Interface|http://openjdk.java.net/jeps/191] may
change the way to do that. Alternatively we may also do this binding by
expanding above-cited Kortforsyningen project instead of doing this work in SIS.
> Remove sis-gdal module
> --
>
> Key: SIS-510
> URL: https://issues.apache.org/jira/browse/SIS-510
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Referencing
>Affects Versions: 0.8, 1.0
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.1
>
>
> Development and maintenance of GeoAPI wrappers for PROJ moved to a separated
> project:
> [https://github.com/Kortforsyningen/PROJ-JNI]
> {color:#de350b}Edit (September 2021):{color} project moved to
> [https://github.com/OSGeo/PROJ-JNI]
> The PROJ native bindings in Apache SIS should be removed. Maybe we will
> recreate that module in the future if we want to add GDAL bindings instead of
> only PROJ, but current implementation did not reach that level. Furthermore
> the [JEP 191: Foreign Function Interface|http://openjdk.java.net/jeps/191]
> may change the way to do that. Alternatively we may also do this binding by
> expanding above-cited Kortforsyningen project instead of doing this work in
> SIS.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-510) Remove sis-gdal module
[
https://issues.apache.org/jira/browse/SIS-510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-510:
Description:
Development and maintenance of GeoAPI wrappers for PROJ moved to a separated
project:
[https://github.com/Kortforsyningen/PROJ-JNI]
{color:#de350b}*Edit (September 2021):*{color} project moved to
[https://github.com/OSGeo/PROJ-JNI]
The PROJ native bindings in Apache SIS should be removed. Maybe we will
recreate that module in the future if we want to add GDAL bindings instead of
only PROJ, but current implementation did not reach that level. Furthermore the
[JEP 191: Foreign Function Interface|http://openjdk.java.net/jeps/191] may
change the way to do that. Alternatively we may also do this binding by
expanding above-cited Kortforsyningen project instead of doing this work in SIS.
was:
Development and maintenance of GeoAPI wrappers for PROJ moved to a separated
project:
https://github.com/Kortforsyningen/PROJ-JNI
Note: above project may move to OSGeo organization if we have a volunteer for
doing the "administrative" work.
The PROJ native bindings in Apache SIS should be removed. Maybe we will
recreate that module in the future if we want to add GDAL bindings instead of
only PROJ, but current implementation did not reach that level. Furthermore the
[JEP 191: Foreign Function Interface|http://openjdk.java.net/jeps/191] may
change the way to do that. Alternatively we may also do this binding by
expanding above-cited Kortforsyningen project instead of doing this work in SIS.
> Remove sis-gdal module
> --
>
> Key: SIS-510
> URL: https://issues.apache.org/jira/browse/SIS-510
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Referencing
>Affects Versions: 0.8, 1.0
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.1
>
>
> Development and maintenance of GeoAPI wrappers for PROJ moved to a separated
> project:
> [https://github.com/Kortforsyningen/PROJ-JNI]
> {color:#de350b}*Edit (September 2021):*{color} project moved to
> [https://github.com/OSGeo/PROJ-JNI]
> The PROJ native bindings in Apache SIS should be removed. Maybe we will
> recreate that module in the future if we want to add GDAL bindings instead of
> only PROJ, but current implementation did not reach that level. Furthermore
> the [JEP 191: Foreign Function Interface|http://openjdk.java.net/jeps/191]
> may change the way to do that. Alternatively we may also do this binding by
> expanding above-cited Kortforsyningen project instead of doing this work in
> SIS.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-500) Deprecate (for removal) InterpolatedMolodenskyTransform
[
https://issues.apache.org/jira/browse/SIS-500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-500:
Fix Version/s: (was: 1.1)
Affects Version/s: 1.1
We postdone this task until the completion of OGC work on GGXF format. We will
wait to see if GGXF data make this class useful, if not we will deprecate it.
> Deprecate (for removal) InterpolatedMolodenskyTransform
> ---
>
> Key: SIS-500
> URL: https://issues.apache.org/jira/browse/SIS-500
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Referencing
>Affects Versions: 0.7, 0.8, 1.0, 1.1
>Reporter: Martin Desruisseaux
>Priority: Major
>
> {{InterpolatedMolodenskyTransform}} applies a transformation between two
> geographic CRS by performing geocentric translations interpolated from a grid
> file, but using Molodensky approximation. The errors caused by this
> approximation is greater than the intended precision of those grid files,
> which make the use of this class dubious Indeed,
> {{InterpolatedMolodenskyTransform}} is not used anywhere and should be
> removed. The class to use instead is {{InterpolatedGeocentricTransform}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (SIS-484) Avoid use of same package name in two different modules
[
https://issues.apache.org/jira/browse/SIS-484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux resolved SIS-484.
-
Resolution: Fixed
Moved {{InternationalString}} implementation classes to {{org.apache.sis.util}}
package. This is an anticipation for Jigsaw modularisation.
> Avoid use of same package name in two different modules
> ---
>
> Key: SIS-484
> URL: https://issues.apache.org/jira/browse/SIS-484
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Metadata, Referencing, Utilities
>Affects Versions: 1.0
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.1
>
>
> The following packages have classes defined by two different modules:
>
> * {{org.apache.sis.internal.simple}}
> * {{org.apache.sis.util.iso}}
> * {{org.apache.sis.metadata.iso}}
> The cases of {{metadata.iso}} is already solved on master branch. The case of
> {{internal.simple}} should be easy since it is about internal classes. The
> {{util.iso}} case may be the only problematic one.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[sis] 01/02: Record some "too aggressive simplification" problems that still need to be fixed.
This is an automated email from the ASF dual-hosted git repository.
desruisseaux pushed a commit to branch geoapi-4.0
in repository https://gitbox.apache.org/repos/asf/sis.git
commit c1eddc769657c37202075ffd19ac56e7d9ee1996
Author: Martin Desruisseaux
AuthorDate: Fri Sep 17 11:55:48 2021 +0200
Record some "too aggressive simplification" problems that still need to be
fixed.
https://issues.apache.org/jira/browse/SIS-378
---
.../java/org/apache/sis/measure/UnitFormatTest.java | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git
a/core/sis-utility/src/test/java/org/apache/sis/measure/UnitFormatTest.java
b/core/sis-utility/src/test/java/org/apache/sis/measure/UnitFormatTest.java
index bcbb3d7..3a7590e 100644
--- a/core/sis-utility/src/test/java/org/apache/sis/measure/UnitFormatTest.java
+++ b/core/sis-utility/src/test/java/org/apache/sis/measure/UnitFormatTest.java
@@ -644,6 +644,8 @@ public final strictfp class UnitFormatTest extends TestCase
{
/**
* Tests parsing of miscellaneous symbols, followed by formatting.
* This test uses some units defined by World Meteorological Organisation
(WMO).
+ * The lines with "Too aggressive simplification bug
(SIS-378)" comment are actually bugs,
+ * but they are tested anyway (despite the bogus "expected" value) for
tracking progresses on SIS-378.
*
* @see https://issues.apache.org/jira/browse/SIS-378;>SIS-378
*/
@@ -668,23 +670,31 @@ public final strictfp class UnitFormatTest extends
TestCase {
roundtrip(f, "μg.m-2", "µg∕m²");
roundtrip(f, "K.m-1","K∕m");
roundtrip(f, "W.m-2","W∕m²");
+roundtrip(f, "W.m-2.Hz-1", "kg∕s²"); // Too aggressive
simplification bug (SIS-378)
+roundtrip(f, "W.sr-1.m-2", "kg∕s³"); // Too aggressive
simplification bug (SIS-378)
+roundtrip(f, "W.m-1.sr-1", "W∕m");// Too aggressive
simplification bug (SIS-378)
+roundtrip(f, "W.m-3.sr-1", "W∕m³"); // Too aggressive
simplification bug (SIS-378)
+roundtrip(f, "N.m-1","N∕m");
roundtrip(f, "N.m-2","Pa");
roundtrip(f, "kg.m-2", "kg∕m²");
roundtrip(f, "kg.m-3", "kg∕m³");
roundtrip(f, "K*m.s-1", "K⋅m∕s");
roundtrip(f, "N.m-2.s", "Pa⋅s");
roundtrip(f, "K*m/s","K⋅m∕s");
-roundtrip(f, "kg/kg*Pa/s", "Pa∕s");
-roundtrip(f, "kg/kg*m/s","m∕s");
+roundtrip(f, "kg/kg*Pa/s", "Pa∕s"); // Too aggressive
simplification bug (SIS-378)
+roundtrip(f, "kg/kg*m/s","m∕s");// Too aggressive
simplification bug (SIS-378)
+roundtrip(f, "kg.kg-1.m.s-1","m∕s");// Too aggressive
simplification bug (SIS-378)
+roundtrip(f, "kg/kg*kg/kg", "kg∕kg"); // Too aggressive
simplification bug (SIS-378)
roundtrip(f, "day", "d");
roundtrip(f, "µg.m-3", "µg∕m³");
roundtrip(f, "Pa*Pa","Pa²");
-roundtrip(f, "N.m-1","N∕m");
roundtrip(f, "m-2.s-1", "1∕(m²⋅s)");
+roundtrip(f, "m-2.s.rad-1", "s∕m²"); // Too aggressive
simplification bug (SIS-378)
roundtrip(f, "°","°");
roundtrip(f, "K*Pa/s", "K⋅Pa∕s");
roundtrip(f, "kg.kg-1", "kg∕kg");
roundtrip(f, "m3.m-3", "m³∕m³");
+roundtrip(f, "m3.s-1.m-1", "m²∕s"); // Too aggressive
simplification bug (SIS-378)
roundtrip(f, "s.m-1","s∕m");
roundtrip(f, "V.m-1","V∕m");
roundtrip(f, "m2.s-2", "m²∕s²");
@@ -699,7 +709,10 @@ public final strictfp class UnitFormatTest extends
TestCase {
roundtrip(f, "rad.s-1", "rad∕s");
roundtrip(f, "(m2.s)^-1","1∕(m²⋅s)");
roundtrip(f, "(m2.s)-1", "1∕(m²⋅s)");
+roundtrip(f, "(m2.s.sr)-1", "1∕(m²⋅s)"); // Too aggressive
simplification bug (SIS-378)
+roundtrip(f, "(kg.m-3).(m.s-1)", "kg∕(m²⋅s)"); // Too aggressive
simplification bug (SIS-378)
roundtrip(f, "cm/day", "cm∕d");
+roundtrip(f, "W.m-2.nm-1", "10⁹⋅kg∕(m⋅s³)"); // Too aggressive
simplification bug (SIS-378)
}
/**
[sis] branch geoapi-4.0 updated (8ff80c8 -> 9d36a8d)
This is an automated email from the ASF dual-hosted git repository.
desruisseaux pushed a change to branch geoapi-4.0
in repository https://gitbox.apache.org/repos/asf/sis.git.
from 8ff80c8 Fix a “Missing value for tgt_semi_major parameter” error when
parsing coordinate operation from WKT.
new c1eddc7 Record some "too aggressive simplification" problems that
still need to be fixed.
new 9d36a8d Move `InternationalString` implementations to
`org.apache.sis.util` package. This is in anticipation for Jigsaw
modularization.
The 2 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
.../org/apache/sis/feature/CustomAttribute.java| 2 +-
.../org/apache/sis/feature/FeatureTestCase.java| 2 +-
.../builder/AssociationRoleBuilderTest.java| 2 +-
.../jaxb/gco/InternationalStringAdapter.java | 2 +-
.../jaxb/gco/InternationalStringConverter.java | 2 +-
.../apache/sis/internal/jaxb/gco/PropertyType.java | 2 +-
.../sis/internal/jaxb/gts/TM_PeriodDuration.java | 2 +-
.../apache/sis/internal/jaxb/lan/PT_FreeText.java | 4 +-
.../apache/sis/internal/simple/SimpleCitation.java | 2 +-
.../apache/sis/metadata/iso/DefaultMetadata.java | 2 +-
.../java/org/apache/sis/util/iso/AbstractName.java | 3 +-
.../org/apache/sis/util/iso/DefaultLocalName.java | 3 +-
.../apache/sis/util/iso/DefaultNameFactory.java| 2 +
.../org/apache/sis/util/iso/DefaultNameSpace.java | 1 +
.../main/java/org/apache/sis/util/iso/Types.java | 36 --
.../java/org/apache/sis/util/iso/package-info.java | 9 -
.../java/org/apache/sis/xml/MarshalContext.java| 2 +-
.../src/main/java/org/apache/sis/xml/XML.java | 2 +-
.../sis/internal/jaxb/gco/PropertyTypeTest.java| 2 +-
.../sis/internal/jaxb/gco/StringAdapterTest.java | 4 +-
.../internal/jaxb/lan/FreeTextMarshallingTest.java | 2 +-
.../java/org/apache/sis/metadata/HashCodeTest.java | 2 +-
.../apache/sis/metadata/MetadataStandardTest.java | 2 +-
.../sis/metadata/ModifiableMetadataTest.java | 2 +-
.../apache/sis/metadata/PropertyAccessorTest.java | 2 +-
.../apache/sis/metadata/TreeNodeChildrenTest.java | 2 +-
.../apache/sis/metadata/TreeTableFormatTest.java | 2 +-
.../java/org/apache/sis/metadata/ValueMapTest.java | 2 +-
.../sis/metadata/iso/CustomMetadataTest.java | 2 +-
.../sis/metadata/iso/DefaultMetadataTest.java | 2 +-
.../apache/sis/metadata/iso/MarshallingTest.java | 4 +-
.../metadata/iso/citation/DefaultCitationTest.java | 4 +-
.../metadata/iso/citation/HardCodedCitations.java | 2 +-
.../sis/metadata/iso/extent/DefaultExtentTest.java | 2 +-
.../iso/identification/DefaultKeywordsTest.java| 2 +-
.../metadata/iso/lineage/DefaultLineageTest.java | 2 +-
.../iso/lineage/DefaultProcessStepTest.java| 2 +-
.../maintenance/DefaultScopeDescriptionTest.java | 2 +-
.../iso/spatial/DefaultGeorectifiedTest.java | 2 +-
.../sis/metadata/sql/MetadataSourceTest.java | 2 +-
.../sis/util/iso/DefaultNameFactoryTest.java | 1 +
.../apache/sis/util/iso/DefaultScopedNameTest.java | 1 +
.../java/org/apache/sis/util/iso/TypesTest.java| 2 +
.../org/apache/sis/xml/XLinkMarshallingTest.java | 2 +-
.../test/java/org/apache/sis/xml/XLinkTest.java| 2 +-
.../internal/referencing/SignReversalComment.java | 2 +-
.../referencing/provider/SatelliteTracking.java| 2 +-
.../java/org/apache/sis/io/wkt/WKTDictionary.java | 2 +-
.../factory/CommonAuthorityFactory.java| 2 +-
.../factory/GeodeticAuthorityFactory.java | 2 +-
.../referencing/factory/sql/EPSGDataAccess.java| 2 +-
.../operation/DefaultOperationMethod.java | 2 +-
.../sis/referencing/ImmutableIdentifierTest.java | 2 +-
.../sis/referencing/NamedIdentifierTest.java | 2 +-
.../referencing/factory/AuthorityFactoryMock.java | 2 +-
.../apache/sis/test/integration/MetadataTest.java | 2 +-
.../sis/internal/converter/StringConverter.java| 2 +-
.../main/java/org/apache/sis/math/Statistics.java | 2 +-
.../main/java/org/apache/sis/setup/OptionKey.java | 2 +-
.../{iso => }/AbstractInternationalString.java | 16
.../util/{iso => }/DefaultInternationalString.java | 43 +++---
.../{iso => }/ResourceInternationalString.java | 7 ++--
.../util/{iso => }/SimpleInternationalString.java | 13 +++
.../apache/sis/util/collection/TableColumn.java| 2 +-
.../resources/ResourceInternationalString.java | 4 +-
.../apache/sis/util/resources/package-info.java| 2 +-
.../internal/converter/StringConverterTest.java| 2 +-
.../org/apache/sis/measure/UnitFormatTest.java | 19 --
.../apache/sis/test/suite/UtilityTestSuite.java| 4 +-
[sis] 02/02: Move `InternationalString` implementations to `org.apache.sis.util` package. This is in anticipation for Jigsaw modularization.
This is an automated email from the ASF dual-hosted git repository.
desruisseaux pushed a commit to branch geoapi-4.0
in repository https://gitbox.apache.org/repos/asf/sis.git
commit 9d36a8db813bad76195b5ab22c03f28538803341
Author: Martin Desruisseaux
AuthorDate: Fri Sep 17 12:57:21 2021 +0200
Move `InternationalString` implementations to `org.apache.sis.util` package.
This is in anticipation for Jigsaw modularization.
https://issues.apache.org/jira/browse/SIS-484
---
.../org/apache/sis/feature/CustomAttribute.java| 2 +-
.../org/apache/sis/feature/FeatureTestCase.java| 2 +-
.../builder/AssociationRoleBuilderTest.java| 2 +-
.../jaxb/gco/InternationalStringAdapter.java | 2 +-
.../jaxb/gco/InternationalStringConverter.java | 2 +-
.../apache/sis/internal/jaxb/gco/PropertyType.java | 2 +-
.../sis/internal/jaxb/gts/TM_PeriodDuration.java | 2 +-
.../apache/sis/internal/jaxb/lan/PT_FreeText.java | 4 +-
.../apache/sis/internal/simple/SimpleCitation.java | 2 +-
.../apache/sis/metadata/iso/DefaultMetadata.java | 2 +-
.../java/org/apache/sis/util/iso/AbstractName.java | 3 +-
.../org/apache/sis/util/iso/DefaultLocalName.java | 3 +-
.../apache/sis/util/iso/DefaultNameFactory.java| 2 +
.../org/apache/sis/util/iso/DefaultNameSpace.java | 1 +
.../main/java/org/apache/sis/util/iso/Types.java | 36 --
.../java/org/apache/sis/util/iso/package-info.java | 9 -
.../java/org/apache/sis/xml/MarshalContext.java| 2 +-
.../src/main/java/org/apache/sis/xml/XML.java | 2 +-
.../sis/internal/jaxb/gco/PropertyTypeTest.java| 2 +-
.../sis/internal/jaxb/gco/StringAdapterTest.java | 4 +-
.../internal/jaxb/lan/FreeTextMarshallingTest.java | 2 +-
.../java/org/apache/sis/metadata/HashCodeTest.java | 2 +-
.../apache/sis/metadata/MetadataStandardTest.java | 2 +-
.../sis/metadata/ModifiableMetadataTest.java | 2 +-
.../apache/sis/metadata/PropertyAccessorTest.java | 2 +-
.../apache/sis/metadata/TreeNodeChildrenTest.java | 2 +-
.../apache/sis/metadata/TreeTableFormatTest.java | 2 +-
.../java/org/apache/sis/metadata/ValueMapTest.java | 2 +-
.../sis/metadata/iso/CustomMetadataTest.java | 2 +-
.../sis/metadata/iso/DefaultMetadataTest.java | 2 +-
.../apache/sis/metadata/iso/MarshallingTest.java | 4 +-
.../metadata/iso/citation/DefaultCitationTest.java | 4 +-
.../metadata/iso/citation/HardCodedCitations.java | 2 +-
.../sis/metadata/iso/extent/DefaultExtentTest.java | 2 +-
.../iso/identification/DefaultKeywordsTest.java| 2 +-
.../metadata/iso/lineage/DefaultLineageTest.java | 2 +-
.../iso/lineage/DefaultProcessStepTest.java| 2 +-
.../maintenance/DefaultScopeDescriptionTest.java | 2 +-
.../iso/spatial/DefaultGeorectifiedTest.java | 2 +-
.../sis/metadata/sql/MetadataSourceTest.java | 2 +-
.../sis/util/iso/DefaultNameFactoryTest.java | 1 +
.../apache/sis/util/iso/DefaultScopedNameTest.java | 1 +
.../java/org/apache/sis/util/iso/TypesTest.java| 2 +
.../org/apache/sis/xml/XLinkMarshallingTest.java | 2 +-
.../test/java/org/apache/sis/xml/XLinkTest.java| 2 +-
.../internal/referencing/SignReversalComment.java | 2 +-
.../referencing/provider/SatelliteTracking.java| 2 +-
.../java/org/apache/sis/io/wkt/WKTDictionary.java | 2 +-
.../factory/CommonAuthorityFactory.java| 2 +-
.../factory/GeodeticAuthorityFactory.java | 2 +-
.../referencing/factory/sql/EPSGDataAccess.java| 2 +-
.../operation/DefaultOperationMethod.java | 2 +-
.../sis/referencing/ImmutableIdentifierTest.java | 2 +-
.../sis/referencing/NamedIdentifierTest.java | 2 +-
.../referencing/factory/AuthorityFactoryMock.java | 2 +-
.../apache/sis/test/integration/MetadataTest.java | 2 +-
.../sis/internal/converter/StringConverter.java| 2 +-
.../main/java/org/apache/sis/math/Statistics.java | 2 +-
.../main/java/org/apache/sis/setup/OptionKey.java | 2 +-
.../{iso => }/AbstractInternationalString.java | 16
.../util/{iso => }/DefaultInternationalString.java | 43 +++---
.../{iso => }/ResourceInternationalString.java | 7 ++--
.../util/{iso => }/SimpleInternationalString.java | 13 +++
.../apache/sis/util/collection/TableColumn.java| 2 +-
.../resources/ResourceInternationalString.java | 4 +-
.../apache/sis/util/resources/package-info.java| 2 +-
.../internal/converter/StringConverterTest.java| 2 +-
.../apache/sis/test/suite/UtilityTestSuite.java| 4 +-
.../org/apache/sis/util/CharSequencesTest.java | 1 -
.../{iso => }/DefaultInternationalStringTest.java | 2 +-
.../{iso => }/SimpleInternationalStringTest.java | 4 +-
.../sis/util/collection/TreeTableFormatTest.java | 2 +-
.../apache/sis/util/collection/TreeTablesTest.java | 2 +-
.../sis/storage/earthobservation/LandsatBand.java | 2 +-
[jira] [Assigned] (SIS-484) Avoid use of same package name in two different modules
[
https://issues.apache.org/jira/browse/SIS-484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux reassigned SIS-484:
---
Assignee: Martin Desruisseaux
> Avoid use of same package name in two different modules
> ---
>
> Key: SIS-484
> URL: https://issues.apache.org/jira/browse/SIS-484
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Metadata, Referencing, Utilities
>Affects Versions: 1.0
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.1
>
>
> The following packages have classes defined by two different modules:
>
> * {{org.apache.sis.internal.simple}}
> * {{org.apache.sis.util.iso}}
> * {{org.apache.sis.metadata.iso}}
> The cases of {{metadata.iso}} is already solved on master branch. The case of
> {{internal.simple}} should be easy since it is about internal classes. The
> {{util.iso}} case may be the only problematic one.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-442) Cache CRS.findOperation(…, areaOfInteret) when area of interest is non null
[
https://issues.apache.org/jira/browse/SIS-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-442:
Fix Version/s: (was: 1.1)
1.2
Affects Version/s: 1.1
1.0
> Cache CRS.findOperation(…, areaOfInteret) when area of interest is non null
> ---
>
> Key: SIS-442
> URL: https://issues.apache.org/jira/browse/SIS-442
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Referencing
>Affects Versions: 0.7, 0.8, 1.0, 1.1
>Reporter: Martin Desruisseaux
>Priority: Major
> Fix For: 1.2
>
>
> Calls to {{CRS.findOperation(sourceCRS, targetCRS, areaOfInterest)}}
> currently cache the {{CoordinateOperation}} only when {{areaOfInterest}} is
> null. It is hard to implement a general cache mechanism for all non-null area
> of interest, but we can implement an intermediate solution:
> # When {{EPSGFactory}} or {{CoordinateOperationRegistry}} detects that there
> is only one {{CoordinateOperation}} for given source and target CRS, it
> automatically adds some sentinel value in {{PositionalAccuracy}} metadata. It
> could be some internal sub-class.
> # When {{DefaultCoordinateOperationFactory}} sees above sentinel values, it
> allows caching even if {{areaOfInterest}} is non-null. Otherwise caching is
> enabled only if {{areaOfInterest}} is null, as today.
> # After this optimization has been implemented, we should search for
> occurrences of {{factory()}} in {{Envelopes}} and replace them by calls to
> {{Envelope.findOperation(Envelope, Envelope)}}.
> We could also take this opportunity for adding an information message if we
> detected may transformations for the same pair of CRS. Something like _"Note:
> many transformations are defined for this pair of referencing systems in
> different domains of validity."_
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-403) Upgrade org.apache.sis.test.integration.MetadataTest to ISO 19115-3
[
https://issues.apache.org/jira/browse/SIS-403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-403:
Fix Version/s: (was: 1.1)
Affects Version/s: 1.1
> Upgrade org.apache.sis.test.integration.MetadataTest to ISO 19115-3
> ---
>
> Key: SIS-403
> URL: https://issues.apache.org/jira/browse/SIS-403
> Project: Spatial Information Systems
> Issue Type: Sub-task
> Components: Metadata
>Affects Versions: 1.0, 1.1
>Reporter: Martin Desruisseaux
>Priority: Major
>
> The {{org.apache.sis.test.integration.MetadataTest}} class currently marshal
> and unmarshal metadata in the legacy ISO 19139:2007 format. This is partially
> because it includes {{VerticalCRS}} component, which requires GML 3.2. We
> should upgrade this class for testing both schema.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-411) GPX data store should implement WritableFeatureSet
[
https://issues.apache.org/jira/browse/SIS-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-411:
Fix Version/s: (was: 1.1)
1.2
Affects Version/s: 1.1
1.0
> GPX data store should implement WritableFeatureSet
> --
>
> Key: SIS-411
> URL: https://issues.apache.org/jira/browse/SIS-411
> Project: Spatial Information Systems
> Issue Type: New Feature
> Components: Storage
>Affects Versions: 0.8, 1.0, 1.1
>Reporter: Martin Desruisseaux
>Priority: Major
> Fix For: 1.2
>
>
> {{org.apache.sis.internal.storage.gpx.Store}} implement the {{FeatureSet}}
> interface. It also provides the following method:
> {code:java}
> public void write(Metadata metadata, Stream features)
> {code}
> but it does not yet matches any public API. We need to retrofit that method
> into the methods provided by {{WritableFeatureSet}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-401) Use of GML 3.2 implies the use of ISO 19139:2007 metadata
[
https://issues.apache.org/jira/browse/SIS-401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-401:
Fix Version/s: (was: 1.1)
1.2
Affects Version/s: 1.1
> Use of GML 3.2 implies the use of ISO 19139:2007 metadata
> -
>
> Key: SIS-401
> URL: https://issues.apache.org/jira/browse/SIS-401
> Project: Spatial Information Systems
> Issue Type: Sub-task
> Components: Metadata, Referencing
>Affects Versions: 1.0, 1.1
>Reporter: Martin Desruisseaux
>Priority: Major
> Fix For: 1.2
>
>
> The use of GML 3.2 implies the use of ISO 19139:2007 metadata for describing
> the extent, positional accuracy, identifiers, _etc._ For now (in Apache SIS
> 1.0), we use an {{\@UseLegacyMetadata}} annotations (internal API). When this
> annotation is found on the object to marshal, {{PooledMarshaller}}
> automatically set the metadata version to 2007. However this works only for
> the root element. If the user specifies another object which itself contains
> GML, this will not work.
> If we want this automatic selection of ISO 19139:2007 metadata to work no
> matter where the GML elements appear, we need a different approach. One
> possible approach is to update the {{org.apache.sis.internal.jaxb.Context}}
> state in a way similar to what we do for {{Locale}}. This can be done by
> addition the following constructor and modifying the {{push(…)}} method like
> below (only the main elements that are modified are shown below):
> {code:java}
> public final class Context extends MarshalContext {
> /**
> * The locale to use for marshalling, or {@code null} if no locale were
> explicitly specified.
> */
> private final Locale locale;
> /**
> * Creates a new context identical to the given parent except for the
> locale and bitmask.
> */
> private Context(final Context parent, final int bitMasks, final Locale
> locale) {
> this.bitMasks = bitMasks;
> this.locale= locale;
> this.timezone = parent.timezone;
> this.schemas = parent.schemas;
> this.versionGML= parent.versionGML;
> this.resolver = parent.resolver;
> this.converter = parent.converter;
> this.warningListener = parent.warningListener;
> this.identifiers = parent.identifiers;
> this.identifiedObjects = parent.identifiedObjects;
> this.previous = parent;
> }
> @Override
> public final Locale getLocale() {
> return locale;
> }
> /**
> * Sets the locale to the given value, optionally with additional bits to
> set.
> * The old locales and bit masks are remembered and will be restored by
> the next call to {@link #pull()}.
> * This method can be invoked when marshalling object that need to
> marshall their children in a different
> * locale, like below:
> *
> * {@preformat java
> * private void beforeMarshal(Marshaller marshaller) {
> * Context.push(0, language);
> * }
> *
> * private void afterMarshal(Marshaller marshaller) {
> * Context.pull();
> * }
> * }
> *
> * @param bitsToSet new bits to set, or 0 for no change.
> * @param locale the locale to set, or {@code null} for keeping the
> current locale.
> */
> public static void push(final int bitsToSet, Locale locale) {
> Context current = current();
> if (current != null) {
> if (locale == null) {
> locale = current.getLocale();
> }
> current = new Context(current, current.bitMasks | bitsToSet,
> locale);
> CURRENT.set(current);
> }
> }
> /**
> * Restores the locale which was used prior the call to {@link #push(int,
> Locale)}.
> */
> public static void pull() {
> final Context current = current();
> if (current != null) {
> CURRENT.set(current.previous);
> }
> }
> }
> {code}
> Then, in the {{org.apache.sis.referencing}} package:
> {code:java}
> public class AbstractIdentifiedObject implements IdentifiedObject {
> /**
> * Invoked by JAXB {@link javax.xml.bind.Marshaller} before this object
> is marshalled to XML.
> * This method sets the locale to be used for XML marshalling to the
> metadata language.
> */
> @SuppressWarnings("unused")
> private void beforeMarshal(final Marshaller marshaller) {
> Context.push(Context.LEGACY_METADATA, null);
> }
> /**
> * Invoked by JAXB {@link javax.xml.bind.Marshaller} after this object
> has been marshalled to
> * XML. This
[jira] [Updated] (SIS-400) Complete MarshallingTest and add UnmarshallingTest
[
https://issues.apache.org/jira/browse/SIS-400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-400:
Fix Version/s: (was: 1.1)
Affects Version/s: 1.1
> Complete MarshallingTest and add UnmarshallingTest
> --
>
> Key: SIS-400
> URL: https://issues.apache.org/jira/browse/SIS-400
> Project: Spatial Information Systems
> Issue Type: Sub-task
> Components: Metadata
>Affects Versions: 1.0, 1.1
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
>
> {{org.apache.sis.metadata.iso.MarshallingTest}} merely tests that marshalling
> a {{DefaultMetadata}} does not produce an exception. We need to improve the
> tests by comparing with expected documents in both legacy ISO 19139:2007 and
> new ISO 19115-3:2016 format. The XML documents produced by ImageMatters can
> be used as a starting point.
> Conversely, the {{UnmarshallingTest}} class on ImageMatters repository should
> be adapted and included in the test suite.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-393) Missing META-INF service declarations for authority factories
[
https://issues.apache.org/jira/browse/SIS-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-393:
Fix Version/s: (was: 1.1)
1.2
Affects Version/s: 1.1
1.0
> Missing META-INF service declarations for authority factories
> -
>
> Key: SIS-393
> URL: https://issues.apache.org/jira/browse/SIS-393
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Referencing
>Affects Versions: 0.7, 0.8, 1.0, 1.1
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.2
>
>
> The {{core/sis-referencing/src/main/resources/META-INF/services/}} directory
> registers a {{CRSAuthorityFactory}}, but not yet any {{CSAuthorityFactory}},
> {{DatumAuthorityFactory}} or {{CoordinateOperationAuthorityFactory}}. The
> later in particular would be useful for an easier access to the following
> method:
> {code:java}
> Set createFromCoordinateReferenceSystemCodes(String
> sourceCRS, String targetCRS)
> {code}
> The reason why authority factories other than {{CRSAuthorityFactory}} are not
> yet registered is because it is more convenient for Apache SIS to use a
> single instance for all kind of authority factories (for sharing the cache).
> This can be done more cleanly in Java 9 using the new {{ServiceLoader}}
> capability. In the meantime, users can get the factory with following code,
> which is unsafe, but should work at least with SIS 0.8:
> {code:java}
> CoordinateOperationAuthorityFactory factory =
> (CoordinateOperationAuthorityFactory) CRS.getAuthorityFactory("EPSG");
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-378) Too aggressive simplification of some units of measurement
[
https://issues.apache.org/jira/browse/SIS-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-378:
Description:
In the left column, some units used by the World Meteorological Organisation
(WMO). In the right column, the result of parsing with Apache SIS. Some
simplifications are too aggressive, in particular with dimensionless units like
radians. Some issues were fixed in Apache SIS 1.0 but we keep this issue open
because not all problems were resolved.
Test case: {{org.apache.sis.measure.UnitFormatTest.testParseAndFormat()}}.
|| WMO units || SIS 0.8 parsing|| SIS 0.8 || SIS 1.0 || SIS 1.1 ||
| K m2 kg-1 s-1 | K⋅m²∕(kg⋅s) | (/) | (/) | (/) |
|m m6 m-3 |m⁴ | (!) | (/) | (/) |
| Pa s-1 | kg∕(m⋅s³) | (!) | (/) | (/) |
| S m-1 | A²⋅s³∕(kg⋅m³) | (!) | (/) | (/) |
| kg kg-1 m s-1 | m∕s | (!) | (!) | (!) |
|m2/3 s-1 | 0.⋅m²∕s | (x) | (/) | (/) |
| J kg-1 | m²∕s² | (!) | (/) | (/) |
| mol mol-1 | | (!) | (/) | (/) |
| mol s-1 | mol∕s | (/) | (/) | (/) |
| K s-1 | K∕s | (/) | (/) | (/) |
| m s-1 | m∕s | (/) | (/) | (/) |
| m s-2 | m∕s² | (/) | (/) | (/) |
|Pa m | kg∕s² | (!) | (/) | (/) |
| m3 s-1 | m³∕s | (/) | (/) | (/) |
| kg m-2 s-1 | kg∕(m²⋅s) | (/) | (/) | (/) |
| μg m-3 | 1.0E-9⋅kg∕m³ | (!) | (/) | (/) |
| K m-1 | K∕m | (/) | (/) | (/) |
| W m-2 | kg∕s³ | (!) | (/) | (/) |
| N m-2 |Pa | (?) | (?) | (?) |
| (m2 s sr)-1 | -1⋅m²⋅s | (x) | (!) | (!) |
| kg m-2 | kg∕m² | (/) | (/) | (/) |
| kg m-3 | kg∕m³ | (/) | (/) | (/) |
| K*m s-1 | K⋅m∕s | (/) | (/) | (/) |
| cm/day | cm∕d | (!) | (/) | (/) |
| m-2 s rad-1 | s∕m² | (x) | (x) | (x) |
| N m-2 s | kg∕(m⋅s) | (!) | (?) | (?) |
| kg kg-1 s-1 |Hz | (x) | (x) | (x) |
| kg/kg*kg/kg | | (!) | (!) | (!) |
| K*m/s | K⋅m∕s | (/) | (/) | (/) |
| kg/kg*Pa/s | kg∕(m⋅s³) | (!) | (!) | (!) |
| kg/kg*m/s | m∕s | (!) | (!) | (!) |
| day | d | (/) | (/) | (/) |
| µg m-3 | 1.0E-9⋅kg∕m³ | (!) | (/) | (/) |
| Pa*Pa | kg²∕(m²⋅s⁴) | (!) | (/) | (/) |
| W m-2 Hz-1 | kg∕s² | (!) | (!) | (!) |
| W sr-1 m-2 | kg∕s³ | (x) | (x) | (x) |
| N m-1 | kg∕s² | (!) | (/) | (/) |
| W m-1 sr-1 | kg⋅m∕s³ | (x) | (x) | (x) |
| m-2 s-1 | ∕(m²⋅s) | (!) | (?) | (?) |
| ° | ° | (/) | (/) | (/) |
| kg kg-1 | | (!) | (/) | (/) |
| s m-1 | s∕m | (/) | (/) | (/) |
| W m-3 sr-1 | kg∕(m⋅s³) | (x) | (x) | (x) |
| K*Pa/s | K⋅kg∕(m⋅s³) | (!) | (/) | (/) |
| m3 m-3 | | (!) | (/) | (/) |
| V m-1 | kg⋅m∕(s³⋅A) | (!) | (/) | (/) |
| m2 s-2 | m²∕s² | (/) | (/) | (/) |
| m2 s-1 | m²∕s | (/) | (/) | (/) |
| mol m-3 |mol∕m³ | (/) | (/) | (/) |
| psu | psu | (/) | (/) | (/) |
| J m-2 | kg∕s² | (!) | (/) | (/) |
|kg-2 s-1 | ∕(kg²⋅s) | (!) | (?) | (?) |
| K*K |K² | (/) | (/) | (/) |
| kg m-3 s-1 | kg∕(m³⋅s) | (/) | (/) | (/) |
| m3 s-1 m-1 | m²∕s | (!) | (!) | (!) |
|(kg m-3) (m s-1) | kg∕(m²⋅s) | (!) | (!) | (!) |
| W m-2 nm-1 | 9.999E8⋅kg∕(m⋅s³) | (!) | (!) | (!) |
was:
In the left column, some units used by the World Meteorological Organisation
(WMO). In the right column, the result of parsing with Apache SIS. Some
[jira] [Commented] (SIS-378) Too aggressive simplification of some units of measurement
[ https://issues.apache.org/jira/browse/SIS-378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17416599#comment-17416599 ] Martin Desruisseaux commented on SIS-378: - Some issues were fixed in SIS 1.0, but we keep this issue open because there is remaining too aggressive simplifications. > Too aggressive simplification of some units of measurement > -- > > Key: SIS-378 > URL: https://issues.apache.org/jira/browse/SIS-378 > Project: Spatial Information Systems > Issue Type: Bug > Components: Utilities >Affects Versions: 0.8 >Reporter: Martin Desruisseaux >Assignee: Martin Desruisseaux >Priority: Major > Fix For: 1.0 > > > In the left column, some units used by the World Meteorological Organisation > (WMO). In the right column, the result of parsing with Apache SIS. Some > simplifications are too aggressive, in particular with dimensionless units > like radians. > || WMO units || SIS 0.8 parsing|| SIS 0.8 || SIS 1.0 || SIS 1.1 || > | K m2 kg-1 s-1 | K⋅m²∕(kg⋅s) | (/) | (/) | (/) | > |m m6 m-3 |m⁴ | (!) | (/) | (/) | > | Pa s-1 | kg∕(m⋅s³) | (!) | (/) | (/) | > | S m-1 | A²⋅s³∕(kg⋅m³) | (!) | (/) | (/) | > | kg kg-1 m s-1 | m∕s | (!) | (!) | (!) | > |m2/3 s-1 | 0.⋅m²∕s | (x) | (/) | (/) | > | J kg-1 | m²∕s² | (!) | (/) | (/) | > | mol mol-1 | | (!) | (/) | (/) | > | mol s-1 | mol∕s | (/) | (/) | (/) | > | K s-1 | K∕s | (/) | (/) | (/) | > | m s-1 | m∕s | (/) | (/) | (/) | > | m s-2 | m∕s² | (/) | (/) | (/) | > |Pa m | kg∕s² | (!) | (/) | (/) | > | m3 s-1 | m³∕s | (/) | (/) | (/) | > | kg m-2 s-1 | kg∕(m²⋅s) | (/) | (/) | (/) | > | μg m-3 | 1.0E-9⋅kg∕m³ | (!) | (/) | (/) | > | K m-1 | K∕m | (/) | (/) | (/) | > | W m-2 | kg∕s³ | (!) | (/) | (/) | > | N m-2 |Pa | (?) | (?) | (?) | > | (m2 s sr)-1 | -1⋅m²⋅s | (x) | (!) | (!) | > | kg m-2 | kg∕m² | (/) | (/) | (/) | > | kg m-3 | kg∕m³ | (/) | (/) | (/) | > | K*m s-1 | K⋅m∕s | (/) | (/) | (/) | > | cm/day | cm∕d | (!) | (/) | (/) | > | m-2 s rad-1 | s∕m² | (x) | (x) | (x) | > | N m-2 s | kg∕(m⋅s) | (!) | (?) | (?) | > | kg kg-1 s-1 |Hz | (x) | (x) | (x) | > | kg/kg*kg/kg | | (!) | (!) | (!) | > | K*m/s | K⋅m∕s | (/) | (/) | (/) | > | kg/kg*Pa/s | kg∕(m⋅s³) | (!) | (!) | (!) | > | kg/kg*m/s | m∕s | (!) | (!) | (!) | > | day | d | (/) | (/) | (/) | > | µg m-3 | 1.0E-9⋅kg∕m³ | (!) | (/) | (/) | > | Pa*Pa | kg²∕(m²⋅s⁴) | (!) | (/) | (/) | > | W m-2 Hz-1 | kg∕s² | (!) | (!) | (!) | > | W sr-1 m-2 | kg∕s³ | (x) | (x) | (x) | > | N m-1 | kg∕s² | (!) | (/) | (/) | > | W m-1 sr-1 | kg⋅m∕s³ | (x) | (x) | (x) | > | m-2 s-1 | ∕(m²⋅s) | (!) | (?) | (?) | > | ° | ° | (/) | (/) | (/) | > | kg kg-1 | | (!) | (/) | (/) | > | s m-1 | s∕m | (/) | (/) | (/) | > | W m-3 sr-1 | kg∕(m⋅s³) | (x) | (x) | (x) | > | K*Pa/s | K⋅kg∕(m⋅s³) | (!) | (/) | (/) | > | m3 m-3 | | (!) | (/) | (/) | > | V m-1 | kg⋅m∕(s³⋅A) | (!) | (/) | (/) | > | m2 s-2 | m²∕s² | (/) | (/) | (/) | > | m2 s-1 | m²∕s | (/) | (/) | (/) | > | mol m-3 |mol∕m³ | (/) | (/) | (/) | > | psu | psu | (/) | (/) | (/) | > | J m-2 | kg∕s² | (!) | (/) | (/) | > |kg-2 s-1 |
[jira] [Updated] (SIS-378) Too aggressive simplification of some units of measurement
[ https://issues.apache.org/jira/browse/SIS-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux updated SIS-378: Fix Version/s: (was: 1.1) Description: In the left column, some units used by the World Meteorological Organisation (WMO). In the right column, the result of parsing with Apache SIS. Some simplifications are too aggressive, in particular with dimensionless units like radians. || WMO units || SIS 0.8 parsing|| SIS 0.8 || SIS 1.0 || SIS 1.1 || | K m2 kg-1 s-1 | K⋅m²∕(kg⋅s) | (/) | (/) | (/) | |m m6 m-3 |m⁴ | (!) | (/) | (/) | | Pa s-1 | kg∕(m⋅s³) | (!) | (/) | (/) | | S m-1 | A²⋅s³∕(kg⋅m³) | (!) | (/) | (/) | | kg kg-1 m s-1 | m∕s | (!) | (!) | (!) | |m2/3 s-1 | 0.⋅m²∕s | (x) | (/) | (/) | | J kg-1 | m²∕s² | (!) | (/) | (/) | | mol mol-1 | | (!) | (/) | (/) | | mol s-1 | mol∕s | (/) | (/) | (/) | | K s-1 | K∕s | (/) | (/) | (/) | | m s-1 | m∕s | (/) | (/) | (/) | | m s-2 | m∕s² | (/) | (/) | (/) | |Pa m | kg∕s² | (!) | (/) | (/) | | m3 s-1 | m³∕s | (/) | (/) | (/) | | kg m-2 s-1 | kg∕(m²⋅s) | (/) | (/) | (/) | | μg m-3 | 1.0E-9⋅kg∕m³ | (!) | (/) | (/) | | K m-1 | K∕m | (/) | (/) | (/) | | W m-2 | kg∕s³ | (!) | (/) | (/) | | N m-2 |Pa | (?) | (?) | (?) | | (m2 s sr)-1 | -1⋅m²⋅s | (x) | (!) | (!) | | kg m-2 | kg∕m² | (/) | (/) | (/) | | kg m-3 | kg∕m³ | (/) | (/) | (/) | | K*m s-1 | K⋅m∕s | (/) | (/) | (/) | | cm/day | cm∕d | (!) | (/) | (/) | | m-2 s rad-1 | s∕m² | (x) | (x) | (x) | | N m-2 s | kg∕(m⋅s) | (!) | (?) | (?) | | kg kg-1 s-1 |Hz | (x) | (x) | (x) | | kg/kg*kg/kg | | (!) | (!) | (!) | | K*m/s | K⋅m∕s | (/) | (/) | (/) | | kg/kg*Pa/s | kg∕(m⋅s³) | (!) | (!) | (!) | | kg/kg*m/s | m∕s | (!) | (!) | (!) | | day | d | (/) | (/) | (/) | | µg m-3 | 1.0E-9⋅kg∕m³ | (!) | (/) | (/) | | Pa*Pa | kg²∕(m²⋅s⁴) | (!) | (/) | (/) | | W m-2 Hz-1 | kg∕s² | (!) | (!) | (!) | | W sr-1 m-2 | kg∕s³ | (x) | (x) | (x) | | N m-1 | kg∕s² | (!) | (/) | (/) | | W m-1 sr-1 | kg⋅m∕s³ | (x) | (x) | (x) | | m-2 s-1 | ∕(m²⋅s) | (!) | (?) | (?) | | ° | ° | (/) | (/) | (/) | | kg kg-1 | | (!) | (/) | (/) | | s m-1 | s∕m | (/) | (/) | (/) | | W m-3 sr-1 | kg∕(m⋅s³) | (x) | (x) | (x) | | K*Pa/s | K⋅kg∕(m⋅s³) | (!) | (/) | (/) | | m3 m-3 | | (!) | (/) | (/) | | V m-1 | kg⋅m∕(s³⋅A) | (!) | (/) | (/) | | m2 s-2 | m²∕s² | (/) | (/) | (/) | | m2 s-1 | m²∕s | (/) | (/) | (/) | | mol m-3 |mol∕m³ | (/) | (/) | (/) | | psu | psu | (/) | (/) | (/) | | J m-2 | kg∕s² | (!) | (/) | (/) | |kg-2 s-1 | ∕(kg²⋅s) | (!) | (?) | (?) | | K*K |K² | (/) | (/) | (/) | | kg m-3 s-1 | kg∕(m³⋅s) | (/) | (/) | (/) | | m3 s-1 m-1 | m²∕s | (!) | (!) | (!) | |(kg m-3) (m s-1) | kg∕(m²⋅s) | (!) | (!) | (!) | | W m-2 nm-1 | 9.999E8⋅kg∕(m⋅s³) | (!) | (!) | (!) | was: In the left column, some units used by the World Meteorological Organisation (WMO). In the right column, the result of parsing with Apache SIS. Some simplifications are too aggressive, in particular with dimensionless units like radians. || WMO units || SIS 0.8 parsing || SIS 0.8 || SIS 1.0 || | K
[jira] [Updated] (SIS-361) NetCDF to ISO 19115:2014 mapping
[
https://issues.apache.org/jira/browse/SIS-361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-361:
Fix Version/s: (was: 1.1)
1.2
Affects Version/s: 1.1
1.0
> NetCDF to ISO 19115:2014 mapping
>
>
> Key: SIS-361
> URL: https://issues.apache.org/jira/browse/SIS-361
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Storage
>Affects Versions: 0.5, 0.6, 0.7, 0.8, 1.0, 1.1
>Reporter: Martin Desruisseaux
>Priority: Major
> Fix For: 1.2
>
>
> The {{org.org.apache.sis.storage.netcdf.AttributeNames}} class defines a
> mapping from NetCDF attributes to ISO 19115:2003 metadata. This mapping is
> defined by the following file:
> *
> https://github.com/Unidata/threddsIso/blob/master/src/main/resources/xsl/nciso/UnidataDD2MI.xsl
> However as of June 2017, this file seems to have been defined for a mapping
> to the 2003 version of ISO 19115. A mapping to the ISO 19115 revision
> published in 2014 could make some difference. This task enumerate some
> possible changes. Ideally, those changes should be submitted to the UCAR
> community. Whether Apache SIS should apply them on its own or not is an open
> question.
> h2. ACDD {{history}} attribute
> The NetCDF {{history}} attribute is documented as "Provides an audit trail
> for modifications to the original data". It is currently indirectly mapped to
> data quality information, which is defined in ISO 19115 as "overall
> assessment of quality of a resource(s)":
> {noformat}
> Metadata.dataQualityInfo.lineage.statement = $history
> Metadata.dataQualityInfo.scope.level = dataset
> {noformat}
> Since ISO 19115:2014, we could use the following instead. Documentation said
> "Information about the provenance, sources and/or the production processes
> applied to the resource", which seems more appropriate:
> {noformat}
> Metadata.resourceLineage.statement = $history
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-342) Support temporal CRS in URL
[
https://issues.apache.org/jira/browse/SIS-342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-342:
Fix Version/s: (was: 1.1)
1.2
Affects Version/s: 1.1
1.0
> Support temporal CRS in URL
> ---
>
> Key: SIS-342
> URL: https://issues.apache.org/jira/browse/SIS-342
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Referencing
>Affects Versions: 0.6, 0.7, 0.8, 1.0, 1.1
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.2
>
>
> The {{CRS.forCode(String)}} method supports CRS defined in the OGC namespace,
> but currently only for geographic or projected CRS. We need to support also
> temporal CRS like below:
> {noformat}
> http://http://www.opengis.net/def/crs/OGC/0/AnsiDate
> {noformat}
> Candidates for inclusion are:
> * AnsiDate
> * JulianDate
> * TruncatedJulianDate
> * UnixTime
> * ChronometricGeologicTime
> The list can be viewed from http://www.opengis.net/def/crs/OGC/0.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-212) Coordinate operation methods to implement
[
https://issues.apache.org/jira/browse/SIS-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-212:
Fix Version/s: 1.2
> Coordinate operation methods to implement
> -
>
> Key: SIS-212
> URL: https://issues.apache.org/jira/browse/SIS-212
> Project: Spatial Information Systems
> Issue Type: New Feature
> Components: Referencing
>Affects Versions: 0.6, 0.7, 0.8, 1.0, 1.1
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Labels: gsoc2016, gsoc2017, gsoc2021, java, mentor
> Fix For: 0.6, 0.7, 0.8, 1.0, 1.1, 1.2
>
>
> This is an umbrella task for some coordinate operation methods not yet
> supported in Apache SIS. Coordinate operations include _map projections_
> (e.g. Transverse Mercator, Lambert Conic Conformal, _etc._), _datum shifts_
> (e.g. transformations from NAD27 to NAD83 in United States), transformation
> of vertical coordinates, _etc_. We can of course not list all possible
> formulas that we do not support, but this JIRA task lists at least some of
> the operations listed in the EPSG guidance notes.
> The main material for this work is the EPSG guidance notes, which can be
> downloaded freely from the following site:
> {panel}
> IOGP Publication 373-7-2 – Geomatics Guidance Note number 7, part 2
> Coordinate Conversions and Transformations including Formulas
> http://www.epsg.org/GuidanceNotes
> {panel}
> Google summer of code students interested in this work would need to be
> reasonably comfortable with the Java language (but not necessarily with the
> JDK library at large, since this work uses relatively few JDK classes outside
> {{Math}}), and in mathematic. In particular, this work requires a good
> understanding of _affine transforms_: their representation as a matrix, and
> how to map a term in a formula to a coefficient in the affine transform
> matrix.
> Apache SIS has one advanced feature which is not easily found in popular
> geospatial software or text books: the capability to compute the _derivative_
> (or more precisely, the _Jacobian_) of a transformation at a given point.
> Implementation of this feature requires the capability to find the analytic
> derivative of a non-linear formula and to simplify it.
> Implementations of those formulas take place in one of the
> {{org.apache.sis.referencing.operation}} sub-packages ({{projection}} or
> {{transform}}). Implementations of JUnit test happen partially in Apache SIS,
> and partially in the ["conformance module" of the GeoAPI
> project|http://www.geoapi.org/geoapi-conformance/index.html], if possible
> through the Geospatial Integrity of Geoscience Software (GIGS) tests.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-86) Refactor @Configuration annotation into a real Configuration class
[
https://issues.apache.org/jira/browse/SIS-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-86:
---
Fix Version/s: (was: 1.1)
1.2
> Refactor @Configuration annotation into a real Configuration class
> --
>
> Key: SIS-86
> URL: https://issues.apache.org/jira/browse/SIS-86
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Utilities
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.2
>
>
> The {{@Configuration}} annotation is currently for identifying various static
> method having a system-wide effect. We may consider regrouping all such
> methods in a central place, maybe in a new {{org.apache.sis.setup}} package.
> We could provide pre-defined configuration profiles, including:
> * {{STRICT}} - maximal level of strictness (duplicated values cause parsing
> errors, Bursa-Wolf parameters mandatory for datum shifts, _etc._).
> * {{DEFAULT}} - the default setting as a compromise between {{STRICT}} and
> {{LENIENT}}: duplicated values just produce warnings, but datum shifts still
> require Bursa-Wolf parameters.
> * {{LENIENT}} - still working even if the accuracy may be compromise (e.g.
> apply datum shifts even in the absence of Bursa-Wolf parameters).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-162) Provide an AbstractCRS.subCRS(int lower, int upper) method
[
https://issues.apache.org/jira/browse/SIS-162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-162:
Fix Version/s: (was: 1.1)
1.2
> Provide an AbstractCRS.subCRS(int lower, int upper) method
> --
>
> Key: SIS-162
> URL: https://issues.apache.org/jira/browse/SIS-162
> Project: Spatial Information Systems
> Issue Type: New Feature
> Components: Referencing
>Reporter: Martin Desruisseaux
>Priority: Major
> Fix For: 1.2
>
>
> We need some way to get the components of a spatio-temporal CRS over a range
> of indices. In Geotk we were used to provide a static {{CRS.getSubCRS(…)}}
> method. For Apache SIS, we should consider a member method in the
> {{AbstractCRS}} class instead. Reasons are:
> * Would allow caching (by generalizing the existing {{derived}} private map).
> * Implementation depends on the coordinate system and CRS type.
> In particular, getting the two-dimensional (_latitude_, _longitude_) part of
> a three-dimensional {{GeographicCRS}} is a common operation. It would be nice
> if SIS were able to find the instance declared in EPSG database. However
> since it would be a relatively costly operation, this would justify caching
> the result.
> h3. Implementation plan
> We may need to start the work in the coordinate system package:
> * Sub CS of a {{CartesianCS}} can be an other {{CartesianCS}}.
> * Sub CS of a {{SphericalCS}} or a {{CylindricalCS}} can be a {{PolarCS}}.
> In the CRS package, the {{CompoundCRS}}, {{GeographicCRS}} and
> {{EngineeringCRS}} among others would probably have their custom {{subCRS}}
> method implementation. The {{GeographicCRS}} special case handled by
> {{CRS.getHorizontalComponent(…)}} and {{CRS.getVerticalComponent(…)}} would
> need to move in some SIS internal package in order to allow
> {{DefaultGeographicCRS}} to share it. The same warning about ellipsoidal
> height would apply, so the actual method signature may be:
> {code:java}
> public AbstractCRS subCRS(int lower, int upper, boolean
> allowCreateEllipsoidalHeight);
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (SIS-512) Can't create transformation from wkt
[
https://issues.apache.org/jira/browse/SIS-512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux resolved SIS-512.
-
Resolution: Fixed
Fixed in commit `8ff80c89f1e9aa8748d68e0f0e37bc0cc5ad5810`.
> Can't create transformation from wkt
>
>
> Key: SIS-512
> URL: https://issues.apache.org/jira/browse/SIS-512
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Referencing
>Affects Versions: 1.0
>Reporter: Michael Arneson
>Assignee: Martin Desruisseaux
>Priority: Critical
> Fix For: 1.1
>
>
> We are unable to create a _CoordinateOperation_ from the WKT that comes from
> an existing _CoordinateOperation_ object.
> The code below can be used to test this:
>
> _CoordinateOperationAuthorityFactory opFactory =
> (CoordinateOperationAuthorityFactory) CRS.getAuthorityFactory("EPSG");_
> _CoordinateOperation opFromCode =
> opFactory.createCoordinateOperation("5630");_
> _String operationWKT = opFromCode.toWKT();
> WKTFormat wf = new WKTFormat(null, null);
> CoordinateOperation opFromWKT = (CoordinateOperation)
> wf.parseObject(operationWKT);_
>
> When trying to execute this code the following error is returned:
>
> org.apache.sis.io.wkt.UnparsableObjectException: Error in
> “COORDINATEOPERATION”: Missing value for “tgt_semi_major” parameter.
> at org.apache.sis.io.wkt.Element.parseFailed(Element.java:383)
> at
> org.apache.sis.io.wkt.GeodeticObjectParser.parseOperation(GeodeticObjectParser.java:2279)
> at
> org.apache.sis.io.wkt.GeodeticObjectParser.parseObject(GeodeticObjectParser.java:306)
> at org.apache.sis.io.wkt.AbstractParser.parseObject(AbstractParser.java:283)
> at
> org.apache.sis.io.wkt.GeodeticObjectParser.parseObject(GeodeticObjectParser.java:244)
> at org.apache.sis.io.wkt.WKTFormat.parse(WKTFormat.java:753)
> at org.apache.sis.io.CompoundFormat.parseObject(CompoundFormat.java:317)
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[sis] 01/02: Bug fix in Lanczos optimisation: first row of pixel values in the "interpolation window" were not correctly used.
This is an automated email from the ASF dual-hosted git repository.
desruisseaux pushed a commit to branch geoapi-4.0
in repository https://gitbox.apache.org/repos/asf/sis.git
commit 68351864053fdf305a055bb3b1845d9c70514476
Author: Martin Desruisseaux
AuthorDate: Fri Sep 17 10:05:40 2021 +0200
Bug fix in Lanczos optimisation: first row of pixel values in the
"interpolation window" were not correctly used.
---
.../org/apache/sis/image/LanczosInterpolation.java | 32 ++
.../org/apache/sis/image/InterpolationTest.java| 22 +--
2 files changed, 40 insertions(+), 14 deletions(-)
diff --git
a/core/sis-feature/src/main/java/org/apache/sis/image/LanczosInterpolation.java
b/core/sis-feature/src/main/java/org/apache/sis/image/LanczosInterpolation.java
index 3a0bdca..8c238a8 100644
---
a/core/sis-feature/src/main/java/org/apache/sis/image/LanczosInterpolation.java
+++
b/core/sis-feature/src/main/java/org/apache/sis/image/LanczosInterpolation.java
@@ -86,6 +86,7 @@ final class LanczosInterpolation implements Interpolation {
public void interpolate(final DoubleBuffer source, final int numBands,
final double xfrac, final double yfrac, final double[] writeTo,
final int writeToOffset)
{
+source.mark();
/*
* Lanczos kernel coefficients, pre-computed because reused many
times. We store them in a temporary array
* created in this method; we do not reuse a cached array because this
method will be invoked concurrently
@@ -112,6 +113,15 @@ final class LanczosInterpolation implements Interpolation {
siny = Math.sin(yp);
kx[0] = kernel(xp, sinx);
ky= kernel(yp, siny);
+/*
+ * Multiply pixel values by Lanczos kernel coefficients. This is
the first
+ * iteration of the loop after this block, unrolled for using the
existing
+ * `ky` value and for overwritten existing values in the
destination array.
+ */
+double k = kx[0] * ky;
+for (int b=0; bx coordinate in the source image.
- * @param y y coordinate in the source image.
+ * @param x x coordinate in the source image, from
{@value #XMIN} to {@value #XUP} (exclusive).
+ * @param y y coordinate in the source image, from
{@value #YMIN} to {@value #YUP} (exclusive).
* @param expected the expected value.
*/
private void assertResultEquals(double x, double y, final double expected)
{
[sis] 02/02: Fix a “Missing value for tgt_semi_major parameter” error when parsing coordinate operation from WKT.
This is an automated email from the ASF dual-hosted git repository.
desruisseaux pushed a commit to branch geoapi-4.0
in repository https://gitbox.apache.org/repos/asf/sis.git
commit 8ff80c89f1e9aa8748d68e0f0e37bc0cc5ad5810
Author: Martin Desruisseaux
AuthorDate: Fri Sep 17 10:53:55 2021 +0200
Fix a “Missing value for tgt_semi_major parameter” error when parsing
coordinate operation from WKT.
https://issues.apache.org/jira/browse/SIS-512
---
.../internal/referencing/CoordinateOperations.java | 2 +-
.../internal/referencing/ReferencingUtilities.java | 35 ++
.../referencing/factory/sql/EPSGDataAccess.java| 10 +--
.../operation/AbstractSingleOperation.java | 19 ++--
.../referencing/operation/DefaultConversion.java | 8 ++---
.../DefaultCoordinateOperationFactory.java | 15 +-
.../org/apache/sis/io/wkt/ComparisonWithEPSG.java | 31 ---
7 files changed, 86 insertions(+), 34 deletions(-)
diff --git
a/core/sis-referencing/src/main/java/org/apache/sis/internal/referencing/CoordinateOperations.java
b/core/sis-referencing/src/main/java/org/apache/sis/internal/referencing/CoordinateOperations.java
index bd4e063..349d999 100644
---
a/core/sis-referencing/src/main/java/org/apache/sis/internal/referencing/CoordinateOperations.java
+++
b/core/sis-referencing/src/main/java/org/apache/sis/internal/referencing/CoordinateOperations.java
@@ -283,7 +283,7 @@ public final class CoordinateOperations extends
SystemListener {
}
}
/*
- * No existing instance found. Expand the 'changes' bit mask in an
array of integers in order to create an
+ * No existing instance found. Expand the `changes` bit mask in an
array of integers in order to create an
* unmodifiable List. The list is for public API; internally,
Apache SIS will use toBitMask(…).
*/
long r = changes;
diff --git
a/core/sis-referencing/src/main/java/org/apache/sis/internal/referencing/ReferencingUtilities.java
b/core/sis-referencing/src/main/java/org/apache/sis/internal/referencing/ReferencingUtilities.java
index ebd7443..3df50b8 100644
---
a/core/sis-referencing/src/main/java/org/apache/sis/internal/referencing/ReferencingUtilities.java
+++
b/core/sis-referencing/src/main/java/org/apache/sis/internal/referencing/ReferencingUtilities.java
@@ -25,8 +25,10 @@ import org.opengis.annotation.UML;
import org.opengis.annotation.Specification;
import org.opengis.metadata.Identifier;
import org.opengis.metadata.citation.Citation;
+import org.opengis.parameter.ParameterValueGroup;
import org.opengis.parameter.ParameterDescriptorGroup;
import org.opengis.parameter.GeneralParameterDescriptor;
+import org.opengis.util.FactoryException;
import org.opengis.referencing.cs.*;
import org.opengis.referencing.crs.*;
import org.opengis.referencing.IdentifiedObject;
@@ -36,6 +38,8 @@ import org.opengis.referencing.datum.PrimeMeridian;
import org.opengis.referencing.datum.GeodeticDatum;
import org.opengis.referencing.datum.VerticalDatum;
import org.opengis.referencing.datum.VerticalDatumType;
+import org.opengis.referencing.operation.MathTransform;
+import org.opengis.referencing.operation.MathTransformFactory;
import org.apache.sis.util.Static;
import org.apache.sis.util.Classes;
import org.apache.sis.util.Utilities;
@@ -49,6 +53,7 @@ import org.apache.sis.referencing.datum.DefaultPrimeMeridian;
import org.apache.sis.referencing.crs.DefaultGeographicCRS;
import org.apache.sis.referencing.cs.AxesConvention;
import org.apache.sis.referencing.cs.DefaultEllipsoidalCS;
+import
org.apache.sis.referencing.operation.transform.DefaultMathTransformFactory;
import
org.apache.sis.referencing.operation.transform.DefaultMathTransformFactory.Context;
import static java.util.Collections.singletonMap;
@@ -534,6 +539,36 @@ public final class ReferencingUtilities extends Static {
}
/**
+ * Substitute for the deprecated {@link
MathTransformFactory#createBaseToDerived createBaseToDerived(…)} method.
+ * This substitute use the full {@code targetCRS} instead of only the
coordinate system of the target.
+ * This is needed for setting the {@code "tgt_semi_minor"} and {@code
"tgt_semi_major"} parameters of
+ * Molodensky transformation for example.
+ *
+ * @param factory the factory to use for creating the transform.
+ * @param sourceCRS the source (base) coordinate reference system.
+ * @param parameters the parameter values for the transform.
+ * @param targetCRS the target (derived) coordinate system.
+ * @return the parameterized transform from {@code sourceCRS} to {@code
targetCRS},
+ * including unit conversions and axis swapping.
+ * @throws FactoryException if the object creation failed. This exception
is thrown
+ * if some required parameter has not been supplied, or has
illegal value.
+ *
+
[sis] branch geoapi-4.0 updated (e354739 -> 8ff80c8)
This is an automated email from the ASF dual-hosted git repository. desruisseaux pushed a change to branch geoapi-4.0 in repository https://gitbox.apache.org/repos/asf/sis.git. from e354739 Minor cleanup following the port of `org.apache.sis.measure` to Seshat. new 6835186 Bug fix in Lanczos optimisation: first row of pixel values in the "interpolation window" were not correctly used. new 8ff80c8 Fix a “Missing value for tgt_semi_major parameter” error when parsing coordinate operation from WKT. The 2 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .../org/apache/sis/image/LanczosInterpolation.java | 32 +--- .../org/apache/sis/image/InterpolationTest.java| 22 -- .../internal/referencing/CoordinateOperations.java | 2 +- .../internal/referencing/ReferencingUtilities.java | 35 ++ .../referencing/factory/sql/EPSGDataAccess.java| 10 +-- .../operation/AbstractSingleOperation.java | 19 ++-- .../referencing/operation/DefaultConversion.java | 8 ++--- .../DefaultCoordinateOperationFactory.java | 15 +- .../org/apache/sis/io/wkt/ComparisonWithEPSG.java | 31 --- 9 files changed, 126 insertions(+), 48 deletions(-)
[jira] [Updated] (SIS-84) Setter methods in metadata objects shall check for ISO 19115 constraints
[
https://issues.apache.org/jira/browse/SIS-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-84:
---
Fix Version/s: (was: 1.1)
1.2
Affects Version/s: 1.1
1.0
> Setter methods in metadata objects shall check for ISO 19115 constraints
>
>
> Key: SIS-84
> URL: https://issues.apache.org/jira/browse/SIS-84
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Metadata
>Affects Versions: 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 1.0, 1.1
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.2
>
>
> Setter methods in {{ISOMetadata}} subclasses shall enforce the ISO 19115
> restriction. This include:
> * Everywhere a {{@ValueRange}} annotation is present, add a runtime check for
> the same range of values.
> * For every property flagged as {{CONDITIONAL}} for a reason other than
> union, implement a check for that reason (case-by-case basis). For example:
> ** {{MD_ExtendedElementInformation}} allows a non-null {{domainCode}} only if
> {{dataType}} is {{CODE_LIST_ELEMENT}}.
> ** {{MD_ExtendedElementInformation}} allows a non-null {{condition}} only if
> {{obligation}} is {{CONDITIONAL}}.
> ** {{MD_LegalConstraints}} allows a non-empty {{otherConstraints}} only if
> {{accessConstraintsaccessConstraints}} or {{useConstraints}} is
> {{OTHER_RESTRICTIONS}}.
> ** {{LI_Lineage}} allows a non-null {{statement}} only if the scope level is
> {{SERIES}}.
> ** {{DQ_DataQuality}} allows non-null {{reports}} and {{lineage}} only if the
> scope level is {{DATASET}}.
> ** {{DQ_Scope}} allows a non-null {{levelDescription}} only if {{level}} is
> neither {{DATASET}} or {{SERIES}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
