Re: [GRASS-user] sample a strds at specific locations (areas)

[Stefan Blumentrath]

Ciao Vero,

Currently, areas, lines and points are rasterized by default.
Centroids would come in addition.

That means, small polygons that only cover parts of a pixel would get 
rasterized never the less. This can of course be useful in some cases but cause 
issues in others. However, given that GRASS centroids are located inside areas 
it should be mostly OK.

Cheers
Stefan

From: Veronica Andreo 
Sent: mandag 12. august 2019 16:24
To: Stefan Blumentrath 
Cc: Margherita Di Leo ; grass-user 

Subject: Re: [GRASS-user] sample a strds at specific locations (areas)

Ciao Madi,

is the region properly set?

@Stefan in this case, if the centroid only is rasterized, then stats will also 
belong to that pixel only? AFAIU, we don't want that, but stats for the area. 
Or rasterization of centroid would have a different effect?

best,
Vero

El vie., 9 ago. 2019 a las 21:29, Stefan Blumentrath 
(mailto:stefan.blumentr...@nina.no>>) escribió:
Ciao Margherita,

This is strange. The area (I assume it is an area though your image just shows 
the boundary) should definitely get rasterized and thus analysed in 
v.strds.stats.

Can you post the output of:
v.category input=big_areas2@PERMANENT option=report
and
v.info test -t ?

I double-checked, and the possibility to rasterize also centroids is 
unfortunately not handed down to v.rast.stats (and moduls build ontop of that, 
like v.strds.stats). This should be done for GRASS version >= 7.6 (e.g. by 
adding centroids to the default selection of types to rasterize in v.to.rast) 
and is probably worth a ticket.

Cheers
Stefan

From: Margherita Di Leo mailto:direg...@gmail.com>>
Sent: fredag 9. august 2019 16:51
To: Veronica Andreo mailto:veroand...@gmail.com>>
Cc: Stefan Blumentrath 
mailto:stefan.blumentr...@nina.no>>; grass-user 
mailto:grass-user@lists.osgeo.org>>
Subject: Re: [GRASS-user] sample a strds at specific locations (areas)

Hi,

excuse me if I return on this. I have again the same problem, of v.strds.stats 
skipping lots of polygons. Now I'm using a brand new dataset - strds of 
Sentinel 1 and a brand now vector of polygons - and the skipped polygons are 
not narrow, I'm sure that there are cells centroids in it. See for example 
screenshot attached, depicting a polygon that was skipped. I also tried to run 
v.strds.stats on that polygon alone, like:

v.strds.stats in=big_areas2@PERMANENT where="cat == '1'"  
strds=db_cross_pol@scaled out=test method=average

v.info test
 ++
 | Name:test  |
 | Mapset:  stats |
 | Location:S1|
 | Database:/media/madi/TOSHIBA EXT/S1/grassdata  |
 | Title:   Output from v.patch   |
 | Map scale:   1:1   |
 | Name of creator: madi  |
 | Organization:  |
 | Source date: Fri Aug  9 12:12:49 2019  |
 | Timestamp (first layer): none  |
 ||
 | Map format:  native|
 ||
 |   Type of map: vector (level: 2)   |
 ||
 |   Number of points:   0   Number of centroids:  0  |
 |   Number of lines:0   Number of boundaries: 0  |
 |   Number of areas:0   Number of islands:0  |
 ||
 |   Map is 3D:  No   |
 |   Number of dblinks:  0|
 ||
 |   Projection: UTM (zone 34)|
 ||
 |   N: 0S: 0 |
 |   E: 0W: 0 |
 ||
 |   Digitization threshold: 0|
 |   Comment: |
 ||
 

Re: [GRASS-user] t.rast.gapfill error

[Veronica Andreo]

Hi Juan,

Can you provide further details about your strds and how you want to use
t.rast.gapfill? What does t.info and t.rast.list show? Please note that
t.rast.gapfill is not intended to fill holes in maps but interpolate full
missing maps in between x other maps, that's why it needs to determine
predecessor and sucessors. Take a look at the manaul page:
https://grass.osgeo.org/grass76/manuals/t.rast.gapfill.html

HTH,
Vero



El mié., 7 ago. 2019 a las 0:51, JUAN SEBASTIAN VINASCO SALINAS (<
vinasco.j...@correounivalle.edu.co>) escribió:

>
> Hello everyone,
>
> I have a trouble with the t.rast.gapfill module when i applied to a strds
> i have recieve the next message "Unable to determinate successor and
> predecessor of a gap". Any idea because this?
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] sample a strds at specific locations (areas)

[Veronica Andreo]

Ciao Madi,

is the region properly set?

@Stefan in this case, if the centroid only is rasterized, then stats will
also belong to that pixel only? AFAIU, we don't want that, but stats for
the area. Or rasterization of centroid would have a different effect?

best,
Vero

El vie., 9 ago. 2019 a las 21:29, Stefan Blumentrath (<
stefan.blumentr...@nina.no>) escribió:

> Ciao Margherita,
>
>
>
> This is strange. The area (I assume it is an area though your image just
> shows the boundary) should definitely get rasterized and thus analysed in
> v.strds.stats.
>
>
>
> Can you post the output of:
>
> v.category input=big_areas2@PERMANENT option=report
>
> and
>
> v.info test -t ?
>
>
>
> I double-checked, and the possibility to rasterize also centroids is
> unfortunately not handed down to v.rast.stats (and moduls build ontop of
> that, like v.strds.stats). This should be done for GRASS version >= 7.6
> (e.g. by adding centroids to the default selection of types to rasterize in
> v.to.rast) and is probably worth a ticket.
>
>
>
> Cheers
>
> Stefan
>
>
>
> *From:* Margherita Di Leo 
> *Sent:* fredag 9. august 2019 16:51
> *To:* Veronica Andreo 
> *Cc:* Stefan Blumentrath ; grass-user <
> grass-user@lists.osgeo.org>
> *Subject:* Re: [GRASS-user] sample a strds at specific locations (areas)
>
>
>
> Hi,
>
>
>
> excuse me if I return on this. I have again the same problem, of v.strds.stats
> skipping lots of polygons. Now I'm using a brand new dataset - strds of
> Sentinel 1 and a brand now vector of polygons - and the skipped polygons
> are not narrow, I'm sure that there are cells centroids in it. See for
> example screenshot attached, depicting a polygon that was skipped. I also
> tried to run v.strds.stats on that polygon alone, like:
>
>
>
> v.strds.stats in=big_areas2@PERMANENT where="cat == '1'"
> strds=db_cross_pol@scaled out=test method=average
>
>
>
> v.info test
>
>  
> ++
>  | Name:test
>|
>  | Mapset:  stats
> |
>  | Location:S1
>|
>  | Database:/media/madi/TOSHIBA EXT/S1/grassdata
>|
>  | Title:   Output from v.patch
> |
>  | Map scale:   1:1
> |
>  | Name of creator: madi
>|
>  | Organization:
>|
>  | Source date: Fri Aug  9 12:12:49 2019
>|
>  | Timestamp (first layer): none
>|
>
>  
> ||
>  | Map format:  native
>|
>
>  
> ||
>  |   Type of map: vector (level: 2)
> |
>  |
>|
>  |   Number of points:   0   Number of centroids:  0
>|
>  |   Number of lines:0   Number of boundaries: 0
>|
>  |   Number of areas:0   Number of islands:0
>|
>  |
>|
>  |   Map is 3D:  No
> |
>  |   Number of dblinks:  0
>|
>  |
>|
>  |   Projection: UTM (zone 34)
>|
>  |
>|
>  |   N: 0S: 0
> |
>  |   E: 0W: 0
> |
>  |
>|
>  |   Digitization threshold: 0
>|
>  |   Comment:
> |
>  |
>|
>
>  
> ++
>
> I confess I hadn't look much further into it because I thought it was a
> problem with nodata, but this is not the case and I think it's  worth of
> further investigation. Thanks for any pointers.
>
>
>
> Regards,
>
>
>
>
>
> On Thu, Feb 7, 2019 at 4:10 PM Margherita Di Leo 
> wrote:
>
> Thanks for testing, Vero. I assume it's due to a local problem then.
>
>
>
> Cheers,
>
>
>
> On Thu, Feb 7, 2019 at 3:29 PM Veronica Andreo 
> wrote:
>
> Hi Stefan and Madi,
>
>
>
> Thanks Stefan for the explanations :) Indeed I agree that a flag to avoid
> the alignment to input rasters (and just use region settings) sounds good.
>
> I tested what Madi said, but cannot reproduce in the climate NC location
> [0]. This is the command I used:
>
>
>
> v.strds.stats in=boundary_county where="cat == '261'" strds=tempmean
> t_where="start_time >= '2012-01-01'" out=test
>
>
>
> to make it faster (it feels indeed kinda slow for the whole vector and
> full time series), I selected only one polygon and a range of dates. I get
> the table as expected while leaving methods by default.
>
>
>
> best,
>
> Vero
>
>
>
> [0]
> http://courses.ncsu.edu/mea592/common/media/02/nc_climate_spm_2000_2012.zip
>
>
>
>
>
>
>
>
>
> El jue., 7 feb. 2019 a las 14:39, Margherita Di Leo ()
> escribió:
>
> Thank you Stefan for your help! I figured what happens. v.strds.stats with
> default method produces in my case a corrupted output, topology is there
> but there's no table associated to it. If I specify method=average, I do
> obtain the table, and the mystery is solved: some of the polygons fall into
> a nodata (due to cloud mask). If anyone else 

Re: [GRASS-user] Wrangling CityGML with GRASS ?

[Peter Löwe]

Hi Markus,
 

I am not sure whether GMLAS is currently supported:

ogr2ogr -f GeoJSON SMALL.json GMLAS:SMALL.gml -oo REMOVE_UNUSED_LAYERS=YES -oo REMOVE_UNUSED_FIELDS=YES -sql "SELECT * FROM groundsurface"

throws 

"FAILURE:
Unable to open datasource `GMLAS:SMALL.gml' with the following drivers.
  -> `OGR_GRASS'
  -> `PCIDSK'
  -> `PDF'

 [...]
"

-> with no mentioning of GMLAS as a driver option.

 

Best,

Peter

 






You need to rebuild GDAL accordingly, but

 

> override for the import-driver:
>  
> ogr2ogr -f GeoJSON SMALL.json GMLAS:SMALL.gml -oo REMOVE_UNUSED_LAYERS=YES -oo REMOVE_UNUSED_FIELDS=YES -sql "SELECT * FROM groundsurface"

 

apparently GMLAS is supported. What is the exact error message for " GDAL2.3.1 in GRASS refuses to accept the "GMLAS:""?

 

Markus M





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