[jira] [Updated] (SIS-94) Update SIS to revision 2013 of the ISO 19115 standard
[
https://issues.apache.org/jira/browse/SIS-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-94:
---
Description:
One of Apache SIS goals is to comply with the ISO (_International Standards
Organization_) specifications. Compliance to international standards not only
increase inter-operability between products, but is also a legal requirement
for government agencies in the European Union since the INSPIRE directive from
the European Commission.
Apache SIS currently implements the ISO 19115 (_Geographic information -
Metadata_) standard, as published in 2003, completed by ISO 19115-2 published
in 2009. The ISO organization updates their standards once every 10 years. The
new ISO 19115 revision has been published in 2014 and is available there:
http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=53798
We need to update Apache SIS to make it compliant with the new ISO 19115
standards. Because Apache SIS implements the GeoAPI interfaces defined by the
Open Geospatial Consortium (OGC), this task will need to be done in cooperation
with the OGC GeoAPI working group. More specifically, the tasks will be (not
necessarily in that order - many tasks are expected to be done in parallel):
* On the OGC GeoAPI side ([GEO-232|http://jira.codehaus.org/browse/GEO-232]):
** Get legal copies of the new ISO 19115-1, -2, -3 and -4 standards (to be
provided by mentors).
** Review all classes, interfaces, fields and methods defined in the
{{org.opengis.metadata.*}} packages and compare them with the new definitions
provided in ISO 19115-1 and -2.
*** For every new elements added in ISO 19115-1/2, add the corresponding
elements in the Java interfaces.
*** For every elements removed from ISO 19115-1/2, deprecate the corresponding
elements in the Java interfaces.
*** Fix any discrepancies or errors which may be found on a case-by-case basis,
to be discussed on the GeoAPI mailing list.
*** Make sure that all elements have an up-to-date and accurate Javadoc.
** Update the GeoAPI specification with mentor help.
** Write test cases in the {{geoapi-conformance}} module.
* On the Apache SIS side:
** For all changes done in GeoAPI interface, reflect the changes in the Apache
SIS implementation in the {{org.apache.sis.metadata.iso.*}} packages.
** Add JAXB adapters for the new elements, or fix JAXB adapters for existing
elements, in order to marshal/unmarshall XML documents compliant with the new
standards as defined in ISO 19115-3 and -4.
** Check for any additional requirements defined by the INSPIRE directive.
** Ensure that Apache SIS passes the tests defined in GeoAPI.
** In collaboration with specialists, write some use cases and demos using the
new metadata objects.
Peoples who can help for this task are:
* Contributor of the Apache SIS metadata module and GeoAPI chairman (mentor).
* Authors of the MD-Web project and peoples working in remote-sensing (for more
metadata advice).
* Member of the OGC Architecture Board for help with OGC procedure.
* Some authors who contributed to the ISO 19115 revision.
was:
One of Apache SIS goals is to comply with the ISO (_International Standards
Organization_) specifications. Compliance to international standards not only
increase inter-operability between products, but is also a legal requirement
for government agencies in the European Union since the INSPIRE directive from
the European Commission.
Apache SIS currently implements the ISO 19115 (_Geographic information -
Metadata_) standard, as published in 2003, completed by ISO 19115-2 published
in 2009. The ISO organization updates their standards once every 10 years. The
new ISO 19115 revision is expected to be published around May 2013.
We will need to update Apache SIS to make it compliant with the new ISO 19115
standards. Because Apache SIS implements the GeoAPI interfaces defined by the
Open Geospatial Consortium (OGC), this task will need to be done in cooperation
with the OGC GeoAPI working group. More specifically, the tasks will be (not
necessarily in that order - many tasks are expected to be done in parallel):
* On the OGC GeoAPI side:
** Get legal copies of the new ISO 19115-1, -2, -3 and -4 standards (to be
provided by mentors).
** Review all classes, interfaces, fields and methods defined in the
{{org.opengis.metadata.*}} packages and compare them with the new definitions
provided in ISO 19115-1 and -2.
*** For every new elements added in ISO 19115-1/2, add the corresponding
elements in the Java interfaces.
*** For every elements removed from ISO 19115-1/2, deprecate the corresponding
elements in the Java interfaces.
*** Fix any discrepancies or errors which may be found on a case-by-case basis,
to be discussed on the GeoAPI mailing list.
*** Make sure that all elements have an up-to-date and accurate Javadoc.
** Update the GeoAPI specification with mentor
[jira] [Closed] (SIS-169) Upgrade metadata classes to the new ISO 19115:2014 revision
[ https://issues.apache.org/jira/browse/SIS-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux closed SIS-169. --- Resolution: Duplicate Assignee: Martin Desruisseaux Duplicate of SIS-94. > Upgrade metadata classes to the new ISO 19115:2014 revision > --- > > Key: SIS-169 > URL: https://issues.apache.org/jira/browse/SIS-169 > Project: Spatial Information Systems > Issue Type: Task > Components: Metadata >Reporter: Martin Desruisseaux >Assignee: Martin Desruisseaux > > ISO 19115:2014 has been published: > http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=53798 > We need to update the metadata classes accordingly. This work requires > upgrading the GeoAPI interfaces first > ([GEO-232|http://jira.codehaus.org/browse/GEO-232]). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Work started] (SIS-94) Update SIS to revision 2013 of the ISO 19115 standard
[
https://issues.apache.org/jira/browse/SIS-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on SIS-94 started by Martin Desruisseaux.
> Update SIS to revision 2013 of the ISO 19115 standard
> -
>
> Key: SIS-94
> URL: https://issues.apache.org/jira/browse/SIS-94
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Metadata
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Labels: gsoc2013
> Attachments: AbstractParty.java, DefaultAssociatedResource.java,
> DefaultConstraint.patch, DefaultDimension.patch, DefaultFeatureTypeInfo.java,
> DefaultGeoRectified.patch, DefaultMetadataScope.java,
> DefaultProcessStep.patch, DefaultReleasability.java,
> DefaultRepresentativeFraction.patch, DefaultResponsibility.java,
> defaultBrowseGraphic.patch, defaultGeoReferenceable.patch,
> defaultLineage.patch, defaultMaintenance.patch, defaultSource.patch,
> defaultUsage.patch
>
> Original Estimate: 1,344h
> Remaining Estimate: 1,344h
>
> One of Apache SIS goals is to comply with the ISO (_International Standards
> Organization_) specifications. Compliance to international standards not only
> increase inter-operability between products, but is also a legal requirement
> for government agencies in the European Union since the INSPIRE directive
> from the European Commission.
> Apache SIS currently implements the ISO 19115 (_Geographic information -
> Metadata_) standard, as published in 2003, completed by ISO 19115-2 published
> in 2009. The ISO organization updates their standards once every 10 years.
> The new ISO 19115 revision has been published in 2014 and is available there:
> http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=53798
> We need to update Apache SIS to make it compliant with the new ISO 19115
> standards. Because Apache SIS implements the GeoAPI interfaces defined by the
> Open Geospatial Consortium (OGC), this task will need to be done in
> cooperation with the OGC GeoAPI working group. More specifically, the tasks
> will be (not necessarily in that order - many tasks are expected to be done
> in parallel):
> * On the OGC GeoAPI side ([GEO-232|http://jira.codehaus.org/browse/GEO-232]):
> ** Get legal copies of the new ISO 19115-1, -2, -3 and -4 standards (to be
> provided by mentors).
> ** Review all classes, interfaces, fields and methods defined in the
> {{org.opengis.metadata.*}} packages and compare them with the new definitions
> provided in ISO 19115-1 and -2.
> *** For every new elements added in ISO 19115-1/2, add the corresponding
> elements in the Java interfaces.
> *** For every elements removed from ISO 19115-1/2, deprecate the
> corresponding elements in the Java interfaces.
> *** Fix any discrepancies or errors which may be found on a case-by-case
> basis, to be discussed on the GeoAPI mailing list.
> *** Make sure that all elements have an up-to-date and accurate Javadoc.
> ** Update the GeoAPI specification with mentor help.
> ** Write test cases in the {{geoapi-conformance}} module.
> * On the Apache SIS side:
> ** For all changes done in GeoAPI interface, reflect the changes in the
> Apache SIS implementation in the {{org.apache.sis.metadata.iso.*}} packages.
> ** Add JAXB adapters for the new elements, or fix JAXB adapters for existing
> elements, in order to marshal/unmarshall XML documents compliant with the new
> standards as defined in ISO 19115-3 and -4.
> ** Check for any additional requirements defined by the INSPIRE directive.
> ** Ensure that Apache SIS passes the tests defined in GeoAPI.
> ** In collaboration with specialists, write some use cases and demos using
> the new metadata objects.
> Peoples who can help for this task are:
> * Contributor of the Apache SIS metadata module and GeoAPI chairman (mentor).
> * Authors of the MD-Web project and peoples working in remote-sensing (for
> more metadata advice).
> * Member of the OGC Architecture Board for help with OGC procedure.
> * Some authors who contributed to the ISO 19115 revision.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (SIS-94) Update SIS to revision 2013 of the ISO 19115 standard
[
https://issues.apache.org/jira/browse/SIS-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-94:
---
Attachment: (was: DefaultGeoRectified.patch)
> Update SIS to revision 2013 of the ISO 19115 standard
> -
>
> Key: SIS-94
> URL: https://issues.apache.org/jira/browse/SIS-94
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Metadata
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Labels: gsoc2013
> Attachments: AbstractParty.java, DefaultAssociatedResource.java,
> DefaultAttributeGroup.java, DefaultConstraint.patch, DefaultDimension.patch,
> DefaultFeatureTypeInfo.java, DefaultMetadataScope.java,
> DefaultProcessStep.patch, DefaultReleasability.java,
> DefaultRepresentativeFraction.patch, DefaultResponsibility.java,
> defaultBrowseGraphic.patch, defaultGeoReferenceable.patch,
> defaultLineage.patch, defaultMaintenance.patch, defaultSource.patch,
> defaultUsage.patch
>
> Original Estimate: 1,344h
> Remaining Estimate: 1,344h
>
> One of Apache SIS goals is to comply with the ISO (_International Standards
> Organization_) specifications. Compliance to international standards not only
> increase inter-operability between products, but is also a legal requirement
> for government agencies in the European Union since the INSPIRE directive
> from the European Commission.
> Apache SIS currently implements the ISO 19115 (_Geographic information -
> Metadata_) standard, as published in 2003, completed by ISO 19115-2 published
> in 2009. The ISO organization updates their standards once every 10 years.
> The new ISO 19115 revision has been published in 2014 and is available there:
> http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=53798
> We need to update Apache SIS to make it compliant with the new ISO 19115
> standards. Because Apache SIS implements the GeoAPI interfaces defined by the
> Open Geospatial Consortium (OGC), this task will need to be done in
> cooperation with the OGC GeoAPI working group. More specifically, the tasks
> will be (not necessarily in that order - many tasks are expected to be done
> in parallel):
> * On the OGC GeoAPI side ([GEO-232|http://jira.codehaus.org/browse/GEO-232]):
> ** Get legal copies of the new ISO 19115-1, -2, -3 and -4 standards (to be
> provided by mentors).
> ** Review all classes, interfaces, fields and methods defined in the
> {{org.opengis.metadata.*}} packages and compare them with the new definitions
> provided in ISO 19115-1 and -2.
> *** For every new elements added in ISO 19115-1/2, add the corresponding
> elements in the Java interfaces.
> *** For every elements removed from ISO 19115-1/2, deprecate the
> corresponding elements in the Java interfaces.
> *** Fix any discrepancies or errors which may be found on a case-by-case
> basis, to be discussed on the GeoAPI mailing list.
> *** Make sure that all elements have an up-to-date and accurate Javadoc.
> ** Update the GeoAPI specification with mentor help.
> ** Write test cases in the {{geoapi-conformance}} module.
> * On the Apache SIS side:
> ** For all changes done in GeoAPI interface, reflect the changes in the
> Apache SIS implementation in the {{org.apache.sis.metadata.iso.*}} packages.
> ** Add JAXB adapters for the new elements, or fix JAXB adapters for existing
> elements, in order to marshal/unmarshall XML documents compliant with the new
> standards as defined in ISO 19115-3 and -4.
> ** Check for any additional requirements defined by the INSPIRE directive.
> ** Ensure that Apache SIS passes the tests defined in GeoAPI.
> ** In collaboration with specialists, write some use cases and demos using
> the new metadata objects.
> Peoples who can help for this task are:
> * Contributor of the Apache SIS metadata module and GeoAPI chairman (mentor).
> * Authors of the MD-Web project and peoples working in remote-sensing (for
> more metadata advice).
> * Member of the OGC Architecture Board for help with OGC procedure.
> * Some authors who contributed to the ISO 19115 revision.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (SIS-94) Update SIS to revision 2013 of the ISO 19115 standard
[
https://issues.apache.org/jira/browse/SIS-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-94:
---
Attachment: (was: defaultGeoReferenceable.patch)
> Update SIS to revision 2013 of the ISO 19115 standard
> -
>
> Key: SIS-94
> URL: https://issues.apache.org/jira/browse/SIS-94
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Metadata
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Labels: gsoc2013
> Attachments: AbstractParty.java, DefaultAssociatedResource.java,
> DefaultAttributeGroup.java, DefaultConstraint.patch, DefaultDimension.patch,
> DefaultFeatureTypeInfo.java, DefaultMetadataScope.java,
> DefaultProcessStep.patch, DefaultReleasability.java,
> DefaultRepresentativeFraction.patch, DefaultResponsibility.java,
> defaultBrowseGraphic.patch, defaultLineage.patch, defaultMaintenance.patch,
> defaultSource.patch, defaultUsage.patch
>
> Original Estimate: 1,344h
> Remaining Estimate: 1,344h
>
> One of Apache SIS goals is to comply with the ISO (_International Standards
> Organization_) specifications. Compliance to international standards not only
> increase inter-operability between products, but is also a legal requirement
> for government agencies in the European Union since the INSPIRE directive
> from the European Commission.
> Apache SIS currently implements the ISO 19115 (_Geographic information -
> Metadata_) standard, as published in 2003, completed by ISO 19115-2 published
> in 2009. The ISO organization updates their standards once every 10 years.
> The new ISO 19115 revision has been published in 2014 and is available there:
> http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=53798
> We need to update Apache SIS to make it compliant with the new ISO 19115
> standards. Because Apache SIS implements the GeoAPI interfaces defined by the
> Open Geospatial Consortium (OGC), this task will need to be done in
> cooperation with the OGC GeoAPI working group. More specifically, the tasks
> will be (not necessarily in that order - many tasks are expected to be done
> in parallel):
> * On the OGC GeoAPI side ([GEO-232|http://jira.codehaus.org/browse/GEO-232]):
> ** Get legal copies of the new ISO 19115-1, -2, -3 and -4 standards (to be
> provided by mentors).
> ** Review all classes, interfaces, fields and methods defined in the
> {{org.opengis.metadata.*}} packages and compare them with the new definitions
> provided in ISO 19115-1 and -2.
> *** For every new elements added in ISO 19115-1/2, add the corresponding
> elements in the Java interfaces.
> *** For every elements removed from ISO 19115-1/2, deprecate the
> corresponding elements in the Java interfaces.
> *** Fix any discrepancies or errors which may be found on a case-by-case
> basis, to be discussed on the GeoAPI mailing list.
> *** Make sure that all elements have an up-to-date and accurate Javadoc.
> ** Update the GeoAPI specification with mentor help.
> ** Write test cases in the {{geoapi-conformance}} module.
> * On the Apache SIS side:
> ** For all changes done in GeoAPI interface, reflect the changes in the
> Apache SIS implementation in the {{org.apache.sis.metadata.iso.*}} packages.
> ** Add JAXB adapters for the new elements, or fix JAXB adapters for existing
> elements, in order to marshal/unmarshall XML documents compliant with the new
> standards as defined in ISO 19115-3 and -4.
> ** Check for any additional requirements defined by the INSPIRE directive.
> ** Ensure that Apache SIS passes the tests defined in GeoAPI.
> ** In collaboration with specialists, write some use cases and demos using
> the new metadata objects.
> Peoples who can help for this task are:
> * Contributor of the Apache SIS metadata module and GeoAPI chairman (mentor).
> * Authors of the MD-Web project and peoples working in remote-sensing (for
> more metadata advice).
> * Member of the OGC Architecture Board for help with OGC procedure.
> * Some authors who contributed to the ISO 19115 revision.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Work started] (SIS-127) Create an implementation of Record
[
https://issues.apache.org/jira/browse/SIS-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on SIS-127 started by Martin Desruisseaux.
> Create an implementation of Record
> --
>
> Key: SIS-127
> URL: https://issues.apache.org/jira/browse/SIS-127
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Metadata
>Affects Versions: 0.3
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Fix For: 0.5
>
>
> We need an implementation of GeoAPI {{Record}} interface. This is minor for
> now, but will become more critical when we will implement {{Feature}} and
> {{Coverage}} in an ISO-compliant way. This is also needed for JAXB
> annotations of {{DefaultQuantitativeResult}} metadata.
> Useful links:
> * https://geo-ide.noaa.gov/wiki/index.php?title=Record
> *
> http://sciencedatasystems.org/wiki/main/index.php/Attribute_Type_Code_Samples
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Work stopped] (SIS-127) Create an implementation of Record
[
https://issues.apache.org/jira/browse/SIS-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on SIS-127 stopped by Martin Desruisseaux.
> Create an implementation of Record
> --
>
> Key: SIS-127
> URL: https://issues.apache.org/jira/browse/SIS-127
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Metadata
>Affects Versions: 0.3
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Fix For: 0.5
>
>
> We need an implementation of GeoAPI {{Record}} interface. This is minor for
> now, but will become more critical when we will implement {{Feature}} and
> {{Coverage}} in an ISO-compliant way. This is also needed for JAXB
> annotations of {{DefaultQuantitativeResult}} metadata.
> Useful links:
> * https://geo-ide.noaa.gov/wiki/index.php?title=Record
> *
> http://sciencedatasystems.org/wiki/main/index.php/Attribute_Type_Code_Samples
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (SIS-127) Create an implementation of Record
[
https://issues.apache.org/jira/browse/SIS-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux resolved SIS-127.
-
Resolution: Fixed
Implemented on the JDK8 branch as of revision 1609161, but without XML
(un)marshalling for now. XML support will be added later when we will have more
examples.
> Create an implementation of Record
> --
>
> Key: SIS-127
> URL: https://issues.apache.org/jira/browse/SIS-127
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Metadata
>Affects Versions: 0.3
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Fix For: 0.5
>
>
> We need an implementation of GeoAPI {{Record}} interface. This is minor for
> now, but will become more critical when we will implement {{Feature}} and
> {{Coverage}} in an ISO-compliant way. This is also needed for JAXB
> annotations of {{DefaultQuantitativeResult}} metadata.
> Useful links:
> * https://geo-ide.noaa.gov/wiki/index.php?title=Record
> *
> http://sciencedatasystems.org/wiki/main/index.php/Attribute_Type_Code_Samples
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (SIS-176) Provides an optimized transform the diagonal matrices
Martin Desruisseaux created SIS-176:
---
Summary: Provides an optimized transform the diagonal matrices
Key: SIS-176
URL: https://issues.apache.org/jira/browse/SIS-176
Project: Spatial Information Systems
Issue Type: Improvement
Components: Referencing
Reporter: Martin Desruisseaux
Priority: Minor
{{ProjectiveTransform}} handles arbitrary matrices in a generic way. However in
practice, many matrices are diagonal + a translation transform. We may get some
performance improvement if we write a specialized transform class for such
matrices, because it would replace a O(_n_²) operation by a O(_n_) one (_n_ is
the matrix size).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (SIS-176) Provide an optimized transform for diagonal matrices
[
https://issues.apache.org/jira/browse/SIS-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-176:
Summary: Provide an optimized transform for diagonal matrices (was:
Provides an optimized transform for diagonal matrices)
> Provide an optimized transform for diagonal matrices
>
>
> Key: SIS-176
> URL: https://issues.apache.org/jira/browse/SIS-176
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Referencing
>Reporter: Martin Desruisseaux
>Priority: Minor
>
> {{ProjectiveTransform}} handles arbitrary matrices in a generic way. However
> in practice, many matrices are diagonal + a translation transform. We may get
> some performance improvement if we write a specialized transform class for
> such matrices, because it would replace a O(_n_²) operation by a O(_n_) one
> (_n_ is the matrix size).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (SIS-176) Provide an optimized MathTransform implementation for diagonal matrices
[
https://issues.apache.org/jira/browse/SIS-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-176:
Summary: Provide an optimized MathTransform implementation for diagonal
matrices (was: Provide an optimized transform for diagonal matrices)
> Provide an optimized MathTransform implementation for diagonal matrices
> ---
>
> Key: SIS-176
> URL: https://issues.apache.org/jira/browse/SIS-176
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Referencing
>Reporter: Martin Desruisseaux
>Priority: Minor
>
> {{ProjectiveTransform}} handles arbitrary matrices in a generic way. However
> in practice, many matrices are diagonal + a translation transform. We may get
> some performance improvement if we write a specialized transform class for
> such matrices, because it would replace a O(_n_²) operation by a O(_n_) one
> (_n_ is the matrix size).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (SIS-176) Provides an optimized transform for diagonal matrices
[
https://issues.apache.org/jira/browse/SIS-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-176:
Summary: Provides an optimized transform for diagonal matrices (was:
Provides an optimized transform the diagonal matrices)
> Provides an optimized transform for diagonal matrices
> -
>
> Key: SIS-176
> URL: https://issues.apache.org/jira/browse/SIS-176
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Referencing
>Reporter: Martin Desruisseaux
>Priority: Minor
>
> {{ProjectiveTransform}} handles arbitrary matrices in a generic way. However
> in practice, many matrices are diagonal + a translation transform. We may get
> some performance improvement if we write a specialized transform class for
> such matrices, because it would replace a O(_n_²) operation by a O(_n_) one
> (_n_ is the matrix size).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (SIS-94) Update SIS to revision 2014 of the ISO 19115 standard
[
https://issues.apache.org/jira/browse/SIS-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-94:
---
Summary: Update SIS to revision 2014 of the ISO 19115 standard (was:
Update SIS to revision 2013 of the ISO 19115 standard)
> Update SIS to revision 2014 of the ISO 19115 standard
> -
>
> Key: SIS-94
> URL: https://issues.apache.org/jira/browse/SIS-94
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Metadata
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Labels: gsoc2013
> Attachments: AbstractParty.java, DefaultAssociatedResource.java,
> DefaultAttributeGroup.java, DefaultBand.patch, DefaultCitation.patch,
> DefaultConstraint.patch, DefaultContact.patch, DefaultCoupledResource.java,
> DefaultCoverageDescription.java, DefaultDimension.patch,
> DefaultFeatureTypeInfo.java, DefaultIndividual.java,
> DefaultKeywordClass.java, DefaultMetadataScope.java,
> DefaultOperationChainMetadata.java, DefaultOperationMetadata.java,
> DefaultOrganisation.java, DefaultParameter.java, DefaultProcessStep.patch,
> DefaultRangeDimension.patch, DefaultReleasability.java,
> DefaultRepresentativeFraction.patch, DefaultResponsibility.java,
> DefaultSampleDimension.java, DefaultSpatialTemporalExtent.patch,
> DefaultTelephone.patch, defaultBrowseGraphic.patch, defaultKeyword.patch,
> defaultLineage.patch, defaultMaintenance.patch,
> defaultServiceIdentification.patch, defaultSource.patch, defaultUsage.patch
>
> Original Estimate: 1,344h
> Remaining Estimate: 1,344h
>
> One of Apache SIS goals is to comply with the ISO (_International Standards
> Organization_) specifications. Compliance to international standards not only
> increase inter-operability between products, but is also a legal requirement
> for government agencies in the European Union since the INSPIRE directive
> from the European Commission.
> Apache SIS currently implements the ISO 19115 (_Geographic information -
> Metadata_) standard, as published in 2003, completed by ISO 19115-2 published
> in 2009. The ISO organization updates their standards once every 10 years.
> The new ISO 19115 revision has been published in 2014 and is available there:
> http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=53798
> We need to update Apache SIS to make it compliant with the new ISO 19115
> standards. Because Apache SIS implements the GeoAPI interfaces defined by the
> Open Geospatial Consortium (OGC), this task will need to be done in
> cooperation with the OGC GeoAPI working group. More specifically, the tasks
> will be (not necessarily in that order - many tasks are expected to be done
> in parallel):
> * On the OGC GeoAPI side ([GEO-232|http://jira.codehaus.org/browse/GEO-232]):
> ** Get legal copies of the new ISO 19115-1, -2, -3 and -4 standards (to be
> provided by mentors).
> ** Review all classes, interfaces, fields and methods defined in the
> {{org.opengis.metadata.*}} packages and compare them with the new definitions
> provided in ISO 19115-1 and -2.
> *** For every new elements added in ISO 19115-1/2, add the corresponding
> elements in the Java interfaces.
> *** For every elements removed from ISO 19115-1/2, deprecate the
> corresponding elements in the Java interfaces.
> *** Fix any discrepancies or errors which may be found on a case-by-case
> basis, to be discussed on the GeoAPI mailing list.
> *** Make sure that all elements have an up-to-date and accurate Javadoc.
> ** Update the GeoAPI specification with mentor help.
> ** Write test cases in the {{geoapi-conformance}} module.
> * On the Apache SIS side:
> ** For all changes done in GeoAPI interface, reflect the changes in the
> Apache SIS implementation in the {{org.apache.sis.metadata.iso.*}} packages.
> ** Add JAXB adapters for the new elements, or fix JAXB adapters for existing
> elements, in order to marshal/unmarshall XML documents compliant with the new
> standards as defined in ISO 19115-3 and -4.
> ** Check for any additional requirements defined by the INSPIRE directive.
> ** Ensure that Apache SIS passes the tests defined in GeoAPI.
> ** In collaboration with specialists, write some use cases and demos using
> the new metadata objects.
> Peoples who can help for this task are:
> * Contributor of the Apache SIS metadata module and GeoAPI chairman (mentor).
> * Authors of the MD-Web project and peoples working in remote-sensing (for
> more metadata advice).
> * Member of the OGC Architecture Board for help with OGC procedure.
> * Some authors who contributed to the ISO 19115 revision.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (SIS-110) Add some intelligence in metadata implementation
[
https://issues.apache.org/jira/browse/SIS-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-110:
Description:
ISO 19115 seems to have some redundancies in metadata information. For example:
* {{Identification.pointOfContact}} ↔
{{Identification.citation.citedResponsibleParty}} (collection of
{{ResponsibleParty}}): the former could be defined as a subset of the later
where the {{ResponsibleParty.role}} attribute is set to
{{Role.POINT_OF_CONTACT}}.
* {{Metadata.contact}} ↔ {{Metadata.identificationInfo.pointOfContact}}
(collection of {{ResponsibleParty}}): the former is the contact responsible for
the metadata, while the later is the contact responsible for the _resource_
described by the metadata. However in practice this is often the same contact.
* {{GeographicBoundingBox}} ↔ {{BoundingPolygon}}: the former could be inferred
from the later.
* {{Georectified.checkPointAvailability}} ↔
({{Georectified.checkPointDescription}}, {{Georectified.checkPoint}}): the
former could be set to {{true}} if any of the later attribute is non-null.
There is many other {{fooAvailability}} attribute like that one - all of them
may be candidate to such automatic inference.
* {{OnlineResource.getLinkage()}}: could be inferred from {{getDataSetUri()}}.
* {{OnlineResource.getProtocol()}}: could be inferred from the scheme part of
{{getLinkage()}}.
* {{Metadata.identificationInfo.spatialResolutions}} seems to be synonymous of
{{metadata.spatialRepresentationInfo.axisDimensionProperties.resolution}}.
* {{Distribution.formats}} may be inferred by the union of all contained
{{DigitalTransferOptions.formats}}.
* {{Metadata.locale}} may need to contain all locales used by every
{{InternationalString}} instances in the metadata tree. This is needed since
the {{locale}} attribute in {{}} is a reference
to a locale defined in {{}} (SIS-137).
h3. As an optional mechanism
We could provide some optional mechanism (to be enabled only if desired) where,
if a value was not explicitly given for some attributes, a default value is
automatically inferred from other attribute. For example:
* If no value was explicitly given to {{Metadata.contact}}, returns
{{Metadata.identificationInfo.pointOfContact}}.
* If no value was explicitly given to
{{Metadata.identificationInfo.pointOfContact}}, returns a filtered list of
{{Metadata.identificationInfo.citation.citedResponsibleParty}} where {{role}} =
{{POINT_OF_CONTACT}}.
Note the cascading of the above two inference mechanisms.
h3. Impact on other code
If the {{Metadata.pointOfContact}} property become automatically calculated,
then we should remove the duplication done in the NetCDF metadata reader.
was:
ISO 19115 seems to have some redundancies in metadata information. For example:
* {{Identification.pointOfContact}} ↔
{{Identification.citation.citedResponsibleParty}} (collection of
{{ResponsibleParty}}): the former could be defined as a subset of the later
where the {{ResponsibleParty.role}} attribute is set to
{{Role.POINT_OF_CONTACT}}.
* {{Metadata.contact}} ↔ {{Metadata.identificationInfo.pointOfContact}}
(collection of {{ResponsibleParty}}): the former is the contact responsible for
the metadata, while the later is the contact responsible for the _resource_
described by the metadata. However in practice this is often the same contact.
* {{GeographicBoundingBox}} ↔ {{BoundingPolygon}}: the former could be inferred
from the later.
* {{Georectified.checkPointAvailability}} ↔
({{Georectified.checkPointDescription}}, {{Georectified.checkPoint}}): the
former could be set to {{true}} if any of the later attribute is non-null.
There is many other {{fooAvailability}} attribute like that one - all of them
may be candidate to such automatic inference.
* {{OnlineResource.getLinkage()}}: could be inferred from {{getDataSetUri()}}.
* {{OnlineResource.getProtocol()}}: could be inferred from the scheme part of
{{getLinkage()}}.
* {{Metadata.identificationInfo.spatialResolutions}} seems to be synonymous of
{{metadata.spatialRepresentationInfo.axisDimensionProperties.resolution}}.
* {{Metadata.locale}} may need to contain all locales used by every
{{InternationalString}} instances in the metadata tree. This is needed since
the {{locale}} attribute in {{}} is a reference
to a locale defined in {{}} (SIS-137).
h3. As an optional mechanism
We could provide some optional mechanism (to be enabled only if desired) where,
if a value was not explicitly given for some attributes, a default value is
automatically inferred from other attribute. For example:
* If no value was explicitly given to {{Metadata.contact}}, returns
{{Metadata.identificationInfo.pointOfContact}}.
* If no value was explicitly given to
{{Metadata.identificationInfo.pointOfContact}}, returns a filtered list of
{{Metadata.identificationInfo.citation.citedResponsibleParty}} where {{role}}
[jira] [Created] (SIS-177) Translate the developer guide to English
Martin Desruisseaux created SIS-177: --- Summary: Translate the developer guide to English Key: SIS-177 URL: https://issues.apache.org/jira/browse/SIS-177 Project: Spatial Information Systems Issue Type: Task Components: Documentation Reporter: Martin Desruisseaux A developer guide (still incomplete) is available at http://sis.staging.apache.org/book/fr/developer-guide.html . However the guide has been written in French, in part because based on existing material (e.g. some chapters written during thesis). This task is about translating the guide to English. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (SIS-110) Add some intelligence in metadata implementation
[
https://issues.apache.org/jira/browse/SIS-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-110:
Description:
ISO 19115 seems to have some redundancies in metadata information. For example:
* {{Identification.pointOfContact}} ↔
{{Identification.citation.citedResponsibleParty}} (collection of
{{ResponsibleParty}}): the former could be defined as a subset of the later
where the {{ResponsibleParty.role}} attribute is set to
{{Role.POINT_OF_CONTACT}}.
* {{Metadata.contact}} ↔ {{Metadata.identificationInfo.pointOfContact}}
(collection of {{ResponsibleParty}}): the former is the contact responsible for
the metadata, while the later is the contact responsible for the _resource_
described by the metadata. However in practice this is often the same contact.
* {{GeographicBoundingBox}} ↔ {{BoundingPolygon}}: the former could be inferred
from the later.
* {{Georectified.checkPointAvailability}} ↔
({{Georectified.checkPointDescription}}, {{Georectified.checkPoint}}): the
former could be set to {{true}} if any of the later attribute is non-null.
There is many other {{fooAvailability}} attribute like that one - all of them
may be candidate to such automatic inference.
* {{OnlineResource.getLinkage()}}: could be inferred from {{getDataSetUri()}}.
* {{OnlineResource.getProtocol()}}: could be inferred from the scheme part of
{{getLinkage()}}.
* {{StandardOrderProcess.getOrderOptionType()}} could be inferred from
{{getOrderOptions().getRecordType()}}.
* {{Metadata.identificationInfo.spatialResolutions}} seems to be synonymous of
{{metadata.spatialRepresentationInfo.axisDimensionProperties.resolution}}.
* {{Distribution.formats}} may be inferred by the union of all contained
{{DigitalTransferOptions.formats}}.
* {{Metadata.locale}} may need to contain all locales used by every
{{InternationalString}} instances in the metadata tree. This is needed since
the {{locale}} attribute in {{}} is a reference
to a locale defined in {{}} (SIS-137).
h3. As an optional mechanism
We could provide some optional mechanism (to be enabled only if desired) where,
if a value was not explicitly given for some attributes, a default value is
automatically inferred from other attribute. For example:
* If no value was explicitly given to {{Metadata.contact}}, returns
{{Metadata.identificationInfo.pointOfContact}}.
* If no value was explicitly given to
{{Metadata.identificationInfo.pointOfContact}}, returns a filtered list of
{{Metadata.identificationInfo.citation.citedResponsibleParty}} where {{role}} =
{{POINT_OF_CONTACT}}.
Note the cascading of the above two inference mechanisms.
h3. Impact on other code
If the {{Metadata.pointOfContact}} property become automatically calculated,
then we should remove the duplication done in the NetCDF metadata reader.
was:
ISO 19115 seems to have some redundancies in metadata information. For example:
* {{Identification.pointOfContact}} ↔
{{Identification.citation.citedResponsibleParty}} (collection of
{{ResponsibleParty}}): the former could be defined as a subset of the later
where the {{ResponsibleParty.role}} attribute is set to
{{Role.POINT_OF_CONTACT}}.
* {{Metadata.contact}} ↔ {{Metadata.identificationInfo.pointOfContact}}
(collection of {{ResponsibleParty}}): the former is the contact responsible for
the metadata, while the later is the contact responsible for the _resource_
described by the metadata. However in practice this is often the same contact.
* {{GeographicBoundingBox}} ↔ {{BoundingPolygon}}: the former could be inferred
from the later.
* {{Georectified.checkPointAvailability}} ↔
({{Georectified.checkPointDescription}}, {{Georectified.checkPoint}}): the
former could be set to {{true}} if any of the later attribute is non-null.
There is many other {{fooAvailability}} attribute like that one - all of them
may be candidate to such automatic inference.
* {{OnlineResource.getLinkage()}}: could be inferred from {{getDataSetUri()}}.
* {{OnlineResource.getProtocol()}}: could be inferred from the scheme part of
{{getLinkage()}}.
* {{Metadata.identificationInfo.spatialResolutions}} seems to be synonymous of
{{metadata.spatialRepresentationInfo.axisDimensionProperties.resolution}}.
* {{Distribution.formats}} may be inferred by the union of all contained
{{DigitalTransferOptions.formats}}.
* {{Metadata.locale}} may need to contain all locales used by every
{{InternationalString}} instances in the metadata tree. This is needed since
the {{locale}} attribute in {{}} is a reference
to a locale defined in {{}} (SIS-137).
h3. As an optional mechanism
We could provide some optional mechanism (to be enabled only if desired) where,
if a value was not explicitly given for some attributes, a default value is
automatically inferred from other attribute. For example:
* If no value was explicitly given to {{Metadata.contact}}, returns
{{Metadata.identific
[jira] [Commented] (SIS-177) Translate the developer guide to English
[ https://issues.apache.org/jira/browse/SIS-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14095318#comment-14095318 ] Martin Desruisseaux commented on SIS-177: - Thanks again for all this work! There is my suggestions: * Line 191: the intend was to said something like "This database is offered by petroleum companies that have an interest to ensure that their exploration is performed at the right place, given that the companies don't always control the production of the maps they use”. * Line 194: cool, thanks! * Line 292: the intend was something like "Attempts to support object-oriented paradigm result in verbose approach in some language." * Line 491-493: yes, the translation sound good. * Line 531-532: maybe something like "... while leaving the remaining features as extension points for future developments."? * Line 596: yes, I think that "verbose" is appropriate here. * Line 670: the translation sound good. * Line 686-687: yes, "property files" are the words used in Java. * Line 697: maybe replacing "obligation level" by "obligation (i.e. whether the element is mandatory or optional)" would help? * Line 698: yes, I have seen "code snippet" used in similar context. * Line 723: "introspection methods" is correct, but the Java language tends to said "reflection methods" instead. * Line 724: the translation sound good. The names that we mean are the UML identifiers. We could replace "names" by "UML identifiers". * Line 925: the translation sound good. * Line 1166, 1177: "the running JVM" or "the currently running JVM" was the intend. > Translate the developer guide to English > > > Key: SIS-177 > URL: https://issues.apache.org/jira/browse/SIS-177 > Project: Spatial Information Systems > Issue Type: Task > Components: Documentation >Reporter: Martin Desruisseaux > Attachments: developer-guide-en.html, developer-guide-en.html > > > A developer guide (still incomplete) is available at > http://sis.staging.apache.org/book/fr/developer-guide.html . However the > guide has been written in French, in part because based on existing material > (e.g. some chapters written during thesis). This task is about translating > the guide to English. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (SIS-177) Translate the developer guide to English
[ https://issues.apache.org/jira/browse/SIS-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14113818#comment-14113818 ] Martin Desruisseaux commented on SIS-177: - Thanks! I re-generated the Table Of Content and commited the new files on the staging web site: http://localhost:8383/site/content/book/en/developer-guide.html * Line 1331: yes, I was meaning its own section in the document. I added a link to that section. * Line 1346: yes, "namespace" is the standard term. * Line 1396: the idea behind "_for objects written with relatively few models_" was rather "_for objects that do not occur very often in the document_". I will also update the French sentence - I agree that it may be confusing. * Line 1425: yes, I think that "_enclosed by_" is better. * Line 1460: "_parent_" is okay from a _tree_ perspective, but would have a different meaning from a _hierarchy_ perspective. Since XML mixes both, I'm not sure how we should interpret "_parent_". Maybe "_enclosing_" is less ambiguous. But reading the original French again, I feel that the whole paragraph was confusing. So I rewrote it and updated the English version accordingly. The change was mostly to move around some sentence in order to form a numerated list (the sentences stay about the same). The updated paragraph is [here|http://sis.staging.apache.org/book/en/developer-guide.html#XML-ISO-19115]. Please feel free to update or fix as you see fit. * Line 1160: yes, "_dependencies chain_" is something that I have see too. I think it is good. * Line 1501: agree, I added "_listed above_". * Line 1738: "_safe operation_" sound good. * Line 1742: I do not know how good is "_known to_" in standard English, but the translation looks good to me. * Line 1786: In this context, "Formatteur" would rather be "Formatter". I applied the replacement. * Line 1810: I think that the original French was a bit confusing. I tried to reword it. Maybe "_This is particularly useful for immutable classes used for creating unique instances independently of local conventions_"? * Line 1972: Yes I mean that one is large and complex and the other simpler. I think that "cumbersome" is appropriate, but I replaced "less cumbersome" by "more lightweight", since I have seen "lightweight" often used in similar context. It catch the idea that the later is not only simpler for the developer, but also consume less memory (when the computer must holds million of points, it may matter). * Line 2121: I think the translation you did make a useful definition of terms. I think they are good like that :-). * Line 2175: The Oracle documentation uses "_inclusive_" and "_exclusive_" words, so I just removed the trailing "_ly_". * Yes, "_deprecated"_ is the word used in Oracle documentation. Thanks for replacing them. I will add author and translator names somewhere in the page. Thanks again for all your work! > Translate the developer guide to English > > > Key: SIS-177 > URL: https://issues.apache.org/jira/browse/SIS-177 > Project: Spatial Information Systems > Issue Type: Task > Components: Documentation >Reporter: Martin Desruisseaux > Attachments: developer-guide-en.html, developer-guide-en.html, > developer-guide2.html > > > A developer guide (still incomplete) is available at > http://sis.staging.apache.org/book/fr/developer-guide.html . However the > guide has been written in French, in part because based on existing material > (e.g. some chapters written during thesis). This task is about translating > the guide to English. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (SIS-110) Add some intelligence in metadata implementation
[
https://issues.apache.org/jira/browse/SIS-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-110:
Description:
ISO 19115 seems to have some redundancies in metadata information. For example:
* {{Identification.pointOfContact}} ↔
{{Identification.citation.citedResponsibleParty}} (collection of
{{ResponsibleParty}}): the former could be defined as a subset of the later
where the {{ResponsibleParty.role}} attribute is set to
{{Role.POINT_OF_CONTACT}}.
* {{Metadata.contact}} ↔ {{Metadata.identificationInfo.pointOfContact}}
(collection of {{ResponsibleParty}}): the former is the contact responsible for
the metadata, while the later is the contact responsible for the _resource_
described by the metadata. However in practice this is often the same contact.
* {{GeographicBoundingBox}} ↔ {{BoundingPolygon}}: the former could be inferred
from the later.
* {{Georectified.checkPointAvailability}} ↔
({{Georectified.checkPointDescription}}, {{Georectified.checkPoint}}): the
former could be set to {{true}} if any of the later attribute is non-null.
There is many other {{fooAvailability}} attribute like that one - all of them
may be candidate to such automatic inference.
* {{OnlineResource.getLinkage()}}: could be inferred from {{getDataSetUri()}}.
* {{OnlineResource.getProtocol()}}: could be inferred from the scheme part of
{{getLinkage()}}.
* {{StandardOrderProcess.getOrderOptionType()}} could be inferred from
{{getOrderOptions().getRecordType()}}.
* Adding a {{Source}} to {{ProcessStep.sources}} could automatically add the
{{ProcessStep}} to {{Source.processSteps}} by weak reference, and conversely. A
similar idea may apply to {{Platform}} and {{Instrument}}.
* {{Metadata.identificationInfo.spatialResolutions}} seems to be synonymous of
{{metadata.spatialRepresentationInfo.axisDimensionProperties.resolution}}.
* {{Distribution.formats}} may be inferred by the union of all contained
{{DigitalTransferOptions.formats}}.
* {{Metadata.locale}} may need to contain all locales used by every
{{InternationalString}} instances in the metadata tree. This is needed since
the {{locale}} attribute in {{}} is a reference
to a locale defined in {{}} (SIS-137).
h3. As an optional mechanism
We could provide some optional mechanism (to be enabled only if desired) where,
if a value was not explicitly given for some attributes, a default value is
automatically inferred from other attribute. For example:
* If no value was explicitly given to {{Metadata.contact}}, returns
{{Metadata.identificationInfo.pointOfContact}}.
* If no value was explicitly given to
{{Metadata.identificationInfo.pointOfContact}}, returns a filtered list of
{{Metadata.identificationInfo.citation.citedResponsibleParty}} where {{role}} =
{{POINT_OF_CONTACT}}.
Note the cascading of the above two inference mechanisms.
h3. Impact on other code
If the {{Metadata.pointOfContact}} property become automatically calculated,
then we should remove the duplication done in the NetCDF metadata reader.
was:
ISO 19115 seems to have some redundancies in metadata information. For example:
* {{Identification.pointOfContact}} ↔
{{Identification.citation.citedResponsibleParty}} (collection of
{{ResponsibleParty}}): the former could be defined as a subset of the later
where the {{ResponsibleParty.role}} attribute is set to
{{Role.POINT_OF_CONTACT}}.
* {{Metadata.contact}} ↔ {{Metadata.identificationInfo.pointOfContact}}
(collection of {{ResponsibleParty}}): the former is the contact responsible for
the metadata, while the later is the contact responsible for the _resource_
described by the metadata. However in practice this is often the same contact.
* {{GeographicBoundingBox}} ↔ {{BoundingPolygon}}: the former could be inferred
from the later.
* {{Georectified.checkPointAvailability}} ↔
({{Georectified.checkPointDescription}}, {{Georectified.checkPoint}}): the
former could be set to {{true}} if any of the later attribute is non-null.
There is many other {{fooAvailability}} attribute like that one - all of them
may be candidate to such automatic inference.
* {{OnlineResource.getLinkage()}}: could be inferred from {{getDataSetUri()}}.
* {{OnlineResource.getProtocol()}}: could be inferred from the scheme part of
{{getLinkage()}}.
* {{StandardOrderProcess.getOrderOptionType()}} could be inferred from
{{getOrderOptions().getRecordType()}}.
* {{Metadata.identificationInfo.spatialResolutions}} seems to be synonymous of
{{metadata.spatialRepresentationInfo.axisDimensionProperties.resolution}}.
* {{Distribution.formats}} may be inferred by the union of all contained
{{DigitalTransferOptions.formats}}.
* {{Metadata.locale}} may need to contain all locales used by every
{{InternationalString}} instances in the metadata tree. This is needed since
the {{locale}} attribute in {{}} is a reference
to a locale defined in {{}} (SIS-137).
h3. As a
[jira] [Assigned] (SIS-79) Implement RangeSet.remove(E, E)
[
https://issues.apache.org/jira/browse/SIS-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux reassigned SIS-79:
--
Assignee: Martin Desruisseaux
> Implement RangeSet.remove(E, E)
> ---
>
> Key: SIS-79
> URL: https://issues.apache.org/jira/browse/SIS-79
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Utilities
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Labels: licensing
> Attachments: RangeSet.patch, RangeSetTest.patch
>
>
> The {{org.apache.sis.util.collection.RangeSet}} class has been ported to
> Apache SIS at the exclusion of the implementation of the {{remove(E,E)}}
> method, which has been excluded for licensing reasons. We need volunteer work
> for implementing that method.
> A copy of the {{add(E,E)}} can be used as a starting point, then modified.
> The basic idea is it to get the index of the given {{minValue}} and
> {{maxValue}} arguments using the {{binarySearch}} method, then make some
> choices:
> * If the given range is completely outside all {{RangeSet}} ranges, do
> nothing.
> * If the given range fully contains one or many {{RangeSet}} ranges, remove
> all those ranges by invoking the {{removeAt(int, int)}} method.
> * If the given range is fully contained inside an existing range, split that
> existing range in two smaller ranges: one for the part before the range to
> remove, and one for the part after the range to remove. The {{insertAt(int,
> E, E)}} method will need to be invoked.
> * If the given range partially overlaps an existing {{RangeSet}} range, edits
> the endpoints of that range. No range are removed or inserted.
> There is some tricks to keep in mind for hacking {{RangeSet}}:
> * The internal {{array}} is a sequence of (_minimal_, _maximal_) value
> tupples for all ranges included in this {{RangeSet}} instance.Even index are
> for minimal values and odd index are for maximal values.
> * If {{binarySearch}} returns a negative value, no exact match was found. To
> get the insertion point (the index of the first value greater than the
> searched value), use {{index = ~index}} (the tild operation, not the minus
> sign).
> * To test if an index points to a minimal value (i.e. the index is an even
> number), use {{((index & 1) == 0)}}.
> * To test if an index points to a maximal value (i.e. the index is an odd
> number), use {{((index & 1) != 0)}}.
> * To force an index to be even (i.e. to point to the minimal value of the
> range) either be leaving the index unchanged, or if the index was odd
> decrease the value by one, use {{index &= ~1}}.
> * To force an index to be odd (i.e. to point to the maximal value of the
> range) either by leaving the index unchanged, or if the index was even
> increase the value by one, use {{index |= 1}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Work started] (SIS-79) Implement RangeSet.remove(E, E)
[
https://issues.apache.org/jira/browse/SIS-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on SIS-79 started by Martin Desruisseaux.
--
> Implement RangeSet.remove(E, E)
> ---
>
> Key: SIS-79
> URL: https://issues.apache.org/jira/browse/SIS-79
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Utilities
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Labels: licensing
> Attachments: RangeSet.patch, RangeSetTest.patch
>
>
> The {{org.apache.sis.util.collection.RangeSet}} class has been ported to
> Apache SIS at the exclusion of the implementation of the {{remove(E,E)}}
> method, which has been excluded for licensing reasons. We need volunteer work
> for implementing that method.
> A copy of the {{add(E,E)}} can be used as a starting point, then modified.
> The basic idea is it to get the index of the given {{minValue}} and
> {{maxValue}} arguments using the {{binarySearch}} method, then make some
> choices:
> * If the given range is completely outside all {{RangeSet}} ranges, do
> nothing.
> * If the given range fully contains one or many {{RangeSet}} ranges, remove
> all those ranges by invoking the {{removeAt(int, int)}} method.
> * If the given range is fully contained inside an existing range, split that
> existing range in two smaller ranges: one for the part before the range to
> remove, and one for the part after the range to remove. The {{insertAt(int,
> E, E)}} method will need to be invoked.
> * If the given range partially overlaps an existing {{RangeSet}} range, edits
> the endpoints of that range. No range are removed or inserted.
> There is some tricks to keep in mind for hacking {{RangeSet}}:
> * The internal {{array}} is a sequence of (_minimal_, _maximal_) value
> tupples for all ranges included in this {{RangeSet}} instance.Even index are
> for minimal values and odd index are for maximal values.
> * If {{binarySearch}} returns a negative value, no exact match was found. To
> get the insertion point (the index of the first value greater than the
> searched value), use {{index = ~index}} (the tild operation, not the minus
> sign).
> * To test if an index points to a minimal value (i.e. the index is an even
> number), use {{((index & 1) == 0)}}.
> * To test if an index points to a maximal value (i.e. the index is an odd
> number), use {{((index & 1) != 0)}}.
> * To force an index to be even (i.e. to point to the minimal value of the
> range) either be leaving the index unchanged, or if the index was odd
> decrease the value by one, use {{index &= ~1}}.
> * To force an index to be odd (i.e. to point to the maximal value of the
> range) either by leaving the index unchanged, or if the index was even
> increase the value by one, use {{index |= 1}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SIS-79) Implement RangeSet.remove(E, E)
[
https://issues.apache.org/jira/browse/SIS-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-79:
---
Affects Version/s: 0.3
0.4
> Implement RangeSet.remove(E, E)
> ---
>
> Key: SIS-79
> URL: https://issues.apache.org/jira/browse/SIS-79
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Utilities
>Affects Versions: 0.3, 0.4
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Labels: licensing
> Fix For: 0.5
>
> Attachments: RangeSet.patch, RangeSetTest.patch
>
>
> The {{org.apache.sis.util.collection.RangeSet}} class has been ported to
> Apache SIS at the exclusion of the implementation of the {{remove(E,E)}}
> method, which has been excluded for licensing reasons. We need volunteer work
> for implementing that method.
> A copy of the {{add(E,E)}} can be used as a starting point, then modified.
> The basic idea is it to get the index of the given {{minValue}} and
> {{maxValue}} arguments using the {{binarySearch}} method, then make some
> choices:
> * If the given range is completely outside all {{RangeSet}} ranges, do
> nothing.
> * If the given range fully contains one or many {{RangeSet}} ranges, remove
> all those ranges by invoking the {{removeAt(int, int)}} method.
> * If the given range is fully contained inside an existing range, split that
> existing range in two smaller ranges: one for the part before the range to
> remove, and one for the part after the range to remove. The {{insertAt(int,
> E, E)}} method will need to be invoked.
> * If the given range partially overlaps an existing {{RangeSet}} range, edits
> the endpoints of that range. No range are removed or inserted.
> There is some tricks to keep in mind for hacking {{RangeSet}}:
> * The internal {{array}} is a sequence of (_minimal_, _maximal_) value
> tupples for all ranges included in this {{RangeSet}} instance.Even index are
> for minimal values and odd index are for maximal values.
> * If {{binarySearch}} returns a negative value, no exact match was found. To
> get the insertion point (the index of the first value greater than the
> searched value), use {{index = ~index}} (the tild operation, not the minus
> sign).
> * To test if an index points to a minimal value (i.e. the index is an even
> number), use {{((index & 1) == 0)}}.
> * To test if an index points to a maximal value (i.e. the index is an odd
> number), use {{((index & 1) != 0)}}.
> * To force an index to be even (i.e. to point to the minimal value of the
> range) either be leaving the index unchanged, or if the index was odd
> decrease the value by one, use {{index &= ~1}}.
> * To force an index to be odd (i.e. to point to the maximal value of the
> range) either by leaving the index unchanged, or if the index was even
> increase the value by one, use {{index |= 1}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SIS-79) Implement RangeSet.remove(E, E)
[
https://issues.apache.org/jira/browse/SIS-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux resolved SIS-79.
Resolution: Fixed
> Implement RangeSet.remove(E, E)
> ---
>
> Key: SIS-79
> URL: https://issues.apache.org/jira/browse/SIS-79
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Utilities
>Affects Versions: 0.3, 0.4
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Labels: licensing
> Attachments: RangeSet.patch, RangeSetTest.patch
>
>
> The {{org.apache.sis.util.collection.RangeSet}} class has been ported to
> Apache SIS at the exclusion of the implementation of the {{remove(E,E)}}
> method, which has been excluded for licensing reasons. We need volunteer work
> for implementing that method.
> A copy of the {{add(E,E)}} can be used as a starting point, then modified.
> The basic idea is it to get the index of the given {{minValue}} and
> {{maxValue}} arguments using the {{binarySearch}} method, then make some
> choices:
> * If the given range is completely outside all {{RangeSet}} ranges, do
> nothing.
> * If the given range fully contains one or many {{RangeSet}} ranges, remove
> all those ranges by invoking the {{removeAt(int, int)}} method.
> * If the given range is fully contained inside an existing range, split that
> existing range in two smaller ranges: one for the part before the range to
> remove, and one for the part after the range to remove. The {{insertAt(int,
> E, E)}} method will need to be invoked.
> * If the given range partially overlaps an existing {{RangeSet}} range, edits
> the endpoints of that range. No range are removed or inserted.
> There is some tricks to keep in mind for hacking {{RangeSet}}:
> * The internal {{array}} is a sequence of (_minimal_, _maximal_) value
> tupples for all ranges included in this {{RangeSet}} instance.Even index are
> for minimal values and odd index are for maximal values.
> * If {{binarySearch}} returns a negative value, no exact match was found. To
> get the insertion point (the index of the first value greater than the
> searched value), use {{index = ~index}} (the tild operation, not the minus
> sign).
> * To test if an index points to a minimal value (i.e. the index is an even
> number), use {{((index & 1) == 0)}}.
> * To test if an index points to a maximal value (i.e. the index is an odd
> number), use {{((index & 1) != 0)}}.
> * To force an index to be even (i.e. to point to the minimal value of the
> range) either be leaving the index unchanged, or if the index was odd
> decrease the value by one, use {{index &= ~1}}.
> * To force an index to be odd (i.e. to point to the maximal value of the
> range) either by leaving the index unchanged, or if the index was even
> increase the value by one, use {{index |= 1}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SIS-79) Implement RangeSet.remove(E, E)
[
https://issues.apache.org/jira/browse/SIS-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-79:
---
Fix Version/s: 0.5
> Implement RangeSet.remove(E, E)
> ---
>
> Key: SIS-79
> URL: https://issues.apache.org/jira/browse/SIS-79
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Utilities
>Affects Versions: 0.3, 0.4
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Labels: licensing
> Fix For: 0.5
>
> Attachments: RangeSet.patch, RangeSetTest.patch
>
>
> The {{org.apache.sis.util.collection.RangeSet}} class has been ported to
> Apache SIS at the exclusion of the implementation of the {{remove(E,E)}}
> method, which has been excluded for licensing reasons. We need volunteer work
> for implementing that method.
> A copy of the {{add(E,E)}} can be used as a starting point, then modified.
> The basic idea is it to get the index of the given {{minValue}} and
> {{maxValue}} arguments using the {{binarySearch}} method, then make some
> choices:
> * If the given range is completely outside all {{RangeSet}} ranges, do
> nothing.
> * If the given range fully contains one or many {{RangeSet}} ranges, remove
> all those ranges by invoking the {{removeAt(int, int)}} method.
> * If the given range is fully contained inside an existing range, split that
> existing range in two smaller ranges: one for the part before the range to
> remove, and one for the part after the range to remove. The {{insertAt(int,
> E, E)}} method will need to be invoked.
> * If the given range partially overlaps an existing {{RangeSet}} range, edits
> the endpoints of that range. No range are removed or inserted.
> There is some tricks to keep in mind for hacking {{RangeSet}}:
> * The internal {{array}} is a sequence of (_minimal_, _maximal_) value
> tupples for all ranges included in this {{RangeSet}} instance.Even index are
> for minimal values and odd index are for maximal values.
> * If {{binarySearch}} returns a negative value, no exact match was found. To
> get the insertion point (the index of the first value greater than the
> searched value), use {{index = ~index}} (the tild operation, not the minus
> sign).
> * To test if an index points to a minimal value (i.e. the index is an even
> number), use {{((index & 1) == 0)}}.
> * To test if an index points to a maximal value (i.e. the index is an odd
> number), use {{((index & 1) != 0)}}.
> * To force an index to be even (i.e. to point to the minimal value of the
> range) either be leaving the index unchanged, or if the index was odd
> decrease the value by one, use {{index &= ~1}}.
> * To force an index to be odd (i.e. to point to the maximal value of the
> range) either by leaving the index unchanged, or if the index was even
> increase the value by one, use {{index |= 1}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (SIS-178) First property red in a DenseFeature returns a null value, next ones are ok.
[
https://issues.apache.org/jira/browse/SIS-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux reassigned SIS-178:
---
Assignee: Martin Desruisseaux
> First property red in a DenseFeature returns a null value, next ones are ok.
>
>
> Key: SIS-178
> URL: https://issues.apache.org/jira/browse/SIS-178
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Features, Storage
>Affects Versions: 0.5
> Environment: Seen on branch JDK 8, but should be the same everywhere.
>Reporter: M. Le Bihan
>Assignee: Martin Desruisseaux
>Priority: Minor
>
> The first field value asked in a _DenseFeature_ is always returning a null
> value, the next calls on the same feature are successful.
> Loading a sample shapefile from here
> [http://export.openstreetmap.fr/contours-administratifs/communes/92-Hauts-de-Seine.shp.tar.gz]
>
> If I attempt to query the values of a Feature this way : "REF_INSEE",
> "COMMUNE", "CODE_POSTA",
> I will receive : null, “a city name”, “a zip code”.
>
> If I try to query this way : "CODE_POSTA", "REF_INSEE", "COMMUNE",
> I will receive : null, “an INSEE code”, “a city name”.
>
> *Involved method :*
> {code:title=DenseFeature.java}
> @Override
> public Property getProperty(final String name) throws
> IllegalArgumentException {
> ArgumentChecks.ensureNonNull("name", name);
> final int index = getIndex(name);
> if (properties instanceof Property[]) {
> final Property property = ((Property[]) properties)[index];
> if (property != null) {
> return property;
> }
> } else {
> wrapValuesInProperties();
> }
> final Property property = createProperty(name);
> properties[index] = property;
> return property;
> }
> {code}
> *hypothesis :*
> after the init call of
> {code}wrapValuesInProperties();{code}
> the method assumes that it has done the same work it would have done with
> {code}final Property property = ((Property[])
> properties)[index];{code}
> but it’s not the case.
> The following unit test will show the problem :
> {code:title=IssuesWithFeaturesTest.java}
> package org.apache.sis.storage.shapefile;
> import static org.junit.Assert.*;
> import java.io.*;
> import org.apache.sis.storage.*;
> import org.junit.*;
> import org.opengis.feature.*;
> import org.opengis.test.*;
> /**
> * Issues with features.
> */
> public class IssuesWithFeaturesTest extends TestCase
> {
>/**
> * Issue : the first property red by DenseFeature is null.
> * @throws DataStoreException if unable to find or read the shapefile.
> * @throws IOException if unable to find or read the shapefile.
> */
>@Test public void issueFirstPropertyNull() throws IOException,
> DataStoreException {
> ShapeFile shapefile = new
> ShapeFile("src/test/resources/org/apache/sis/storage/shapefile/92-Hauts-de-Seine.shp");
> Feature feature = shapefile.FeatureMap.values().iterator().next(); //
> The shapefile has 36 features, take the first one.
> String city = (String)feature.getProperty("COMMUNE\0\0\0\0").getValue();
> String refInsee =
> (String)feature.getProperty("REF_INSEE\0\0").getValue();
> String zipCode = (String)feature.getProperty("CODE_POSTA\0").getValue();
> // The first feature property you read (city here) will return a null
> value.
> assertNotNull("The city should have an INSEE reference.", refInsee);
> assertNotNull("The city should have a zip code.", zipCode);
> assertNotNull("The city should have a name.", city);
>}
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Work started] (SIS-178) First property red in a DenseFeature returns a null value, next ones are ok.
[
https://issues.apache.org/jira/browse/SIS-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on SIS-178 started by Martin Desruisseaux.
---
> First property red in a DenseFeature returns a null value, next ones are ok.
>
>
> Key: SIS-178
> URL: https://issues.apache.org/jira/browse/SIS-178
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Features, Storage
>Affects Versions: 0.5
> Environment: Seen on branch JDK 8, but should be the same everywhere.
>Reporter: M. Le Bihan
>Assignee: Martin Desruisseaux
>Priority: Minor
>
> The first field value asked in a _DenseFeature_ is always returning a null
> value, the next calls on the same feature are successful.
> Loading a sample shapefile from here
> [http://export.openstreetmap.fr/contours-administratifs/communes/92-Hauts-de-Seine.shp.tar.gz]
>
> If I attempt to query the values of a Feature this way : "REF_INSEE",
> "COMMUNE", "CODE_POSTA",
> I will receive : null, “a city name”, “a zip code”.
>
> If I try to query this way : "CODE_POSTA", "REF_INSEE", "COMMUNE",
> I will receive : null, “an INSEE code”, “a city name”.
>
> *Involved method :*
> {code:title=DenseFeature.java}
> @Override
> public Property getProperty(final String name) throws
> IllegalArgumentException {
> ArgumentChecks.ensureNonNull("name", name);
> final int index = getIndex(name);
> if (properties instanceof Property[]) {
> final Property property = ((Property[]) properties)[index];
> if (property != null) {
> return property;
> }
> } else {
> wrapValuesInProperties();
> }
> final Property property = createProperty(name);
> properties[index] = property;
> return property;
> }
> {code}
> *hypothesis :*
> after the init call of
> {code}wrapValuesInProperties();{code}
> the method assumes that it has done the same work it would have done with
> {code}final Property property = ((Property[])
> properties)[index];{code}
> but it’s not the case.
> The following unit test will show the problem :
> {code:title=IssuesWithFeaturesTest.java}
> package org.apache.sis.storage.shapefile;
> import static org.junit.Assert.*;
> import java.io.*;
> import org.apache.sis.storage.*;
> import org.junit.*;
> import org.opengis.feature.*;
> import org.opengis.test.*;
> /**
> * Issues with features.
> */
> public class IssuesWithFeaturesTest extends TestCase
> {
>/**
> * Issue : the first property red by DenseFeature is null.
> * @throws DataStoreException if unable to find or read the shapefile.
> * @throws IOException if unable to find or read the shapefile.
> */
>@Test public void issueFirstPropertyNull() throws IOException,
> DataStoreException {
> ShapeFile shapefile = new
> ShapeFile("src/test/resources/org/apache/sis/storage/shapefile/92-Hauts-de-Seine.shp");
> Feature feature = shapefile.FeatureMap.values().iterator().next(); //
> The shapefile has 36 features, take the first one.
> String city = (String)feature.getProperty("COMMUNE\0\0\0\0").getValue();
> String refInsee =
> (String)feature.getProperty("REF_INSEE\0\0").getValue();
> String zipCode = (String)feature.getProperty("CODE_POSTA\0").getValue();
> // The first feature property you read (city here) will return a null
> value.
> assertNotNull("The city should have an INSEE reference.", refInsee);
> assertNotNull("The city should have a zip code.", zipCode);
> assertNotNull("The city should have a name.", city);
>}
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SIS-178) First property red in a DenseFeature returns a null value, next ones are ok.
[
https://issues.apache.org/jira/browse/SIS-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux resolved SIS-178.
-
Resolution: Fixed
Fix Version/s: 0.5
Committed on the JDK8 branch as of revision 1628479.
> First property red in a DenseFeature returns a null value, next ones are ok.
>
>
> Key: SIS-178
> URL: https://issues.apache.org/jira/browse/SIS-178
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Features, Storage
>Affects Versions: 0.5
> Environment: Seen on branch JDK 8, but should be the same everywhere.
>Reporter: M. Le Bihan
>Assignee: Martin Desruisseaux
>Priority: Minor
> Fix For: 0.5
>
>
> The first field value asked in a _DenseFeature_ is always returning a null
> value, the next calls on the same feature are successful.
> Loading a sample shapefile from here
> [http://export.openstreetmap.fr/contours-administratifs/communes/92-Hauts-de-Seine.shp.tar.gz]
>
> If I attempt to query the values of a Feature this way : "REF_INSEE",
> "COMMUNE", "CODE_POSTA",
> I will receive : null, “a city name”, “a zip code”.
>
> If I try to query this way : "CODE_POSTA", "REF_INSEE", "COMMUNE",
> I will receive : null, “an INSEE code”, “a city name”.
>
> *Involved method :*
> {code:title=DenseFeature.java}
> @Override
> public Property getProperty(final String name) throws
> IllegalArgumentException {
> ArgumentChecks.ensureNonNull("name", name);
> final int index = getIndex(name);
> if (properties instanceof Property[]) {
> final Property property = ((Property[]) properties)[index];
> if (property != null) {
> return property;
> }
> } else {
> wrapValuesInProperties();
> }
> final Property property = createProperty(name);
> properties[index] = property;
> return property;
> }
> {code}
> *hypothesis :*
> after the init call of
> {code}wrapValuesInProperties();{code}
> the method assumes that it has done the same work it would have done with
> {code}final Property property = ((Property[])
> properties)[index];{code}
> but it’s not the case.
> The following unit test will show the problem :
> {code:title=IssuesWithFeaturesTest.java}
> package org.apache.sis.storage.shapefile;
> import static org.junit.Assert.*;
> import java.io.*;
> import org.apache.sis.storage.*;
> import org.junit.*;
> import org.opengis.feature.*;
> import org.opengis.test.*;
> /**
> * Issues with features.
> */
> public class IssuesWithFeaturesTest extends TestCase
> {
>/**
> * Issue : the first property red by DenseFeature is null.
> * @throws DataStoreException if unable to find or read the shapefile.
> * @throws IOException if unable to find or read the shapefile.
> */
>@Test public void issueFirstPropertyNull() throws IOException,
> DataStoreException {
> ShapeFile shapefile = new
> ShapeFile("src/test/resources/org/apache/sis/storage/shapefile/92-Hauts-de-Seine.shp");
> Feature feature = shapefile.FeatureMap.values().iterator().next(); //
> The shapefile has 36 features, take the first one.
> String city = (String)feature.getProperty("COMMUNE\0\0\0\0").getValue();
> String refInsee =
> (String)feature.getProperty("REF_INSEE\0\0").getValue();
> String zipCode = (String)feature.getProperty("CODE_POSTA\0").getValue();
> // The first feature property you read (city here) will return a null
> value.
> assertNotNull("The city should have an INSEE reference.", refInsee);
> assertNotNull("The city should have a zip code.", zipCode);
> assertNotNull("The city should have a name.", city);
>}
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SIS-179) Extract Database class from Shapefile class to allow reading DBF without shapefile
[
https://issues.apache.org/jira/browse/SIS-179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14161344#comment-14161344
]
Martin Desruisseaux commented on SIS-179:
-
Maybe {{org.apache.sis.storage.database}} is a too generic package name for a
code which is specific to the DBF3 format? Some alternatives may be:
* Keep {{Database}} and related classes in {{org.apache.sis.storage.shapefile}}
for now, if possible as package-privated classes.
* Or alternatively, but them in a {{org.apache.sis.internal.storage.dbf3}}
package. Note the {{internal}} in the package name - those packages are hidden
from public API. The reason for that is that JDBC drivers usually expose only
their API through JDBC interfaces, and try to hide their internal mechanic from
the user as much as possible.
Note that the {{sis-shapefile}} module has significant dependencies, like
{{sis-referencing}} (to be needed for parsing {{.prj}} files). The weight of
those dependencies may discourage some peoples to use {{sis-shapefile}} for
reading plain DBF3 files. Maybe some users would be more interested in having a
copy of the code for the DBF3-only part in a separated, lightweight project.
However having the DBF3-only part in a separated package may make such
separation easier.
P.S.: If possible, I would like to get ride of {{CodePage}} class since I think
it duplicates {{java.nio.charset}}.
> Extract Database class from Shapefile class to allow reading DBF without
> shapefile
> --
>
> Key: SIS-179
> URL: https://issues.apache.org/jira/browse/SIS-179
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Features, Storage
>Affects Versions: 0.5
>Reporter: M. Le Bihan
>Priority: Minor
> Attachments: DataType.java, Database.java, FieldDescriptor.java,
> ShapeFile.java, package-info.java
>
>
> Extracting the DBF binary reader from th Shapefile class to a Database class
> allows the loading of a DBF file when it is not accompanied with a shapefile.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SIS-181) Use Apache code signing service for SIS releases
Martin Desruisseaux created SIS-181: --- Summary: Use Apache code signing service for SIS releases Key: SIS-181 URL: https://issues.apache.org/jira/browse/SIS-181 Project: Spatial Information Systems Issue Type: Improvement Components: Build process Reporter: Martin Desruisseaux Priority: Minor The Apache Foundation now provide a code signing service. The Apache SIS project should consider using it for their releases. Instructions are there: https://blogs.apache.org/infra/entry/code_signing_service_now_available -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SIS-180) Place a crude JDBC driver over Dbase files
[
https://issues.apache.org/jira/browse/SIS-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14161359#comment-14161359
]
Martin Desruisseaux commented on SIS-180:
-
I wonder, if the first version limit itself to the {{SELECT * FROM }}
clause, I wonder if we could start with a manually-written parser instead than
using AntLR? I find tools that generate code automatically useful for a quick
start, but later become a limitation. For example Sun initially written javac
using such tools, and later abandoned it and rewrote the full javac parser from
scratch, manually. I had myself similar experience with the Well Known Text
(WKT) parser: the first version wrote 10 years ago was using something like
AntLR, and later we had to abandon it and rewrite everything from scratch. I
believe that as the text that we are tying to parse gains in complexity, the
constraint of such tools become more problematic.
> Place a crude JDBC driver over Dbase files
> --
>
> Key: SIS-180
> URL: https://issues.apache.org/jira/browse/SIS-180
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Storage
>Affects Versions: 0.5
>Reporter: M. Le Bihan
>Priority: Minor
>
> It would be useful to be able to query DBF content through SQL.
> But there are no free drivers available for the old _Dbase 3_ format.
> The first step is to create short implementations of _Connection_,
> _Statement_, _ResultSet_, _ResultSetMetadata_ interfaces for a JDBC using our
> _Database_ class as core binary loader at the begining.
> The main difficulty is to respond to a SQL request, and first : being able to
> analyze it to understand what is expected.
> The SQL request analysis is a very strong job, but I suggest to ease it a lot
> by relying on _AntLR_ API for grammar analysis, associated with a BNF grammar
> file, maybe taken from ^1^ or from elsewhere (grammars are of public domain).
> The goal of this current JIRA is only to be able to perform a
> _SELECT * FROM _
> The WHERE clause or the selection of fields, will come later in other JIRA.
> No transactions, classic _Statement_ only.
> _PreparedStatement_ would be also implemented later (another JIRA).
> Of course, this improvment can be discarded if an open source or free driver
> is discovered, that would allow us to execute SQL requests on DBase 3 easily.
> ^1^ For example, [http://www.savage.net.au/SQL/] has some BNF, but maybe
> elsewhere they will more compliant with AntLR.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SIS-177) Translate the developer guide to English
[ https://issues.apache.org/jira/browse/SIS-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux updated SIS-177: Assignee: Christina Hough > Translate the developer guide to English > > > Key: SIS-177 > URL: https://issues.apache.org/jira/browse/SIS-177 > Project: Spatial Information Systems > Issue Type: Task > Components: Documentation >Reporter: Martin Desruisseaux >Assignee: Christina Hough > Attachments: developer-guide-en.html, developer-guide-en.html, > developer-guide2.html > > > A developer guide (still incomplete) is available at > http://sis.staging.apache.org/book/fr/developer-guide.html . However the > guide has been written in French, in part because based on existing material > (e.g. some chapters written during thesis). This task is about translating > the guide to English. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (SIS-177) Translate the developer guide to English
[ https://issues.apache.org/jira/browse/SIS-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux resolved SIS-177. - Resolution: Fixed > Translate the developer guide to English > > > Key: SIS-177 > URL: https://issues.apache.org/jira/browse/SIS-177 > Project: Spatial Information Systems > Issue Type: Task > Components: Documentation >Reporter: Martin Desruisseaux >Assignee: Christina Hough > Attachments: developer-guide-en.html, developer-guide-en.html, > developer-guide2.html > > > A developer guide (still incomplete) is available at > http://sis.staging.apache.org/book/fr/developer-guide.html . However the > guide has been written in French, in part because based on existing material > (e.g. some chapters written during thesis). This task is about translating > the guide to English. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (SIS-182) More dynamic table of content for the web site
Martin Desruisseaux created SIS-182: --- Summary: More dynamic table of content for the web site Key: SIS-182 URL: https://issues.apache.org/jira/browse/SIS-182 Project: Spatial Information Systems Issue Type: Improvement Components: Web site Reporter: Martin Desruisseaux Priority: Minor Consider moving the Table Of Content in a HTML frame on the left side, to be always visible. The highlighted item should change when the user scroll down the page. This can be done using the Tocify plugin: * http://gregfranko.com/jquery.tocify.js/ * http://errietta.me/blog/tocify-scrollspy/ Note that Tocify generate the TOC dynamically by scanning the HTML page. Given the size of that page, it may not be desirable. Instead, we may want a static TOC with only the "scrollspy" feature of Tocify. * http://www.tutorialspoint.com/bootstrap/bootstrap_scrollspy_plugin.htm -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SIS-182) More dynamic table of content for the developer guide
[ https://issues.apache.org/jira/browse/SIS-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux updated SIS-182: Summary: More dynamic table of content for the developer guide (was: More dynamic table of content for the web site) > More dynamic table of content for the developer guide > - > > Key: SIS-182 > URL: https://issues.apache.org/jira/browse/SIS-182 > Project: Spatial Information Systems > Issue Type: Improvement > Components: Web site >Reporter: Martin Desruisseaux >Priority: Minor > > Consider moving the Table Of Content in a HTML frame on the left side, to be > always visible. The highlighted item should change when the user scroll down > the page. This can be done using the Tocify plugin: > * http://gregfranko.com/jquery.tocify.js/ > * http://errietta.me/blog/tocify-scrollspy/ > Note that Tocify generate the TOC dynamically by scanning the HTML page. > Given the size of that page, it may not be desirable. Instead, we may want a > static TOC with only the "scrollspy" feature of Tocify. > * http://www.tutorialspoint.com/bootstrap/bootstrap_scrollspy_plugin.htm -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SIS-182) More dynamic table of content for the developer guide
[ https://issues.apache.org/jira/browse/SIS-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux updated SIS-182: Description: The developer guide (http://sis.apache.org/book/en/developer-guide.html) currently contains a static Table Of Content (TOC). Consider moving that Table Of Content in a HTML frame on the left side, to be always visible. The highlighted item should change when the user scroll down the page. This can be done using the Tocify plugin: * http://gregfranko.com/jquery.tocify.js/ * http://errietta.me/blog/tocify-scrollspy/ Note that Tocify generate the TOC dynamically by scanning the HTML page. Given the size of that page, it may not be desirable. Instead, we may want a static TOC with only the "scrollspy" feature of Tocify. * http://www.tutorialspoint.com/bootstrap/bootstrap_scrollspy_plugin.htm was: Consider moving the Table Of Content in a HTML frame on the left side, to be always visible. The highlighted item should change when the user scroll down the page. This can be done using the Tocify plugin: * http://gregfranko.com/jquery.tocify.js/ * http://errietta.me/blog/tocify-scrollspy/ Note that Tocify generate the TOC dynamically by scanning the HTML page. Given the size of that page, it may not be desirable. Instead, we may want a static TOC with only the "scrollspy" feature of Tocify. * http://www.tutorialspoint.com/bootstrap/bootstrap_scrollspy_plugin.htm > More dynamic table of content for the developer guide > - > > Key: SIS-182 > URL: https://issues.apache.org/jira/browse/SIS-182 > Project: Spatial Information Systems > Issue Type: Improvement > Components: Web site >Reporter: Martin Desruisseaux >Priority: Minor > > The developer guide (http://sis.apache.org/book/en/developer-guide.html) > currently contains a static Table Of Content (TOC). Consider moving that > Table Of Content in a HTML frame on the left side, to be always visible. The > highlighted item should change when the user scroll down the page. This can > be done using the Tocify plugin: > * http://gregfranko.com/jquery.tocify.js/ > * http://errietta.me/blog/tocify-scrollspy/ > Note that Tocify generate the TOC dynamically by scanning the HTML page. > Given the size of that page, it may not be desirable. Instead, we may want a > static TOC with only the "scrollspy" feature of Tocify. > * http://www.tutorialspoint.com/bootstrap/bootstrap_scrollspy_plugin.htm -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SIS-183) Basic Geometry Operations
[
https://issues.apache.org/jira/browse/SIS-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14168236#comment-14168236
]
Martin Desruisseaux commented on SIS-183:
-
Thanks for bringing this topic. There is some elements of context:
* The geometry projection part (including referencing WKT parsing) is actually
an independent topic. This is the subject of {{sis-referencing}} module. This
work exists in Geotk and its port to {{sis-referencing}} is expected to resume
this month.
* For two dimensional geometries in a Cartesian space, there is a library by
[ESRI under Apache 2 license|https://github.com/Esri/geometry-api-java] which
can be used as a starting point. This is the library currently used by the
{{sis-shapefile}} module.
* For three dimensional geometries, or for two-dimensional geometries in a
curved space like Earth surface, we may have to write from scratch. However the
ISO 19107 specification is under revision and not yet completed.
> Basic Geometry Operations
> -
>
> Key: SIS-183
> URL: https://issues.apache.org/jira/browse/SIS-183
> Project: Spatial Information Systems
> Issue Type: Wish
> Components: Geometry objects
> Environment: java 6 or 7
>Reporter: Mark Giaconia
>
> It would be very useful to have some basic geometry operations available,
> such as:
> - Read WKT, CSV, or shapefile into a geometry object in which the attribute
> tables are stored as a HashMap, geom projection info etc.
> - Buffer, and intersect (contains, within, overlaps equivalent in RDBMSs)
> operations via a method for passing in a geom to compare against a geom
> collection.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SIS-183) Basic Geometry Operations
[
https://issues.apache.org/jira/browse/SIS-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14168939#comment-14168939
]
Martin Desruisseaux commented on SIS-183:
-
Thanks Mark for the proposal. We have no domain model specifically for Geotk.
However we use the OGC/ISO international standard as our domain model for large
parts. The OGC standards (not the ISO ones) can be downloaded for free, but
there is so many of them that one can be lost. We try to provide an overview
for Apache SIS here:
* http://sis.apache.org/book/en/developer-guide.html
This is a work in progress, really just scratching the surface for now. If you
have a chance to take a look to this document, any help improving clarity or
completing the document would be greatly appreciated :-).
About the port of Geotk objects, it depends if we talk about geometries or
other modules. If the focus is on geometry, then there is not many thing that
we can get from Geotk - we are probably better to start from scratch in Apache
SIS. If there is interest in other modules, then maybe we should open a
separated thread?
On geometry-related classes, Apache SIS currently contains 3 very basic types.
Note that none of them are formally geometry, in that they do not extends any
{{Geometry}} base class:
*
http://sis.apache.org/apidocs/org/apache/sis/geometry/GeneralDirectPosition.html
* http://sis.apache.org/apidocs/org/apache/sis/geometry/GeneralEnvelope.html
*
http://sis.apache.org/apidocs/org/apache/sis/metadata/iso/extent/DefaultGeographicBoundingBox.html
The domain model for a more complete geometry library would be the ISO 19107
specification. However this specification is under revision right now, which
complicate the task of creating an implementation now. This domain model has
been translated (with some differences) into Java API there:
*
http://www.geoapi.org/snapshot/pending/org/opengis/geometry/package-summary.html
* Sub-packages of above
However in its current state, the above is a mix of ISO 19107 formal release,
ISO 19107 draft, and a few idea from an other library (Java Topology Suite
(JTS)). It is guaranteed to change, and would at least need a little bit of
cleaning before to implement them.
So would you like to work on geometry or on other aspects? If the work would be
on geometry, I see two paths (we would probably need to do both anyway):
* Define a set of classes close to the above-cited API (without implementing
the interfaces for now). The implementation would delegate the work to the ESRI
library or an other library. In other words, just wraps an existing library
into an ISO 19107 API.
* Define a set of classes close to the above-cited API, and try to provide a
truly 3-dimensional implementation of them (if we do only a two-dimensional
implementation in a Cartesian space, I don't think that our library would have
an advantage over the existing ESRI and JTS ones).
> Basic Geometry Operations
> -
>
> Key: SIS-183
> URL: https://issues.apache.org/jira/browse/SIS-183
> Project: Spatial Information Systems
> Issue Type: Wish
> Components: Geometry objects
> Environment: java 6 or 7
>Reporter: Mark Giaconia
>
> It would be very useful to have some basic geometry operations available,
> such as:
> - Read WKT, CSV, or shapefile into a geometry object in which the attribute
> tables are stored as a HashMap, geom projection info etc.
> - Buffer, and intersect (contains, within, overlaps equivalent in RDBMSs)
> operations via a method for passing in a geom to compare against a geom
> collection.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (SIS-180) Place a crude JDBC driver over Dbase files
[ https://issues.apache.org/jira/browse/SIS-180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux reassigned SIS-180: --- Assignee: Martin Desruisseaux > Place a crude JDBC driver over Dbase files > -- > > Key: SIS-180 > URL: https://issues.apache.org/jira/browse/SIS-180 > Project: Spatial Information Systems > Issue Type: Improvement > Components: Storage >Affects Versions: 0.5 >Reporter: M. Le Bihan >Assignee: Martin Desruisseaux >Priority: Minor > Fix For: 0.5 > > Attachments: src.zip > > > It would be useful to be able to query DBF content through SQL. > But there are no free drivers available for the old _Dbase 3_ format. > The first step is to create short implementations of _Connection_, > _Statement_, _ResultSet_, _ResultSetMetadata_ interfaces for a JDBC using our > _Database_ class as core binary loader at the begining. > The main difficulty is to respond to a SQL request, and first : being able to > analyze it to understand what is expected. > The SQL request analysis is a very strong job, but I suggest to ease it a lot > by relying on _AntLR_ API for grammar analysis, associated with a BNF grammar > file, maybe taken from ^1^ or from elsewhere (grammars are of public domain). > The goal of this current JIRA is only to be able to perform a > _SELECT * FROM _ > The WHERE clause or the selection of fields, will come later in other JIRA. > No transactions, classic _Statement_ only. > _PreparedStatement_ would be also implemented later (another JIRA). > Of course, this improvment can be discarded if an open source or free driver > is discovered, that would allow us to execute SQL requests on DBase 3 easily. > ^1^ For example, [http://www.savage.net.au/SQL/] has some BNF, but maybe > elsewhere they will more compliant with AntLR. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SIS-180) Place a crude JDBC driver over Dbase files
[
https://issues.apache.org/jira/browse/SIS-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14169542#comment-14169542
]
Martin Desruisseaux commented on SIS-180:
-
Thanks Marc. I installed your code on my local copy and looked at it. I didn't
saw any license header, while the Apache foundation requires us to put the
Apache 2 license in every Java source files. I could easily copy-and-paste
them, but can not do that without your formal authorization. Would it be
possible to follow those steps, if you accept of course? It should take only
about 10 minutes:
* Go to http://www.apache.org/licenses/icla.txt
* Print that page.
* Fill it and sign it.
* Scan it as a PDF document
* Send the PDF by email to the Apache secretary (address is given on the page).
* Inform us when you got the reply from the secretary (they are usually fast).
Note that it does not remove any of your rights on your code - you are still
free to do all you want with your original copies.
On technical topics, would you mind if I apply the following editions?
* I would like to put the {{org.apache.sis.storage.database*}} classes as
package-privated classes in {{org.apache.sis.storage.shapefile}} for now. It is
not necessarily forever - we could make them public later. But it is much
easier to start strict, then relax later if needed, than the converse.
* We could integrate the resource files with the Apache SIS resource systems.
It is an extension of the standard {{ResourceBundle}} which take cares of using
{{MessageFormat}} itself, so we don't have to repeat the later in every classes
using resources.
> Place a crude JDBC driver over Dbase files
> --
>
> Key: SIS-180
> URL: https://issues.apache.org/jira/browse/SIS-180
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Storage
>Affects Versions: 0.5
>Reporter: M. Le Bihan
>Assignee: Martin Desruisseaux
>Priority: Minor
> Fix For: 0.5
>
> Attachments: src.zip
>
>
> It would be useful to be able to query DBF content through SQL.
> But there are no free drivers available for the old _Dbase 3_ format.
> The first step is to create short implementations of _Connection_,
> _Statement_, _ResultSet_, _ResultSetMetadata_ interfaces for a JDBC using our
> _Database_ class as core binary loader at the begining.
> The main difficulty is to respond to a SQL request, and first : being able to
> analyze it to understand what is expected.
> The SQL request analysis is a very strong job, but I suggest to ease it a lot
> by relying on _AntLR_ API for grammar analysis, associated with a BNF grammar
> file, maybe taken from ^1^ or from elsewhere (grammars are of public domain).
> The goal of this current JIRA is only to be able to perform a
> _SELECT * FROM _
> The WHERE clause or the selection of fields, will come later in other JIRA.
> No transactions, classic _Statement_ only.
> _PreparedStatement_ would be also implemented later (another JIRA).
> Of course, this improvment can be discarded if an open source or free driver
> is discovered, that would allow us to execute SQL requests on DBase 3 easily.
> ^1^ For example, [http://www.savage.net.au/SQL/] has some BNF, but maybe
> elsewhere they will more compliant with AntLR.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (SIS-180) Place a crude JDBC driver over Dbase files
[ https://issues.apache.org/jira/browse/SIS-180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux reopened SIS-180: - Reopen for the time of the process of committing to Subversion. > Place a crude JDBC driver over Dbase files > -- > > Key: SIS-180 > URL: https://issues.apache.org/jira/browse/SIS-180 > Project: Spatial Information Systems > Issue Type: Improvement > Components: Storage >Affects Versions: 0.5 >Reporter: M. Le Bihan >Assignee: Martin Desruisseaux >Priority: Minor > Fix For: 0.5 > > Attachments: src.zip > > > It would be useful to be able to query DBF content through SQL. > But there are no free drivers available for the old _Dbase 3_ format. > The first step is to create short implementations of _Connection_, > _Statement_, _ResultSet_, _ResultSetMetadata_ interfaces for a JDBC using our > _Database_ class as core binary loader at the begining. > The main difficulty is to respond to a SQL request, and first : being able to > analyze it to understand what is expected. > The SQL request analysis is a very strong job, but I suggest to ease it a lot > by relying on _AntLR_ API for grammar analysis, associated with a BNF grammar > file, maybe taken from ^1^ or from elsewhere (grammars are of public domain). > The goal of this current JIRA is only to be able to perform a > _SELECT * FROM _ > The WHERE clause or the selection of fields, will come later in other JIRA. > No transactions, classic _Statement_ only. > _PreparedStatement_ would be also implemented later (another JIRA). > Of course, this improvment can be discarded if an open source or free driver > is discovered, that would allow us to execute SQL requests on DBase 3 easily. > ^1^ For example, [http://www.savage.net.au/SQL/] has some BNF, but maybe > elsewhere they will more compliant with AntLR. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SIS-180) Place a crude JDBC driver over Dbase files
[
https://issues.apache.org/jira/browse/SIS-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14171208#comment-14171208
]
Martin Desruisseaux commented on SIS-180:
-
Committed on the JDK8 branch. But before to continue on JDBC support, would it
be possible to do some consolidation work?
I applied the following changes:
* Renamed package as {{org.apache.sis.internal.shapefile.jdbc}}, so those
classes will be hidden from public API.
* Renamed {{XXXUnimplementedFeature}} classes as {{AbstractXXX}}.
* Omitted {{DBaseJDBCDriverUnhandledOperationException}}. Used
{{java.sql.SQLFeatureNotSupportedException}} instead.
* Removed all {{throw new RuntimeException("Should not have been there")}}
lines since they were unnecessary (note: {{throw new AssertionError(...)}}
would have been more accurate). See the code for the simplification trick.
* Defined {{InvalidDbaseFileFormatException}} as a subtype of
{{SQLNonTransientException}} instead than {{SQLException}}.
Would you have a chance to apply the following proposed consolidation, if you
agree?
* Please configure your IDE for using spaces rather than tabulations, since not
all editors have the same tabulation width.
* Remove the {{public}} modifier for every classes that do not need to be
accessed from outside the package.
* Replace star imports by explicit imports, unless there is really a lot of
them (e.g. more than 8 from the same package).
* Minor grammatical note: Javadoc convention asks us to use the third person in
the first sentence of method javadoc (e.g. "Format*s*" instead than "Format").
* Some classes have {{\@SuppressWarnings("unused")}} annotation in front of
every arguments, which make method signature very verbose. {{"unused"}} is not
a value recognized by the Oracle {{javac}} compiler (as of JDK8). I presume
that this is an Eclipse-specific one? If this annotation is really desired, I
suggest to put it at the class level at least in {{AbstractFoo}} classes, for
avoiding to repeat it hundred of times.
* {{unsupportedOperation}} method excepts the source class and method in
argument. But this information is not complete at least in
{{AbstractResultSet}}. We could complete them... but given that this
information duplicates the stack trace information, maybe it could also be
completely omitted.
* It may be worth to take a look at the Javadoc of all JDBC methods and see if
some of them are optional. I suspect that not all methods need to throws a
{{SQLFeatureNotSupportedException}}.
* In the Javadoc, I guess that all the {{\@see the_implemented_JDBC_method}}
were inserted by Eclipse? Since the Javadoc tool generates this information
automatically in the "Specified by" section, those automatically generated
{{\@see}} tags are redundant and could be omitted.
> Place a crude JDBC driver over Dbase files
> --
>
> Key: SIS-180
> URL: https://issues.apache.org/jira/browse/SIS-180
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Storage
>Affects Versions: 0.5
>Reporter: M. Le Bihan
>Assignee: Martin Desruisseaux
>Priority: Minor
> Fix For: 0.5
>
> Attachments: src.zip
>
>
> It would be useful to be able to query DBF content through SQL.
> But there are no free drivers available for the old _Dbase 3_ format.
> The first step is to create short implementations of _Connection_,
> _Statement_, _ResultSet_, _ResultSetMetadata_ interfaces for a JDBC using our
> _Database_ class as core binary loader at the begining.
> The main difficulty is to respond to a SQL request, and first : being able to
> analyze it to understand what is expected.
> The SQL request analysis is a very strong job, but I suggest to ease it a lot
> by relying on _AntLR_ API for grammar analysis, associated with a BNF grammar
> file, maybe taken from ^1^ or from elsewhere (grammars are of public domain).
> The goal of this current JIRA is only to be able to perform a
> _SELECT * FROM _
> The WHERE clause or the selection of fields, will come later in other JIRA.
> No transactions, classic _Statement_ only.
> _PreparedStatement_ would be also implemented later (another JIRA).
> Of course, this improvment can be discarded if an open source or free driver
> is discovered, that would allow us to execute SQL requests on DBase 3 easily.
> ^1^ For example, [http://www.savage.net.au/SQL/] has some BNF, but maybe
> elsewhere they will more compliant with AntLR.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SIS-180) Place a crude JDBC driver over Dbase files
[
https://issues.apache.org/jira/browse/SIS-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14171982#comment-14171982
]
Martin Desruisseaux commented on SIS-180:
-
On the star imports, there is no absolute rule. This is a compromise depending
on the amount of imports. If there is only 3 or 4 classes to import from a
package, enumerating them does not pollute the code so much. But if a package
is imported almost entirely, then a star import makes lot of sense. Between the
2 the frontier is not clear.
The reason for enumerating the imports explicitly is to protect the code
against name collision between two packages. The problem may not exist at the
time of writing a code, but appears later when new classes are added in the
imported packages. An historical example is the name collision between
{{java.awt.List}} and {{java.util.List}} when the later has been added to Java
1.2: some code using start imports that compiled under Java 1.1 did not
compiled anymore under Java 1.2.
However I agree about long list of imports not being easy to read - there is a
balance somewhere between enumerating everything and all start imports.
> Place a crude JDBC driver over Dbase files
> --
>
> Key: SIS-180
> URL: https://issues.apache.org/jira/browse/SIS-180
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Storage
>Affects Versions: 0.5
>Reporter: M. Le Bihan
>Assignee: Martin Desruisseaux
>Priority: Minor
> Fix For: 0.5
>
> Attachments: src.zip
>
>
> It would be useful to be able to query DBF content through SQL.
> But there are no free drivers available for the old _Dbase 3_ format.
> The first step is to create short implementations of _Connection_,
> _Statement_, _ResultSet_, _ResultSetMetadata_ interfaces for a JDBC using our
> _Database_ class as core binary loader at the begining.
> The main difficulty is to respond to a SQL request, and first : being able to
> analyze it to understand what is expected.
> The SQL request analysis is a very strong job, but I suggest to ease it a lot
> by relying on _AntLR_ API for grammar analysis, associated with a BNF grammar
> file, maybe taken from ^1^ or from elsewhere (grammars are of public domain).
> The goal of this current JIRA is only to be able to perform a
> _SELECT * FROM _
> The WHERE clause or the selection of fields, will come later in other JIRA.
> No transactions, classic _Statement_ only.
> _PreparedStatement_ would be also implemented later (another JIRA).
> Of course, this improvment can be discarded if an open source or free driver
> is discovered, that would allow us to execute SQL requests on DBase 3 easily.
> ^1^ For example, [http://www.savage.net.au/SQL/] has some BNF, but maybe
> elsewhere they will more compliant with AntLR.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Work started] (SIS-180) Place a crude JDBC driver over Dbase files
[ https://issues.apache.org/jira/browse/SIS-180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SIS-180 started by Martin Desruisseaux. --- > Place a crude JDBC driver over Dbase files > -- > > Key: SIS-180 > URL: https://issues.apache.org/jira/browse/SIS-180 > Project: Spatial Information Systems > Issue Type: Improvement > Components: Storage >Affects Versions: 0.5 >Reporter: M. Le Bihan >Assignee: Martin Desruisseaux >Priority: Minor > Fix For: 0.5 > > Attachments: src.zip > > > It would be useful to be able to query DBF content through SQL. > But there are no free drivers available for the old _Dbase 3_ format. > The first step is to create short implementations of _Connection_, > _Statement_, _ResultSet_, _ResultSetMetadata_ interfaces for a JDBC using our > _Database_ class as core binary loader at the begining. > The main difficulty is to respond to a SQL request, and first : being able to > analyze it to understand what is expected. > The SQL request analysis is a very strong job, but I suggest to ease it a lot > by relying on _AntLR_ API for grammar analysis, associated with a BNF grammar > file, maybe taken from ^1^ or from elsewhere (grammars are of public domain). > The goal of this current JIRA is only to be able to perform a > _SELECT * FROM _ > The WHERE clause or the selection of fields, will come later in other JIRA. > No transactions, classic _Statement_ only. > _PreparedStatement_ would be also implemented later (another JIRA). > Of course, this improvment can be discarded if an open source or free driver > is discovered, that would allow us to execute SQL requests on DBase 3 easily. > ^1^ For example, [http://www.savage.net.au/SQL/] has some BNF, but maybe > elsewhere they will more compliant with AntLR. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SIS-180) Place a crude JDBC driver over Dbase files
[
https://issues.apache.org/jira/browse/SIS-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14181534#comment-14181534
]
Martin Desruisseaux commented on SIS-180:
-
Thanks for the new JIRA task. I have applied a few changes in the JDBC classes:
* Replaced {{InvalidDbaseFileFormatException}} by the standard
{{SQLNonTransientConnectionException}}. Especially since the former moved to
SIS internal packages, it can theoretically not be known to the user.
* Replaced the resource properties files by the SIS mechanism (which is itself
built on top of JDK resource bundles):
** Collapsed {{AbstractJDBC.properties}}, {{DBFConnection.properties}},
{{DBFResultSet.properties}} and {{DBFStatement.properties}} in a single
{{Resources.properties}} file. This avoid redundancies like the message for
closed connection, which was repeated in different resource files.
** Moved {{Resources.properties}} from the {{src/main/resources}} to the
{{src/main/java}} directory. While not a Java source, the SIS mechanism does
not bundle the properties file directly in the JAR file neither. The resources
are instead bundled in a kind of compiled form by our {{sis-build-helper}}
plugin.
** Element order in {{Resources.properties}} file does not matter. I tend to
use alphabetical order, but any other order is okay as long as this is
structured in a way easy to find when the file has a lot of resources. It is
okay to put large comment explaining the logic (if desired), since those
comments are omitted in the compiled result.
** Some differences between French and English languages: French quotation
marks versus English quotation marks, a space before ":" in French but not in
English. In French the space before ":" or adjacent to the quotation marks is
{{\\u202f}} (narrow no-break space). The easiest way to edit is to always
copy-and-paste those character sequences instead than typing them.
** When using the SIS resources, the key names need to be valid Java
identifiers. I omit the "exception" or "log" prefix since I found (in other
resources) that the same message can sometime be used in both case. By
convention, I use the "_(number of arguments)" prefix in order to see in source
code how many arguments are expected. This reduce the risk of errors.
** Single quote does not need to be doubled in the SIS resource files for
{{MessageFormat}} compliance. This is done automatically by SIS resource
compiler.
** Note the {{Resources.java}} file, which contains static constants for the
resource keys in order to ensure compile-time safety. We don't need to edit
this file manually: just add new entries in the {{*.properties}} files, then
run {{mvn compile}} from the command line (it is okay to be only in the
{{sis-shapefile}} directory for faster compilation). The {{Resources.java}}
file will be updated automatically.
* The {{throw new SQLException(...)}} instructions were also logging a warning
at the {{SEVERE}} level. I took the liberty to omit the logging step. I think
we should either log a warning or throw an exception, but not both. Furthermore
{{Level.SEVERE}} should be reserved for serious problem which compromise the
system (or Apache SIS library as a whole) integrity. Its usage should be very
rare.
* Omit the {{m_}} prefix for member fields. While this convention is sometime
used, this is not really the usage in Java.
* Edited javadoc for uniformity with other SIS classes and re-arranged the
method order in an attempt to keep related methods together (the order in JDBC
interfaces is more historical than logical).
* Provided default implementation when a sensible behaviour exists. For example
all {{get}} and {{update}} method of {{ResultSet}} with a {{String
columnLabel}} argument convert the label to an index by invoking
{{findColumn(String)}}, then delegate to the method having a {{int
columnIndex}} argument. Also some method like {{first()}}, {{previous()}},
{{relative(int)}} etc. can delegate their work to {{absolute(int)}}. For each
class, a table in the class javadoc document most of the default
implementations.
Open questions:
* {{AbstractConnection.rollback()}} log a warning. I would have expected an
exception to be thrown, since a change that the user may have expected in the
database did not occurred because of unsupported functionality. This is
different than {{commit()}}, which may have invisible effect.
* Same idea apply to all setters: it seems to me that all of them shall thrown
an exception instead than logging a warning. This is the same idea than
{{java.util.AbstractCollection}} for instance. Some exception to this rule
would be when the given value is the expected one. For instance
{{AbstractConnection.setAutoCommit(boolean)}} would throw an exception only if
the given value is {{false}}.
* Probably some getters do not need to log a warning. For example
{{Connection.getTypeMap(
[jira] [Commented] (SIS-184) DBase 3 - JDBC : Simple WHERE CLAUSE and Integer, Double field support
[ https://issues.apache.org/jira/browse/SIS-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14198039#comment-14198039 ] Martin Desruisseaux commented on SIS-184: - Hello Marc Thanks a lot for all your work. I think that you have commit access now, isn't it? > DBase 3 - JDBC : Simple WHERE CLAUSE and Integer, Double field support > -- > > Key: SIS-184 > URL: https://issues.apache.org/jira/browse/SIS-184 > Project: Spatial Information Systems > Issue Type: Improvement > Components: Features, Storage >Affects Versions: 0.5 >Reporter: M. Le Bihan >Priority: Minor > Attachments: SIS184_attach_DBase3_driver_to_Squirrel.png, > SIS184_connect_to_database.png, SIS184_create_alias_to_a_dbase3_file.png, > SIS184_query_the_table.png, SIS184_table_metadata.png > > > Following the SIS-180 (select * from DBF) this improvment will add the > ability to : > * Obtain field values from Integer and Double fields. > * Add a simple WHERE clause with = , >, <, >=, <=, <> operators. > Relational operators (AND, OR) _might be_ implemented too, depending on the > ability of parsing the query easily or not. Else, this feature will come in > another JIRA. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SIS-184) DBase 3 - JDBC : Simple WHERE CLAUSE and Integer, Double field support
[
https://issues.apache.org/jira/browse/SIS-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14201350#comment-14201350
]
Martin Desruisseaux commented on SIS-184:
-
The Git repository is only a mirror. The "real" repository is SVN. Any commit
on SVN is almost immediately reflected on the Git mirror. I suggest that you
checkout the JDK8 branch:
{noformat}
svn checkout https://svn.apache.org/repos/asf/sis/branches/JDK8 sis
{noformat}
There is a guide for new committers here:
http://www.apache.org/dev/new-committers-guide.html
Just a quick note about subversion just in case: I do not know if there is any
files that need to be moved or renamed. But if it is the case, when moving
files around, Git detects those move automatically but not SVN; we should not
forget to use {{svn move}} in order to keep trace of the history (not
necessarily an inconvenient since auto-detection does not always give the
expected results, but this is an other story).
> DBase 3 - JDBC : Simple WHERE CLAUSE and Integer, Double field support
> --
>
> Key: SIS-184
> URL: https://issues.apache.org/jira/browse/SIS-184
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Features, Storage
>Affects Versions: 0.5
>Reporter: M. Le Bihan
>Priority: Minor
> Attachments: SIS184_attach_DBase3_driver_to_Squirrel.png,
> SIS184_connect_to_database.png, SIS184_create_alias_to_a_dbase3_file.png,
> SIS184_query_the_table.png, SIS184_table_metadata.png
>
>
> Following the SIS-180 (select * from DBF) this improvment will add the
> ability to :
> * Obtain field values from Integer and Double fields.
> * Add a simple WHERE clause with = , >, <, >=, <=, <> operators.
> Relational operators (AND, OR) _might be_ implemented too, depending on the
> ability of parsing the query easily or not. Else, this feature will come in
> another JIRA.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SIS-184) DBase 3 - JDBC : Simple WHERE CLAUSE and Integer, Double field support
[ https://issues.apache.org/jira/browse/SIS-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14215951#comment-14215951 ] Martin Desruisseaux commented on SIS-184: - Would you like that I commit those files, or would you like that we try to resolve SVN access first? In my understanding, the next step would be that you chose an ID which is not already used in http://people.apache.org/committer-index.html > DBase 3 - JDBC : Simple WHERE CLAUSE and Integer, Double field support > -- > > Key: SIS-184 > URL: https://issues.apache.org/jira/browse/SIS-184 > Project: Spatial Information Systems > Issue Type: Improvement > Components: Features, Storage >Affects Versions: 0.5 >Reporter: M. Le Bihan >Priority: Minor > Attachments: SIS184_attach_DBase3_driver_to_Squirrel.png, > SIS184_connect_to_database.png, SIS184_create_alias_to_a_dbase3_file.png, > SIS184_query_the_table.png, SIS184_table_metadata.png, > SIS184_where_statement.png, git_svn.png, sis-shapefile.zip, > sis-utility.org.apache.sis.util.logging.zip > > > Following the SIS-180 (select * from DBF) this improvment will add the > ability to : > * Obtain field values from Integer and Double fields. > * Add a simple WHERE clause with = , >, <, >=, <=, <> operators. > Relational operators (AND, OR) _might be_ implemented too, depending on the > ability of parsing the query easily or not. Else, this feature will come in > another JIRA. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SIS-184) DBase 3 - JDBC : Simple WHERE CLAUSE and Integer, Double field support
[ https://issues.apache.org/jira/browse/SIS-184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux updated SIS-184: Component/s: (was: Features) (was: Storage) Shapefile > DBase 3 - JDBC : Simple WHERE CLAUSE and Integer, Double field support > -- > > Key: SIS-184 > URL: https://issues.apache.org/jira/browse/SIS-184 > Project: Spatial Information Systems > Issue Type: Improvement > Components: Shapefile >Affects Versions: 0.5 >Reporter: M. Le Bihan >Priority: Minor > Fix For: 0.5 > > Attachments: SIS184_attach_DBase3_driver_to_Squirrel.png, > SIS184_connect_to_database.png, SIS184_create_alias_to_a_dbase3_file.png, > SIS184_query_the_table.png, SIS184_table_metadata.png, > SIS184_where_statement.png, git_svn.png, sis-shapefile.zip, > sis-utility.org.apache.sis.util.logging.zip > > > Following the SIS-180 (select * from DBF) this improvment will add the > ability to : > * Obtain field values from Integer and Double fields. > * Add a simple WHERE clause with = , >, <, >=, <=, <> operators. > Relational operators (AND, OR) _might be_ implemented too, depending on the > ability of parsing the query easily or not. Else, this feature will come in > another JIRA. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SIS-180) Place a crude JDBC driver over Dbase files
[ https://issues.apache.org/jira/browse/SIS-180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux updated SIS-180: Component/s: (was: Storage) Shapefile > Place a crude JDBC driver over Dbase files > -- > > Key: SIS-180 > URL: https://issues.apache.org/jira/browse/SIS-180 > Project: Spatial Information Systems > Issue Type: Improvement > Components: Shapefile >Affects Versions: 0.5 >Reporter: M. Le Bihan >Assignee: Martin Desruisseaux >Priority: Minor > Fix For: 0.5 > > Attachments: src.zip > > > It would be useful to be able to query DBF content through SQL. > But there are no free drivers available for the old _Dbase 3_ format. > The first step is to create short implementations of _Connection_, > _Statement_, _ResultSet_, _ResultSetMetadata_ interfaces for a JDBC using our > _Database_ class as core binary loader at the begining. > The main difficulty is to respond to a SQL request, and first : being able to > analyze it to understand what is expected. > The SQL request analysis is a very strong job, but I suggest to ease it a lot > by relying on _AntLR_ API for grammar analysis, associated with a BNF grammar > file, maybe taken from ^1^ or from elsewhere (grammars are of public domain). > The goal of this current JIRA is only to be able to perform a > _SELECT * FROM _ > The WHERE clause or the selection of fields, will come later in other JIRA. > No transactions, classic _Statement_ only. > _PreparedStatement_ would be also implemented later (another JIRA). > Of course, this improvment can be discarded if an open source or free driver > is discovered, that would allow us to execute SQL requests on DBase 3 easily. > ^1^ For example, [http://www.savage.net.au/SQL/] has some BNF, but maybe > elsewhere they will more compliant with AntLR. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SIS-179) Extract Database class from Shapefile class to allow reading DBF without shapefile
[ https://issues.apache.org/jira/browse/SIS-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Desruisseaux updated SIS-179: Component/s: (was: Features) (was: Storage) Shapefile > Extract Database class from Shapefile class to allow reading DBF without > shapefile > -- > > Key: SIS-179 > URL: https://issues.apache.org/jira/browse/SIS-179 > Project: Spatial Information Systems > Issue Type: Improvement > Components: Shapefile >Affects Versions: 0.5 >Reporter: M. Le Bihan >Priority: Minor > Attachments: DataType.java, Database.java, FieldDescriptor.java, > ShapeFile.java, package-info.java > > > Extracting the DBF binary reader from th Shapefile class to a Database class > allows the loading of a DBF file when it is not accompanied with a shapefile. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SIS-100) Implement a ShapeFile data store
[
https://issues.apache.org/jira/browse/SIS-100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-100:
Component/s: (was: Storage)
Shapefile
> Implement a ShapeFile data store
>
>
> Key: SIS-100
> URL: https://issues.apache.org/jira/browse/SIS-100
> Project: Spatial Information Systems
> Issue Type: New Feature
> Components: Shapefile
>Reporter: Martin Desruisseaux
>
> Apache SIS needs a class for reading Shapefiles, and an other class for
> writing Shapefiles. The Shapefiles specification is available there:
> http://www.esri.com/library/whitepapers/pdfs/shapefile.pdf
> At the time of writing (May 2013), there is no infrastructure in Apache SIS
> for building such reader and writer. There is no {{DataStore}} interface, no
> {{Feature}} implementation, no {{Geometry}}, no
> {{CoordinateReferenceSystem}}. A Shapefiles reader and writer could only be a
> simple initial draft *which is guaranteed to break compatibility in future
> SIS releases*. If a volunteer wishes to experiment Shapefiles, it could be
> done as below:
> * Ignore (for now) any possible generic base, since there is no {{DataStore}}
> interface yet. API would be specific to the Shapefiles reader and writer.
> * Use (for now) {{java.util.Map}} instead of {{Feature}}, since the later are
> not yet available.
> * Use (for now) directly the ESRI open source geometry library, since there
> is no ISO geometries in SIS yet.
> * Ignore coordinate reference systems.
> Of course all the above would need to be revisited *in incompatible way* as
> more SIS services become available.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SIS-178) First property red in a DenseFeature returns a null value, next ones are ok.
[
https://issues.apache.org/jira/browse/SIS-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-178:
Component/s: (was: Storage)
> First property red in a DenseFeature returns a null value, next ones are ok.
>
>
> Key: SIS-178
> URL: https://issues.apache.org/jira/browse/SIS-178
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Features
>Affects Versions: 0.5
> Environment: Seen on branch JDK 8, but should be the same everywhere.
>Reporter: M. Le Bihan
>Assignee: Martin Desruisseaux
>Priority: Minor
> Fix For: 0.5
>
>
> The first field value asked in a _DenseFeature_ is always returning a null
> value, the next calls on the same feature are successful.
> Loading a sample shapefile from here
> [http://export.openstreetmap.fr/contours-administratifs/communes/92-Hauts-de-Seine.shp.tar.gz]
>
> If I attempt to query the values of a Feature this way : "REF_INSEE",
> "COMMUNE", "CODE_POSTA",
> I will receive : null, “a city name”, “a zip code”.
>
> If I try to query this way : "CODE_POSTA", "REF_INSEE", "COMMUNE",
> I will receive : null, “an INSEE code”, “a city name”.
>
> *Involved method :*
> {code:title=DenseFeature.java}
> @Override
> public Property getProperty(final String name) throws
> IllegalArgumentException {
> ArgumentChecks.ensureNonNull("name", name);
> final int index = getIndex(name);
> if (properties instanceof Property[]) {
> final Property property = ((Property[]) properties)[index];
> if (property != null) {
> return property;
> }
> } else {
> wrapValuesInProperties();
> }
> final Property property = createProperty(name);
> properties[index] = property;
> return property;
> }
> {code}
> *hypothesis :*
> after the init call of
> {code}wrapValuesInProperties();{code}
> the method assumes that it has done the same work it would have done with
> {code}final Property property = ((Property[])
> properties)[index];{code}
> but it’s not the case.
> The following unit test will show the problem :
> {code:title=IssuesWithFeaturesTest.java}
> package org.apache.sis.storage.shapefile;
> import static org.junit.Assert.*;
> import java.io.*;
> import org.apache.sis.storage.*;
> import org.junit.*;
> import org.opengis.feature.*;
> import org.opengis.test.*;
> /**
> * Issues with features.
> */
> public class IssuesWithFeaturesTest extends TestCase
> {
>/**
> * Issue : the first property red by DenseFeature is null.
> * @throws DataStoreException if unable to find or read the shapefile.
> * @throws IOException if unable to find or read the shapefile.
> */
>@Test public void issueFirstPropertyNull() throws IOException,
> DataStoreException {
> ShapeFile shapefile = new
> ShapeFile("src/test/resources/org/apache/sis/storage/shapefile/92-Hauts-de-Seine.shp");
> Feature feature = shapefile.FeatureMap.values().iterator().next(); //
> The shapefile has 36 features, take the first one.
> String city = (String)feature.getProperty("COMMUNE\0\0\0\0").getValue();
> String refInsee =
> (String)feature.getProperty("REF_INSEE\0\0").getValue();
> String zipCode = (String)feature.getProperty("CODE_POSTA\0").getValue();
> // The first feature property you read (city here) will return a null
> value.
> assertNotNull("The city should have an INSEE reference.", refInsee);
> assertNotNull("The city should have a zip code.", zipCode);
> assertNotNull("The city should have a name.", city);
>}
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SIS-186) Set Shapefile as a subclass of DataStore
Martin Desruisseaux created SIS-186:
---
Summary: Set Shapefile as a subclass of DataStore
Key: SIS-186
URL: https://issues.apache.org/jira/browse/SIS-186
Project: Spatial Information Systems
Issue Type: Sub-task
Components: Shapefile
Reporter: Martin Desruisseaux
{{Shapefile}} currently extends {{Object}}. It should extends
{{org.apache.sis.storage.DataStore}}, since the later is targeted as the base
class of all data readers (currently NetCDF and ISO 19139 metadata).
The intend of having a base class for all data readers is to allow applications
to process data without knowledge about whether the data are stored in a
Shapefile or a NetCDF file. The SIS command-line tools is an example of such
application.
In the current state of {{DataStore}} class, the main implication is that
{{Shapefile}} must implement the {{getMetadata()}} and {{close()}} methods. A
proposed implementation is attached to this task. Future {{DataStore}} versions
will require more methods, but their API is not yet designed.
Of course, if the {{DataStore}} API is considered problematic for
{{Shapefile}}, we can revisit it according feedbacks.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SIS-185) Define the commited API for Shapefile
Martin Desruisseaux created SIS-185:
---
Summary: Define the commited API for Shapefile
Key: SIS-185
URL: https://issues.apache.org/jira/browse/SIS-185
Project: Spatial Information Systems
Issue Type: Task
Components: Shapefile
Reporter: Martin Desruisseaux
We should define the first elements of what would be the committed API for
{{Shapefile}}. The intend of this task is not to define the full API neither to
change implementation details that are not visible through the API. The intend
is only to reduce the size of the public API to elements that, we think, have
good chances to stay there.
This task is targeted for completion before SIS 0.5 release. The intend is to
give some guarantees to Apache SIS 0.5 users that their code is likely to
compile and run with Apache SIS 0.6. To achieve this goal, the proposal is hide
the API elements which are likely to change, for preventing users to depend on
it. Those API elements can be hidden either by declaring them package-privated,
or by moving them in any {{org.apache.sis.internal}} sub-package, depending on
which approach is the less disruptive for the code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SIS-186) Set Shapefile as a subclass of DataStore
[
https://issues.apache.org/jira/browse/SIS-186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-186:
Attachment: ExtendsDataStore.patch
> Set Shapefile as a subclass of DataStore
>
>
> Key: SIS-186
> URL: https://issues.apache.org/jira/browse/SIS-186
> Project: Spatial Information Systems
> Issue Type: Sub-task
> Components: Shapefile
>Reporter: Martin Desruisseaux
> Attachments: ExtendsDataStore.patch
>
>
> {{Shapefile}} currently extends {{Object}}. It should extends
> {{org.apache.sis.storage.DataStore}}, since the later is targeted as the base
> class of all data readers (currently NetCDF and ISO 19139 metadata).
> The intend of having a base class for all data readers is to allow
> applications to process data without knowledge about whether the data are
> stored in a Shapefile or a NetCDF file. The SIS command-line tools is an
> example of such application.
> In the current state of {{DataStore}} class, the main implication is that
> {{Shapefile}} must implement the {{getMetadata()}} and {{close()}} methods. A
> proposed implementation is attached to this task. Future {{DataStore}}
> versions will require more methods, but their API is not yet designed.
> Of course, if the {{DataStore}} API is considered problematic for
> {{Shapefile}}, we can revisit it according feedbacks.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SIS-187) Reduce visibility of Shapefile fields
Martin Desruisseaux created SIS-187:
---
Summary: Reduce visibility of Shapefile fields
Key: SIS-187
URL: https://issues.apache.org/jira/browse/SIS-187
Project: Spatial Information Systems
Issue Type: Sub-task
Components: Shapefile
Reporter: Martin Desruisseaux
The {{Shapefile}} implementation contains many fields, and all of them are
currently public. Probably many of them could be private. Below is a list of
fields with a guess of whether users are likely to want this information, and
how he could obtain it.
h3. Fields that could be considered internal mechanic
* {{FileCode}}: currently used only in {{Shapefile.toString()}} implementation
without explanation.
* {{FileLength}}: currently used only in {{Shapefile.toString()}}
implementation. Potentially useful to the {{Shapefile}} reader itself, but
unlikely to be useful to external user since getting a useful meaning from a
file length require knowledge of the file format structure.
* {{Version}}: currently used only in {{Shapefile.toString()}} implementation.
Not clear if it is the file format version or the dataset version. In the
former case, this is an important information for the {{Shapefile}} reader but
less for other users. In the later case, it could be an ISO metadata property.
* {{dbf}}: a pointer to the underlying {{Database}} object. May be a dangerous
things to expose. If nevertheless we really want to give direct access to the
DBF database, maybe we should return a JDBC {{Connection}} instead.
h3. Information to be made accessible through a public API
* {{xmin}}, {{ymin}}, {{xmax}}, {{ymax}}: the spatial extent of the data. Could
be made accessible through the ISO 19115 {{GeographicBoundingBox}} element.
However it is unclear if those elements are always expressed in a geographic
CRS or if they can be in a projected CRS.
* {{zmin}}, {{zmax}}: the vertical extent of the data. Could be made accessible
through the ISO 19115 {{VerticalExtent}} element. However the {{VerticalCRS}}
of that extent is currently unknown.
* {{main}}, {{mmax}}: the javadoc does not said what those values are.
* {{FeatureMap}}: the set of {{Feature}} is indeed important, but maybe we
should return them through some kind of iterator (or a JDK8 {{Stream}} ?) for
fetching data on-demand (in a later implementation, not necessarily now) rather
than loading all of them at {{Shapefile}} construction time.
h3. Open questions
* {{ShapeType}}: currently used only in {{Shapefile.toString()}}
implementation. Tells whether the geometries are points, polygons, etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SIS-185) Define the commited API for Shapefile
[
https://issues.apache.org/jira/browse/SIS-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-185:
Description:
We should define the first elements of what would be the committed API for
{{Shapefile}}. The intend of this task is not to define the full API neither to
change implementation details that are not visible through the API. The intend
is only to reduce the size of the public API to elements that, we think, have
good chances to stay there.
This task is targeted for completion before SIS 0.5 release. The intend is to
give some guarantees to Apache SIS 0.5 users that their code is likely to
compile and run with Apache SIS 0.6. To achieve this goal, the proposal is to
hide the API elements which are likely to change, for preventing users to
depend on it. Those API elements can be hidden either by declaring them
package-privated, or by moving them in any {{org.apache.sis.internal}}
sub-package, depending on which approach is the less disruptive for the code.
was:
We should define the first elements of what would be the committed API for
{{Shapefile}}. The intend of this task is not to define the full API neither to
change implementation details that are not visible through the API. The intend
is only to reduce the size of the public API to elements that, we think, have
good chances to stay there.
This task is targeted for completion before SIS 0.5 release. The intend is to
give some guarantees to Apache SIS 0.5 users that their code is likely to
compile and run with Apache SIS 0.6. To achieve this goal, the proposal is hide
the API elements which are likely to change, for preventing users to depend on
it. Those API elements can be hidden either by declaring them package-privated,
or by moving them in any {{org.apache.sis.internal}} sub-package, depending on
which approach is the less disruptive for the code.
> Define the commited API for Shapefile
> -
>
> Key: SIS-185
> URL: https://issues.apache.org/jira/browse/SIS-185
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Shapefile
>Reporter: Martin Desruisseaux
>
> We should define the first elements of what would be the committed API for
> {{Shapefile}}. The intend of this task is not to define the full API neither
> to change implementation details that are not visible through the API. The
> intend is only to reduce the size of the public API to elements that, we
> think, have good chances to stay there.
> This task is targeted for completion before SIS 0.5 release. The intend is to
> give some guarantees to Apache SIS 0.5 users that their code is likely to
> compile and run with Apache SIS 0.6. To achieve this goal, the proposal is to
> hide the API elements which are likely to change, for preventing users to
> depend on it. Those API elements can be hidden either by declaring them
> package-privated, or by moving them in any {{org.apache.sis.internal}}
> sub-package, depending on which approach is the less disruptive for the code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SIS-188) Hide FieldDescriptor (a DBase3 internal format structure)
Martin Desruisseaux created SIS-188:
---
Summary: Hide FieldDescriptor (a DBase3 internal format structure)
Key: SIS-188
URL: https://issues.apache.org/jira/browse/SIS-188
Project: Spatial Information Systems
Issue Type: Sub-task
Components: Shapefile
Reporter: Martin Desruisseaux
The {{org.apache.sis.storage.shapefile}} package contains a {{FieldDescriptor}}
public class, which contain information that look likes very specific to the
internal of DBase format. For example:
* Field name as an array of bytes (this is not what user would usually handle,
which are rather {{String}} objects)
* Field address in memory (maybe an heritage from C/C++ ?)
* DBase+ Lan Reserved 2 (not sure what it is, documentation only said "reserved
2")
Those internal details should not be visible to the users. I suggest to either
declare the class package-privated, or move it to an internal package.
The {{FieldDescriptors}} class, which is a list of {{FieldDescriptor}}, should
also move in the same way.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SIS-189) InvalidDbaseFileFormatException should extend DataStoreException
Martin Desruisseaux created SIS-189:
---
Summary: InvalidDbaseFileFormatException should extend
DataStoreException
Key: SIS-189
URL: https://issues.apache.org/jira/browse/SIS-189
Project: Spatial Information Systems
Issue Type: Sub-task
Components: Shapefile
Reporter: Martin Desruisseaux
{{InvalidDbaseFileFormatException}} currently extends
{{SQLNonTransientException}}. But the the fact that a {{DataStore}} uses SQL or
I/O operations for fetching the data is considered internal to the data store.
The higher-level exception for data stores is rather {{DataStoreException}},
which may contain a {{SQLException}}, {{IOException}} or other kind of
exceptions as its cause.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SIS-94) Update SIS to revision 2014 of the ISO 19115 standard
[
https://issues.apache.org/jira/browse/SIS-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux resolved SIS-94.
Resolution: Fixed
Fix Version/s: 0.5
> Update SIS to revision 2014 of the ISO 19115 standard
> -
>
> Key: SIS-94
> URL: https://issues.apache.org/jira/browse/SIS-94
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Metadata
>Affects Versions: 0.3, 0.4
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Labels: gsoc2013
> Fix For: 0.5
>
> Attachments: AbstractParty.java, DefaultAssociatedResource.java,
> DefaultAttributeGroup.java, DefaultBand.patch, DefaultCitation.patch,
> DefaultConstraint.patch, DefaultContact.patch, DefaultCoupledResource.java,
> DefaultCoverageDescription.java, DefaultDimension.patch,
> DefaultFeatureTypeInfo.java, DefaultIndividual.java,
> DefaultKeywordClass.java, DefaultMetadataScope.java,
> DefaultOperationChainMetadata.java, DefaultOperationMetadata.java,
> DefaultOrganisation.java, DefaultParameter.java, DefaultProcessStep.patch,
> DefaultRangeDimension.patch, DefaultReleasability.java,
> DefaultRepresentativeFraction.patch, DefaultResponsibility.java,
> DefaultSampleDimension.java, DefaultSpatialTemporalExtent.patch,
> DefaultTelephone.patch, defaultBrowseGraphic.patch, defaultKeyword.patch,
> defaultLineage.patch, defaultMaintenance.patch,
> defaultServiceIdentification.patch, defaultSource.patch, defaultUsage.patch
>
> Original Estimate: 1,344h
> Remaining Estimate: 1,344h
>
> One of Apache SIS goals is to comply with the ISO (_International Standards
> Organization_) specifications. Compliance to international standards not only
> increase inter-operability between products, but is also a legal requirement
> for government agencies in the European Union since the INSPIRE directive
> from the European Commission.
> Apache SIS currently implements the ISO 19115 (_Geographic information -
> Metadata_) standard, as published in 2003, completed by ISO 19115-2 published
> in 2009. The ISO organization updates their standards once every 10 years.
> The new ISO 19115 revision has been published in 2014 and is available there:
> http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=53798
> We need to update Apache SIS to make it compliant with the new ISO 19115
> standards. Because Apache SIS implements the GeoAPI interfaces defined by the
> Open Geospatial Consortium (OGC), this task will need to be done in
> cooperation with the OGC GeoAPI working group. More specifically, the tasks
> will be (not necessarily in that order - many tasks are expected to be done
> in parallel):
> * On the OGC GeoAPI side ([GEO-232|http://jira.codehaus.org/browse/GEO-232]):
> ** Get legal copies of the new ISO 19115-1, -2, -3 and -4 standards (to be
> provided by mentors).
> ** Review all classes, interfaces, fields and methods defined in the
> {{org.opengis.metadata.*}} packages and compare them with the new definitions
> provided in ISO 19115-1 and -2.
> *** For every new elements added in ISO 19115-1/2, add the corresponding
> elements in the Java interfaces.
> *** For every elements removed from ISO 19115-1/2, deprecate the
> corresponding elements in the Java interfaces.
> *** Fix any discrepancies or errors which may be found on a case-by-case
> basis, to be discussed on the GeoAPI mailing list.
> *** Make sure that all elements have an up-to-date and accurate Javadoc.
> ** Update the GeoAPI specification with mentor help.
> ** Write test cases in the {{geoapi-conformance}} module.
> * On the Apache SIS side:
> ** For all changes done in GeoAPI interface, reflect the changes in the
> Apache SIS implementation in the {{org.apache.sis.metadata.iso.*}} packages.
> ** Add JAXB adapters for the new elements, or fix JAXB adapters for existing
> elements, in order to marshal/unmarshall XML documents compliant with the new
> standards as defined in ISO 19115-3 and -4.
> ** Check for any additional requirements defined by the INSPIRE directive.
> ** Ensure that Apache SIS passes the tests defined in GeoAPI.
> ** In collaboration with specialists, write some use cases and demos using
> the new metadata objects.
> Peoples who can help for this task are:
> * Contributor of the Apache SIS metadata module and GeoAPI chairman (mentor).
> * Authors of the MD-Web project and peoples working in remote-sensing (for
> more metadata advice).
> * Member of the OGC Architecture Board for help with OGC procedure.
> * Some authors who contributed to the ISO 19115 revision.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SIS-94) Update SIS to revision 2014 of the ISO 19115 standard
[
https://issues.apache.org/jira/browse/SIS-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-94:
---
Affects Version/s: 0.3
0.4
> Update SIS to revision 2014 of the ISO 19115 standard
> -
>
> Key: SIS-94
> URL: https://issues.apache.org/jira/browse/SIS-94
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Metadata
>Affects Versions: 0.3, 0.4
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Labels: gsoc2013
> Fix For: 0.5
>
> Attachments: AbstractParty.java, DefaultAssociatedResource.java,
> DefaultAttributeGroup.java, DefaultBand.patch, DefaultCitation.patch,
> DefaultConstraint.patch, DefaultContact.patch, DefaultCoupledResource.java,
> DefaultCoverageDescription.java, DefaultDimension.patch,
> DefaultFeatureTypeInfo.java, DefaultIndividual.java,
> DefaultKeywordClass.java, DefaultMetadataScope.java,
> DefaultOperationChainMetadata.java, DefaultOperationMetadata.java,
> DefaultOrganisation.java, DefaultParameter.java, DefaultProcessStep.patch,
> DefaultRangeDimension.patch, DefaultReleasability.java,
> DefaultRepresentativeFraction.patch, DefaultResponsibility.java,
> DefaultSampleDimension.java, DefaultSpatialTemporalExtent.patch,
> DefaultTelephone.patch, defaultBrowseGraphic.patch, defaultKeyword.patch,
> defaultLineage.patch, defaultMaintenance.patch,
> defaultServiceIdentification.patch, defaultSource.patch, defaultUsage.patch
>
> Original Estimate: 1,344h
> Remaining Estimate: 1,344h
>
> One of Apache SIS goals is to comply with the ISO (_International Standards
> Organization_) specifications. Compliance to international standards not only
> increase inter-operability between products, but is also a legal requirement
> for government agencies in the European Union since the INSPIRE directive
> from the European Commission.
> Apache SIS currently implements the ISO 19115 (_Geographic information -
> Metadata_) standard, as published in 2003, completed by ISO 19115-2 published
> in 2009. The ISO organization updates their standards once every 10 years.
> The new ISO 19115 revision has been published in 2014 and is available there:
> http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=53798
> We need to update Apache SIS to make it compliant with the new ISO 19115
> standards. Because Apache SIS implements the GeoAPI interfaces defined by the
> Open Geospatial Consortium (OGC), this task will need to be done in
> cooperation with the OGC GeoAPI working group. More specifically, the tasks
> will be (not necessarily in that order - many tasks are expected to be done
> in parallel):
> * On the OGC GeoAPI side ([GEO-232|http://jira.codehaus.org/browse/GEO-232]):
> ** Get legal copies of the new ISO 19115-1, -2, -3 and -4 standards (to be
> provided by mentors).
> ** Review all classes, interfaces, fields and methods defined in the
> {{org.opengis.metadata.*}} packages and compare them with the new definitions
> provided in ISO 19115-1 and -2.
> *** For every new elements added in ISO 19115-1/2, add the corresponding
> elements in the Java interfaces.
> *** For every elements removed from ISO 19115-1/2, deprecate the
> corresponding elements in the Java interfaces.
> *** Fix any discrepancies or errors which may be found on a case-by-case
> basis, to be discussed on the GeoAPI mailing list.
> *** Make sure that all elements have an up-to-date and accurate Javadoc.
> ** Update the GeoAPI specification with mentor help.
> ** Write test cases in the {{geoapi-conformance}} module.
> * On the Apache SIS side:
> ** For all changes done in GeoAPI interface, reflect the changes in the
> Apache SIS implementation in the {{org.apache.sis.metadata.iso.*}} packages.
> ** Add JAXB adapters for the new elements, or fix JAXB adapters for existing
> elements, in order to marshal/unmarshall XML documents compliant with the new
> standards as defined in ISO 19115-3 and -4.
> ** Check for any additional requirements defined by the INSPIRE directive.
> ** Ensure that Apache SIS passes the tests defined in GeoAPI.
> ** In collaboration with specialists, write some use cases and demos using
> the new metadata objects.
> Peoples who can help for this task are:
> * Contributor of the Apache SIS metadata module and GeoAPI chairman (mentor).
> * Authors of the MD-Web project and peoples working in remote-sensing (for
> more metadata advice).
> * Member of the OGC Architecture Board for help with OGC procedure.
> * Some authors who contributed to the ISO 19115 revision.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[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:
Description:
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 Java (but not necessarily with the large JDK
library, since this work uses relatively few JDK classes outside {{Math}}), and
in mathematic. In particular, this work requires that the developer is familiar
with _affine transforms_: their representation as a matrix, and how to map a
term in a formula to a coefficient in the affine transform matrix. This work
requires also the capability to find the analytic derivative of a 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}}).
was:
This is an umbrella task for some coordinate operation methods not yet
supported in Apache SIS. We can of course not list all possible formulas that
we do not support, but we list at least some of the EPSG guidance notes.
The EPSG guidance notes 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}
Implementations of those formulas take place in one of the
{{org.apache.sis.referencing.operation}} sub-packages ({{projection}} or
{{transform}}).
> 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
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Labels: gsoc2016
> Fix For: 0.6, 0.7
>
>
> 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 Java (but not necessarily with the large JDK
> library, since this work uses relatively few JDK classes outside {{Math}}),
> and in mathematic. In particular, this work requires that the developer is
> familiar with _affine transforms_: their representation as a matrix, and how
> to map a term in a formula to a coefficient in the affine transform matrix.
> This work requires also the capability to find the analytic derivative of a
> 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}}).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[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 java (was: gsoc2016)
> 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
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Labels: gsoc2016, java
> Fix For: 0.6, 0.7
>
>
> 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 Java (but not necessarily with the large JDK
> library, since this work uses relatively few JDK classes outside {{Math}}),
> and in mathematic. In particular, this work requires that the developer is
> familiar with _affine transforms_: their representation as a matrix, and how
> to map a term in a formula to a coefficient in the affine transform matrix.
> This work requires also the capability to find the analytic derivative of a
> 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}}).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[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 java mentor (was: gsoc2016 java)
> 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
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Labels: gsoc2016, java, mentor
> Fix For: 0.6, 0.7
>
>
> 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 Java (but not necessarily with the large JDK
> library, since this work uses relatively few JDK classes outside {{Math}}),
> and in mathematic. In particular, this work requires that the developer is
> familiar with _affine transforms_: their representation as a matrix, and how
> to map a term in a formula to a coefficient in the affine transform matrix.
> This work requires also the capability to find the analytic derivative of a
> 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}}).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[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:
Description:
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}}).
was:
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 Java (but not necessarily with the large JDK
library, since this work uses relatively few JDK classes outside {{Math}}), and
in mathematic. In particular, this work requires that the developer is familiar
with _affine transforms_: their representation as a matrix, and how to map a
term in a formula to a coefficient in the affine transform matrix. This work
requires also the capability to find the analytic derivative of a 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}}).
> 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
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Labels: gsoc2016, java, mentor
> Fix For: 0.6, 0.7
>
>
> 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
[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:
Description:
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.
was:
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}}).
> 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
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Labels: gsoc2016, java, mentor
> Fix For: 0.6, 0.7
>
>
> 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 oper
[jira] [Created] (SIS-307) Create the foundation of a module for remote sensing data
Martin Desruisseaux created SIS-307:
---
Summary: Create the foundation of a module for remote sensing data
Key: SIS-307
URL: https://issues.apache.org/jira/browse/SIS-307
Project: Spatial Information Systems
Issue Type: New Feature
Components: Storage
Reporter: Martin Desruisseaux
Assignee: Martin Desruisseaux
This is a proposal for a [Google Summer of
Code|https://summerofcode.withgoogle.com/] (GSoC) project. The Apache SIS
library needs a module for efficient handling of large _n_-dimensional remote
sensing data. The module shall:
* Provide a common approach to the reading and writing of grid coverages
applicable to simple imagery as to multi-dimensional data structures.
* Allow operations that preserve the scientific meaning of data (e.g.
distinguish between measurements and missing values, why the value is missing,
estimation of accuracy).
* Be compliant with international standards, in particular (but not only)
_Schema for coverage geometry and functions_ (ISO 19123) and _Web Coverage
Services_ (WCS). The module should provide extensions to those standards only
for aspects that are not covered by an existing standard.
This module will be a redesign of coverage module that existed in previous
projects. In particular, the coverage module of the
[Geotk|http://www.geotoolkit.org] project will be used as a starting point.
However an important focus of this project is to fix known limitations of
previous projects, for example:
* Too strong reliance on {{javax.imageio}} API, which was designed for
two-dimensional images. That API is difficult to generalize to three- or
four-dimensional data accesses.
* Too strong reliance on {{javax.imageio.metadata}} API, which is basically a
XML document. Ordinary Java objects are more convenient to use and the ISO
19115 international standard can be a good model for those objects.
* Too strong restriction on the grid geometry (in previous projects, the
conversion from pixel coordinates to "real world" coordinates is restricted to
an affine transform).
* Only quadrilateral grid coverages were supported.
h3. Proof of concept
In order to ensure that the module is on the right track, a small application
(either a desktop application for browsing images or a simple web application
conforms to the WCS standard) will be created. This simple application will be
created in collaboration with volunteers of a space agency, and should be able
to:
* Read at least one image format of that space agency.
* Allow diffusion of those data in time range, sub-area, sub-sampling and
layers selected by the user.
* Allow searches in some metadata fields (to be selected according the needs of
the space agency).
h3. Non-goals
This GSoC project is not expected to create a fully functional coverage module
in 3 months. Performance is not a concern for this initial stage (in
particular, building index or storing information in a database is out of
scope), except that the application shall not load all data in memory: the
application should prove that it can work with only a small fraction of the
data in memory and load the remaining parts when needed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SIS-307) Create the foundation of a module for remote sensing data
[
https://issues.apache.org/jira/browse/SIS-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-307:
Description:
This is a proposal for a [Google Summer of
Code|https://summerofcode.withgoogle.com/] (GSoC) project. The Apache SIS
library needs a module for efficient handling of large _n_-dimensional remote
sensing data. The module shall:
* Provide a common approach to the reading and writing of grid coverages
applicable to simple imagery as to multi-dimensional data structures.
* Allow operations that preserve the scientific meaning of data (e.g.
distinguish between measurements and missing values, why the value is missing,
estimation of accuracy).
* Be compliant with international standards, in particular (but not only)
_Schema for coverage geometry and functions_ (ISO 19123) and _Web Coverage
Services_ (WCS). The module should provide extensions to those standards only
for aspects that are not covered by an existing standard.
This module will be a redesign of coverage module that existed in previous
projects. In particular, the coverage module of the
[Geotk|http://www.geotoolkit.org] project will be used as a starting point.
However an important focus of this project is to fix known limitations of
previous projects, for example:
* Too strong reliance on {{javax.imageio}} API, which was designed for
two-dimensional images. That API is difficult to generalize to three- or
four-dimensional data accesses.
* Too strong reliance on {{javax.imageio.metadata}} API, which is basically a
XML document. Ordinary Java objects are more convenient to use and the ISO
19115 international standard can be a good model for those objects.
* Too strong restriction on the grid geometry (in previous projects, the
conversion from pixel coordinates to "real world" coordinates is restricted to
an affine transform).
* Only quadrilateral grid coverages were supported.
The development language is Java. Operating system can be Linux, Windows or
MacOS. The build tool is Maven. If a web application is created (see next
section), the container would be Tomcat.
h2. Proof of concept
In order to ensure that the module is on the right track, a small application
(either a desktop application for browsing images or a simple web application
conforms to the WCS standard) will be created. This simple application will be
created in collaboration with volunteers of a space agency, and should be able
to:
* Read at least one image format of that space agency.
* Allow diffusion of those data in time range, sub-area, sub-sampling and
layers selected by the user.
* Allow searches in some metadata fields (to be selected according the needs of
the space agency).
h2. Non-goals
This GSoC project is not expected to create a fully functional coverage module
in 3 months. Performance is not a concern for this initial stage (in
particular, building index or storing information in a database is out of
scope), except that the application shall not load all data in memory: the
application should prove that it can work with only a small fraction of the
data in memory and load the remaining parts when needed. For the prototype
application, those data will be read from a specified directory (a more
advanced application could a database or cloud).
was:
This is a proposal for a [Google Summer of
Code|https://summerofcode.withgoogle.com/] (GSoC) project. The Apache SIS
library needs a module for efficient handling of large _n_-dimensional remote
sensing data. The module shall:
* Provide a common approach to the reading and writing of grid coverages
applicable to simple imagery as to multi-dimensional data structures.
* Allow operations that preserve the scientific meaning of data (e.g.
distinguish between measurements and missing values, why the value is missing,
estimation of accuracy).
* Be compliant with international standards, in particular (but not only)
_Schema for coverage geometry and functions_ (ISO 19123) and _Web Coverage
Services_ (WCS). The module should provide extensions to those standards only
for aspects that are not covered by an existing standard.
This module will be a redesign of coverage module that existed in previous
projects. In particular, the coverage module of the
[Geotk|http://www.geotoolkit.org] project will be used as a starting point.
However an important focus of this project is to fix known limitations of
previous projects, for example:
* Too strong reliance on {{javax.imageio}} API, which was designed for
two-dimensional images. That API is difficult to generalize to three- or
four-dimensional data accesses.
* Too strong reliance on {{javax.imageio.metadata}} API, which is basically a
XML document. Ordinary Java objects are more convenient to use and the ISO
19115 international standard can be a good model for those objects.
* Too strong restriction on the grid geometry
[jira] [Updated] (SIS-307) Create the foundation of a module for remote sensing data
[
https://issues.apache.org/jira/browse/SIS-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-307:
Description:
This is a proposal for a [Google Summer of
Code|https://summerofcode.withgoogle.com/] (GSoC) project. The Apache SIS
library needs a module for efficient handling of large _n_-dimensional remote
sensing data. The module shall:
* Provide a common approach to the reading and writing of grid coverages
applicable to simple imagery as to multi-dimensional data structures.
* Allow operations that preserve the scientific meaning of data (e.g.
distinguish between measurements and missing values, why the value is missing,
estimation of accuracy).
* Be compliant with international standards, in particular (but not only)
_Schema for coverage geometry and functions_ (ISO 19123) and _Web Coverage
Services_ (WCS). The module should provide extensions to those standards only
for aspects that are not covered by an existing standard.
This module will be a redesign of coverage module that existed in previous
projects. In particular, the coverage module of the
[Geotk|http://www.geotoolkit.org] project will be used as a starting point.
However an important focus of this project is to fix known limitations of
previous projects, for example:
* Too strong reliance on {{javax.imageio}} API, which was designed for
two-dimensional images. That API is difficult to generalize to three- or
four-dimensional data accesses.
* Too strong reliance on {{javax.imageio.metadata}} API, which is basically a
XML document. Ordinary Java objects are more convenient to use and the ISO
19115 international standard can be a good model for those objects.
* Too strong restriction on the grid geometry (in previous projects, the
conversion from pixel coordinates to "real world" coordinates is restricted to
an affine transform).
* Only quadrilateral grid coverages were supported.
The development language is Java. Operating system can be Linux, Windows or
MacOS. The build tool is Maven. If a web application is created (see next
section), the container would be Tomcat.
h2. Proof of concept
In order to ensure that the module is on the right track, a small application
(either a desktop application for browsing images or a simple web application
conforms to the WCS standard) will be created. This simple application will be
created in collaboration with volunteers of space agency in Vietnam, [Vietnam
National Satellite Center|http://vnsc.org.vn/] (VNSC), for managing its
geospatial database. The application should be able to:
* Read at least one image format of that space agency.
* Allow diffusion of those data in time range, sub-area, sub-sampling and
layers selected by the user.
* Allow searches in some metadata fields (to be selected according the needs of
the space agency).
h2. Non-goals
This GSoC project is not expected to create a fully functional coverage module
in 3 months. Performance is not a concern for this initial stage (in
particular, building index or storing information in a database is out of
scope), except that the application shall not load all data in memory: the
application should prove that it can work with only a small fraction of the
data in memory and load the remaining parts when needed. For the prototype
application, those data will be read from a specified directory (a more
advanced application could a database or cloud).
was:
This is a proposal for a [Google Summer of
Code|https://summerofcode.withgoogle.com/] (GSoC) project. The Apache SIS
library needs a module for efficient handling of large _n_-dimensional remote
sensing data. The module shall:
* Provide a common approach to the reading and writing of grid coverages
applicable to simple imagery as to multi-dimensional data structures.
* Allow operations that preserve the scientific meaning of data (e.g.
distinguish between measurements and missing values, why the value is missing,
estimation of accuracy).
* Be compliant with international standards, in particular (but not only)
_Schema for coverage geometry and functions_ (ISO 19123) and _Web Coverage
Services_ (WCS). The module should provide extensions to those standards only
for aspects that are not covered by an existing standard.
This module will be a redesign of coverage module that existed in previous
projects. In particular, the coverage module of the
[Geotk|http://www.geotoolkit.org] project will be used as a starting point.
However an important focus of this project is to fix known limitations of
previous projects, for example:
* Too strong reliance on {{javax.imageio}} API, which was designed for
two-dimensional images. That API is difficult to generalize to three- or
four-dimensional data accesses.
* Too strong reliance on {{javax.imageio.metadata}} API, which is basically a
XML document. Ordinary Java objects are more convenient to use and
[jira] [Updated] (SIS-307) Create the foundation of a module for remote sensing data
[
https://issues.apache.org/jira/browse/SIS-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-307:
Description:
This is a proposal for a [Google Summer of
Code|https://summerofcode.withgoogle.com/] (GSoC) project. The Apache SIS
library needs a module for efficient handling of large _n_-dimensional remote
sensing data. The module shall:
* Provide a common approach to the reading and writing of grid coverages
applicable to simple imagery as to multi-dimensional data structures.
* Allow operations that preserve the scientific meaning of data (e.g.
distinguish between measurements and missing values, why the value is missing,
estimation of accuracy).
* Be compliant with international standards, in particular (but not only)
_Schema for coverage geometry and functions_ (ISO 19123) and _Web Coverage
Services_ (WCS). The module should provide extensions to those standards only
for aspects that are not covered by an existing standard.
This module will be a redesign of coverage module that existed in previous
projects. In particular, the coverage module of the
[Geotk|http://www.geotoolkit.org] project will be used as a starting point.
However an important focus of this project is to fix known limitations of
previous projects, for example:
* Too strong reliance on {{javax.imageio}} API, which was designed for
two-dimensional images. That API is difficult to generalize to three- or
four-dimensional data accesses.
* Too strong reliance on {{javax.imageio.metadata}} API, which is basically a
XML document. Ordinary Java objects are more convenient to use and the ISO
19115 international standard can be a good model for those objects.
* Too strong restriction on the grid geometry (in previous projects, the
conversion from pixel coordinates to "real world" coordinates is restricted to
an affine transform).
* Only quadrilateral grid coverages were supported.
The development language is Java. Operating system can be Linux, Windows or
MacOS. The build tool is Maven. If a web application is created (see next
section), the container would be Tomcat.
h2. Proof of concept
In order to ensure that the module is on the right track, a small application
(either a desktop application for browsing images or a simple web application
conforms to the WCS standard) will be created. This simple application will be
created in collaboration with volunteers of space agency in Vietnam, [Vietnam
National Satellite Center|http://vnsc.org.vn/] (VNSC), for managing its
geospatial database. The application should be able to:
* Read at least two image formats of that space agency (the API shall allow
addition of more formats in the future).
* Allow diffusion of those data in time range, sub-area, sub-sampling and
layers selected by the user.
* Allow searches in some metadata fields (to be selected according the needs of
the space agency).
h2. Non-goals
This GSoC project is not expected to create a fully functional coverage module
in 3 months. Performance is not a concern for this initial stage (in
particular, building index or storing information in a database is out of
scope), except that the application shall not load all data in memory: the
application should prove that it can work with only a small fraction of the
data in memory and load the remaining parts when needed. For the prototype
application, those data will be read from a specified directory (a more
advanced application could a database or cloud).
was:
This is a proposal for a [Google Summer of
Code|https://summerofcode.withgoogle.com/] (GSoC) project. The Apache SIS
library needs a module for efficient handling of large _n_-dimensional remote
sensing data. The module shall:
* Provide a common approach to the reading and writing of grid coverages
applicable to simple imagery as to multi-dimensional data structures.
* Allow operations that preserve the scientific meaning of data (e.g.
distinguish between measurements and missing values, why the value is missing,
estimation of accuracy).
* Be compliant with international standards, in particular (but not only)
_Schema for coverage geometry and functions_ (ISO 19123) and _Web Coverage
Services_ (WCS). The module should provide extensions to those standards only
for aspects that are not covered by an existing standard.
This module will be a redesign of coverage module that existed in previous
projects. In particular, the coverage module of the
[Geotk|http://www.geotoolkit.org] project will be used as a starting point.
However an important focus of this project is to fix known limitations of
previous projects, for example:
* Too strong reliance on {{javax.imageio}} API, which was designed for
two-dimensional images. That API is difficult to generalize to three- or
four-dimensional data accesses.
* Too strong reliance on {{javax.imageio.metadata}} API, which is basically a
XML
[jira] [Updated] (SIS-307) GSoC: Create the foundation of a module for remote sensing data
[
https://issues.apache.org/jira/browse/SIS-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-307:
Summary: GSoC: Create the foundation of a module for remote sensing data
(was: Create the foundation of a module for remote sensing data)
> GSoC: Create the foundation of a module for remote sensing data
> ---
>
> Key: SIS-307
> URL: https://issues.apache.org/jira/browse/SIS-307
> Project: Spatial Information Systems
> Issue Type: New Feature
> Components: Storage
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Labels: gsoc2016, mentor
> Original Estimate: 3,024h
> Remaining Estimate: 3,024h
>
> This is a proposal for a [Google Summer of
> Code|https://summerofcode.withgoogle.com/] (GSoC) project. The Apache SIS
> library needs a module for efficient handling of large _n_-dimensional remote
> sensing data. The module shall:
> * Provide a common approach to the reading and writing of grid coverages
> applicable to simple imagery as to multi-dimensional data structures.
> * Allow operations that preserve the scientific meaning of data (e.g.
> distinguish between measurements and missing values, why the value is
> missing, estimation of accuracy).
> * Be compliant with international standards, in particular (but not only)
> _Schema for coverage geometry and functions_ (ISO 19123) and _Web Coverage
> Services_ (WCS). The module should provide extensions to those standards only
> for aspects that are not covered by an existing standard.
> This module will be a redesign of coverage module that existed in previous
> projects. In particular, the coverage module of the
> [Geotk|http://www.geotoolkit.org] project will be used as a starting point.
> However an important focus of this project is to fix known limitations of
> previous projects, for example:
> * Too strong reliance on {{javax.imageio}} API, which was designed for
> two-dimensional images. That API is difficult to generalize to three- or
> four-dimensional data accesses.
> * Too strong reliance on {{javax.imageio.metadata}} API, which is basically a
> XML document. Ordinary Java objects are more convenient to use and the ISO
> 19115 international standard can be a good model for those objects.
> * Too strong restriction on the grid geometry (in previous projects, the
> conversion from pixel coordinates to "real world" coordinates is restricted
> to an affine transform).
> * Only quadrilateral grid coverages were supported.
> The development language is Java. Operating system can be Linux, Windows or
> MacOS. The build tool is Maven. If a web application is created (see next
> section), the container would be Tomcat.
> h2. Proof of concept
> In order to ensure that the module is on the right track, a small application
> (either a desktop application for browsing images or a simple web application
> conforms to the WCS standard) will be created. This simple application will
> be created in collaboration with volunteers of space agency in Vietnam,
> [Vietnam National Satellite Center|http://vnsc.org.vn/] (VNSC), for managing
> its geospatial database. The application should be able to:
> * Read at least two image formats of that space agency (the API shall allow
> addition of more formats in the future).
> * Allow diffusion of those data in time range, sub-area, sub-sampling and
> layers selected by the user.
> * Allow searches in some metadata fields (to be selected according the needs
> of the space agency).
> h2. Non-goals
> This GSoC project is not expected to create a fully functional coverage
> module in 3 months. Performance is not a concern for this initial stage (in
> particular, building index or storing information in a database is out of
> scope), except that the application shall not load all data in memory: the
> application should prove that it can work with only a small fraction of the
> data in memory and load the remaining parts when needed. For the prototype
> application, those data will be read from a specified directory (a more
> advanced application could a database or cloud).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SIS-308) InputStream provided by StorageConnector not always at the beginning of the stream
Martin Desruisseaux created SIS-308:
---
Summary: InputStream provided by StorageConnector not always at
the beginning of the stream
Key: SIS-308
URL: https://issues.apache.org/jira/browse/SIS-308
Project: Spatial Information Systems
Issue Type: Bug
Components: Storage
Affects Versions: 0.6, 0.5, 0.4, 0.3
Reporter: Martin Desruisseaux
Assignee: Martin Desruisseaux
Fix For: 0.7
Call to {{StorageConnector.getStorageAs(InputStream.class)}} returns an
{{InputStream}} which does not read from the beginning of the stream if a call
to {{StorageConnection.getStorageAs(…)}} has been done before for another type.
The fix is to use {{InputStream.mark()}} when the other type is created and
{{InputStream.reset()}} when the {{InputStream}} is requested.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SIS-308) InputStream provided by StorageConnector not always at the beginning of the stream
[
https://issues.apache.org/jira/browse/SIS-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux resolved SIS-308.
-
Resolution: Fixed
> InputStream provided by StorageConnector not always at the beginning of the
> stream
> --
>
> Key: SIS-308
> URL: https://issues.apache.org/jira/browse/SIS-308
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Storage
>Affects Versions: 0.3, 0.4, 0.5, 0.6
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Fix For: 0.7
>
>
> Call to {{StorageConnector.getStorageAs(InputStream.class)}} returns an
> {{InputStream}} which does not read from the beginning of the stream if a
> call to {{StorageConnection.getStorageAs(…)}} has been done before for
> another type.
> The fix is to use {{InputStream.mark()}} when the other type is created and
> {{InputStream.reset()}} when the {{InputStream}} is requested.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SIS-309) URI in the Id element of WKT 2 wrongly taken as Id version number
Martin Desruisseaux created SIS-309:
---
Summary: URI in the Id element of WKT 2 wrongly taken as Id
version number
Key: SIS-309
URL: https://issues.apache.org/jira/browse/SIS-309
Project: Spatial Information Systems
Issue Type: Bug
Components: Referencing
Affects Versions: 0.6
Reporter: Martin Desruisseaux
Assignee: Martin Desruisseaux
Fix For: 0.7
In WKT element like {{Id\[“EPSG”, 27572,
URI\[“urn:ogc:def:crs:EPSG::27572”\]\]}} in which the version (an optional
element between {{27572}} and {{URI}}) is omitted, the {{URI}} element is
wrongly taken as the version.
This bug does not happen if the {{Id}} has a version element.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Work started] (SIS-309) URI in the Id element of WKT 2 wrongly taken as Id version number
[
https://issues.apache.org/jira/browse/SIS-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on SIS-309 started by Martin Desruisseaux.
---
> URI in the Id element of WKT 2 wrongly taken as Id version number
> -
>
> Key: SIS-309
> URL: https://issues.apache.org/jira/browse/SIS-309
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Referencing
>Affects Versions: 0.6
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Fix For: 0.7
>
>
> In WKT element like {{Id\[“EPSG”, 27572,
> URI\[“urn:ogc:def:crs:EPSG::27572”\]\]}} in which the version (an optional
> element between {{27572}} and {{URI}}) is omitted, the {{URI}} element is
> wrongly taken as the version.
> This bug does not happen if the {{Id}} has a version element.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SIS-310) WKT parser fails to parse UNIT["grade", 0.015707963267948967]
Martin Desruisseaux created SIS-310:
---
Summary: WKT parser fails to parse UNIT["grade",
0.015707963267948967]
Key: SIS-310
URL: https://issues.apache.org/jira/browse/SIS-310
Project: Spatial Information Systems
Issue Type: Bug
Components: Referencing
Affects Versions: 0.6
Reporter: Martin Desruisseaux
Assignee: Martin Desruisseaux
Fix For: 0.7
If a WKT contains grade unit like {{UNIT\["grade", 0.015707963267948967\]}} and
the parser can not infer from the context that the units are angular (for
example when the unit appears in a {{PARAMETER}} element), parsing fails.
This bug does not happen if the {{ANGLEUNIT}} keyword is used instead of the
neutral {{UNIT}} or if the context implies that the units are angular (for
example inside a {{PRIMEMERIDIAN}} element).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Work started] (SIS-310) WKT parser fails to parse UNIT["grade", 0.015707963267948967]
[
https://issues.apache.org/jira/browse/SIS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on SIS-310 started by Martin Desruisseaux.
---
> WKT parser fails to parse UNIT["grade", 0.015707963267948967]
> -
>
> Key: SIS-310
> URL: https://issues.apache.org/jira/browse/SIS-310
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Referencing
>Affects Versions: 0.6
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Fix For: 0.7
>
>
> If a WKT contains grade unit like {{UNIT\["grade", 0.015707963267948967\]}}
> and the parser can not infer from the context that the units are angular (for
> example when the unit appears in a {{PARAMETER}} element), parsing fails.
> This bug does not happen if the {{ANGLEUNIT}} keyword is used instead of the
> neutral {{UNIT}} or if the context implies that the units are angular (for
> example inside a {{PRIMEMERIDIAN}} element).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SIS-310) WKT parser fails to parse UNIT["grade", 0.015707963267948967]
[
https://issues.apache.org/jira/browse/SIS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-310:
Labels: WKT (was: )
> WKT parser fails to parse UNIT["grade", 0.015707963267948967]
> -
>
> Key: SIS-310
> URL: https://issues.apache.org/jira/browse/SIS-310
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Referencing
>Affects Versions: 0.6
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Labels: WKT
> Fix For: 0.7
>
>
> If a WKT contains grade unit like {{UNIT\["grade", 0.015707963267948967\]}}
> and the parser can not infer from the context that the units are angular (for
> example when the unit appears in a {{PARAMETER}} element), parsing fails.
> This bug does not happen if the {{ANGLEUNIT}} keyword is used instead of the
> neutral {{UNIT}} or if the context implies that the units are angular (for
> example inside a {{PRIMEMERIDIAN}} element).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SIS-309) URI in the Id element of WKT 2 wrongly taken as Id version number
[
https://issues.apache.org/jira/browse/SIS-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-309:
Labels: WKT (was: )
> URI in the Id element of WKT 2 wrongly taken as Id version number
> -
>
> Key: SIS-309
> URL: https://issues.apache.org/jira/browse/SIS-309
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Referencing
>Affects Versions: 0.6
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Labels: WKT
> Fix For: 0.7
>
>
> In WKT element like {{Id\[“EPSG”, 27572,
> URI\[“urn:ogc:def:crs:EPSG::27572”\]\]}} in which the version (an optional
> element between {{27572}} and {{URI}}) is omitted, the {{URI}} element is
> wrongly taken as the version.
> This bug does not happen if the {{Id}} has a version element.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SIS-309) URI in the ID element of WKT 2 wrongly taken as Id version number
[
https://issues.apache.org/jira/browse/SIS-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-309:
Description:
In WKT element like {{ID\[“EPSG”, 27572,
URI\[“urn:ogc:def:crs:EPSG::27572”\]\]}} in which the version (an optional
element between {{27572}} and {{URI}}) is omitted, the {{URI}} element is
wrongly taken as the version.
This bug does not happen if the {{ID}} has a version element.
was:
In WKT element like {{Id\[“EPSG”, 27572,
URI\[“urn:ogc:def:crs:EPSG::27572”\]\]}} in which the version (an optional
element between {{27572}} and {{URI}}) is omitted, the {{URI}} element is
wrongly taken as the version.
This bug does not happen if the {{Id}} has a version element.
> URI in the ID element of WKT 2 wrongly taken as Id version number
> -
>
> Key: SIS-309
> URL: https://issues.apache.org/jira/browse/SIS-309
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Referencing
>Affects Versions: 0.6
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Labels: WKT
> Fix For: 0.7
>
>
> In WKT element like {{ID\[“EPSG”, 27572,
> URI\[“urn:ogc:def:crs:EPSG::27572”\]\]}} in which the version (an optional
> element between {{27572}} and {{URI}}) is omitted, the {{URI}} element is
> wrongly taken as the version.
> This bug does not happen if the {{ID}} has a version element.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SIS-309) URI in the ID element of WKT 2 wrongly taken as Id version number
[
https://issues.apache.org/jira/browse/SIS-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-309:
Summary: URI in the ID element of WKT 2 wrongly taken as Id version number
(was: URI in the Id element of WKT 2 wrongly taken as Id version number)
> URI in the ID element of WKT 2 wrongly taken as Id version number
> -
>
> Key: SIS-309
> URL: https://issues.apache.org/jira/browse/SIS-309
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Referencing
>Affects Versions: 0.6
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Labels: WKT
> Fix For: 0.7
>
>
> In WKT element like {{Id\[“EPSG”, 27572,
> URI\[“urn:ogc:def:crs:EPSG::27572”\]\]}} in which the version (an optional
> element between {{27572}} and {{URI}}) is omitted, the {{URI}} element is
> wrongly taken as the version.
> This bug does not happen if the {{Id}} has a version element.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SIS-309) URI in the ID element of WKT 2 wrongly taken as Id version number
[
https://issues.apache.org/jira/browse/SIS-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux resolved SIS-309.
-
Resolution: Fixed
> URI in the ID element of WKT 2 wrongly taken as Id version number
> -
>
> Key: SIS-309
> URL: https://issues.apache.org/jira/browse/SIS-309
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Referencing
>Affects Versions: 0.6
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Labels: WKT
> Fix For: 0.7
>
>
> In WKT element like {{ID\[“EPSG”, 27572,
> URI\[“urn:ogc:def:crs:EPSG::27572”\]\]}} in which the version (an optional
> element between {{27572}} and {{URI}}) is omitted, the {{URI}} element is
> wrongly taken as the version.
> This bug does not happen if the {{ID}} has a version element.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SIS-310) WKT parser fails to parse UNIT["grade", 0.015707963267948967]
[
https://issues.apache.org/jira/browse/SIS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux resolved SIS-310.
-
Resolution: Fixed
> WKT parser fails to parse UNIT["grade", 0.015707963267948967]
> -
>
> Key: SIS-310
> URL: https://issues.apache.org/jira/browse/SIS-310
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Referencing
>Affects Versions: 0.6
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Labels: WKT
> Fix For: 0.7
>
>
> If a WKT contains grade unit like {{UNIT\["grade", 0.015707963267948967\]}}
> and the parser can not infer from the context that the units are angular (for
> example when the unit appears in a {{PARAMETER}} element), parsing fails.
> This bug does not happen if the {{ANGLEUNIT}} keyword is used instead of the
> neutral {{UNIT}} or if the context implies that the units are angular (for
> example inside a {{PRIMEMERIDIAN}} element).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SIS-311) WKT parser ignores AREA and BBOX elements
[
https://issues.apache.org/jira/browse/SIS-311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-311:
Summary: WKT parser ignores AREA and BBOX elements (was: WKT parser ignore
AREA and BBOX elements)
> WKT parser ignores AREA and BBOX elements
> -
>
> Key: SIS-311
> URL: https://issues.apache.org/jira/browse/SIS-311
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Referencing
>Affects Versions: 0.6
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Labels: WKT
> Fix For: 0.7
>
>
> {{GeodeticObjectParser}} parses the {{AREA}} and {{BBOX}} elements as
> expected, but do not put them in the properties map given to {{CRSFactory}}.
> Consequently the domain of validity do not appear in the CRS created by the
> WKT parser.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SIS-311) WKT parser ignore AREA and BBOX elements
Martin Desruisseaux created SIS-311:
---
Summary: WKT parser ignore AREA and BBOX elements
Key: SIS-311
URL: https://issues.apache.org/jira/browse/SIS-311
Project: Spatial Information Systems
Issue Type: Bug
Components: Referencing
Affects Versions: 0.6
Reporter: Martin Desruisseaux
Assignee: Martin Desruisseaux
Fix For: 0.7
{{GeodeticObjectParser}} parses the {{AREA}} and {{BBOX}} elements as expected,
but do not put them in the properties map given to {{CRSFactory}}. Consequently
the domain of validity do not appear in the CRS created by the WKT parser.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Work started] (SIS-311) WKT parser ignores AREA and BBOX elements
[
https://issues.apache.org/jira/browse/SIS-311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on SIS-311 started by Martin Desruisseaux.
---
> WKT parser ignores AREA and BBOX elements
> -
>
> Key: SIS-311
> URL: https://issues.apache.org/jira/browse/SIS-311
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Referencing
>Affects Versions: 0.6
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Labels: WKT
> Fix For: 0.7
>
>
> {{GeodeticObjectParser}} parses the {{AREA}} and {{BBOX}} elements as
> expected, but do not put them in the properties map given to {{CRSFactory}}.
> Consequently the domain of validity do not appear in the CRS created by the
> WKT parser.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SIS-312) Axis abbreviation with nested parenthesis confuse the WKT parser
Martin Desruisseaux created SIS-312:
---
Summary: Axis abbreviation with nested parenthesis confuse the WKT
parser
Key: SIS-312
URL: https://issues.apache.org/jira/browse/SIS-312
Project: Spatial Information Systems
Issue Type: Bug
Components: Referencing
Affects Versions: 0.6
Reporter: Martin Desruisseaux
Assignee: Martin Desruisseaux
Fix For: 0.7
EPSG dataset sometime contains axis with properties like below:
* name: {{Easting}}
* abbreviation: {{E(X)}}
{{GeodeticObjectParser}} wrongly parses as below:
* name: {{Easting E(}}
* abbreviation: {{X)}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SIS-312) Axis abbreviation with nested parenthesis confuse the WKT parser
[
https://issues.apache.org/jira/browse/SIS-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-312:
Description:
EPSG dataset sometime contains axis with properties like below:
* name: {{Easting}}
* abbreviation: {{E(X)}}
which is formatted in WKT as "Easting (E(X))". But {{GeodeticObjectParser}}
wrongly parses that WKT as below:
* name: {{Easting E(}}
* abbreviation: {{X)}}
was:
EPSG dataset sometime contains axis with properties like below:
* name: {{Easting}}
* abbreviation: {{E(X)}}
{{GeodeticObjectParser}} wrongly parses as below:
* name: {{Easting E(}}
* abbreviation: {{X)}}
> Axis abbreviation with nested parenthesis confuse the WKT parser
>
>
> Key: SIS-312
> URL: https://issues.apache.org/jira/browse/SIS-312
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Referencing
>Affects Versions: 0.6
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Labels: WKT
> Fix For: 0.7
>
>
> EPSG dataset sometime contains axis with properties like below:
> * name: {{Easting}}
> * abbreviation: {{E(X)}}
> which is formatted in WKT as "Easting (E(X))". But {{GeodeticObjectParser}}
> wrongly parses that WKT as below:
> * name: {{Easting E(}}
> * abbreviation: {{X)}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SIS-313) WKT formatter should tell that it can not format directions like "North along 130°W" in WKT 1
Martin Desruisseaux created SIS-313:
---
Summary: WKT formatter should tell that it can not format
directions like "North along 130°W" in WKT 1
Key: SIS-313
URL: https://issues.apache.org/jira/browse/SIS-313
Project: Spatial Information Systems
Issue Type: Bug
Components: Referencing
Affects Versions: 0.6
Reporter: Martin Desruisseaux
Assignee: Martin Desruisseaux
Fix For: 0.7
The WKT 1 format supported only axis directions like _"East"_, _"West"_,
_"North"_ and _"South"_. The WKT 2 format add support for directions like
_"North along 130°W"_, which are used over poles. However writing those
directions requires a particular syntax introduced only with WKT 2. Attempts to
format those directions in older format result in invalid WKT 1 string. The WKT
formatter should instead throw an {{UnformattableObjectException}} in such
situation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Work started] (SIS-313) Formatter should tell that "North along 130°W" axis direction requires version 2 of WKT
[
https://issues.apache.org/jira/browse/SIS-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on SIS-313 started by Martin Desruisseaux.
---
> Formatter should tell that "North along 130°W" axis direction requires
> version 2 of WKT
> ---
>
> Key: SIS-313
> URL: https://issues.apache.org/jira/browse/SIS-313
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Referencing
>Affects Versions: 0.6
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Labels: WKT
> Fix For: 0.7
>
>
> The WKT 1 format supported only axis directions like _"East"_, _"West"_,
> _"North"_ and _"South"_. The WKT 2 format add support for directions like
> _"North along 130°W"_, which are used over poles. However writing those
> directions requires a particular syntax introduced only with WKT 2. Attempts
> to format those directions in older format result in invalid WKT 1 string.
> The WKT formatter should instead throw an {{UnformattableObjectException}} in
> such situation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SIS-313) Formatter should tell that "North along 130°W" axis direction requires version 2 of WKT
[
https://issues.apache.org/jira/browse/SIS-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-313:
Summary: Formatter should tell that "North along 130°W" axis direction
requires version 2 of WKT (was: WKT formatter should tell that it can not
format directions like "North along 130°W" in WKT 1)
> Formatter should tell that "North along 130°W" axis direction requires
> version 2 of WKT
> ---
>
> Key: SIS-313
> URL: https://issues.apache.org/jira/browse/SIS-313
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Referencing
>Affects Versions: 0.6
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Labels: WKT
> Fix For: 0.7
>
>
> The WKT 1 format supported only axis directions like _"East"_, _"West"_,
> _"North"_ and _"South"_. The WKT 2 format add support for directions like
> _"North along 130°W"_, which are used over poles. However writing those
> directions requires a particular syntax introduced only with WKT 2. Attempts
> to format those directions in older format result in invalid WKT 1 string.
> The WKT formatter should instead throw an {{UnformattableObjectException}} in
> such situation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SIS-311) WKT parser ignores AREA and BBOX elements
[
https://issues.apache.org/jira/browse/SIS-311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux resolved SIS-311.
-
Resolution: Fixed
> WKT parser ignores AREA and BBOX elements
> -
>
> Key: SIS-311
> URL: https://issues.apache.org/jira/browse/SIS-311
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Referencing
>Affects Versions: 0.6
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Labels: WKT
> Fix For: 0.7
>
>
> {{GeodeticObjectParser}} parses the {{AREA}} and {{BBOX}} elements as
> expected, but do not put them in the properties map given to {{CRSFactory}}.
> Consequently the domain of validity do not appear in the CRS created by the
> WKT parser.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SIS-312) Axis abbreviation with nested parenthesis confuse the WKT parser
[
https://issues.apache.org/jira/browse/SIS-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux resolved SIS-312.
-
Resolution: Fixed
> Axis abbreviation with nested parenthesis confuse the WKT parser
>
>
> Key: SIS-312
> URL: https://issues.apache.org/jira/browse/SIS-312
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Referencing
>Affects Versions: 0.6
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Labels: WKT
> Fix For: 0.7
>
>
> EPSG dataset sometime contains axis with properties like below:
> * name: {{Easting}}
> * abbreviation: {{E(X)}}
> which is formatted in WKT as "Easting (E(X))". But {{GeodeticObjectParser}}
> wrongly parses that WKT as below:
> * name: {{Easting E(}}
> * abbreviation: {{X)}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (SIS-313) Formatter should tell that "North along 130°W" axis direction requires version 2 of WKT
[
https://issues.apache.org/jira/browse/SIS-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux resolved SIS-313.
-
Resolution: Fixed
> Formatter should tell that "North along 130°W" axis direction requires
> version 2 of WKT
> ---
>
> Key: SIS-313
> URL: https://issues.apache.org/jira/browse/SIS-313
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Referencing
>Affects Versions: 0.6
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Labels: WKT
> Fix For: 0.7
>
>
> The WKT 1 format supported only axis directions like _"East"_, _"West"_,
> _"North"_ and _"South"_. The WKT 2 format add support for directions like
> _"North along 130°W"_, which are used over poles. However writing those
> directions requires a particular syntax introduced only with WKT 2. Attempts
> to format those directions in older format result in invalid WKT 1 string.
> The WKT formatter should instead throw an {{UnformattableObjectException}} in
> such situation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SIS-309) URI in the ID element of WKT 2 wrongly taken as ID version number
[
https://issues.apache.org/jira/browse/SIS-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-309:
Summary: URI in the ID element of WKT 2 wrongly taken as ID version number
(was: URI in the ID element of WKT 2 wrongly taken as Id version number)
> URI in the ID element of WKT 2 wrongly taken as ID version number
> -
>
> Key: SIS-309
> URL: https://issues.apache.org/jira/browse/SIS-309
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Referencing
>Affects Versions: 0.6
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Labels: WKT
> Fix For: 0.7
>
>
> In WKT element like {{ID\[“EPSG”, 27572,
> URI\[“urn:ogc:def:crs:EPSG::27572”\]\]}} in which the version (an optional
> element between {{27572}} and {{URI}}) is omitted, the {{URI}} element is
> wrongly taken as the version.
> This bug does not happen if the {{ID}} has a version element.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SIS-163) Unsupported WKT 2 features
[
https://issues.apache.org/jira/browse/SIS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-163:
Description:
This page summarizes the WKT 2 features which are currently not supported in
Apache SIS. More details are provided in the sub-tasks for unsupported elements
and restrictions. The third sections is about recommendations that are not
mandatory, but that we do not yet follow.
h3. Unsupported WKT elements
* {{ParametricCRS}} (we need an implementation in the rest of SIS first).
* {{Bearing}} element for polar coordinate systems having a "clockwise" or
"counterClockwise" axis direction.
* {{BoundCRS}} element as the successor of the WKT 1 {{TOWGS84}} element.
* Time extent with named eras (e.g.{{TIMEEXTENT\["Jurassic", "Quaternary"\]}})
h3. Restrictions that we do not verify
* ISO 19162 restrictions on {{CompoundCRS}}: (_geographic_ or _projected_ or
_engineering_) followed by (_vertical_ or _parametric_) followed by _temporal_.
{color:green}(edit: fixed){color}
* ISO 19162 restrictions on axis name, abbreviation and directions (e.g.
geographic CRS shall be ‘_latitude_’, ‘_longitude_’).
* Precedence of EPSG codes over names for {{Conversion}} objects.
h3. Recommendations that we do not yet follow
* Formatter should be able to write the short WKT 2 keywords (currently we
format only the long ones, because they match the type names).
{color:green}(edit: fixed){color}
* We do not check the recommended maximum string lengths (80 characters in
names, 255 characters in other quoted texts, 4096 in total).
was:
This page summarizes the WKT 2 features which are currently not supported in
Apache SIS. More details are provided in the sub-tasks for unsupported elements
and restrictions. The third sections is about recommendations that are not
mandatory, but that we do not yet follow.
h3. Unsupported WKT elements
* {{ParametricCRS}} (we need an implementation in the rest of SIS first).
* {{Bearing}} element for polar coordinate systems having a "clockwise" or
"counterClockwise" axis direction.
* {{BoundCRS}} element as the successor of the WKT 1 {{TOWGS84}} element.
* Time extent with named eras (e.g.{{TIMEEXTENT\["Jurassic", "Quaternary"\]}})
h3. Restrictions that we do not verify
* ISO 19162 restrictions on {{CompoundCRS}}: (_geographic_ or _projected_ or
_engineering_) followed by (_vertical_ or _parametric_) followed by _temporal_.
* ISO 19162 restrictions on axis name, abbreviation and directions (e.g.
geographic CRS shall be ‘_latitude_’, ‘_longitude_’).
* Precedence of EPSG codes over names for {{Conversion}} objects.
h3. Recommendations that we do not yet follow
* Formatter should be able to write the short WKT 2 keywords (currently we
format only the long ones, because they match the type names).
* We do not check the recommended maximum string lengths (80 characters in
names, 255 characters in other quoted texts, 4096 in total).
> Unsupported WKT 2 features
> --
>
> Key: SIS-163
> URL: https://issues.apache.org/jira/browse/SIS-163
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Referencing
>Affects Versions: 0.4, 0.5, 0.6
>Reporter: Martin Desruisseaux
>Priority: Minor
>
> This page summarizes the WKT 2 features which are currently not supported in
> Apache SIS. More details are provided in the sub-tasks for unsupported
> elements and restrictions. The third sections is about recommendations that
> are not mandatory, but that we do not yet follow.
> h3. Unsupported WKT elements
> * {{ParametricCRS}} (we need an implementation in the rest of SIS first).
> * {{Bearing}} element for polar coordinate systems having a "clockwise" or
> "counterClockwise" axis direction.
> * {{BoundCRS}} element as the successor of the WKT 1 {{TOWGS84}} element.
> * Time extent with named eras (e.g.{{TIMEEXTENT\["Jurassic", "Quaternary"\]}})
> h3. Restrictions that we do not verify
> * ISO 19162 restrictions on {{CompoundCRS}}: (_geographic_ or _projected_ or
> _engineering_) followed by (_vertical_ or _parametric_) followed by
> _temporal_. {color:green}(edit: fixed){color}
> * ISO 19162 restrictions on axis name, abbreviation and directions (e.g.
> geographic CRS shall be ‘_latitude_’, ‘_longitude_’).
> * Precedence of EPSG codes over names for {{Conversion}} objects.
> h3. Recommendations that we do not yet follow
> * Formatter should be able to write the short WKT 2 keywords (currently we
> format only the long ones, because they match the type names).
> {color:green}(edit: fixed){color}
> * We do not check the recommended maximum string lengths (80 characters in
> names, 255 characters in other quoted texts, 4096 in total).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SIS-317) On-the-fly Geographic3D ↔ CompoundCRS conversion when formatting WKT 1
Martin Desruisseaux created SIS-317:
---
Summary: On-the-fly Geographic3D ↔ CompoundCRS conversion when
formatting WKT 1
Key: SIS-317
URL: https://issues.apache.org/jira/browse/SIS-317
Project: Spatial Information Systems
Issue Type: Improvement
Components: Referencing
Affects Versions: 0.6
Reporter: Martin Desruisseaux
Assignee: Martin Desruisseaux
Fix For: 0.7
According the ISO 19111 standard, ellipsoidal heights can not be represented by
standalone {{VerticalCRS}} instances. Instead they need to be part of a
three-dimensional {{GeographicCRS}} instance. Version 2 of Well Known Text
(WKT) format follows this specification, but version 1 had a different model.
In WKT 1, three-dimensional {{GeographicCRS}} did not existed. It is not even
possible to represent such CRS in WKT 1 because of heterogeneous units of
measurement. Instead, WKT 1 used a {{CompoundCRS}} made of a two-dimensional
{{GeographicCRS}} followed by a {{VerticalCRS}}. Since such structure is
illegal in today's model, we need to create it temporarily only during WKT 1
formatting and discard it immediately after.
Conversely, the WKT parser needs to convert the above-cited {{CompoundCRS}} to
a three-dimensional {{GeographicCRS}} on-the-fly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Work started] (SIS-317) On-the-fly Geographic3D ↔ CompoundCRS conversion when formatting WKT 1
[
https://issues.apache.org/jira/browse/SIS-317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on SIS-317 started by Martin Desruisseaux.
---
> On-the-fly Geographic3D ↔ CompoundCRS conversion when formatting WKT 1
> --
>
> Key: SIS-317
> URL: https://issues.apache.org/jira/browse/SIS-317
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Referencing
>Affects Versions: 0.6
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Labels: WKT
> Fix For: 0.7
>
>
> According the ISO 19111 standard, ellipsoidal heights can not be represented
> by standalone {{VerticalCRS}} instances. Instead they need to be part of a
> three-dimensional {{GeographicCRS}} instance. Version 2 of Well Known Text
> (WKT) format follows this specification, but version 1 had a different model.
> In WKT 1, three-dimensional {{GeographicCRS}} did not existed. It is not even
> possible to represent such CRS in WKT 1 because of heterogeneous units of
> measurement. Instead, WKT 1 used a {{CompoundCRS}} made of a two-dimensional
> {{GeographicCRS}} followed by a {{VerticalCRS}}. Since such structure is
> illegal in today's model, we need to create it temporarily only during WKT 1
> formatting and discard it immediately after.
> Conversely, the WKT parser needs to convert the above-cited {{CompoundCRS}}
> to a three-dimensional {{GeographicCRS}} on-the-fly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SIS-317) On-the-fly Geographic3D ↔ CompoundCRS conversion when formatting WKT 1
[
https://issues.apache.org/jira/browse/SIS-317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-317:
Description:
According the ISO 19111 standard, ellipsoidal heights can not be represented by
standalone {{VerticalCRS}} instances. Instead they need to be part of a
three-dimensional {{GeographicCRS}} instance. Version 2 of Well Known Text
(WKT) format follows this specification, but version 1 had a different model.
In WKT 1, three-dimensional {{GeographicCRS}} did not existed (it is not even
possible to represent such CRS in WKT 1 because of heterogeneous units of
measurement). Instead, WKT 1 used a {{CompoundCRS}} made of a two-dimensional
{{GeographicCRS}} followed by a {{VerticalCRS}}.
*Example (WKT 2 format):*
{noformat}
GEODCRS[“WGS 84 (3D)”,
DATUM[“World Geodetic System 1984”,
ELLIPSOID[“WGS84”, 6378137.0, 298.257223563, LENGTHUNIT[“metre”, 1]]],
PRIMEM[“Greenwich”, 0.0, ANGLEUNIT[“degree”, 0.017453292519943295]],
CS[ellipsoidal, 3],
AXIS[“Longitude (L)”, east, ORDER[1], ANGLEUNIT[“degree”,
0.017453292519943295]],
AXIS[“Latitude (B)”, north, ORDER[2], ANGLEUNIT[“degree”,
0.017453292519943295]],
AXIS[“Ellipsoidal height (h)”, up, ORDER[3], LENGTHUNIT[“metre”, 1]],
AREA[“World”],
BBOX[-90.00, -180.00, 90.00, 180.00]]
{noformat}
*Same example than above, but using WKT 1 format:*
{noformat}
COMPD_CS[“WGS 84 (3D)”,
GEOGCS[“WGS 84”,
DATUM[“World Geodetic System 1984”,
SPHEROID[“WGS84”, 6378137.0, 298.257223563]],
PRIMEM[“Greenwich”, 0.0],
UNIT[“degree”, 0.017453292519943295],
AXIS[“Longitude”, EAST],
AXIS[“Latitude”, NORTH]],
VERT_CS[“Ellipsoidal height”,
VERT_DATUM[“Ellipsoid”, 2002],
UNIT[“metre”, 1],
AXIS[“Ellipsoidal height”, UP]]]
{noformat}
The WKT 1 structure is illegal in today's model, so we need to create it
temporarily only during WKT 1 formatting and discard it immediately after.
Conversely, the WKT parser needs to convert the above-cited {{CompoundCRS}} to
a three-dimensional {{GeographicCRS}} on-the-fly.
was:
According the ISO 19111 standard, ellipsoidal heights can not be represented by
standalone {{VerticalCRS}} instances. Instead they need to be part of a
three-dimensional {{GeographicCRS}} instance. Version 2 of Well Known Text
(WKT) format follows this specification, but version 1 had a different model.
In WKT 1, three-dimensional {{GeographicCRS}} did not existed. It is not even
possible to represent such CRS in WKT 1 because of heterogeneous units of
measurement. Instead, WKT 1 used a {{CompoundCRS}} made of a two-dimensional
{{GeographicCRS}} followed by a {{VerticalCRS}}. Since such structure is
illegal in today's model, we need to create it temporarily only during WKT 1
formatting and discard it immediately after.
Conversely, the WKT parser needs to convert the above-cited {{CompoundCRS}} to
a three-dimensional {{GeographicCRS}} on-the-fly.
> On-the-fly Geographic3D ↔ CompoundCRS conversion when formatting WKT 1
> --
>
> Key: SIS-317
> URL: https://issues.apache.org/jira/browse/SIS-317
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Referencing
>Affects Versions: 0.6
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Labels: WKT
> Fix For: 0.7
>
>
> According the ISO 19111 standard, ellipsoidal heights can not be represented
> by standalone {{VerticalCRS}} instances. Instead they need to be part of a
> three-dimensional {{GeographicCRS}} instance. Version 2 of Well Known Text
> (WKT) format follows this specification, but version 1 had a different model.
> In WKT 1, three-dimensional {{GeographicCRS}} did not existed (it is not even
> possible to represent such CRS in WKT 1 because of heterogeneous units of
> measurement). Instead, WKT 1 used a {{CompoundCRS}} made of a two-dimensional
> {{GeographicCRS}} followed by a {{VerticalCRS}}.
> *Example (WKT 2 format):*
> {noformat}
> GEODCRS[“WGS 84 (3D)”,
> DATUM[“World Geodetic System 1984”,
> ELLIPSOID[“WGS84”, 6378137.0, 298.257223563, LENGTHUNIT[“metre”, 1]]],
> PRIMEM[“Greenwich”, 0.0, ANGLEUNIT[“degree”, 0.017453292519943295]],
> CS[ellipsoidal, 3],
> AXIS[“Longitude (L)”, east, ORDER[1], ANGLEUNIT[“degree”,
> 0.017453292519943295]],
> AXIS[“Latitude (B)”, north, ORDER[2], ANGLEUNIT[“degree”,
> 0.017453292519943295]],
> AXIS[“Ellipsoidal height (h)”, up, ORDER[3], LENGTHUNIT[“metre”, 1]],
> AREA[“World”],
> BBOX[-90.00, -180.00, 90.00, 180.00]]
> {noformat}
> *Same example than above, but using WKT 1 format:*
> {noformat}
> COMPD_CS[“WGS 84 (3D)”,
> GEOGCS[“WGS 84”,
> DATUM[“World Geodetic System 1984”,
> SPHEROID[“WGS84”, 6378137.0, 298.257223563]],
>
[jira] [Updated] (SIS-317) On-the-fly Geographic3D ↔ CompoundCRS conversion when parsing/formatting WKT 1
[
https://issues.apache.org/jira/browse/SIS-317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-317:
Summary: On-the-fly Geographic3D ↔ CompoundCRS conversion when
parsing/formatting WKT 1 (was: On-the-fly Geographic3D ↔ CompoundCRS
conversion when formatting WKT 1)
> On-the-fly Geographic3D ↔ CompoundCRS conversion when parsing/formatting WKT 1
> --
>
> Key: SIS-317
> URL: https://issues.apache.org/jira/browse/SIS-317
> Project: Spatial Information Systems
> Issue Type: Improvement
> Components: Referencing
>Affects Versions: 0.6
>Reporter: Martin Desruisseaux
>Assignee: Martin Desruisseaux
> Labels: WKT
> Fix For: 0.7
>
>
> According the ISO 19111 standard, ellipsoidal heights can not be represented
> by standalone {{VerticalCRS}} instances. Instead they need to be part of a
> three-dimensional {{GeographicCRS}} instance. Version 2 of Well Known Text
> (WKT) format follows this specification, but version 1 had a different model.
> In WKT 1, three-dimensional {{GeographicCRS}} did not existed (it is not even
> possible to represent such CRS in WKT 1 because of heterogeneous units of
> measurement). Instead, WKT 1 used a {{CompoundCRS}} made of a two-dimensional
> {{GeographicCRS}} followed by a {{VerticalCRS}}.
> *Example (WKT 2 format):*
> {noformat}
> GEODCRS[“WGS 84 (3D)”,
> DATUM[“World Geodetic System 1984”,
> ELLIPSOID[“WGS84”, 6378137.0, 298.257223563, LENGTHUNIT[“metre”, 1]]],
> PRIMEM[“Greenwich”, 0.0, ANGLEUNIT[“degree”, 0.017453292519943295]],
> CS[ellipsoidal, 3],
> AXIS[“Longitude (L)”, east, ORDER[1], ANGLEUNIT[“degree”,
> 0.017453292519943295]],
> AXIS[“Latitude (B)”, north, ORDER[2], ANGLEUNIT[“degree”,
> 0.017453292519943295]],
> AXIS[“Ellipsoidal height (h)”, up, ORDER[3], LENGTHUNIT[“metre”, 1]],
> AREA[“World”],
> BBOX[-90.00, -180.00, 90.00, 180.00]]
> {noformat}
> *Same example than above, but using WKT 1 format:*
> {noformat}
> COMPD_CS[“WGS 84 (3D)”,
> GEOGCS[“WGS 84”,
> DATUM[“World Geodetic System 1984”,
> SPHEROID[“WGS84”, 6378137.0, 298.257223563]],
> PRIMEM[“Greenwich”, 0.0],
> UNIT[“degree”, 0.017453292519943295],
> AXIS[“Longitude”, EAST],
> AXIS[“Latitude”, NORTH]],
> VERT_CS[“Ellipsoidal height”,
> VERT_DATUM[“Ellipsoid”, 2002],
> UNIT[“metre”, 1],
> AXIS[“Ellipsoidal height”, UP]]]
> {noformat}
> The WKT 1 structure is illegal in today's model, so we need to create it
> temporarily only during WKT 1 formatting and discard it immediately after.
> Conversely, the WKT parser needs to convert the above-cited {{CompoundCRS}}
> to a three-dimensional {{GeographicCRS}} on-the-fly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
