, Aug 10, 2017 at 11:55 AM, patrick s. <patrick_...@gmx.net> wrote:
Dear all
Can s.o. help me to remove "broken" vector-files which have no table
connected ?
g.remove type=vect name=mytable -f => ERROR: Unable to read header file of
vector map
Tables have been deleted
Dear all
Can s.o. help me to remove "broken" vector-files which have no table
connected ?
g.remove type=vect name=mytable -f => ERROR: Unable to read header file
of vector map
Tables have been deleted beforehand to allow '--overwrite' in PostgreSQL.
Thanks for any hint
patrick schirmer
32, Moritz Lennert wrote:
On 09/08/17 16:13, patrick s. wrote:
Dear all
A short not on the manual v.in.ogr. It appears to be out of date for
PostGIS import. I have to call the schema in "layer" to have
schema-support. My previous code as given below was been running
without this.
Dear all
A short not on the manual v.in.ogr. It appears to be out of date for
PostGIS import. I have to call the schema in "layer" to have
schema-support. My previous code as given below was been running without
this.
Best Regards,
patrick schirmer
#Syntax in the past and still
Running PG connection on grass70 works for me as well.
Wild guess:
1.) Are the maps stored in Schemas? (see $INPATH below)
2.) Have you tested the change/removing of quotations? (see codeexample below)
My (tested) code in BASH:
GSCHEMA=grass_2015
INPATH="PG:dbname=$DB_NAME
Paul, a short comment.
Depending on the information you need to process it might be enough to match
the rasterdata to the centroid of the polyons, which is not having issues of
overlaps with multiple tiles.
Regards,
Patrick
--
Message: 1
Date: Fri, 24 Jun 2016 11:34:47 +0200
From: Paul
with r.null null= it will return for all of these.
Is there a solution to that problem?
Patrick
On 16.03.2016 13:59, Anna Petrášová wrote:
On Wed, Mar 16, 2016 at 6:23 AM, patrick s. <patrick_...@gmx.net
<mailto:patrick_...@gmx.net>> wrote:
Dear list
Is it pos
Thanks, Anna. That helps!
Cheers, Patrick
On 16.03.2016 13:59, Anna Petrášová wrote:
On Wed, Mar 16, 2016 at 6:23 AM, patrick s. <patrick_...@gmx.net
<mailto:patrick_...@gmx.net>> wrote:
Dear list
Is it possible to get the "mode" (most common occurring v
Dear list
Is it possible to get the "mode" (most common occurring value) in a
polygon for discrete classes? It appears that v.rast.stats does not have
this option.
Thanks for a short feedback,
Patrick
___
grass-user mailing list
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 <grass-
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
=bldg_pt layer=gws_buildings --overwrite
#NOTE: "in" needs to be quoted or it will not work
On 04.02.2016 10:44, patrick s. wrote:
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-o
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
Short sidenotes from a basic Ubuntu-User:
1.) It is a great step to have repositories for GRASS and straight
forward to stream these with Ubuntu-GIS.
Thanks Martin! I am sure this will be of benefit for many
GRASS-beginners!
2.) I upgraded Ubuntu from 15.04 (vivid) to 15.10 (wily)
Dylan
A small sidenote on your issue. I also use GNU parallel for operations
that have to run on very large scales. Never had problems with it when
running it on different mapsets, i.e. I create a temporary mapset in my
scripts that are wrapped by the command. Storing the data back to a
-like" mapsets in a collaborative way
3) Archiving of mapsets (expired projects and up- / out-dated entities from
data series)
Cheers
Stefan
-Original Message-----
From: patrick s. [mailto:patrick_...@gmx.net]
Sent: 5. oktober 2015 09:21
To: grass-user@lists.osgeo.org; Blumentra
Hi Stefan
Not sure on your needs, but if not all projects run on GRASS, it might
be an option to run a spatial database as backend to store the data. At
ETH Zürich we have been running PostgreSQL to host our data. Access to
different software is running very well (GRASS, QGIS, R,..) and the
Dear all
I process several rasters in a loop and sum up the results. During the
processing I keep getting multiple warnings. A simplified version of the
code and the warnings are given below. Can somebody please help me to
understand these warnings. Is there a setting to avoid the
to load csv-files into
GRASS, but misses the option to create spatial points out of the
coordinates. Furthermore this might need guidance on the data-type
through a .csvt-file (see manual db.in.ogr).
Patrick
On 11.08.2015 23:13, Markus Neteler wrote:
On Thu, Aug 6, 2015 at 10:04 AM, patrick
n="$i double"
fi
v.what.rast map=pt_grid rast=$i col=$i
done;
##
On 11.08.2015 23:33, Markus Neteler wrote:
On Mon, Aug 10, 2015 at 9:51 AM, patrick s. <patrick_...@gmx.net> wrote:
Dear grass-users
First off all-
Dear grass-users
First off all- sorry for spamming this user-list recently with
questions. I don't know any grass-users that I could ask. So this list
is the only feedback I can get for support and I am happy it works so
well. So my Thanks to all of you, for the recommendations given!
Now
Thanks Anna, for pointing out the error.
+1 for removing the test or change it to WARNING without 'exit'.
In my opinion this is the standard behavior of all raster-commands.
Patrick
On 05.08.2015 18:51, grass-user-requ...@lists.osgeo.org wrote:
Looking at v.neighbors source code [1], the
Dear all
I want to import multiple csv-files with coordinates (points) that come
from Excel/SPSS, having first row as header. These have undefined labels
of columns that need to be available in grass and that might change in
future. Running grass on dbf-backend, I used to create shapefiles in
UPDATE:
The error of v.neighbors does not appear when importing points only for
a region: v.in.ogr -r
So definitely a problem of v.neighbors.
Patrick
On 01.08.2015 23:56, Markus Neteler wrote:
On Wed, Jul 29, 2015 at 4:40 PM, patrick s. patrick_...@gmx.net wrote:
Hi,
I need to run
Markus
Error of migration? The page
http://grass.osgeo.org/documentation/manuals/ has a missing link; Tested
for the manuals of grass70.
(Wrong link: http://grass.osgeo.org/grass70/manuals/index.html)
Cheers,
Patrick
On 03.08.2015 21:00, grass-user-requ...@lists.osgeo.org wrote:
Message:
Thx, Markus.
This explains a lot. Initial setup was GRASS 6- so it kept being dbf.
Also good to know, how much more efficient sqlite is.
Speaking of efficiency:
Is the speed of PostgreSQL as backend comparable to sqlite? I can't
find any benchmarks on db-usage here:
rebuilt the topology. Is it
for that reason that GRASS70 runs/changes to dbf?
Patrick
On 30.07.2015 21:17, Markus Neteler wrote:
On Thu, Jul 30, 2015 at 2:26 PM, patrick s. patrick_...@gmx.net wrote:
Thanks Stefan
It seems first of all v.out.ascii is slow. Following your proposaI, the
tmp-file
south: 1074200
west: 2484400
east: 2834800
nsres: 25
ewres: 25
rows: 8912
cols: 14016
cells: 124910592
On 01.08.2015 23:56, Markus Neteler wrote:
On Wed, Jul 29, 2015 at 4:40 PM, patrick s. patrick_...@gmx.net wrote:
Hi,
I need to run v.neighbors
:
v.out.ascii input=pt output=./tmp column=VAL
r.in.xyz input=./tmp z=4 output=pt method=sum
Cheers
Stefan
*From:*grass-user-boun...@lists.osgeo.org
[mailto:grass-user-boun...@lists.osgeo.org] *On Behalf Of *patrick s.
*Sent:* 30. juli 2015 10:18
*To:* Markus Neteler
*Cc:* GRASS user list
in=pt out=pt_dens -c size=300 meth=sum/. Maybe there is an
approach to directly use the vector data and avoid conversion- something
as /v.neighbors meth=sum/?
Thanks for you help,
Patrick
On 24.07.2015 04:13, Markus Neteler wrote:
On Thu, Jul 23, 2015 at 11:00 AM, patrick s. patrick_
My congretulations and thanks to the whole developer team! I am very impressed
about the progress done in Version 7.0 and happy to have switched.
Patrick
___
grass-user mailing list
grass-user@lists.osgeo.org
Hi,
I need to run v.neighbors on multiple datasets for the identic region
(extend and resolution). One dataset has observations outside of this
region, and causes an error: ERROR: Input vector and computational
region do not overlap. However, viewing the extend in v.info and r.info
(see
Dear all
Trying to learn using GRASS in the ideal way: What would be best
practice to merge multiple point-layers? Currently I can think of the
two versions below. However, both seem to be a workaround.BTW: Does
bounding-box definition in v.edit (x1,y1,x2,y2) mean lower left to
upper right?
;//
/
On 25.07.2015 19:47, Micha Silver wrote:
On 07/25/2015 08:08 PM, patrick s. wrote:
Dear all
Is there a function in GRASS70 to match multiple rasters as values to
a point-vector. Some of the rasters are of type integer, some of type
float and the columns should ideally respect the datatype. It might
that this is not the
behavior? Some users might not go through the examples.
Regards,
Patrick
On 24.07.2015 04:13, Markus Neteler wrote:
On Thu, Jul 23, 2015 at 11:00 AM, patrick s. patrick_...@gmx.net wrote:
Dear all
I am puzzled on the behavior of v.to.rast. When several points fall into one
gridcell, the raster
Dear all
Is there a function in GRASS70 to match multiple rasters as values to a
point-vector. Some of the rasters are of type integer, some of type
float and the columns should ideally respect the datatype. It might be
possible as a bash.loop on v.what.rast, but I do not find a way to query
=pts_dens300 -c size=7 meth=sum --o/
Thanks,
Patrick S.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Thanks, Vaclav.
Will keep geomorphons in mind, but run 64 currently. I have pretty much
the same experience here- almost no peaks. I thought that minor
differences in the elevation might be the reason and rescaled. Also
tested change in size but this did not have effects- rather less than
Does v.category not work when connected to postgresql? I get a corrupt
output for v.category in=elev_contour_area out=elev_contour_area_cat
op=add on GRASS64.
The map is created and can be viewed, but there is no table and trying
to view the attributes crashes GRASS.
Number of nodes: 878
Dear List,
In my test of r.param.scale on GRASS64 peaks are evaluated on basis of
single cells and do not form areas. High plains, i.e. neighboring
peaks with the same value get ignored, while the example picture shows
such areas http://grass.osgeo.org/grass65/manuals/r.param.scale.html
Thanks, Markus.
In that case it would be of advantage to remove this function.
However, before I go for GRASS 7 (which will be harder to host on our
Server): The module v.net.allpairs in GRASS 7.0 demands to keep points
and lines on different layers, which did not work for me when using
On 03/12/2014 10:46 AM, Markus Neteler wrote:
On Wed, Mar 12, 2014 at 10:40 AM, Patrick S. patrick_...@gmx.ch wrote:
...
Anything we can help with to facilitate the installation of GRASS 7?
Note that you can run both GRASS 6 and 7 in parallel.
I am not a poweruser of the servers, so the admin
Dear list,
I hope you can help me to understand the behavior of GRASS for the
following: I need calculate the network-distances for intersections in
this network. What seemed easy, starts to get very tricky
My approach is shown below, but has following problems:
1.) As intersections
Dear all,
Hopefully someone of you can help me:
I need to run a kernel density function as distance weighted function
that uses a given attribute. Locations are given as points and the
weight is given in a column. As far as I see, this is not possible with
v.kernel (Manual: LIMITATIONS The
and give out a warning instead of an
error. In case of same column-names (after truncating), last letter
could be replaced by a number.
However I don't see that this is implemented yet - or did I miss something?
greetz,
Patrick S.
___
grass-user mailing
Made a little shell-script solving this earlier question of mine. Maybe
someone else will need this as well
patrick
###INIT:make copy of file (name short is used as indicator)
g.copy vect=myfile,myfile_short --o
###iterate through all columns, all files and check double column-name
Hello,
Here another view on this issue:
I worked with grass 7 on Ubuntu for several month and was very pleased,
i.e. no problems, except for a few scripts written for grass 6 due to
changes in the commands (mainly flags and display-commands).
However, due to the need of manual compilation
/ubuntugis-testing/+packages
https://launchpad.net/%7Eubuntugis/+archive/ubuntugis-testing/+packages
On Fri, Jan 11, 2013 at 3:33 PM, Patrick S. patrick_...@gmx.ch
mailto:patrick_...@gmx.ch wrote:
Hello,
Here another view on this issue:
I worked with grass 7 on Ubuntu for several month
Thanks Markus,
will check that and report on it. The second issue might be a
data-error. I can not reproduce the mistake with other data. Will report
on this as well, when I know more about it.
Regards,
Patrick
On 11/15/2012 01:39 PM, Markus Neteler wrote:
1.) When starting GRASS I get
Hi,
I observe two errors in my GRASS-GIS 6.4.2 from UbuntuGIS-Repository
with sqlite as database. Does someone know whether these refer to
missing dependancies of UbuntuGIS or are errors of my system and - in
case of the latter - eventually how I can fix this?
1.) When starting GRASS I get
that somewhere without access-rights (to contribute) or would I rather
report this?
Patrick
that On 11/08/2012 07:34 PM, Markus Metz wrote:
On Thu, Nov 8, 2012 at 10:50 AM, Patrick S. patrick_...@gmx.ch wrote:
Dear List,
I keep getting a log(0) error in r.mapcalculator, even if I
Markus,
I understand your arguments, but A is the slope of r.slope.aspect and
has floating point values as input for the formula. I just created a
testcase to be able to report on the behavior in detail. As you can see
below the results are truncated to integer as soon as I add a term to
A
Dear List,
I keep getting a log(0) error in r.mapcalculator, even if I enlarge the
data. This seems to be a bug as I controlled the same data with R and
get (non-infinity) values. Does r.mapcalculator eventually truncate the
results of formulas to some integer values?
logit-expression:
Hi Paulo,
I don't know anything about r.series and it's output, so please forward
any results. But my approach would be to use R through the spgrass6
package. This would be something as the commands below.
Inside grass-session, run:
R
setwd(~/mydata/01_Regressiondata)
memory.limit(2000)
Dear GRASS-Users and Developers,
I am trying to create a point layer of a table I got in R, which
includes coordinates. To avoid the truncated columnnames I would like to
use th cnames-option of v.in.ogr-- something as:
writeVECT6(d.points, parameters=list(vname='v_comparis_data',
A little feedback of current findings for r.shaded.relief in GRASS6.4.2
in case anybody should have the same problem as we just had. We needed
to create comparable results between the hillshade algorithm (ArcGIS)
and the shaded.relief algorithm (GRASS) and compared the output. Values
of shaded
Dear list,
I am still trying to understand the output of shaded.relief to compare
to results of collegues created with other tools.
When getting through the script I found the following calculation
/r.mapcalc EOF//
//$elev_out = eval( \\//
// x=($zmult*$elev[-1,-1] + 2*$zmult*$elev[0,-1] +
Dear List,
I am trying to create a hillshade map with shadowing effect of the
topography. It seems r.sunmask should be my weapon of choice, but it is
incredibly slow. Then I found a mail to the userlist in 2007 where
Markus replies on this
Dear list,
I try to reproduce previous work reported in a paper done with the
hillshade-tool of ArcGIS, and am using GRASS64.
Comparing the hillshade of GRASS6.4, GDAL and ArcGIS showed that the
results vary- at least in terms of the resulting raster-values. While I
assume ArcGIS to create
Dear list,
I try to reproduce previous work reported in a paper done with the
hillshade-tool of ArcGIS, and am using GRASS64.
Comparing the hillshade of GRASS6.4, GDAL and ArcGIS showed that the
results vary- at least in terms of the resulting raster-values. While I
assume ArcGIS to create a
Dear list,
first a feedback to the developers : Seems there has been a change to
v.type?
from_type and to_type is now required, but the example still shows
type=from,to as use case.
2.) using from_type=centroid and to_type=point does not create a point
only layer, but still include
Another workaround. Don't know if that helps and never tried it out, but
my approach for inner offset would be a decomposition of the polygons:
v.type in=poly out=poly_as_line type=boundary,line
v.parallel
v.clean tool=break
v.type type=line,boundary
v.centroids
v.build
If you can not define
Thank you Moritz,
that works perfect!
BTW, I saw that you can also write: $( ..) instead of `...`
The result seems to be equivalent.
patrick
On 03/15/2012 10:03 AM, Moritz Lennert wrote:
v.category in=gr_help1 out=gr_help1_cat option=sum value=`echo 'SELECT
MAX(cat) FROM gr_help1'
Dear list,
sorry for writing several times in such a short time, but every start is
a little hard
When importing from PostGIS, v.in.ogr will remove the column with the
primary key and use the objects as cat. Is there a way to avoid this
behaviour, e.g a flag?
I just copied the table now
I try to import various files from PostgreSQL to GRASS in GRASS70.
/
db.connect driver=pg
database='host=server,dbname=database,schema=schamename'
db.login user=sustaincity pass=+++
db.connect -p
db.tables -p |less
for i in {1..3};
do
v.in.ogr dsn='PG:host=servername dbname=dbname
Just found the problem with PostgreSQL-import:
If the postGIS-layer has multiple geometries (in my case, centroid and
polygon), it will be viewed with db.tables -p, but not imported
through v.in.ogr. Error is misleading as it says Layer not
available. Workaround, was a copy of the layer with
Dear list,
I am trying to merge several douzen vectorlayers in a loop. These are
representing zones of neighboring municipalities, that have been
imported from PostgreSQL and might overlap. Overlapping is not expected
to be of relevant size, so it is more important to keep the number of
Hi Rich,
In case you don't know: .lyr is the layout-fileformat of ArcGIS. It will thus
only contain colorinformation for visualisation of the layers, but no data
and might not be essential for your work.
patrick
Message-ID:
alpine.lnx.2.00.1105091549320.27...@salmo.appl-ecosys.com
, tables, columns, data
types, domain lists, etc.)
2. .itf file (the raw data: geometry and attribute data). - itf means
interlis transfer format
You always need both files.
Here are one or two examples:http://gis.hsr.ch/wiki/HowTo_OGR2OGR
Good luck,
Andreas
On 3/11/11 8:00 PM, Patrick S. wrote
Dear List,
does someone have experience in importing the topological format
INTERLIS to GRASS?
It seems to need an .ili file, that will define polygons, lines and
points, but I don't see how to integrate this one in the v.in.ogr command.
I managed to use ogr2ogr and tested conversion to
70 matches
Mail list logo
