[jira] [Created] (SIS-526) Replace org.apache.sis.storage.geotiff.Tags by javax.imageio.plugins.tiff
Martin Desruisseaux created SIS-526:
---
Summary: Replace org.apache.sis.storage.geotiff.Tags by
javax.imageio.plugins.tiff
Key: SIS-526
URL: https://issues.apache.org/jira/browse/SIS-526
Project: Spatial Information Systems
Issue Type: Wish
Components: Storage
Affects Versions: 1.1
Reporter: Martin Desruisseaux
SIS has a list of TIFF tags in package-privete
{{org.apache.sis.storage.geotiff.Tags}} class. Since Java 9, the
{{javax.imageio.plugins.tiff}} package provide the same functionality. The
standard package is richer in term of tag information (name, values, etc.);
using it would both remove unnecessary duplication and allows richer
{{GeoTIFFStore.getNativeMetadata()}} result.
This issue depends on the migration to Java 9, which must be done first.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (SIS-320) Enable SIS to run is security-constrained environments
[
https://issues.apache.org/jira/browse/SIS-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux resolved SIS-320.
-
Fix Version/s: 1.2
Resolution: Won't Fix
{{java.security.AccessController}} is deprecated for removal since Java 17. All
usages of this class will be removed.
> Enable SIS to run is security-constrained environments
> --
>
> Key: SIS-320
> URL: https://issues.apache.org/jira/browse/SIS-320
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Metadata, Referencing, Storage, Utilities
>Affects Versions: 0.3, 0.4, 0.5, 0.6, 0.7
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Labels: Jigsaw
> Fix For: 1.2
>
>
> Wraps some code necessary to SIS working in
> {{AccessController.doPrivileged(...)}} blocks. Examples:
> {code:java}
> String dir = AccessController.doPrivileged((PrivilegedAction) () -> {
> return System.getenv("SIS_DATA");
> });
> {code}
> We should not wrap all security-sensitive request for information, but only
> those that are needed for SIS working. Examples:
> * Environment variable value for {{SIS_DATA}}.
> * Property value for {{"java.naming.factory.initial"}},
> {{"derby.system.home"}}.
> * Call to {{Field.setAccessible(true)}} in {{clone()}} methods for setting
> final fields.
> Information for which we do *not* request privileged actions at this time:
> * MBean registration.
> * Property value for {{"java.home"}}.
> * Call to {{Field.setAccessible(true)}} on deserialization for setting final
> transient fields.
> Initial patch for SIS has been submitted by Guilhem Légal.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (SIS-525) Remove AccessController usage
Martin Desruisseaux created SIS-525:
---
Summary: Remove AccessController usage
Key: SIS-525
URL: https://issues.apache.org/jira/browse/SIS-525
Project: Spatial Information Systems
Issue Type: New Feature
Components: Features, Metadata, Referencing, Utilities
Affects Versions: 1.0, 0.8, 0.7, 0.6, 0.5, 0.4, 0.3
Reporter: Martin Desruisseaux
Assignee: Martin Desruisseaux
Fix For: 1.2
{{java.security.AccessController}} is deprecated for removal since Java 17. All
usage of this class should be removed. There would be no real lost of
functionality since we never completed the security policy work.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (SIS-524) Image masking based on a geometry
[ https://issues.apache.org/jira/browse/SIS-524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux resolved SIS-524. - Resolution: Fixed > Image masking based on a geometry > - > > Key: SIS-524 > URL: https://issues.apache.org/jira/browse/SIS-524 > Project: Spatial Information Systems > Issue Type: New Feature > Components: Coverage >Reporter: Martin Desruisseaux >Assignee: Martin Desruisseaux >Priority: Major > Fix For: 1.2 > > > Add an image operator for applying a mask on a `GridCoverage`: all pixel > values outside a geometry would be replaced by a fill value. The coverage and > the geometry are in arbitrary CRS, not necessarily the same. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SIS-524) Image masking based on a geometry
[ https://issues.apache.org/jira/browse/SIS-524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux updated SIS-524: Summary: Image masking based on a geometry (was: Image mask based on a geometry) > Image masking based on a geometry > - > > Key: SIS-524 > URL: https://issues.apache.org/jira/browse/SIS-524 > Project: Spatial Information Systems > Issue Type: New Feature > Components: Coverage >Reporter: Martin Desruisseaux >Assignee: Martin Desruisseaux >Priority: Major > Fix For: 1.2 > > > Add an image operator for applying a mask on a `GridCoverage`: all pixel > values outside a geometry would be replaced by a fill value. The coverage and > the geometry are in arbitrary CRS, not necessarily the same. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SIS-524) Image mask based on a geometry
Martin Desruisseaux created SIS-524: --- Summary: Image mask based on a geometry Key: SIS-524 URL: https://issues.apache.org/jira/browse/SIS-524 Project: Spatial Information Systems Issue Type: New Feature Components: Coverage Reporter: Martin Desruisseaux Assignee: Martin Desruisseaux Fix For: 1.2 Add an image operator for applying a mask on a `GridCoverage`: all pixel values outside a geometry would be replaced by a fill value. The coverage and the geometry are in arbitrary CRS, not necessarily the same. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SIS-523) Download of EPSG data must use https
[
https://issues.apache.org/jira/browse/SIS-523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux resolved SIS-523.
-
Resolution: Fixed
> Download of EPSG data must use https
>
>
> Key: SIS-523
> URL: https://issues.apache.org/jira/browse/SIS-523
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Referencing
>Affects Versions: 0.7, 0.8, 1.0, 1.1
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.2
>
>
> The {{sis-javafx}} and {{sis-console}} modules offer to users to download the
> EPSG geodetic dataset if they accept [EPSG terms of
> use|https://epsg.org/terms-of-use.html] (the license is shown in a popup
> window or in the console). Data are downloaded from Maven central using a
> {{"http://repo1.maven.org/maven2/org/apache/sis/non-free/…"}} URL. But
> {{"http:"}} URLs do not work anymore with Maven Central; we need to use
> {{"https:"}}. The URL needs to be updated.
> We should take this opportunity for improving error message in JavaFX
> application. Currently it fails silently without any feedback to user.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SIS-237) Modified Azimuthal Equidistant (EPSG:9832)
[ https://issues.apache.org/jira/browse/SIS-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17429197#comment-17429197 ] Martin Desruisseaux commented on SIS-237: - Attempt to derive formulas for Jacobian matrix are [on SVN repository|https://svn.apache.org/repos/asf/sis/analysis/Modified%20Azimuthal%20Equidistant.wxmx]. > Modified Azimuthal Equidistant (EPSG:9832) > -- > > Key: SIS-237 > URL: https://issues.apache.org/jira/browse/SIS-237 > Project: Spatial Information Systems > Issue Type: Sub-task > Components: Referencing >Reporter: Martin Desruisseaux >Assignee: Martin Desruisseaux >Priority: Minor > Fix For: 1.1 > > > For various islands in Micronesia. See §1.3.16.1 in IOGP Publication 373-7-2 > – Geomatics Guidance Note number 7, part 2 – April 2015. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SIS-523) Download of EPSG data must use https
Martin Desruisseaux created SIS-523:
---
Summary: Download of EPSG data must use https
Key: SIS-523
URL: https://issues.apache.org/jira/browse/SIS-523
Project: Spatial Information Systems
Issue Type: Bug
Components: Referencing
Affects Versions: 1.1, 1.0, 0.8, 0.7
Reporter: Martin Desruisseaux
Assignee: Martin Desruisseaux
Fix For: 1.2
The {{sis-javafx}} and {{sis-console}} modules offer to users to download the
EPSG geodetic dataset if they accept [EPSG terms of
use|https://epsg.org/terms-of-use.html] (the license is shown in a popup window
or in the console). Data are downloaded from Maven central using a
{{"http://repo1.maven.org/maven2/org/apache/sis/non-free/…"}} URL. But
{{"http:"}} URLs do not work anymore with Maven Central; we need to use
{{"https:"}}. The URL needs to be updated.
We should take this opportunity for improving error message in JavaFX
application. Currently it fails silently without any feedback to user.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (SIS-522) IllegalArgumentException in GridExtent.toEnvelope(…)
[
https://issues.apache.org/jira/browse/SIS-522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux resolved SIS-522.
-
Resolution: Fixed
Fixed in commit {{c929255718ee7bfccea289c8ad6c2f85713e5eb6}}.
> IllegalArgumentException in GridExtent.toEnvelope(…)
>
>
> Key: SIS-522
> URL: https://issues.apache.org/jira/browse/SIS-522
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Coverage
>Affects Versions: 1.1
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.2
>
>
> {{GridExtent.toEnvelope(…)}} throws an {{IllegalArgumentException}} if the
> extent has 3 dimensions with one of the dimension of type
> {{DimensionNameType.TIME}} (the problem does not occur if the extent has 4
> dimensions).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (SIS-522) IllegalArgumentException in GridExtent.toEnvelope(…)
Martin Desruisseaux created SIS-522:
---
Summary: IllegalArgumentException in GridExtent.toEnvelope(…)
Key: SIS-522
URL: https://issues.apache.org/jira/browse/SIS-522
Project: Spatial Information Systems
Issue Type: Improvement
Components: Coverage
Affects Versions: 1.1
Reporter: Martin Desruisseaux
Assignee: Martin Desruisseaux
Fix For: 1.2
{{GridExtent.toEnvelope(…)}} throws an {{IllegalArgumentException}} if the
extent has 3 dimensions with one of the dimension of type
{{DimensionNameType.TIME}} (the problem does not occur if the extent has 4
dimensions).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (SIS-521) Malformed SQL query in SQLStore
[
https://issues.apache.org/jira/browse/SIS-521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux resolved SIS-521.
-
Resolution: Fixed
Fixed in commit {{aa29b4de091d56fe0cd27b0dc4db13098231ee98}}.
> Malformed SQL query in SQLStore
> ---
>
> Key: SIS-521
> URL: https://issues.apache.org/jira/browse/SIS-521
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Storage
>Affects Versions: 1.1
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.2
>
>
> {{SQLStore}} creates an illegal SQL statement when filters are specified but
> can not be represented as an SQL query (i.e. when all filters have to be
> executed in Java). The SQL query contains a {{WHERE}} keyword with nothing
> after it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (SIS-521) Malformed SQL query in SQLStore
Martin Desruisseaux created SIS-521:
---
Summary: Malformed SQL query in SQLStore
Key: SIS-521
URL: https://issues.apache.org/jira/browse/SIS-521
Project: Spatial Information Systems
Issue Type: Improvement
Components: Storage
Affects Versions: 1.1
Reporter: Martin Desruisseaux
Assignee: Martin Desruisseaux
Fix For: 1.2
{{SQLStore}} creates an illegal SQL statement when filters are specified but
can not be represented as an SQL query (i.e. when all filters have to be
executed in Java). The SQL query contains a {{WHERE}} keyword with nothing
after it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (SIS-520) SQLStore should avoid creating features with cyclic associations
Martin Desruisseaux created SIS-520:
---
Summary: SQLStore should avoid creating features with cyclic
associations
Key: SIS-520
URL: https://issues.apache.org/jira/browse/SIS-520
Project: Spatial Information Systems
Issue Type: Improvement
Components: Storage
Affects Versions: 1.1, 1.0
Reporter: Martin Desruisseaux
Assignee: Martin Desruisseaux
Fix For: 1.2
When {{SLStore}} analyses a database schema for table _A_, if anoter table _B_
has a foreigner key to table _A_, then {{SQLStore}} consider table _B_ as a
"children" of _A_. It creates a property in feature _A_ containing a collection
of associations to feature _B_ instances. However in Apache SIS 1.1, the
feature _B_ instances keep a reference to their parent (the feature _A_). The
result is a cyclic graph, which can cause problems as SIS-519. While SIS can
generally handle recursivity, client code may not. So it is probably better to
modify {{SQLStore}} for not providing an association from "children features"
to their "parent feature".
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (SIS-520) SQLStore should avoid creating features with cyclic associations
[
https://issues.apache.org/jira/browse/SIS-520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux resolved SIS-520.
-
Resolution: Fixed
Fixed in commit {{911a413919d06cd4a549a4365c461e02adb622d3}}.
> SQLStore should avoid creating features with cyclic associations
>
>
> Key: SIS-520
> URL: https://issues.apache.org/jira/browse/SIS-520
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Storage
>Affects Versions: 1.0, 1.1
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.2
>
>
> When {{SLStore}} analyses a database schema for table _A_, if anoter table
> _B_ has a foreigner key to table _A_, then {{SQLStore}} consider table _B_ as
> a "children" of _A_. It creates a property in feature _A_ containing a
> collection of associations to feature _B_ instances. However in Apache SIS
> 1.1, the feature _B_ instances keep a reference to their parent (the feature
> _A_). The result is a cyclic graph, which can cause problems as SIS-519.
> While SIS can generally handle recursivity, client code may not. So it is
> probably better to modify {{SQLStore}} for not providing an association from
> "children features" to their "parent feature".
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (SIS-519) Never-ending loop in AbstractFeature.equals/hashCode
[
https://issues.apache.org/jira/browse/SIS-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427032#comment-17427032
]
Martin Desruisseaux edited comment on SIS-519 at 10/11/21, 9:29 AM:
Fixed in commit {{f311c23a97b22ce473631101737132012320cf8a}}.
was (Author: desruisseaux):
Fixed in commit {{911a413919d06cd4a549a4365c461e02adb622d3}}.
> Never-ending loop in AbstractFeature.equals/hashCode
>
>
> Key: SIS-519
> URL: https://issues.apache.org/jira/browse/SIS-519
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Features
>Affects Versions: 0.5, 0.6, 0.7, 0.8, 1.0, 1.1
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.2
>
>
> If two feature instances have cyclic associations (a property of feature _A_
> is an association to feature _B_, and a property of feature _B_ is an
> association to feature _A_), the {{equals(Object)}} and {{hashCode()}}
> methods of those features fall in an infinite loop. We need to add a safety
> against infinite recursivity.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (SIS-519) Never-ending loop in AbstractFeature.equals/hashCode
Martin Desruisseaux created SIS-519: --- Summary: Never-ending loop in AbstractFeature.equals/hashCode Key: SIS-519 URL: https://issues.apache.org/jira/browse/SIS-519 Project: Spatial Information Systems Issue Type: Bug Components: Features Affects Versions: 1.1, 1.0, 0.8, 0.7, 0.6, 0.5 Reporter: Martin Desruisseaux Assignee: Martin Desruisseaux Fix For: 1.2 If two feature instances have cyclic associations (a property of feature _A_ is an association to feature _B_, and a property of feature _B_ is an association to feature _A_), the `equals(Object)` and `hashCode()` methods of those features fall in an infinite loop. We need to add a safety against infinite recursivity. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SIS-519) Never-ending loop in AbstractFeature.equals/hashCode
[
https://issues.apache.org/jira/browse/SIS-519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-519:
Description:
If two feature instances have cyclic associations (a property of feature _A_ is
an association to feature _B_, and a property of feature _B_ is an association
to feature _A_), the {{equals(Object)}} and {{hashCode()}} methods of those
features fall in an infinite loop. We need to add a safety against infinite
recursivity.
was:
If two feature instances have cyclic associations (a property of feature _A_ is
an association to feature _B_, and a property of feature _B_ is an association
to feature _A_), the `equals(Object)` and `hashCode()` methods of those
features fall in an infinite loop. We need to add a safety against infinite
recursivity.
> Never-ending loop in AbstractFeature.equals/hashCode
>
>
> Key: SIS-519
> URL: https://issues.apache.org/jira/browse/SIS-519
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Features
>Affects Versions: 0.5, 0.6, 0.7, 0.8, 1.0, 1.1
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.2
>
>
> If two feature instances have cyclic associations (a property of feature _A_
> is an association to feature _B_, and a property of feature _B_ is an
> association to feature _A_), the {{equals(Object)}} and {{hashCode()}}
> methods of those features fall in an infinite loop. We need to add a safety
> against infinite recursivity.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (SIS-519) Never-ending loop in AbstractFeature.equals/hashCode
[
https://issues.apache.org/jira/browse/SIS-519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux resolved SIS-519.
-
Resolution: Fixed
Fixed in commit {{911a413919d06cd4a549a4365c461e02adb622d3}}.
> Never-ending loop in AbstractFeature.equals/hashCode
>
>
> Key: SIS-519
> URL: https://issues.apache.org/jira/browse/SIS-519
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Features
>Affects Versions: 0.5, 0.6, 0.7, 0.8, 1.0, 1.1
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.2
>
>
> If two feature instances have cyclic associations (a property of feature _A_
> is an association to feature _B_, and a property of feature _B_ is an
> association to feature _A_), the `equals(Object)` and `hashCode()` methods of
> those features fall in an infinite loop. We need to add a safety against
> infinite recursivity.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (SIS-96) WKB Support
[ https://issues.apache.org/jira/browse/SIS-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux resolved SIS-96. Fix Version/s: 1.1 Assignee: Martin Desruisseaux Resolution: Fixed A WKB supports is available (indirectly) in SIS 1.1. When reading a geometry column from a database, SIS delegates to the underlying geometry library. The following libraries are supported (at user choice): * Java Topology Suite (JTS) * ESRI geometry API We do not have a public API at this time; this is internal mechanic for now. But developers using JTS (for example) can use the JTS API directly. > WKB Support > --- > > Key: SIS-96 > URL: https://issues.apache.org/jira/browse/SIS-96 > Project: Spatial Information Systems > Issue Type: Wish > Components: Geometry >Affects Versions: 0.3 > Environment: All >Reporter: Adam Estrada >Assignee: Martin Desruisseaux >Priority: Minor > Labels: WKB, WKT > Fix For: 1.1 > > > I would like to have WKB Support in SIS. I can't seem to find a class that > has direct support for it right now (maybe I am completely missing something > here), so my intent is to add it. What I am curious about is whether or not > this is part of the code base that will be ported over from GeoTK. Martin? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SIS-475) Md5 and SHA are deprecated
[ https://issues.apache.org/jira/browse/SIS-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux resolved SIS-475. - Resolution: Fixed > Md5 and SHA are deprecated > -- > > Key: SIS-475 > URL: https://issues.apache.org/jira/browse/SIS-475 > Project: Spatial Information Systems > Issue Type: Bug >Affects Versions: 1.0 >Reporter: Sebb >Assignee: Martin Desruisseaux >Priority: Major > Fix For: 1.1 > > > MD5 and SHA were deprecated as hash methods quite some time ago. > They should no longer be used. > Please update your releases to use SHA256 or SHA512 and remove/update any > references to MD5 and SHA in download documentation. > https://www.apache.org/dev/release-distribution#sigs-and-sums -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SIS-285) Make OSGi compatible
[
https://issues.apache.org/jira/browse/SIS-285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-285.
---
> Make OSGi compatible
>
>
> Key: SIS-285
> URL: https://issues.apache.org/jira/browse/SIS-285
> Project: Spatial Information Systems
> Issue Type: New Feature
> Components: Build process
>Affects Versions: 0.3, 0.4, 0.5
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 0.6
>
>
> The {{pom.xml}} files use the OSGi's {{bundle}} packaging together with the
> use of {{org.apache.felix}} {{maven-bundle-plugin}}, but this is not
> sufficient for allowing Apache SIS to run in an OSGi container. More work are
> needed regarding our use of {{java.util.ServiceLoader}} among other.
> Olivier Nouguier investigated the issues.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-399) When renaming "xsi:type" value, may need to declare a new namespace
[
https://issues.apache.org/jira/browse/SIS-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-399.
---
> When renaming "xsi:type" value, may need to declare a new namespace
> ---
>
> Key: SIS-399
> URL: https://issues.apache.org/jira/browse/SIS-399
> Project: Spatial Information Systems
> Issue Type: Sub-task
> Components: Metadata
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Labels: regression
> Fix For: 1.0
>
>
> {{TransformingReader}} converts XML element and attribute names from legacy
> standards to new standards, but there is one special case where instead of
> the attribute name, we need to convert attribute value: the {{xsi:type}}
> attribute. Example:
> {code:xml}
>
>
> Some text in default language
>
>
> Same text in
> French
>
>
>
>
> {code}
> Conversion from legacy ISO 19139:2007 to new ISO 19115-3:2016 result in
> something like (omitting non-pertinent prefixes for this discussion):
> {code:xml}
> <…:…>
> <…:name xsi:type="lan:PT_FreeText_PropertyType">
> Some text in default language
>
>
> Same text in
> French
>
>
>
> <…:…>
> {code}
> {{gmd}} prefix has been replaced by {{lan}} prefix in various places, but
> this is not a concern for elements like {{lan:PT_FreeText}} because the
> {{XMLEvent}} created by {{TransformingReader}} already contain the full
> namespace URI. The problem is in the {{xsi:type}} value, where we do not
> specify the namespace ourselves. Attempts to unmarshal this converted XML
> result in an error message complaining the the {{lan}} prefix has not been
> bound. The workaround would be to replace the following fragment:
> {code:xml}
> <…:… xsi:type="gmd:PT_FreeText_PropertyType">
> {code}
> by
> {code:xml}
> <…:… xmlns:lan="http://standards.iso.org/iso/19115/-3/lan/1.0;
> xsi:type="gmd:PT_FreeText_PropertyType">
> {code}
> In other words, we need to insert a local {{Namespace}} event which was not
> present in the original XML document. In the meantime, the workaround is to
> add a {{xmlns:lan}} declaration in the root XML element of the document to
> parse. This workaround is applied in the {{"2007/PositionalAccuracy.xml"}}
> test file, and should be removed when this issue is fixed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-424) Create Feature instances from a SQL database
[
https://issues.apache.org/jira/browse/SIS-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-424.
---
> Create Feature instances from a SQL database
>
>
> Key: SIS-424
> URL: https://issues.apache.org/jira/browse/SIS-424
> Project: Spatial Information Systems
> Issue Type: New Feature
> Components: Storage
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.0
>
>
> Implements a {{SQLStore}} capable to create {{org.opengis.feature.Feature}}
> instances from the content of a database. The store takes a one or more
> tables at construction time. Each enumerated table is represented by a
> {{FeatureType}}. Each relation defined by a foreigner key is represented by
> an {{FeatureAssociationRole}} to another feature (with transitive
> dependencies automatically resolved), and the other columns are represented
> by {{AttributeType}}.
> This work was initially started by Johann Sorel.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-430) Remove PACK200 usage
[
https://issues.apache.org/jira/browse/SIS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-430.
---
> Remove PACK200 usage
>
>
> Key: SIS-430
> URL: https://issues.apache.org/jira/browse/SIS-430
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Build process, OpenOffice
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.0
>
>
> The PACK200 format was used for building the {{open-office}} add-in and the
> binary distribution. But PACK200 will be removed in future Java versions. We
> need to remove our use of it. This task impacts at least the following files:
> * *master:*
> ** {{application/pom.xml}}
> ** {{application/sis-console/pom.xml}}
> ** {{application/sis-console/src/main/artifact/README}}
> ** {{application/sis-console/src/main/artifact/bin/sis}}
> ** {{application/sis-openoffice/pom.xml}}
> **
> {{application/sis-openoffice/src/main/java/org/apache/sis/openoffice/Registration.java}}
> **
> {{core/sis-build-helper/src/main/java/org/apache/sis/internal/maven/*.java}}
> * *site:*
> ** {{content/build.mdtext}}
> In addition, we should modify the {{sis-openoffice}} module for uncompressing
> {{sis-embedded-data.jar}} file. Since the JAR files are compressed in the
> {{sis.oxt}} file, it should not make a difference on the size of the
> distributed binary file. However it makes a big difference on the performance
> after {{sis.oxt}} registration: Derby is much faster in using embedded
> database if the JAR file is uncompressed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-315) NetCDF: convention interface and parsing utilities
[ https://issues.apache.org/jira/browse/SIS-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux closed SIS-315. --- > NetCDF: convention interface and parsing utilities > -- > > Key: SIS-315 > URL: https://issues.apache.org/jira/browse/SIS-315 > 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: Conventions (version 2).patch, RestecConvention.java, > netcdfconvention.patch > > > NetCDF has a wide range of conventions, this patch include a start of api and > utility methods the most used NetCDF-CF convention. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SIS-445) NetCDF store should be robust to localization grid crossing anti-meridian
[
https://issues.apache.org/jira/browse/SIS-445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-445.
---
> NetCDF store should be robust to localization grid crossing anti-meridian
> -
>
> Key: SIS-445
> URL: https://issues.apache.org/jira/browse/SIS-445
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Referencing, Storage
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.0
>
>
> NetCDF files often have a "longitude" and "latitude" variables (names may
> vary) containing longitude and latitude values of every pixels. For raster
> data in Pacific ocean, the range of longitude sometime cross the
> anti-meridian, where longitude values suddenly drop from +180° to -180°. This
> discontinuity breaks our attempt to compute an affine transform approximation
> in {{LocalizationGridBuilder}}, produces wrong results when interpolating
> values in this area of the grid, and makes more difficult to converge when
> performing an inverse transformation.
> The proposed fix is to detect when such discontinuity happens, and add or
> subtract 360° on one side in order to get continuous values. Inconvenient is
> that some values become outside the [-180 … 180] range. In some case it can
> be outside the [0 … 360] range too (i.e. the data may turn around the Earth
> more than one lap).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-444) GridCoverageResource interface for raster data
[
https://issues.apache.org/jira/browse/SIS-444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-444:
Description:
All {{DataStore}} in Apache SIS provides their data as a collection of
{{Resource}}. There is different kinds of resources; SIS 0.8 already provides
{{FeatureSet}} for resources made of a stream of {{Feature}} instances
(typically geometries associated to some property values). We need another
specialization of resources, {{GridCoverageResource}}, for raster data. Two key
elements of grid coverages are:
* {{GridGeometry}}, which describe the _domain_ of a coverage (e.g. the raster
size in pixels and the geographic envelope).
* {{SampleDimension}} which describe the _range_ of a coverage (e.g. the
meaning of values stored in raster bands).
was:
All {{DataStore}} in Apache SIS provides their data as a collection of
`Resource`. There is different kinds of resources; SIS 0.8 already provides
{{FeatureSet}} for resources made of a stream of `Feature` instances (typically
geometries associated to some property values). We need another specialization
of resources, {{GridCoverageResource}}, for raster data. Two key elements of
grid coverages are:
* {{GridGeometry}}, which describe the _domain_ of a coverage (e.g. the raster
size in pixels and the geographic envelope).
* {{SampleDimension}} which describe the _range_ of a coverage (e.g. the
meaning of values stored in raster bands).
> GridCoverageResource interface for raster data
> --
>
> Key: SIS-444
> URL: https://issues.apache.org/jira/browse/SIS-444
> Project: Spatial Information Systems
> Issue Type: New Feature
> Components: Storage
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.0
>
>
> All {{DataStore}} in Apache SIS provides their data as a collection of
> {{Resource}}. There is different kinds of resources; SIS 0.8 already provides
> {{FeatureSet}} for resources made of a stream of {{Feature}} instances
> (typically geometries associated to some property values). We need another
> specialization of resources, {{GridCoverageResource}}, for raster data. Two
> key elements of grid coverages are:
> * {{GridGeometry}}, which describe the _domain_ of a coverage (e.g. the
> raster size in pixels and the geographic envelope).
> * {{SampleDimension}} which describe the _range_ of a coverage (e.g. the
> meaning of values stored in raster bands).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-444) GridCoverageResource interface for raster data
[
https://issues.apache.org/jira/browse/SIS-444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-444.
---
> GridCoverageResource interface for raster data
> --
>
> Key: SIS-444
> URL: https://issues.apache.org/jira/browse/SIS-444
> Project: Spatial Information Systems
> Issue Type: New Feature
> Components: Storage
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.0
>
>
> All {{DataStore}} in Apache SIS provides their data as a collection of
> {{Resource}}. There is different kinds of resources; SIS 0.8 already provides
> {{FeatureSet}} for resources made of a stream of {{Feature}} instances
> (typically geometries associated to some property values). We need another
> specialization of resources, {{GridCoverageResource}}, for raster data. Two
> key elements of grid coverages are:
> * {{GridGeometry}}, which describe the _domain_ of a coverage (e.g. the
> raster size in pixels and the geographic envelope).
> * {{SampleDimension}} which describe the _range_ of a coverage (e.g. the
> meaning of values stored in raster bands).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-385) Inaccurate formulas in DistanceUtils
[
https://issues.apache.org/jira/browse/SIS-385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-385.
---
> Inaccurate formulas in DistanceUtils
>
>
> Key: SIS-385
> URL: https://issues.apache.org/jira/browse/SIS-385
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Referencing
>Affects Versions: 0.1-incubating, 0.2-incubating, 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 {{DistanceUtils}} class has the following problems:
> * Inaccurate formula in {{getPointOnGreatCircle}}.
> * Inaccurate formula in {{getHaversineDistance}}.
> * Misnamed {{getHaversineDistance}} method.
> Charles Karney kindly provided descriptions of the problems [on the developer
> mailing
> list|https://lists.apache.org/thread.html/85ba228a3191f2952f2e37caa489f929daffd491da50484972af4aef@%3Cdev.sis.apache.org%3E],
> together with proposed fixes. One possible action is to deprecate
> {{DistanceUtils}} in favor of something like the {{GeodeticCalculator}} class
> [in the Geotk
> project|http://www.geotoolkit.org/apidocs/org/geotoolkit/referencing/GeodeticCalculator.html].
> That class is a port in Java of following Fortran code:
> * ftp://ftp.ngs.noaa.gov/pub/pcsoft/for_inv.3d/source/forward.for subroutine
> DIRECT1.
> * ftp://ftp.ngs.noaa.gov/pub/pcsoft/for_inv.3d/source/inverse.for subroutines
> GPNARC (version 25.26) and GPNHRI (version 200208.09) written by Robert
> (Sid) Safford.
> But we may take another source if suitable, for example
> [https://geographiclib.sourceforge.io/|https://geographiclib.sourceforge.io/].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-446) NetCDF store should be robust to non-linear localization grid
[
https://issues.apache.org/jira/browse/SIS-446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-446.
---
> NetCDF store should be robust to non-linear localization grid
> -
>
> Key: SIS-446
> URL: https://issues.apache.org/jira/browse/SIS-446
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Referencing, Storage
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.0
>
>
> Localization grid in netCDF files contain (longitude, latitude) values of all
> pixels. {{LocalizationGridBuilder}} first computes a linear (affine)
> approximation of a localization grid, then stores only the residual in its
> internal grid. The intent is to have small residual, which make easier to
> compute the _inverse_ transformation (given a latitude and longitude, find
> indices of the pixel at that location). However if the localization grid is
> non-linear, then the affine transform is a poor approximation of that grid
> and the residuals are high. High residual make _inverse_ transforms hard to
> compute, which result sometime in {{TransformException}} being throw with a
> "no convergence" error message.
> In practice, the localization grid in netCDF files is often used for storing
> the results of a map projection. The Mercator projection for example is often
> used. The proposed fix is to allow {{LocalizationGridBuilder}} to try to
> transform the grid using a given list of map projections and see if one of
> those projections results in a grid closer to a linear transform. In other
> words, we should be able to "guess" what the projection may be. It is okay if
> the guess is not a perfect match; if the residuals become smalls, it will
> resolve the "no convergence" errors.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-386) Replace DefaultEllipsoid.orthodromicDistance(…) method
[
https://issues.apache.org/jira/browse/SIS-386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-386.
---
> Replace DefaultEllipsoid.orthodromicDistance(…) method
> --
>
> Key: SIS-386
> URL: https://issues.apache.org/jira/browse/SIS-386
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Referencing
>Affects Versions: 0.4, 0.5, 0.6, 0.7, 0.8
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.0
>
>
> The {{DefaultEllipsoid.orthodromicDistance}} method has the following
> problems:
> * Could have a better name.
> * It does not converge in some situations.
> * The wraparound over some non-convergence problems is itself erroneous.
> Charles Karney kindly listed the problems [on the developer mailing
> list|https://lists.apache.org/thread.html/eee29fc53123e94b74c22737413b2572d3e4c9e4f111847fefb6a3af@%3Cdev.sis.apache.org%3E].
> A possible action would be to deprecate {{orthodromicDistance}}, to be
> replaced by the same {{GeodeticCalculator}} (or any other name) class than
> the one proposed for SIS-385.
> *Historical note:* {{orthodromicDistance}} was defined in the
> {{DefaultEllipsoid}} class because it made easy to override the method with
> code optimized for the spherical case. A future version could also override
> the method with code for triaxial ellipsoid. But experience in the Geotk
> project suggest that this method is almost never used, since
> {{GeodeticCalculator}} is used instead.
> As an alternative to deprecate {{DefaultEllipsoid.orthodromicDistance}}, we
> could keep it (after renaming), fix the issues identified by Charles, and
> design {{GeodeticCalculator}} as a class that use {{DefaultEllipsoid}} under
> the hood instead than re-implementing its own algorithm.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-395) Need a public way to get connection to "SpatialMetadata" database
[
https://issues.apache.org/jira/browse/SIS-395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-395.
---
> Need a public way to get connection to "SpatialMetadata" database
> -
>
> Key: SIS-395
> URL: https://issues.apache.org/jira/browse/SIS-395
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Metadata, Referencing
>Affects Versions: 0.5, 0.6, 0.7, 0.8
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.0
>
>
> There is currently no public API for getting the {{javax.sql.DataSource}}
> instance for Apache SIS {{SpatialMetadata}} database. There is
> {{Initializer.getDataSource()}} method in the
> {{org.apache.sis.internal.metadata.sql}} but this is non-public API, subject
> to change in any future SIS version and will not be accessible in Java 9
> (unless the restriction is bypassed by Java options on the command-line).
> A standard way to provide {{DataSource}} in Java is with _Java Naming and
> Directory Interface_ (JNDI). However there is no JNDI environment by default
> in standard Java installation; JNDI are rather provided by containers like
> Tomcat. We could provide our own micro-JNDI when no environment is installed,
> but it may be disruptive as installing our own JNDI environment would have a
> JVM-wide impact.
> A last-resort approach would be a {{public static DataSource getXXX()}}
> method somewhere, but it would not follow standard mechanisms (JNDI,
> dependency injection, _etc._).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-331) Verify the mapping from ISO 19115:2003 to ISO 19115:2014
[
https://issues.apache.org/jira/browse/SIS-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-331.
---
> Verify the mapping from ISO 19115:2003 to ISO 19115:2014
>
>
> Key: SIS-331
> URL: https://issues.apache.org/jira/browse/SIS-331
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Metadata
>Affects Versions: 0.6, 0.7, 0.8
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.0
>
>
> ISO 19115 metadata implementations in {{org.apache.sis.metadata.iso}}
> packages have hard-coded mapping between ISO 19115 published in 2003 and the
> revision published in 2014. We need to verify if this mapping matches the
> mapping performed by the XSLT sheet published by ISO. See:
> *
> https://github.com/ISO-TC211/XML/wiki/Migrating-ISO-19139-and-19139-2-to-19115-3
> * http://standards.iso.org/iso/19115/resources/transforms/ISO19139
> In particular, what should be the mapping of (now deprecated)
> {{Format.name}}? Current implementation delegates to
> {{Citation.alternateTitle}}. Is that correct? If not, we need to revisit
> {{org.apache.sis.internal.simple.SimpleFormat}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-223) Orthographic (EPSG:9840)
[
https://issues.apache.org/jira/browse/SIS-223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-223.
---
> Orthographic (EPSG:9840)
>
>
> Key: SIS-223
> URL: https://issues.apache.org/jira/browse/SIS-223
> Project: Spatial Information Systems
> Issue Type: Sub-task
> Components: Referencing
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Minor
> Fix For: 1.1
>
>
> The orthographic case is a special case of _"Vertical perspective
> (ortographic case)"_ with all points on the ellipsoid (height = 0).
> An {{Orthographic}} file is available on Geotk, but can not be ported as-is
> in SIS for licensing reason, except the projection derivative formulas and
> the work on (de)normalization matrices. However we can restart from the
> formulas given in the EPSG guide. But EPSG gives ellipsoidal formulas instead
> than spherical ones, so the work is a little bit more complicated.
> See §1.3.18 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-452) Satellite-tracking projections
[ https://issues.apache.org/jira/browse/SIS-452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux closed SIS-452. --- > Satellite-tracking projections > -- > > Key: SIS-452 > URL: https://issues.apache.org/jira/browse/SIS-452 > Project: Spatial Information Systems > Issue Type: Sub-task > Components: Referencing >Reporter: Martin Desruisseaux >Assignee: Martin Desruisseaux >Priority: Major > Fix For: 1.1 > > > _Satellite-tracking projections_ are projections in which groundtracks for > satellites orbiting the Earth with same orbital parameters are shown as > straight line on the map. This projection would be useful for improving the > convergence problem when using localization grid such as the ones encoded in > netCDF files (SIS-446). This projection has no EPSG code, but is described in > Snyder's book at page 230 to 238. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SIS-483) Some CoordinateOperation created from EPSG database get wrong name/identifier/remarks
[
https://issues.apache.org/jira/browse/SIS-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-483.
---
> Some CoordinateOperation created from EPSG database get wrong
> name/identifier/remarks
> -
>
> Key: SIS-483
> URL: https://issues.apache.org/jira/browse/SIS-483
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Referencing
>Affects Versions: 1.0
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.1
>
>
> Calls to {{CRS.findOperation(sourceCRS, targetCRS)}} sometime produces a
> {{CoordinateOperation}} with wrong metadata (name, identifiers, remarks,
> scope). For example requesting an operation from EPSG::4202 to EPSG::4283
> should produce the following operation (when there is no NTv2 datum shift
> grid available):
> {noformat}
> CoordinateOperation["AGD66 to GDA94 (19)",
> SourceCRS[GeodeticCRS["AGD66", (...snip...)],
> TargetCRS[GeodeticCRS["GDA94", (...snip...)],
> Method["Coordinate Frame rotation (geog2D domain)"], (...snip...)],
> OperationAccuracy[0.5],
> Scope["Recommended for mid-accuracy use in A.C.T. 1m accuracy."],
> Area["Australia - Australian Capital Territory."],
> BBox[-35.93, 148.76, -35.12, 149.40],
> Id["EPSG", 5827, "9.7",
> URI["urn:ogc:def:coordinateOperation:EPSG:9.7:5827"]],
> Remark["Replaces nationally-derived transformation code 1458."]]
> {noformat}
> But we get instead the name _"Ellipsoidal 2D CS. Axes: longitude, latitude.
> Orientations: east, north. UoM: degree"_ together with identifier and remarks
> of EPSG::6424 coordinate system. The accuracy, scope, area and bounding box
> are lost. The bug is in {{EPSGDataAccess}} where metadata are accidentally
> overwritten before we finished to construct the {{CoordinateOperation}}. This
> bug affects only metadata; the coordinate operation parameters are unaffected
> so the numerical results of coordinate operations should be the same.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-486) Some map projections produce wrong results when |Δλ| > 180°
[ https://issues.apache.org/jira/browse/SIS-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux closed SIS-486. --- > Some map projections produce wrong results when |Δλ| > 180° > --- > > Key: SIS-486 > URL: https://issues.apache.org/jira/browse/SIS-486 > Project: Spatial Information Systems > Issue Type: Task > Components: Referencing >Affects Versions: 0.8, 1.0 >Reporter: Martin Desruisseaux >Assignee: Martin Desruisseaux >Priority: Major > Fix For: 1.1 > > > Some map projections produce a wrong result when the difference Δλ between > the longitude value and the central meridian is greater than 180°. For most > map projections there is no problem because the Δλ value is used directly in > trigonometric functions which perform automatically the range reduction for > us. For example sin(200°) = sin(-160°). However there is a few map > projections where the longitude value is transformed (e.g. multiplied by some > factor) _before_ to be given to a trigonometric function. For such map > projections, we must apply the range reduction ourselves. > Impacted map projection methods in Apache SIS 1.0 are: > * Albers Equal Area (EPSG::9822) > * Lambert Conic Conformal (EPSG::9801, 9802, 9826) > * Oblique Stereographic (EPSG::9809) > * Satellite-Tracking projection > This problem impacts in particular the cases when one of above projections is > used in an area crossing the anti-meridian (±180°). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SIS-480) Change ISO schema locations from "http:" to "https:"
[ https://issues.apache.org/jira/browse/SIS-480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux closed SIS-480. --- > Change ISO schema locations from "http:" to "https:" > > > Key: SIS-480 > URL: https://issues.apache.org/jira/browse/SIS-480 > Project: Spatial Information Systems > Issue Type: Task > Components: Metadata >Affects Versions: 1.0 >Reporter: Martin Desruisseaux >Assignee: Martin Desruisseaux >Priority: Major > Labels: JAXB > Fix For: 1.1 > > > XSD files in the following directories: > * http://www.isotc211.org/2005 > * http://standards.iso.org/iso/ > Moved to HTTPS protocol: > * https://www.isotc211.org/2005 > * https://standards.iso.org/iso/ > We need up update the links in test XML files. The old "http" protocol does > not work with our JUnit tests (no redirection happens). Note that XSD files > in http://schemas.opengis.net/ are still under "http" only. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SIS-477) Add GridCoverage.evaluate(DirectPosition) method
[
https://issues.apache.org/jira/browse/SIS-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-477.
---
> Add GridCoverage.evaluate(DirectPosition) method
>
>
> Key: SIS-477
> URL: https://issues.apache.org/jira/browse/SIS-477
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Features
>Affects Versions: 1.0
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.1
>
>
> Add a {{evaluate(DirectPosition)}} method in the {{GridCoverage}} class for
> evaluating the sample values at a geographic or projected coordinate. This
> method should apply coordinate conversions as needed and optionally
> interpolate.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-479) Change default namespace of legacy "gmd" metadata
[
https://issues.apache.org/jira/browse/SIS-479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-479.
---
> Change default namespace of legacy "gmd" metadata
> -
>
> Key: SIS-479
> URL: https://issues.apache.org/jira/browse/SIS-479
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Metadata
>Affects Versions: 1.0
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Labels: JAXB
> Fix For: 1.1
>
>
> Changes the default {{gmd}} namespace from:
> * http://schemas.opengis.net/iso/19139/20070417/
> To
> * http://www.isotc211.org/2005/
> and update the {{org.apache.sis.xml.XML}} documentation accordingly. Note
> that the new namespace do not match exactly XSD file locations because XSD
> files are now under https protocol. Example:
> http://schemas.opengis.net/iso/19139/20070417/gco/gcoBase.xsd
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-282) Geographic Offset by Interpolation of Gridded Data (EPSG:9613, 9615, 9633)
[ https://issues.apache.org/jira/browse/SIS-282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux closed SIS-282. --- > Geographic Offset by Interpolation of Gridded Data (EPSG:9613, 9615, 9633) > -- > > Key: SIS-282 > URL: https://issues.apache.org/jira/browse/SIS-282 > Project: Spatial Information Systems > Issue Type: Sub-task > Components: Referencing >Reporter: Martin Desruisseaux >Assignee: Martin Desruisseaux >Priority: Major > Fix For: 0.7 > > > This family of methods includes: > * NADCON (EPSG:9613) > * NTv2 (EPSG:9615) > * OSTN (EPSG:9633) > See §2.4.4.4 in IOGP Publication 373-7-2 – Geomatics Guidance Note number 7, > part 2 – April 2015. > The main difficulty will be to decide how to get the data file. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SIS-488) Handle wrap-around longitude in NADCON grid
[
https://issues.apache.org/jira/browse/SIS-488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-488.
---
> Handle wrap-around longitude in NADCON grid
> ---
>
> Key: SIS-488
> URL: https://issues.apache.org/jira/browse/SIS-488
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Referencing
>Affects Versions: 0.7, 0.8, 1.0
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.1
>
>
> The NADCON grid for Alaska ({{"alaska.las"}} and {{"alaska.los"}} files) have
> a domain of validity ranging from -194° to -127.875° of longitude and 46° to
> 77.125° of latitude. So it has a part defined beyond the -180° limit, with
> longitude values between -194° and -180°. When asking a coordinate
> transformation at longitude 170°, the {{InterpolatedTransform}} class should
> understand that this 170° longitude is actually located at -190° longitude in
> the coordinate system of its NADCON grid.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-492) Remove support for JavaDB (JDK 8)
[
https://issues.apache.org/jira/browse/SIS-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-492.
---
> Remove support for JavaDB (JDK 8)
> -
>
> Key: SIS-492
> URL: https://issues.apache.org/jira/browse/SIS-492
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Metadata, Referencing
>Affects Versions: 1.0
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Minor
> Labels: JDK9
> Fix For: 1.1
>
>
> Apache SIS was used to try to open the {{SpatialMetadata}} database (which
> contains the EPSG dataset) using the Derby driver on the classpath, or if no
> such driver is found using the JavaDB driver embedded in the JDK from Java 6
> to Java 8. But JavaDB has been removed from the JDK in Java 9. We
> nevertheless kept the code looking for JavaDB because SIS was still
> compatible with Java 8. But even JDK 8 removed JavaDB since update 181 (JDK
> 8u181). That update expired one year and half ago, in October 16, 2018 (was
> released in July 17, 2018). Consequently there is no longer any reason to
> keep the code looking for JavaDB.
> * Reference: [Update 181 release
> note|https://www.oracle.com/technetwork/java/javase/8u181-relnotes-4479407.html]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-218) Cassini-Soldner (EPSG:9806)
[ https://issues.apache.org/jira/browse/SIS-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux closed SIS-218. --- > Cassini-Soldner (EPSG:9806) > --- > > Key: SIS-218 > URL: https://issues.apache.org/jira/browse/SIS-218 > Project: Spatial Information Systems > Issue Type: Sub-task > Components: Referencing >Reporter: Martin Desruisseaux >Assignee: Martin Desruisseaux >Priority: Minor > Fix For: 1.1 > > > The Cassini-Soldner projection looks like the Transverse Mercator projection > and was more extensively used in past centuries. It would still be useful to > port it for historical data. The code in Geotk was originally started by an > external contributor. We need to rewrite the formulas for the coordinate > projection and inverse projection, using the EPSG guide. > Note that the formulas for the projection derivative can be ported as-is. > IP review: https://svn.apache.org/repos/asf/sis/ip-review/CassiniSoldner.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (SIS-495) Resampling trims one pixel when transform is identity and interpolation is nearest
[
https://issues.apache.org/jira/browse/SIS-495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-495.
---
> Resampling trims one pixel when transform is identity and interpolation is
> nearest
> --
>
> Key: SIS-495
> URL: https://issues.apache.org/jira/browse/SIS-495
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Referencing
>Reporter: Johann Sorel
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.1
>
>
> The new resample removes the right most pixel when transform is identity and
> interpolation is set to nearest.
>
> Test case :
> {code:java}
> /**
> * Tests resample with an identity transform and a coverage extent change.
> *
> * @throws TransformException if some coordinates can not be transformed
> to the target grid geometry.
> */
> @Test
> @Ignore
> public void testExtentIdentity() throws TransformException {
> final CoordinateReferenceSystem crs =
> CommonCRS.WGS84.normalizedGeographic();
> final BufferedImage image = new BufferedImage(2, 2,
> BufferedImage.TYPE_BYTE_GRAY);
> final WritablePixelIterator ite = WritablePixelIterator.create(image);
> for (int x = 0; x < 2; x++) {
> for (int y = 0; y < 2; y++) {
> ite.moveTo(x, y);
> ite.setSample(0, 10);
> }
> }
> final AffineTransform2D gridToCrs = new AffineTransform2D(1, 0, 0,
> -1, 0, 0);
> final GridCoverageBuilder gcb = new GridCoverageBuilder();
> gcb.setValues(image);
> gcb.setDomain(new GridGeometry(null, CELL_CENTER, gridToCrs, crs));
> final GridCoverage coverage = gcb.build();
> GridGeometry targetGrid = new GridGeometry(new GridExtent(4, 4),
> CELL_CENTER, gridToCrs, crs);
> final GridCoverage target = resample(coverage, targetGrid);
> Raster data = target.render(null).getData();
> Assert.assertEquals(10, data.getSample(0, 0, 0));
> Assert.assertEquals(10, data.getSample(1, 0, 0));
> Assert.assertEquals( 0, data.getSample(2, 0, 0));
> Assert.assertEquals( 0, data.getSample(3, 0, 0));
> Assert.assertEquals(10, data.getSample(0, 1, 0));
> Assert.assertEquals(10, data.getSample(1, 1, 0));
> Assert.assertEquals( 0, data.getSample(2, 1, 0));
> Assert.assertEquals( 0, data.getSample(3, 1, 0));
> Assert.assertEquals( 0, data.getSample(0, 2, 0));
> Assert.assertEquals( 0, data.getSample(1, 2, 0));
> Assert.assertEquals( 0, data.getSample(2, 2, 0));
> Assert.assertEquals( 0, data.getSample(3, 2, 0));
> }{code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-485) Replace GridCoverage.evaluate(DirectPosition, …) method
[
https://issues.apache.org/jira/browse/SIS-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-485.
---
> Replace GridCoverage.evaluate(DirectPosition, …) method
> ---
>
> Key: SIS-485
> URL: https://issues.apache.org/jira/browse/SIS-485
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Features
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.1
>
>
> The following method has been added in the {{GridCoverage}} class in the
> development branch:
> {code:java}
> public double[] evaluate(final DirectPosition point, double[] buffer) throws
> CannotEvaluateException;
> {code}
> However this method is inefficient if invoked for more than one point (which
> is a typical scenario). It may trig many readings of small areas, construct
> many times the same {{CoordinateOperation}}, _etc._ Furthermore it does not
> allow users to control the interpolatipn method.
> An alternative approach could be to define a separated {{Evaluator}} class
> with methods for setting the interpolation types among other. All coordinates
> to evaluate could be specified in advance, allowing {{Evaluator}} to perform
> only one larger read operation instead than many small operations.
> We may keep {{GridCoverage.evaluate}} as a convenience method when there is
> really only one point to evaluate. But we would need to clarify at least the
> policy regarding interpolation method.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-496) GridCoverage.forConvertedValues(true) sometime creates an image that can not store NaN values
[
https://issues.apache.org/jira/browse/SIS-496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-496.
---
> GridCoverage.forConvertedValues(true) sometime creates an image that can not
> store NaN values
> -
>
> Key: SIS-496
> URL: https://issues.apache.org/jira/browse/SIS-496
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Features
>Affects Versions: 1.0
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.1
>
>
> A call to {{GridCoverage.forConvertedValues(true)}} is supposed to create a
> {{GridCoverage}} where all sample values have been converted to "geophysics"
> values (i.e. values in the units of measurement given by
> {{SampleDimension.getUnits()}}). If the values before conversion had some
> sentinel values used for missing data (e.g. "999 = no data"), then those
> values shall be converted to NaN values. However in Apache SIS 1.0, the
> {{forConvertedValues(true)}} method sometime fails to recognize that it needs
> to change the image data type from an integer type to a floating point type
> in order to be able to store NaN values.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-493) Raster reprojection
[
https://issues.apache.org/jira/browse/SIS-493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-493.
---
> Raster reprojection
> ---
>
> Key: SIS-493
> URL: https://issues.apache.org/jira/browse/SIS-493
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Features
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.1
>
>
> Implements the reprojection of rasters. A {{ResampledImage}} class will be
> provided.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-499) CommonCRS.WGS84.geographic() fails to initialize with JDK 11.0.8
[
https://issues.apache.org/jira/browse/SIS-499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-499.
---
> CommonCRS.WGS84.geographic() fails to initialize with JDK 11.0.8
>
>
> Key: SIS-499
> URL: https://issues.apache.org/jira/browse/SIS-499
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Build process
>Affects Versions: 1.0
>Reporter: Roland
>Assignee: Martin Desruisseaux
>Priority: Major
> Attachments: Test.zip, pom.Failure.xml, stacktrace_Eclipse.txt,
> stacktrace_Maven.txt
>
>
> We have in the constructor of a class the following code:
> {{CoordinateReferenceSystem targetCRS = CommonCRS.WGS84.geographic();}}
> When we run the Maven build with Java 1.8.0_252 the build succeeds. Running
> with OpenJDK 11.0.8 it fails with
> java.util.ServiceConfigurationError:
> org.opengis.referencing.datum.DatumFactory:
> org.apache.sis.referencing.factory.GeodeticObjectFactory Unable to get public
> no-arg constructor
> at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:581)
> at java.base/java.util.ServiceLoader.getConstructor(ServiceLoader.java:672)
> at
> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(ServiceLoader.java:1232)
> at
> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(ServiceLoader.java:1264)
> at java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1299)
> at java.base/java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1384)
> at
> org.apache.sis.internal.system.DefaultFactories.forClass(DefaultFactories.java:94)
> at
> org.apache.sis.internal.system.DefaultFactories.forBuildin(DefaultFactories.java:136)
> at
> org.apache.sis.referencing.factory.sql.EPSGFactory.factory(EPSGFactory.java:291)
> at
> org.apache.sis.referencing.factory.sql.EPSGFactory.(EPSGFactory.java:278)
> at
> org.apache.sis.referencing.AuthorityFactories.EPSG(AuthorityFactories.java:122)
> at org.apache.sis.referencing.CommonCRS.factory(CommonCRS.java:1815)
> at org.apache.sis.referencing.CommonCRS.geographic(CommonCRS.java:635)
> at
> at.weberhofer.webcommons_geo.converter.PointConverter.(PointConverter.java:39)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-379) Upgrade to ISO 19103:2015
[
https://issues.apache.org/jira/browse/SIS-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-379.
---
> Upgrade to ISO 19103:2015
> -
>
> Key: SIS-379
> URL: https://issues.apache.org/jira/browse/SIS-379
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Utilities
>Affects Versions: 0.8, 1.0
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.1
>
>
> The {{GenericName}}, {{Record}}, {{RecordType}} and {{Measure}} hierarchies
> of types are derived from ISO 19103:2005. The revision published in 2015
> completes or clarifies some API and also adds some new types (e.g.
> {{DirectedMeasure}} for vectors like velocity or acceleration). We should
> review our API in light of ISO 19103:2015.
> This may require proposing changes back into GeoAPI. But we can start
> experimenting in Apache SIS implementation before GeoAPI changes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-417) Metadata panel
[ https://issues.apache.org/jira/browse/SIS-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux closed SIS-417. --- > Metadata panel > -- > > Key: SIS-417 > URL: https://issues.apache.org/jira/browse/SIS-417 > Project: Spatial Information Systems > Issue Type: New Feature > Components: GUI, Metadata >Reporter: Smaniotto Enzo >Assignee: Martin Desruisseaux >Priority: Trivial > Fix For: 1.1 > > Attachments: FXFeatureTable.java, FeatureMapLayer.java, MapItem.java, > MapLayer.java, MetadataNode.java, MetadataOverview.java, ResourceView.java, > WorldMap360x180.png > > > This tool provide a window to select and view file metadata. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SIS-489) Inaccurate result for MGI Ferro transform (see test case attached)
[
https://issues.apache.org/jira/browse/SIS-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux resolved SIS-489.
-
Resolution: Not A Bug
I'm closing as "not a bug" because I believe that the bug is on the software
that produced the expected values. In order to obtain those values, we need to
replace a coordinate operation parameter value (the _Longitude rotation_
parameter) by a value taken elsewhere (the _Greenwich longitude_ value of the
prime meridian). If it was the correct thing to do, I think that EPSG would
have provided that value in the coordinate operation parameters instead of
expecting us to ignore the longitude rotation parameter value. Maybe the slight
difference between _Longitude rotation_ and _Greenwich longitude_ values is
because the former is not a rotation to WGS84, but a rotation to MGI 1901,
while the later is (maybe) a rotation to WGS84.
Please feel free to reopen this issue if above analysis is incorrect.
> Inaccurate result for MGI Ferro transform (see test case attached)
> --
>
> Key: SIS-489
> URL: https://issues.apache.org/jira/browse/SIS-489
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Referencing
>Affects Versions: 1.0
>Reporter: Olivier Lhemann
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.1
>
>
> {code:java}
> public void TransformTest() throws FactoryException,
> MismatchedDimensionException, TransformException {
> double latitude = 46.72;
> double longitude = 16;
> double x = -25097.740155822;
> double y = 175686.952118893;
> CRSAuthorityFactory crsFactory = CRS.getAuthorityFactory("EPSG");
> CoordinateOperationAuthorityFactory opFactory =
> (CoordinateOperationAuthorityFactory) crsFactory;
> // MGI (Ferro) to WGS 84 (1)
> CoordinateOperation datumOperation =
> opFactory.createCoordinateOperation("3966");
> // MGI (Ferro) / Austria GK East Zone
> CoordinateReferenceSystem targetCRS =
> crsFactory.createCoordinateReferenceSystem("31253");
> // normalize the axis for the target
> targetCRS =
> AbstractCRS.castOrCopy(targetCRS).forConvention(AxesConvention.DISPLAY_ORIENTED);
> CoordinateOperation targetOperation =
> CRS.findOperation(datumOperation.getSourceCRS(), targetCRS, null);
> /*
> * We have two operations to concatenate
> */
> MathTransform step1 = datumOperation.getMathTransform().inverse();
> MathTransform step2 = targetOperation.getMathTransform();
> MathTransform completeTransform = MathTransforms.concatenate(step1,
> step2);
> /*
> * transform to x,y in one step
> */
> DirectPosition source = new DirectPosition2D(latitude, longitude);
> DirectPosition target = completeTransform.transform(source, null);
> double[] coordinate = target.getCoordinate();
> //System.out.println(operation.getSourceCRS().toString());
> Assert.assertEquals(x, coordinate[0], 0.1);
> Assert.assertEquals(y, coordinate[1], 0.1);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SIS-489) Inaccurate result for MGI Ferro transform (see test case attached)
[
https://issues.apache.org/jira/browse/SIS-489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17419305#comment-17419305
]
Martin Desruisseaux commented on SIS-489:
-
Hello Olivier. I investigated this issue and I would like a confirmation of
what should be the right answer. The core issue is with the value of the
_longitude rotation_ parameter in the EPSG:3966 concatenated operation. It can
be checked online in the EPSG registry as below.
* Go on https://epsg.org/concatenated-operation_3966/MGI-Ferro-to-WGS-84-1.html
* Click on _Source CRS: MGI (Ferro)_ for expanding details about the source CRS.
* In the expanded section, click on _Datum: Militar-Geographische Institut
(Ferro)_.
* In the expanded datum section, click on _Prime Meridian: Ferro_.
* Note the value of the _Greenwich longitude_ parameter: it is *17°40'00" W*.
* Back to the main section, click on _Operation 1: MGI (Ferro) to MGI 1901 (1)_.
* Note the value of the _Longitude offset_ parameter: it is *17°39'46.02" W*.
So we are in the (unusual?) case where in order to rotate to the Greenwich
longitude, the coordinate operation explicitly tells us to apply a rotation
slightly different than the _Greenwich longitude_ value defined by the prime
meridian. Apache SIS follows exactly the steps described by the EPSG:3966
coordinate operation, i.e. it applies a rotation of 17°39'46.02" W, even if it
disagree with the _Greenwich meridian_ value declared in the prime meridian. I
verified that if I force SIS to use a rotation of 17°40'00" W instead, then we
get the values expected by the test case in the description. The table below
summarizes the coordinates transformed by SIS:
|| Axis || Source coordinates || 17°39'46.02" W rotation || 17°40'00" W
rotation ||
| X | 16°E| -25394.59 |-25097.74
|
| Y | 46.72°N| 175688.20 |175686.95
|
The last column appears to be exactly the value expected by the test case. So
my question is, how those expected values were computed? Are we sure that we
want to ignore the longitude rotation declared in EPSG:3966 and use the
_Greenwich longityde_ value instead?
> Inaccurate result for MGI Ferro transform (see test case attached)
> --
>
> Key: SIS-489
> URL: https://issues.apache.org/jira/browse/SIS-489
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Referencing
>Affects Versions: 1.0
>Reporter: Olivier Lhemann
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.1
>
>
> {code:java}
> public void TransformTest() throws FactoryException,
> MismatchedDimensionException, TransformException {
> double latitude = 46.72;
> double longitude = 16;
> double x = -25097.740155822;
> double y = 175686.952118893;
> CRSAuthorityFactory crsFactory = CRS.getAuthorityFactory("EPSG");
> CoordinateOperationAuthorityFactory opFactory =
> (CoordinateOperationAuthorityFactory) crsFactory;
> // MGI (Ferro) to WGS 84 (1)
> CoordinateOperation datumOperation =
> opFactory.createCoordinateOperation("3966");
> // MGI (Ferro) / Austria GK East Zone
> CoordinateReferenceSystem targetCRS =
> crsFactory.createCoordinateReferenceSystem("31253");
> // normalize the axis for the target
> targetCRS =
> AbstractCRS.castOrCopy(targetCRS).forConvention(AxesConvention.DISPLAY_ORIENTED);
> CoordinateOperation targetOperation =
> CRS.findOperation(datumOperation.getSourceCRS(), targetCRS, null);
> /*
> * We have two operations to concatenate
> */
> MathTransform step1 = datumOperation.getMathTransform().inverse();
> MathTransform step2 = targetOperation.getMathTransform();
> MathTransform completeTransform = MathTransforms.concatenate(step1,
> step2);
> /*
> * transform to x,y in one step
> */
> DirectPosition source = new DirectPosition2D(latitude, longitude);
> DirectPosition target = completeTransform.transform(source, null);
> double[] coordinate = target.getCoordinate();
> //System.out.println(operation.getSourceCRS().toString());
> Assert.assertEquals(x, coordinate[0], 0.1);
> Assert.assertEquals(y, coordinate[1], 0.1);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (SIS-489) Inaccurate result for MGI Ferro transform (see test case attached)
[
https://issues.apache.org/jira/browse/SIS-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux reassigned SIS-489:
---
Fix Version/s: 1.1
Affects Version/s: 1.0
Assignee: Martin Desruisseaux
> Inaccurate result for MGI Ferro transform (see test case attached)
> --
>
> Key: SIS-489
> URL: https://issues.apache.org/jira/browse/SIS-489
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Referencing
>Affects Versions: 1.0
>Reporter: Olivier Lhemann
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.1
>
>
> {code:java}
> public void TransformTest() throws FactoryException,
> MismatchedDimensionException, TransformException {
> double latitude = 46.72;
> double longitude = 16;
> double x = -25097.740155822;
> double y = 175686.952118893;
> CRSAuthorityFactory crsFactory = CRS.getAuthorityFactory("EPSG");
> CoordinateOperationAuthorityFactory opFactory =
> (CoordinateOperationAuthorityFactory) crsFactory;
> // MGI (Ferro) to WGS 84 (1)
> CoordinateOperation datumOperation =
> opFactory.createCoordinateOperation("3966");
> // MGI (Ferro) / Austria GK East Zone
> CoordinateReferenceSystem targetCRS =
> crsFactory.createCoordinateReferenceSystem("31253");
> // normalize the axis for the target
> targetCRS =
> AbstractCRS.castOrCopy(targetCRS).forConvention(AxesConvention.DISPLAY_ORIENTED);
> CoordinateOperation targetOperation =
> CRS.findOperation(datumOperation.getSourceCRS(), targetCRS, null);
> /*
> * We have two operations to concatenate
> */
> MathTransform step1 = datumOperation.getMathTransform().inverse();
> MathTransform step2 = targetOperation.getMathTransform();
> MathTransform completeTransform = MathTransforms.concatenate(step1,
> step2);
> /*
> * transform to x,y in one step
> */
> DirectPosition source = new DirectPosition2D(latitude, longitude);
> DirectPosition target = completeTransform.transform(source, null);
> double[] coordinate = target.getCoordinate();
> //System.out.println(operation.getSourceCRS().toString());
> Assert.assertEquals(x, coordinate[0], 0.1);
> Assert.assertEquals(y, coordinate[1], 0.1);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SIS-44) Update the 'demo.jsp' file in the SIS webapp to use an open source maps API
[
https://issues.apache.org/jira/browse/SIS-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-44.
--
> Update the 'demo.jsp' file in the SIS webapp to use an open source maps API
> ---
>
> Key: SIS-44
> URL: https://issues.apache.org/jira/browse/SIS-44
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Web services, Web site
>Reporter: Ross Laidlaw
>Assignee: Chris A. Mattmann
>Priority: Minor
> Labels: javascript
> Fix For: 0.3
>
> Attachments: SIS-44.rlaidlaw.2012-04-09.patch,
> demo_openlayers_experiment.jsp, demo_openlayers_experiment.png,
> screenshot_with_leaflet_bbox.png, screenshot_with_leaflet_pointradius.png
>
>
> A suggestion was made on one of the SIS wiki pages to update the 'demo.jsp'
> file in the SIS webapp to use an open source maps API, such as Leaflet
> (http://leaflet.cloudmade.com), rather than Google maps.
> For reference, below is a copy of the comment from Paul Ramirez, see
> https://cwiki.apache.org/confluence/display/SIS/OODT+File+Manager+to+SIS+Connection+Demo
> for details:
> Instead of using Google Maps you may want to use Leaflet
> (http://leaflet.cloudmade.com/) or OpenLayers (http://openlayers.org/) due to
> required API key for the map. This might matter if you are going to host this
> example on the SIS Wiki or OODT Wiki as the required API would be attached to
> you.
> Here's a snippet of Leaflet code to setup the map:
> {code}
> var map = new L.Map('map');
> // Setup the basemap
> var osm = new
> L.TileLayer('http://otile{s}.mqcdn.com/tiles/1.0.0/osm/{z}/{x}/{y}.png', {
> minZoom: 1,
> attribution: 'Basemap href="http://creativecommons.org/licenses/by-sa/2.0/;
> target="_blank">CC-BY-SA by http://openstreetmap.org/;
> target="_blank">OpenStreetMap, Tiles Courtesy of href="http://open.mapquest.com; target="_blank">MapQuest',
> subdomains: ['1','2','3','4']
> });
> // Add the basemap to the map
> map.addLayer(osm);
> // Create a marker for the map and add it
> var marker = new L.Marker(new L.LatLng(10.0, 30.0));
> map.addLayer(marker);
> // Attach a given HTML content to the marker. For brevity I truncated the
> content
> marker.bindPopup("Title: geodata.txtLink: href='http://localhost:8080...'>...");
> {code}
> Unlike the GoogleMap API this does not require a key and is an open source
> product as is the basemap (e.g. Open Street Map served by Mapquest). Then
> this would be a complete open source solution from top to bottom.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (SIS-491) sis-embedded-data database fails to start on Apache Spark
[
https://issues.apache.org/jira/browse/SIS-491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux resolved SIS-491.
-
Fix Version/s: 1.1
Resolution: Cannot Reproduce
I'm closing on the assumption that the problem was caused by Spark using an
older version of Apache Derby than Apache SIS. It seems that later Spark
versions use Derby 10.14.2, which is the same version than Apache SIS (the last
Derby version running on Java 8). So I presume that the problem can be resolved
by upgrading the Spark version.
> sis-embedded-data database fails to start on Apache Spark
> -
>
> Key: SIS-491
> URL: https://issues.apache.org/jira/browse/SIS-491
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Metadata
>Affects Versions: 0.8, 1.0
> Environment: Spark version 2.4.4
> Hadoop version 2.7.6
> Scala version 2.11.12
> Java version 1.8.0_242
> OS: Linux 4.15.0-88-generic #88-Ubuntu SMP Tue Feb 11 20:11:34 UTC
> 2020 x86_64 x86_64 x86_64 GNU/Linux
>Reporter: Derrick Oswald
>Assignee: Martin Desruisseaux
>Priority: Minor
> Fix For: 1.1
>
>
> Operation _CRS_.forCode fails when used within the Apache Spark environment.
> Steps to reproduce (see full log below):
> 1) Start spark-shell with the --packages argument specifying the
> sis-embedded-data artifact
> 2) Execute CRS.forCode ("EPSG:21781") {color:#808080}// Swiss coordinate
> system [https://epsg.io/21781]{color}
> {color:#172b4d}Result:{color}
> {color:#172b4d} NoSuchAuthorityCodeException (with a prior warning
> message: Failed to start database
> 'classpath:SIS_DATA/Databases/SpatialMetadata'){color}
> {color:#172b4d}Expected result:{color}
> {color:#172b4d} Returns a valid CoordinateReferenceSystem for
> "EPSG:21781".{color}
> {color:#172b4d}Workaround:{color}
> {color:#172b4d} Use _CRS.fromWKT_ instead.{color}
> {color:#172b4d}Note:{color}
> {{{color:#172b4d}It works fine in a stand-alone Scala program with
> build.sbt:{color}}}
> {{{color:#660e7a}name {color}:= {color:#008000}"ApacheSISTest"{color}}}
> {{{color:#660e7a}version {color}:=
> {color:#008000}"0.1"{color}{color:#660e7a}scalaVersion {color}:=
> {color:#008000}"2.11.12"{color}}}
> {{{color:#660e7a}libraryDependencies {color}+=
> {color:#008000}"org.apache.sis.core" {color}%
> {color:#008000}"sis-referencing" {color}% {color:#008000}"1.0"{color}+}}
> {{+{color:#660e7a}libraryDependencies{color}+ =
> {color:#008000}"org.apache.sis.non-free" {color}%
> {color:#008000}"sis-embedded-data" {color}% {color:#008000}"1.0"{color}}}
> and code
> {color:#80}import {color}org.apache.sis.geometry.DirectPosition2D
> {color:#80}import {color}org.apache.sis.referencing.CRS
> {color:#80}object {color}Test {color:#80}extends {color}App {
> {color:#80}val {color}{color:#660e7a}position {color}=
> {color:#80}new {color}DirectPosition2D
> ({color:#ff}678544.6095273666{color},
> {color:#ff}248462.881516265{color})
> println ({color:#008000}"Source: " {color}+
> {color:#660e7a}position{color})
> {color:#80}val {color}{color:#660e7a}sourceCRS {color}= CRS.forCode
> ({color:#008000}"EPSG:21781"{color}) {color:#808080}// Swiss coordinate
> system [https://epsg.io/21781]{color}
> {color:#80}val {color}{color:#660e7a}targetCRS {color}= CRS.forCode
> ({color:#008000}"EPSG:4326"{color}) {color:#808080}// WGS 84
> [https://epsg.io/4326]{color}
> {color:#80}val {color}{color:#660e7a}operation {color}=
> CRS.findOperation ({color:#660e7a}sourceCRS{color},
> {color:#660e7a}targetCRS{color}, {color:#80}null{color})
> {color:#80}val {color}{color:#660e7a}transform {color}=
> {color:#660e7a}operation{color}.getMathTransform
> {color:#80}val {color}{color:#660e7a}latlong {color}=
> {color:#660e7a}transform{color}.transform ({color:#660e7a}position{color},
> {color:#80}null{color}) {color:#808080}// °N, °E{color}
> println ({color:#008000}"Target: " {color}+ {color:#660e7a}latlong{color})
> }
>
> {color:#172b4d}Full Spark log:{color}
> $ *spark-shell --master local[*] --verbose --packages
> org.apache.sis.core:sis-referencing:1.0,org.apache.sis.non-free:sis-embedded-data:1.0*
> Using properties file: null
> 20/03/08 15:41:42 WARN Utils: Your hostname, resolves to a
> loopback address: 127.0.1.1; using 192.168.10.221 instead (on interface
> wlp4s0)
> 20/03/08 15:41:42 WARN Utils: Set SPARK_LOCAL_IP if you need to bind to
> another address
> Parsed arguments:
> master local[*]
> deployMode null
> executorMemory null
> executorCores null
> totalExecutorCores null
> propertiesFile null
> driverMemory null
> driverCores null
> driverExtraClassPath null
> driverExtraLibraryPath null
>
[jira] [Resolved] (SIS-517) Update EPSG geodetic dataset to version 9.9.1
[ https://issues.apache.org/jira/browse/SIS-517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux resolved SIS-517. - Resolution: Fixed > Update EPSG geodetic dataset to version 9.9.1 > - > > Key: SIS-517 > URL: https://issues.apache.org/jira/browse/SIS-517 > Project: Spatial Information Systems > Issue Type: Task > Components: Referencing >Affects Versions: 1.0 >Reporter: Martin Desruisseaux >Assignee: Martin Desruisseaux >Priority: Major > Fix For: 1.1 > > > EPSG dataset 9.9.1 (September 2020) is the last version before the 10._x_ > series of EPSG dataset. The 10._x_ series have changes in SQL schema and can > not be integrated immediately in Apache SIS. Consequently EPSG 9.9.1 is the > last version we can support until we do necessary adaptation work for the new > EPSG schema. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SIS-518) Update EPSG geodetic dataset to version 10.x
Martin Desruisseaux created SIS-518:
---
Summary: Update EPSG geodetic dataset to version 10.x
Key: SIS-518
URL: https://issues.apache.org/jira/browse/SIS-518
Project: Spatial Information Systems
Issue Type: Task
Components: Referencing
Affects Versions: 1.1
Reporter: Martin Desruisseaux
Assignee: Martin Desruisseaux
Fix For: 1.2
EPSG geodetic dataset version 10 and later uses a new SQL schema different than
the one supported by Apache SIS until now. The new SQL schema aims to support
dynamic datum. The {{EPSGDataAccess}} class needs to be adapter before we can
support latest EPSG datasets.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (SIS-517) Update EPSG geodetic dataset to version 9.9.1
Martin Desruisseaux created SIS-517: --- Summary: Update EPSG geodetic dataset to version 9.9.1 Key: SIS-517 URL: https://issues.apache.org/jira/browse/SIS-517 Project: Spatial Information Systems Issue Type: Task Components: Referencing Affects Versions: 1.0 Reporter: Martin Desruisseaux Assignee: Martin Desruisseaux Fix For: 1.1 EPSG dataset 9.9.1 (September 2020) is the last version before the 10._x_ series of EPSG dataset. The 10._x_ series have changes in SQL schema and can not be integrated immediately in Apache SIS. Consequently EPSG 9.9.1 is the last version we can support until we do necessary adaptation work for the new EPSG schema. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SIS-516) Read and write filters in XML and KVP formats
Martin Desruisseaux created SIS-516: --- Summary: Read and write filters in XML and KVP formats Key: SIS-516 URL: https://issues.apache.org/jira/browse/SIS-516 Project: Spatial Information Systems Issue Type: Task Components: Features Affects Versions: 1.1 Reporter: Martin Desruisseaux The [OGC® Filter Encoding 2.0 Encoding Standard|http://docs.opengeospatial.org/is/09-026r2/09-026r2.html] standard has been used for dering a conceptual model (the set of interfaces and methods) for filters and expressions in GeoAPI and Apache SIS. But that standard defines also en encoding in XML and in Key-Value Pairs (KVP) formats. Parsing and formatting of filters in those 2 formats should be supported. Note: Common Query Language (CQL) format is the topic of a separated specification. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (SIS-511) build failed on AArch64, Fedora 33
[
https://issues.apache.org/jira/browse/SIS-511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux resolved SIS-511.
-
Resolution: Cannot Reproduce
Can not reproduce the issue. The error message said that
{{9}} configuration is invalid, but the actual configuration
in the root {{pom.xml}} file is {{8}} (a LTS Java version).
> build failed on AArch64, Fedora 33
> ---
>
> Key: SIS-511
> URL: https://issues.apache.org/jira/browse/SIS-511
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Build process
>Reporter: Lutz Weischer
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.1
>
>
> {noformat}
> (base) [jw@cn06 sis]$ mvn install -DskipTests
> [INFO] Scanning for projects...
> [WARNING]
> [WARNING] Some problems were encountered while building the effective model
> for org.apache.sis:parent:pom:1.1-SNAPSHOT
> [WARNING] 'parent.relativePath' of POM org.apache.sis:parent:1.1-SNAPSHOT
> (/data/jw/apache/samoa/sis/pom.xml) points at org.apache.samoa:samoa instead
> of org.apache:apache, please verify your project structure @ line 38, column
> 11
> [WARNING]
> [WARNING] It is highly recommended to fix these problems because they
> threaten the stability of your build.
> [WARNING]
> [WARNING] For this reason, future Maven versions might no longer support
> building such malformed projects.
> [WARNING]
> [INFO]
>
> [INFO] Reactor Build Order:
> [INFO]
> [INFO] Apache SIS [pom]
> [INFO] Apache SIS build helper [maven-plugin]
> [INFO] Apache SIS core modules [pom]
> [INFO] Apache SIS utilities [jar]
> [INFO] Apache SIS metadata [jar]
> [INFO] Apache SIS referencing [jar]
> [INFO] Apache SIS referencing by geographic identifiers [jar]
> [INFO] Apache SIS features [jar]
> [INFO] Apache SIS storage [pom]
> [INFO] Apache SIS common storage [jar]
> [INFO] Apache SIS portrayal [jar]
> [INFO] Apache SIS Shapefile storage [jar]
> [INFO] Apache SIS XML storage [jar]
> [INFO] Apache SIS SQL storage [jar]
> [INFO] Apache SIS netCDF storage [jar]
> [INFO] Apache SIS GeoTIFF storage [jar]
> [INFO] Apache SIS Earth Observation storage [jar]
> [INFO] Apache SIS bindings for Proj4 [jar]
> [INFO] Apache SIS applications [pom]
> [INFO] Apache SIS console [jar]
> [INFO] Apache SIS web services layer [war]
> [INFO] Bridges to Apache OpenOffice or LibreOffice [jar]
> [INFO] Apache SIS profiles [pom]
> [INFO] Apache SIS French profiles [jar]
> [INFO] Apache SIS Japanese profiles [jar]
> [INFO]
> [INFO] ---< org.apache.sis:parent
> >
> [INFO] Building Apache SIS 1.1-SNAPSHOT [1/25]
> [INFO] [ pom
> ]-
> [INFO]
> [INFO] — maven-enforcer-plugin:3.0.0-M2:enforce (enforce-maven-version) @
> parent —
> [INFO]
> [INFO] — maven-enforcer-plugin:3.0.0-M2:enforce (enforce) @ parent —
> [INFO]
> [INFO] — maven-remote-resources-plugin:1.5:process
> (process-resource-bundles) @ parent —
> [INFO]
> [INFO] — build-helper-maven-plugin:3.0.0:remove-project-artifact
> (remove-old-artifacts) @ parent —
> [INFO] /home/jw/.m2/repository/org/apache/sis/parent/1.1-SNAPSHOT removed.
> [INFO]
> [INFO] — maven-jar-plugin:3.1.2:test-jar (default) @ parent —
> [INFO] Skipping packaging of the test-jar
> [INFO]
> [INFO] — maven-site-plugin:3.7.1:attach-descriptor (attach-descriptor) @
> parent —
> [INFO] No site descriptor found: nothing to attach.
> [INFO]
> [INFO] — maven-checkstyle-plugin:3.1.0:check (default) @ parent —
> [INFO]
> [INFO] — maven-install-plugin:2.5.2:install (default-install) @ parent —
> [INFO] Installing /data/jw/apache/samoa/sis/pom.xml to
> /home/jw/.m2/repository/org/apache/sis/parent/1.1-SNAPSHOT/parent-1.1-SNAPSHOT.pom
> [INFO]
> [INFO] < org.apache.sis.core:sis-build-helper
> >
> [INFO] Building Apache SIS build helper 1.1-SNAPSHOT [2/25]
> [INFO] [ maven-plugin
> ]
> [INFO]
> [INFO] — maven-enforcer-plugin:3.0.0-M2:enforce (enforce-maven-version) @
> sis-build-helper —
> [INFO]
> [INFO] — maven-enforcer-plugin:3.0.0-M2:enforce (enforce) @ sis-build-helper
> —
> [INFO]
> [INFO] — maven-remote-resources-plugin:1.5:process
> (process-resource-bundles) @ sis-build-helper —
> [INFO]
> [INFO] — maven-resources-plugin:3.1.0:resources (default-resources) @
> sis-build-helper —
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 5 resources
> [INFO] Copying 3 resources
> [INFO]
> [INFO] — maven-compiler-plugin:3.8.1:compile (default-compile) @
> sis-build-helper —
> [INFO] Compiling 24 source files to
[jira] [Updated] (SIS-511) build failed on AArch64, Fedora 33
[
https://issues.apache.org/jira/browse/SIS-511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-511:
Component/s: Build process
Fix Version/s: 1.1
Description:
{noformat}
(base) [jw@cn06 sis]$ mvn install -DskipTests
[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective model
for org.apache.sis:parent:pom:1.1-SNAPSHOT
[WARNING] 'parent.relativePath' of POM org.apache.sis:parent:1.1-SNAPSHOT
(/data/jw/apache/samoa/sis/pom.xml) points at org.apache.samoa:samoa instead of
org.apache:apache, please verify your project structure @ line 38, column 11
[WARNING]
[WARNING] It is highly recommended to fix these problems because they threaten
the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support
building such malformed projects.
[WARNING]
[INFO]
[INFO] Reactor Build Order:
[INFO]
[INFO] Apache SIS [pom]
[INFO] Apache SIS build helper [maven-plugin]
[INFO] Apache SIS core modules [pom]
[INFO] Apache SIS utilities [jar]
[INFO] Apache SIS metadata [jar]
[INFO] Apache SIS referencing [jar]
[INFO] Apache SIS referencing by geographic identifiers [jar]
[INFO] Apache SIS features [jar]
[INFO] Apache SIS storage [pom]
[INFO] Apache SIS common storage [jar]
[INFO] Apache SIS portrayal [jar]
[INFO] Apache SIS Shapefile storage [jar]
[INFO] Apache SIS XML storage [jar]
[INFO] Apache SIS SQL storage [jar]
[INFO] Apache SIS netCDF storage [jar]
[INFO] Apache SIS GeoTIFF storage [jar]
[INFO] Apache SIS Earth Observation storage [jar]
[INFO] Apache SIS bindings for Proj4 [jar]
[INFO] Apache SIS applications [pom]
[INFO] Apache SIS console [jar]
[INFO] Apache SIS web services layer [war]
[INFO] Bridges to Apache OpenOffice or LibreOffice [jar]
[INFO] Apache SIS profiles [pom]
[INFO] Apache SIS French profiles [jar]
[INFO] Apache SIS Japanese profiles [jar]
[INFO]
[INFO] ---< org.apache.sis:parent >
[INFO] Building Apache SIS 1.1-SNAPSHOT [1/25]
[INFO] [ pom ]-
[INFO]
[INFO] — maven-enforcer-plugin:3.0.0-M2:enforce (enforce-maven-version) @
parent —
[INFO]
[INFO] — maven-enforcer-plugin:3.0.0-M2:enforce (enforce) @ parent —
[INFO]
[INFO] — maven-remote-resources-plugin:1.5:process (process-resource-bundles)
@ parent —
[INFO]
[INFO] — build-helper-maven-plugin:3.0.0:remove-project-artifact
(remove-old-artifacts) @ parent —
[INFO] /home/jw/.m2/repository/org/apache/sis/parent/1.1-SNAPSHOT removed.
[INFO]
[INFO] — maven-jar-plugin:3.1.2:test-jar (default) @ parent —
[INFO] Skipping packaging of the test-jar
[INFO]
[INFO] — maven-site-plugin:3.7.1:attach-descriptor (attach-descriptor) @
parent —
[INFO] No site descriptor found: nothing to attach.
[INFO]
[INFO] — maven-checkstyle-plugin:3.1.0:check (default) @ parent —
[INFO]
[INFO] — maven-install-plugin:2.5.2:install (default-install) @ parent —
[INFO] Installing /data/jw/apache/samoa/sis/pom.xml to
/home/jw/.m2/repository/org/apache/sis/parent/1.1-SNAPSHOT/parent-1.1-SNAPSHOT.pom
[INFO]
[INFO] < org.apache.sis.core:sis-build-helper >
[INFO] Building Apache SIS build helper 1.1-SNAPSHOT [2/25]
[INFO] [ maven-plugin ]
[INFO]
[INFO] — maven-enforcer-plugin:3.0.0-M2:enforce (enforce-maven-version) @
sis-build-helper —
[INFO]
[INFO] — maven-enforcer-plugin:3.0.0-M2:enforce (enforce) @ sis-build-helper —
[INFO]
[INFO] — maven-remote-resources-plugin:1.5:process (process-resource-bundles)
@ sis-build-helper —
[INFO]
[INFO] — maven-resources-plugin:3.1.0:resources (default-resources) @
sis-build-helper —
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 5 resources
[INFO] Copying 3 resources
[INFO]
[INFO] — maven-compiler-plugin:3.8.1:compile (default-compile) @
sis-build-helper —
[INFO] Compiling 24 source files to
/data/jw/apache/samoa/sis/core/sis-build-helper/target/classes
[INFO]
[INFO] Reactor Summary for Apache SIS 1.1-SNAPSHOT:
[INFO]
[INFO] Apache SIS . SUCCESS [ 6.804 s]
[INFO] Apache SIS build helper FAILURE [ 2.915 s]
[INFO] Apache SIS core modules SKIPPED
[INFO] Apache SIS utilities ... SKIPPED
[INFO] Apache SIS metadata SKIPPED
[INFO] Apache SIS referencing . SKIPPED
[INFO] Apache SIS referencing by geographic identifiers ... SKIPPED
[INFO] Apache SIS features SKIPPED
[jira] [Resolved] (SIS-508) MD_Scope in place of DQ_Scope when generating old 2007 iso 19139
[
https://issues.apache.org/jira/browse/SIS-508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux resolved SIS-508.
-
Resolution: Fixed
Fixed on {{master}} and on branches {{geoapi-3.1}} and {{geoapi-4.0}}. Given
that the fix was a little bit more complex than I thought, if anyone has a
chance to test if there is no regression, that would be appreciated.
> MD_Scope in place of DQ_Scope when generating old 2007 iso 19139
> -
>
> Key: SIS-508
> URL: https://issues.apache.org/jira/browse/SIS-508
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Metadata
>Affects Versions: 1.0
>Reporter: jean-marc Bourdaret
>Assignee: Martin Desruisseaux
>Priority: Minor
> Fix For: 1.1
>
>
> When building _DefaultDataQuality_ objects with a _Scope ,_
> Generated XML may not contain the appropriate *+_DQ_Scope_+* tag.
> I understand that *DQ_Scope* was deprecated in *iso19115:2014*, in favor of
> MD_Scope. but it might still be valid when generating iso19115:*2007* XML.
> h4. exemple:
> {code:java}
> DefaultDataQuality dataQuality = new
> DefaultDataQuality(ScopeCode.DATASET);{code}
> and then :
> {code:java}
> XML.marshal(sisMetadata,new StreamResult( xmlOut ),
> Map.of(XML.METADATA_VERSION, "2007"))
> {code}
> will produce :
> {code:java}
> ...
>
>
>
>
>{code}
> and I was expecting :
> {code:java}
> ...
>
>
>
>
>{code}
> because it should be a iso19115:2007 compliant document.
> using SIS v2.0 on the Geomatys repo.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (SIS-505) Upgrade OpenOffice/LibreOffice dependency
[
https://issues.apache.org/jira/browse/SIS-505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux resolved SIS-505.
-
Assignee: Martin Desruisseaux
Resolution: Fixed
> Upgrade OpenOffice/LibreOffice dependency
> -
>
> Key: SIS-505
> URL: https://issues.apache.org/jira/browse/SIS-505
> Project: Spatial Information Systems
> Issue Type: New Feature
> Components: OpenOffice
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Minor
> Fix For: 1.1
>
>
> The four Java jars {{juh.jar}}, {{jurt.jar}}, {{ridl.jar}}, and {{unoil.jar}}
> are now combined into a single {{libreoffice.jar}}.
> Source: https://wiki.documentfoundation.org/ReleaseNotes/7.0/en#Java_support
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-469) Remove support for JAXB internal implementation (JDK 8)
[
https://issues.apache.org/jira/browse/SIS-469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-469:
Fix Version/s: (was: 1.1)
1.2
Affects Version/s: 1.1
> Remove support for JAXB internal implementation (JDK 8)
> ---
>
> Key: SIS-469
> URL: https://issues.apache.org/jira/browse/SIS-469
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Metadata, Referencing, Storage
>Affects Versions: 1.0, 1.1
>Reporter: Martin Desruisseaux
>Priority: Minor
> Fix For: 1.2
>
>
> Apache SIS 1.0 uses the JAXB implementation found in the
> {{com.sun.xml.internal.bind}} package, if presents, because this package is
> provided with Java 8. That JAXB implementation can optionally be replaced by
> the one in {{com.sun.xml.bind}} package (without {{internal}}), but we still
> want to use the internal implementation as a fallback.
> Starting with Java 11, the internal JAXB implementation is no longer
> available. Consequently there is no point in continuing to support that
> package after Apache SIS upgraded its requirement to Java 11. The codes to
> delete will be:
> * {{Implementation.INTERNAL}}
> * {{Implementation.toInternal(String)}}
> * {{Pooled.internal}}
> * Maybe more, to be investigated.
> Then, the {{provided}} scope of {{jakarta.xml.bind-api}} dependency in root
> {{pom.xml}} file should be removed. Since the default scope {{compile}} is
> transitive, {{jakarta.xml.bind-api}} dependencies declared downstream
> {{sis-metadata}} module can be removed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (SIS-447) NumericCoverage as a parent of GridCoverage
[
https://issues.apache.org/jira/browse/SIS-447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux resolved SIS-447.
-
Resolution: Fixed
The class name is {{BandedCoverage}} instead of {{NumericCoverage}}, but the
rest is about as described in this issue.
> NumericCoverage as a parent of GridCoverage
> ---
>
> Key: SIS-447
> URL: https://issues.apache.org/jira/browse/SIS-447
> Project: Spatial Information Systems
> Issue Type: New Feature
> Components: Features
>Affects Versions: 1.0
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Minor
> Fix For: 1.1
>
>
> The base type of all coverage (including raster) data is {{Coverage}}, which
> is defined by ISO 19123. A {{Coverage}} is not necessarily a grid (raster).
> It is rather a collection of "geometry - record" pairs where the geometries
> are pixels in the particular case of rasters. ISO 19123 defines many
> {{Coverage}} subtypes: {{DiscreteCoverage}}, {{ContinuousCoverage}}, _etc._.
> The types which seem closest to a raster are
> {{ContinuousQuadrilateralGridCoverage}} and {{DiscreteGridPointCoverage}}.
> However even those types are more complex than the majority of the needs to
> be handled by Apache SIS. For now SIS defines only one class,
> {{GridCoverage}}, which is simpler (at the cost of being less powerful) than
> ISO 19123 classes. We tried to define {{GridCoverage}} in a way that should
> not conflict with future ISO 19123 compliant development.
> A key simplification done in SIS {{GridCoverage}} compared to ISO 19123
> {{Coverage}} is that, in addition of assuming that values are distributed on
> a grid, it also assumes that all values are stored as numbers. Those numbers
> may be associated to categories (e.g. _1 = clouds_), but they still numbers.
> By contrast ISO 19123 allows the storage of more complex structures:
> {{Record}} where each record may contain other records. An ISO 19123
> {{Record}} may be seen as a simple {{Feature}}, i.e. a feature where the
> multiplicity of all attributes is constrained to [1…1].
> In the same way than ISO 19123 allows various coverage types (not necessarily
> gridded) and defines subclasses for the particular case of coverage using a
> grid, we may want a more general class in Apache SIS for any coverage storing
> data as numbers (as a simplification of the more general {{Record}} type).
> The methods could be:
> {code:java}
> public abstract class NumericCoverage {
> public abstract CoordinateReferenceSystem getCoordinateReferenceSystem();
> public abstract List getSampleDimensions();
> }
> {code}
> {{GridCoverage}} would extend that class and add a {{getGridGeometry()}}
> method. The main difference between this proposed {{NumericCoverage}}
> compared to ISO 19123 {{Coverage}} is the {{getSampleDimensions()}} method,
> which can be seen as a specialization of the following method:
> {code:java}
> public interface Coverage {
> RecordType getRangeType();
> }
> {code}
> The class name is difficult to chose. Current proposal is
> {{NumericCoverage}}. We found usage of that term on a web page about
> [Atmospheric Dispersion
> Index|http://cwfis.cfs.nrcan.gc.ca/background/summary/adi]: _"The coverage
> descriptions, which indicate few, scattered, broken, or overcast, are
> translated into numeric coverage classes."_ — while I'm not sure it describes
> the same thing. We searched also {{NumericalCoverage}} but found less
> relevant usages.
> This {{NumericCoverage}} class would be a complement of ISO 19123 classes. It
> should not prevent us to implement more fully ISO 19123 in the future. The
> "Numeric" part in {{NumericCoverage}} describes a characteristic of the
> _range_ (ISO 19123 coverages have two parts: _domain_ and _range_), in the
> same way than the "Discrete" and "Continuous" parts in ISO 19123
> {{DiscreteCoverage}} and {{ContinuousCoverage}} also refer to the range.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (SIS-447) NumericCoverage as a parent of GridCoverage
[
https://issues.apache.org/jira/browse/SIS-447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux reassigned SIS-447:
---
Assignee: Martin Desruisseaux
> NumericCoverage as a parent of GridCoverage
> ---
>
> Key: SIS-447
> URL: https://issues.apache.org/jira/browse/SIS-447
> Project: Spatial Information Systems
> Issue Type: New Feature
> Components: Features
>Affects Versions: 1.0
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Minor
> Fix For: 1.1
>
>
> The base type of all coverage (including raster) data is {{Coverage}}, which
> is defined by ISO 19123. A {{Coverage}} is not necessarily a grid (raster).
> It is rather a collection of "geometry - record" pairs where the geometries
> are pixels in the particular case of rasters. ISO 19123 defines many
> {{Coverage}} subtypes: {{DiscreteCoverage}}, {{ContinuousCoverage}}, _etc._.
> The types which seem closest to a raster are
> {{ContinuousQuadrilateralGridCoverage}} and {{DiscreteGridPointCoverage}}.
> However even those types are more complex than the majority of the needs to
> be handled by Apache SIS. For now SIS defines only one class,
> {{GridCoverage}}, which is simpler (at the cost of being less powerful) than
> ISO 19123 classes. We tried to define {{GridCoverage}} in a way that should
> not conflict with future ISO 19123 compliant development.
> A key simplification done in SIS {{GridCoverage}} compared to ISO 19123
> {{Coverage}} is that, in addition of assuming that values are distributed on
> a grid, it also assumes that all values are stored as numbers. Those numbers
> may be associated to categories (e.g. _1 = clouds_), but they still numbers.
> By contrast ISO 19123 allows the storage of more complex structures:
> {{Record}} where each record may contain other records. An ISO 19123
> {{Record}} may be seen as a simple {{Feature}}, i.e. a feature where the
> multiplicity of all attributes is constrained to [1…1].
> In the same way than ISO 19123 allows various coverage types (not necessarily
> gridded) and defines subclasses for the particular case of coverage using a
> grid, we may want a more general class in Apache SIS for any coverage storing
> data as numbers (as a simplification of the more general {{Record}} type).
> The methods could be:
> {code:java}
> public abstract class NumericCoverage {
> public abstract CoordinateReferenceSystem getCoordinateReferenceSystem();
> public abstract List getSampleDimensions();
> }
> {code}
> {{GridCoverage}} would extend that class and add a {{getGridGeometry()}}
> method. The main difference between this proposed {{NumericCoverage}}
> compared to ISO 19123 {{Coverage}} is the {{getSampleDimensions()}} method,
> which can be seen as a specialization of the following method:
> {code:java}
> public interface Coverage {
> RecordType getRangeType();
> }
> {code}
> The class name is difficult to chose. Current proposal is
> {{NumericCoverage}}. We found usage of that term on a web page about
> [Atmospheric Dispersion
> Index|http://cwfis.cfs.nrcan.gc.ca/background/summary/adi]: _"The coverage
> descriptions, which indicate few, scattered, broken, or overcast, are
> translated into numeric coverage classes."_ — while I'm not sure it describes
> the same thing. We searched also {{NumericalCoverage}} but found less
> relevant usages.
> This {{NumericCoverage}} class would be a complement of ISO 19123 classes. It
> should not prevent us to implement more fully ISO 19123 in the future. The
> "Numeric" part in {{NumericCoverage}} describes a characteristic of the
> _range_ (ISO 19123 coverages have two parts: _domain_ and _range_), in the
> same way than the "Discrete" and "Continuous" parts in ISO 19123
> {{DiscreteCoverage}} and {{ContinuousCoverage}} also refer to the range.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-398) MI_PolarizationOrientationCode as an alias of MI_PolarisationOrientationCode
[
https://issues.apache.org/jira/browse/SIS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-398:
Fix Version/s: (was: 1.1)
1.2
Affects Version/s: 1.1
> MI_PolarizationOrientationCode as an alias of MI_PolarisationOrientationCode
>
>
> Key: SIS-398
> URL: https://issues.apache.org/jira/browse/SIS-398
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Metadata
>Affects Versions: 1.0, 1.1
>Reporter: Martin Desruisseaux
>Priority: Minor
> Labels: JAXB
> Fix For: 1.2
>
>
> The {{MI_PolarizationOrientationCode}} code list in ISO 19139:2007 has been
> renamed {{MI_PolarisationOrientationCode}} in ISO 19115-3:2016 ("z" changed
> into "s"). We should:
> * (minor) rename the class name in {{org.apache.sis.internal.jaxb.code}}
> package. This require an update of at least the GeoAPI annotation in order to
> all {{AllMetadataTest}} to pass. See
> https://github.com/opengeospatial/geoapi/issues/23
> * (major) adapt our XML (un)marshalling process for using both spelling
> depending on the ISO version used. We already have a renaming mechanism for
> properties, but not yet for types.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-384) (Affine → Passthrough → Affine) should be simplified as (Affine → Passthrough) or (Passthrough → Affine)
[
https://issues.apache.org/jira/browse/SIS-384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-384:
Fix Version/s: (was: 1.1)
1.2
Affects Version/s: 1.1
1.0
> (Affine → Passthrough → Affine) should be simplified as (Affine →
> Passthrough) or (Passthrough → Affine)
>
>
> Key: SIS-384
> URL: https://issues.apache.org/jira/browse/SIS-384
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Referencing
>Affects Versions: 0.5, 0.6, 0.7, 0.8, 1.0, 1.1
>Reporter: Martin Desruisseaux
>Priority: Minor
> Labels: performance
> Fix For: 1.2
>
>
> Below is an example of concatenated math transform. An "Affine" operation
> appears twice: before and after the "Passthrough" operation:
> {noformat}
> Concat_MT[
> Param_MT["Affine",
> Parameter["num_row", 5],
> Parameter["num_col", 5],
> Parameter["elt_0_0", 0.025],
> Parameter["elt_0_4", 3.0125],
> Parameter["elt_1_1", -0.025],
> Parameter["elt_1_4", 44.9875]],
> PassThrough_MT[2, 1, Param_MT["Interpolation 1D",
> Parameter["values", {2.0, 10.0, 20.0, 35.0, 50.0, 75.0, 100.0}]]],
> Param_MT["Affine",
> Parameter["num_row", 5],
> Parameter["num_col", 5],
> Parameter["elt_3_3", 360.0],
> Parameter["elt_3_4", 1.5127128E12]]]
> {noformat}
> The last "Affine" operates only on passthrough coordinates. Consequently it
> could be moved before the "Passthrouh" operation, which would allow
> concatenation with the first "Affine" operation. It should not change the
> operation result, but can improve performance.
> This optimization is possible only for "Affine" that operate only on
> pass-through coordinates. If the last "Affine" does not comply with this
> condition, maybe the first "Affine" does. So we will need to test both.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-369) Better selection of datum shift method depending on desired accuracy
[
https://issues.apache.org/jira/browse/SIS-369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-369:
Fix Version/s: (was: 1.1)
1.2
Affects Version/s: 1.1
1.0
> Better selection of datum shift method depending on desired accuracy
>
>
> Key: SIS-369
> URL: https://issues.apache.org/jira/browse/SIS-369
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Referencing
>Affects Versions: 0.8, 1.0, 1.1
>Reporter: Martin Desruisseaux
>Priority: Minor
> Fix For: 1.2
>
>
> Coordinate operations may be slow, especially when datum shifts are involved.
> When not using datum shift grid files, the most common method is _geocentric
> translation_. The _Molodensky_ method is a little bit faster at the expanse
> of accuracy, but that accuracy lost may be acceptable for example if the
> scale on a map is not sufficient for seeing the difference. At very small
> scale where each pixel is 10 km wide, we can even skip the datum shift
> operation completely. The question is where to put the threshold. 5 meters
> for _Molodensky_, 10 meters for _Abridged Molodensky_, 3 km for none? This
> need to be measured, for example by trying all _geocentric translation_
> operations in the EPSG database. Once thresholds have been determined, the
> {{DatumShiftMethod.forAccuracy(double)}} method should be updated accordingly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-370) Improve CoordinateOperation WKT for axis changes and Molodensky parameters
[
https://issues.apache.org/jira/browse/SIS-370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-370:
Fix Version/s: (was: 1.1)
1.2
Affects Version/s: 1.1
1.0
> Improve CoordinateOperation WKT for axis changes and Molodensky parameters
> --
>
> Key: SIS-370
> URL: https://issues.apache.org/jira/browse/SIS-370
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Referencing
>Affects Versions: 0.7, 0.8, 1.0, 1.1
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Minor
> Fix For: 1.2
>
>
> The Well Known Text (WKT) formatting of {{CoordinateOperation}} objects have
> the following shortcomings:
> In the formatting of Molodensky Parameters, _Semi-major axis length
> difference_ and _Flattening difference_ parameters are wrongly set to NaN.
> Note that this issue happen only for {{CoordinateOperation}} WKT, not for
> {{MathTransform}} WKT.
> Operation steps inserted for changing axis order are shown as affine
> transform, which is difficult to read for most users. The formatter should
> detect automatically when a matrix is square, of size 3×3 or 4×4 and having 1
> value on anti-diagonal (except last row) and show instead one of the
> following operations:
> * EPSG::15498 — axis order change (2D)
> * EPSG::15499 — axis order change (geographic3D horizontal)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-365) CRS.findOperation(…) should take current locale in account when there is ambiguity
[
https://issues.apache.org/jira/browse/SIS-365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-365:
Fix Version/s: (was: 1.1)
Affects Version/s: 1.1
1.0
> CRS.findOperation(…) should take current locale in account when there is
> ambiguity
> --
>
> Key: SIS-365
> URL: https://issues.apache.org/jira/browse/SIS-365
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Referencing
>Affects Versions: 0.7, 0.8, 1.0, 1.1
>Reporter: Martin Desruisseaux
>Priority: Minor
>
> The {{CRS.findOperation(…)}} method expects 3 arguments: a source CRS, a
> target CRS, and an optional area of interest (as a geographic bounding box).
> The area of interest is sometime necessary because more than one operation
> may exists for the same pair of CRS, depending on the area of interest. For
> example the EPSG database contains about 85 different operations between
> NAD27 and WGS84. There is an operation for East of Texas, an other operation
> (with different parameters) for West of Texas, one operation for the
> continental USA as a whole, one operation for Canada as a whole,_etc._
> If the user does not provide any area of interest, then Apache SIS default
> behavior is to select the operation which is valid in the widest area.
> However, this criterion means that when asking for a transformation from
> NAD27 to WGS84, Apache SIS will select by default the operation for Canada
> because it covers a wider geographic area than the operation for continental
> USA. This may not be the default choice than many users would expect.
> We can try to improve this situation by taking the locale in account. If no
> geographic area is specified, then:
> * If the default locale is {{Locale.US}}, give precedence to the operation
> for USA.
> * If the default locale is {{Locale.CANADA}}, give precedence to the
> operation for Canada.
> * For any other locale, keep the current behavior (select widest area).
> While we used USA and Canada as an example, we actually want to apply the
> same approach for any country. Technically, we can use the {{Area}} table in
> the EPSG database. That table contains 3 columns for ISO codes: one for the
> two-letters codes, one for the three-letters codes and another one for
> numerical codes. The approach is:
> * When creating a {{GeographicExtent}} from EPSG database, include ISO codes
> (if present) as identifiers.
> * When searching for a coordinate operation, if and only if the users did not
> specified explicitly a geographic area, use the ISO codes associated with
> {{GeographicExtent}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-359) Support coordinate transformations between CRS having duplicated axis orientations
[
https://issues.apache.org/jira/browse/SIS-359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-359:
Fix Version/s: (was: 1.1)
1.2
Affects Version/s: 1.1
1.0
> Support coordinate transformations between CRS having duplicated axis
> orientations
> --
>
> Key: SIS-359
> URL: https://issues.apache.org/jira/browse/SIS-359
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Referencing
>Affects Versions: 0.6, 0.7, 0.8, 1.0, 1.1
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Minor
> Fix For: 1.2
>
>
> Coordinate systems are usually not allowed to have two axes with the same
> orientation. For example it is considered an error to have two axes oriented
> toward East. But there is at least two exceptions to this rule:
> * {{AxisDirection.OTHER}}: there is actually no way to know which direction
> it is, so two {{OTHER}} orientations may be actually different directions.
> * {{AxisDirection.FUTURE}}: meteorological data can have two time axes. For
> more information, see [OGC Best Practice for using Web Map Services (WMS)
> with Time-Dependent or Elevation-Dependent
> Data|http://www.opengis.net/doc/bp/wms-tnz/1.0] (OGC 12-111r1).
> Currently, attempt to transform two CRS having duplicated axis orientation
> produces an exception like below:
> {noformat}
> org.opengis.util.FactoryException: Ne peut pas créer l’objet géodétique pour
> « CompoundCRS[“grib-lonlat-crs+Java…”] → CompoundCRS[“grib-lonlat-crs+Java…”]
> ».
> at
> org.apache.sis.referencing.operation.CoordinateOperationFinder.createOperation(CoordinateOperationFinder.java:206)
> at
> org.apache.sis.referencing.operation.DefaultCoordinateOperationFactory.createOperation(DefaultCoordinateOperationFactory.java:750)
> at org.apache.sis.referencing.CRS.findOperation(CRS.java:610)
> ... 22 more
> Caused by: java.lang.IllegalArgumentException: Les directions d’axes
> Other et Other sont colinéaires.
> at
> org.apache.sis.referencing.operation.matrix.Matrices.createTransform(Matrices.java:267)
> at
> org.apache.sis.referencing.operation.matrix.Matrices.createTransform(Matrices.java:440)
> at
> org.apache.sis.referencing.cs.CoordinateSystems.swapAndScaleAxes(CoordinateSystems.java:280)
> at
> org.apache.sis.referencing.operation.CoordinateOperationFinder.createOperation(CoordinateOperationFinder.java:204)
> ... 26 more
> {noformat}
> One possible approach may be to remember the indirect association between
> axes and CRS during the computation performed by
> {{Matrices.createTransform(…)}}. If two axes have the same axis direction but
> we can still distinguish the axes by the enclosing CRS instance, then we can
> avoid throwing the exception.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-357) EPSG factory should be able to create geocentric CRS as derived CRS
[
https://issues.apache.org/jira/browse/SIS-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-357:
Fix Version/s: (was: 1.1)
1.2
Affects Version/s: 1.1
1.0
> EPSG factory should be able to create geocentric CRS as derived CRS
> ---
>
> Key: SIS-357
> URL: https://issues.apache.org/jira/browse/SIS-357
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Referencing
>Affects Versions: 0.7, 0.8, 1.0, 1.1
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Minor
> Fix For: 1.2
>
>
> The {{EPSGDataAccess.createCoordinateReferenceSystem(String)}} queries the
> EPSG {{"Coordinate Reference System"}} table with more than 10 columns. Some
> relevant columns for this tasks are:
> * {{COORD_REF_SYS_KIND}} (may be "geographic 2D", "geographic 3D",
> "geocentric", "projected", _etc._)
> * {{SOURCE_GEOGCRS_CODE}} (EPSG code of a {{GeographicCRS}})
> * {{PROJECTION_CONV_CODE}} (EPSG code of a {{CoordinateOperation}})
> Current {{EPSGDataAccess}} implementation uses the {{SOURCE_GEOGCRS_CODE}}
> and {{PROJECTION_CONV_CODE}} columns only if the {{COORD_REF_SYS_KIND}} is
> {{"projected"}}. But the EPSG database sometime uses those columns for other
> kind of CRS. For example with WGS 84 coordinate reference systems:
> * EPSG:4326 (geographic 2D) is derived from EPSG:4979 (geographic 3D) with
> conversion EPSG:15593 (geographic3D to geographic2D).
> * EPSG::4979 (geographic 3D) is derived from EPSG::4978 (geocentric) with
> conversion EPSG:15592 (geocentric to geographic3D).
> We could modify {{EPSGDataAccess}} as below:
> * Unconditionally build a coordinate operation from {{SOURCE_GEOGCRS_CODE}}
> and {{PROJECTION_CONV_CODE}} columns instead than only in the projected CRS
> case.
> * Above operation is mandatory for projected CRS case, optional for all other.
> * If an operation was found, use it for creating a derived CRS like below:
> {code:java}
> CoordinateOperation op = …,
> CoordinateReferenceSystem base = ...;
> if (op instanceof Conversion && base instanceof SingleCRS) {
> crs = DefaultDerivedCRS.create(properties, (SingleCRS) base, (Conversion)
> op, cs);
> }
> {code}
> However we may want to keep _Well Known Text_ (WKT) outputs simple by
> formatting the CRS as if it was a non-derived CRS. How to handle that is an
> open question.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-339) Feature attribute should verify the CRS of geometric value
[
https://issues.apache.org/jira/browse/SIS-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-339:
Fix Version/s: (was: 1.1)
1.2
Affects Version/s: 1.1
1.0
> Feature attribute should verify the CRS of geometric value
> --
>
> Key: SIS-339
> URL: https://issues.apache.org/jira/browse/SIS-339
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Features
>Affects Versions: 0.7, 0.8, 1.0, 1.1
>Reporter: Martin Desruisseaux
>Priority: Minor
> Fix For: 1.2
>
>
> In the {{org.apache.sis.feature}} package, a {{DefaultFeature}} can contains
> an attribute which itself contains a characteristic having the
> {{AttributeConvention.CRS_CHARACTERISTIC}} name. The value of that
> characteristic is the Coordinate Reference System (CRS) of the geometry that
> this attribute can contains. However there is currently no verification that
> a geometry given to that attribute has the expected CRS. We should add a
> verification mechanism, compatible with both JTS and ESRI API. This may
> require Java reflection code, since those two libraries are optional.
> One open question is where to store the CRS information in the geometry
> object. JTS has a SRID property, but it is only an {{int}} type. It could be
> decided that the integer value is the EPSG code, but this is an arbitrary
> (while common) decision. Alternatively we could use the JTS user object for
> storing the full {{CoordinateReferenceSystem}} object, but this is another
> arbitrary decision.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-319) Read CSV file conform to OGC Moving Features syntax
[
https://issues.apache.org/jira/browse/SIS-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-319:
Fix Version/s: (was: 1.1)
1.0
> Read CSV file conform to OGC Moving Features syntax
> ---
>
> Key: SIS-319
> URL: https://issues.apache.org/jira/browse/SIS-319
> Project: Spatial Information Systems
> Issue Type: New Feature
> Components: Storage
>Affects Versions: 0.7, 0.8
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Minor
> Fix For: 1.0
>
>
> Implement a reader for the OGC® Moving Features Encoding Extension:
> Simple Comma Separated Values (CSV) specification:
> * http://docs.opengeospatial.org/is/14-084r2/14-084r2.html
> Example:
> {noformat}
> @stboundedby,urn:ogc:def:crs:CRS:1.3:84,2D,50.23 9.23,50.31
> 9.27,2012-01-17T12:33:41Z,2012-01-17T12:37:00Z,sec
> @columns,mfidref,trajectory,state,xsd:token,"type code",xsd:integer
> a,10,150,11.0 2.0 12.0 3.0,walking,1
> b,10,190,10.0 2.0 11.0 3.0,walking,2
> a,150,190,12.0 3.0 10.0 3.0,walking,2
> c,10,190,12.0 1.0 10.0 2.0 11.0 3.0,vehicle,1
> {noformat}
> Implementing this is a relatively simple format allow us to test the
> following Apache SIS capabilities in a real use-case scenario:
> * {{CRS.forCode(String)}} which create a Coordinate Reference System object
> from an authority code.
> * {{org.apache.sis.feature}} implementation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-336) URL to EPSG installation instructions should be customizable
[ https://issues.apache.org/jira/browse/SIS-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux updated SIS-336: Fix Version/s: (was: 1.1) 1.2 Affects Version/s: 1.1 1.0 > URL to EPSG installation instructions should be customizable > > > Key: SIS-336 > URL: https://issues.apache.org/jira/browse/SIS-336 > Project: Spatial Information Systems > Issue Type: Task > Components: Referencing >Affects Versions: 0.7, 0.8, 1.0, 1.1 >Reporter: Martin Desruisseaux >Priority: Minor > Fix For: 1.2 > > > When SIS failed to create a Coordinate Reference System because the EPSG > geodetic dataset is not installed, the error message contains a link to the > http://sis.apache.org/epsg.html page for guiding the user to the installation > process. However applications that use Apache SIS may have their own EPSG > installation process. Those application should have the possibility to > replace the above-cited URL by their own URL. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SIS-318) Support PassThroughTransform directly into AbstractMathTransform
[
https://issues.apache.org/jira/browse/SIS-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-318:
Fix Version/s: (was: 1.1)
1.2
Affects Version/s: 1.1
1.0
> Support PassThroughTransform directly into AbstractMathTransform
>
>
> Key: SIS-318
> URL: https://issues.apache.org/jira/browse/SIS-318
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Referencing
>Affects Versions: 0.5, 0.6, 0.7, 0.8, 1.0, 1.1
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Minor
> Labels: performance
> Fix For: 1.2
>
>
> Add the 4 variants (for {{float[]}} and {{double[]}} arrays) of the following
> method in {{AbstractMathTransform}}:
> {code:java}
> protected void transform(double[] srcPts, int srcOff, int srcInc,
> double[] dstPts, int dstOff, int dstInc, int numPts)
> throws TransformException;
> {code}
> The difference compared to existing methods is the addition of {{srcInc}} and
> {{dstInc}} parameters. Then, move the {{AbstractMathTransform}} default
> implementations of {{transform(…)}} methods under those 4 new methods. The
> default implementation of previous methods would redirect to the new ones
> like below:
> {code:java}
> @Override
> public void transform(double[] srcPts, int srcOff,
> double[] dstPts, int dstOff, int numPts) throws
> TransformException
> {
> transform(srcPts, srcOff, getSourceDimensions(),
> dstPts, dstOff, getTargetDimensions(), numPts);
> }
> {code}
> This approach should ensure {{MathTransform}} methods consistency no matter
> if a sub-class override the old methods or the new ones. Modify all Apache
> SIS implementations that override the old methods for overriding the new ones
> instead.
> With those news methods, we can modify {{PassThroughTransform}}
> implementation for invoking those methods on the sub-transform with
> {{srcInc}} and {{dstInc}} values increased by {{firstAffectedOrdinate}} +
> {{numTrailingOrdinates}}. The performance benefit may be important since
> {{PassThroughTransform}} can hardly implement the {{transform}} method in an
> efficient way otherwise. We will still need the current
> {{transformOverlapping}} private method however as a fallback when array
> regions overlap.
> This approach would also make easier to concatenate the matrices of linear
> transforms. In the current implementation we lost a concatenation opportunity
> if one linear transform is the last {{MathTransform}} (in a chain of a
> concatenated transforms) inside the {{PassThroughTransform}}, while the other
> linear transform is the first {{MathTransform}} outside the
> {{PassThroughTransform}}. We could move the former linear transform outside
> the {{PassThroughTransform}}, but it cause confusing WKT to be formatted if
> the transforms inside the {{PassThroughTransform}} have a
> {{ContextualParameters}}. We expect that this problem would be solved with
> the fix proposed in this issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-300) Complete the information provided in Citations constants
[
https://issues.apache.org/jira/browse/SIS-300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-300:
Fix Version/s: (was: 1.1)
1.2
Affects Version/s: 1.1
> Complete the information provided in Citations constants
>
>
> Key: SIS-300
> URL: https://issues.apache.org/jira/browse/SIS-300
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Metadata
>Affects Versions: 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 1.0, 1.1
>Reporter: Martin Desruisseaux
>Priority: Minor
> Fix For: 1.2
>
>
> The {{org.apache.sis.metadata.iso.citation.Citations}} class contains various
> instances of {{Citation}} as static final constants, but those constants
> contain only the citation title at this time. We need to complete them with
> more information like the responsible party. In particular, we need to make
> sure that the constants contain enough information for forming a valid GML
> document when marshalled in XML (currently, they do not pass validation
> tests).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (SIS-237) Modified Azimuthal Equidistant (EPSG:9832)
[ https://issues.apache.org/jira/browse/SIS-237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux resolved SIS-237. - Resolution: Fixed > Modified Azimuthal Equidistant (EPSG:9832) > -- > > Key: SIS-237 > URL: https://issues.apache.org/jira/browse/SIS-237 > Project: Spatial Information Systems > Issue Type: Sub-task > Components: Referencing >Reporter: Martin Desruisseaux >Assignee: Martin Desruisseaux >Priority: Minor > Fix For: 1.1 > > > For various islands in Micronesia. See §1.3.16.1 in IOGP Publication 373-7-2 > – Geomatics Guidance Note number 7, part 2 – April 2015. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (SIS-210) Enforce precedence of EPSG codes over names at parsing time
[
https://issues.apache.org/jira/browse/SIS-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-210:
Fix Version/s: (was: 1.1)
1.2
Affects Version/s: 1.1
1.0
> Enforce precedence of EPSG codes over names at parsing time
> ---
>
> Key: SIS-210
> URL: https://issues.apache.org/jira/browse/SIS-210
> Project: Spatial Information Systems
> Issue Type: Sub-task
> Components: Referencing
>Affects Versions: 0.6, 0.7, 0.8, 1.0, 1.1
>Reporter: Martin Desruisseaux
>Priority: Minor
> Fix For: 1.2
>
>
> The specification §9.3.2 said:
> {quote}
> If an identifier is provided as an attribute within the conversion> object, because it is expected to describe a complete collection
> of zone name, method, parameters and parameter values, it shall override any
> identifiers given within the map projection method and map projection
> parameter objects.
> {quote}
> However this would require the {{GeodeticObjectParser}} to hold a
> {{CoordinateOperationAuthorityFactory}}, which we do not yet implement.
> Likewise, EPSG code in {{Parameter}} elements are also supposed to have
> precedence over the parameter name. This is not yet implemented in SIS, but
> may be less critical since SIS implementation is quite lenient (without
> introducing ambiguities) regarding parameter names.
> For now, the only place where EPSG codes take precedence over names is when
> fetching the {{OperationMethod}} objects, which is the most critical place
> where we observed ambiguities in our experience.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-207) Support Bearing element in axes
[
https://issues.apache.org/jira/browse/SIS-207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-207:
Fix Version/s: (was: 1.1)
1.2
Affects Version/s: 1.1
1.0
> Support Bearing element in axes
> ---
>
> Key: SIS-207
> URL: https://issues.apache.org/jira/browse/SIS-207
> Project: Spatial Information Systems
> Issue Type: Sub-task
> Components: Referencing
>Affects Versions: 0.4, 0.5, 0.6, 0.7, 0.8, 1.0, 1.1
>Reporter: Martin Desruisseaux
>Priority: Minor
> Fix For: 1.2
>
>
> Polar coordinate systems may have a "{{clockwise}}" or "{{counterClockwise}}"
> axis direction followed by a {{BEARING\[angle, ANGLEUNIT\[...\]\]}} element.
> The bearing gives the specified direction from which the rotation is
> measured. Those axis directions are not yet supported in Apache SIS. If we
> wish to support them in a future version, we could adopt a strategy similar
> to the {{DirectionAlongMeridian}} package-private class.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-193) Remove the workaround for ServiceLoader bug
[
https://issues.apache.org/jira/browse/SIS-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-193:
Fix Version/s: (was: 1.1)
1.2
Affects Version/s: 1.1
1.0
> Remove the workaround for ServiceLoader bug
> ---
>
> Key: SIS-193
> URL: https://issues.apache.org/jira/browse/SIS-193
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Referencing
>Affects Versions: 0.6, 0.7, 0.8, 1.0, 1.1
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Minor
> Labels: JDK9
> Fix For: 1.2
>
>
> As of 1.8.0_31-b13, {{java.util.ServiceLoader}} does not support usage of a
> second {{Iterator}} in the middle of a previous iteration. The following Java
> code provides two simple tests with a {{ServiceLoader}} iterating over two
> elements.
> {code:java}
> import java.util.Iterator;
> import java.util.ServiceLoader;
> public class ServiceLoaderTest {
> public static class I1 extends ServiceLoaderTest {} // A dummy provider.
> public static class I2 extends ServiceLoaderTest {} // An other provider.
> public static void main(String[] args) {
> test1();
> test2();
> }
> private static void test1() {
> System.out.println();
> System.out.println(" TEST 1 ");
> ServiceLoader loader =
> ServiceLoader.load(ServiceLoaderTest.class);
> Iterator it1 = loader.iterator();
> System.out.println("it1.hasNext() = " + it1.hasNext());
> System.out.println("it1.next()= " + it1.next());
> Iterator it2 = loader.iterator();
> System.out.println("it2.hasNext() = " + it2.hasNext());
> System.out.println("it2.next()= " + it2.next());
> System.out.println("it1.hasNext() = " + it1.hasNext());
> System.out.println("it1.next()= " + it1.next());
> System.out.println("it2.hasNext() = " + it2.hasNext()); // Expected
> "true" here, but get "false".
> }
> private static void test2() {
> System.out.println();
> System.out.println(" TEST 2 ");
> ServiceLoader loader =
> ServiceLoader.load(ServiceLoaderTest.class);
> Iterator it1 = loader.iterator();
> System.out.println("it1.hasNext() = " + it1.hasNext());
> System.out.println("it1.next()= " + it1.next());
> Iterator it2 = loader.iterator();
> System.out.println("it1.hasNext() = " + it1.hasNext());
> System.out.println("it2.hasNext() = " + it2.hasNext());
> System.out.println("it1.next()= " + it1.next());
> System.out.println("it2.next()= " + it2.next()); //
> ConcurrentModificationException here.
> }
> }
> {code}
> The second test throws the following exception:
> {noformat}
> Exception in thread "main" java.util.ConcurrentModificationException
> at
> java.util.LinkedHashMap$LinkedHashIterator.nextNode(LinkedHashMap.java:711)
> at
> java.util.LinkedHashMap$LinkedEntryIterator.next(LinkedHashMap.java:744)
> at
> java.util.LinkedHashMap$LinkedEntryIterator.next(LinkedHashMap.java:742)
> at java.util.ServiceLoader$1.next(ServiceLoader.java:479)
> at test.ServiceLoaderTest.test2(ServiceLoaderTest.java:47)
> at test.ServiceLoaderTest.main(ServiceLoaderTest.java:12)
> {noformat}
> The workaround applied in Apache SIS has been to add a {{LazySet}} internal
> class which wraps an {{Iterable}} and caches its values. But this is a little
> bit unfortunate since {{ServiceLoader}} already caches its values.
> {{ServiceLoader}} is probably going to be significantly rewritten in JDK9 as
> a side effect of the Jigsaw project. So we should revisit if our {{LazySet}}
> workaround is still needed on a JDK9 branch.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-206) Verify axis name, abbreviation and direction constraints at format time
[
https://issues.apache.org/jira/browse/SIS-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-206:
Fix Version/s: (was: 1.1)
1.2
Affects Version/s: 1.1
1.0
> Verify axis name, abbreviation and direction constraints at format time
> ---
>
> Key: SIS-206
> URL: https://issues.apache.org/jira/browse/SIS-206
> Project: Spatial Information Systems
> Issue Type: Sub-task
> Components: Referencing
>Affects Versions: 0.4, 0.5, 0.6, 0.7, 0.8, 1.0, 1.1
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Minor
> Fix For: 1.2
>
>
> ISO 19162 puts many constraints on axis names, abbreviations and directions.
> Some of those constraints are inherited from ISO 19111, and some others are
> specific to ISO 19162. Apache SIS verifies some of those constraints at
> {{CoordinateSystem}} construction time, but not all. Constraints *not*
> verified by Apache SIS includes:
> * Axis names of geographic CRS shall be ‘_latitude_’, ‘_longitude_’ and (in
> 3D case) ‘_ellipsoidal height_’.
> * For other kind of CRS axis names shall be as documented in ISO 19111.
> * Abbreviation of ellipsoidal height shall be _h_.
> * Abbreviations of geocentric CRS axes shall be _X_, _Y_, _Z_.
> * Axis directions are restricted to _north_, _east_ and _up_ for geographic
> CRS (no _south_, _west_ or _down_).
> Apache SIS does not verify those constraints at formatting time. We may argue
> that this is not formatter job.
> {color:red}Update (May 2015):{color} on-the-fly renaming of "Geodetic
> longitude/latitude" into "longitude/latitude" now supported.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-136) Fused multiply-add in org.apache.sis.referencing.operation
[
https://issues.apache.org/jira/browse/SIS-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-136:
Fix Version/s: (was: 1.1)
1.2
Affects Version/s: 1.1
1.0
> Fused multiply-add in org.apache.sis.referencing.operation
> --
>
> Key: SIS-136
> URL: https://issues.apache.org/jira/browse/SIS-136
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Referencing
>Affects Versions: 0.7, 0.8, 1.0, 1.1
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Minor
> Labels: JDK9
> Fix For: 1.2
>
>
> This issue is for tracking the progress on the two following Oracle tasks:
> * [JDK-4851642 : Add FMA to Java math
> library|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4851642]
> * [JDK-4919337 : Augment Java math libraries with more methods from C libm
> and IEEE 754|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4919337]
> If _Fused Multiply-Add_ (FMA) are added to the Java language, we should
> leverage them in coordinate operations. In some cases (e.g. {{MatrixSIS}}
> subclasses), the main goal is not performance, but rather accuracy. Matrix
> inversions usually have rounding errors, and those rounding errors may be
> propagated in every corners of SIS library because of the central role played
> by matrices in SIS. While rounding errors can not be completely avoided,
> reducing them as much as possible may reduce the risk of surprising
> behaviour, especially when converting the pixel coordinates between two _Grid
> Coverages_.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (SIS-513) When rounding grids, allow per axis strategy instead of a single global one.
[
https://issues.apache.org/jira/browse/SIS-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17416696#comment-17416696
]
Martin Desruisseaux edited comment on SIS-513 at 9/17/21, 1:41 PM:
---
The strategy described in above comment is used instead of per-axis rounding
mode.
was (Author: desruisseaux):
The strategy described in above comment is used instead if per-axis rounding
mode.
> When rounding grids, allow per axis strategy instead of a single global one.
>
>
> Key: SIS-513
> URL: https://issues.apache.org/jira/browse/SIS-513
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Coverage
>Affects Versions: 1.0
>Reporter: Alexís Manin
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.1
>
>
> Related to the usage of
> `{color:#00}org.apache.sis.coverage.grid.GridRoundingMode{color}` :
>
> At the moment, its usage is often considered as a global configuration for
> every axes treated (Example:
> [GridDerivation.rounding()).|https://sis.apache.org/apidocs/org/apache/sis/coverage/grid/GridDerivation.html#rounding(org.apache.sis.coverage.grid.GridRoundingMode)]
>
> A possible improvement would be to specify the rounding strategy
> independently for each axis of the grid. One possible use-case would be to
> ease management of 2D resample over 3D+ datasets.
>
> For example, if the source coverage of a resample defines a grid [ 0..99,
> 0..99, 0..0 ], with the axes being respectively longitude, latitude and time,
> the pipeline of operation over the grid could extend all axes, even time
> slice depending on chosen rounding mode. Such behavior can fail resampling
> operation, but would be easily avoidable if we can specify that time is a
> special axis to round using NEAREST strategy.
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-125) ModifiableMetadata.nonNullCollection(...) should determine more accuratly if the metadata object is being marshalled
[
https://issues.apache.org/jira/browse/SIS-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-125:
Fix Version/s: (was: 1.1)
Affects Version/s: 1.1
1.0
> ModifiableMetadata.nonNullCollection(...) should determine more accuratly if
> the metadata object is being marshalled
>
>
> Key: SIS-125
> URL: https://issues.apache.org/jira/browse/SIS-125
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Metadata
>Affects Versions: 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 1.0, 1.1
>Reporter: Martin Desruisseaux
>Priority: Minor
>
> Despite its name, the {{ModifiableMetadata.nonNullCollection(...)}} method
> may return {{null}} in the special case of XML marshalling if and only if the
> marshalled element is optional. This is a hack for preventing JAXB to create
> empty nodes for empty properties. However in current implementation, the
> decision to return null or not is set by a thread-local flag, which apply to
> the {{ModifiableMetadata}} instances being marshalled in that particular
> thread. This approach does not work well when the user provides its own
> metadata subclass which create new elements in the collection on the fly.
> We may need to make the {{ModifiableMetadata.canReturnNull()}} method more
> accurate in order to not only use a thread-local flag, but also check for the
> particular metadata instance being marshalled. This would require storing
> somewhere a reference to the element being marshalled, and cleaning that
> reference after the marshalling of that particular element finished.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (SIS-513) When rounding grids, allow per axis strategy instead of a single global one.
[
https://issues.apache.org/jira/browse/SIS-513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux resolved SIS-513.
-
Resolution: Won't Fix
The strategy described in above comment is used instead if per-axis rounding
mode.
> When rounding grids, allow per axis strategy instead of a single global one.
>
>
> Key: SIS-513
> URL: https://issues.apache.org/jira/browse/SIS-513
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Coverage
>Affects Versions: 1.0
>Reporter: Alexís Manin
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.1
>
>
> Related to the usage of
> `{color:#00}org.apache.sis.coverage.grid.GridRoundingMode{color}` :
>
> At the moment, its usage is often considered as a global configuration for
> every axes treated (Example:
> [GridDerivation.rounding()).|https://sis.apache.org/apidocs/org/apache/sis/coverage/grid/GridDerivation.html#rounding(org.apache.sis.coverage.grid.GridRoundingMode)]
>
> A possible improvement would be to specify the rounding strategy
> independently for each axis of the grid. One possible use-case would be to
> ease management of 2D resample over 3D+ datasets.
>
> For example, if the source coverage of a resample defines a grid [ 0..99,
> 0..99, 0..0 ], with the axes being respectively longitude, latitude and time,
> the pipeline of operation over the grid could extend all axes, even time
> slice depending on chosen rounding mode. Such behavior can fail resampling
> operation, but would be easily avoidable if we can specify that time is a
> special axis to round using NEAREST strategy.
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (SIS-510) Remove sis-gdal module
[
https://issues.apache.org/jira/browse/SIS-510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux resolved SIS-510.
-
Resolution: Fixed
Two commits in order:
* {{97fcad5dc0fe393da7e8ef315498164609e5a8e7}} removes the "sis-gdal" module.
* {{32936ed8d4bcec29f82d0c302b0a3bcf031127f0}} removes support types.
Support types removed by last commit are:
* {{SpecializedOperationFactory}} (used for finding the coordinate operation
between a pair of CRS should be determined by an external library).
* {{OS}} (used for loading native libraries).
> Remove sis-gdal module
> --
>
> Key: SIS-510
> URL: https://issues.apache.org/jira/browse/SIS-510
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Referencing
>Affects Versions: 0.8, 1.0
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.1
>
>
> Development and maintenance of GeoAPI wrappers for PROJ moved to a separated
> project:
> [https://github.com/Kortforsyningen/PROJ-JNI]
> {color:#de350b}Edit (September 2021):{color} project moved to
> [https://github.com/OSGeo/PROJ-JNI]
> The PROJ native bindings in Apache SIS should be removed. Maybe we will
> recreate that module in the future if we want to add GDAL bindings instead of
> only PROJ, but current implementation did not reach that level. Furthermore
> the [JEP 191: Foreign Function Interface|http://openjdk.java.net/jeps/191]
> may change the way to do that. Alternatively we may also do this binding by
> expanding above-cited Kortforsyningen project instead of doing this work in
> SIS.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-510) Remove sis-gdal module
[
https://issues.apache.org/jira/browse/SIS-510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-510:
Description:
Development and maintenance of GeoAPI wrappers for PROJ moved to a separated
project:
[https://github.com/Kortforsyningen/PROJ-JNI]
{color:#de350b}Edit (September 2021):{color} project moved to
[https://github.com/OSGeo/PROJ-JNI]
The PROJ native bindings in Apache SIS should be removed. Maybe we will
recreate that module in the future if we want to add GDAL bindings instead of
only PROJ, but current implementation did not reach that level. Furthermore the
[JEP 191: Foreign Function Interface|http://openjdk.java.net/jeps/191] may
change the way to do that. Alternatively we may also do this binding by
expanding above-cited Kortforsyningen project instead of doing this work in SIS.
was:
Development and maintenance of GeoAPI wrappers for PROJ moved to a separated
project:
[https://github.com/Kortforsyningen/PROJ-JNI]
{color:#de350b}*Edit (September 2021):*{color} project moved to
[https://github.com/OSGeo/PROJ-JNI]
The PROJ native bindings in Apache SIS should be removed. Maybe we will
recreate that module in the future if we want to add GDAL bindings instead of
only PROJ, but current implementation did not reach that level. Furthermore the
[JEP 191: Foreign Function Interface|http://openjdk.java.net/jeps/191] may
change the way to do that. Alternatively we may also do this binding by
expanding above-cited Kortforsyningen project instead of doing this work in SIS.
> Remove sis-gdal module
> --
>
> Key: SIS-510
> URL: https://issues.apache.org/jira/browse/SIS-510
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Referencing
>Affects Versions: 0.8, 1.0
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.1
>
>
> Development and maintenance of GeoAPI wrappers for PROJ moved to a separated
> project:
> [https://github.com/Kortforsyningen/PROJ-JNI]
> {color:#de350b}Edit (September 2021):{color} project moved to
> [https://github.com/OSGeo/PROJ-JNI]
> The PROJ native bindings in Apache SIS should be removed. Maybe we will
> recreate that module in the future if we want to add GDAL bindings instead of
> only PROJ, but current implementation did not reach that level. Furthermore
> the [JEP 191: Foreign Function Interface|http://openjdk.java.net/jeps/191]
> may change the way to do that. Alternatively we may also do this binding by
> expanding above-cited Kortforsyningen project instead of doing this work in
> SIS.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-510) Remove sis-gdal module
[
https://issues.apache.org/jira/browse/SIS-510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-510:
Description:
Development and maintenance of GeoAPI wrappers for PROJ moved to a separated
project:
[https://github.com/Kortforsyningen/PROJ-JNI]
{color:#de350b}*Edit (September 2021):*{color} project moved to
[https://github.com/OSGeo/PROJ-JNI]
The PROJ native bindings in Apache SIS should be removed. Maybe we will
recreate that module in the future if we want to add GDAL bindings instead of
only PROJ, but current implementation did not reach that level. Furthermore the
[JEP 191: Foreign Function Interface|http://openjdk.java.net/jeps/191] may
change the way to do that. Alternatively we may also do this binding by
expanding above-cited Kortforsyningen project instead of doing this work in SIS.
was:
Development and maintenance of GeoAPI wrappers for PROJ moved to a separated
project:
https://github.com/Kortforsyningen/PROJ-JNI
Note: above project may move to OSGeo organization if we have a volunteer for
doing the "administrative" work.
The PROJ native bindings in Apache SIS should be removed. Maybe we will
recreate that module in the future if we want to add GDAL bindings instead of
only PROJ, but current implementation did not reach that level. Furthermore the
[JEP 191: Foreign Function Interface|http://openjdk.java.net/jeps/191] may
change the way to do that. Alternatively we may also do this binding by
expanding above-cited Kortforsyningen project instead of doing this work in SIS.
> Remove sis-gdal module
> --
>
> Key: SIS-510
> URL: https://issues.apache.org/jira/browse/SIS-510
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Referencing
>Affects Versions: 0.8, 1.0
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.1
>
>
> Development and maintenance of GeoAPI wrappers for PROJ moved to a separated
> project:
> [https://github.com/Kortforsyningen/PROJ-JNI]
> {color:#de350b}*Edit (September 2021):*{color} project moved to
> [https://github.com/OSGeo/PROJ-JNI]
> The PROJ native bindings in Apache SIS should be removed. Maybe we will
> recreate that module in the future if we want to add GDAL bindings instead of
> only PROJ, but current implementation did not reach that level. Furthermore
> the [JEP 191: Foreign Function Interface|http://openjdk.java.net/jeps/191]
> may change the way to do that. Alternatively we may also do this binding by
> expanding above-cited Kortforsyningen project instead of doing this work in
> SIS.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-500) Deprecate (for removal) InterpolatedMolodenskyTransform
[
https://issues.apache.org/jira/browse/SIS-500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-500:
Fix Version/s: (was: 1.1)
Affects Version/s: 1.1
We postdone this task until the completion of OGC work on GGXF format. We will
wait to see if GGXF data make this class useful, if not we will deprecate it.
> Deprecate (for removal) InterpolatedMolodenskyTransform
> ---
>
> Key: SIS-500
> URL: https://issues.apache.org/jira/browse/SIS-500
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Referencing
>Affects Versions: 0.7, 0.8, 1.0, 1.1
>Reporter: Martin Desruisseaux
>Priority: Major
>
> {{InterpolatedMolodenskyTransform}} applies a transformation between two
> geographic CRS by performing geocentric translations interpolated from a grid
> file, but using Molodensky approximation. The errors caused by this
> approximation is greater than the intended precision of those grid files,
> which make the use of this class dubious Indeed,
> {{InterpolatedMolodenskyTransform}} is not used anywhere and should be
> removed. The class to use instead is {{InterpolatedGeocentricTransform}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (SIS-484) Avoid use of same package name in two different modules
[
https://issues.apache.org/jira/browse/SIS-484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux resolved SIS-484.
-
Resolution: Fixed
Moved {{InternationalString}} implementation classes to {{org.apache.sis.util}}
package. This is an anticipation for Jigsaw modularisation.
> Avoid use of same package name in two different modules
> ---
>
> Key: SIS-484
> URL: https://issues.apache.org/jira/browse/SIS-484
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Metadata, Referencing, Utilities
>Affects Versions: 1.0
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.1
>
>
> The following packages have classes defined by two different modules:
>
> * {{org.apache.sis.internal.simple}}
> * {{org.apache.sis.util.iso}}
> * {{org.apache.sis.metadata.iso}}
> The cases of {{metadata.iso}} is already solved on master branch. The case of
> {{internal.simple}} should be easy since it is about internal classes. The
> {{util.iso}} case may be the only problematic one.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (SIS-484) Avoid use of same package name in two different modules
[
https://issues.apache.org/jira/browse/SIS-484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux reassigned SIS-484:
---
Assignee: Martin Desruisseaux
> Avoid use of same package name in two different modules
> ---
>
> Key: SIS-484
> URL: https://issues.apache.org/jira/browse/SIS-484
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Metadata, Referencing, Utilities
>Affects Versions: 1.0
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
> Fix For: 1.1
>
>
> The following packages have classes defined by two different modules:
>
> * {{org.apache.sis.internal.simple}}
> * {{org.apache.sis.util.iso}}
> * {{org.apache.sis.metadata.iso}}
> The cases of {{metadata.iso}} is already solved on master branch. The case of
> {{internal.simple}} should be easy since it is about internal classes. The
> {{util.iso}} case may be the only problematic one.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-442) Cache CRS.findOperation(…, areaOfInteret) when area of interest is non null
[
https://issues.apache.org/jira/browse/SIS-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-442:
Fix Version/s: (was: 1.1)
1.2
Affects Version/s: 1.1
1.0
> Cache CRS.findOperation(…, areaOfInteret) when area of interest is non null
> ---
>
> Key: SIS-442
> URL: https://issues.apache.org/jira/browse/SIS-442
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Referencing
>Affects Versions: 0.7, 0.8, 1.0, 1.1
>Reporter: Martin Desruisseaux
>Priority: Major
> Fix For: 1.2
>
>
> Calls to {{CRS.findOperation(sourceCRS, targetCRS, areaOfInterest)}}
> currently cache the {{CoordinateOperation}} only when {{areaOfInterest}} is
> null. It is hard to implement a general cache mechanism for all non-null area
> of interest, but we can implement an intermediate solution:
> # When {{EPSGFactory}} or {{CoordinateOperationRegistry}} detects that there
> is only one {{CoordinateOperation}} for given source and target CRS, it
> automatically adds some sentinel value in {{PositionalAccuracy}} metadata. It
> could be some internal sub-class.
> # When {{DefaultCoordinateOperationFactory}} sees above sentinel values, it
> allows caching even if {{areaOfInterest}} is non-null. Otherwise caching is
> enabled only if {{areaOfInterest}} is null, as today.
> # After this optimization has been implemented, we should search for
> occurrences of {{factory()}} in {{Envelopes}} and replace them by calls to
> {{Envelope.findOperation(Envelope, Envelope)}}.
> We could also take this opportunity for adding an information message if we
> detected may transformations for the same pair of CRS. Something like _"Note:
> many transformations are defined for this pair of referencing systems in
> different domains of validity."_
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-403) Upgrade org.apache.sis.test.integration.MetadataTest to ISO 19115-3
[
https://issues.apache.org/jira/browse/SIS-403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-403:
Fix Version/s: (was: 1.1)
Affects Version/s: 1.1
> Upgrade org.apache.sis.test.integration.MetadataTest to ISO 19115-3
> ---
>
> Key: SIS-403
> URL: https://issues.apache.org/jira/browse/SIS-403
> Project: Spatial Information Systems
> Issue Type: Sub-task
> Components: Metadata
>Affects Versions: 1.0, 1.1
>Reporter: Martin Desruisseaux
>Priority: Major
>
> The {{org.apache.sis.test.integration.MetadataTest}} class currently marshal
> and unmarshal metadata in the legacy ISO 19139:2007 format. This is partially
> because it includes {{VerticalCRS}} component, which requires GML 3.2. We
> should upgrade this class for testing both schema.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-411) GPX data store should implement WritableFeatureSet
[
https://issues.apache.org/jira/browse/SIS-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-411:
Fix Version/s: (was: 1.1)
1.2
Affects Version/s: 1.1
1.0
> GPX data store should implement WritableFeatureSet
> --
>
> Key: SIS-411
> URL: https://issues.apache.org/jira/browse/SIS-411
> Project: Spatial Information Systems
> Issue Type: New Feature
> Components: Storage
>Affects Versions: 0.8, 1.0, 1.1
>Reporter: Martin Desruisseaux
>Priority: Major
> Fix For: 1.2
>
>
> {{org.apache.sis.internal.storage.gpx.Store}} implement the {{FeatureSet}}
> interface. It also provides the following method:
> {code:java}
> public void write(Metadata metadata, Stream features)
> {code}
> but it does not yet matches any public API. We need to retrofit that method
> into the methods provided by {{WritableFeatureSet}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SIS-401) Use of GML 3.2 implies the use of ISO 19139:2007 metadata
[
https://issues.apache.org/jira/browse/SIS-401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-401:
Fix Version/s: (was: 1.1)
1.2
Affects Version/s: 1.1
> Use of GML 3.2 implies the use of ISO 19139:2007 metadata
> -
>
> Key: SIS-401
> URL: https://issues.apache.org/jira/browse/SIS-401
> Project: Spatial Information Systems
> Issue Type: Sub-task
> Components: Metadata, Referencing
>Affects Versions: 1.0, 1.1
>Reporter: Martin Desruisseaux
>Priority: Major
> Fix For: 1.2
>
>
> The use of GML 3.2 implies the use of ISO 19139:2007 metadata for describing
> the extent, positional accuracy, identifiers, _etc._ For now (in Apache SIS
> 1.0), we use an {{\@UseLegacyMetadata}} annotations (internal API). When this
> annotation is found on the object to marshal, {{PooledMarshaller}}
> automatically set the metadata version to 2007. However this works only for
> the root element. If the user specifies another object which itself contains
> GML, this will not work.
> If we want this automatic selection of ISO 19139:2007 metadata to work no
> matter where the GML elements appear, we need a different approach. One
> possible approach is to update the {{org.apache.sis.internal.jaxb.Context}}
> state in a way similar to what we do for {{Locale}}. This can be done by
> addition the following constructor and modifying the {{push(…)}} method like
> below (only the main elements that are modified are shown below):
> {code:java}
> public final class Context extends MarshalContext {
> /**
> * The locale to use for marshalling, or {@code null} if no locale were
> explicitly specified.
> */
> private final Locale locale;
> /**
> * Creates a new context identical to the given parent except for the
> locale and bitmask.
> */
> private Context(final Context parent, final int bitMasks, final Locale
> locale) {
> this.bitMasks = bitMasks;
> this.locale= locale;
> this.timezone = parent.timezone;
> this.schemas = parent.schemas;
> this.versionGML= parent.versionGML;
> this.resolver = parent.resolver;
> this.converter = parent.converter;
> this.warningListener = parent.warningListener;
> this.identifiers = parent.identifiers;
> this.identifiedObjects = parent.identifiedObjects;
> this.previous = parent;
> }
> @Override
> public final Locale getLocale() {
> return locale;
> }
> /**
> * Sets the locale to the given value, optionally with additional bits to
> set.
> * The old locales and bit masks are remembered and will be restored by
> the next call to {@link #pull()}.
> * This method can be invoked when marshalling object that need to
> marshall their children in a different
> * locale, like below:
> *
> * {@preformat java
> * private void beforeMarshal(Marshaller marshaller) {
> * Context.push(0, language);
> * }
> *
> * private void afterMarshal(Marshaller marshaller) {
> * Context.pull();
> * }
> * }
> *
> * @param bitsToSet new bits to set, or 0 for no change.
> * @param locale the locale to set, or {@code null} for keeping the
> current locale.
> */
> public static void push(final int bitsToSet, Locale locale) {
> Context current = current();
> if (current != null) {
> if (locale == null) {
> locale = current.getLocale();
> }
> current = new Context(current, current.bitMasks | bitsToSet,
> locale);
> CURRENT.set(current);
> }
> }
> /**
> * Restores the locale which was used prior the call to {@link #push(int,
> Locale)}.
> */
> public static void pull() {
> final Context current = current();
> if (current != null) {
> CURRENT.set(current.previous);
> }
> }
> }
> {code}
> Then, in the {{org.apache.sis.referencing}} package:
> {code:java}
> public class AbstractIdentifiedObject implements IdentifiedObject {
> /**
> * Invoked by JAXB {@link javax.xml.bind.Marshaller} before this object
> is marshalled to XML.
> * This method sets the locale to be used for XML marshalling to the
> metadata language.
> */
> @SuppressWarnings("unused")
> private void beforeMarshal(final Marshaller marshaller) {
> Context.push(Context.LEGACY_METADATA, null);
> }
> /**
> * Invoked by JAXB {@link javax.xml.bind.Marshaller} after this object
> has been marshalled to
> * XML. This
[jira] [Updated] (SIS-400) Complete MarshallingTest and add UnmarshallingTest
[
https://issues.apache.org/jira/browse/SIS-400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-400:
Fix Version/s: (was: 1.1)
Affects Version/s: 1.1
> Complete MarshallingTest and add UnmarshallingTest
> --
>
> Key: SIS-400
> URL: https://issues.apache.org/jira/browse/SIS-400
> Project: Spatial Information Systems
> Issue Type: Sub-task
> Components: Metadata
>Affects Versions: 1.0, 1.1
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Major
>
> {{org.apache.sis.metadata.iso.MarshallingTest}} merely tests that marshalling
> a {{DefaultMetadata}} does not produce an exception. We need to improve the
> tests by comparing with expected documents in both legacy ISO 19139:2007 and
> new ISO 19115-3:2016 format. The XML documents produced by ImageMatters can
> be used as a starting point.
> Conversely, the {{UnmarshallingTest}} class on ImageMatters repository should
> be adapted and included in the test suite.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
