Re: Notes from OGC meeting

[Charitha Madusankha <ch...@gmail.com>]

Hi Martin.

I'm interesting to work on 'SIS for Android' [1]. So please provide some
background about it then I can start it asap.

Thanks,

[1] - https://svn.apache.org/repos/asf/sis/branches/Android/

On 19 June 2014 at 21:30, Martin Desruisseaux <de...@apache.org>
wrote:

> Hello all
>
> The OGC meeting was hold in Geneva form June 10 to 13. We lost the last
> day because of French train strike, so this email is only about June 10
> to 12. In this email, I try to explain better why an item is relevant to
> Apache SIS with separated "Relevance to SIS" paragraphs.
>
>
> Standardization process
> ------------------------------------------------------------
> OGC is considering to classify their standards in 3 groups:
>
>   * Community specification, developed outside OGC but so widely used
>     that they are worth to be adopted as an official OGC position.
>   * Provisional OGC standard, which follow OGC policy (modularization,
>     etc.) but have no evidence of implementation and no CITE tests.
>   * Full OGC standards: same as provisional except that there is strong
>     evidence of implementation and maturity, and CITE test exists.
>
>
> GeoAPI is concerned by the "Provisional" versus "Full" OGC standard. For
> example GeoAPI provides its own test suite (the "geoapi-conformance"
> module [1]) instead than the CITE tests. This situation exists because
> of the particular GeoAPI nature compared to other OGC standard, since
> GeoAPI is neither an encoding standard nor a web service standard.
> Closer ties between CITE tests and "geoapi-conformance" is desirable,
> but we would need volunteer help for that.
>
>
> GeoAPI
> ------------------------------------------------------------
> I posted a subset of GeoAPI slides below. The most important thing is
> the Feature model proposal:
>
> http://people.apache.org/~desruisseaux/GeoAPI/2014-06.pdf
> See also GeoAPI snapshot javadoc [3]
>
> We had about 7 peoples in the room. We got no comment yet on the feature
> model. We got a comment that explicit support for circles is needed for
> user location with a mobile device in GeoXACML 3.0. GML already has
> Circle and CircleByCenterPoint, but the geometry interfaces do not yet
> have a Circle interface. The next ISO 19107 revision may include
> circles, in which case the GeoAPI interfaces will be updated accordingly.
>
> *Relevance to Apache SIS:* GeoAPI interfaces are implemented directly by
> Apache SIS. If there is any comments on the above Feature model, please
> let us know!
>
>
> Moving features
> ------------------------------------------------------------
> The current scope of moving features is massive data exchange. Scope of
> a future revision may be web service interface. The current scope has
> two parts: Part I defines the XML core encoding while part II defines a
> simple CSV format. The later is expected to be used most often. Those
> formats can be seen as an implementation of "ISO 19141:2008 - Schema for
> moving features" [2] model. The OGC Moving Features specification is
> targeted for completion on December this year.
>
> *Relevance to Apache SIS:* we have not yet checked if the current
> Feature API proposal [3] is consistent with Moving Features. This is
> another area where volunteer help would be welcome.
>
>
> Data quality and user feedbacks
> ------------------------------------------------------------
> Apache SIS provides an "org.apache.sis.metadata.iso.quality" package [4]
> based on standard published in 2003. The new standard revision, ISO
> 19157, combines 3 older standards in a unified conceptual model. When
> Apache SIS will be updated for that new standard, this is expected to
> double the number of classes in the
> "org.apache.sis.metadata.iso.quality" package.
>
> There is an other standard under development, ISO 8000, which has a yet
> wider scope. ISO 8000 seems to have about 150 parts (if I understood
> right), which I think would be beyond the Apache SIS scope. If I
> understand right, ISO 19157 (which Apache SIS would support) could be
> seen as a subset of ISO 8000. However if anyone wanted full ISO 8000
> support, I suspect that it could be the scope of a different Apache
> project.
>
> An other data quality model is UncertML. UncertML provides some
> probability distributions that can be used to express uncertainties in
> positions, continue attributes, etc., but does not try to address (in my
> understanding) other kind of values like confusion matrix, counting
> number of conflicts, etc. They were some discussion about how to combine
> UncertML with ISO 19157.
>
> *Relevance to Apache SIS:* we will need to update the
> "org.apache.sis.metadata.iso.quality" package, but make clear that the
> scope is not full data quality in ISO 8000 sense.
>
>
> User feedbacks
> ------------------------------------------------------------
> "Data quality" (ISO 19157) can be seen as a kind of metadata (ISO
> 19115), and "user feedbacks" can be seen as a kind of "data quality".
> The GeoViQua and CHARMe projects are experiments for complementing the
> existing ISO 19157 elements with accumulated reports from data users.
> The idea is to provide rankings like on the Amazon web site. This is a
> different model than the current one:
>
>   * ISO 19157 is a "producer quality model" (quality recorded by the
>     producer).
>   * GeoViQua and CHARMeare are "consumer quality model" (attempts to
>     post-qualify the dataset).
>   * An other model mentioned but not discussed is "stakeholder quality
>     model".
>
>
> However the "consumer quality model" raises the issue of users as a
> source of error. This issue may be reported by the ISO 19157
> "metaquality" (quality of the quality) element. One way to reduce the
> problem is to iterate with the users. For example sending a request for
> more information, asking same question in different ways, suggesting
> that the user move to a different location, asking other users in the
> area to confirm the observation, re-evaluating the quality of previous
> observations as new information is made available.
>
> The above-cited GeoViQua project proposes QualityML as an extension of
> UncertainML. QualityML is a dictionary for quality metadata encoding.
> This is not yet a standard, but an experiment.
>
> *Relevance to Apache SIS:* we may need volunteer work for checking if
> user feedbacks should be supported as an
> "org.apache.sis.metadata.iso.quality" extension, maybe in an
> experimental module.
>
>
> GeoTIFF and NetCDF metadata
> ------------------------------------------------------------
> A mapping from GeoTIFF tags to the "Coverage" model (a generalization of
> rasters model) has been published [5]. A similar mapping from NetCDF to
> "Coverage" model is under way. A draft exists, but there is still open
> issues with OPeNDAP, especially their use of index for data access.
> After the "NetCDF to coverage" binding, a next goal may be "ncML to GML"
> (ncML is a XML encoding of NetCDF metadata.
>
> *Relevance to Apache SIS:* once the "NetCDF to coverage" standard is
> published, Apache SIS may need to revisit its NetCDF mapping
> implementation [6].
>
> The European Space Agency (ESA) is working on an extension of NetCDF
> standard attributes for Earth Observation products [7]. This proposal is
> compliant with CF-NetCDF and NetCDF-U (uncertainty convention). Final
> version is planned for July, and standardization through OGC may come
> later.
>
> *Relevance to Apache SIS:* the mapping of Earth Observation attributes
> to ISO 19115 metadata is not yet clear to me. But if a volunteer is
> willing to investigate, we should augment our NetCDF mapping
> implementation [6] with those Earth Observation attributes.
>
>
> GML in JPEG2000
> ------------------------------------------------------------
> GMLJP2 version 2.0 is under work. The new specification will clarify
> some GMLJP2 1.0 ambiguities (e.g. axis order), and may add support for
> "georeferenceable" [8] images (not to be confused with "georeferenced"
> images, which are already supported). They were also a request for
> motion image annotations.
>
>
> (Transactional) Web Coverage Service
> ------------------------------------------------------------
> WCS-t contains 3 operations: insert, delete and update. The "update"
> operation is the hard one to define. Work is still going on the later.
> As a side-note, some peoples expressed the need to be able to determine
> if a bounding box contains any non-null value before to request a
> coverage (raster) in that area. The goal is to reduce the transfer size.
>
> Some peoples are investigating JPEG 2000 Interactive Protocol (JPIP) for
> streaming of coverages with reduced band width usage. An other aspect
> under study is asynchronous access to WCS coverages via FTP or on DVD
> (user noticed when ready).
>
>
> Linked data
> ------------------------------------------------------------
> While I'm not aware of an OGC standard specifically related to linked
> data, OGC is thinking about this long-term tendency. The current World
> Wide Web hyperlinks focus on "document about things". The Linked Data
> approach rather focuses about thing themselves. This will require things
> to have a unique and persistent identifiers.
>
> *Relevance to Apache SIS:* SIS already tries to prepare itself with the
> IdentifiedObject interface [9]. We do not know yet if the SIS approach
> will work well, since I'm not aware of feedback yet.
>
>
> Mobile location services (MLS), a.k.a. "Mass market"
> ------------------------------------------------------------
> The "mass market" working group has been renamed Mobile Location
> Services (MLS) domain working group.
>
> *Relevance to Apache SIS:* we have an orphan "SIS for Android" branch
> [10]. If we get a volunteer for maintaining that branch, we may need to
> follow Mobile Location Services activity in order to apply relevant
> recommendations to our branch.
>
>     Martin
>
>
> [1] http://www.geoapi.org/geoapi-conformance/index.html
> [2]
>
> http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=41445
> [3]
>
> http://www.geoapi.org/snapshot/javadoc/org/opengis/feature/package-summary.html
> [4]
>
> http://sis.apache.org/apidocs/org/apache/sis/metadata/iso/quality/package-summary.html
> [5] https://portal.opengeospatial.org/files/?artifact_id=54813
> [6]
>
> http://sis.apache.org/apidocs/org/apache/sis/storage/netcdf/AttributeNames.html
> [7]
> http://wiki.services.eoportal.org/tiki-index.php?page=Prod-Trees+Resources
> [8]
>
> http://www.geoapi.org/snapshot/javadoc/org/opengis/metadata/spatial/Georeferenceable.html
> [9] http://sis.apache.org/apidocs/org/apache/sis/xml/IdentifiedObject.html
> [10] https://svn.apache.org/repos/asf/sis/branches/Android/
>
>


-- 
Charitha Madusanka
Linkdin : http://www.linkedin.com/pub/charith-madusanka/1a/508/42a
Twitter  : http://twitter.com/#!/charithccmc

Re: Android branch

[Martin Desruisseaux <ma...@geomatys.fr>]

Le 08/01/15 17:43, Martin Desruisseaux a écrit :
> Anyway, I think that the most difficult task will the the JAXB issue.

An idea: I played a little bit with Annotation Processing Tools (APT)
and found them surprisingly powerful. I think it would be possible to
write an APT which automatically replace JAXB annotations by Java code
using the Android XML API. This action would be performed at
compile-time (no runtime dependency). If someone is interested in
exploring that path, I could write a starting point (an APT skeleton
that intercept JAXB annotations, and configure the Maven build to run
that APT).

    Martin

Re: Android branch (was: Notes from OGC meeting)

[Martin Desruisseaux <ma...@geomatys.fr>]

Hello Charitha

Le 08/01/15 16:58, Charitha Madusankha a écrit :
> I'm interesting to work on 'SIS for Android' [1]. So please provide some
> background about it then I can start it asap.

That would be hugely appreciated! We currently have an Android branch,
but is it is almost identical to trunk:

https://svn.apache.org/repos/asf/sis/branches/Android/

I think that the very first step would be to configure the Maven build
in order to get compiler errors when using JDK classes that are not
available on the Android platform. I didn't investigated how to do that.

Next, we would probably get a massive amount of compiler errors caused
by our use of JAXB (which is not available on Android as far as I know).
So the question would be: do we want to support reading/writing of XML
metadata documents (ISO 19139) on the Android platform? If not, we could
delete or disable JAXB dependencies on the Android branch.

An other source of compiler errors would be Java2D dependencies, but I
already managed to isolate those dependencies in separated classes in
anticipation to Android branch. One of the tasks will be to replace
usage of java.awt.geom.AffineTransform2D by android.graphics.Matrix [1].

Anyway, I think that the most difficult task will the the JAXB issue.
Any though about that?

Note: I didn't merged the trunk to the Android branch for a long time.
Do you want me to do that this week?

    Martin

[1] http://developer.android.com/reference/android/graphics/Matrix.html