[SoC] [GRASS-dev] GSoC 2017 Weekly Report 12 - SOS tools in GRASS GIS

[Ondřej Pešek]

Hi Madi,

oh, I'm sorry. I have read that manual, but I have thought that the final
report will be the next one. My fault. So here it is reelaborated.

*Project Title:*
SOS tools in GRASS GIS

*Organization:*
Google Summer of Code 2017
Open Source Geospatial Foundation (OSGeo)
GRASS GIS

*Abstract:*
Intended modules would enable the user to create a vector, a raster based
on some aggregations and create a space time vector or raster dataset,
everything directly from user's access to the SOS server. t.vect.to.rast
would also allow the user to convert a space time vector dataset into a
raster dataset. The user should be also allowed to get the capabilities to
get info about sensors from these modules and filter the results.

*Pre-GSoC:*
GRASS GIS didn't have any module to work with Sensor Observation Service
(SOS). When the user wanted to use data from his SOS server, he had to
access them through OWSLib, convert them into GRASS GIS or OGR supported
format ad then import it somehow to GRASS GIS as one huge file.

*Added value:*
v.in.sos imports data from SOS server as a vector map to GRASS GIS. It
creates one layer for each offering and observed property.
r.in.sos imports data from SOS server as a raster maps to GRASS GIS. It
creates new raster map for each timestamp. User is allowed to use some
aggregations and granularity to filter data.
t.vect.in.sos imports data from SOS server to GRASS GIS as a
spatio-temporal vector dataset. It creates new stvds for each offering and
observed property (created from one vector map as an intermediate).
t.rast.in.sos imports data from SOS server to GRASS GIS as a
spatio-temporal raster dataset. It creates new strds for each property and
each procedure (registered from raster maps created as intermediates).
t.vect.to.rast doesn't import data from SOS server to GRASS GIS. It
converts a space time vector dataset into a space time raster dataset.

*Continued Work:*
There are some issues or possible enhancements in the modules.
v.in.sos uses timestamps as column names for each layer. The problem is
that it is not possible to have more than 3000 columns in SQLite table
(GRASS GIS attribute table) without SQLite recompilation. It will be little
bit solved by granularity and this module isn't so necessary when there is
t.vect.in.sos, but it is still useful for some purposes and this is really
lack.
t.vect.to.rast is working, but if you take  look at t.rast.to.vect, you can
see much more options. It would be great to involve them also into this
module.
It would be also great to have a flag for ignoring empty procedures in all
the modules.


*Link:*
The modules github repository:
https://github.com/pesekon2/GRASS-GIS-SOS-tools
(they should be moved into the official GRASS GIS add-ons repository in the
future)

*One image to show how can visualized sensors look on the OSM map:*
https://raw.githubusercontent.com/pesekon2/GRASS-GIS-SOS-tools/d566c868a50f12ba6fc4e1d6b953e9708e4b0061/image_vector_import.png


2017-08-18 22:22 GMT+02:00 Margherita Di Leo <diregola at gmail.com>:

> Hi Ondrej,
>
> Thank you for your report.
> Note that this is your final report and was supposed to be a summary of
> your work. Please, read https://lists.osgeo.org/pipermail/soc/2017-August/
> 003827.html and re-elaborate your report to meet the given template
>
> --
> Margherita Di Leo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/soc/attachments/20170822/a43a66af/attachment.html>