[GRASS-user] RV: r.in.lidar problem GRASS GIS 7.0.3

[Vicent García]

-Mensaje original-
De: Vicent García [mailto:vicent_mont...@hotmail.com] 
Enviado el: dimecres, 10 de febrer de 2016 10:32
Para: 'Martin Landa' 
Asunto: RE: [GRASS-user] r.in.lidar problem GRASS GIS 7.0.3

Good job! r.in.lidar works perfectly in daily build no. 67.
Thanks for your attention

Vicent.

-Mensaje original-
De: Martin Landa [mailto:landa.mar...@gmail.com] Enviado el: dimarts, 9 de 
febrer de 2016 19:43
Para: Vicent García 
CC: GRASS users list 
Asunto: Re: [GRASS-user] r.in.lidar problem GRASS GIS 7.0.3

Hi,

2016-02-09 19:19 GMT+01:00 Vicent García :
> I’m having a problem with the module “r.in.lidar” in Grass GIS 7.0.3 
> for Windows 10: I can’t execute it. Everytime when I try to do it, the 
> same message is displayed on the screen manager “can't open file 'r.in.lidar':

launching r.in.lidar from terminal says that liblas_c.dll is not available. I 
checked it on build server and it's right (I guess that you are using 64bit 
installation, 32bit has liblas installed). I have updated build environment, 
could you check next daily build [1] (so build no. >= 66)? Please let us know 
if it works for you. Then I will re-package 7.0.3 to include liblas also for 
64bit installator. Martin

[1] https://wingrass.fsv.cvut.cz/grass70/x86_64/

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] PostgreSQL raster and vector import

[patrick s.]

Thanks for the confirmation, Stefan.

How can r.external be used for PostGIS than- if this concerns all 
PG-Rasters?


Concerning the workflow: good hint to use VRT and also to have WCT. Will 
need to check that.


My reason to use PG is to have a datastorage which can be connected to 
multiple software, without having to run these from within GRASS (R, 
QGIS, ArcGIS, own PostgreSQL functions, bash-scripts,). 
Unfortunately GRASS-format is not supported by all software and PG has 
multiple additional features of interest (User control, Indexing, 
Stability, Comments,  Schemas, Views,.). Last not least I have some 
WebGIS-applications that make use of PG-views and allow a visualisation 
of different contents through simply changing the content of a view, 
i.e. the link to data.


Currently I load from db to GRASS, run all processes inside GRASS which 
depend on the GRASS-functions and save my data to db at the end. Works 
ok for vectors, even if I need transform them to topology for each 
process (v.external does not support of all functions to my knowledge 
and was very slow in the past). However my rasterdata needs to be stored 
in local folders and loaded from there which works fine, but appears to 
be a bit inconsistent with the rest of the workflow. So I thought it 
might be time to make use of the new PostGIS-RASTERS.


Happy on any comment. And sorry of this description is a bit confused.

Patrick



On 09.02.2016 21:10, Blumentrath, Stefan wrote:

Hi Patrick,

Now I tested your approach and I can confirm your issue. It is likely a GRASS 
issue, I guess, as:
gdalinfo "PG:dbname=psql_local schema=myschema table=reference_map"
returns reasonable results.

You are probably hit by this: https://trac.osgeo.org/grass/ticket/798 as a PG 
raster consists of (many) subdatasets, which you can see in gdalinfo output...

You could try:
gdalbuildvrt ./reference_map.vrt "PG:dbname=psql_local schema=myschema 
table=reference_map"
r.in.gdal input=./reference_map.vrt output=region_ref -o --o
as GDAL VRTs are only "meta"-datasets and usually produced very fast.

However, if I were you, I would really reconsider my storage / workflow 
approach, as having the data in PG most likely does not yield in satisfying 
performance. Building a VRT from a reasonable sized raster dataset in PG takes 
ages, while it is built within a few seconds from a GeoTIFF or GRASS dataset.
Having it the other way around, linking a GRASS raster to PG (out-db storage) 
might be more appropriate. That would require building GDAL with GRASS support 
and PG against that GDAL version, so the driver becomes available for PG...

Or if you have to make the raster available over the internet, consider WCS...

Anyway, I hope you manage to achieve what you want!

Cheers
Stefan




-Original Message-
From: grass-user [mailto:grass-user-boun...@lists.osgeo.org] On Behalf Of 
patrick s.
Sent: 4. februar 2016 10:45
To: GRASS user list 
Subject: Re: [GRASS-user] PostgreSQL raster and vector import

Dear list

In addition to my mail yesterday (see below):

The use of PostGIS might be related to the conversation from octobre last year 
(http://osgeo-org.1560.x6.nabble.com/External-raster-from-PostGIS-td5231932.html),
but it remains unclear to me how to import raster and is not referred to in the 
manual.

My current state seems close to the solution:
r.in.gdal in="PG:dbname=psql_local schema=myschema table=reference_map"
out=region_ref -o --o #load into grass
r.external source="PG:dbname=psql_local schema=myschema table=reference_map" 
out=region_ref --o -o  #link to grass

But both lead to "ERROR: North must be larger than South"

However, I can view the data in QGIS (loading though db-manager) and it appears 
to be ok.

Is Error it a problem of gdal, my data or the grass-modules? And how can I 
solve it?

Thanks for any help
Patrick



On 03.02.2016 15:48, patrick s. wrote:

Dear list

I need some help on importing PostGIS raster with r.in.gdal and schema
support under v.in.ogr.


RASTER:
"r.in.gdal -f" shows support: "PostGISRaster (rw): PostGIS Raster driver"
But I did not find any example on how to formulate the dsn/input.


VECTOR:
Unfortunately there is no hint in the manual of grass70 on how to work
with schemas (there was one in 64).
I had a script in grass64 of following syntax, which is still working:

ISCHEMA=baselayer
v.in.ogr dsn="PG:dbname=psql_local active_schema=my_dataschema"
layer=gws_buildings --overwrite

However, I would like to form this more general as a variable for all
incoming data, which is not working:

INPATH="PG:dbname=psql_local active_schema=my_dataschema"
v.in.ogr in=$INPATH out=bldg_pt layer=gws_buildings --overwrite
=>ERROR: v.in.ogr: Sorry,  is not a valid parameter

Also the approach described in the manual of grass64 does not work any
longer

db.connect driver=pg database=psql_local schema=my_dataschema v.in.ogr
in=./ out=bldg_pt layer=gws_buildings --overwrite
=>ERROR: Unable to open data source <./>


Tha

Re: [GRASS-user] r.in.lidar problem GRASS GIS 7.0.3

[Martin Landa]

Hi,

2016-02-10 10:31 GMT+01:00 Vicent García :
> Good job! r.in.lidar works perfectly in daily build no. 67.
> Thanks for your attention

please try new installer for 7.0.3 [1]. Feedback very welcome. Thanks, Martin

[1] 
https://grass.osgeo.org/grass70/binary/mswindows/native/x86_64/WinGRASS-7.0.3-2-Setup-x86_64.exe

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Fwd: International Summer Academy on Spatial Ecotoxicology 12-25.09.2016

[Ralf Schäfer]

FYI
An international Summer Academy that uses R and GRASS GIS in the different 
modules!
The interesting bit: The course is fully funded by the DAAD, which means that 
people from developing countries can participate for free/all costs of travel, 
accomodation and course fees will be covered

Best regards
Ralf


> International Summer Academy on Spatial Ecotoxicology and Ecotoxicological 
> Risk Assessment, 
> 12 - 25 September 2016
> 
> Dear all,
> 
> we will host the „International Summer Academy on Spatial Ecotoxicology and 
> Ecotoxicological Risk Assessment  - 
> Using an Open Community Approach“ from 12.-25. September 2016 at University 
> Koblenz-Landau, Campus Landau, Germany. 
> 
> Further details and registration are available on our website: 
> www.summeracademy-landau.de 
> 
> Developing countries are particularly affected with high contamination, but 
> often have inadequate control mechanisms and insufficient resources for risk 
> assessment. Spatial analysis offers more and more applications and potential 
> within ecological risk assessment. Our ‘International Summer Academy on 
> Spatial Ecotoxicology and Ecotoxicological Risk Assessment’ gives an overview 
> of ecotoxicological risk assessment with a focus on the use of freely 
> available methods and resources for remote sensing and spatial analysis using 
> GIS.  The course provides young scientists with inexpensive tools that are 
> oriented for use in both developing and developed countries.
> Topics: 
> - Problem formulation
> - Hazard assessment of chemical stressors
> - Characterization of effects on One Health
> - Pesticide pollution and vulnerability concepts
> - Earth-to-space-based observing systems for environmental risk assessment 
> and disaster management
> - Use of Open Source spatial analysis tool
> - Open community approach in One Health risk mapping
> - Creation of global pesticide application maps
> - Risk assessment and data availability in developing countries
> The Summer Academy is funded by the DAAD (German Academic Exchange Service) 
> with financial support from the Federal Foreign Office. 
> 
> We are looking forward to welcome you in Landau!
> 
> Best regards, 
> the Organizing Team 
> 
> 
> 
> University Koblenz-Landau
> Institute for Environmental Sciences
> Fortstrasse 7
> D-76829 Landau / Germany
> sommerakade...@uni-landau.de 
> www.summeracademy-landau.de 
> 
> 
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user