[GRASS-user] Saving Linestring layer to SQLite
Pedro Camargo
veigacamargo at gmail.com
Tue Jan 24 17:37:02 PST 2017
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 at lists.osgeo.org> wrote:
> Send grass-user mailing list submissions to
> grass-user at 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 at lists.osgeo.org
>
> You can reach the person managing the list at
> grass-user-owner at 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 at gmail.com>
> To: Veronica Andreo <veroandreo at gmail.com>
> Cc: grass list <grass-user at lists.osgeo.org>
> Subject: Re: [GRASS-user] Archiving GPM 3hr rainrate in GRASS
> Message-ID:
> <CABmXgEH7Wd==FbfB9fEDfD3Ud+LUSXzj1Rfhk7JpmY-aJVs1yg at 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 at 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 at 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 at 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 at 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. :)
> >> >>
> >> >> On Thu, Nov 6, 2014 at 4:27 PM, Markus Neteler <neteler at osgeo.org>
> >> >> wrote:
> >> >> > On Mon, Nov 3, 2014 at 10:18 AM, maning sambale
> >> >> > <emmanuel.sambale at 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 at lists.osgeo.org
> >> >> http://lists.osgeo.org/mailman/listinfo/grass-user
> >> >
> >> >
> >> _______________________________________________
> >> grass-user mailing list
> >> grass-user at 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 at uni-jena.de>
> To: <grass-user at 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 at club.worldonline.be>
> To: grass-user at lists.osgeo.org,Raphael Knevels
> <raphael.knevels at uni-jena.de>
> Subject: Re: [GRASS-user] Question to the input seed grid of i.segment
> Message-ID: <5E0E6C7A-402B-4F07-9C4F-B5C612C7D4E0 at club.worldonline.be>
> Content-Type: text/plain; charset=utf-8
>
>
>
> Le 24 janvier 2017 18:42:22 GMT+01:00, Raphael Knevels <
> raphael.knevels at 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 at uni-jena.de>
> To: "'Moritz Lennert'" <mlennert at club.worldonline.be>,
> <grass-user at 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 :-)
>
> 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 at club.worldonline.be]
> Gesendet: Dienstag, 24. Januar 2017 19:11
> An: grass-user at 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 at 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 at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
>
> ------------------------------
>
> End of grass-user Digest, Vol 129, Issue 35
> *******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20170125/5840fc98/attachment-0001.html>
More information about the grass-user
mailing list