Re: [GRASS-dev] [SoC] 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 :

> 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
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] v.in.osm working?

[Markus Neteler]

Hi,

does v.in.osm actually work? I am trying to import from a OSM PBF
file, for example:

http://download.geofabrik.de/europe/germany/berlin.html
--> berlin-latest.osm.pbf (51MB)

grass72 ~/grassdata/latlong_wgs84/osm
g.extension v.in.osm

v.in.osm input=Downloads/berlin-latest.osm.pbf table=lines
type=point,line output=roads --o
WARNING: Width for column osm_id set to 255 (was not specified by OGR),
 some strings may be truncated!
WARNING: Width for column name set to 255 (was not specified by OGR), some
 strings may be truncated!
WARNING: Width for column highway set to 255 (was not specified by OGR),
 some strings may be truncated!
WARNING: Width for column waterway set to 255 (was not specified by OGR),
 some strings may be truncated!
WARNING: Width for column aerialway set to 255 (was not specified by OGR),
 some strings may be truncated!
WARNING: Width for column barrier set to 255 (was not specified by OGR),
 some strings may be truncated!
WARNING: Width for column man_made set to 255 (was not specified by OGR),
 some strings may be truncated!
WARNING: Width for column other_tags set to 255 (was not specified by OGR),
 some strings may be truncated!
WARNING: Vector map  already exists and will be overwritten
WARNING: No data base element files found

v.info -t roads
nodes=0
points=0
lines=0
boundaries=0
centroids=0
areas=0
islands=0
primitives=0
map3d=0

I was following the example given in
https://grass.osgeo.org/grass72/manuals/addons/v.in.osm.html

but nothing is imported. Is it to be used differently?

thanks,
Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3405: encoding issue when launching modules

[GRASS GIS]

#3405: encoding issue when launching modules
--+---
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.4.0
 Component:  wxGUI|Version:  svn-trunk
Resolution:   |   Keywords:  g.search.modules encoding
   CPU:  Unspecified  |   Platform:  Unspecified
--+---

Comment (by mlennert):

 I just tested on my office computer with a fresh svn checkout, and cannot
 reproduce. It must be something on my home computer... I'll try again
 tonight, but maybe this is just noise...

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev