[jira] [Updated] (SIS-171) Upgrade NetCDF to ISO-19115 mapping
[
https://issues.apache.org/jira/browse/SIS-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-171:
Description:
The mapping from NetCDF attributes to the ISO-19115 metadata is defined at this
page:
* [NetCDF Attribute Convention for Dataset
Discovery|http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery]
* [NetCDF, HDF, and ISO
Metadata|http://wiki.esipfed.org/index.php/NetCDF,_HDF,_and_ISO_Metadata]
* [NcISO|https://geo-ide.noaa.gov/wiki/index.php?title=NcISO] (is XSLT files
for the mapping from NetCDF metadata to ISO 19115-2)
The mapping implemented since SIS 0.3 is the version 1.0 of above convention.
Available versions as of May 2017 is 1.3. We will need to upgrade the mapping
implemented by SIS to the latest version.
h2. {color:green}UPDATE - June 1917{color}
Rob Wallace did a review and [posted his result on the mailing
list|https://lists.apache.org/thread.html/76c0ccf2e7e678a5525fc6ef633e06345c67286d077ab86e3c7f73f4@%3Cdev.sis.apache.org%3E].
Below is a copy of his result:
h3. Report on work to check consistency of attributeNames between ISO 19115,
ACDD 1-3 and Metadata paths in Javadoc June 2017
Resources used:
* [ACDD
1-3|http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery]
last modified version as of 24th January 2017
* SIS source > Retrieved on 1st June 2017:
{{storage/sis-netcdf/src/main/java/org/apache/sis/storage/netcdf/AttributeNames.java}}
* [AttributeNames
Javadoc|http://sis.apache.org/apidocs/org/apache/sis/storage/netcdf/AttributeNames.html]
> Retrieved 26th June 2017
* [ISO 19115 xsl
file|https://github.com/Unidata/threddsIso/blob/master/src/main/resources/xsl/nciso/UnidataDD2MI.xsl]
> Retrieved on 6th June 2017
In order to make the scanning of the XSL file easier, I (Rob): >
* Read the XSL file with csVed v2.5.1 and filtered out xsl lines
* Saved filtered version as CSV
* Read CSV file with Notepad++ v7.4.1. This facilitated the metadata element
searches.
||ACDD 1-3 Attribute Names||In Javadoc Heading List?||In Javadoc Field
Summary?||In Javadoc Field Detail?||Metadata Path in ISO 19115 XSL file||Field
and ISO 19115 path in
AttributeNames Class Source?||
|{{title}}|(/)|(/)|(/)|{{Metadata/citation/title}}|(/)|
|{{summary}}|(/)|(/)|(/)|{{Metadata/identificationInfo/abstract}}|(/)|
|{{keywords}}|(/)|(/)|(/)|{{Metadata/identificationInfo/descriptiveKeywords/keyword}}
with {{KeywordType.THEME}}|(/)|
|{{Conventions}}|(x)|(x)|(x)|{color:red}Needs to be implemented{color}|(x)|
was:
The mapping from NetCDF attributes to the ISO-19115 metadata is defined at this
page:
* [NetCDF Attribute Convention for Dataset
Discovery|http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery]
* [NetCDF, HDF, and ISO
Metadata|http://wiki.esipfed.org/index.php/NetCDF,_HDF,_and_ISO_Metadata]
* [NcISO|https://geo-ide.noaa.gov/wiki/index.php?title=NcISO] (is XSLT files
for the mapping from NetCDF metadata to ISO 19115-2)
The mapping implemented since SIS 0.3 is the version 1.0 of above convention.
Available versions as of May 2017 is 1.3. We will need to upgrade the mapping
implemented by SIS to the latest version.
h2. {color:green}UPDATE - June 1917{color}
Rob Wallace did a review and [posted his result on the mailing
list|https://lists.apache.org/thread.html/76c0ccf2e7e678a5525fc6ef633e06345c67286d077ab86e3c7f73f4@%3Cdev.sis.apache.org%3E].
Below is a copy of his result: {color:red}to be completed{color}
h3. Report on work to check consistency of attributeNames between ISO 19115,
ACDD 1-3 and Metadata paths in Javadoc June 2017
Resources used:
* [ACDD
1-3|http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery]
last modified version as of 24th January 2017
* SIS source > Retrieved on 1st June 2017:
{{storage/sis-netcdf/src/main/java/org/apache/sis/storage/netcdf/AttributeNames.java}}
* [AttributeNames
Javadoc|http://sis.apache.org/apidocs/org/apache/sis/storage/netcdf/AttributeNames.html]
> Retrieved 26th June 2017
* [ISO 19115 xsl
file|https://github.com/Unidata/threddsIso/blob/master/src/main/resources/xsl/nciso/UnidataDD2MI.xsl]
> Retrieved on 6th June 2017
In order to make the scanning of the XSL file easier, I: >
* Read the XSL file with csVed v2.5.1 and filtered out xsl lines
* Saved filtered version as CSV
* Read CSV file with Notepad++ v7.4.1. This facilitated the metadata element
searches.
||ACDD 1-3 Attribute Names||In Javadoc Heading List?||In Javadoc Field
Summary?||In Javadoc Field Detail?||Metadata Path in ISO 19115 XSL file||Field
and ISO 19115 path in
AttributeNames Class Source?||
|Highly Recommended:||
|{{title}}|Y|Y|Y|{{Metadata/citation/title}}|Y|
|{{summary}}|Y|Y|Y|{{Metadata/identificationInfo/abstract}}|Y|
|{{keywords}}|Y|Y|Y|{{Metadata/identificationInfo/descriptiveKeywords/keyword}}
with {{KeywordType.THEME}}|Y|
[jira] [Assigned] (SIS-351) Create metadata, CRS and tabular data editors in JavaFX
[ https://issues.apache.org/jira/browse/SIS-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux reassigned SIS-351: --- Assignee: Siddhesh Rane > Create metadata, CRS and tabular data editors in JavaFX > --- > > Key: SIS-351 > URL: https://issues.apache.org/jira/browse/SIS-351 > Project: Spatial Information Systems > Issue Type: New Feature > Components: GUI >Reporter: Martin Desruisseaux >Assignee: Siddhesh Rane > Labels: gsoc2017, mentor > > Creates the foundation of a GUI application for Apache SIS based on JavaFX. > This application should leverage the functionalities available in Apache SIS > 0.8. In particular: > * Read metadata from files in various formats (currently ISO 19139, GeoTIFF, > NetCDF, LANDSAT, GPX, Moving Features) > * Get Coordinate Reference System from a registry or from GML or WKT > definitions and apply coordinate transformations. > * Show vector data in a tabular format. > Since SIS does not yet have a renderer engine, we can not yet show maps in > the application. However the application should be designed with this goal in > mind. > This project should create a metadata editor showing the ISO 19115 metadata. > We should provide a simplified view with only the essential information, and > an advanced view showing all information. The information to shown should be > customizable. The user should be able to edit the metadata and save them in > ISO 19139 format. > The project should also create the necessary widgets for showing a Coordinate > Reference System (CRS) definition and allow the user to edit it. Another > widget should use the CRS definitions for applying coordinate operations (map > projections) using the existing Apache SIS referencing engine, and show the > result in a table with information about accuracy and domain of validity. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (SIS-361) NetCDF to ISO 19115:2014 mapping
Martin Desruisseaux created SIS-361:
---
Summary: NetCDF to ISO 19115:2014 mapping
Key: SIS-361
URL: https://issues.apache.org/jira/browse/SIS-361
Project: Spatial Information Systems
Issue Type: Task
Components: Storage
Affects Versions: 0.7, 0.6, 0.5
Reporter: Martin Desruisseaux
The {{org.org.apache.sis.storage.netcdf.AttributeNames}} class defines a
mapping from NetCDF attributes to ISO 19115:2003 metadata. This mapping is
defined by the following file:
*
https://github.com/Unidata/threddsIso/blob/master/src/main/resources/xsl/nciso/UnidataDD2MI.xsl
However as of June 2017, this file seems to have been defined for a mapping to
the 2003 version of ISO 19115. A mapping to the ISO 19115 revision published in
2014 could make some difference. This task enumerate some possible changes.
Ideally, those changes should be submitted to the UCAR community. Whether
Apache SIS should apply them on its own or not is an open question.
h2. ACDD {{history}} attribute
The NetCDF {{history}} attribute is documented as "Provides an audit trail for
modifications to the original data". It is currently indirectly mapped to data
quality information, which is defined in ISO 19115 as "overall assessment of
quality of a resource(s)":
{noformat}
Metadata.dataQualityInfo.lineage.statement = $history
Metadata.dataQualityInfo.scope.level = dataset
{noformat}
Since ISO 19115:2014, we could use the following instead. Documentation said
"Information about the provenance, sources and/or the production processes
applied to the resource", which seems more appropriate:
{noformat}
Metadata.resourceLineage.statement = $history
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (SIS-190) Implement the FeatureType model derived from ISO 19109
[
https://issues.apache.org/jira/browse/SIS-190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-190.
---
> Implement the FeatureType model derived from ISO 19109
> --
>
> Key: SIS-190
> URL: https://issues.apache.org/jira/browse/SIS-190
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Features
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Fix For: 0.5
>
>
> Implement the {{org.opengis.feature}} interfaces derived from ISO 19109.
> Those interfaces are available there:
> http://www.geoapi.org/snapshot/javadoc/org/opengis/feature/package-summary.html
> Those interfaces are derived from ISO 19109 - Rules for application schema.
> Abstract from ISO:
> {quote}
> Defines rules for creating and documenting application schemas, including
> principles for the definition of features. Its scope includes the following:
> * conceptual modelling of features and their properties from a universe of
> discourse;
> * definition of application schemas;
> * use of the conceptual schema language for application schemas;
> * transition from the concepts in the conceptual model to the data types in
> the application schema;
> * integration of standardized schemas from other ISO geographic information
> standards with the application schema.
> {quote}
> The {{Feature}} interfaces will be of critical importance to {{DataStore}}
> uses. Note that in its simplest form {{Feature}} has many conceptual common
> points with {{Record}} (SIS-127), even if the API is quite different.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (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 updated SIS-331:
Description:
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}}.
was:
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
> 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
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Fix For: 0.8
>
>
> 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
(v6.3.15#6346)
[jira] [Created] (SIS-359) Support coordinate transformations between CRS having duplicated axis orientations
Martin Desruisseaux created SIS-359:
---
Summary: 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.7, 0.6
Reporter: Martin Desruisseaux
Assignee: Martin Desruisseaux
Priority: Minor
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
(v6.3.15#6346)
[jira] [Updated] (SIS-171) Upgrade NetCDF to ISO-19115 mapping
[ https://issues.apache.org/jira/browse/SIS-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux updated SIS-171: Description: The mapping from NetCDF attributes to the ISO-19115 metadata is defined at this page: * [NetCDF Attribute Convention for Dataset Discovery|http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery] * [NetCDF, HDF, and ISO Metadata|http://wiki.esipfed.org/index.php/NetCDF,_HDF,_and_ISO_Metadata] * [NcISO|https://geo-ide.noaa.gov/wiki/index.php?title=NcISO] (is XSLT files for the mapping from NetCDF metadata to ISO 19115-2) The mapping implemented since SIS 0.3 is the version 1.0 of above convention. Available versions as of May 2017 is 1.3. We will need to upgrade the mapping implemented by SIS to the latest version. was: The mapping from NetCDF attributes to the ISO-19115 metadata is defined at this page: * [NetCDF Attribute Convention for Dataset Discovery|http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery] * [NetCDF, HDF, and ISO Metadata|http://wiki.esipfed.org/index.php/NetCDF,_HDF,_and_ISO_Metadata] The mapping implemented since SIS 0.3 is the version 1.0 of above convention. Available versions as of May 2017 is 1.3. We will need to upgrade the mapping implemented by SIS to the latest version. > Upgrade NetCDF to ISO-19115 mapping > --- > > Key: SIS-171 > URL: https://issues.apache.org/jira/browse/SIS-171 > Project: Spatial Information Systems > Issue Type: Task > Components: Metadata, Storage >Affects Versions: 0.3, 0.4, 0.5, 0.6, 0.7 >Reporter: Martin Desruisseaux >Priority: Minor > Labels: NetCDF > Fix For: 0.8 > > > The mapping from NetCDF attributes to the ISO-19115 metadata is defined at > this page: > * [NetCDF Attribute Convention for Dataset > Discovery|http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery] > * [NetCDF, HDF, and ISO > Metadata|http://wiki.esipfed.org/index.php/NetCDF,_HDF,_and_ISO_Metadata] > * [NcISO|https://geo-ide.noaa.gov/wiki/index.php?title=NcISO] (is XSLT files > for the mapping from NetCDF metadata to ISO 19115-2) > The mapping implemented since SIS 0.3 is the version 1.0 of above convention. > Available versions as of May 2017 is 1.3. We will need to upgrade the mapping > implemented by SIS to the latest version. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (SIS-171) Upgrade NetCDF to ISO-19115 mapping
[ https://issues.apache.org/jira/browse/SIS-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux updated SIS-171: Description: The mapping from NetCDF attributes to the ISO-19115 metadata is defined at this page: * [NetCDF Attribute Convention for Dataset Discovery|http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery] * [NetCDF, HDF, and ISO Metadata|http://wiki.esipfed.org/index.php/NetCDF,_HDF,_and_ISO_Metadata] The mapping implemented since SIS 0.3 is the version 1.0 of above convention. Available versions as of May 2017 is 1.3. We will need to upgrade the mapping implemented by SIS to the latest version. was: The mapping from NetCDF attributes to the ISO-19115 metadata is defined at this page: * [NetCDF Attribute Convention for Dataset Discovery|http://wiki.esipfed.org/index.php/Category:Attribute_Conventions_Dataset_Discovery] The mapping implemented in SIS 0.3 and 0.4 is the version 1.0 of above convention. Available versions at the time of writing is 1.1 and 1.2 beta. We will need to upgrade the mapping implemented by SIS to the latest version. > Upgrade NetCDF to ISO-19115 mapping > --- > > Key: SIS-171 > URL: https://issues.apache.org/jira/browse/SIS-171 > Project: Spatial Information Systems > Issue Type: Task > Components: Metadata, Storage >Affects Versions: 0.3, 0.4, 0.5, 0.6, 0.7 >Reporter: Martin Desruisseaux >Priority: Minor > Labels: NetCDF > Fix For: 0.8 > > > The mapping from NetCDF attributes to the ISO-19115 metadata is defined at > this page: > * [NetCDF Attribute Convention for Dataset > Discovery|http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery] > * [NetCDF, HDF, and ISO > Metadata|http://wiki.esipfed.org/index.php/NetCDF,_HDF,_and_ISO_Metadata] > The mapping implemented since SIS 0.3 is the version 1.0 of above convention. > Available versions as of May 2017 is 1.3. We will need to upgrade the mapping > implemented by SIS to the latest version. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (SIS-358) Leverage index inheritance when PostgreSQL will support this feature
[
https://issues.apache.org/jira/browse/SIS-358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-358:
Labels: SQL (was: )
> Leverage index inheritance when PostgreSQL will support this feature
>
>
> Key: SIS-358
> URL: https://issues.apache.org/jira/browse/SIS-358
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Metadata
>Affects Versions: 0.8
> Environment: PostgreSQL 9.6.
>Reporter: Martin Desruisseaux
>Priority: Minor
> Labels: SQL
>
> The {{org.apache.sis.metadata.sql}} package takes advantage of table
> inheritance as documented there:
> http://www.postgresql.org/docs/9.6/static/ddl-inherit.html
> However as of version 9.6, PostgreSQL does not support index inheritance.
> This limitation is documented in the "Caveats" section at the bottom of the
> above-cited page. The consequence is that {{org.apache.sis.metadata.sql}} can
> not enforce foreigner key constraints on columns that reference a parent
> table.
> If PostgreSQL supports index inheritance in a future version, then the
> {{Dialect.isIndexInheritanceSupported}} constant should be set to {{true}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (SIS-358) Leverage index inheritance when PostgreSQL will support this feature
Martin Desruisseaux created SIS-358:
---
Summary: Leverage index inheritance when PostgreSQL will support
this feature
Key: SIS-358
URL: https://issues.apache.org/jira/browse/SIS-358
Project: Spatial Information Systems
Issue Type: Improvement
Components: Metadata
Affects Versions: 0.8
Environment: PostgreSQL 9.6.
Reporter: Martin Desruisseaux
Priority: Minor
The {{org.apache.sis.metadata.sql}} package takes advantage of table
inheritance as documented there:
http://www.postgresql.org/docs/9.6/static/ddl-inherit.html
However as of version 9.6, PostgreSQL does not support index inheritance. This
limitation is documented in the "Caveats" section at the bottom of the
above-cited page. The consequence is that {{org.apache.sis.metadata.sql}} can
not enforce foreigner key constraints on columns that reference a parent table.
If PostgreSQL supports index inheritance in a future version, then the
{{Dialect.isIndexInheritanceSupported}} constant should be set to {{true}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (SIS-357) EPSG factory should be able to create geocentric CRS as derived CRS
Martin Desruisseaux created SIS-357:
---
Summary: 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
Reporter: Martin Desruisseaux
Assignee: Martin Desruisseaux
Priority: Minor
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
(v6.3.15#6346)
[jira] [Resolved] (SIS-298) Simplification in MetadataTreeFormat output
[
https://issues.apache.org/jira/browse/SIS-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux resolved SIS-298.
-
Resolution: Fixed
> Simplification in MetadataTreeFormat output
> ---
>
> Key: SIS-298
> URL: https://issues.apache.org/jira/browse/SIS-298
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Metadata
>Affects Versions: 0.3, 0.4, 0.5, 0.6, 0.7
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Minor
> Fix For: 0.8
>
>
> We could simplify and clarify a little bit the tree produced by the
> {{MetadataTreeFormat}} by using two additional rules:
> h3. Use less lines in simple case
> If a property has the same name than the parent property that contains it, we
> could write its value in that parent property. For example instead of:
> {noformat}
> Citation
> └─Date
> ├─Date 2012/01/01
> └─Date type …… Creation
> {noformat}
> We could simplify as:
> {noformat}
> Citation
> └─Date……… 2012/01/01
> └─Date type …… Creation
> {noformat}
> h3. Tell the sub-type
> If a property has the same name than the value type, and if that value type
> has sub-type, we could format the actual value sub-type in the tree. For
> example {{Citation}} as a property named {{party}} of type {{Party}}
> (ignoring multi-occurrences). But {{Party}} has two sub-types: {{Individual}}
> and {{Organisation}}. So instead of:
> {noformat}
> Citation
> └─Cited responsible party
> └─Party
>└─Name Jon Smith
> {noformat}
> It would be helpful to format:
> {noformat}
> Citation
> └─Cited responsible party
> └─Individual
>└─Name Jon Smith
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (SIS-298) Simplification in MetadataTreeFormat output
[
https://issues.apache.org/jira/browse/SIS-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux reassigned SIS-298:
---
Assignee: Martin Desruisseaux
> Simplification in MetadataTreeFormat output
> ---
>
> Key: SIS-298
> URL: https://issues.apache.org/jira/browse/SIS-298
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Metadata
>Affects Versions: 0.3, 0.4, 0.5, 0.6, 0.7
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Minor
> Fix For: 0.8
>
>
> We could simplify and clarify a little bit the tree produced by the
> {{MetadataTreeFormat}} by using two additional rules:
> h3. Use less lines in simple case
> If a property has the same name than the parent property that contains it, we
> could write its value in that parent property. For example instead of:
> {noformat}
> Citation
> └─Date
> ├─Date 2012/01/01
> └─Date type …… Creation
> {noformat}
> We could simplify as:
> {noformat}
> Citation
> └─Date……… 2012/01/01
> └─Date type …… Creation
> {noformat}
> h3. Tell the sub-type
> If a property has the same name than the value type, and if that value type
> has sub-type, we could format the actual value sub-type in the tree. For
> example {{Citation}} as a property named {{party}} of type {{Party}}
> (ignoring multi-occurrences). But {{Party}} has two sub-types: {{Individual}}
> and {{Organisation}}. So instead of:
> {noformat}
> Citation
> └─Cited responsible party
> └─Party
>└─Name Jon Smith
> {noformat}
> It would be helpful to format:
> {noformat}
> Citation
> └─Cited responsible party
> └─Individual
>└─Name Jon Smith
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (SIS-172) Replace boolean argument in AbstractEnvelope.contains and intersects
[
https://issues.apache.org/jira/browse/SIS-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-172.
---
Resolution: Won't Fix
Storing the inclusion/exclusion state for each border separately is not very
practical when the envelope is the result of a map projection. Instead, we
document {{intersects(Envelope, boolean)}} in terms of more classical
{{intersects}} and {{touches}} operation.
We have to change the behavior of {{intersects(Envelope)}} for making it
conform to the usual definition of {{intersects}}, i.e. does not include the
cases where the envelopes only touch each-other.
> Replace boolean argument in AbstractEnvelope.contains and intersects
>
>
> Key: SIS-172
> URL: https://issues.apache.org/jira/browse/SIS-172
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Referencing
>Affects Versions: 0.3, 0.4, 0.5, 0.6, 0.7
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Minor
> Fix For: 0.8
>
>
> The {{AbstractEnvelope}} class provides the following methods:
> * {{boolean contains(Envelope envelope, boolean edgesInclusive)}}
> * {{boolean intersects(Envelope envelope, boolean edgesInclusive)}}
> We may replace the {{boolean}} argument by something more generic.
> h3. First alternative: enumeration
> We could replace the {{boolean}} argument by something like the following
> enumeration:
> {code:java}
> public enum EdgeInclusion {
> /**
> * All edges are inclusive. This is the default policy for Envelope.
> */
> ALL,
> /**
> * All edges are exclusive.
> */
> NONE,
> /**
> * Edges defined by the lower corner are inclusive, while edges defined
> by the upper corner are exclusive.
> * This is the usual policy in Java2D.
> */
> LOWER,
> /**
> * Edges defined by the upper corner are inclusive, while edges defined
> by the lower corner are exclusive.
> * This policy is defined for completeness but rarely used.
> */
> UPPER
> }
> {code}
> The policy used in the majority of cases is the {{ALL}} one. Consequently we
> should provide convenience methods expecting only an {{Envelope}} argument
> and using that mode by default.
> h3. Second alternative: {{isLowerInclusive(int)}} and
> {{isUpperInclusive(int)}} methods.
> We could add a pair of methods telling whether the lower and upper values are
> inclusive or exclusive for a given dimension. This would be more generic than
> the above-cited enumeration, and would also be closer to the
> {{org.apache.sis.measure.Range}} API. The inclusion/exclusion information
> would be part of the {{Envelope}} state instead than an argument provided to
> the {{contains}} and {{intersects}} methods. However we would need to revisit
> also the {{contains(DirectPosition)}} and {{add(Envelope)}} methods.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (SIS-296) Consider defining Angle as a subclass of java.lang.Number
[
https://issues.apache.org/jira/browse/SIS-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-296.
---
Resolution: Won't Fix
{{Angle}} extends {{Object}} since SIS 0.3; changing that would be a risk of
breaking existing code. Furthermore a search shows that extending {{Number}}
would save only one {{instanceof}} check in the whole SIS 0.8 code base. The
cost would be to "pollute" {{Angle}} API with new methods like
{{doubleValue()}}, {{intValue()}}, _etc._ where the unit (degrees or radians)
is not obvious from the method signature. The units could still be specified in
the javadoc, but developers seeing the angle only as a {{Number}} would not see
that unit of measurement.
> Consider defining Angle as a subclass of java.lang.Number
> -
>
> Key: SIS-296
> URL: https://issues.apache.org/jira/browse/SIS-296
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Utilities
>Affects Versions: 0.6, 0.7
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Minor
> Fix For: 0.8
>
> Attachments: Angle.patch
>
>
> {{org.apache.sis.measure.Angle}} was intentionally defined as *not* extending
> {{java.lang.Number}}. In a previous library this was causing confusion. But a
> few tests suggest that this is not causing confusion anymore with Apache SIS
> design. Considering {{Angle}} as a kind of {{Number}} may help to reduce the
> amount of {{instanceof}} checks in code that are only interested in the
> numerical value.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (SIS-333) In GML, the second defining parameter of spheres should be true
[
https://issues.apache.org/jira/browse/SIS-333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-333.
---
> In GML, the second defining parameter of spheres should be
> true
>
>
> Key: SIS-333
> URL: https://issues.apache.org/jira/browse/SIS-333
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Referencing
>Affects Versions: 0.4, 0.5, 0.6, 0.7
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Minor
> Fix For: 0.8
>
>
> Currently, Apache SIS marshals the XML representation of the EPSG:7048
> ellipsoid (_"GRS 1980 Authalic Sphere"_) as below (extract):
> {code:xml}
> uom="urn:ogc:def:uom:EPSG::9001">6371007
>
>
> uom="urn:ogc:def:uom:EPSG::9001">6371007
>
>
> {code}
> This is not wrong, but the GML way would rather be:
> {code:xml}
> uom="urn:ogc:def:uom:EPSG::9001">6371007
>
>
> true
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (SIS-349) Dead-lock between ContextualParameters and WeakHashSet
[
https://issues.apache.org/jira/browse/SIS-349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-349.
---
> Dead-lock between ContextualParameters and WeakHashSet
> --
>
> Key: SIS-349
> URL: https://issues.apache.org/jira/browse/SIS-349
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Referencing
>Affects Versions: 0.6, 0.7
>Reporter: Johann Sorel
>Assignee: Martin Desruisseaux
> Fix For: 0.8
>
>
> Below are thread-dump of relevant parts. The first parts is in the thread
> that verifies if an existing map projection exists in the {{WeakHashSet}}.
> This verification implies {{NormalizedProjection}} comparisons, which
> themselves imply {{ContextualParameters}} comparisons:
> {noformat}
> "Thread-3407" #3588 daemon prio=5 os_prio=0 tid=0x7f7951adf000 nid=0x5836
> waiting for monitor entry [0x7f78744ef000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at
> org.apache.sis.referencing.operation.transform.ContextualParameters.equals(ContextualParameters.java:720)
> - waiting to lock <0x0007818ef028> (a
> org.apache.sis.referencing.operation.transform.ContextualParameters)
> at java.util.Arrays.deepEquals0(Arrays.java:4299)
> at java.util.Objects.deepEquals(Objects.java:85)
> at org.apache.sis.util.Utilities.deepEquals(Utilities.java:200)
> at
> org.apache.sis.referencing.operation.transform.AbstractMathTransform.equals(AbstractMathTransform.java:921)
> at
> org.apache.sis.referencing.operation.projection.NormalizedProjection.equals(NormalizedProjection.java:797)
> at org.apache.sis.util.Utilities.deepEquals(Utilities.java:143)
> at org.apache.sis.util.Utilities.equals(Utilities.java:238)
> at org.apache.sis.util.Utilities.deepEquals(Utilities.java:168)
> at
> org.apache.sis.referencing.operation.transform.ConcatenatedTransform.equals(ConcatenatedTransform.java:934)
> at
> org.apache.sis.referencing.operation.transform.AbstractMathTransform.equals(AbstractMathTransform.java:867)
> at org.apache.sis.util.collection.WeakHashSet.intern(WeakHashSet.java:315)
> at org.apache.sis.util.collection.WeakHashSet.unique(WeakHashSet.java:290)
> - locked <0x000704b65b40> (a
> org.apache.sis.util.collection.WeakHashSet)
> at
> org.apache.sis.referencing.operation.transform.DefaultMathTransformFactory.unique(DefaultMathTransformFactory.java:1372)
> {noformat}
> The second part is in the thread that creates a new map projection, which
> implies operations on {{ContextualParameters}}.
> {noformat}
> "Thread-3409" #3590 daemon prio=5 os_prio=0 tid=0x7f7824cfd000 nid=0x5838
> waiting for monitor entry [0x7f7819e6e000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at org.apache.sis.util.collection.WeakHashSet.unique(WeakHashSet.java:290)
> - waiting to lock <0x000704b65b40> (a
> org.apache.sis.util.collection.WeakHashSet)
> at
> org.apache.sis.referencing.operation.transform.DefaultMathTransformFactory.unique(DefaultMathTransformFactory.java:1372)
> at
> org.apache.sis.referencing.operation.transform.DefaultMathTransformFactory.createConcatenatedTransform(DefaultMathTransformFactory.java:1256)
> at
> org.apache.sis.referencing.operation.transform.ContextualParameters.completeTransform(ContextualParameters.java:522)
> - locked <0x0007818ef028> (a
> org.apache.sis.referencing.operation.transform.ContextualParameters)
> at
> org.apache.sis.referencing.operation.projection.TransverseMercator.createMapProjection(TransverseMercator.java:301)
> at
> org.apache.sis.internal.referencing.provider.MapProjection.createMathTransform(MapProjection.java:199)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (SIS-329) Transformation of envelope from UTM to WGS84 sometime wrongly expanded to the ±180° longitude range
[
https://issues.apache.org/jira/browse/SIS-329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-329.
---
> Transformation of envelope from UTM to WGS84 sometime wrongly expanded to the
> ±180° longitude range
> ---
>
> Key: SIS-329
> URL: https://issues.apache.org/jira/browse/SIS-329
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Referencing
>Affects Versions: 0.7
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Fix For: 0.8
>
>
> Consider the following envelope in UTM 30N (EPSG code 32630). Note that the
> longitude range crosses the limit of the CRS domain of validity, which is -6°
> to 0°:
> {noformat}
> BOX(199980 4490220, 309780 4600020)
> {noformat}
> Transformation to WGS84 (EPSG code 4326) should give something close to:
> {noformat}
> BOX(-6.5941 40.5085, -5.2462 41.5292)
> {noformat}
> but we get:
> {noformat}
> BOX(-180 40.5085, +180 41.5292)
> {noformat}
> The longitude range (-6.6° to -5.2°) has been expanded to ±180°. This is
> because the {{Envelopes.transform(…)}} method verifies if the given envelope
> contains a "singularity" (typically a pole), and the ±180° longitude are
> wrongly identified as contained singularities in this particular case.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (SIS-232) Albers Equal Area (EPSG:9822)
[ https://issues.apache.org/jira/browse/SIS-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux closed SIS-232. --- > Albers Equal Area (EPSG:9822) > - > > Key: SIS-232 > URL: https://issues.apache.org/jira/browse/SIS-232 > Project: Spatial Information Systems > Issue Type: Sub-task > Components: Referencing >Reporter: Martin Desruisseaux >Assignee: Martin Desruisseaux > Fix For: 0.8 > > > We may be able to port this projection from Geotk, after IP review and > eventually rewriting some equations. The formulas are given by §1.3.13 in > IOGP Publication 373-7-2 – Geomatics Guidance Note number 7, part 2 – April > 2015. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (SIS-335) CRS.findOperation(…) sometime slow
[
https://issues.apache.org/jira/browse/SIS-335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-335.
---
> CRS.findOperation(…) sometime slow
> --
>
> Key: SIS-335
> URL: https://issues.apache.org/jira/browse/SIS-335
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Referencing
>Affects Versions: 0.7
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Fix For: 0.8
>
>
> Execution of {{CRS.findOperation(sourceCRS, targetCRS, areaOfInterest)}} is
> slow when:
> * A connection to the EPSG geodetic dataset is available (which is
> recommended)
> * the given CRS have no EPSG identifiers, or their identifiers are wrong
> In such case, {{IdentifiedObjectFinder}} search the right EPSG code for the
> given CRS by scanning the EPSG database. Some conditions are put in the SQL
> {{WHERE}} clause for reducing the amount of CRS to scan, but in Apache SIS
> 0.7 those conditions are not restrictive enough, resulting in way too many
> CRS being scanned.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Reopened] (SIS-155) Area calculation on ellipsoid
[
https://issues.apache.org/jira/browse/SIS-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux reopened SIS-155:
-
> Area calculation on ellipsoid
> -
>
> Key: SIS-155
> URL: https://issues.apache.org/jira/browse/SIS-155
> Project: Spatial Information Systems
> Issue Type: New Feature
> Components: Referencing
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>
> We need a method for calculating the area inside a polygon on the ellipsoid.
> Some useful references:
> * [Algorithm to find the area of a
> polygon|http://www.mathopenref.com/coordpolygonarea2.html] in Cartesian
> coordinate system.
> * [Ellipsoidal area computations of large terrestrial
> objects|http://www.geodyssey.com/papers/ggelare.html]
> * [Some algorithms for polygons on a
> sphere|http://trs-new.jpl.nasa.gov/dspace/bitstream/2014/40409/3/JPL%20Pub%2007-3%20%20w%20Errata.pdf]
> * [Addenda for C. F. F. Karney, Algorithms for
> Geodesics|http://geographiclib.sourceforge.net/geod-addenda.html]
> This algorithm for Cartesian coordinate system can be adapted to spherical
> coordinate systems by replacing the area sum by (note that this replacement
> uses vertical strips instead than horizontal ones):
> {code:java}
> s += (λ2 - λ1) * (2 + sin(φ1) + sin(φ2));
> {code}
> and the final answer by:
> {code:java}
> area = abs(s * r² / 2);
> {code}
> The _r_ value could be approximated to the authalic radius (the radius of a
> hypothetical sphere having the same surface than the ellipsoid). However the
> _Ellipsoidal Area Computations of Large Terrestrial Objects_ article seems to
> use a more local approximation, where _a_ and _b_ are semi-major and
> semi-minor axis lengths:
> {code:java}
> s = sin(φ)
> c = cos(φ)
> r = (a²b) / (a²c² + b²s²)
> {code}
> This task is for writing down some ideas. We probably need to read the
> above-cited article and other internet resources more carefully. In
> particular we need some more analytical analysis for determining how [rhumb
> lines|http://en.wikipedia.org/wiki/Rhumb_line] are handled in the above-cited
> resources. This would affect polygon segments of more than 100 km.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (SIS-155) Area calculation on ellipsoid
[
https://issues.apache.org/jira/browse/SIS-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-155:
Fix Version/s: (was: 0.8)
> Area calculation on ellipsoid
> -
>
> Key: SIS-155
> URL: https://issues.apache.org/jira/browse/SIS-155
> Project: Spatial Information Systems
> Issue Type: New Feature
> Components: Referencing
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>
> We need a method for calculating the area inside a polygon on the ellipsoid.
> Some useful references:
> * [Algorithm to find the area of a
> polygon|http://www.mathopenref.com/coordpolygonarea2.html] in Cartesian
> coordinate system.
> * [Ellipsoidal area computations of large terrestrial
> objects|http://www.geodyssey.com/papers/ggelare.html]
> * [Some algorithms for polygons on a
> sphere|http://trs-new.jpl.nasa.gov/dspace/bitstream/2014/40409/3/JPL%20Pub%2007-3%20%20w%20Errata.pdf]
> * [Addenda for C. F. F. Karney, Algorithms for
> Geodesics|http://geographiclib.sourceforge.net/geod-addenda.html]
> This algorithm for Cartesian coordinate system can be adapted to spherical
> coordinate systems by replacing the area sum by (note that this replacement
> uses vertical strips instead than horizontal ones):
> {code:java}
> s += (λ2 - λ1) * (2 + sin(φ1) + sin(φ2));
> {code}
> and the final answer by:
> {code:java}
> area = abs(s * r² / 2);
> {code}
> The _r_ value could be approximated to the authalic radius (the radius of a
> hypothetical sphere having the same surface than the ellipsoid). However the
> _Ellipsoidal Area Computations of Large Terrestrial Objects_ article seems to
> use a more local approximation, where _a_ and _b_ are semi-major and
> semi-minor axis lengths:
> {code:java}
> s = sin(φ)
> c = cos(φ)
> r = (a²b) / (a²c² + b²s²)
> {code}
> This task is for writing down some ideas. We probably need to read the
> above-cited article and other internet resources more carefully. In
> particular we need some more analytical analysis for determining how [rhumb
> lines|http://en.wikipedia.org/wiki/Rhumb_line] are handled in the above-cited
> resources. This would affect polygon segments of more than 100 km.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (SIS-327) Defer loading of datum shift grid files
[
https://issues.apache.org/jira/browse/SIS-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux resolved SIS-327.
-
Resolution: Fixed
> Defer loading of datum shift grid files
> ---
>
> Key: SIS-327
> URL: https://issues.apache.org/jira/browse/SIS-327
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Referencing
>Affects Versions: 0.7
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Minor
> Fix For: 0.8
>
>
> When a {{CoordinateOperation}} is created, its {{MathTransform}} is created
> immediately. This is usually not so costly, except in the case of datum shift
> based on a grid files where the grid files is loaded immediately. This is a
> waste of resources when the caller needs create many such operations, compare
> their {{domainOfValidity}} and retain only one operation at the end.
> The proposal is to load the datum shift grid files only the first time that
> {{getMathTransform()}} is invoked. In addition to reduce the amount of
> resources to load, another effect of this would be to reduce the amount of
> warnings emitted because of grid files not present.
> *How to reproduce:* the snippet below produces a lot of warnings if the grid
> files are not present. After this issue is fixed, we should have at most 1
> warning.
> {code:java}
> CoordinateReferenceSystem sourceCRS = CRS.forCode("EPSG:4267");
> CoordinateReferenceSystem targetCRS = CRS.forCode("EPSG:4326");
> CoordinateOperation op = CRS.findOperation(sourceCRS, targetCRS, null);
> {code}
> *Note:* we could defer the creation of all {{MathTransform}} objects, but
> this is advantageous only for the cases where many operations exist between
> the same pair of CRS. This is the case of datum shift mostly.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (SIS-113) Support deep copy of metadata objects
[
https://issues.apache.org/jira/browse/SIS-113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux resolved SIS-113.
-
Resolution: Fixed
Implemented as {{org.apache.sis.metadata.MetadataCopier}}.
> Support deep copy of metadata objects
> -
>
> Key: SIS-113
> URL: https://issues.apache.org/jira/browse/SIS-113
> Project: Spatial Information Systems
> Issue Type: New Feature
> Components: Metadata
>Affects Versions: 0.3
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>
> Current metadata implementations provide constructors performing shallow copy
> of metadata objects. We also need a method providing a deep copy. It shall
> not be a constructor (using reflection in constructors is unsafe).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (SIS-352) Support spatial referencing by geographic identifiers (ISO 19112)
[
https://issues.apache.org/jira/browse/SIS-352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux resolved SIS-352.
-
Resolution: Fixed
> Support spatial referencing by geographic identifiers (ISO 19112)
> -
>
> Key: SIS-352
> URL: https://issues.apache.org/jira/browse/SIS-352
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Referencing
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Fix For: 0.8
>
>
> Provide a basic support of [ISO 19112:2003 — Spatial referencing by
> geographic
> identifiers|http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=26017].
> Geographic identifiers are location descriptors such as addresses and grid
> indexes. ISO 19112 describes (among other things) how to map geographic
> identifiers to spatial coordinates. Some keys classes defined by ISO 19112
> are listed below (Apache SIS would not necessarily use exactly the same
> names):
> * {{SpatialReferenceSystemUsingGeographicIdentifier}}
> * {{Gazetteer}}
> * {{LocationType}}
> * {{LocationInstance}}
> The {{Gazetteer}} seems the most interesting part for us, since it is the
> class in charge of converting a geographic identifier to something else
> (_e.g._ a geographic coordinate). It seems that {{Gazetteer}} could be
> compared to the {{MathTransform}} interface that we already implement in the
> following package:
> * {{org.apache.sis.referencing.operation}}
> but working on geographic identifiers instead than coordinates. For this
> reason, I propose to put an ISO 19112 implementation in the following package:
> * {{org.apache.sis.referencing.gazetteer}}
> I have hesitation about whether such package should be in a separated module
> (e.g. {{"sis-referencing-by-identifier"}}) or not, but given that I expect
> the amount of classes to be small I'm not sure it is worth creating a new
> module.
> An implementation of [Military Grid Reference System
> (MGRS)|https://en.wikipedia.org/wiki/Military_Grid_Reference_System] is used
> for experimenting what the API may looks like. Despite its name, MGRS is not
> used only for military purpose. It is used also as a way to organize Earth
> Observation data on Amazon S3 cloud storage.
> Note that Apache SIS already have (since the 0.1 version!) a class that seems
> in the scope of ISO 19112:
> [GeoHashCoder|http://sis.apache.org/apidocs/org/apache/sis/index/GeoHashCoder.html].
> As part of an ISO 19112 support, we could also refactor {{GeoHashCoder}} as
> another implementation, side-by-side with {{MilitaryGridReferenceSystem}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SIS-344) Update EPSG geodetic dataset to version 9.0
[
https://issues.apache.org/jira/browse/SIS-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15961095#comment-15961095
]
Martin Desruisseaux commented on SIS-344:
-
We will need to revisit SIS-284 (even if marked resolved) after this EPSG
dataset upgrade.
> Update EPSG geodetic dataset to version 9.0
> ---
>
> Key: SIS-344
> URL: https://issues.apache.org/jira/browse/SIS-344
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Referencing
>Affects Versions: 0.7
>Reporter: Martin Desruisseaux
> Fix For: 0.8
>
>
> EPSG geodetic dataset version 9.0 has been released on December 15, 2016. We
> need to upgrade the {{org.apache.sis.non-free:sis-epsg}} Maven artifact
> accordingly. Note that this version introduce 6 news definitions of WGS 84
> geographic CRS.
> This update included the following changes in the EPSG schema:
> * Data declaration for the {{datum.realization_epoch}} attribute has been
> changed from {{char(4)}} to {{char(10)}} to allow dates to be given to day
> resolution.
> * The length of abbreviations has been changed to a nominal maximum of 32
> characters.
> The {{Tables.sql}} file provided in SIS will need to be updated accordingly.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SIS-284) Geographic2D with Height Offsets (EPSG:9618)
[
https://issues.apache.org/jira/browse/SIS-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15961091#comment-15961091
]
Martin Desruisseaux commented on SIS-284:
-
Before to close this task, we need to verify that we can decode all the
following coordinate operations:
{code:java}
public class Test {
public static void main(String[] args) throws Exception {
CoordinateOperationAuthorityFactory factory =
(CoordinateOperationAuthorityFactory) CRS.getAuthorityFactory("EPSG");
System.out.println(factory.createCoordinateOperation("15596")); //
3D to 3D
System.out.println(factory.createCoordinateOperation("1336")); //
3D to 2D
System.out.println(factory.createCoordinateOperation("1335")); //
2D to 2D
}
}
{code}
With EPSG geodetic data set 8.9, the first coordinate operation succeed but the
next two fails, because the operation method is declared with a {{null}}
(meaning arbitrary) source number of dimensions, which is okay, but a target
number of dimensions fixed to 3. If the situation is the same in EPSG geodetic
dataset 9.0, we may need to force the target dimension to null.
> Geographic2D with Height Offsets (EPSG:9618)
>
>
> Key: SIS-284
> URL: https://issues.apache.org/jira/browse/SIS-284
> Project: Spatial Information Systems
> Issue Type: Sub-task
> Components: Referencing
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Minor
> Fix For: 0.8
>
>
> Simplified form of _"Geographic3D to Geographic2D + gravity-related height"_
> transformation used in Japan.
> See §2.4.5.3 in IOGP Publication 373-7-2 – Geomatics Guidance Note number 7,
> part 2 – April 2015.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (SIS-284) Geographic2D with Height Offsets (EPSG:9618)
[ https://issues.apache.org/jira/browse/SIS-284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux resolved SIS-284. - Resolution: Fixed > Geographic2D with Height Offsets (EPSG:9618) > > > Key: SIS-284 > URL: https://issues.apache.org/jira/browse/SIS-284 > Project: Spatial Information Systems > Issue Type: Sub-task > Components: Referencing >Reporter: Martin Desruisseaux >Assignee: Martin Desruisseaux >Priority: Minor > Fix For: 0.8 > > > Simplified form of _"Geographic3D to Geographic2D + gravity-related height"_ > transformation used in Japan. > See §2.4.5.3 in IOGP Publication 373-7-2 – Geomatics Guidance Note number 7, > part 2 – April 2015. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (SIS-343) Axis order reversal (EPSG:9843)
[ https://issues.apache.org/jira/browse/SIS-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux resolved SIS-343. - Resolution: Fixed > Axis order reversal (EPSG:9843) > --- > > Key: SIS-343 > URL: https://issues.apache.org/jira/browse/SIS-343 > Project: Spatial Information Systems > Issue Type: Sub-task > Components: Referencing >Affects Versions: 0.7 >Reporter: Martin Desruisseaux >Assignee: Martin Desruisseaux >Priority: Minor > Fix For: 0.8 > > > This trivial coordinate operation method is not listed in the EPSG guidance > note, but nevertheless appear in EPSG geodetic dataset. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (SIS-356) NetCDF reader should recognize Earth Observation metadata
Martin Desruisseaux created SIS-356:
---
Summary: NetCDF reader should recognize Earth Observation metadata
Key: SIS-356
URL: https://issues.apache.org/jira/browse/SIS-356
Project: Spatial Information Systems
Issue Type: Task
Components: Storage
Affects Versions: 0.7
Reporter: Martin Desruisseaux
Priority: Minor
The European Space Agency (ESA) published an extension to CF-Convention for
Earth Observation (EO) Metadata. This extension would fit nicely in SIS by
completing the
[AttributeNames|http://sis.apache.org/apidocs/org/apache/sis/storage/netcdf/AttributeNames.html]
class, which defines the mapping from NetCDF attributes to ISO 19115 metadata.
The process would be:
* Get the [NetCDF Earth Observation (EO) Metadata
Conventions|https://wiki.services.eoportal.org/tiki-download_wiki_attachment.php?attId=3271=y]
document (version 1.1.0 published in 2014-03-11). Authors are from CNR -
Institute of Atmospheric Pollution Research.
* Inspect the NetCDF attributes listed in table and establish a relationship
with an equivalent ISO 19115 attribute when possible. Not all attributes have
equivalence; it is okay to leave attributes unmapped.
* For each mapped attribute, add a constant in Apache SIS {{AttributeNames}}
class.
* Edit the {{MetadataReader}} class for using those new constants.
* Add JUnit tests.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SIS-351) Create metadata, CRS and tabular data editors in JavaFX
[
https://issues.apache.org/jira/browse/SIS-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15950807#comment-15950807
]
Martin Desruisseaux commented on SIS-351:
-
Hello Siddhesh. The deadline for submitting a proposal is April 3th at 16:00
UTC, which is in about 75 hours. The {{sis-web-app}} module has not been
updated for years; I would suggest to not look at it for now. Instead, you may
try to run the [command-line
interface|http://sis.apache.org/command-line.html]. There is 4 examples, one of
them for ISO 19115 metadata. While the metadata example seems verbose, I think
it is actually less complex than the other examples.
> Create metadata, CRS and tabular data editors in JavaFX
> ---
>
> Key: SIS-351
> URL: https://issues.apache.org/jira/browse/SIS-351
> Project: Spatial Information Systems
> Issue Type: New Feature
> Components: GUI
>Reporter: Martin Desruisseaux
> Labels: gsoc2017, mentor
>
> Creates the foundation of a GUI application for Apache SIS based on JavaFX.
> This application should leverage the functionalities available in Apache SIS
> 0.8. In particular:
> * Read metadata from files in various formats (currently ISO 19139, GeoTIFF,
> NetCDF, LANDSAT, GPX, Moving Features)
> * Get Coordinate Reference System from a registry or from GML or WKT
> definitions and apply coordinate transformations.
> * Show vector data in a tabular format.
> Since SIS does not yet have a renderer engine, we can not yet show maps in
> the application. However the application should be designed with this goal in
> mind.
> This project should create a metadata editor showing the ISO 19115 metadata.
> We should provide a simplified view with only the essential information, and
> an advanced view showing all information. The information to shown should be
> customizable. The user should be able to edit the metadata and save them in
> ISO 19139 format.
> The project should also create the necessary widgets for showing a Coordinate
> Reference System (CRS) definition and allow the user to edit it. Another
> widget should use the CRS definitions for applying coordinate operations (map
> projections) using the existing Apache SIS referencing engine, and show the
> result in a table with information about accuracy and domain of validity.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SIS-351) Create metadata, CRS and tabular data editors in JavaFX
[ https://issues.apache.org/jira/browse/SIS-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15950569#comment-15950569 ] Martin Desruisseaux commented on SIS-351: - Hello Pavel and Siddhesh. If you are still interested in this project, would you like to show a proposal draft so we can comment on it (if you want) before the deadline? > Create metadata, CRS and tabular data editors in JavaFX > --- > > Key: SIS-351 > URL: https://issues.apache.org/jira/browse/SIS-351 > Project: Spatial Information Systems > Issue Type: New Feature > Components: GUI >Reporter: Martin Desruisseaux > Labels: gsoc2017, mentor > > Creates the foundation of a GUI application for Apache SIS based on JavaFX. > This application should leverage the functionalities available in Apache SIS > 0.8. In particular: > * Read metadata from files in various formats (currently ISO 19139, GeoTIFF, > NetCDF, LANDSAT, GPX, Moving Features) > * Get Coordinate Reference System from a registry or from GML or WKT > definitions and apply coordinate transformations. > * Show vector data in a tabular format. > Since SIS does not yet have a renderer engine, we can not yet show maps in > the application. However the application should be designed with this goal in > mind. > This project should create a metadata editor showing the ISO 19115 metadata. > We should provide a simplified view with only the essential information, and > an advanced view showing all information. The information to shown should be > customizable. The user should be able to edit the metadata and save them in > ISO 19139 format. > The project should also create the necessary widgets for showing a Coordinate > Reference System (CRS) definition and allow the user to edit it. Another > widget should use the CRS definitions for applying coordinate operations (map > projections) using the existing Apache SIS referencing engine, and show the > result in a table with information about accuracy and domain of validity. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SIS-350) Port Apache SIS to Android
[
https://issues.apache.org/jira/browse/SIS-350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15950567#comment-15950567
]
Martin Desruisseaux commented on SIS-350:
-
Hello Weilun, Aditya, Sisinda, Buddhi and Dulaj. Thank Sisinda for your
proposal draft. For other people, if you are still interested in this project,
would you like to show a draft of your proposal before the deadline, so we can
comment on it if you want?
> Port Apache SIS to Android
> --
>
> Key: SIS-350
> URL: https://issues.apache.org/jira/browse/SIS-350
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Features, Metadata, Referencing, Storage, Utilities
>Reporter: Martin Desruisseaux
> Labels: gsoc2017, mentor
>
> Create an Apache SIS branch for Android. This will require the following work:
> * Simulate the JAXB framework if possible, or remove SIS usage of JAXB on the
> Android branch. JAXB is extensively used in the metadata modules, but some
> usages are found also in other modules.
> * Remove Java2D dependency. This work has already been anticipated by keeping
> Java2D dependency in separated classes or packages. When a replacement is
> available on the Android platform, the Java2D type should be substituted by
> the replacement. This should include in particular
> {{java.awt.geom.AffineTransform}}.
> * Get a JDBC implementation for SQLite. If needed, write code that adapt
> on-the-fly the SQL statements used for the creation of EPSG dataset to SQL
> statements compatible with SQLite.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (SIS-350) Port Apache SIS to Android
[
https://issues.apache.org/jira/browse/SIS-350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-350:
Description:
Create an Apache SIS branch for Android. This will require the following work:
* Simulate the JAXB framework if possible, or remove SIS usage of JAXB on the
Android branch. JAXB is extensively used in the metadata modules, but some
usages are found also in other modules.
* Remove Java2D dependency. This work has already been anticipated by keeping
Java2D dependency in separated classes or packages. When a replacement is
available on the Android platform, the Java2D type should be substituted by the
replacement. This should include in particular
{{java.awt.geom.AffineTransform}}.
* Get a JDBC implementation for SQLite. If needed, write code that adapt
on-the-fly the SQL statements used for the creation of EPSG dataset to SQL
statements compatible with SQLite.
was:
Create an Apache SIS branch for Android. This will require the following work:
* Simulate the JAXB framework if possible, or remove SIS usage of JAXB on the
Android branch. JAXB is extensively used in the metadata modules, but some
usages are found also in other modules.
* Remove Java2D dependency. This work has already been anticipated by keeping
Java2D dependency in separated classes or packages. When a replacement is
available on the Android platform, the Java2D type should be substituted by the
replacement. This should include in particular
{{java.awt.geom.AffineTransform}}.
> Port Apache SIS to Android
> --
>
> Key: SIS-350
> URL: https://issues.apache.org/jira/browse/SIS-350
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Features, Metadata, Referencing, Storage, Utilities
>Reporter: Martin Desruisseaux
> Labels: gsoc2017, mentor
>
> Create an Apache SIS branch for Android. This will require the following work:
> * Simulate the JAXB framework if possible, or remove SIS usage of JAXB on the
> Android branch. JAXB is extensively used in the metadata modules, but some
> usages are found also in other modules.
> * Remove Java2D dependency. This work has already been anticipated by keeping
> Java2D dependency in separated classes or packages. When a replacement is
> available on the Android platform, the Java2D type should be substituted by
> the replacement. This should include in particular
> {{java.awt.geom.AffineTransform}}.
> * Get a JDBC implementation for SQLite. If needed, write code that adapt
> on-the-fly the SQL statements used for the creation of EPSG dataset to SQL
> statements compatible with SQLite.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (SIS-354) Military Grid Reference System (MGRS)
[
https://issues.apache.org/jira/browse/SIS-354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux resolved SIS-354.
-
Resolution: Fixed
> Military Grid Reference System (MGRS)
> -
>
> Key: SIS-354
> URL: https://issues.apache.org/jira/browse/SIS-354
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Referencing
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Fix For: 0.8
>
>
> Support the [Military Grid Reference
> System|https://en.wikipedia.org/wiki/Military_Grid_Reference_System] (MGRS).
> The MGRS is the geocoordinate standard used by NATO militaries for locating
> points on the earth. It is based on the Universal Transverse Mercator (UTM)
> and the Universal Polar Stereographic (UPS) projections. Despite its name,
> MGRS is used not only for military purposes; it is used also for organizing
> Earth Observation data in directory trees for example.
> MGRS can be used as an alternative to {{GeoHashCoder}} already available
> since Apache SIS 0.1. A MGRS advantage is that it uses rectangular
> coordinates in metres instead than degrees, and that it provides a way to
> divide the Earth in grid cells of the same size (except those that are on the
> border between two zones).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SIS-212) Coordinate operation methods to implement
[
https://issues.apache.org/jira/browse/SIS-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15906376#comment-15906376
]
Martin Desruisseaux commented on SIS-212:
-
Hello Milinda, and welcome!
For participating to a GSoC, each projects have their own way but for SIS I
suggest the following:
* Take inspiration from a SIS task of your choice (SIS-212, SIS-351, SIS-350 or
other). You can also make your own proposal if you wish.
* Start drafting your proposal in the format of your choice (it may be
GoogleDoc, GitHub readme file, ASCII doc, an OpenOffice document, etc.). I
suggest to organize the proposal as described here:
http://write.flossmanuals.net/gsocstudentguide/writing-a-proposal/
* Share the link to your proposal, get feedback from potential mentor, modify
your proposal, _etc._ Many iterations may be necessary. You can ask questions
on the SIS developer mailing list.
* Once ready, submit the proposal to Google.
Before to start the project, it is important that the mentor can see from the
proposal that the student has a good idea of the technical steps required for
doing this task. I also recommend to submit more than one proposal since we do
not know in advance which projects will be accepted. Each student can submit up
to 5 proposals to different projects.
> Coordinate operation methods to implement
> -
>
> Key: SIS-212
> URL: https://issues.apache.org/jira/browse/SIS-212
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Referencing
>Affects Versions: 0.6, 0.7, 0.8
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Labels: gsoc2016, gsoc2017, java, mentor
> Fix For: 0.6, 0.7, 0.8
>
>
> This is an umbrella task for some coordinate operation methods not yet
> supported in Apache SIS. Coordinate operations include _map projections_
> (e.g. Transverse Mercator, Lambert Conic Conformal, _etc._), _datum shifts_
> (e.g. transformations from NAD27 to NAD83 in United States), transformation
> of vertical coordinates, _etc_. We can of course not list all possible
> formulas that we do not support, but this JIRA task lists at least some of
> the operations listed in the EPSG guidance notes.
> The main material for this work is the EPSG guidance notes, which can be
> downloaded freely from the following site:
> {panel}
> IOGP Publication 373-7-2 – Geomatics Guidance Note number 7, part 2
> Coordinate Conversions and Transformations including Formulas
> http://www.epsg.org/GuidanceNotes
> {panel}
> Google summer of code students interested in this work would need to be
> reasonably comfortable with the Java language (but not necessarily with the
> JDK library at large, since this work uses relatively few JDK classes outside
> {{Math}}), and in mathematic. In particular, this work requires a good
> understanding of _affine transforms_: their representation as a matrix, and
> how to map a term in a formula to a coefficient in the affine transform
> matrix.
> Apache SIS has one advanced feature which is not easily found in popular
> geospatial software or text books: the capability to compute the _derivative_
> (or more precisely, the _Jacobian_) of a transformation at a given point.
> Implementation of this feature requires the capability to find the analytic
> derivative of a non-linear formula and to simplify it.
> Implementations of those formulas take place in one of the
> {{org.apache.sis.referencing.operation}} sub-packages ({{projection}} or
> {{transform}}). Implementations of JUnit test happen partially in Apache SIS,
> and partially in the ["conformance module" of the GeoAPI
> project|http://www.geoapi.org/geoapi-conformance/index.html], if possible
> through the Geospatial Integrity of Geoscience Software (GIGS) tests.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SIS-351) Create metadata, CRS and tabular data editors in JavaFX
[ https://issues.apache.org/jira/browse/SIS-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15906372#comment-15906372 ] Martin Desruisseaux commented on SIS-351: - Hello Siddhesh, and welcome! No JavaFX work started as far as I know, so we are starting from scratch. SIS-43 did not provided much details about its scope; for a GSoC I think we need to be more specific. This SIS-351 task suggests to focus on metadata and referencing by coordinates because they are the most mature functionalities currently available in Apache SIS, but the student is of course free to make his/her own proposal. > Create metadata, CRS and tabular data editors in JavaFX > --- > > Key: SIS-351 > URL: https://issues.apache.org/jira/browse/SIS-351 > Project: Spatial Information Systems > Issue Type: New Feature > Components: GUI >Reporter: Martin Desruisseaux > Labels: gsoc2017, mentor > > Creates the foundation of a GUI application for Apache SIS based on JavaFX. > This application should leverage the functionalities available in Apache SIS > 0.8. In particular: > * Read metadata from files in various formats (currently ISO 19139, GeoTIFF, > NetCDF, LANDSAT, GPX, Moving Features) > * Get Coordinate Reference System from a registry or from GML or WKT > definitions and apply coordinate transformations. > * Show vector data in a tabular format. > Since SIS does not yet have a renderer engine, we can not yet show maps in > the application. However the application should be designed with this goal in > mind. > This project should create a metadata editor showing the ISO 19115 metadata. > We should provide a simplified view with only the essential information, and > an advanced view showing all information. The information to shown should be > customizable. The user should be able to edit the metadata and save them in > ISO 19139 format. > The project should also create the necessary widgets for showing a Coordinate > Reference System (CRS) definition and allow the user to edit it. Another > widget should use the CRS definitions for applying coordinate operations (map > projections) using the existing Apache SIS referencing engine, and show the > result in a table with information about accuracy and domain of validity. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SIS-351) Create metadata, CRS and tabular data editors in JavaFX
[ https://issues.apache.org/jira/browse/SIS-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15895948#comment-15895948 ] Martin Desruisseaux commented on SIS-351: - Hello Pavel Welcome! To communicate, you can at your choice comment on this JIRA task or register to the [SIS developer mailing list|http://sis.apache.org/mail-lists.html]. In this project proposal, the metadata part would probably be the easiest one. The Coordinate Reference System (CRS) part is more challenging, so it would probably be safer to put in only second or third. Martin > Create metadata, CRS and tabular data editors in JavaFX > --- > > Key: SIS-351 > URL: https://issues.apache.org/jira/browse/SIS-351 > Project: Spatial Information Systems > Issue Type: New Feature > Components: GUI >Reporter: Martin Desruisseaux > Labels: gsoc2017, mentor > > Creates the foundation of a GUI application for Apache SIS based on JavaFX. > This application should leverage the functionalities available in Apache SIS > 0.8. In particular: > * Read metadata from files in various formats (currently ISO 19139, GeoTIFF, > NetCDF, LANDSAT, GPX, Moving Features) > * Get Coordinate Reference System from a registry or from GML or WKT > definitions and apply coordinate transformations. > * Show vector data in a tabular format. > Since SIS does not yet have a renderer engine, we can not yet show maps in > the application. However the application should be designed with this goal in > mind. > This project should create a metadata editor showing the ISO 19115 metadata. > We should provide a simplified view with only the essential information, and > an advanced view showing all information. The information to shown should be > customizable. The user should be able to edit the metadata and save them in > ISO 19139 format. > The project should also create the necessary widgets for showing a Coordinate > Reference System (CRS) definition and allow the user to edit it. Another > widget should use the CRS definitions for applying coordinate operations (map > projections) using the existing Apache SIS referencing engine, and show the > result in a table with information about accuracy and domain of validity. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (SIS-43) GUI Client for SIS
[ https://issues.apache.org/jira/browse/SIS-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux resolved SIS-43. Resolution: Duplicate Closing as a duplicated of SIS-351. Actually this task is of wider scope since it is about a GUI in general, while SIS-351 is about GUI specifically for the metadata and referencing parts. But SIS does not yet (as of 2017) have enough functionalities for a more complete application showing maps. > GUI Client for SIS > -- > > Key: SIS-43 > URL: https://issues.apache.org/jira/browse/SIS-43 > Project: Spatial Information Systems > Issue Type: New Feature > Components: Command line, GUI, Web services >Reporter: Madusanka > Labels: gsoc2014 > Attachments: SIS-43.charitha.20120410.patch.txt, > SIS-43.roshan.2014.08.22.pach-1 > > > Implement a GUI client for SIS framework. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SIS-350) Port Apache SIS to Android
[
https://issues.apache.org/jira/browse/SIS-350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15893975#comment-15893975
]
Martin Desruisseaux commented on SIS-350:
-
{color:blue}Adapted from email thread: {color} For Google Summer of Code 2017
(GSoC), a next step would be to draft a proposal as described in the [student
guide|http://write.flossmanuals.net/gsocstudentguide/writing-a-proposal/].
Students can use any tools at their choice (GoogleDoc, Markdown in a Git
repository, OpenOffice, _etc._) and share the link either publicly on this
mailing list if you are fine with public review, or privately with the mentor
otherwise. We may need many cycles for improving the draft.
The proposal document should list the issues to resolve in this GSoC. Below are
some examples, but need student's review for evaluating if they are valid
issues, and if there is any other issues to resolve:
* Change the Maven project configuration for targeting Android.
* Either get JAXB support, or replace JAXB by something equivalent.
* Replace Java2D dependencies by equivalent classes from Android SDK.
* Port the EPSG dataset to the database engine supported by Android (SQLite).
* Provide a JDBC implementation sufficient for allowing SIS to use EPSG on
SQLite.
The proposal document should give more details for each issue and explain how
they could be solved. Note that Apache SIS does not yet have a graphical user
interface, so all above work is (for now) purely computational.
Finally, I strongly recommend that the student also submit other proposals for
different projects. Each GSoC student can submit up to 5 proposals. We always
receive much more proposals than the number of slots allocated by Google or the
number of mentors available, so putting all expectations on a single proposal
would be risky.
> Port Apache SIS to Android
> --
>
> Key: SIS-350
> URL: https://issues.apache.org/jira/browse/SIS-350
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Features, Metadata, Referencing, Storage, Utilities
>Reporter: Martin Desruisseaux
> Labels: gsoc2017, mentor
>
> Create an Apache SIS branch for Android. This will require the following work:
> * Simulate the JAXB framework if possible, or remove SIS usage of JAXB on the
> Android branch. JAXB is extensively used in the metadata modules, but some
> usages are found also in other modules.
> * Remove Java2D dependency. This work has already been anticipated by keeping
> Java2D dependency in separated classes or packages. When a replacement is
> available on the Android platform, the Java2D type should be substituted by
> the replacement. This should include in particular
> {{java.awt.geom.AffineTransform}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SIS-350) Port Apache SIS to Android
[
https://issues.apache.org/jira/browse/SIS-350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15893934#comment-15893934
]
Martin Desruisseaux commented on SIS-350:
-
Hello Weilun. I just saw that the list of accepted organizations [has been
published|https://summerofcode.withgoogle.com/organizations/], and Apache is on
the list. Sorry for my mistake in previous comment. So now is the time to
discuss about projects, until April 3th. Aditya already posted an email on the
mailing list; I will reply to [that
thread|https://lists.apache.org/thread.html/b6a85ae93d59294215b6ca413c869ea2fccafce348f8301b7116b631@%3Cdev.sis.apache.org%3E]
and post a summary on this JIRA task later.
> Port Apache SIS to Android
> --
>
> Key: SIS-350
> URL: https://issues.apache.org/jira/browse/SIS-350
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Features, Metadata, Referencing, Storage, Utilities
>Reporter: Martin Desruisseaux
> Labels: gsoc2017, mentor
>
> Create an Apache SIS branch for Android. This will require the following work:
> * Simulate the JAXB framework if possible, or remove SIS usage of JAXB on the
> Android branch. JAXB is extensively used in the metadata modules, but some
> usages are found also in other modules.
> * Remove Java2D dependency. This work has already been anticipated by keeping
> Java2D dependency in separated classes or packages. When a replacement is
> available on the Android platform, the Java2D type should be substituted by
> the replacement. This should include in particular
> {{java.awt.geom.AffineTransform}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SIS-350) Port Apache SIS to Android
[
https://issues.apache.org/jira/browse/SIS-350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15893043#comment-15893043
]
Martin Desruisseaux commented on SIS-350:
-
Welcome Aditya! Would you like to contribute in the context of Google Summer of
Code (GSoC), or independently of GSoC? If you (or Weilun) want to contribute as
a GSoC student, we first need to wait for confirmation that the Apache Software
Foundation (ASF) is accepted for GSoC participation this year (ASF needs to
apply each year). If you would like to participate independently of GSoC, then
one possible approach could be to start a discussion on the Apache SIS mailing
list?
> Port Apache SIS to Android
> --
>
> Key: SIS-350
> URL: https://issues.apache.org/jira/browse/SIS-350
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Features, Metadata, Referencing, Storage, Utilities
>Reporter: Martin Desruisseaux
> Labels: gsoc2017, mentor
>
> Create an Apache SIS branch for Android. This will require the following work:
> * Simulate the JAXB framework if possible, or remove SIS usage of JAXB on the
> Android branch. JAXB is extensively used in the metadata modules, but some
> usages are found also in other modules.
> * Remove Java2D dependency. This work has already been anticipated by keeping
> Java2D dependency in separated classes or packages. When a replacement is
> available on the Android platform, the Java2D type should be substituted by
> the replacement. This should include in particular
> {{java.awt.geom.AffineTransform}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SIS-350) Port Apache SIS to Android
[
https://issues.apache.org/jira/browse/SIS-350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15889737#comment-15889737
]
Martin Desruisseaux commented on SIS-350:
-
Thanks Weilun, your contribution would be welcome!
> Port Apache SIS to Android
> --
>
> Key: SIS-350
> URL: https://issues.apache.org/jira/browse/SIS-350
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Features, Metadata, Referencing, Storage, Utilities
>Reporter: Martin Desruisseaux
> Labels: gsoc2017, mentor
>
> Create an Apache SIS branch for Android. This will require the following work:
> * Simulate the JAXB framework if possible, or remove SIS usage of JAXB on the
> Android branch. JAXB is extensively used in the metadata modules, but some
> usages are found also in other modules.
> * Remove Java2D dependency. This work has already been anticipated by keeping
> Java2D dependency in separated classes or packages. When a replacement is
> available on the Android platform, the Java2D type should be substituted by
> the replacement. This should include in particular
> {{java.awt.geom.AffineTransform}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (SIS-355) Provide a "deep copy" operation on ISO 19115 metadata
[
https://issues.apache.org/jira/browse/SIS-355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux resolved SIS-355.
-
Resolution: Fixed
> Provide a "deep copy" operation on ISO 19115 metadata
> -
>
> Key: SIS-355
> URL: https://issues.apache.org/jira/browse/SIS-355
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Metadata
>Affects Versions: 0.3, 0.4, 0.5, 0.6, 0.7
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Minor
> Fix For: 0.8
>
>
> In Apache SIS, all implementation classes of ISO 19115 metadata types have a
> shallow copy constructor. However there is nothing for performing a deep copy
> (the {{clone()}} method is not for this purpose). While deep copy should be
> avoided, it is sometime useful for example when using an existing metadata as
> a template.
> h3. Better alternative
> Note that the {{ModifiableMetadata.unmodifiable()}} method provides a better
> way to use a metadata as a template, as it returns a snapshot and allows the
> caller to continue to modify the original metadata object and create new
> snapshots. This approach allows sharing the children that have the same
> content, thus reducing memory usage. In comparison, deep copy operations
> unconditionally duplicate everything, no matter if it was needed or not.
> Nevertheless deep copies are still sometime useful, for example when we do
> not have the original {{ModifiableMetadata}} instance anymore.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (SIS-355) Provide a "deep copy" operation on ISO 19115 metadata
Martin Desruisseaux created SIS-355:
---
Summary: Provide a "deep copy" operation on ISO 19115 metadata
Key: SIS-355
URL: https://issues.apache.org/jira/browse/SIS-355
Project: Spatial Information Systems
Issue Type: Task
Components: Metadata
Affects Versions: 0.7, 0.6, 0.5, 0.4, 0.3
Reporter: Martin Desruisseaux
Assignee: Martin Desruisseaux
Priority: Minor
Fix For: 0.8
In Apache SIS, all implementation classes of ISO 19115 metadata types have a
shallow copy constructor. However there is nothing for performing a deep copy
(the {{clone()}} method is not for this purpose). While deep copy should be
avoided, it is sometime useful for example when using an existing metadata as a
template.
h3. Better alternative
Note that the {{ModifiableMetadata.unmodifiable()}} method provides a better
way to use a metadata as a template, as it returns a snapshot and allows the
caller to continue to modify the original metadata object and create new
snapshots. This approach allows sharing the children that have the same
content, thus reducing memory usage. In comparison, deep copy operations
unconditionally duplicate everything, no matter if it was needed or not.
Nevertheless deep copies are still sometime useful, for example when we do not
have the original {{ModifiableMetadata}} instance anymore.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (SIS-354) Military Grid Reference System (MGRS)
[
https://issues.apache.org/jira/browse/SIS-354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-354:
Description:
Support the [Military Grid Reference
System|https://en.wikipedia.org/wiki/Military_Grid_Reference_System] (MGRS).
The MGRS is the geocoordinate standard used by NATO militaries for locating
points on the earth. It is based on the Universal Transverse Mercator (UTM) and
the Universal Polar Stereographic (UPS) projections. Despite its name, MGRS is
used not only for military purposes; it is used also for organizing Earth
Observation data in directory trees for example.
MGRS can be used as an alternative to {{GeoHashCoder}} already available since
Apache SIS 0.1. A MGRS advantage is that it uses rectangular coordinates in
metres instead than degrees, and that it provides a way to divide the Earth in
grid cells of the same size (except those that are on the border between two
zones).
was:
Support the Military Grid Reference System (MGRS). The MGRS is the
geocoordinate standard used by NATO militaries for locating points on the
earth. It is based on the Universal Transverse Mercator (UTM) and the Universal
Polar Stereographic (UPS) projections. Despite its name, MGRS is used not only
for military purposes; it is used also for organizing Earth Observation data in
directory trees for example.
MGRS can be used as an alternative to {{GeoHashCoder}} already available since
Apache SIS 0.1. A MGRS advantage is that it uses rectangular coordinates in
metres instead than degrees, and that it provides a way to divide the Earth in
grid cells of the same size (except those that are on the border between two
zones).
> Military Grid Reference System (MGRS)
> -
>
> Key: SIS-354
> URL: https://issues.apache.org/jira/browse/SIS-354
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Referencing
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Fix For: 0.8
>
>
> Support the [Military Grid Reference
> System|https://en.wikipedia.org/wiki/Military_Grid_Reference_System] (MGRS).
> The MGRS is the geocoordinate standard used by NATO militaries for locating
> points on the earth. It is based on the Universal Transverse Mercator (UTM)
> and the Universal Polar Stereographic (UPS) projections. Despite its name,
> MGRS is used not only for military purposes; it is used also for organizing
> Earth Observation data in directory trees for example.
> MGRS can be used as an alternative to {{GeoHashCoder}} already available
> since Apache SIS 0.1. A MGRS advantage is that it uses rectangular
> coordinates in metres instead than degrees, and that it provides a way to
> divide the Earth in grid cells of the same size (except those that are on the
> border between two zones).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (SIS-354) Military Grid Reference System (MGRS)
Martin Desruisseaux created SIS-354:
---
Summary: Military Grid Reference System (MGRS)
Key: SIS-354
URL: https://issues.apache.org/jira/browse/SIS-354
Project: Spatial Information Systems
Issue Type: Task
Components: Referencing
Reporter: Martin Desruisseaux
Assignee: Martin Desruisseaux
Fix For: 0.8
Support the Military Grid Reference System (MGRS). The MGRS is the
geocoordinate standard used by NATO militaries for locating points on the
earth. It is based on the Universal Transverse Mercator (UTM) and the Universal
Polar Stereographic (UPS) projections. Despite its name, MGRS is used not only
for military purposes; it is used also for organizing Earth Observation data in
directory trees for example.
MGRS can be used as an alternative to {{GeoHashCoder}} already available since
Apache SIS 0.1. A MGRS advantage is that it uses rectangular coordinates in
metres instead than degrees, and that it provides a way to divide the Earth in
grid cells of the same size (except those that are on the border between two
zones).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (SIS-353) UTM should take in account Norway and Svalbard special cases
[
https://issues.apache.org/jira/browse/SIS-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux resolved SIS-353.
-
Resolution: Fixed
> UTM should take in account Norway and Svalbard special cases
>
>
> Key: SIS-353
> URL: https://issues.apache.org/jira/browse/SIS-353
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Referencing
>Affects Versions: 0.7
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Fix For: 0.8
>
>
> The Universal Transverse Mercator (UTM) is not strictly divided in 6° width
> zones. There is exceptions for Norway and Svalbard, for historical reasons
> (UTM seems to have been designed by military around World War II).
> * Between 56°N and 64°N, zone 32 is widened to 9° (at the expense of zone 31)
> to accommodate southwest Norway.
> * Between 72°N and 84°N, zones 33 and 35 are widened to 12° to accommodate
> Svalbard. To compensate for these 12° wide zones, zones 31 and 37 are widened
> to 9° and zones 32, 34, and 36 are eliminated.
> A nice image of UTM grid including the special cases is [available on
> Wikimedia
> common|https://upload.wikimedia.org/wikipedia/commons/e/ed/Utm-zones.jpg]
> (see the 31X, 33X, 35X, 37X and 32V cells). This image also covers the UPS
> cases (A, B, Y and Z cells, discussed below).
> Since the {{CommonCRS.UTM(double, double)}} method already expects latitude
> and longitude arguments, it can easily be fixed without API change. However
> it would be a slight change in its behavior. An alternative is to deprecate
> the current {{UTM(double, double)}} method and create a new
> {{universal(double, double)}} method instead. That {{universal}} method would
> handle not only the Universal Transverse Mercator (UTM) projection with the
> above-cited special cases, but also Universal Polar Stereographic (UPS)
> projections for latitudes north of 84°N or south of 80°S.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (SIS-353) UTM should take in account Norway and Svalbard special cases
[
https://issues.apache.org/jira/browse/SIS-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-353:
Description:
The Universal Transverse Mercator (UTM) is not strictly divided in 6° width
zones. There is exceptions for Norway and Svalbard, for historical reasons (UTM
seems to have been designed by military around World War II).
* Between 56°N and 64°N, zone 32 is widened to 9° (at the expense of zone 31)
to accommodate southwest Norway.
* Between 72°N and 84°N, zones 33 and 35 are widened to 12° to accommodate
Svalbard. To compensate for these 12° wide zones, zones 31 and 37 are widened
to 9° and zones 32, 34, and 36 are eliminated.
A nice image of UTM grid including the special cases is [available on Wikimedia
common|https://upload.wikimedia.org/wikipedia/commons/e/ed/Utm-zones.jpg] (see
the 31X, 33X, 35X, 37X and 32V cells). This image also covers the UPS cases (A,
B, Y and Z cells, discussed below).
Since the {{CommonCRS.UTM(double, double)}} method already expects latitude and
longitude arguments, it can easily be fixed without API change. However it
would be a slight change in its behavior. An alternative is to deprecate the
current {{UTM(double, double)}} method and create a new {{universal(double,
double)}} method instead. That {{universal}} method would handle not only the
Universal Transverse Mercator (UTM) projection with the above-cited special
cases, but also Universal Polar Stereographic (UPS) projections for latitudes
north of 84°N or south of 80°S.
was:
The Universal Transverse Mercator (UTM) is not strictly divided in 6° width
zones. There is exceptions for Norway and Svalbard, for historical reasons (UTM
seems to have been designed by military around World War II).
* Between 56°N and 64°N, zone 32 is widened to 9° (at the expense of zone 31)
to accommodate southwest Norway.
* Between 72°N and 84°N, zones 33 and 35 are widened to 12° to accommodate
Svalbard. To compensate for these 12° wide zones, zones 31 and 37 are widened
to 9° and zones 32, 34, and 36 are eliminated.
A nice image of UTM grid including the special cases is [available on Wikimedia
common|https://upload.wikimedia.org/wikipedia/commons/e/ed/Utm-zones.jpg] (see
the 31X, 33X, 35X, 37X and 32V cells). This image also covers the UPS cases (A,
B, Y and Z cells, discussed below).
Since the {{CommonCRS.UTM(double, double)}} method already expect latitude and
longitude, it can easily be fixed without API change. However it would be a
slight change in its behavior. An alternative is to deprecate the current
{{UTM(double, double)}} method and create a new {{universal(double, double)}}
method instead. That {{universal}} method would handle not only the Universal
Transverse Mercator (UTM) case with its special cases, but also Universal Polar
Stereographic (UPS) cases.
> UTM should take in account Norway and Svalbard special cases
>
>
> Key: SIS-353
> URL: https://issues.apache.org/jira/browse/SIS-353
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Referencing
>Affects Versions: 0.7
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Fix For: 0.8
>
>
> The Universal Transverse Mercator (UTM) is not strictly divided in 6° width
> zones. There is exceptions for Norway and Svalbard, for historical reasons
> (UTM seems to have been designed by military around World War II).
> * Between 56°N and 64°N, zone 32 is widened to 9° (at the expense of zone 31)
> to accommodate southwest Norway.
> * Between 72°N and 84°N, zones 33 and 35 are widened to 12° to accommodate
> Svalbard. To compensate for these 12° wide zones, zones 31 and 37 are widened
> to 9° and zones 32, 34, and 36 are eliminated.
> A nice image of UTM grid including the special cases is [available on
> Wikimedia
> common|https://upload.wikimedia.org/wikipedia/commons/e/ed/Utm-zones.jpg]
> (see the 31X, 33X, 35X, 37X and 32V cells). This image also covers the UPS
> cases (A, B, Y and Z cells, discussed below).
> Since the {{CommonCRS.UTM(double, double)}} method already expects latitude
> and longitude arguments, it can easily be fixed without API change. However
> it would be a slight change in its behavior. An alternative is to deprecate
> the current {{UTM(double, double)}} method and create a new
> {{universal(double, double)}} method instead. That {{universal}} method would
> handle not only the Universal Transverse Mercator (UTM) projection with the
> above-cited special cases, but also Universal Polar Stereographic (UPS)
> projections for latitudes north of 84°N or south of 80°S.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (SIS-353) UTM should take in account Norway and Svalbard special cases
[
https://issues.apache.org/jira/browse/SIS-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-353:
Description:
The Universal Transverse Mercator (UTM) is not strictly divided in 6° width
zones. There is exceptions for Norway and Svalbard, for historical reasons (UTM
seems to have been designed by military around World War II).
* Between 56°N and 64°N, zone 32 is widened to 9° (at the expense of zone 31)
to accommodate southwest Norway.
* Between 72°N and 84°N, zones 33 and 35 are widened to 12° to accommodate
Svalbard. To compensate for these 12° wide zones, zones 31 and 37 are widened
to 9° and zones 32, 34, and 36 are eliminated.
A nice image of UTM grid including the special cases is [available on Wikimedia
common|https://upload.wikimedia.org/wikipedia/commons/e/ed/Utm-zones.jpg] (see
cell 31X, 33X, 35X, 37X and 32V). This image also covers the UPS cases
(discussed below).
Since the {{CommonCRS.UTM(double, double)}} method already expect latitude and
longitude, it can easily be fixed without API change. However it would be a
slight change in its behavior. An alternative is to deprecate the current
{{UTM(double, double)}} method and create a new {{universal(double, double)}}
method instead. That {{universal}} method would handle not only the Universal
Transverse Mercator (UTM) case with its special cases, but also Universal Polar
Stereographic (UPS) cases.
was:
The Universal Transverse Mercator (UTM) is not strictly divided in 6° width
zones. There is exceptions for Norway and Svalbard, for historical reasons (UTM
seems to have been designed by military around World War II).
* Between 56°N and 64°N, zone 32 is widened to 9° (at the expense of zone 31)
to accommodate southwest Norway.
* Between 72°N and 84°N, zones 33 and 35 are widened to 12° to accommodate
Svalbard. To compensate for these 12° wide zones, zones 31 and 37 are widened
to 9° and zones 32, 34, and 36 are eliminated.
A nice image of UTM grid including the special cases is [available on Wikimedia
common|https://upload.wikimedia.org/wikipedia/commons/e/ed/Utm-zones.jpg]. This
image also covers the UPS cases (discussed below).
Since the {{CommonCRS.UTM(double, double)}} method already expect latitude and
longitude, it can easily be fixed without API change. However it would be a
slight change in its behavior. An alternative is to deprecate the current
{{UTM(double, double)}} method and create a new {{universal(double, double)}}
method instead. That {{universal}} method would handle not only the Universal
Transverse Mercator (UTM) case with its special cases, but also Universal Polar
Stereographic (UPS) cases.
> UTM should take in account Norway and Svalbard special cases
>
>
> Key: SIS-353
> URL: https://issues.apache.org/jira/browse/SIS-353
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Referencing
>Affects Versions: 0.7
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Fix For: 0.8
>
>
> The Universal Transverse Mercator (UTM) is not strictly divided in 6° width
> zones. There is exceptions for Norway and Svalbard, for historical reasons
> (UTM seems to have been designed by military around World War II).
> * Between 56°N and 64°N, zone 32 is widened to 9° (at the expense of zone 31)
> to accommodate southwest Norway.
> * Between 72°N and 84°N, zones 33 and 35 are widened to 12° to accommodate
> Svalbard. To compensate for these 12° wide zones, zones 31 and 37 are widened
> to 9° and zones 32, 34, and 36 are eliminated.
> A nice image of UTM grid including the special cases is [available on
> Wikimedia
> common|https://upload.wikimedia.org/wikipedia/commons/e/ed/Utm-zones.jpg]
> (see cell 31X, 33X, 35X, 37X and 32V). This image also covers the UPS cases
> (discussed below).
> Since the {{CommonCRS.UTM(double, double)}} method already expect latitude
> and longitude, it can easily be fixed without API change. However it would be
> a slight change in its behavior. An alternative is to deprecate the current
> {{UTM(double, double)}} method and create a new {{universal(double, double)}}
> method instead. That {{universal}} method would handle not only the Universal
> Transverse Mercator (UTM) case with its special cases, but also Universal
> Polar Stereographic (UPS) cases.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (SIS-353) UTM should take in account Norway and Svalbard special cases
[
https://issues.apache.org/jira/browse/SIS-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-353:
Description:
The Universal Transverse Mercator (UTM) is not strictly divided in 6° width
zones. There is exceptions for Norway and Svalbard, for historical reasons (UTM
seems to have been designed by military around World War II).
* Between 56°N and 64°N, zone 32 is widened to 9° (at the expense of zone 31)
to accommodate southwest Norway.
* Between 72°N and 84°N, zones 33 and 35 are widened to 12° to accommodate
Svalbard. To compensate for these 12° wide zones, zones 31 and 37 are widened
to 9° and zones 32, 34, and 36 are eliminated.
A nice image of UTM grid including the special cases is [available on Wikimedia
common|https://upload.wikimedia.org/wikipedia/commons/e/ed/Utm-zones.jpg] (see
the 31X, 33X, 35X, 37X and 32V cells). This image also covers the UPS cases (A,
B, Y and Z cells, discussed below).
Since the {{CommonCRS.UTM(double, double)}} method already expect latitude and
longitude, it can easily be fixed without API change. However it would be a
slight change in its behavior. An alternative is to deprecate the current
{{UTM(double, double)}} method and create a new {{universal(double, double)}}
method instead. That {{universal}} method would handle not only the Universal
Transverse Mercator (UTM) case with its special cases, but also Universal Polar
Stereographic (UPS) cases.
was:
The Universal Transverse Mercator (UTM) is not strictly divided in 6° width
zones. There is exceptions for Norway and Svalbard, for historical reasons (UTM
seems to have been designed by military around World War II).
* Between 56°N and 64°N, zone 32 is widened to 9° (at the expense of zone 31)
to accommodate southwest Norway.
* Between 72°N and 84°N, zones 33 and 35 are widened to 12° to accommodate
Svalbard. To compensate for these 12° wide zones, zones 31 and 37 are widened
to 9° and zones 32, 34, and 36 are eliminated.
A nice image of UTM grid including the special cases is [available on Wikimedia
common|https://upload.wikimedia.org/wikipedia/commons/e/ed/Utm-zones.jpg] (see
cell 31X, 33X, 35X, 37X and 32V). This image also covers the UPS cases
(discussed below).
Since the {{CommonCRS.UTM(double, double)}} method already expect latitude and
longitude, it can easily be fixed without API change. However it would be a
slight change in its behavior. An alternative is to deprecate the current
{{UTM(double, double)}} method and create a new {{universal(double, double)}}
method instead. That {{universal}} method would handle not only the Universal
Transverse Mercator (UTM) case with its special cases, but also Universal Polar
Stereographic (UPS) cases.
> UTM should take in account Norway and Svalbard special cases
>
>
> Key: SIS-353
> URL: https://issues.apache.org/jira/browse/SIS-353
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Referencing
>Affects Versions: 0.7
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Fix For: 0.8
>
>
> The Universal Transverse Mercator (UTM) is not strictly divided in 6° width
> zones. There is exceptions for Norway and Svalbard, for historical reasons
> (UTM seems to have been designed by military around World War II).
> * Between 56°N and 64°N, zone 32 is widened to 9° (at the expense of zone 31)
> to accommodate southwest Norway.
> * Between 72°N and 84°N, zones 33 and 35 are widened to 12° to accommodate
> Svalbard. To compensate for these 12° wide zones, zones 31 and 37 are widened
> to 9° and zones 32, 34, and 36 are eliminated.
> A nice image of UTM grid including the special cases is [available on
> Wikimedia
> common|https://upload.wikimedia.org/wikipedia/commons/e/ed/Utm-zones.jpg]
> (see the 31X, 33X, 35X, 37X and 32V cells). This image also covers the UPS
> cases (A, B, Y and Z cells, discussed below).
> Since the {{CommonCRS.UTM(double, double)}} method already expect latitude
> and longitude, it can easily be fixed without API change. However it would be
> a slight change in its behavior. An alternative is to deprecate the current
> {{UTM(double, double)}} method and create a new {{universal(double, double)}}
> method instead. That {{universal}} method would handle not only the Universal
> Transverse Mercator (UTM) case with its special cases, but also Universal
> Polar Stereographic (UPS) cases.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (SIS-353) UTM should take in account Norway and Svalbard special cases
[
https://issues.apache.org/jira/browse/SIS-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-353:
Description:
The Universal Transverse Mercator (UTM) is not strictly divided in 6° width
zones. There is exceptions for Norway and Svalbard, for historical reasons (UTM
seems to have been designed by military around World War II).
* Between 56°N and 64°N, zone 32 is widened to 9° (at the expense of zone 31)
to accommodate southwest Norway.
* Between 72°N and 84°N, zones 33 and 35 are widened to 12° to accommodate
Svalbard. To compensate for these 12° wide zones, zones 31 and 37 are widened
to 9° and zones 32, 34, and 36 are eliminated.
A nice image of UTM grid including the special cases is [available on Wikimedia
common|https://upload.wikimedia.org/wikipedia/commons/e/ed/Utm-zones.jpg]. This
image also covers the UPS cases (discussed below).
Since the {{CommonCRS.UTM(double, double)}} method already expect latitude and
longitude, it can easily be fixed without API change. However it would be a
slight change in its behavior. An alternative is to deprecate the current
{{UTM(double, double)}} method and create a new {{universal(double, double)}}
method instead. That {{universal}} method would handle not only the Universal
Transverse Mercator (UTM) case with its special cases, but also Universal Polar
Stereographic (UPS) cases.
was:
The Universal Transverse Mercator (UTM) is not strictly divided in 6° width
zones. There is exceptions for Norway and Svalbard, for historical reasons (UTM
seems to have been designed by military around World War II).
* Between 56°N and 64°N, zone 32 is widened to 9° (at the expense of zone 31)
to accommodate southwest Norway.
* Between 72°N and 84°N, zones 33 and 35 are widened to 12° to accommodate
Svalbard. To compensate for these 12° wide zones, zones 31 and 37 are widened
to 9° and zones 32, 34, and 36 are eliminated.
Since the {{CommonCRS.UTM(double, double)}} method already expect latitude and
longitude, it can easily be fixed without API change. However it would be a
slight change in its behavior. An alternative is to deprecate the current
{{UTM(double, double)}} method and create a new {{universal(double, double)}}
method instead. That {{universal}} method would handle not only the Universal
Transverse Mercator (UTM) case with its special cases, but also Universal Polar
Stereographic (UPS) cases.
> UTM should take in account Norway and Svalbard special cases
>
>
> Key: SIS-353
> URL: https://issues.apache.org/jira/browse/SIS-353
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Referencing
>Affects Versions: 0.7
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Fix For: 0.8
>
>
> The Universal Transverse Mercator (UTM) is not strictly divided in 6° width
> zones. There is exceptions for Norway and Svalbard, for historical reasons
> (UTM seems to have been designed by military around World War II).
> * Between 56°N and 64°N, zone 32 is widened to 9° (at the expense of zone 31)
> to accommodate southwest Norway.
> * Between 72°N and 84°N, zones 33 and 35 are widened to 12° to accommodate
> Svalbard. To compensate for these 12° wide zones, zones 31 and 37 are widened
> to 9° and zones 32, 34, and 36 are eliminated.
> A nice image of UTM grid including the special cases is [available on
> Wikimedia
> common|https://upload.wikimedia.org/wikipedia/commons/e/ed/Utm-zones.jpg].
> This image also covers the UPS cases (discussed below).
> Since the {{CommonCRS.UTM(double, double)}} method already expect latitude
> and longitude, it can easily be fixed without API change. However it would be
> a slight change in its behavior. An alternative is to deprecate the current
> {{UTM(double, double)}} method and create a new {{universal(double, double)}}
> method instead. That {{universal}} method would handle not only the Universal
> Transverse Mercator (UTM) case with its special cases, but also Universal
> Polar Stereographic (UPS) cases.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (SIS-353) UTM should take in account Norway and Svalbard special cases
Martin Desruisseaux created SIS-353:
---
Summary: UTM should take in account Norway and Svalbard special
cases
Key: SIS-353
URL: https://issues.apache.org/jira/browse/SIS-353
Project: Spatial Information Systems
Issue Type: Improvement
Components: Referencing
Affects Versions: 0.7
Reporter: Martin Desruisseaux
Assignee: Martin Desruisseaux
Fix For: 0.8
The Universal Transverse Mercator (UTM) is not strictly divided in 6° width
zones. There is exceptions for Norway and Svalbard, for historical reasons (UTM
seems to have been designed by military around World War II).
* Between 56°N and 64°N, zone 32 is widened to 9° (at the expense of zone 31)
to accommodate southwest Norway.
* Between 72°N and 84°N, zones 33 and 35 are widened to 12° to accommodate
Svalbard. To compensate for these 12° wide zones, zones 31 and 37 are widened
to 9° and zones 32, 34, and 36 are eliminated.
Since the {{CommonCRS.UTM(double, double)}} method already expect latitude and
longitude, it can easily be fixed without API change. However it would be a
slight change in its behavior. An alternative is to deprecate the current
{{UTM(double, double)}} method and create a new {{universal(double, double)}}
method instead. That {{universal}} method would handle not only the Universal
Transverse Mercator (UTM) case with its special cases, but also Universal Polar
Stereographic (UPS) cases.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (SIS-352) Support spatial referencing by geographic identifiers (ISO 19112)
Martin Desruisseaux created SIS-352:
---
Summary: Support spatial referencing by geographic identifiers
(ISO 19112)
Key: SIS-352
URL: https://issues.apache.org/jira/browse/SIS-352
Project: Spatial Information Systems
Issue Type: Task
Components: Referencing
Reporter: Martin Desruisseaux
Assignee: Martin Desruisseaux
Fix For: 0.8
Provide a basic support of [ISO 19112:2003 — Spatial referencing by geographic
identifiers|http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=26017].
Geographic identifiers are location descriptors such as addresses and grid
indexes. ISO 19112 describes (among other things) how to map geographic
identifiers to spatial coordinates. Some keys classes defined by ISO 19112 are
listed below (Apache SIS would not necessarily use exactly the same names):
* {{SpatialReferenceSystemUsingGeographicIdentifier}}
* {{Gazetteer}}
* {{LocationType}}
* {{LocationInstance}}
The {{Gazetteer}} seems the most interesting part for us, since it is the class
in charge of converting a geographic identifier to something else (_e.g._ a
geographic coordinate). It seems that {{Gazetteer}} could be compared to the
{{MathTransform}} interface that we already implement in the following package:
* {{org.apache.sis.referencing.operation}}
but working on geographic identifiers instead than coordinates. For this
reason, I propose to put an ISO 19112 implementation in the following package:
* {{org.apache.sis.referencing.gazetteer}}
I have hesitation about whether such package should be in a separated module
(e.g. {{"sis-referencing-by-identifier"}}) or not, but given that I expect the
amount of classes to be small I'm not sure it is worth creating a new module.
An implementation of [Military Grid Reference System
(MGRS)|https://en.wikipedia.org/wiki/Military_Grid_Reference_System] is used
for experimenting what the API may looks like. Despite its name, MGRS is not
used only for military purpose. It is used also as a way to organize Earth
Observation data on Amazon S3 cloud storage.
Note that Apache SIS already have (since the 0.1 version!) a class that seems
in the scope of ISO 19112:
[GeoHashCoder|http://sis.apache.org/apidocs/org/apache/sis/index/GeoHashCoder.html].
As part of an ISO 19112 support, we could also refactor {{GeoHashCoder}} as
another implementation, side-by-side with {{MilitaryGridReferenceSystem}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (SIS-351) Create metadata, CRS and tabular data editors in JavaFX
[ https://issues.apache.org/jira/browse/SIS-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux updated SIS-351: Labels: gsoc2017 mentor (was: gsoc2017) > Create metadata, CRS and tabular data editors in JavaFX > --- > > Key: SIS-351 > URL: https://issues.apache.org/jira/browse/SIS-351 > Project: Spatial Information Systems > Issue Type: New Feature > Components: GUI >Reporter: Martin Desruisseaux > Labels: gsoc2017, mentor > > Creates the foundation of a GUI application for Apache SIS based on JavaFX. > This application should leverage the functionalities available in Apache SIS > 0.8. In particular: > * Read metadata from files in various formats (currently ISO 19139, GeoTIFF, > NetCDF, LANDSAT, GPX, Moving Features) > * Get Coordinate Reference System from a registry or from GML or WKT > definitions and apply coordinate transformations. > * Show vector data in a tabular format. > Since SIS does not yet have a renderer engine, we can not yet show maps in > the application. However the application should be designed with this goal in > mind. > This project should create a metadata editor showing the ISO 19115 metadata. > We should provide a simplified view with only the essential information, and > an advanced view showing all information. The information to shown should be > customizable. The user should be able to edit the metadata and save them in > ISO 19139 format. > The project should also create the necessary widgets for showing a Coordinate > Reference System (CRS) definition and allow the user to edit it. Another > widget should use the CRS definitions for applying coordinate operations (map > projections) using the existing Apache SIS referencing engine, and show the > result in a table with information about accuracy and domain of validity. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (SIS-351) Create metadata, CRS and tabular data editors in JavaFX
[ https://issues.apache.org/jira/browse/SIS-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux updated SIS-351: Summary: Create metadata, CRS and tabular data editors in JavaFX (was: Create a metadata, CRS and tabular data editor in JavaFX) > Create metadata, CRS and tabular data editors in JavaFX > --- > > Key: SIS-351 > URL: https://issues.apache.org/jira/browse/SIS-351 > Project: Spatial Information Systems > Issue Type: New Feature > Components: GUI >Reporter: Martin Desruisseaux > Labels: gsoc2017 > > Creates the foundation of a GUI application for Apache SIS based on JavaFX. > This application should leverage the functionalities available in Apache SIS > 0.8. In particular: > * Read metadata from files in various formats (currently ISO 19139, GeoTIFF, > NetCDF, LANDSAT, GPX, Moving Features) > * Get Coordinate Reference System from a registry or from GML or WKT > definitions and apply coordinate transformations. > * Show vector data in a tabular format. > Since SIS does not yet have a renderer engine, we can not yet show maps in > the application. However the application should be designed with this goal in > mind. > This project should create a metadata editor showing the ISO 19115 metadata. > We should provide a simplified view with only the essential information, and > an advanced view showing all information. The information to shown should be > customizable. The user should be able to edit the metadata and save them in > ISO 19139 format. > The project should also create the necessary widgets for showing a Coordinate > Reference System (CRS) definition and allow the user to edit it. Another > widget should use the CRS definitions for applying coordinate operations (map > projections) using the existing Apache SIS referencing engine, and show the > result in a table with information about accuracy and domain of validity. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (SIS-351) Create a metadata, CRS and tabular data editor in JavaFX
[ https://issues.apache.org/jira/browse/SIS-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux updated SIS-351: Summary: Create a metadata, CRS and tabular data editor in JavaFX (was: Create a metadata editor in JavaFX) > Create a metadata, CRS and tabular data editor in JavaFX > > > Key: SIS-351 > URL: https://issues.apache.org/jira/browse/SIS-351 > Project: Spatial Information Systems > Issue Type: New Feature > Components: GUI >Reporter: Martin Desruisseaux > Labels: gsoc2017 > > Creates the foundation of a GUI application for Apache SIS based on JavaFX. > This application should leverage the functionalities available in Apache SIS > 0.8. In particular: > * Read metadata from files in various formats (currently ISO 19139, GeoTIFF, > NetCDF, LANDSAT, GPX, Moving Features) > * Get Coordinate Reference System from a registry or from GML or WKT > definitions and apply coordinate transformations. > * Show vector data in a tabular format. > Since SIS does not yet have a renderer engine, we can not yet show maps in > the application. However the application should be designed with this goal in > mind. > This project should create a metadata editor showing the ISO 19115 metadata. > We should provide a simplified view with only the essential information, and > an advanced view showing all information. The information to shown should be > customizable. The user should be able to edit the metadata and save them in > ISO 19139 format. > The project should also create the necessary widgets for showing a Coordinate > Reference System (CRS) definition and allow the user to edit it. Another > widget should use the CRS definitions for applying coordinate operations (map > projections) using the existing Apache SIS referencing engine, and show the > result in a table with information about accuracy and domain of validity. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (SIS-351) Create a metadata editor in JavaFX
Martin Desruisseaux created SIS-351: --- Summary: Create a metadata editor in JavaFX Key: SIS-351 URL: https://issues.apache.org/jira/browse/SIS-351 Project: Spatial Information Systems Issue Type: New Feature Components: GUI Reporter: Martin Desruisseaux Creates the foundation of a GUI application for Apache SIS based on JavaFX. This application should leverage the functionalities available in Apache SIS 0.8. In particular: * Read metadata from files in various formats (currently ISO 19139, GeoTIFF, NetCDF, LANDSAT, GPX, Moving Features) * Get Coordinate Reference System from a registry or from GML or WKT definitions and apply coordinate transformations. * Show vector data in a tabular format. Since SIS does not yet have a renderer engine, we can not yet show maps in the application. However the application should be designed with this goal in mind. This project should create a metadata editor showing the ISO 19115 metadata. We should provide a simplified view with only the essential information, and an advanced view showing all information. The information to shown should be customizable. The user should be able to edit the metadata and save them in ISO 19139 format. The project should also create the necessary widgets for showing a Coordinate Reference System (CRS) definition and allow the user to edit it. Another widget should use the CRS definitions for applying coordinate operations (map projections) using the existing Apache SIS referencing engine, and show the result in a table with information about accuracy and domain of validity. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (SIS-350) Port Apache SIS to Android
[
https://issues.apache.org/jira/browse/SIS-350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-350:
Labels: gsoc2017 mentor (was: gsoc2017)
> Port Apache SIS to Android
> --
>
> Key: SIS-350
> URL: https://issues.apache.org/jira/browse/SIS-350
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Features, Metadata, Referencing, Storage, Utilities
>Reporter: Martin Desruisseaux
> Labels: gsoc2017, mentor
>
> Create an Apache SIS branch for Android. This will require the following work:
> * Simulate the JAXB framework if possible, or remove SIS usage of JAXB on the
> Android branch. JAXB is extensively used in the metadata modules, but some
> usages are found also in other modules.
> * Remove Java2D dependency. This work has already been anticipated by keeping
> Java2D dependency in separated classes or packages. When a replacement is
> available on the Android platform, the Java2D type should be substituted by
> the replacement. This should include in particular
> {{java.awt.geom.AffineTransform}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (SIS-350) Port Apache SIS to Android
[
https://issues.apache.org/jira/browse/SIS-350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-350:
Labels: gsoc2017 (was: )
> Port Apache SIS to Android
> --
>
> Key: SIS-350
> URL: https://issues.apache.org/jira/browse/SIS-350
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Features, Metadata, Referencing, Storage, Utilities
>Reporter: Martin Desruisseaux
> Labels: gsoc2017
>
> Create an Apache SIS branch for Android. This will require the following work:
> * Simulate the JAXB framework if possible, or remove SIS usage of JAXB on the
> Android branch. JAXB is extensively used in the metadata modules, but some
> usages are found also in other modules.
> * Remove Java2D dependency. This work has already been anticipated by keeping
> Java2D dependency in separated classes or packages. When a replacement is
> available on the Android platform, the Java2D type should be substituted by
> the replacement. This should include in particular
> {{java.awt.geom.AffineTransform}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (SIS-350) Port Apache SIS to Android
Martin Desruisseaux created SIS-350:
---
Summary: Port Apache SIS to Android
Key: SIS-350
URL: https://issues.apache.org/jira/browse/SIS-350
Project: Spatial Information Systems
Issue Type: Task
Components: Features, Metadata, Referencing, Storage, Utilities
Reporter: Martin Desruisseaux
Create an Apache SIS branch for Android. This will require the following work:
* Simulate the JAXB framework if possible, or remove SIS usage of JAXB on the
Android branch. JAXB is extensively used in the metadata modules, but some
usages are found also in other modules.
* Remove Java2D dependency. This work has already been anticipated by keeping
Java2D dependency in separated classes or packages. When a replacement is
available on the Android platform, the Java2D type should be substituted by the
replacement. This should include in particular
{{java.awt.geom.AffineTransform}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (SIS-10) Ability to create SIS data from WKT specs
[ https://issues.apache.org/jira/browse/SIS-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux updated SIS-10: --- Component/s: (was: Referencing) > Ability to create SIS data from WKT specs > - > > Key: SIS-10 > URL: https://issues.apache.org/jira/browse/SIS-10 > Project: Spatial Information Systems > Issue Type: New Feature > Components: Geometry objects, Storage, Web services >Reporter: Chris A. Mattmann >Assignee: Chris A. Mattmann > Labels: WKT > Fix For: 0.7 > > > OGC well known text [1] is an ASCII-like specification for vector and > geometry objects (points, linestrings, multilinestrings, etc.) We should > provide a means to load and create SIS data from these specs. > [1] http://en.wikipedia.org/wiki/Well-known_text -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (SIS-212) Coordinate operation methods to implement
[
https://issues.apache.org/jira/browse/SIS-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-212:
Labels: gsoc2016 gsoc2017 java mentor (was: gsoc2016 java mentor)
> Coordinate operation methods to implement
> -
>
> Key: SIS-212
> URL: https://issues.apache.org/jira/browse/SIS-212
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Referencing
>Affects Versions: 0.6, 0.7, 0.8
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Labels: gsoc2016, gsoc2017, java, mentor
> Fix For: 0.6, 0.7, 0.8
>
>
> This is an umbrella task for some coordinate operation methods not yet
> supported in Apache SIS. Coordinate operations include _map projections_
> (e.g. Transverse Mercator, Lambert Conic Conformal, _etc._), _datum shifts_
> (e.g. transformations from NAD27 to NAD83 in United States), transformation
> of vertical coordinates, _etc_. We can of course not list all possible
> formulas that we do not support, but this JIRA task lists at least some of
> the operations listed in the EPSG guidance notes.
> The main material for this work is the EPSG guidance notes, which can be
> downloaded freely from the following site:
> {panel}
> IOGP Publication 373-7-2 – Geomatics Guidance Note number 7, part 2
> Coordinate Conversions and Transformations including Formulas
> http://www.epsg.org/GuidanceNotes
> {panel}
> Google summer of code students interested in this work would need to be
> reasonably comfortable with the Java language (but not necessarily with the
> JDK library at large, since this work uses relatively few JDK classes outside
> {{Math}}), and in mathematic. In particular, this work requires a good
> understanding of _affine transforms_: their representation as a matrix, and
> how to map a term in a formula to a coefficient in the affine transform
> matrix.
> Apache SIS has one advanced feature which is not easily found in popular
> geospatial software or text books: the capability to compute the _derivative_
> (or more precisely, the _Jacobian_) of a transformation at a given point.
> Implementation of this feature requires the capability to find the analytic
> derivative of a non-linear formula and to simplify it.
> Implementations of those formulas take place in one of the
> {{org.apache.sis.referencing.operation}} sub-packages ({{projection}} or
> {{transform}}). Implementations of JUnit test happen partially in Apache SIS,
> and partially in the ["conformance module" of the GeoAPI
> project|http://www.geoapi.org/geoapi-conformance/index.html], if possible
> through the Geospatial Integrity of Geoscience Software (GIGS) tests.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (SIS-349) Dead-lock between ContextualParameters and WeakHashSet
[
https://issues.apache.org/jira/browse/SIS-349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux resolved SIS-349.
-
Resolution: Fixed
> Dead-lock between ContextualParameters and WeakHashSet
> --
>
> Key: SIS-349
> URL: https://issues.apache.org/jira/browse/SIS-349
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Referencing
>Affects Versions: 0.6, 0.7
>Reporter: Johann Sorel
>Assignee: Martin Desruisseaux
> Fix For: 0.8
>
>
> Below are thread-dump of relevant parts. The first parts is in the thread
> that verifies if an existing map projection exists in the {{WeakHashSet}}.
> This verification implies {{NormalizedProjection}} comparisons, which
> themselves imply {{ContextualParameters}} comparisons:
> {noformat}
> "Thread-3407" #3588 daemon prio=5 os_prio=0 tid=0x7f7951adf000 nid=0x5836
> waiting for monitor entry [0x7f78744ef000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at
> org.apache.sis.referencing.operation.transform.ContextualParameters.equals(ContextualParameters.java:720)
> - waiting to lock <0x0007818ef028> (a
> org.apache.sis.referencing.operation.transform.ContextualParameters)
> at java.util.Arrays.deepEquals0(Arrays.java:4299)
> at java.util.Objects.deepEquals(Objects.java:85)
> at org.apache.sis.util.Utilities.deepEquals(Utilities.java:200)
> at
> org.apache.sis.referencing.operation.transform.AbstractMathTransform.equals(AbstractMathTransform.java:921)
> at
> org.apache.sis.referencing.operation.projection.NormalizedProjection.equals(NormalizedProjection.java:797)
> at org.apache.sis.util.Utilities.deepEquals(Utilities.java:143)
> at org.apache.sis.util.Utilities.equals(Utilities.java:238)
> at org.apache.sis.util.Utilities.deepEquals(Utilities.java:168)
> at
> org.apache.sis.referencing.operation.transform.ConcatenatedTransform.equals(ConcatenatedTransform.java:934)
> at
> org.apache.sis.referencing.operation.transform.AbstractMathTransform.equals(AbstractMathTransform.java:867)
> at org.apache.sis.util.collection.WeakHashSet.intern(WeakHashSet.java:315)
> at org.apache.sis.util.collection.WeakHashSet.unique(WeakHashSet.java:290)
> - locked <0x000704b65b40> (a
> org.apache.sis.util.collection.WeakHashSet)
> at
> org.apache.sis.referencing.operation.transform.DefaultMathTransformFactory.unique(DefaultMathTransformFactory.java:1372)
> {noformat}
> The second part is in the thread that creates a new map projection, which
> implies operations on {{ContextualParameters}}.
> {noformat}
> "Thread-3409" #3590 daemon prio=5 os_prio=0 tid=0x7f7824cfd000 nid=0x5838
> waiting for monitor entry [0x7f7819e6e000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at org.apache.sis.util.collection.WeakHashSet.unique(WeakHashSet.java:290)
> - waiting to lock <0x000704b65b40> (a
> org.apache.sis.util.collection.WeakHashSet)
> at
> org.apache.sis.referencing.operation.transform.DefaultMathTransformFactory.unique(DefaultMathTransformFactory.java:1372)
> at
> org.apache.sis.referencing.operation.transform.DefaultMathTransformFactory.createConcatenatedTransform(DefaultMathTransformFactory.java:1256)
> at
> org.apache.sis.referencing.operation.transform.ContextualParameters.completeTransform(ContextualParameters.java:522)
> - locked <0x0007818ef028> (a
> org.apache.sis.referencing.operation.transform.ContextualParameters)
> at
> org.apache.sis.referencing.operation.projection.TransverseMercator.createMapProjection(TransverseMercator.java:301)
> at
> org.apache.sis.internal.referencing.provider.MapProjection.createMathTransform(MapProjection.java:199)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (SIS-349) Dead-lock between ContextualParameters and WeakHashSet
Martin Desruisseaux created SIS-349:
---
Summary: Dead-lock between ContextualParameters and WeakHashSet
Key: SIS-349
URL: https://issues.apache.org/jira/browse/SIS-349
Project: Spatial Information Systems
Issue Type: Bug
Components: Referencing
Affects Versions: 0.7, 0.6
Reporter: Johann Sorel
Assignee: Martin Desruisseaux
Fix For: 0.8
Below are thread-dump of relevant parts. The first parts is in the thread that
verifies if an existing map projection exists in the {{WeakHashSet}}. This
verification implies {{NormalizedProjection}} comparisons, which themselves
imply {{ContextualParameters}} comparisons:
{noformat}
"Thread-3407" #3588 daemon prio=5 os_prio=0 tid=0x7f7951adf000 nid=0x5836
waiting for monitor entry [0x7f78744ef000]
java.lang.Thread.State: BLOCKED (on object monitor)
at
org.apache.sis.referencing.operation.transform.ContextualParameters.equals(ContextualParameters.java:720)
- waiting to lock <0x0007818ef028> (a
org.apache.sis.referencing.operation.transform.ContextualParameters)
at java.util.Arrays.deepEquals0(Arrays.java:4299)
at java.util.Objects.deepEquals(Objects.java:85)
at org.apache.sis.util.Utilities.deepEquals(Utilities.java:200)
at
org.apache.sis.referencing.operation.transform.AbstractMathTransform.equals(AbstractMathTransform.java:921)
at
org.apache.sis.referencing.operation.projection.NormalizedProjection.equals(NormalizedProjection.java:797)
at org.apache.sis.util.Utilities.deepEquals(Utilities.java:143)
at org.apache.sis.util.Utilities.equals(Utilities.java:238)
at org.apache.sis.util.Utilities.deepEquals(Utilities.java:168)
at
org.apache.sis.referencing.operation.transform.ConcatenatedTransform.equals(ConcatenatedTransform.java:934)
at
org.apache.sis.referencing.operation.transform.AbstractMathTransform.equals(AbstractMathTransform.java:867)
at org.apache.sis.util.collection.WeakHashSet.intern(WeakHashSet.java:315)
at org.apache.sis.util.collection.WeakHashSet.unique(WeakHashSet.java:290)
- locked <0x000704b65b40> (a org.apache.sis.util.collection.WeakHashSet)
at
org.apache.sis.referencing.operation.transform.DefaultMathTransformFactory.unique(DefaultMathTransformFactory.java:1372)
{noformat}
The second part is in the thread that creates a new map projection, which
implies operations on {{ContextualParameters}}.
{noformat}
"Thread-3409" #3590 daemon prio=5 os_prio=0 tid=0x7f7824cfd000 nid=0x5838
waiting for monitor entry [0x7f7819e6e000]
java.lang.Thread.State: BLOCKED (on object monitor)
at org.apache.sis.util.collection.WeakHashSet.unique(WeakHashSet.java:290)
- waiting to lock <0x000704b65b40> (a
org.apache.sis.util.collection.WeakHashSet)
at
org.apache.sis.referencing.operation.transform.DefaultMathTransformFactory.unique(DefaultMathTransformFactory.java:1372)
at
org.apache.sis.referencing.operation.transform.DefaultMathTransformFactory.createConcatenatedTransform(DefaultMathTransformFactory.java:1256)
at
org.apache.sis.referencing.operation.transform.ContextualParameters.completeTransform(ContextualParameters.java:522)
- locked <0x0007818ef028> (a
org.apache.sis.referencing.operation.transform.ContextualParameters)
at
org.apache.sis.referencing.operation.projection.TransverseMercator.createMapProjection(TransverseMercator.java:301)
at
org.apache.sis.internal.referencing.provider.MapProjection.createMathTransform(MapProjection.java:199)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (SIS-220) Transverse Mercator Zoned Grid System (EPSG:9824)
[
https://issues.apache.org/jira/browse/SIS-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux resolved SIS-220.
-
Resolution: Fixed
Fix Version/s: 0.8
> Transverse Mercator Zoned Grid System (EPSG:9824)
> -
>
> Key: SIS-220
> URL: https://issues.apache.org/jira/browse/SIS-220
> Project: Spatial Information Systems
> Issue Type: Sub-task
> Components: Referencing
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Minor
> Fix For: 0.8
>
>
> This projection is basically the standard Transverse Mercator with a zone
> number prefixed in front of the Easting coordinates, with Z*1E6. See §1.3.5.2
> in IOGP Publication 373-7-2 – Geomatics Guidance Note number 7, part 2 –
> April 2015.
> This case should not be handled like other projection in SIS. It should
> instead be handled by a special {{MathTransform}} implementation, which is
> *not* a {{NormalizedProjection}}, but would be pre-concatenated before the
> sequence of transforms (including the normalization matrix) that compute a
> Transverse Mercator projection.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (SIS-220) Transverse Mercator Zoned Grid System (EPSG:9824)
[
https://issues.apache.org/jira/browse/SIS-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux reassigned SIS-220:
---
Assignee: Martin Desruisseaux
> Transverse Mercator Zoned Grid System (EPSG:9824)
> -
>
> Key: SIS-220
> URL: https://issues.apache.org/jira/browse/SIS-220
> Project: Spatial Information Systems
> Issue Type: Sub-task
> Components: Referencing
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Minor
>
> This projection is basically the standard Transverse Mercator with a zone
> number prefixed in front of the Easting coordinates, with Z*1E6. See §1.3.5.2
> in IOGP Publication 373-7-2 – Geomatics Guidance Note number 7, part 2 –
> April 2015.
> This case should not be handled like other projection in SIS. It should
> instead be handled by a special {{MathTransform}} implementation, which is
> *not* a {{NormalizedProjection}}, but would be pre-concatenated before the
> sequence of transforms (including the normalization matrix) that compute a
> Transverse Mercator projection.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (SIS-348) CompoundFormat.parse(CharSequence text, ParsePosition pos) javadoc is inconsistent with implementation
[
https://issues.apache.org/jira/browse/SIS-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux resolved SIS-348.
-
Resolution: Fixed
> CompoundFormat.parse(CharSequence text, ParsePosition pos) javadoc is
> inconsistent with implementation
> --
>
> Key: SIS-348
> URL: https://issues.apache.org/jira/browse/SIS-348
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 0.3, 0.4, 0.5, 0.6, 0.7
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Fix For: 0.8
>
>
> In the {{CompoundFormat}} class, the Javadoc of following method give a
> description of {{ParseException.getErrorOffset()}} value which is
> inconsistent with what most Apache SIS implementations actually do:
> {code:java}
> public abstract T parse(CharSequence text, ParsePosition pos) throws
> ParseException;
> {code}
> The current specification of above method is more convolved than what we
> usually expect from a method throwing {{ParseException}}. It said that the
> error offset of the exception is relative to the error index of the
> {{ParsePosition}}. But the {{TreeTableFormat}} subclass is the only one to
> follow that specification; all other subclasses apply the more usual and
> straightforward interpretation where {{ParseException.getErrorOffset()}}
> gives directly the index where parsing error occurred.
> Instead than modifying {{WKTFormat}} - which is a much more sensitive
> subclass than {{TreeTableFormat}}, we should rather modify the
> {{CompoundFormat.parse(CharSequence, ParsePosition)}} specification for
> making it less surprising and adapt {{TreeTableFormat}} accordingly.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (SIS-348) CompoundFormat.parse(CharSequence text, ParsePosition pos) javadoc is inconsistent with implementation
Martin Desruisseaux created SIS-348:
---
Summary: CompoundFormat.parse(CharSequence text, ParsePosition
pos) javadoc is inconsistent with implementation
Key: SIS-348
URL: https://issues.apache.org/jira/browse/SIS-348
Project: Spatial Information Systems
Issue Type: Bug
Components: Utilities
Affects Versions: 0.7, 0.6, 0.5, 0.4, 0.3
Reporter: Martin Desruisseaux
Assignee: Martin Desruisseaux
Fix For: 0.8
In the {{CompoundFormat}} class, the Javadoc of following method give a
description of {{ParseException.getErrorOffset()}} value which is inconsistent
with what most Apache SIS implementations actually do:
{code:java}
public abstract T parse(CharSequence text, ParsePosition pos) throws
ParseException;
{code}
The current specification of above method is more convolved than what we
usually expect from a method throwing {{ParseException}}. It said that the
error offset of the exception is relative to the error index of the
{{ParsePosition}}. But the {{TreeTableFormat}} subclass is the only one to
follow that specification; all other subclasses apply the more usual and
straightforward interpretation where {{ParseException.getErrorOffset()}} gives
directly the index where parsing error occurred.
Instead than modifying {{WKTFormat}} - which is a much more sensitive subclass
than {{TreeTableFormat}}, we should rather modify the
{{CompoundFormat.parse(CharSequence, ParsePosition)}} specification for making
it less surprising and adapt {{TreeTableFormat}} accordingly.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] (SIS-337) Package EPSG Derby DB in sis-epsg jar, eliminating the need for external SIS_DATA dir
[ https://issues.apache.org/jira/browse/SIS-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux updated SIS-337: Fix Version/s: 0.8 > Package EPSG Derby DB in sis-epsg jar, eliminating the need for external > SIS_DATA dir > -- > > Key: SIS-337 > URL: https://issues.apache.org/jira/browse/SIS-337 > Project: Spatial Information Systems > Issue Type: Wish > Components: Referencing >Affects Versions: 0.7 >Reporter: Kevin Mehall > Fix For: 0.8 > > > Since [Derby > supports|https://db.apache.org/derby/docs/10.7/devguide/cdevdeploy11201.html] > read-only databases in .jar files, is there a reason that the > `org.apache.sis.non-free:sis-epsg` package includes SQL source to create an > external database, rather than the database itself? > It would make deployment much easier if there were no need for a SIS_DATA > directory and environment variable, and adding the dependency were the only > thing necessary. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (SIS-337) Package EPSG Derby DB in sis-epsg jar, eliminating the need for external SIS_DATA dir
[
https://issues.apache.org/jira/browse/SIS-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15840132#comment-15840132
]
Martin Desruisseaux commented on SIS-337:
-
In order to try to address the need better, I would like to know: for
applications that need an embedded EPSG database, is there a need for the full
EPSG database or do such applications typically know in advance the EPSG codes
they are interested on?
I was wondering if it would be useful to have a mechanism like that (the
{{@PrefetchCRS}} annotation does not exist yet - this part of the proposal for
which I would like to evaluate the interest):
{code:java}
@PrefetchCRS("EPSG:3395")
CoordinateReferenceSystem myCRS;
{code}
An annotation processing tool provided by Apache SIS would inject automatically
the necessary code for initializing {{myCRS}} to the EPSG:3395 Coordinate
Reference System. The developer would need the EPSG database at build time, but
not at runtime; the CRS definition would be copied for example using Java
object serialization. If there is any {{CoordinateOperation}} explicitly
defined in the EPSG database for some pair of CRS declared in different
{{@PrefetchCRS}} annotation, they would also be copied.
Of course this approach would be useful only if an application is interest in a
relatively small set of CRS known at build time.
> Package EPSG Derby DB in sis-epsg jar, eliminating the need for external
> SIS_DATA dir
> --
>
> Key: SIS-337
> URL: https://issues.apache.org/jira/browse/SIS-337
> Project: Spatial Information Systems
> Issue Type: Wish
> Components: Referencing
>Affects Versions: 0.7
>Reporter: Kevin Mehall
>
> Since [Derby
> supports|https://db.apache.org/derby/docs/10.7/devguide/cdevdeploy11201.html]
> read-only databases in .jar files, is there a reason that the
> `org.apache.sis.non-free:sis-epsg` package includes SQL source to create an
> external database, rather than the database itself?
> It would make deployment much easier if there were no need for a SIS_DATA
> directory and environment variable, and adding the dependency were the only
> thing necessary.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SIS-347) Extents.area(GeographicBoundingBox) returns 0 if the longitude range is 360° large.
[
https://issues.apache.org/jira/browse/SIS-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux resolved SIS-347.
-
Resolution: Fixed
Fixed as of revision 1779003.
> Extents.area(GeographicBoundingBox) returns 0 if the longitude range is 360°
> large.
> ---
>
> Key: SIS-347
> URL: https://issues.apache.org/jira/browse/SIS-347
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Metadata
>Affects Versions: 0.4, 0.5, 0.6, 0.7
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Fix For: 0.8
>
>
> Steps to reproduce:
> {code:java}
> DefaultGeographicBoundingBox box = new DefaultGeographicBoundingBox();
> box.setBounds(-180, +180, -90, 90);
> System.out.println(Extents.area(box));
> {code}
> The above computes zero with SIS 0.7. The reason is in the line that take in
> account boxes crossing the anti-meridian; the span reduction performed there
> is a little bit too much aggressive.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SIS-347) Extents.area(GeographicBoundingBox) returns 0 if the longitude range is 360° large.
Martin Desruisseaux created SIS-347:
---
Summary: Extents.area(GeographicBoundingBox) returns 0 if the
longitude range is 360° large.
Key: SIS-347
URL: https://issues.apache.org/jira/browse/SIS-347
Project: Spatial Information Systems
Issue Type: Bug
Components: Metadata
Affects Versions: 0.7, 0.6, 0.5, 0.4
Reporter: Martin Desruisseaux
Assignee: Martin Desruisseaux
Fix For: 0.8
Steps to reproduce:
{code:java}
DefaultGeographicBoundingBox box = new DefaultGeographicBoundingBox();
box.setBounds(-180, +180, -90, 90);
System.out.println(Extents.area(box));
{code}
The above computes zero with SIS 0.7. The reason is in the line that take in
account boxes crossing the anti-meridian; the span reduction performed there is
a little bit too much aggressive.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SIS-346) MetadataStandard.asValueMap(…) / asTreeTable(…) do not work if the argument implements more than one metadata interface
[
https://issues.apache.org/jira/browse/SIS-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux resolved SIS-346.
-
Resolution: Fixed
> MetadataStandard.asValueMap(…) / asTreeTable(…) do not work if the argument
> implements more than one metadata interface
> ---
>
> Key: SIS-346
> URL: https://issues.apache.org/jira/browse/SIS-346
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Metadata
>Affects Versions: 0.3, 0.4, 0.5, 0.6, 0.7
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Fix For: 0.8
>
>
> It is some time convenient to implement more than one interface by the same
> class. For example an implementation interested only in extents defined by
> geographic bounding boxes could implement
> {{org.opengis.metadata.extent.Extent}} and
> {{org.opengis.metadata.extent.GeographicBoundingBox}} by the same class.
> However in such cases, we get an ambiguity that prevent most
> {{StandardMetadata}} methods to work. For resolving the ambiguity, we need to
> tell which interface to reflect. This information is often known since the
> metadata is often a return value of some getter methods, so we can use the
> return type of the getter method for filtering the interface of interest
> among the set of interfaces implemented by the value.
> Example: if {{getExtent()}} and {{getGeographicBoundingBox()}} both return
> the same instance, but in the first case the method signature declare
> {{Extent}} as the return value and in the second case declare
> {{GeographicBoundingBox}} as the return value, we can use that information
> for showing only the relevant nodes in a metadata tree.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SIS-346) MetadataStandard.asValueMap(…) / asTreeTable(…) do not work if the argument implements more than one metadata interface
Martin Desruisseaux created SIS-346:
---
Summary: MetadataStandard.asValueMap(…) / asTreeTable(…) do not
work if the argument implements more than one metadata interface
Key: SIS-346
URL: https://issues.apache.org/jira/browse/SIS-346
Project: Spatial Information Systems
Issue Type: Bug
Components: Metadata
Affects Versions: 0.7, 0.6, 0.5, 0.4, 0.3
Reporter: Martin Desruisseaux
Assignee: Martin Desruisseaux
Fix For: 0.8
It is some time convenient to implement more than one interface by the same
class. For example an implementation interested only in extents defined by
geographic bounding boxes could implement
{{org.opengis.metadata.extent.Extent}} and
{{org.opengis.metadata.extent.GeographicBoundingBox}} by the same class.
However in such cases, we get an ambiguity that prevent most
{{StandardMetadata}} methods to work. For resolving the ambiguity, we need to
tell which interface to reflect. This information is often known since the
metadata is often a return value of some getter methods, so we can use the
return type of the getter method for filtering the interface of interest among
the set of interfaces implemented by the value.
Example: if {{getExtent()}} and {{getGeographicBoundingBox()}} both return the
same instance, but in the first case the method signature declare {{Extent}} as
the return value and in the second case declare {{GeographicBoundingBox}} as
the return value, we can use that information for showing only the relevant
nodes in a metadata tree.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SIS-345) Upgrade JAXB binding to ISO 19115-3
Martin Desruisseaux created SIS-345:
---
Summary: Upgrade JAXB binding to ISO 19115-3
Key: SIS-345
URL: https://issues.apache.org/jira/browse/SIS-345
Project: Spatial Information Systems
Issue Type: Task
Components: Metadata
Affects Versions: 0.7
Reporter: Martin Desruisseaux
[ISO
19115-3|http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=32579]
has been published in August 2016. It replaces ISO 19139. This specification
defines the new XML representation of ISO 19115-1 metadata. We should update
JAXB annotations in all metadata classes accordingly. Steps to do are:
* For each {{org.apache.sis.metadata.iso.*}} package, change the value of
{{@XmlSchema}} annotation in {{package-info.java}} files.
* For each deprecated method, remove the {{@XmlElement}} annotation.
* For each class without {{@XmlRootElement}} annotation (i.e. new type
introduced by ISO 19115 revision):
** Add {{@XmlRootElement}} annotation.
** Add the corresponding adapter in {{org.apache.sis.internal.jaxb.metadata}}
package.
* For each getter method without {{@XmlElement}} annotation:
** Add {{@XmlElement}} annotation.
** Verify that the {{package-info.java}} file declares an adapter for the
method return type.
* Update XML test files.
For compatibility with older format, ISO provides XSLT:
* [Migrating
(overview)|https://github.com/ISO-TC211/XML/wiki/Migrating-ISO-19139-and-19139-2-to-19115-3]
* [XSLT files|http://standards.iso.org/iso/19115/resources/transforms/ISO19139]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SIS-344) Update EPSG geodetic dataset to version 9.0
Martin Desruisseaux created SIS-344:
---
Summary: Update EPSG geodetic dataset to version 9.0
Key: SIS-344
URL: https://issues.apache.org/jira/browse/SIS-344
Project: Spatial Information Systems
Issue Type: Task
Components: Referencing
Affects Versions: 0.7
Reporter: Martin Desruisseaux
Fix For: 0.8
EPSG geodetic dataset version 9.0 has been released on December 15, 2016. We
need to upgrade the {{org.apache.sis.non-free:sis-epsg}} Maven artifact
accordingly. Note that this version introduce 6 news definitions of WGS 84
geographic CRS.
This update included the following changes in the EPSG schema:
* Data declaration for the {{datum.realization_epoch}} attribute has been
changed from {{char(4)}} to {{char(10)}} to allow dates to be given to day
resolution.
* The length of abbreviations has been changed to a nominal maximum of 32
characters.
The {{Tables.sql}} file provided in SIS will need to be updated accordingly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SIS-343) Axis order reversal (EPSG:9843)
[ https://issues.apache.org/jira/browse/SIS-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux updated SIS-343: Summary: Axis order reversal (EPSG:9843) (was: Axis order reversal (EPSG::9843)) > Axis order reversal (EPSG:9843) > --- > > Key: SIS-343 > URL: https://issues.apache.org/jira/browse/SIS-343 > Project: Spatial Information Systems > Issue Type: Sub-task > Components: Referencing >Affects Versions: 0.7 >Reporter: Martin Desruisseaux >Assignee: Martin Desruisseaux >Priority: Minor > Fix For: 0.8 > > > This trivial coordinate operation method is not listed in the EPSG guidance > note, but nevertheless appear in EPSG geodetic dataset. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SIS-343) Axis order reversal (EPSG::9843)
Martin Desruisseaux created SIS-343: --- Summary: Axis order reversal (EPSG::9843) Key: SIS-343 URL: https://issues.apache.org/jira/browse/SIS-343 Project: Spatial Information Systems Issue Type: Sub-task Components: Referencing Affects Versions: 0.7 Reporter: Martin Desruisseaux Assignee: Martin Desruisseaux Priority: Minor Fix For: 0.8 This trivial coordinate operation method is not listed in the EPSG guidance note, but nevertheless appear in EPSG geodetic dataset. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SIS-341) Support "crs-compound" in URLs
[
https://issues.apache.org/jira/browse/SIS-341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-341:
Description:
The {{CRS.forCode(String)}} method accepts URL in the {{crs}} space, like below:
{noformat}
http://www.opengis.net/def/crs/epsg/0/4326
{noformat}
We need to also accept URL in the {{crs-compound}} space, like below:
{noformat}
http://www.opengis.net/def/crs-compound?
1=http://http://www.opengis.net/def/crs/OGC/0/AnsiDate;
2=http://www.codes.wmo.int/GRIB2/table4.5/IsobaricSurface
{noformat}
It should be possible to use this kind of CRS in GML like below (example from
U.K. MetOffice):
{code:xml}
http://www.opengis.net/def/crs-compound?
1=http://http://www.opengis.net/def/crs/OGC/0/AnsiDate;
2=http://www.codes.wmo.int/GRIB2/table4.5/IsobaricSurface;
axisLabels="Time pressure" srsDimension="2">
{code}
was:
The {{CRS.forCode(String)}} method accepts URL in the {{crs}} space, like below:
{noformat}
http://www.opengis.net/def/crs/epsg/0/4326
{noformat}
We need to also accept URL in the {{crs-compound}} space, like below:
{noformat}
http://www.opengis.net/def/crs-compound?
1=http://http://www.opengis.net/def/crs/OGC/0/AnsiDate;
2=http://www.codes.wmo.int/GRIB2/table4.5/IsobaricSurface
{noformat}
> Support "crs-compound" in URLs
> --
>
> Key: SIS-341
> URL: https://issues.apache.org/jira/browse/SIS-341
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Referencing
>Affects Versions: 0.7
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Fix For: 0.8
>
>
> The {{CRS.forCode(String)}} method accepts URL in the {{crs}} space, like
> below:
> {noformat}
> http://www.opengis.net/def/crs/epsg/0/4326
> {noformat}
> We need to also accept URL in the {{crs-compound}} space, like below:
> {noformat}
> http://www.opengis.net/def/crs-compound?
> 1=http://http://www.opengis.net/def/crs/OGC/0/AnsiDate;
> 2=http://www.codes.wmo.int/GRIB2/table4.5/IsobaricSurface
> {noformat}
> It should be possible to use this kind of CRS in GML like below (example from
> U.K. MetOffice):
> {code:xml}
> http://www.opengis.net/def/crs-compound?
>
> 1=http://http://www.opengis.net/def/crs/OGC/0/AnsiDate;
>
> 2=http://www.codes.wmo.int/GRIB2/table4.5/IsobaricSurface;
> axisLabels="Time pressure" srsDimension="2">
> upperBound="PT48H" />
> upperBound="200.00" />
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SIS-342) Support temporal CRS in URL
Martin Desruisseaux created SIS-342:
---
Summary: Support temporal CRS in URL
Key: SIS-342
URL: https://issues.apache.org/jira/browse/SIS-342
Project: Spatial Information Systems
Issue Type: Improvement
Components: Referencing
Affects Versions: 0.7, 0.6
Reporter: Martin Desruisseaux
Assignee: Martin Desruisseaux
Fix For: 0.8
The {{CRS.forCode(String)}} method supports CRS defined in the OGC namespace,
but currently only for geographic or projected CRS. We need to support also
temporal CRS like below:
{noformat}
http://http://www.opengis.net/def/crs/OGC/0/AnsiDate
{noformat}
Candidates for inclusion are:
* AnsiDate
* JulianDate
* TruncatedJulianDate
* UnixTime
* ChronometricGeologicTime
The list can be viewed from http://www.opengis.net/def/crs/OGC/0.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SIS-340) Support coordinate transformations between ParametricCRS and VerticalCRS
Martin Desruisseaux created SIS-340:
---
Summary: Support coordinate transformations between ParametricCRS
and VerticalCRS
Key: SIS-340
URL: https://issues.apache.org/jira/browse/SIS-340
Project: Spatial Information Systems
Issue Type: Improvement
Components: Referencing
Affects Versions: 0.7
Reporter: Martin Desruisseaux
{{ParametricCRS}} are used for elevations measured by a pressure, while
{{VerticalCRS}} are used for elevations measured in metres (or other linear
units). There is currently no mechanism for performing coordinate
transformations between those two kind of measurements. We need to implement a
mechanism which allow users to plug-in their transformations. This will require
user-provided data, for example pressure at ground level, that may change at
every instant. We may consider leveraging the "dynamic datum" mechanism under
discussion (as of November 2016) for ISO 19111 revision.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SIS-339) Feature attribute should verify the CRS of geometric value
Martin Desruisseaux created SIS-339:
---
Summary: 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
Reporter: Martin Desruisseaux
Priority: Minor
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
(v6.3.4#6332)
[jira] [Created] (SIS-338) Stores pre-defined metadata in the SpatialMetadata database
Martin Desruisseaux created SIS-338:
---
Summary: Stores pre-defined metadata in the SpatialMetadata
database
Key: SIS-338
URL: https://issues.apache.org/jira/browse/SIS-338
Project: Spatial Information Systems
Issue Type: Improvement
Components: Metadata
Affects Versions: 0.7, 0.6, 0.5, 0.4, 0.3
Reporter: Martin Desruisseaux
Assignee: Martin Desruisseaux
Fix For: 0.8
Apache SIS has some pre-defined metadata constants. In particular, the
{{Citation}} class from ISO 19115 is often used for specifying the organization
that defines Coordinate Reference System codes (EPSG, OGC, _etc._). Currently,
we have a {{Citation EPSG}} constant with hard-coded properties like title,
alternate title, URL, responsible party, _etc._, a {{Citation OGC}} constant
with similar properties, and so one for many constants. This is unconvenient to
program and quite incomplete since we do not provide all information that we
have.
The problem become more acute as we progress in the development of
{{sis-earth-observation}} module, which also has hard coded metadata. For
example Landsat 8 needs the description of 11 bands, and those bands are only
partially described in the Landsat file that we parse. The remaining (e.g. the
actual wavelength that we are measuring) must be hard-coded in our Landsat
metadata reader. The ability to provides those information in a database would
be convenient.
This approach is expected to be let more useful when we will parse data from
the World Meteorological Organization (WMO), which make extensive use of large
table. The NetCDF format too have a list of standardized phenomenon names. All
those things are natural candidates for inclusion in a metadata database.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (SIS-328) EPSG factory on PostgreSQL fails because of missing cast
[
https://issues.apache.org/jira/browse/SIS-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-328.
---
> EPSG factory on PostgreSQL fails because of missing cast
>
>
> Key: SIS-328
> URL: https://issues.apache.org/jira/browse/SIS-328
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Referencing
>Affects Versions: 0.7
> Environment: PostgreSQL
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Fix For: 0.8
>
>
> The EPSG factory works as expected on Derby. But attempt to use the factory
> on PostgreSQL sometime produces the following error message:
> {noformat}
> ERROR: operator does not exist: epsg."CRS Kind" ~~ unknown
> SQL state: 42883
> Hint: No operator matches the given name and argument type(s). You might need
> to add explicit type casts.
> {noformat}
> The issue occurs in expressions like {{coord_ref_sys_kind LIKE 'projected%'}}
> with the {{coord_ref_sys_kind}} column defined as an enum when Apache SIS is
> using PostgreSQL. The fix is to cast the {{CRS Kind}} enum to
> {{VARCHAR(24)}}. The bug does not happen in Derby because that column is
> already a {{VARCHAR(24)}} since Derby does not support enums.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (SIS-332) Upgrade Java platform requirement from JDK6 to JDK7
[
https://issues.apache.org/jira/browse/SIS-332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-332.
---
> Upgrade Java platform requirement from JDK6 to JDK7
> ---
>
> Key: SIS-332
> URL: https://issues.apache.org/jira/browse/SIS-332
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Build process, Command line, Documentation, Features,
> Metadata, Referencing, Shapefile, Storage, Utilities, Web services, Web site
>Affects Versions: 0.7
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Fix For: 0.8
>
>
> The replacement of JSR-275 dependency by
> [JSR-363|https://jcp.org/en/jsr/detail?id=363] (Unit of Measurement)
> introduces a dependency to JDK7. Consequently we should upgrade the whole
> Apache SIS project to JDK7. This allows (among other) the use of
> try-with-resources, multi-catches, switch on strings, diamond operator and
> use of {{java.nio.file}} API. Those changes can be identified relatively
> easily by comparing the JDK6 and JDK7 branches. After the upgrade, the JDK6
> branch will be deleted.
> This upgrade has been [proposed on the developer mailing
> list|https://lists.apache.org/thread.html/b012cc4f4497aab823328ebb2fad626bf8b8c12d40e6e3959ea7784a@%3Cdev.sis.apache.org%3E].
> The Subversion command to execute on trunk is:
> {noformat}
> svn merge https://svn.apache.org/repos/asf/sis/branches/JDK6/core@1758915 \
> https://svn.apache.org/repos/asf/sis/branches/JDK7/core@1758915 .
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SIS-131) Database backend for CRS definitions
[ https://issues.apache.org/jira/browse/SIS-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux updated SIS-131: Affects Version/s: 0.3 0.4 0.5 0.6 > Database backend for CRS definitions > > > Key: SIS-131 > URL: https://issues.apache.org/jira/browse/SIS-131 > Project: Spatial Information Systems > Issue Type: New Feature > Components: Referencing >Affects Versions: 0.4, 0.5, 0.6 >Reporter: Martin Desruisseaux >Assignee: Martin Desruisseaux >Priority: Critical > Fix For: 0.7 > > > We will need some kind of database for holding the Coordinate Reference > Systems (CRS) definitions. The main source of CRS definitions is the EPSG > database (http://www.epsg.org), which provide their definitions as SQL > scripts. The proposal is to use the database created by those scripts > directly. We propose to support at least the following engine: > * Apache Derby (http://db.apache.org/derby) > * HSQL (http://hsqldb.org) > * PostgreSQL (http://www.postgresql.org) > * Spark (http://spark.incubator.apache.org) > * MS-Access (actually the original EPSG format) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SIS-131) Database backend for CRS definitions
[ https://issues.apache.org/jira/browse/SIS-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux updated SIS-131: Affects Version/s: (was: 0.3) > Database backend for CRS definitions > > > Key: SIS-131 > URL: https://issues.apache.org/jira/browse/SIS-131 > Project: Spatial Information Systems > Issue Type: New Feature > Components: Referencing >Affects Versions: 0.4, 0.5, 0.6 >Reporter: Martin Desruisseaux >Assignee: Martin Desruisseaux >Priority: Critical > Fix For: 0.7 > > > We will need some kind of database for holding the Coordinate Reference > Systems (CRS) definitions. The main source of CRS definitions is the EPSG > database (http://www.epsg.org), which provide their definitions as SQL > scripts. The proposal is to use the database created by those scripts > directly. We propose to support at least the following engine: > * Apache Derby (http://db.apache.org/derby) > * HSQL (http://hsqldb.org) > * PostgreSQL (http://www.postgresql.org) > * Spark (http://spark.incubator.apache.org) > * MS-Access (actually the original EPSG format) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SIS-337) Package EPSG Derby DB in sis-epsg jar, eliminating the need for external SIS_DATA dir
[ https://issues.apache.org/jira/browse/SIS-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux updated SIS-337: Affects Version/s: 0.7 Description: Since [Derby supports|https://db.apache.org/derby/docs/10.7/devguide/cdevdeploy11201.html] read-only databases in .jar files, is there a reason that the `org.apache.sis.non-free:sis-epsg` package includes SQL source to create an external database, rather than the database itself? It would make deployment much easier if there were no need for a SIS_DATA directory and environment variable, and adding the dependency were the only thing necessary. was: Since [Derby supports](https://db.apache.org/derby/docs/10.7/devguide/cdevdeploy11201.html) read-only databases in .jar files, is there a reason that the `org.apache.sis.non-free:sis-epsg` package includes SQL source to create an external database, rather than the database itself? It would make deployment much easier if there were no need for a SIS_DATA directory and environment variable, and adding the dependency were the only thing necessary. Component/s: Referencing > Package EPSG Derby DB in sis-epsg jar, eliminating the need for external > SIS_DATA dir > -- > > Key: SIS-337 > URL: https://issues.apache.org/jira/browse/SIS-337 > Project: Spatial Information Systems > Issue Type: Wish > Components: Referencing >Affects Versions: 0.7 >Reporter: Kevin Mehall > > Since [Derby > supports|https://db.apache.org/derby/docs/10.7/devguide/cdevdeploy11201.html] > read-only databases in .jar files, is there a reason that the > `org.apache.sis.non-free:sis-epsg` package includes SQL source to create an > external database, rather than the database itself? > It would make deployment much easier if there were no need for a SIS_DATA > directory and environment variable, and adding the dependency were the only > thing necessary. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SIS-337) Package EPSG Derby DB in sis-epsg jar, eliminating the need for external SIS_DATA dir
[
https://issues.apache.org/jira/browse/SIS-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15687785#comment-15687785
]
Martin Desruisseaux commented on SIS-337:
-
Right, the EPSG geodetic dataset could be embedded in a JAR file. It was not
done yet because the {{SIS_DATA}} directory may contain not only the geodetic
dataset, but also the datum grid shift files and custom CRS definitions
provided by the users, among others. So {{SIS-DATA}} would be the central point
for all those kinds of data. However I agree that a lot of users will want only
the EPSG geodetic dataset.
> Package EPSG Derby DB in sis-epsg jar, eliminating the need for external
> SIS_DATA dir
> --
>
> Key: SIS-337
> URL: https://issues.apache.org/jira/browse/SIS-337
> Project: Spatial Information Systems
> Issue Type: Wish
>Reporter: Kevin Mehall
>
> Since [Derby
> supports](https://db.apache.org/derby/docs/10.7/devguide/cdevdeploy11201.html)
> read-only databases in .jar files, is there a reason that the
> `org.apache.sis.non-free:sis-epsg` package includes SQL source to create an
> external database, rather than the database itself?
> It would make deployment much easier if there were no need for a SIS_DATA
> directory and environment variable, and adding the dependency were the only
> thing necessary.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SIS-336) URL to EPSG installation instructions should be customizable
Martin Desruisseaux created SIS-336: --- Summary: 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 Reporter: Martin Desruisseaux Priority: Minor Fix For: 0.8 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 (v6.3.4#6332)
[jira] [Resolved] (SIS-333) In GML, the second defining parameter of spheres should be true
[
https://issues.apache.org/jira/browse/SIS-333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux resolved SIS-333.
-
Resolution: Fixed
Fixed at revision 1768119.
> In GML, the second defining parameter of spheres should be
> true
>
>
> Key: SIS-333
> URL: https://issues.apache.org/jira/browse/SIS-333
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Referencing
>Affects Versions: 0.4, 0.5, 0.6, 0.7
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Minor
> Fix For: 0.8
>
>
> Currently, Apache SIS marshals the XML representation of the EPSG:7048
> ellipsoid (_"GRS 1980 Authalic Sphere"_) as below (extract):
> {code:xml}
> uom="urn:ogc:def:uom:EPSG::9001">6371007
>
>
> uom="urn:ogc:def:uom:EPSG::9001">6371007
>
>
> {code}
> This is not wrong, but the GML way would rather be:
> {code:xml}
> uom="urn:ogc:def:uom:EPSG::9001">6371007
>
>
> true
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SIS-333) In GML, the second defining parameter of spheres should be true
[
https://issues.apache.org/jira/browse/SIS-333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-333:
Description:
Currently, Apache SIS marshals the XML representation of the EPSG:7048
ellipsoid (_"GRS 1980 Authalic Sphere"_) as below (extract):
{code:xml}
6371007
6371007
{code}
This is not wrong, but the GML way would rather be:
{code:xml}
6371007
true
{code}
was:
Currently, Apache SIS marshals the XML representation of the EPSG:7048
ellipsoid (_"GRS 1980 Authalic Sphere"_) as below (extract):
{code:xml}
6371007
6371007
{code}
This is not wrong, but the GML way would rather be:
{code:xml}
6371007
true
{code}
> In GML, the second defining parameter of spheres should be
> true
>
>
> Key: SIS-333
> URL: https://issues.apache.org/jira/browse/SIS-333
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Referencing
>Affects Versions: 0.4, 0.5, 0.6, 0.7
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
>Priority: Minor
> Fix For: 0.8
>
>
> Currently, Apache SIS marshals the XML representation of the EPSG:7048
> ellipsoid (_"GRS 1980 Authalic Sphere"_) as below (extract):
> {code:xml}
> uom="urn:ogc:def:uom:EPSG::9001">6371007
>
>
> uom="urn:ogc:def:uom:EPSG::9001">6371007
>
>
> {code}
> This is not wrong, but the GML way would rather be:
> {code:xml}
> uom="urn:ogc:def:uom:EPSG::9001">6371007
>
>
> true
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SIS-335) CRS.findOperation(…) sometime slow
[
https://issues.apache.org/jira/browse/SIS-335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux resolved SIS-335.
-
Resolution: Fixed
Fixed as of revision 1768057.
> CRS.findOperation(…) sometime slow
> --
>
> Key: SIS-335
> URL: https://issues.apache.org/jira/browse/SIS-335
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Referencing
>Affects Versions: 0.7
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Fix For: 0.8
>
>
> Execution of {{CRS.findOperation(sourceCRS, targetCRS, areaOfInterest)}} is
> slow when:
> * A connection to the EPSG geodetic dataset is available (which is
> recommended)
> * the given CRS have no EPSG identifiers, or their identifiers are wrong
> In such case, {{IdentifiedObjectFinder}} search the right EPSG code for the
> given CRS by scanning the EPSG database. Some conditions are put in the SQL
> {{WHERE}} clause for reducing the amount of CRS to scan, but in Apache SIS
> 0.7 those conditions are not restrictive enough, resulting in way too many
> CRS being scanned.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SIS-335) CRS.findOperation(…) sometime slow
Martin Desruisseaux created SIS-335:
---
Summary: CRS.findOperation(…) sometime slow
Key: SIS-335
URL: https://issues.apache.org/jira/browse/SIS-335
Project: Spatial Information Systems
Issue Type: Bug
Components: Referencing
Affects Versions: 0.7
Reporter: Martin Desruisseaux
Assignee: Martin Desruisseaux
Fix For: 0.8
Execution of {{CRS.findOperation(sourceCRS, targetCRS, areaOfInterest)}} is
slow when:
* A connection to the EPSG geodetic dataset is available (which is recommended)
* the given CRS have no EPSG identifiers, or their identifiers are wrong
In such case, {{IdentifiedObjectFinder}} search the right EPSG code for the
given CRS by scanning the EPSG database. Some conditions are put in the SQL
{{WHERE}} clause for reducing the amount of CRS to scan, but in Apache SIS 0.7
those conditions are not restrictive enough, resulting in way too many CRS
being scanned.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SIS-334) Replace JSR-275 dependency by JSR-363
[ https://issues.apache.org/jira/browse/SIS-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux resolved SIS-334. - Resolution: Fixed Merged on trunk as of revision 1767577. > Replace JSR-275 dependency by JSR-363 > - > > Key: SIS-334 > URL: https://issues.apache.org/jira/browse/SIS-334 > Project: Spatial Information Systems > Issue Type: Task > Components: Metadata, Referencing, Storage, Utilities >Affects Versions: 0.3, 0.4, 0.5, 0.6, 0.7 >Reporter: Martin Desruisseaux >Assignee: Martin Desruisseaux >Priority: Critical > Fix For: 0.8 > > > Apache SIS versions 0.3 to 0.7 inclusive depend on JSR-275, which has been > rejected by the Java Community Process (JCP). The replacement, JSR-363, is > now ready and officially released. We need to perform the replacement before > next SIS release. At first we need to replace all API usage, maybe using the > JSR-363 reference implementation as a starting point. In a second step, we > should use our own implementation for better support of NetCDF units, EPSG > unit codes, _etc_. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SIS-334) Replace JSR-275 dependency by JSR-363
[ https://issues.apache.org/jira/browse/SIS-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux updated SIS-334: Description: Apache SIS versions 0.3 to 0.7 inclusive depend on JSR-275, which has been rejected by the Java Community Process (JCP). The replacement, JSR-363, is now ready and officially released. We need to perform the replacement before next SIS release. At first we need to replace all API usage, maybe using the JSR-363 reference implementation as a starting point. In a second step, we should use our own implementation for better support of NetCDF units, EPSG unit codes, _etc_. (was: Apache SIS versions 0.3 to 0.7 inclusive depend on JSR-275, which has been rejected by the Java Community Process (JCP). The replacement, JSR-363, is now ready and officially released. We need to perform the replacement before next SIS release.) > Replace JSR-275 dependency by JSR-363 > - > > Key: SIS-334 > URL: https://issues.apache.org/jira/browse/SIS-334 > Project: Spatial Information Systems > Issue Type: Task > Components: Metadata, Referencing, Storage, Utilities >Affects Versions: 0.3, 0.4, 0.5, 0.6, 0.7 >Reporter: Martin Desruisseaux >Assignee: Martin Desruisseaux >Priority: Critical > Fix For: 0.8 > > > Apache SIS versions 0.3 to 0.7 inclusive depend on JSR-275, which has been > rejected by the Java Community Process (JCP). The replacement, JSR-363, is > now ready and officially released. We need to perform the replacement before > next SIS release. At first we need to replace all API usage, maybe using the > JSR-363 reference implementation as a starting point. In a second step, we > should use our own implementation for better support of NetCDF units, EPSG > unit codes, _etc_. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SIS-334) Replace JSR-275 dependency by JSR-363
Martin Desruisseaux created SIS-334: --- Summary: Replace JSR-275 dependency by JSR-363 Key: SIS-334 URL: https://issues.apache.org/jira/browse/SIS-334 Project: Spatial Information Systems Issue Type: Task Components: Metadata, Referencing, Storage, Utilities Affects Versions: 0.7, 0.6, 0.5, 0.4, 0.3 Reporter: Martin Desruisseaux Assignee: Martin Desruisseaux Priority: Critical Fix For: 0.8 Apache SIS versions 0.3 to 0.7 inclusive depends on JSR-275, which has been rejected by the Java Community Process (JCP). The replacement, JSR-363, is now ready and officially released. We need to perform the replacement before next SIS release. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SIS-334) Replace JSR-275 dependency by JSR-363
[ https://issues.apache.org/jira/browse/SIS-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux updated SIS-334: Description: Apache SIS versions 0.3 to 0.7 inclusive depend on JSR-275, which has been rejected by the Java Community Process (JCP). The replacement, JSR-363, is now ready and officially released. We need to perform the replacement before next SIS release. (was: Apache SIS versions 0.3 to 0.7 inclusive depends on JSR-275, which has been rejected by the Java Community Process (JCP). The replacement, JSR-363, is now ready and officially released. We need to perform the replacement before next SIS release.) > Replace JSR-275 dependency by JSR-363 > - > > Key: SIS-334 > URL: https://issues.apache.org/jira/browse/SIS-334 > Project: Spatial Information Systems > Issue Type: Task > Components: Metadata, Referencing, Storage, Utilities >Affects Versions: 0.3, 0.4, 0.5, 0.6, 0.7 >Reporter: Martin Desruisseaux >Assignee: Martin Desruisseaux >Priority: Critical > Fix For: 0.8 > > > Apache SIS versions 0.3 to 0.7 inclusive depend on JSR-275, which has been > rejected by the Java Community Process (JCP). The replacement, JSR-363, is > now ready and officially released. We need to perform the replacement before > next SIS release. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SIS-128) Implement the JSR-363 javax.measure interfaces
[ https://issues.apache.org/jira/browse/SIS-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux updated SIS-128: Fix Version/s: 0.8 > Implement the JSR-363 javax.measure interfaces > -- > > Key: SIS-128 > URL: https://issues.apache.org/jira/browse/SIS-128 > Project: Spatial Information Systems > Issue Type: Improvement > Components: Utilities >Affects Versions: 0.3, 0.4, 0.5, 0.6, 0.7 >Reporter: Martin Desruisseaux > Fix For: 0.8 > > > We needs an implementation of JSR-363 to be used as a replacement of JSR-275. > This is needed since the JSR-275 specification attempt has been rejected. > Some existing implementations exist, especially the UOMo and JScience > projects, but we also have some legacy classes that we could refactor. A > possible advantage of the later approach is that we have to support some > rather particular Unit, like the one used in NetCDF files (e.g. > "degrees_east"), which may be easier in a custom implementation. > Some useful links: > * http://www.unitsofmeasurement.org/apidocs/index.html - the interfaces that > we would have to implement. > * http://www.qudt.org/ - Quantities, Units, Dimensions and Data Types in OWL > and XML (ontology). > * https://code.google.com/p/unit-ontology/ - apparently the same than above. > * http://portal.opengeospatial.org/files/?artifact_id=11498 - OGC Best > Practice for specifying UoM in an OGC standard. > * > https://www.seegrid.csiro.au/subversion/xmml/OGC/trunk/ExampleInstances/dictionaries/units.xml > - a dictionary of unit symbols related to OGC standards. > * http://unitsofmeasure.org/trac/ - UCUM, a text format for units. > * https://github.com/keilw/mco - A Java script project derived from JSR-275. > * http://wiki.eclipse.org/Science_IWG - Open Source Initiative for Scientific > Development Tools. > * http://jscience.org/ - JScience, one of available implementations. > * http://www.eclipse.org/uomo/ - an other implementation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
