[OSGeo-Discuss] Improving usability of INSPIRE data in FOSS4G client applications

Sat Dec 21 01:52:01 PST 2019

I think my point was that there is often funding available for servers to
make new standards available; but without funding libraries to make new
standards accessible *to developers* these activities follow the "build it
and they will come" hope of the field of dreams movie.

I encourage everyone involved to look at the bigger whole-use architecture
picture, identify weak areas and seek out funding/collaboration/advocacy
opportunities. We are notoriously poor at funding core library development,
required to make services available to developers. I appreciate you current
activity evaluating client applications as a step in identifying gaps;
perhaps JRC can reach out to the new OSGeo board as they identify community
and partner goals for 2020 :)

aside: One of my hopes for the new OGCAPI activities is that they include
an OpenAPI REST endpoint that can be used to generate very simple clients
to talk to specific datasets. This will make geospatial data available to a
wider developer community, but it comes at some tradeoffs. I expect the
servers to be less capable initially (something we we can work on over
time) and I expect many of the resulting applications to be brittle (with a
hard coded generated client that will break as data products change).
--
Jody Garnett

On Fri, 20 Dec 2019 at 09:51, Marco Minghini <marco.minghini86 at gmail.com>
wrote:

> Dear all,
>
> Maria and Jochen: many thanks for your positive feedback on our work, we
> are happy to know that this is useful.
>
> Jody: thanks for your suggestion. Two quick comments here. First, the main
> purpose of the comparison was to give INSPIRE implementers an idea of which
> functionality is supported by which client so that they can make an
> informed choice when deciding which solution(s) to use. Also, although
> improvements are clearly possible, please note that in many cases OGR
> already provides the needed functionality but the clients themselves are
> not making the best use of it. This is a clear example about QGIS [1]: a
> simple fix in an OGR-related configuration option would generate an immense
> benefit to INSPIRE users.
>
> Best regards,
> Alex and Marco
>
> [1] https://github.com/qgis/QGIS/issues/29641
> <https://www.mdpi.com/journal/remotesensing/special_issues/appl_VGI>
>
>
> Il giorno gio 12 dic 2019 alle ore 23:35 Jody Garnett <
> jody.garnett at gmail.com> ha scritto:
>
>> Alex and Marco:
>>
>> For wider use of INSPIRE data please consider funding client libraries,
>> GeoTools, OGR, etc...
>> Adding support for the data formats, and the web services, to libraries
>> allow integration in a wind range of applications, utilities and automation
>> activities.
>> --
>> Jody Garnett
>>
>>
>> On Thu, 12 Dec 2019 at 17:09, Marco Minghini <marco.minghini86 at gmail.com>
>> wrote:
>>
>>> Dear all,
>>> at the European Commission - Joint Research Centre (JRC) we have been
>>> working with our Contractors (WeTransform and Epsilon Italia) on a set of
>>> actions aimed at improving the usability of INSPIRE data sets. For those
>>> who are not familiar with INSPIRE [1], this is the European Spatial Data
>>> Infrastructure (SDI) built on top EU Member States infrastructures to
>>> support European environmental policies.
>>>
>>> The rationale behind these actions is that GML is the default encoding
>>> for INSPIRE data because INSPIRE xml schemas are generated automatically
>>> from the conceptual UML models. These schemas are complex and many existing
>>> (web, desktop and mobile) client applications are not able to fully consume
>>> or make use of data shared according to these schemas.
>>>
>>> Two actions have been completed over the last year in order to:
>>> 1) improve client support for INSPIRE data
>>> 2) develop an alternative encoding for INSPIRE data (GeoJSON)
>>>
>>> Within the first Action [2], we compiled a "can I use" matrix [3]
>>> describing which functionality associated with the consumption of INSPIRE
>>> data (both in GML and GeoJSON) is supported by which client. The clients
>>> tested are QGIS, GRASS GIS, hale studio, OpenLayers and LeafletJS as well
>>> as some proprietary solutions.
>>>
>>> This e-mail is first of all to inform you about this Action and to show
>>> that, as you can notice in [3], open source solutions are currently the
>>> most successful ones, but some improvement is still possible. In this
>>> regard, we have established communication with the software PSC and/or
>>> communities and discussed the prioritisation of functionalities that should
>>> be improved or developed for each software to best satisfy user needs.
>>>
>>> Whenever other encodings (e.g. GeoPackage) for INSPIRE data will become
>>> available, the same approach should be followed.
>>>
>>> In addition, since the Action is formally completed but the outcomes
>>> will still be very important for the INSPIRE community in the future, we
>>> are currently exploring how to ensure the sustainability of the tool. In
>>> particular, we would open an invitation to anyone (project developers,
>>> users or communities, or simply interested people) to contribute to keep
>>> the matrix up-to-date by testing new/future versions of specific OSGeo
>>> tools (in particular those mentioned above - QGIS, GRASS GIS, OpenLayers
>>> and LeafletJS - but also other tools). The tests, described at [4], consist
>>> of general GIS tasks and do not require INSPIRE-specific knowledge.
>>> Interested people can also submit content through issues or pull requests
>>> in the GitHub repository [5] or contact us.
>>>
>>> Thank you all for your attention.
>>> Best regards,
>>> Alex and Marco
>>>
>>>
>>> [1] https://inspire.ec.europa.eu
>>> [2]
>>> https://webgate.ec.europa.eu/fpfis/wikis/pages/viewpage.action?pageId=418580131
>>> [3] https://inspire-mif.github.io/caniuse/generator/out.html
>>> [4] https://github.com/INSPIRE-MIF/caniuse/tree/master/docs
>>> [5] https://github.com/INSPIRE-MIF/caniuse
>>> _______________________________________________
>>> Discuss mailing list
>>> Discuss at lists.osgeo.org
>>> https://lists.osgeo.org/mailman/listinfo/discuss
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/discuss/attachments/20191221/29e1c4f2/attachment.html>