Hi Martin,
What an excellent debrief, thank you for the notes.
Can you pint me to the outcomes of the best practices for JSON session(s)?
Thank you
Lewis

On Tue, Apr 3, 2018 at 7:32 AM, <[email protected]> wrote:

>
> From: Martin Desruisseaux <[email protected]>
> To: [email protected]
> Cc:
> Bcc:
> Date: Fri, 30 Mar 2018 16:27:39 +0200
> Subject: Report on some topics from OGC meeting last week
> Hello all
>
> An Open Geospatial Consortium (OGC) meetings happened last week in
> Orléans. Below is a few notes on topics that attracted my attention (of
> course much more were discussed during the meeting):
>
>
>       Which OGC standards for the cloud?
>
> One topic discussed during the meeting was execution of user-provided
> algorithms on the cloud, for avoiding the cost of transferring large
> amount of data to the user machine. We had an update of NOAA Big Data
> Project [1] with three questions:
>
>  1. What OGC standards are still relevant when data are hosted (and
>     computed on) in the Cloud?
>  2. Which OGC standards are not relevant when the end user is also in
>     the Cloud?
>  3. What new/revised OGC standards are needed?
>
> An other initiative facing the same questions is openEO [2], also
> presented during the meeting. That initiative proposes an API in Python
> which can be executed on the clouds. It seems to have similar goals than
> GeoAPI, with a different approach:
>
>   * GeoAPI follows closely OGC/ISO abstract models, while openEO seems
>     to define their own model.
>   * (Partially a consequence of above) GeoAPI defines low-level objects
>     (metadata, referencing) and is progressing toward high-level objects
>     (features, coverages) while openEO starts from high-level objects
>     (image, /etc/).
>
> Those questions can be discussed on a GitHub issue [3]. Note that the
> Google Earth Engine given in example seems to use a mechanism similar to
> Java Remote Method Invocation (RMI); even if the syntax is different, we
> can recognize stubs, /etc./
>
> The GeoAPI meeting presented a first draft of metadata API in Python
> [4], in complement to the already existing Java interfaces. We plan to
> provide two proof-of-concepts, one using GDAL-Python bindings and one
> using Java-Python bindings (the later will enable the use of Apache SIS
> in Python for instance). Another email specifically on GeoAPI will be
> posted later.
>
>
>       Blockchain
>
> Another session discussed Distributed Ledger (Blockchain) technology.
> The "OGC essentials" standards are used for recording locations. The
> aims to to provide cryptographically signed and verified
> presence-claims. Some usage examples are birth certificates, land or
> house ownership, and access to a property. The presenter expressed a
> need for an international standard, in part because smart contracts
> needs to be able to reason about location. Some work are progressing in
> a new International Organization for Standardization group, ISO/TC 307
> [5] (as a reminder, the group for geospatial information is ISO/TC 211),
> but ISO/TC 307 does not seem to include location information yet. Some
> company proposes to work with OGC [6], but I'm not yet aware of a
> communication channel where the discussion happen.
>
>
>       Others
>
> In addition to above, ad-hoc meetings were held to discuss the use of
> Non-Authoritative Data, Earth Observation Exploitation Platforms,
> Interoperable Simulation and Gaming, best practices for JSON, and
> Statistics. They were also talks about "fog computing", as a variant of
> "cloud computing" where the computers are local devices instead than
> servers. An example is autonomous cars collaborating together for
> resolving an urgent problem, where there is no time for communicating
> with distant servers.
>
>     Martin
>
>
> [1] http://www.noaa.gov/big-data-project
> [2] http://openeo.org/openeo/news/2018/03/17/poc.html
> [3] https://github.com/ogcscotts/TC-Meeting-topics/issues/28
> [4] https://github.com/opengeospatial/geoapi/tree/
> master/geoapi/src/main/python/ogc/metadata
> [5] https://www.iso.org/committee/6266604.html
> [6] https://blog.foam.space/crypto-spatial-coordinate-
> standard-and-the-open-geospatial-consortium-technical-committee-
> dffb0bd14c7c
>
>
>


-- 
http://home.apache.org/~lewismc/
http://people.apache.org/keys/committer/lewismc

Reply via email to