[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