[sis] branch geoapi-4.0 updated: Consolidation of the way we check if some tests are enabled.
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
The following commit(s) were added to refs/heads/geoapi-4.0 by this push:
new a941f05 Consolidation of the way we check if some tests are enabled.
a941f05 is described below
commit a941f055d83b95f62b974376916fa3e184380619
Author: Martin Desruisseaux
AuthorDate: Sun Oct 20 16:39:39 2019 +0200
Consolidation of the way we check if some tests are enabled.
---
.../sis/metadata/xml/SchemaComplianceTest.java | 24 +
.../org/apache/sis/test/xml/PackageVerifier.java | 8 +-
.../java/org/apache/sis/internal/jdk9/JDK9.java| 19 +++-
.../org/apache/sis/internal/jdk9/package-info.java | 2 +-
.../java/org/apache/sis/util/logging/Logging.java | 11 +--
.../org/apache/sis/test/ProjectDirectories.java| 104 +
.../test/java/org/apache/sis/test/TestCase.java| 4 +
.../test/java/org/apache/sis/test/TestSuite.java | 35 ++-
.../java/org/apache/sis/test/package-info.java | 2 +-
9 files changed, 147 insertions(+), 62 deletions(-)
diff --git
a/core/sis-metadata/src/test/java/org/apache/sis/metadata/xml/SchemaComplianceTest.java
b/core/sis-metadata/src/test/java/org/apache/sis/metadata/xml/SchemaComplianceTest.java
index be775fc..e03a2ac 100644
---
a/core/sis-metadata/src/test/java/org/apache/sis/metadata/xml/SchemaComplianceTest.java
+++
b/core/sis-metadata/src/test/java/org/apache/sis/metadata/xml/SchemaComplianceTest.java
@@ -17,16 +17,15 @@
package org.apache.sis.metadata.xml;
import java.nio.file.Path;
-import java.nio.file.Paths;
import java.nio.file.Files;
import org.apache.sis.metadata.iso.ISOMetadata;
import org.apache.sis.internal.system.DataDirectory;
+import org.apache.sis.test.ProjectDirectories;
import org.apache.sis.test.xml.SchemaCompliance;
import org.apache.sis.test.TestCase;
import org.junit.Test;
import static org.junit.Assume.*;
-import static org.junit.Assert.*;
/**
@@ -36,7 +35,7 @@ import static org.junit.Assert.*;
* Content can be downloaded as ZIP files from https://standards.iso.org/iso/19115/";>ISO portal.
*
* @author Martin Desruisseaux (Geomatys)
- * @version 1.0
+ * @version 1.1
* @since 1.0
* @module
*/
@@ -58,22 +57,9 @@ public final strictfp class SchemaComplianceTest extends
TestCase {
* Locate the root of metadata class directory. In a Maven build:
* "core/sis-metadata/target/classes/org/apache/sis/metadata/iso"
*/
-final Path mdp =
Paths.get(ISOMetadata.class.getResource("ISOMetadata.class").toURI()).getParent();
-final Path cp = getParent(mdp, "org", "apache", "sis", "metadata",
"iso");
-final SchemaCompliance checker = new SchemaCompliance(cp, directory);
+final ProjectDirectories dir = new
ProjectDirectories(ISOMetadata.class);
+final SchemaCompliance checker = new
SchemaCompliance(dir.classesRootDirectory, directory);
checker.loadDefaultSchemas();
-checker.verify(mdp);
-}
-
-/**
- * Returns the parent directory. The expected names of skipped directories
are given in argument;
- * they will be verified.
- */
-private static Path getParent(Path cp, final String... parents) {
-for (int i=parents.length; --i >= 0;) {
-assertTrue(cp.endsWith(parents[i]));
-cp = cp.getParent();
-}
-return cp;
+checker.verify(dir.classesPackageDirectory);
}
}
diff --git
a/core/sis-metadata/src/test/java/org/apache/sis/test/xml/PackageVerifier.java
b/core/sis-metadata/src/test/java/org/apache/sis/test/xml/PackageVerifier.java
index afa93ea..74f6667 100644
---
a/core/sis-metadata/src/test/java/org/apache/sis/test/xml/PackageVerifier.java
+++
b/core/sis-metadata/src/test/java/org/apache/sis/test/xml/PackageVerifier.java
@@ -45,6 +45,8 @@ import org.apache.sis.internal.system.Modules;
import org.apache.sis.internal.xml.LegacyNamespaces;
import org.apache.sis.xml.Namespaces;
+import static org.apache.sis.test.TestCase.PENDING_FUTURE_SIS_VERSION;
+
/**
* Verify JAXB annotations in a single package. A new instance of this class
is created by
@@ -447,11 +449,11 @@ final strictfp class PackageVerifier {
*/
if (isCollection) {
if (!info.isCollection) {
-if (false) // Temporarily disabled because require GeoAPI
modifications.
+if (PENDING_FUTURE_SIS_VERSION) // Temporarily disabled
because require GeoAPI modifications.
throw new
SchemaException(errorInClassMember(javaName).append("Value should be a
singleton.").toString());
}
} else if (info.isCollection) {
-if (false) // Temporarily disabled because require GeoAPI
modifications.
+if (PENDING_FUTURE_SIS_VERSION) // Temp
[jira] [Closed] (SIS-450) Sinusoidal projection
[ https://issues.apache.org/jira/browse/SIS-450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux closed SIS-450. --- > Sinusoidal projection > - > > Key: SIS-450 > URL: https://issues.apache.org/jira/browse/SIS-450 > Project: Spatial Information Systems > Issue Type: Sub-task > Components: Referencing >Reporter: Martin Desruisseaux >Assignee: Martin Desruisseaux >Priority: Major > Fix For: 1.0 > > > Sinusoidal projection is not defined by EPSG. Definition can be found in > Snyder (1987) page 243, or on > [Wikipedia|https://en.wikipedia.org/wiki/Sinusoidal_projection]. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SIS-426) Mollweide projection
[ https://issues.apache.org/jira/browse/SIS-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux closed SIS-426. --- > Mollweide projection > > > Key: SIS-426 > URL: https://issues.apache.org/jira/browse/SIS-426 > Project: Spatial Information Systems > Issue Type: Sub-task > Components: Referencing >Reporter: Martin Desruisseaux >Assignee: Johann Sorel >Priority: Minor > Fix For: 1.0 > > > Implement the Mollweide projection. As of version 9.4 of EPSG geodetic > dataset, there is no known EPSG code for this projection. Formulas can be > found on [Mathworld|http://mathworld.wolfram.com/MollweideProjection.html] or > [Wikipedia|https://en.wikipedia.org/wiki/Mollweide_projection] and > (unofficial) parameters can be found on [GeoTIFF list of > projections|http://geotiff.maptools.org/proj_list/mollweide.html]. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SIS-473) Build failure with Java 12
[
https://issues.apache.org/jira/browse/SIS-473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-473.
---
Resolution: Fixed
> Build failure with Java 12
> --
>
> Key: SIS-473
> URL: https://issues.apache.org/jira/browse/SIS-473
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Build process, Utilities
>Affects Versions: 1.0
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.1
>
>
> Building Apache SIS with Java 12 cause the following test failure:
> {noformat}
> ConverterRegistryTest.testNumberToMiscellaneous:295
> After ObjectToString.Number[4] expected:
> ├─[Object ] ← Number>
> but was:
> ├─[Constable] ← Number>
> {noformat}
> Seems to be a side effect o {{java.lang.Number}} subclasses now implementing
> the {{java.lang.Constable}} interface (new in Java 12).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (SIS-473) Build failure with Java 12
[
https://issues.apache.org/jira/browse/SIS-473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux reassigned SIS-473:
---
Assignee: Martin Desruisseaux
> Build failure with Java 12
> --
>
> Key: SIS-473
> URL: https://issues.apache.org/jira/browse/SIS-473
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Build process, Utilities
>Affects Versions: 1.0
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.1
>
>
> Building Apache SIS with Java 12 cause the following test failure:
> {noformat}
> ConverterRegistryTest.testNumberToMiscellaneous:295
> After ObjectToString.Number[4] expected:
> ├─[Object ] ← Number>
> but was:
> ├─[Constable] ← Number>
> {noformat}
> Seems to be a side effect o {{java.lang.Number}} subclasses now implementing
> the {{java.lang.Constable}} interface (new in Java 12).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-468) Update EPSG geodetic dataset to version 9.7
[
https://issues.apache.org/jira/browse/SIS-468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-468.
---
> Update EPSG geodetic dataset to version 9.7
> ---
>
> Key: SIS-468
> URL: https://issues.apache.org/jira/browse/SIS-468
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Referencing
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.0
>
>
> Upgrade the {{org.apache.sis.non-free:sis-epsg}} Maven artifact to latest
> EPSG geodetic dataset (currently 9.7) before Apache SIS 1.0 release.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-464) DataSet.getEnvelope() should return Optional
[
https://issues.apache.org/jira/browse/SIS-464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-464.
---
> DataSet.getEnvelope() should return Optional
> --
>
> Key: SIS-464
> URL: https://issues.apache.org/jira/browse/SIS-464
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Storage
>Affects Versions: 0.8
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.0
>
>
> The {{org.apache.sis.storage.DataSet}} interface contains the following
> method:
> {code:java}
> Envelope getEnvelope() throws DataStoreException;
> {code}
> It should be:
> {code:java}
> Optional getEnvelope() throws DataStoreException;
> {code}
> The javadoc was saying that this envelope should not be null, but may
> nevertheless be null is some circumstances. For example the envelope may be
> too costly to compute if it would require to scan all features in a dataset.
> The danger is that users will assume that the envelope will never be null for
> practical purposes, which is a dangerous assumptions. In another project
> using SIS, we found that this assumption was one significant cause of
> {{NullPointerException}}. We propose to declare the envelope as {{Optional}}
> for making clear that it may be absent.
> Note that this is an incompatible API changes. We hope that
> {{DataSet.getEnvelope()}} is not yet used too widely.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-456) New numbering scheme for development branches
[
https://issues.apache.org/jira/browse/SIS-456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-456.
---
> New numbering scheme for development branches
> -
>
> Key: SIS-456
> URL: https://issues.apache.org/jira/browse/SIS-456
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Build process
>Affects Versions: 0.8
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.0
>
>
> Apache SIS is developed in 3 branches with the following version numbers:
> * {{master}} has version {{1.0-SNAPSHOT}}
> * {{geoapi-3.1}} branch has version {{dev-1.0-SNAPSHOT}}
> * {{geoapi-4.0}} branch also has version {{dev-1.0-SNAPSHOT}}
> Having two branches with the same version number is confusing. Furthermore
> those numbers said nothing about the targeted version numbers for the release
> of those branches. The proposal [discussed on the mailing
> list|https://lists.apache.org/thread.html/6f428e0f208ba062c3d8aca6f05f116d0f571d67472c66252fa1bf44@%3Cdev.sis.apache.org%3E]
> is:
> * {{geoapi-3.1}} branch uses version {{1.x-SNAPSHOT}}
> * {{geoapi-4.0}} branch uses version {{2.0-SNAPSHOT}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-439) NetCDF reader does not support unlimited dimension
[ https://issues.apache.org/jira/browse/SIS-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux closed SIS-439. --- > NetCDF reader does not support unlimited dimension > -- > > Key: SIS-439 > URL: https://issues.apache.org/jira/browse/SIS-439 > Project: Spatial Information Systems > Issue Type: Bug > Components: Storage >Affects Versions: 0.7, 0.8 >Reporter: Martin Desruisseaux >Assignee: Martin Desruisseaux >Priority: Major > Fix For: 1.0 > > > NetCDF variables having a "unlimited" dimension have a different layout on > disk than ordinary netCDF variables. This layout is not taken in account by > the current netCDF reader. This result in unpredictable behavior: sometime > erroneous values, sometime an end-of-file exception. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SIS-476) Exception while reading some netCDF variables with unlimited
[
https://issues.apache.org/jira/browse/SIS-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-476.
---
> Exception while reading some netCDF variables with unlimited
> -
>
> Key: SIS-476
> URL: https://issues.apache.org/jira/browse/SIS-476
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Storage
>Affects Versions: 1.0
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.1
>
>
> Reading a netCDF variable with the following characteristics:
> * an unlimited dimension
> * a {{long}} or {{double}} data type
> * a stride which is not a multiple of 8 bytes
> produce the following {{DataStoreContentException}}: _"Can not compute data
> location for “…” variable in the “…” netCDF file."_
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-422) Migrate from SVN to Git as the main SIS code repository
[
https://issues.apache.org/jira/browse/SIS-422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-422.
---
> Migrate from SVN to Git as the main SIS code repository
> ---
>
> Key: SIS-422
> URL: https://issues.apache.org/jira/browse/SIS-422
> Project: Spatial Information Systems
> Issue Type: Improvement
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.0
>
>
> Migrate to git as the main source code repository. After this work:
> * The source code repository will become
> https://gitbox.apache.org/repos/asf/sis.
> * The https://svn.apache.org/repos/asf/sis/trunk/ repository will become
> read-only.
> We will continue to use Subversion for the {{site}}, {{sis-data}} and
> {{non-free}}. Before to make the new git repository ready for use, we will
> try to cleanup its history by removing large files, especially:
> * {{California_Restaurants.csv}} (19 Mb)
> * {{DEPARTEMENT.SHP}} (3 Mb)
> * {{ANC90Ply_4326.shp}} (0.7 Mb)
> Those large files were identified as below (source:
> [stackoverflow|https://stackoverflow.com/questions/10622179/how-to-find-identify-large-files-commits-in-git-history]):
> {code:Bash}
> git rev-list --objects --all | sort -k 2 > allfileshas.txt
> git gc && git verify-pack -v .git/objects/pack/pack-*.idx | egrep "^\w+
> blob\W+[0-9]+ [0-9]+ [0-9]+$" | sort -k 3 -n -r > bigobjects.txt
> for SHA in `cut -f 1 -d\ < bigobjects.txt`; do
> echo $(grep $SHA bigobjects.txt) $(grep $SHA allfileshas.txt) | awk '{print
> $1,$3,$7}' >> bigtosmall.txt
> done;
> {code}
> Commands executed for removing them:
> {code:Bash}
> git filter-branch --tree-filter 'find . -name "California_Restaurants.csv"
> -delete' -- --all
> git filter-branch --tree-filter 'find . -name "DEPARTEMENT.*" -delete' --
> --all
> git filter-branch --tree-filter 'find . -name "ANC90Ply_4326*" -delete' --
> --all
> git filter-branch --tree-filter 'find . -name "*~" -delete' -- --all
> git filter-branch --tree-filter 'rm -rf "sis-data"' -- --all
> git update-ref -d refs/original/refs/heads/master
> git reflog expire --expire=now --all
> git gc --prune=now
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-406) Move XML support from sis-utility module to sis-metadata
[
https://issues.apache.org/jira/browse/SIS-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-406.
---
> Move XML support from sis-utility module to sis-metadata
>
>
> Key: SIS-406
> URL: https://issues.apache.org/jira/browse/SIS-406
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Metadata, Utilities
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.0
>
>
> The {{sis-utility}} module contains many classes needed by Apache SIS for
> supporting XML (marshaller pool, JAXB adapters, _etc._) but - except in
> {{org.apache.sis.util.iso}} - does not provide objects to be read or written
> in XML documents. Those objects are rather defined in the next module,
> {{sis-metadata}}. The initial intent was to keep {{sis-utility}} generic
> enough so it could be used for XML documents unrelated to ISO 19115. However
> with SIS-345 work, a lot of metadata-specific logic has been introduced (e.g.
> more ISO 19115 namespaces, {{RenameOnImport.lst}} and {{RenameOnExport.lst}}
> files which contain a list of ISO 19115 properties, _etc._) in addition of
> specialized JAXB adapters we already had. It does not make sense anymore to
> keep those classes separated from {{sis-metadata}}. The proposal is to move
> the following packages from {{sis-utility}} to {{sis-metadata}}:
> * {{org.apache.sis.xml}}
> * {{org.apache.sis.internal.jaxb}} and all sub-packages.
> * {{org.apache.sis.internal.simple}} (for most parts)
> * {{org.apache.sis.util.iso}} (maybe) as a side-effect of the displacement of
> JAXB adapters.
> The API will stay the same. This change should be transparent for users
> except if they add only the {{sis-utility}} dependency in their Maven project
> (in which case they may need to add {{sis-metadata}} dependency).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-81) Replace ModifiableMetadata.isModifiable() by an enum
[
https://issues.apache.org/jira/browse/SIS-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-81.
--
> Replace ModifiableMetadata.isModifiable() by an enum
>
>
> Key: SIS-81
> URL: https://issues.apache.org/jira/browse/SIS-81
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Metadata
>Affects Versions: 0.3, 0.4, 0.5, 0.6, 0.7, 0.8
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.0
>
>
> The {{ModifiableMetadata}} abstract class provides a {{isModifiable()}}
> method which currently returns a {{boolean}} value. The boolean value should
> be replaced by an enumeration containing the following values (for now):
> * {{EDITABLE}}
> * {{APPENDABLE}}
> * {{FINAL}}
> The new functionality is the {{APPENDABLE}} value, which would be like
> {{EDITABLE}} except that only new values could be set; an exception would be
> thrown on attempt to modify an existing value.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-425) Drop package prefixes in table created in "metadata" schema
[
https://issues.apache.org/jira/browse/SIS-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-425.
---
> Drop package prefixes in table created in "metadata" schema
> ---
>
> Key: SIS-425
> URL: https://issues.apache.org/jira/browse/SIS-425
> Project: Spatial Information Systems
> Issue Type: New Feature
> Components: Metadata
>Affects Versions: 0.8
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.0
>
>
> Apache SIS 0.8 creates tables in the "SpatialMetadata" database with the
> exact same name as defined in the UML of the ISO 19115 metadata standard. All
> those names have a package prefixes (e.g. {{"CI_"}} in {{"CI_Citation"}}).
> However recent ISO standards tends to drop the package prefixes. For example
> {{"CS_CoordinateSystem"}} in ISO 19111:2007 become {{"CoordinateSystem"}} in
> ISO 19111:2018. In anticipation for such change in ISO metadata standard, or
> for making the {{"metadata"}} schema easier to read even if future ISO 19115
> does not apply this change, we drop the package prefixes in names of the
> tables created by the {{org.apache.sis.metadata.sql.MetadataWriter}} class.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-463) Move WKT support from sis-metadata to sis-referencing
[
https://issues.apache.org/jira/browse/SIS-463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-463.
---
> Move WKT support from sis-metadata to sis-referencing
> -
>
> Key: SIS-463
> URL: https://issues.apache.org/jira/browse/SIS-463
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Metadata, Referencing
>Affects Versions: 0.8
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Minor
> Fix For: 1.0
>
>
> The {{org.apache.sis.io.wkt}} package is currently located in the
> {{sis-metadata}} module. However the WKT parser/formatter is close to useless
> without {{sis-referencing}} module because the only objects currently parsed
> or formatted are in that module. This is illustrated by the fact that only
> basic tests are defined in {{sis-metadata}} and more "real situation" tests
> are in {{sis-referencing}}. Even if a future version is generalized to
> parsing/formatting of geometry objects, a geometry module would probably need
> {{sis-referencing}}.
> We should move {{org.apache.sis.io.wkt}} package into the {{sis-referencing}}
> module. It would bring many simplifications, like a single place for all
> tests.
> h2. Post-migration cleanups
> After this move has been done, we should apply the following cleanups:
> Add the following case at the end of {{appendElement(Object)}} method:
> {code:java}
> } else if (value instanceof Position) {
> append(AbstractDirectPosition.castOrCopy(((Position)
> value).getDirectPosition()));
> } else if (value instanceof Envelope) {
> append(AbstractEnvelope.castOrCopy((Envelope) value)); //
> Non-standard
> {code}
> Retrofit {{org.apache.sis.util.internal.Citations}} into
> {{org.apache.sis.metadata.iso.citation.Citations}}, which will allow us to
> add the following code in {{Citations.identifierMatches}}:
> {code:java}
> if (c1 == c2) {
> return true;// Optimization for a common case.
> }
> /*
> * If both argument are one of the constants defined in the Citations class,
> * then we do not need to compare identifier; call to `equals` is sufficient.
> * This special case avoids the potentially costly call to `getIdentifiers()`
> * since that call may cause a connection to the spatial metadata database.
> */
> if (c1 instanceof CitationConstant && c2 instanceof CitationConstant) {
> return c1.equals(c2);
> }
> {code}
> Other cleanups:
> * Move {{EllipsoidalHeightCombiner}}, which will allow us to leverage
> {{ReferencingFactoryContainer}} instead than duplicating its work.
> * Leverage {{ReferencingFactoryContainer}} into {{MathTransforParser}} too.
> * Move {{WKTKeywords}}.
> h2. Requirement
> The only dependency in {{sis-metadata}} is {{ImmutableIdentifier}}. May may
> need to move that class into {{sis-referencing}}, maybe in
> {{org.apache.sis.referencing}} package. That would need a "deprecate now
> delete later" cycle.
> h2. Execution
> Commands to run on the command-line are below. It may be easier to execute
> those commands in each branches instead than only one branch and resolve
> merge conflicts (to be verified).
> {code:bash}
> git mv core/sis-metadata/src/test/java/org/apache/sis/io/wkt/*.java
> core/sis-referencing/src/test/java/org/apache/sis/io/wkt/
> git rm -r core/sis-metadata/src/test/java/org/apache/sis/io
> mkdir core/sis-referencing/src/main/java/org/apache/sis/io
> git mv core/sis-metadata/src/main/java/org/apache/sis/io/wkt
> core/sis-referencing/src/main/java/org/apache/sis/io/
> rmdir core/sis-metadata/src/main/java/org/apache/sis/io
> mkdir core/sis-referencing/src/main/java/org/apache/sis/metadata
> mkdir core/sis-referencing/src/main/java/org/apache/sis/metadata/iso
> mkdir core/sis-referencing/src/test/java/org/apache/sis/metadata
> mkdir core/sis-referencing/src/test/java/org/apache/sis/metadata/iso
> git mv
> core/sis-metadata/src/main/java/org/apache/sis/metadata/iso/ImmutableIdentifier.java
>
> core/sis-referencing/src/main/java/org/apache/sis/metadata/iso/ImmutableIdentifier.java
> {code}
> Some files need to be modified after the move (e.g. {{MetadataTestSuite}},
> _etc_).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-440) ComparisonMode.APPROXIMATIVE should be APPROXIMATE
[
https://issues.apache.org/jira/browse/SIS-440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-440.
---
> ComparisonMode.APPROXIMATIVE should be APPROXIMATE
> --
>
> Key: SIS-440
> URL: https://issues.apache.org/jira/browse/SIS-440
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Utilities
>Affects Versions: 0.3, 0.4, 0.5, 0.6, 0.7, 0.8
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Minor
> Fix For: 1.0
>
>
> "Approximative" is a French word. An English word would be "Approximate". We
> would need to add a {{ComparisonMode.APPROXIMATE}} value and deprecate the
> {{ComparisonMode.APPROXIMATIVE}} enumeration value.
> Another method to rename is {{Utilities.equalsApproximatively(…)}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-337) Package EPSG Derby DB in sis-epsg jar, eliminating the need for external SIS_DATA dir
[ https://issues.apache.org/jira/browse/SIS-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux closed SIS-337. --- > Package EPSG Derby DB in sis-epsg jar, eliminating the need for external > SIS_DATA dir > -- > > Key: SIS-337 > URL: https://issues.apache.org/jira/browse/SIS-337 > Project: Spatial Information Systems > Issue Type: Wish > Components: Referencing >Affects Versions: 0.7 >Reporter: Kevin Mehall >Assignee: Martin Desruisseaux >Priority: Major > Fix For: 0.8 > > > Since [Derby > supports|https://db.apache.org/derby/docs/10.7/devguide/cdevdeploy11201.html] > read-only databases in .jar files, is there a reason that the > `org.apache.sis.non-free:sis-epsg` package includes SQL source to create an > external database, rather than the database itself? > It would make deployment much easier if there were no need for a SIS_DATA > directory and environment variable, and adding the dependency were the only > thing necessary. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SIS-388) Upgrade Java platform requirement from JDK7 to JDK8
[
https://issues.apache.org/jira/browse/SIS-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-388.
---
> Upgrade Java platform requirement from JDK7 to JDK8
> ---
>
> Key: SIS-388
> URL: https://issues.apache.org/jira/browse/SIS-388
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Build process, Command line, Documentation, Features,
> Geometry, GUI, Metadata, OpenOffice, Referencing, Shapefile, Storage,
> Utilities, Web services, Web site
>Affects Versions: 0.8
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.0
>
>
> Upgrade the required platform from Java 7 to Java 8. The main reason for this
> upgrade is to allow the use of {{java.util.stream.Stream}} in public API.
> This is important because {{DataStore}} implementations return the
> {{Feature}} instances in a {{Stream}}. Other API to leverage are
> {{java.time}} and (to a lesser extend) {{java.util.function}}.
> See the [thread of mailing
> list|https://lists.apache.org/thread.html/abf82d212eb1bb2499f31c1714bde242f818c03af010e85bdc53be17@%3Cdev.sis.apache.org%3E].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-461) Replace "ordinate" by "coordinate"
[
https://issues.apache.org/jira/browse/SIS-461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-461.
---
> Replace "ordinate" by "coordinate"
> --
>
> Key: SIS-461
> URL: https://issues.apache.org/jira/browse/SIS-461
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Geometry, Referencing
>Affects Versions: 0.3, 0.4, 0.5, 0.6, 0.7, 0.8
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Minor
> Fix For: 1.0
>
>
> Replace the term "ordinate" by "coordinate" for conformance with ISO 19111
> terminology. The ISO standard said:
> {quote}
> In this document, a coordinate is one of _n_ scalar values that define the
> position of a single point. In other contexts, the term _ordinate_ is used
> for a single value and _coordinate_ for multiple ordinates. Such usage is not
> part of this document.
> {quote}
> SIS was using _ordinate_, but OGC/ISO standards consistently use _coordinate_
> instead. We should align on international standard usage.
> This change implies the following incompatible changes:
> * In {{org.apache.sis.geometry.DirectPosition1D}}, public field {{ordinate}}
> is renamed {{coordinate}}.
> * Serialization UUID of {{DirectPosition1D}} and {{ArrayEnvelope}} changed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-375) Cache : override default Map methods
[ https://issues.apache.org/jira/browse/SIS-375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux closed SIS-375. --- > Cache : override default Map methods > > > Key: SIS-375 > URL: https://issues.apache.org/jira/browse/SIS-375 > Project: Spatial Information Systems > Issue Type: Task > Components: Utilities >Affects Versions: 0.8 >Reporter: Alexís Manin >Assignee: Martin Desruisseaux >Priority: Minor > Labels: newbie, patch > Fix For: 1.0 > > Attachments: cache.diff > > > The aim here is to provide thread-safe implementations of the default utility > methods of Map interface for SIS Cache implementation. > I attach a patch with the implementations I've done. Hope it helps ! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SIS-383) Upgrade Derby dependency and reduce dependency on JavaDB
[
https://issues.apache.org/jira/browse/SIS-383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-383.
---
> Upgrade Derby dependency and reduce dependency on JavaDB
>
>
> Key: SIS-383
> URL: https://issues.apache.org/jira/browse/SIS-383
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Metadata, Referencing
>Affects Versions: 0.8
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Minor
> Fix For: 1.0
>
>
> Upgrade Derby dependency to 10.14.2.0 (released in May 2018). Note that the
> 10.14 series are the last versions compatible with JDK 8; next Derby versions
> will require JDK 9.
> In preparation for JDK 9, we should also declare explicit dependency to Derby
> in {{pom.xml}} files with Maven test scope. Current Apache SIS relies on
> JavaDB bundled with JDK 6, 7 and 8, but JavaDB is no longer bundled with JDK
> 9 and above. Apache SIS will continue to check if JavaDB is available in the
> JDK home directory (until we migrate to Java 9), but this will no longer be a
> documented feature.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-410) More stable MathTransform.Inverse serialization
[
https://issues.apache.org/jira/browse/SIS-410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-410.
---
> More stable MathTransform.Inverse serialization
> ---
>
> Key: SIS-410
> URL: https://issues.apache.org/jira/browse/SIS-410
> Project: Spatial Information Systems
> Issue Type: New Feature
> Components: Referencing
>Affects Versions: 0.5, 0.6, 0.7, 0.8
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Minor
> Fix For: 1.0
>
>
> The {{AbstractMathTransform.Inverse}} class is non-static. This cause the
> compiler to generate a {{this$0}} private field. But this synthetic fields
> may not be the same across implementations of different Java compilers.
> Consequently reading a class serialized with an Apache SIS library compiled
> with a different compiler may not recognize the fields that are named
> differently (see
> http://developer.java.sun.com/developer/bugParade/bugs/4211550.html). We
> should use static inner class with a named field (e.g. {{"forward"}})instead.
> This is an incompatible change, but {{AbstractMathTransform.Inverse}} is
> protected rather than public.
> In the particular case of {{AbstractMathTransform.Inverse}}, it also avoid a
> minor strangeness. Since we extends {{Inverse}} in different classes, we saw
> the synthetic {{this$0}} field duplicated in each subclass. Using a named
> field instead will avoid that.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-316) NetCDF: build CRS and GridToCRS Transform from netcdf variables and attributes
[ https://issues.apache.org/jira/browse/SIS-316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux closed SIS-316. --- > NetCDF: build CRS and GridToCRS Transform from netcdf variables and attributes > -- > > Key: SIS-316 > URL: https://issues.apache.org/jira/browse/SIS-316 > Project: Spatial Information Systems > Issue Type: Improvement > Components: Storage >Affects Versions: 0.6, 0.7, 0.8 >Reporter: Johann Sorel >Assignee: Martin Desruisseaux >Priority: Minor > Labels: NetCDF > Fix For: 1.0 > > Attachments: netcdfgridgeom.patch > > > Patch include : > - CRS reconstruction for GeographicCRS N dimensions. > - MathTransform reconstruction from variable grid to CRS -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SIS-314) NetCDF: read method with subsampling and area parameters
[ https://issues.apache.org/jira/browse/SIS-314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux closed SIS-314. --- > NetCDF: read method with subsampling and area parameters > > > Key: SIS-314 > URL: https://issues.apache.org/jira/browse/SIS-314 > Project: Spatial Information Systems > Issue Type: Improvement > Components: Storage >Reporter: Johann Sorel >Assignee: Martin Desruisseaux >Priority: Minor > Labels: NetCDF > Fix For: 0.8 > > Attachments: netcdfread.patch > > > Current netcdf variable read method can only read the full data set. > this patch introduce a new reading method with area lower/upper bounds and > subsampling factors. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SIS-227) American Polyconic (EPSG:9818)
[ https://issues.apache.org/jira/browse/SIS-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux closed SIS-227. --- > American Polyconic (EPSG:9818) > -- > > Key: SIS-227 > URL: https://issues.apache.org/jira/browse/SIS-227 > Project: Spatial Information Systems > Issue Type: Sub-task > Components: Referencing >Reporter: Martin Desruisseaux >Assignee: Martin Desruisseaux >Priority: Minor > Fix For: 1.0 > > > This projection can be ported from Geotk, but needs corrections. Formulas are > given in §1.3.10 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] [Closed] (SIS-126) Replace the NamespacePrefixMapper hack by NamespaceContext
[
https://issues.apache.org/jira/browse/SIS-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-126.
---
> Replace the NamespacePrefixMapper hack by NamespaceContext
> --
>
> Key: SIS-126
> URL: https://issues.apache.org/jira/browse/SIS-126
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Metadata
>Affects Versions: 0.3, 0.4, 0.5, 0.6, 0.7, 0.8
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Minor
> Labels: JAXB
> Fix For: 1.0
>
>
> In order to customize the mapping of XML prefix to URI, we currently override
> the following classes:
> * {{com.sun.xml.bind.marshaller.NamespacePrefixMapper}}
> * {{com.sun.xml.internal.bind.marshaller.NamespacePrefixMapper}}
> Which class is used depends on the environment (standard JDK or Glassfish).
> However those classes are not public API; they may not be present in other
> implementations, and their API sometime change.
> It seems that {{javax.xml.namespace.NamespaceContext}} in public API can do
> the job. We need to specify an instance to
> {{javax.xml.stream.XMLStreamWriter}} using the {{setNamespaceContext}}
> method, then to use the {{javax.xml.bind.Marshaller}} method that expect a
> {{XMLStreamWriter}} argument.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-13) Change QuadTree Reader/Writer to use URLs instead of String file paths
[ https://issues.apache.org/jira/browse/SIS-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux closed SIS-13. -- > Change QuadTree Reader/Writer to use URLs instead of String file paths > -- > > Key: SIS-13 > URL: https://issues.apache.org/jira/browse/SIS-13 > Project: Spatial Information Systems > Issue Type: Improvement > Components: Storage >Affects Versions: 0.1-incubating >Reporter: Gregory D. Reddin >Assignee: Chris A. Mattmann >Priority: Major > > Per the email thread discussion here [1], it's probably a good idea to > abstract away the underlying Reader/Writer API for the QuadTree storage layer > to use java.net.URLs instead of String file paths. > [1] http://s.apache.org/Iyj -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SIS-33) Make SIS data storage pluggable
[ https://issues.apache.org/jira/browse/SIS-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux closed SIS-33. -- > Make SIS data storage pluggable > --- > > Key: SIS-33 > URL: https://issues.apache.org/jira/browse/SIS-33 > Project: Spatial Information Systems > Issue Type: Improvement > Components: Storage >Reporter: Chris A. Mattmann >Assignee: Chris A. Mattmann >Priority: Major > Fix For: 0.6 > > > It would be really great to make SIS have a pluggable backend storage > service. I'd like to integrate and use the Apache OODT file manager to do > this. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SIS-8) Build a common SIS data container for spatial data
[
https://issues.apache.org/jira/browse/SIS-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-8.
-
> Build a common SIS data container for spatial data
> --
>
> Key: SIS-8
> URL: https://issues.apache.org/jira/browse/SIS-8
> Project: Spatial Information Systems
> Issue Type: New Feature
> Components: Geometry, Storage
>Reporter: Chris A. Mattmann
>Assignee: Chris A. Mattmann
>Priority: Major
> Fix For: 0.6
>
>
> The QuadTreeNode has the concept of a data container per node in the QTree,
> but I'd like to extend this to a general SIS spatial data type. This would in
> part be motivated by e.g., [1], where the suggestion is something like:
> {quote}
> Any measurement we take in Earth and environmental sciences, although this is
> often ignored, has a spatio-temporal reference. A spatio-temporal reference
> is determined by (at least) four parameters:
> 1. geographic location (longitude and latitude or projected X,Y coordinates);
> 2. height above the ground surface (elevation);
> 3. time of measurement (year, month, day, hour, minute etc.);
> 4. spatio-temporal support (size of the blocks of material associated with
> measurements; time interval of measurement);
> {quote}
> [1]
> http://www.lulu.com/items/volume_67/801/8010854/5/print/Hengl_2009_GEOSTATe2c1_f.pdf
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-42) Implement GeoSPARQL in SIS
[ https://issues.apache.org/jira/browse/SIS-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux closed SIS-42. -- > Implement GeoSPARQL in SIS > -- > > Key: SIS-42 > URL: https://issues.apache.org/jira/browse/SIS-42 > Project: Spatial Information Systems > Issue Type: New Feature > Components: Geometry, Referencing, Storage, Web services >Reporter: Chris A. Mattmann >Assignee: Chris A. Mattmann >Priority: Major > Labels: geosparql, gsoc2012, rdf, sis, spatial > > Following Andy Seaborne's post here: http://s.apache.org/wh > I am going to undertake an effort to implement GeoSPARQL in Apache SIS. I > think this will give us an awesome use case and is something that we need an > ALv2 licensed library to do. > See the GeoSPARQL implmentation here: http://www.w3.org/2011/02/GeoSPARQL.pdf -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SIS-224) Oblique and Equatorial Stereographic (EPSG:9809)
[ https://issues.apache.org/jira/browse/SIS-224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux closed SIS-224. --- > Oblique and Equatorial Stereographic (EPSG:9809) > > > Key: SIS-224 > URL: https://issues.apache.org/jira/browse/SIS-224 > Project: Spatial Information Systems > Issue Type: Sub-task > Components: Referencing >Reporter: Martin Desruisseaux >Assignee: Rémi Maréchal >Priority: Major > Fix For: 0.7 > > > Projection defined in §1.3.7.1 of IOGP Publication 373-7-2 – Geomatics > Guidance Note number 7, part 2 – April 2015. This projection can be ported > from Geotk, after IP review and eventually rewriting some formulas using the > EPSG guide as the source. > Note that the _Polar Stereographic_ cases have already been ported to SIS. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SIS-407) OutOfMemoryError when reading Sentinel 1 image with GeoTIFF reader
[
https://issues.apache.org/jira/browse/SIS-407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-407.
---
> OutOfMemoryError when reading Sentinel 1 image with GeoTIFF reader
> --
>
> Key: SIS-407
> URL: https://issues.apache.org/jira/browse/SIS-407
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Storage
>Affects Versions: 0.8
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.0
>
>
> When opening a Sentinel 1 GeoTIFF image, the call to
> {{DataStore.getMetadata()}} cause the JVM to attempt to allocate about one
> gigabyte of memory. This is not caused by the image size, but rather by a
> mathematical error. In the {{LocalizationGridBuilder}} class, private method
> {{infer}} computes the greatest common divisor of _X_ and _Y_ translations
> from the grid origin. Sentinel 1 image have control points spaced by 1320
> pixels on the _X_ axis, except the very last point which is only 1302 pixels
> after the previous one. This cause {{LocalizationGridBuilder}} to find a much
> smaller common divisor than expected (6 instead of 1320), which cause it to
> attempt to create a localization grid much larger than it should be.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-404) Allow profiles to extend legacy metadata schema
[
https://issues.apache.org/jira/browse/SIS-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-404.
---
> Allow profiles to extend legacy metadata schema
> ---
>
> Key: SIS-404
> URL: https://issues.apache.org/jira/browse/SIS-404
> Project: Spatial Information Systems
> Issue Type: Sub-task
> Components: Metadata
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Labels: regression
> Fix For: 1.0
>
>
> The metadata XML upgrade from legacy ISO 19139:2007 to newer ISO 19115-3:2016
> is incompatible with profiles that extends the legacy schema. For example the
> {{profiles/sis-french-profile}} module is broken with this work. For
> restoring that module, we need to allow profiles to extend the
> {{NameImports.lst}} file content.
> Alternatively, we can also discontinue the {{profiles/sis-french-profile}}
> module since it is not used much. However that module is currently our only
> example of extending metadata, so it still have value as a template.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-376) Geographic/geocentric conversion fails if the geographic CRS is two-dimensional
[
https://issues.apache.org/jira/browse/SIS-376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-376.
---
> Geographic/geocentric conversion fails if the geographic CRS is
> two-dimensional
> ---
>
> Key: SIS-376
> URL: https://issues.apache.org/jira/browse/SIS-376
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Referencing
>Affects Versions: 0.7, 0.8
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.0
>
>
> Following Java code:
> {code:java}
> GeographicCRS geographic = CommonCRS.WGS84.geographic();
> GeocentricCRS geocentric = CommonCRS.WGS84.geocentric();
> CRS.findOperation(geographic, geocentric, null);
> {code}
> fails with the following exception.
> {noformat}
> org.apache.sis.referencing.factory.InvalidGeodeticParameterException: Les
> transformations « Affine parametric transformation » et «
> Geographic/geocentric conversions » ne peuvent pas être combinées. Les
> dimensions des objets (2D et 3D) ne concordent pas.
> at
> org.apache.sis.referencing.operation.transform.DefaultMathTransformFactory.createConcatenatedTransform(DefaultMathTransformFactory.java:1313)
> at
> org.apache.sis.referencing.operation.transform.DefaultMathTransformFactory.swapAndScaleAxes(DefaultMathTransformFactory.java:1158)
> at
> org.apache.sis.referencing.operation.transform.DefaultMathTransformFactory.createParameterizedTransform(DefaultMathTransformFactory.java:1058)
> at
> org.apache.sis.referencing.operation.CoordinateOperationFinder.createOperationStep(CoordinateOperationFinder.java:572)
> at
> org.apache.sis.referencing.operation.CoordinateOperationFinder.createOperation(CoordinateOperationFinder.java:272)
> at
> org.apache.sis.referencing.operation.DefaultCoordinateOperationFactory.createOperation(DefaultCoordinateOperationFactory.java:814)
> at org.apache.sis.referencing.CRS.findOperation(CRS.java:644)
> Caused by: org.opengis.geometry.MismatchedDimensionException: Les
> transformations « Affine parametric transformation » et «
> Geographic/geocentric conversions » ne peuvent pas être combinées. Les
> dimensions des objets (2D et 3D) ne concordent pas.
> at
> org.apache.sis.referencing.operation.transform.ConcatenatedTransform.create(ConcatenatedTransform.java:164)
> at
> org.apache.sis.referencing.operation.transform.DefaultMathTransformFactory.createConcatenatedTransform(DefaultMathTransformFactory.java:1311)
> ... 7 more
> {noformat}
> If we replace the call to {{geographic()}} by a call to {{geographic3D}},
> then the code succeed and the converted coordinates are corrects.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-441) UnconvertibleObjectException when reading code list value from PostgreSQL
[
https://issues.apache.org/jira/browse/SIS-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-441.
---
> UnconvertibleObjectException when reading code list value from PostgreSQL
> -
>
> Key: SIS-441
> URL: https://issues.apache.org/jira/browse/SIS-441
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Metadata
>Affects Versions: 0.8
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.0
>
>
> When metadata are read from database using
> {{org.apache.sis.sql.MetadataSource}}, an attempt to get the {{CodeList}}
> value of a metadata entry produce the following error:
> {noformat}
> org.apache.sis.util.collection.BackingStoreException: Database error while
> creating a ‘Role’ object for the “IOGP” identifier.
> at org.apache.sis.metadata.sql.Dispatcher.invoke(Dispatcher.java:161)
> at org.apache.sis.metadata.sql.$Proxy233.getRole(Unknown Source)
> (…snip…)
> Caused by: org.apache.sis.metadata.sql.MetadataStoreException: Expected an
> instance of ‘Role’ for the “role” property, but got an instance of ‘PGobject’.
> at
> org.apache.sis.metadata.sql.MetadataSource.readColumn(MetadataSource.java:990)
> at org.apache.sis.metadata.sql.Dispatcher.fetchValue(Dispatcher.java:227)
> at org.apache.sis.metadata.sql.Dispatcher.invoke(Dispatcher.java:159)
> Caused by: org.apache.sis.util.UnconvertibleObjectException: Can not convert
> from type ‘PGobject’ to type ‘Role’.
> at
> org.apache.sis.internal.converter.ConverterRegistry.find(ConverterRegistry.java:528)
> (…snip…)
> {noformat}
> This happen only with PostgreSQL database, because we store metadata as
> `VARCHAR` on Derby. The workaround is to read {{CodeList}} value using
> {{ResultSet.getString(int)}} instead than {{ResultSet.getObject(…)}}, so the
> {{PGobject}} is converted to a {{String}} that we can later parse as a
> {{CodeList}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-449) Extension to CF-conventions for bands in a netCDF variable
[
https://issues.apache.org/jira/browse/SIS-449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-449.
---
> Extension to CF-conventions for bands in a netCDF variable
> --
>
> Key: SIS-449
> URL: https://issues.apache.org/jira/browse/SIS-449
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Storage
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.0
>
>
> The _Global Change Observation Mission - Water (GCOM-W)_ files have content
> like below (simplified):
> {noformat}
> variables:
> short "Geophysical Data"(1976, 243, 2)
> float SCALE FACTOR = 0.01
> string UNIT = "C"
> float "Latitude of Observation Point"(1976, 243)
> string UNIT = "deg"
> float "Longitude of Observation Point"(1976, 243)
> string UNIT = "deg"
> {noformat}
> The "Geophysical data" variable is of size 1976 × 243 × 2, but the last
> dimension of size 2 is not defined anywhere in the file and does not
> correspond to any variable. We can build a Coordinate Reference System (CRS)
> with latitude and longitude axes, but we can not include in that CRS the
> third dimension since we don't know if it should be a depth, a time or other
> kind of axis. That third dimensions could be interpreted as bands however.
> We take the assumption that this dimension of size 2 means 2 bands. We
> support multi-banded images for other formats (e.g. GeoTIFF), but multi-bands
> in a NetCDF file is more unusual since a common practice is to use different
> variables instead (actually the netCDF format does not have any explicit
> concept of band). This task is about upgrading the netCDF reader for
> interpreting the dimensions that are not Coordinate Reference System
> dimensions as bands.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-443) Give access to netCDF raster data as GridCoverage
[
https://issues.apache.org/jira/browse/SIS-443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-443.
---
> Give access to netCDF raster data as GridCoverage
> -
>
> Key: SIS-443
> URL: https://issues.apache.org/jira/browse/SIS-443
> Project: Spatial Information Systems
> Issue Type: New Feature
> Components: Storage
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.0
>
>
> When opening a raster file with {{NetcdfStore}} and exploring its content
> with the {{components()}} method, users should see instance of
> {{GridCoverageResource}}. Invoking the `read` method on that resource should
> provide the raster data.
> This implies that {{NetcdfStore}} shall be capable to read the localization
> grid included in the netCDF file and build a {{GridGeometry}} from it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-389) DefaultMedium.name property should be a Citation
[
https://issues.apache.org/jira/browse/SIS-389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-389.
---
> DefaultMedium.name property should be a Citation
>
>
> Key: SIS-389
> URL: https://issues.apache.org/jira/browse/SIS-389
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Metadata
>Affects Versions: 0.5, 0.6, 0.7, 0.8, 1.0
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 2.0
>
>
> {{MD_Medium.name}} was a {{MD_MediumNameCode}} code list in ISO 19115:2003
> but became a {{CI_Citation}} in ISO 19115:2014. This change has not yet been
> propagated in GeoAPI 3.0.1 or in Apache SIS, because it would be an
> incompatible change. We may consider applying this change in GeoAPI 4.0 or
> Apache SIS 2.0. This change implies:
> * In {{DefaultMedium}}, change the return and parameter type of {{getName()}}
> and {{setName(…)}}.
> * Deprecated or remove {{MD_MediumNameCode}} adapter.
> See https://github.com/opengeospatial/geoapi/issues/14
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-402) Missing @XmlElement on DefaultMetadata.getCharacterSets()
[
https://issues.apache.org/jira/browse/SIS-402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-402.
---
> Missing @XmlElement on DefaultMetadata.getCharacterSets()
> -
>
> Key: SIS-402
> URL: https://issues.apache.org/jira/browse/SIS-402
> Project: Spatial Information Systems
> Issue Type: Sub-task
> Components: Metadata
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Labels: regression
> Fix For: 1.0
>
>
> ISO 19139:2007 was used to represent language code and character set as two
> different properties. This model matched well the Java {{Locale}} and
> {{Charset}} classes respectively. But ISO 19115-3:2016 merges language and
> character set together. We do not yet have JAXB adapter doing this work. In
> particular, the new {{getCharacterSets()}} method in {{DefaultMetadata}} does
> not yet have its {{\@XmlElement}} annotation.
> After this issue has been fixed, we should remove the {{REGRESSION}} hack in
> {{org.apache.sis.test.integration.MetadataTest}}.
> Resolving this issue may depend on [GeoAPI issue
> #28|https://github.com/opengeospatial/geoapi/issues/28].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-377) Latitude of natural origin = -90 wrongly rejected for Transverse Mercator
[
https://issues.apache.org/jira/browse/SIS-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-377.
---
> Latitude of natural origin = -90 wrongly rejected for Transverse Mercator
> -
>
> Key: SIS-377
> URL: https://issues.apache.org/jira/browse/SIS-377
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Referencing
>Affects Versions: 0.6, 0.7, 0.8
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.0
>
>
> Attempt to parse the following WKT (from [EPSG geodetic
> dataset|http://www.epsg-registry.org/export.htm?wkt=urn:ogc:def:crs:EPSG::22197])
> {noformat}
> PROJCRS["Campo Inchauspe / Argentina 7",
> BASEGEODCRS["Campo Inchauspe",
> DATUM["Campo Inchauspe",
> ELLIPSOID["International 1924",6378388,297,LENGTHUNIT["metre",1.0,
> CONVERSION["Argentina zone 7",
> METHOD["Transverse Mercator",ID["EPSG",9807]],
> PARAMETER["Latitude of natural
> origin",-90,ANGLEUNIT["degree",0.01745329252]],
> PARAMETER["Longitude of natural
> origin",-54,ANGLEUNIT["degree",0.01745329252]],
> PARAMETER["Scale factor at natural origin",1,SCALEUNIT["unity",1.0]],
> PARAMETER["False easting",750,LENGTHUNIT["metre",1.0]],
> PARAMETER["False northing",0,LENGTHUNIT["metre",1.0]]],
> CS[cartesian,2],
> AXIS["northing (X)",north,ORDER[1]],
> AXIS["easting (Y)",east,ORDER[2]],
> LENGTHUNIT["metre",1.0],
> ID["EPSG",22197]]
> {noformat}
> causes the following exception:
> {noformat}
> java.text.ParseException: Value ‘Latitude of natural origin’ = -90 is
> invalid. Expected a value in the [-90 … 90] range.
> at
> org.apache.sis.io.wkt.MathTransformParser.parseParameters(MathTransformParser.java:317)
> (...snip...)
> at org.apache.sis.parameter.Verifier.ensureValidValue(Verifier.java:219)
> at
> org.apache.sis.parameter.DefaultParameterValue.setValue(DefaultParameterValue.java:734)
> {noformat}
> Note: {{CRS.forCode("EPSG::22197")}} succeed.
> This issue has been reported [on the mailing
> list|https://lists.apache.org/thread.html/d4e45098cac941c4e130aa50e3fa6b4f349f3bc757e08258fe8b6587@%3Cuser.sis.apache.org%3E].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-458) TransformSeparator should omit unused source dimensions, unless requested otherwise
[
https://issues.apache.org/jira/browse/SIS-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-458.
---
> TransformSeparator should omit unused source dimensions, unless requested
> otherwise
> ---
>
> Key: SIS-458
> URL: https://issues.apache.org/jira/browse/SIS-458
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Referencing
>Affects Versions: 0.8
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.0
>
>
> {{org.apache.sis.referencing.operation.transform.TransformSeparator}} is
> Apache SIS 0.8 unconditionally keep all source dimensions, unless the source
> dimensions to keep were explicitly specified. The behavior should be changed
> by removing all dimensions that are not needed for the target dimensions to
> keep.
> In a milestone toward SIS 1.0, we added a
> {{setTrimSourceDimensions(boolean)}} method. However in practice this flag is
> always {{false}} if source dimensions were explicitly specified. So we
> propose to remove that flag and instead have the behavior selected
> automatically depending on whether source dimension were specified or not. It
> makes the API simpler, by providing better symmetry with the behavior
> regarding target dimensions.
> This is a slightly incompatible change since we are changing the behavior of
> {{TransformSeparator}} when no source dimensions is specified. However we
> believe that the new behavior is closer to the expected one in such situation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-421) Retrofit WarningListener in a more generic EventListener
[
https://issues.apache.org/jira/browse/SIS-421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-421.
---
> Retrofit WarningListener in a more generic EventListener
>
>
> Key: SIS-421
> URL: https://issues.apache.org/jira/browse/SIS-421
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Storage, Utilities
>Affects Versions: 0.8
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.0
>
>
> {{DataStore}} in SIS 1.0-SNAPSHOT (June 2018) have two kind of listeners:
> * The {{org.apache.sis.util.logging}} package defines a {{WarningListener}}
> interface, together with a {{WarningListeners}} helper class.
> * The {{org.apache.sis.storage.event}} package defines a {{ChangeListener}}
> interface, together with {{ChangeEvent}} class. The intent is to have
> different {{ChangeEvent}} subtypes for e.g. structural changes, content
> changes, _etc._
> We should consider renaming the later as {{StoreListener}} and
> {{StoreEvent}}, and define a {{WarningEvent}} class. The old
> {{WarningListener}} could be replaced by this new mechanism. The intent is to
> avoid having two listener mechanism in parallel in data stores.
> It seems that {{WarningListener}} are currently used only in {{DataStore}},
> with the exception of {{org.apache.sis.metadata.sql}} package. So even if
> {{WarningEvent}} become storage-specific, it may not be a big issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-118) Provide convenience shell script for launching the command-line
[
https://issues.apache.org/jira/browse/SIS-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-118.
---
> Provide convenience shell script for launching the command-line
> ---
>
> Key: SIS-118
> URL: https://issues.apache.org/jira/browse/SIS-118
> Project: Spatial Information Systems
> Issue Type: New Feature
> Components: Command line
>Affects Versions: 0.3
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Minor
> Fix For: 0.3, 0.4
>
>
> Currently, the easiest way to launch the command-line is to use the following
> syntax on the JAR file decompressed from the PACK200 file:
> {noformat}
> java -jar sis.jar
> {noformat}
> However the syntax is slightly more complicated if someone wants control on
> the classpath, for example in order to include the UCAR NetCDF libraries (an
> optional dependencies). We may consider providing a small shell script making
> SIS usage easier.
> We could provide a ZIP bundle with the following files:
> * {{README}}
> * {{LICENSE}}
> * {{NOTICE}}
> * {{bin/sis}}
> * {{bin/sis.bat}}
> * {{bin/sis.pack.gz}}
> * {{etc/logging.properties}}
> * {{ext/}}
> * {{log/}}
> The {{bin/sis.pack.gz}} file would be automatically uncompressed into a
> {{sis.jar}} file by the {{bin/sis}} or {{bin/sis.bat}} scripts when first
> needed.
> {{ext/}} would be an initially empty directory where user can put optional
> dependencies if we wishes (e.g. UCAR NetCDF library).
> {{log/}} would we an initially empty directory where we would send log files
> (e.g. the Derby database log files).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-352) Support spatial referencing by geographic identifiers (ISO 19112)
[
https://issues.apache.org/jira/browse/SIS-352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-352.
---
> Support spatial referencing by geographic identifiers (ISO 19112)
> -
>
> Key: SIS-352
> URL: https://issues.apache.org/jira/browse/SIS-352
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Referencing
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 0.8
>
>
> Provide a basic support of [ISO 19112:2003 — Spatial referencing by
> geographic
> identifiers|http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=26017].
> Geographic identifiers are location descriptors such as addresses and grid
> indexes. ISO 19112 describes (among other things) how to map geographic
> identifiers to spatial coordinates. Some keys classes defined by ISO 19112
> are listed below (Apache SIS would not necessarily use exactly the same
> names):
> * {{SpatialReferenceSystemUsingGeographicIdentifier}}
> * {{Gazetteer}}
> * {{LocationType}}
> * {{LocationInstance}}
> The {{Gazetteer}} seems the most interesting part for us, since it is the
> class in charge of converting a geographic identifier to something else
> (_e.g._ a geographic coordinate). It seems that {{Gazetteer}} could be
> compared to the {{MathTransform}} interface that we already implement in the
> following package:
> * {{org.apache.sis.referencing.operation}}
> but working on geographic identifiers instead than coordinates. For this
> reason, I propose to put an ISO 19112 implementation in the following package:
> * {{org.apache.sis.referencing.gazetteer}}
> I have hesitation about whether such package should be in a separated module
> (e.g. {{"sis-referencing-by-identifier"}}) or not, but given that I expect
> the amount of classes to be small I'm not sure it is worth creating a new
> module.
> An implementation of [Military Grid Reference System
> (MGRS)|https://en.wikipedia.org/wiki/Military_Grid_Reference_System] is used
> for experimenting what the API may looks like. Despite its name, MGRS is not
> used only for military purpose. It is used also as a way to organize Earth
> Observation data on Amazon S3 cloud storage.
> Note that Apache SIS already have (since the 0.1 version!) a class that seems
> in the scope of ISO 19112:
> [GeoHashCoder|http://sis.apache.org/apidocs/org/apache/sis/index/GeoHashCoder.html].
> As part of an ISO 19112 support, we could also refactor {{GeoHashCoder}} as
> another implementation, side-by-side with {{MilitaryGridReferenceSystem}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-368) When a coordinate operation change the longitude axis range from [-180 … +180]° to [0 … 360]°, the Envelopes.transform(…) result should be normalized accordingly
[
https://issues.apache.org/jira/browse/SIS-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-368.
---
> When a coordinate operation change the longitude axis range from [-180 …
> +180]° to [0 … 360]°, the Envelopes.transform(…) result should be normalized
> accordingly
> -
>
> Key: SIS-368
> URL: https://issues.apache.org/jira/browse/SIS-368
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Referencing
>Affects Versions: 0.5, 0.6, 0.7
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 0.8
>
>
> There is at least two conventions regarding the range of longitude values:
> -180° to 180° or 0° to 360°. The range is specified with
> {{CoordinateSystemAxis}} minimum and maximum attributes. Most of the times,
> we use the -180° to +180° convention. However when an envelope is transformed
> with {{Envelopes.transform(CoordinateOperation, Envelope)}} method, if the
> longitude range declared in the coordinate system changes, we expect the
> envelope longitude values to be updated accordingly.
> We could invoke {{GeneralEnvelope.normalize()}} after envelope
> transformation, but we don't want to invoke it systematically. If the
> {{CoordinateOperation}} does not change the longitude range, then it is safer
> to let the longitude values as we found them, even if they are slightly
> outside the expected range. Example:
> * If source CRS uses longitudes in the \[-180 … +180\]° range and target CRS
> uses longitudes are in the \[-180 … +180\]° range, then do nothing. Even if
> the transformation result is an envelope spanning 175° to 185° of longitude,
> leave it as-is because the original envelope was probably already crossing
> the anti-meridian (not necessarily using longitudes; we can cross the
> anti-meridian with the Mercator projection too).
> * If source CRS uses longitudes in the \[0 … 360\]° range and target CRS uses
> longitudes are in the \[0 … 360\]° range, do nothing for the same reason than
> above.
> * If source CRS uses longitudes in the \[-180 … +180\]° range and target CRS
> uses longitudes are in the \[0 … 360\]° range, then if the envelope result is
> outside the \[0 … 360\]° range, brings it back to the \[0 … 360\]° range as
> described in {{GeneralEnvelope.normalize()}}.
> * If source CRS uses longitudes in the \[0 … 360\]° range and target CRS uses
> longitudes are in the \[-180 … +180\]° range, then if the envelope result is
> outside the \[-180 … +180\]° range, brings it back to the \[-180 … +180\]°
> range.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-390) When datum shift information are missing, still apply ellipsoid change
[
https://issues.apache.org/jira/browse/SIS-390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-390.
---
> When datum shift information are missing, still apply ellipsoid change
> --
>
> Key: SIS-390
> URL: https://issues.apache.org/jira/browse/SIS-390
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Referencing
>Affects Versions: 0.7
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 0.8
>
>
> For some pairs of CRS, the datum is not the same but Apache SIS is
> nevertheless unable to apply the datum change, either because we didn't found
> explicit information in EPSG geodetic database, or because the datum shift
> depends on a grid file that we don't have. The problem is what to do in such
> case? Apache SIS 0.7 did nothing. Apache SIS 0.8 takes at least the change of
> ellipsoid in account.
> Example: EPSG:4609 — _NAD27(CGQ77)_ uses the Clarke 1866 ellipsoid, which is
> different than the WGS 84 ellipsoid. The coordinate operation from that CRS
> to EPSG:4326 is
> [EPSG:1691|http://epsg-registry.org/?display=entity&urn=urn:ogc:def:coordinateOperation:EPSG::1691].
> That operation requires the {{CGQ77-98.gsb}} datum shift file, which may not
> be installed. In absence of datum shift information, an ellipsoid change can
> still be applied using a Molodensky operation with all geocentric translation
> parameters left to zero. This can be seen in the following fragment in the
> {{MathTransform}} WKT (this fragment is absent if the transform does nothing
> about the datum/ellipsoid change). Note there is a change of 69 meters in the
> semi-major axis length and 169 meters in the semi-minor axis length:
> {noformat}
> Param_MT["Abridged Molodensky",
> Parameter["dim", 2],
> Parameter["src_semi_major", 6378137.0, Unit["metre", 1]],
> Parameter["src_semi_minor", 6356752.314245179, Unit["metre", 1]],
> Parameter["tgt_semi_major", 6378206.4, Unit["metre", 1]],
> Parameter["tgt_semi_minor", 6356583.8, Unit["metre", 1]],
> Parameter["X-axis translation", 0.0, Unit["metre", 1]],
> Parameter["Y-axis translation", 0.0, Unit["metre", 1]],
> Parameter["Z-axis translation", 0.0, Unit["metre", 1]],
> Parameter["Semi-major axis length difference", 69.4, Unit["metre", 1]],
> Parameter["Flattening difference", 3.726463918114448E-5, Unit["unity", 1]]]
> {noformat}
> Apache SIS conservatively reports an "accuracy" of 3 km when there is no
> datum shift operation, no matter if we nevertheless applied an ellipsoid
> change or not.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-412) Add a CRS.findOperations(sourceCRS, targetCRS, …) method
[
https://issues.apache.org/jira/browse/SIS-412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-412.
---
> Add a CRS.findOperations(sourceCRS, targetCRS, …) method
>
>
> Key: SIS-412
> URL: https://issues.apache.org/jira/browse/SIS-412
> Project: Spatial Information Systems
> Issue Type: New Feature
> Components: Referencing
>Affects Versions: 0.7, 0.8
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.0
>
>
> The {{CRS}} utility class provide a {{findOperation(…)}} static method, which
> return only one operation (the one presumed to be the best one). There is
> sometime a need to have the list of all possible operations, and let user
> choose the desired one himself. We should add a {{findOperations(…)}} (plural
> form) which return a list of coordinate operation instead than a single one.
> This task involves a compatibility break at commit 1828112: the protected
> {{CoordinateOperationFinder.createOperationStep(…)}} methods have been
> modified to return {{List}} instead of
> {{CoordinateOperation}}. Since those methods are protected, we hope that they
> were not used much outside SIS.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-221) Hotine Oblique Mercator (EPSG:9812, 9815)
[
https://issues.apache.org/jira/browse/SIS-221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-221.
---
> Hotine Oblique Mercator (EPSG:9812, 9815)
> -
>
> Key: SIS-221
> URL: https://issues.apache.org/jira/browse/SIS-221
> Project: Spatial Information Systems
> Issue Type: Sub-task
> Components: Referencing
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.0
>
>
> We should be able to port most of the code from Geotk {{ObliqueMercator}}
> class, after IP review and alignment with the EPSG formulas described in
> §1.3.6.1 of 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] [Closed] (SIS-413) Units.PSU should have a scale value of 1/1000
[ https://issues.apache.org/jira/browse/SIS-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux closed SIS-413. --- > Units.PSU should have a scale value of 1/1000 > - > > Key: SIS-413 > URL: https://issues.apache.org/jira/browse/SIS-413 > Project: Spatial Information Systems > Issue Type: New Feature > Components: Utilities >Affects Versions: 0.8 >Reporter: Martin Desruisseaux >Assignee: Martin Desruisseaux >Priority: Major > Fix For: 1.0 > > > Sea Water Salinity was used to be measured in g/kg, with values sometime > written with the "‰" symbol (e.g. "35‰"). In modern oceanography, this has > been replaced by _Practical Salinity Unit_ (PSU), with values written without > symbol (e.g. "35"). Strictly speaking, PSU units are not convertible to g/kg. > However the PSU scale is by design very close to the old scale. If someone > nevertheless attempts a conversion between those two scales, we want it to be > close to the identity operation. Currently, the conversion wrongly multiply > or divide values by 1000. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SIS-382) SI multiples not recognized when applied on kilogram
[
https://issues.apache.org/jira/browse/SIS-382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-382.
---
> SI multiples not recognized when applied on kilogram
>
>
> Key: SIS-382
> URL: https://issues.apache.org/jira/browse/SIS-382
> 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
>
>
> Multiplication or division by a power of 10 are automatically replaced by SI
> prefix when applicable. For example {{Units.METRE.multiply(1000)}}
> automatically assigns the "km" symbol to the resulting units. However this
> mechanism does not work with kilogram: {{Units.KILOGRAM.divide(1E6)}} or
> {{Units.GRAM.divide(1000)}} should produce the "mg" unit, but we get "1E-6 ·
> kg" instead.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-448) Extension to CF-conventions for localization grid smaller than data in netCDF
[
https://issues.apache.org/jira/browse/SIS-448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-448.
---
> Extension to CF-conventions for localization grid smaller than data in netCDF
> -
>
> Key: SIS-448
> URL: https://issues.apache.org/jira/browse/SIS-448
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Storage
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.0
>
>
> The _Global Change Observation Mission - Climate (GCOM-C)_ data have content
> like below (simplified):
> {noformat}
> group: Geometry_data {
> variables:
> float Latitude(161, 126)
> string Unit = "degree"
> string Dim0 = "Line grids"
> string Dim1 = "Pixel grids"
> int Resampling_interval = 10
> float Longitude(161, 126)
> string Unit = "degree"
> string Dim0 = "Line grids"
> string Dim1 = "Pixel grids"
> int Resampling_interval = 10
> }
> group: Image_data {
> variables:
> ushort SST(1599, 1250)// Note: different size than (latitude,
> longitude) variables.
> string dim0 = "Line grids"
> string dim1 = "Pixel grids"
> string Unit = "degree"
> }
> {noformat}
> The size of latitude and longitude variables is not the same than the size of
> image data. In this case, even if reader correctly identifies {{Latitude}}
> and {{Longitude}} as the variables to use for building a localization grid,
> we are still unable to associate the {{SST}} variable to those axes because
> they have no dimension in common. However if we interpret {{dim0}} and
> {{dim1}} attributes as _"Name of dimension 0"_ and _"Name of dimension 1"_
> respectively, then we can associate the same dimension *names* to all those
> variables: namely {{"Line grids"}} and {"Pixel grids"}} in above example.
> Using those names, we deduce that the ({{data_y}}, {{data_x}}) dimensions in
> the {{SST}} variable are mapped to the ({{grid_y}}, {{grid_x}}) dimensions in
> the localization grid.
> The feature is an extension to CF-conventions, as I'm not aware of equivalent
> mechanism in CF at this time. The {{coordinates}} attributes is not exactly
> the same since it tells us which variable to use, but not which dimensions
> (an ambiguity still exists if the variable has 2 or more dimensions).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-414) Multiplication symbol should be omitted when the unit is Units.UNITY
[
https://issues.apache.org/jira/browse/SIS-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-414.
---
> Multiplication symbol should be omitted when the unit is Units.UNITY
>
>
> Key: SIS-414
> URL: https://issues.apache.org/jira/browse/SIS-414
> 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
>
>
> When formatting a unit which is {{Units.UNITY}} scaled to some value, since
> {{Units.UNITY}} has no symbol, attempts to format it produce confusing
> strings. Example with the _number of icebergs per 100 km²_:
> | Symbol in netCDF file: | {{1e-2 km-2}} |
> | SIS 0.8 representation: | {{1.0E-8⋅∕m²}} |
> Note the multiplication immediately followed by division sign above.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-405) Upgrade or remove JAXB annotations of ImmutableIdentifier
[
https://issues.apache.org/jira/browse/SIS-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-405.
---
> Upgrade or remove JAXB annotations of ImmutableIdentifier
> -
>
> Key: SIS-405
> URL: https://issues.apache.org/jira/browse/SIS-405
> Project: Spatial Information Systems
> Issue Type: Sub-task
> Components: Metadata, Referencing
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.0
>
>
> For the upgrade of metadata XML format from legacy ISO 19139:2007 to newer
> ISO 19115-3:2016, all classes in {{org.apache.sis.metadata.iso}} package and
> sub-packages have their JAXB annotations upgraded except
> {{ImmutableIdentifier}}. The later is used mostly by {{sis-referencing}},
> which is still (un)marshalled according GML 3.2. The consequence is that
> {{DefaultIdentifier}} and {{ImmutableIdentifier}} - which are supposed to be
> two implementations of the same {{Identifier}} interface - now use two
> different set of JAXB annotations. This may be a cause of confusion.
> We should upgrade JAXB annotations to ISO 19115-3:2016 on
> {{ImmutableIdentifier}} too, with verification that it preserves
> compatibility with GML 3.2 (un)marshalling in {{sis-referencing}}.
> {color:red}Update (August 2019):{color} an alternative is to remove JAXB
> annotations completely for that particular class. See comments.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-438) Make SIS compatible with latest Java versions
[
https://issues.apache.org/jira/browse/SIS-438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-438.
---
> Make SIS compatible with latest Java versions
> -
>
> Key: SIS-438
> URL: https://issues.apache.org/jira/browse/SIS-438
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Utilities
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Blocker
> Fix For: 1.0
>
>
> Apache SIS make two assumptions which are not valid anymore since Java 9:
> * It assumes that JavaDB is available in the Java installation directory.
> Note that this is not true anymore even in Java 8 since latest updates (e.g.
> 1.8.0_191).
> * It assumes that JAXB is on the classpath. This is not true anymore since
> Java 9.
> Actions to take:
> * We should remove the search for JavaDB in
> {{org.apache.sis.internal.metadata.sql.Initializer.forJavaDB}} lines 511 to
> 525.
> * We need to make above method tolerant to {{ClassNotFoundException}}.
> * We should add Derby dependency with runtime scope in {{sis-console}}.
> * We need to add JAXB-API dependency in a Java 11 profile of root {{pom.xml}}
> file.
> In addition of making sure that JUnit tests pass, we also need to test
> {{sis-console}} command-line application and {{sis-openoffice}} add-in.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-455) Compute length of cubic Bézier curve
[
https://issues.apache.org/jira/browse/SIS-455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-455.
---
> Compute length of cubic Bézier curve
>
>
> Key: SIS-455
> URL: https://issues.apache.org/jira/browse/SIS-455
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Geometry, Referencing
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.0
>
>
> We need a way to estimate the length of a cubic Bézier curve from its
> starting point at _t_=0 to an arbitrary _t_ value where _t_ ∈ [0…1].
> Conversely, we need to estimate the _t_ parameter for a given length since
> the starting point. There is no exact solution for this problem, but we may
> estimate the length using Legendre-Gauss approach documented in [A Primer on
> Bézier Curves|https://pomax.github.io/bezierinfo/#arclength] page. The
> accuracy is determined by the number [Gaussian Quadrature Weights and
> Abscissae|https://pomax.github.io/bezierinfo/legendre-gauss.html] used. For
> example with 3 terms:
> {noformat}
> w₁ = 0.; a₁ = 0;
> w₂ = 0.5556; a₂ = -0.7745966692414834;
> w₃ = 0.5556; a₃ = +0.7745966692414834;
> length(t) ≈ t/2 * (w₁*f(a₁*t/2 - t/2) + w₂*f(a₂*t/2 - t/2) + w₃*f(a₃*t/2 -
> t/2))
> {noformat}
> with _f(t)_ defined as {{hypot(x′(t), y′(t))}} and with _x′(t)_ and _y′(t)_
> the first derivatives of Bézier equations for _x(t)_ and _y(t)_.
> Once we have the length for a given _t_ value, we can try to find the
> converse by using an iterative approach as described in the [Moving Along a
> Curve with Specified
> Speed|https://www.geometrictools.com/Documentation/MovingAlongCurveSpecifiedSpeed.pdf]
> paper from geometric tools.
> Once we are able to estimate the _t_ parameters for a given length, we should
> delete the {{Bezier.isValid(x, y)}} method (and consequently remove its use
> and the {{TransformException}} in the {{curve}} method). Instead, given the
> geodesic distance from Bézier start point to ¼ of the distance from start
> point to end point, estimate the _t_ parameter at that position. It should be
> a value close but not identical to _t_≈¼. We can then compute the (_x_, _y_)
> coordinates of the point on that curve at that _t_ parameter value and
> compare with the expected coordinates. It should (hopefully) be a point
> closer to expected than the point computed at exactly _t_=¼, thus removing
> the need for the {{Bezier.isValid(x,y)}} hack.
> Alternatively, all the above is a complicated way to say that we want the
> shortest distance between a point on the geodesic path and a point on the
> curve which is known to be at position close to (but not exactly at) _t_≈¼
> and _t_≈¾.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-432) Using BETA2007.gsb grid throws IllegalArgumentException
[
https://issues.apache.org/jira/browse/SIS-432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-432.
---
> Using BETA2007.gsb grid throws IllegalArgumentException
> ---
>
> Key: SIS-432
> URL: https://issues.apache.org/jira/browse/SIS-432
> Project: Spatial Information Systems
> Issue Type: Bug
>Affects Versions: 0.8
>Reporter: Ferenc Hechler
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.0
>
> Attachments: patch_BETA2007_gsb.png
>
>
> The following program transforms Gauß-Krüger coordinates (used in Germany) to
> the WGS84 format:
> {code:title=Main.java}
> public static void main(String[] args) throws Exception {
> double hochwert = 550.0;
> double rechtswert = 350.0;
>
> CoordinateReferenceSystem sourceCRS = CRS.forCode("EPSG:31467");
> CoordinateReferenceSystem targetCRS = CRS.forCode("EPSG:4326");
> CoordinateOperation operation = CRS.findOperation(sourceCRS, targetCRS,
> null);
>
> DirectPosition ptSrc = new DirectPosition2D(hochwert, rechtswert);
> DirectPosition ptDst = operation.getMathTransform().transform(ptSrc, null);
> System.out.println("Source: " + ptSrc);
> System.out.println("Target: " + ptDst);
> System.out.println("Expected: POINT(49.63670826166641 8.99895896840875)");
> }
> {code}
>
> Running the program gives the following output:
> {code:title=console.log}
> Okt 09, 2018 10:45:00 PM
> org.apache.sis.referencing.operation.CoordinateOperationFinder createOperation
> WARNUNG: Can not parse “BETA2007.gsb” as a file in the NTv2 format.
> Source: POINT(550 350)
> Target: POINT(49.636710642245184 8.99896356404719)
> Expected: POINT(49.63670826166641 8.99895896840875)
> {code}
> As you can see, the result is not as expected.
> The reason is, that the grid shift file BETA2007.gsb was not found, as the
> warning before already stated: *WARNUNG: Can not parse “BETA2007.gsb” as a
> file in the NTv2 format.*
> The grid shift file "BETA2007.gsb" can be downloaded from the following
> website:
> http://crs.bkg.bund.de/crseu/crs/descrtrans/BeTA/de_dhdn2etrs_beta.php
> There is a link to the ASCII version
> [BETA2007.gsa|http://crs.bkg.bund.de/crseu/crs/descrtrans/BeTA/BETA2007.gsa]
> and the binary format, which is needed for Apache SIS
> [BETA2007.gsb|http://crs.bkg.bund.de/crseu/crs/descrtrans/BeTA/BETA2007.gsb]
> I downloaded the BETA2007.gsb file and copied it into the current working
> directory (or into the project folder in Eclipse).
> Then I started the same main program again and got the follwoing exception:
> {code:title=console.log}
> Exception in thread "main"
> org.apache.sis.referencing.factory.InvalidGeodeticParameterException: Value
> ‘grid.cellPrecision’ = ? is invalid. Expected a number greater than 0.
> at
> org.apache.sis.referencing.operation.transform.DefaultMathTransformFactory.createParameterizedTransform(DefaultMathTransformFactory.java:1050)
> at
> org.apache.sis.referencing.factory.sql.EPSGDataAccess.createCoordinateOperation(EPSGDataAccess.java:2927)
> at
> org.apache.sis.referencing.factory.AuthorityFactoryProxy$34.create(AuthorityFactoryProxy.java:515)
> at
> org.apache.sis.referencing.factory.AuthorityFactoryProxy$34.create(AuthorityFactoryProxy.java:513)
> at
> org.apache.sis.referencing.factory.ConcurrentAuthorityFactory.create(ConcurrentAuthorityFactory.java:1679)
> at
> org.apache.sis.referencing.factory.ConcurrentAuthorityFactory.createCoordinateOperation(ConcurrentAuthorityFactory.java:1590)
> at
> org.apache.sis.internal.referencing.DeferredCoordinateOperation.create(DeferredCoordinateOperation.java:71)
> at
> org.apache.sis.referencing.operation.CoordinateOperationRegistry.search(CoordinateOperationRegistry.java:506)
> at
> org.apache.sis.referencing.operation.CoordinateOperationRegistry.createOperation(CoordinateOperationRegistry.java:333)
> at
> org.apache.sis.referencing.operation.CoordinateOperationFinder.createOperation(CoordinateOperationFinder.java:236)
> at
> org.apache.sis.referencing.operation.CoordinateOperationFinder.createOperationStep(CoordinateOperationFinder.java:358)
> at
> org.apache.sis.referencing.operation.CoordinateOperationFinder.createOperation(CoordinateOperationFinder.java:250)
> at
> org.apache.sis.referencing.operation.DefaultCoordinateOperationFactory.createOperation(DefaultCoordinateOperationFactory.java:811)
> at org.apache.sis.referencing.CRS.findOperation(CRS.java:640)
> at de.hechler.apsistest.GK3toWGS84.main(GK3toWGS84.java:23)
> Caused by: java.lang.IllegalArgumentException: Value ‘grid.cellPrecision’ = ?
> is invalid. Expected a number greater than 0.
> at
> org.apache.sis.referencin
