[GRASS-user] Saving Linestring layer to SQLite

GRASS GRASS user
, ,
1

Hi,

I have been struggling for a few days now with importing Linestring layers into Spatialite.

Everytime I save the layers into a sqlite file, they are automatically converted to MultiLinestring, even though they are perfectly normal Linestring files in all other formats I tested (SHP and TAB).

Has anybody come across this before?

Cheers,

Pedro

···

On Wed, Jan 25, 2017 at 6:00 AM, <grass-user-request@lists.osgeo.org> wrote:

Send grass-user mailing list submissions to
grass-user@lists.osgeo.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.osgeo.org/mailman/listinfo/grass-user
or, via email, send a message with subject or body ‘help’ to
grass-user-request@lists.osgeo.org

You can reach the person managing the list at
grass-user-owner@lists.osgeo.org

When replying, please edit your Subject line so it is more specific
than “Re: Contents of grass-user digest…”

Today’s Topics:

  1. Re: Archiving GPM 3hr rainrate in GRASS (Laurent C.)
  2. Question to the input seed grid of i.segment (Raphael Knevels)
  3. Re: Question to the input seed grid of i.segment (Moritz Lennert)
  4. Re: Question to the input seed grid of i.segment (Raphael Knevels)

Message: 1
Date: Tue, 24 Jan 2017 11:39:37 -0600
From: “Laurent C.” <lrntct@gmail.com>
To: Veronica Andreo <veroandreo@gmail.com>
Cc: grass list <grass-user@lists.osgeo.org>
Subject: Re: [GRASS-user] Archiving GPM 3hr rainrate in GRASS
Message-ID:
<CABmXgEH7Wd==FbfB9fEDfD3Ud+LUSXzj1Rfhk7JpmY-aJVs1yg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

Hello Veronica,

Thanks for your interest. I’ve made some change to the code,
especially added a HTML file. I think it was the reason why
g.extension was failing.
The installation works now from a local folder. For some reason it
seems that g.extension fails to download the code from bitbucket.
If you download the repository of clone it first, it should work.
I’d be glad to hear your comments.

Cheers,
Laurent

2017-01-22 6:56 GMT-06:00 Veronica Andreo <veroandreo@gmail.com>:

Hello Laurent

w00t! This new add-on sounds very nice! I’d like to do some testing.
However, I tried to install it via g.extension and I get the following:

g.extension extension=t.rast.in.gpm
url=https://bitbucket.org/lrntct/t.rast.in.gpm
Fetching <t.rast.in.gpm> from
<https://bitbucket.org/lrntct/t.rast.in.gpm/get/default.zip> (be
patient)…
ERROR: Extension <t.rast.in.gpm> not found

Is it intended to install with g.extension?

thanks much!
Vero

2017-01-21 1:04 GMT+01:00 Laurent C. <lrntct@gmail.com>:

Hello all,

I wrote a module that automatically download, import and register GPM
IMERG maps in GRASS.
You will need a NASA Earthdata Login to download the data. The code
can be found here:
https://bitbucket.org/lrntct/t.rast.in.gpm

For now, it is limited to IMERGHH data.
Hope it could help people working with those data.

Regards,
Laurent

2015-03-19 10:50 GMT-06:00 Laurent C. <lrntct@gmail.com>:

Hi all,

I’m coming back to that subject because the GPM datas are finally
available
since December 2014. The original data are stored in HDF5, which is
supported by GDAL.
However, I had a problem with the geo-referencing of the data. It seems
that
the lat/long coordinates are flipped.
The problem seems to come from GDAL, as the HDF5 driver still don’t
support
GPM data:
http://www.gdal.org/frmt_hdf5.html

I’ve actually downloaded a regional extracts the data in NetCDF from a
NASA
website, although I can’t remember where exactly, as there are several
services. Those data suffer from the same problem of inverted
coordinates.

So I used the ncpdq from NCO package to fix the NetCDF directly, and a
tiny
Python script to batch process the files :

#!/usr/bin/env python
from os import listdir
import subprocess
for input_file in listdir(main_path):
output_file = input_file + ‘_fixed’
subprocess.call([‘ncpdq’,‘-a’, ‘lat,lon’, input_file, output_file])

After batch import the data in GRASS, maintaining the original name
including timestep, which looks like this:
3B-HHR.MS.MRG.3IMERG.20140619-S000000-E002959.0000.V03D

A Python script to register the maps in temporal framework:

#!/usr/bin/env python
import grass.script as grass

retrieve the list of maps

maplist = grass.read_command(‘g.list’, type = ‘raster’,
pattern = ‘IMERG’)

turn result in a list

maplist = maplist.split()

file_name = ‘gpm_timestamp.txt’

creating the file containing the timepstamp

list_file = open(file_name,‘w’)

iterate through the maps

for input_map in maplist:

split line to keep only the timestamp

raw_ts = input_map.split(‘.’)[4]

isolate the date

raw_mapdate = raw_ts.split(‘-’)[0]

put the date in form

mapdate = raw_mapdate[:4] + ‘-’ + raw_mapdate[4:6] +
‘-’ + raw_mapdate[6:]

isolate the start time

raw_start_time = raw_ts.split(‘-’)[1]

put the date in form

start_time = raw_start_time[1:3] + ‘:’ +
raw_start_time[3:5] + ‘:’ + raw_start_time[5:]

isolate the end time

raw_end_time = raw_ts.split(‘-’)[2]

put the end time in form

end_time = raw_end_time[1:3] + ‘:’ +
raw_end_time[3:5] + ‘:’ + raw_end_time[5:]

put timestamp in form

timestamp = mapdate + ’ ’ + start_time + ‘|’ + mapdate +
’ ’ + end_time

format the whole line

line = input_map + ‘|’ + timestamp + ‘\n’

write line to the file

list_file.write(line)

close the file

list_file.close()

register the maps in grass space_time dataset

grass.run_command(‘t.register’, input = ‘GPM_ZMCM’, file = file_name)

Hope it will help other peoples having trouble using those data.

Regards,
Laurent

2014-11-06 5:15 GMT-06:00 maning sambale <emmanuel.sambale@gmail.com>:

Thanks Markus. Already registered and can access ftp. Unfortunately,
processed (L3) rainfall data will be released by Dec 2014.
Will just wait then. :slight_smile:

On Thu, Nov 6, 2014 at 4:27 PM, Markus Neteler <neteler@osgeo.org>
wrote:

On Mon, Nov 3, 2014 at 10:18 AM, maning sambale
<emmanuel.sambale@gmail.com> wrote:

Has anyone here able to archive and load GPM dataset into GRASS? I
was able to get TRMM netcdf in my area of interest before, but I
can’t
find the tools to automate GPM downloads.

Thanks!

[0] http://www.nasa.gov/mission_pages/GPM/main/

They state

“All data are freely available through the NASA’s Precipitation
Processing System at http://pps.gsfc.nasa.gov”

→ “Register and search for GPM and TRMM data, order custom subsets
and set up subscriptions using PPS Data Products Ordering Interface
(STORM).”

At time the server seems to be down?

Markus

–
cheers,
maning

“Freedom is still the most radical idea of all” -N.Branden
wiki: http://esambale.wikispaces.com/
blog: http://epsg4253.wordpress.com/

grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

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

Message: 2
Date: Tue, 24 Jan 2017 18:42:22 +0100
From: “Raphael Knevels” <raphael.knevels@uni-jena.de>
To: <grass-user@lists.osgeo.org>
Subject: [GRASS-user] Question to the input seed grid of i.segment
Message-ID: <005f01d27669$380040b0$a800c210$@uni-jena.de>
Content-Type: text/plain; charset=“utf-8”

Dear GRASS-community,

I have to perform a multi-scale, object-oriented analysis on an image with
about 93’535’000 pixels^^

I’m doing the process on a server, so I need for one simple segmentation
process approximately 700-800 minutes depending on the threshold. The same
process in SAGA takes around 60 minutes with the use of seed points (as grid
pixels). But in SAGA there is no possibility for hierarchical segmentation.
Therefore, I would like to use the seed points of SAGA as Input for GRASS
7.2.0 to speed up i.segment.

However, I am not capable to transform the seeds of SAGA to a meaningful
i.segment input. How has to look an optimal input seeds grid for GRASS?

  • I’ve already found out is that it must be an integer grid with positive
    seed numbers. The float-grid output of SAGA seed contains single pixels
    surrounded by no-data values. When I transform the SAGA seed to an integer
    grid and into GRASS (by (r)gdal), I have to give no data values a positive
    number. Negative values in the seed-grid-input lead to an error in
    i.segment.

I would be glad for any hint and reply.

Best regards

-------------- next part --------------
An HTML attachment was scrubbed…
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20170124/105fbd3a/attachment-0001.html>

Message: 3
Date: Tue, 24 Jan 2017 19:10:45 +0100
From: Moritz Lennert <mlennert@club.worldonline.be>
To: grass-user@lists.osgeo.org,Raphael Knevels
<raphael.knevels@uni-jena.de>
Subject: Re: [GRASS-user] Question to the input seed grid of i.segment
Message-ID: <5E0E6C7A-402B-4F07-9C4F-B5C612C7D4E0@club.worldonline.be>
Content-Type: text/plain; charset=utf-8

Le 24 janvier 2017 18:42:22 GMT+01:00, Raphael Knevels <raphael.knevels@uni-jena.de> a écrit :

Dear GRASS-community,

I have to perform a multi-scale, object-oriented analysis on an image
with
about 93’535’000 pixels^^

I’m doing the process on a server, so I need for one simple
segmentation
process approximately 700-800 minutes depending on the threshold.

This does seem rather long. Is your computational region set to the extent and resolution of your raster ?

Also try setting the memory parameter of I.segment to a higher value (depending on your server’s resources).

Which thresholds have you tried ?

The
same
process in SAGA takes around 60 minutes with the use of seed points (as
grid
pixels).

Which segmentation algorithm do you use in SAGA ?

But in SAGA there is no possibility for hierarchical
segmentation.
Therefore, I would like to use the seed points of SAGA as Input for
GRASS
7.2.0 to speed up i.segment.

However, I am not capable to transform the seeds of SAGA to a
meaningful
i.segment input. How has to look an optimal input seeds grid for GRASS?

  • I’ve already found out is that it must be an integer grid with
    positive
    seed numbers. The float-grid output of SAGA seed contains single pixels
    surrounded by no-data values. When I transform the SAGA seed to an
    integer
    grid and into GRASS (by (r)gdal), I have to give no data values a
    positive
    number. Negative values in the seed-grid-input lead to an error in
    i.segment.

Seeds in i.segment have to be polygons not points. These polygons are represented by identical positive integer values (= IDs) in adjacent pixels, and they have to cover the entire region. When used as seeds for a segmentation, these polygons are the further merged.

I don’t really understand what your seed points represent, but unless they have a semantic meaning related to the objects you are trying to identify, I’m not sure they are really relevant.

You could try using the brand new i.superpixels.slic add-on to create superpixels which you can then use as seeds.

Moritz

Message: 4
Date: Tue, 24 Jan 2017 20:40:57 +0100
From: “Raphael Knevels” <raphael.knevels@uni-jena.de>
To: “‘Moritz Lennert’” <mlennert@club.worldonline.be>,
<grass-user@lists.osgeo.org>
Subject: Re: [GRASS-user] Question to the input seed grid of i.segment
Message-ID: <007201d27679$c93c2c50$5bb484f0$@uni-jena.de>
Content-Type: text/plain; charset=“UTF-8”

Thanks for the quick response :slight_smile:

The extent of my region is also the extent of my imagery-group. For i.segment I used as memory 10240 MB with a threshold of 0.25.

In SAGA I used at first Seed Generation (Band Width of 18, but I also varied this parameter) for producing the Seed Output. The Seed Output is a raster with floating point values. Moreover, the Seed Output contains single pixels distributed over the hole area. The “space” between those pixels is “no data”. The segmentation is then computed by Seeded Region Growing with the seed grid as input.

“Seeds in i.segment have to be polygons not points. These polygons are represented by identical positive integer values (= IDs) in adjacent pixels, and they have to cover the entire region. When used as seeds for a segmentation, these polygons are the further merged.”
→ alright. That means, I definitely must convert the no data values in the SAGA Seed Output to zero or any other integer number.
Meanwhile, I also tried the segmentation result of SAGA Seeded Region Growing as Seeds for GRASS - this works…

" You could try using the brand new i.superpixels.slic add-on to create superpixels which you can then use as seeds."
→ I could successfully install and open it (“g.extension i.superpixels.slic”, GRASS 7.2.0). However, when I run the tool with default settings, GRASS gives a problem message and finishs the process.

Raphael

-----Ursprüngliche Nachricht-----
Von: Moritz Lennert [mailto:mlennert@club.worldonline.be]
Gesendet: Dienstag, 24. Januar 2017 19:11
An: grass-user@lists.osgeo.org; Raphael Knevels
Betreff: Re: [GRASS-user] Question to the input seed grid of i.segment

Le 24 janvier 2017 18:42:22 GMT+01:00, Raphael Knevels <raphael.knevels@uni-jena.de> a écrit :

Dear GRASS-community,

I have to perform a multi-scale, object-oriented analysis on an image
with about 93’535’000 pixels^^

I’m doing the process on a server, so I need for one simple
segmentation process approximately 700-800 minutes depending on the
threshold.

This does seem rather long. Is your computational region set to the extent and resolution of your raster ?

Also try setting the memory parameter of I.segment to a higher value (depending on your server’s resources).

Which thresholds have you tried ?

The
same
process in SAGA takes around 60 minutes with the use of seed points (as
grid pixels).

Which segmentation algorithm do you use in SAGA ?

But in SAGA there is no possibility for hierarchical segmentation.
Therefore, I would like to use the seed points of SAGA as Input for
GRASS
7.2.0 to speed up i.segment.

However, I am not capable to transform the seeds of SAGA to a
meaningful i.segment input. How has to look an optimal input seeds grid
for GRASS?

  • I’ve already found out is that it must be an integer grid with
    positive seed numbers. The float-grid output of SAGA seed contains
    single pixels surrounded by no-data values. When I transform the SAGA
    seed to an integer grid and into GRASS (by (r)gdal), I have to give no
    data values a positive number. Negative values in the seed-grid-input
    lead to an error in i.segment.

Seeds in i.segment have to be polygons not points. These polygons are represented by identical positive integer values (= IDs) in adjacent pixels, and they have to cover the entire region. When used as seeds for a segmentation, these polygons are the further merged.

I don’t really understand what your seed points represent, but unless they have a semantic meaning related to the objects you are trying to identify, I’m not sure they are really relevant.

You could try using the brand new i.superpixels.slic add-on to create superpixels which you can then use as seeds.

Moritz

Subject: Digest Footer

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

End of grass-user Digest, Vol 129, Issue 35