[GRASS-user] Saving Linestring layer to SQLite

[Pedro Camargo]

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,  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-requ...@lists.osgeo.org
>
> You can reach the person managing the list at
> grass-user-ow...@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." 
> To: Veronica Andreo 
> Cc: grass list 
> Subject: Re: [GRASS-user] Archiving GPM 3hr rainrate in GRASS
> Message-ID:
> 

Re: [GRASS-user] Question to the input seed grid of i.segment

[Raphael Knevels]

Thanks for the quick response :-)

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:mlenn...@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 
 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


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

Re: [GRASS-user] Question to the input seed grid of i.segment

[Moritz Lennert]

Le 24 janvier 2017 18:42:22 GMT+01:00, Raphael Knevels 
 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

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

[GRASS-user] Question to the input seed grid of i.segment

[Raphael Knevels]

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

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

Re: [GRASS-user] Archiving GPM 3hr rainrate in GRASS

[Laurent C.]

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 :
> 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  from
>  (be
> patient)...
> ERROR: Extension  not found
>
> Is it intended to install with g.extension?
>
> thanks much!
> Vero
>
> 2017-01-21 1:04 GMT+01:00 Laurent C. :
>>
>> 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. :
>> > 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-S00-E002959..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 :
>> >>
>> >> Thanks Markus.  Already registered and can access ftp.  Unfortunately,
>> >> processed (L3) rainfall data will be released by Dec 2014.
>> >> Will just wait then. :)
>> >>
>> >> On Thu, Nov 6, 2014 at 4:27 PM, Markus Neteler 
>> >> wrote:
>>