. Markus Metz, Markus is really enough :-)
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Markus Neteler wrote:
I have made more tests today with LRS
http://www.grassbook.org/examples3rd_chapter6.php
and the results are identical to the pre-fix times.
So also the v.lrs.* which I suppose to use the dblib are
ok. And pretty fast now!
AFAICT, the v.lrs.* modules don't use any of the
Andrew Lewin wrote:
Hi Everyone,
I am a new GRASS user. Every time I import a shapefile using v.in.ogr
the program shuts downs.
Can anyone tell me why?
Can you post the command you used and all messages produced by v.in.ogr?
The messages are important to figure out where v.in.ogr stopped,
Darren Cope wrote:
Hi all,
I'm using v.net.iso on a very large dataset (National Road Network for
Ontario, Canada - 497879 lines) to determine drive-time 'rings.' I'm
experiencing extremely long calculation times. Since it's a very
large dataset, I'm not entirely surprised. However, my
achim wrote:
DB-Driver's eating my nerves.
Im running grass6.4 on 64bit opensuse11.1
Has anybody had and maybe fixed a problem concerning database
driver-errors? I can hardly go on working with errors like this:
Removing vector a...@achim
DBMI-SQLite driver error:
Unable to open database:
I have updated the vectorintro (vector/vectorintro.html) in grass64,
grass65 and grass7. Attribute management has been changed to Vector
object categories and attribute management.
Please check for and report any errors/inconsistencies or if the changed
description is incomprehensible.
Moritz Lennert wrote:
On 10/03/09 12:57, Markus Metz wrote:
I have updated the vectorintro (vector/vectorintro.html) in grass64,
grass65 and grass7. Attribute management has been changed to
Vector object categories and attribute management.
Please check for and report any errors
Michael Barton wrote:
On Mar 9, 2009, at 9:00 AM, grass-user-requ...@lists.osgeo.org wrote:
On 09/03/09 00:00, Benjamin Ducke wrote:
Dear all,
I keep getting into situations where mapping 1:n and m:n relationships
in relational DBMS to GIS vector models becomes a problem.
The toughest
Moritz Lennert wrote:
On 05/03/09 23:15, i...@the-masterplan.net wrote:
Hi!
I am still working on the extended problem and so far i have done the
following.
I created circles and sectors in autocad and imported the dxf file
(first
one sector at a time).
The import didn't seem to work that
Janet Choate wrote:
Hello grass user community,
I am trying to import an e00 file into grass6.2.2. In older versions
of grass, I was able to use m.in.e00, which is no longer
available with grass6 versions. I see that I should be able to use
v.in.e00 with grass6.2.2. However, I get the
achim wrote:
Hello,
I cannot find a solution for extracting those areas that are crossed by
a line. And further to find out, what areas are crossed by a network of
lines in order to union them into one area.
Its for combining subbasins which are part of a certain rivernetwork.
What about
achim wrote:
I attach an example-jpg to illustrate my point of view...
OK, I think I understand.
You could get the start points with r.mapcalc
r.mapcalc start_points = if(!isnull(stream_segments) drainage 0,
1, null())
convert the start points to vector
r.to.vect in=start_points
achim wrote:
Hi all,
I used r.watershed on a small test-region an all I produce
for accumulation and flow-direction was -1 on the whole area
except on the border-cells. Whats wrong?
Curiously is that the first time I tried on my equal-area projection
everything seemed normal. Before on ll it
achim wrote:
That helped!
Thank you very much.
I thought that in depression-input zero means depressions (like in
r.terraflow, which does not produce that good results).
From the help page: Any non-zero values indicate depressions.
Thanks,
achim
Btw: I suggest oceans as real sinks.
FAROUX STEPHANIE wrote:
Markus Neteler wrote:
On Mon, Feb 23, 2009 at 12:15 PM, FAROUX STEPHANIE
stephanie.far...@meteo.fr wrote:
Hello
I try to export a raster integer map whose values range from - to
5880712. How can i specify that i want integer 4 bytes and not
integer 2
bytes (it
Hamish wrote:
Jose Gómez-Dans wrote:
My take on this is to rasterize my vector data with gdal_rasterize (you
can have a look at the rasterisation code and see how it works, in case
you need to eg buffer your vector data), load it up in python, load my
dataset in python, and calculate
Hamish wrote:
Markus Metz:
r.univar2.zonal does zonal statistics
pssst- svn copy not svn add. It works between -addons and trunk.
Removed from addons again, I'll try again the proper svn way. Also have
to sort out a random segfault first.
Markus M
Hamish wrote:
Markus Metz:
r.univar2.zonal does zonal statistics
pssst- svn copy not svn add. It works between -addons and trunk.
Done, hopefully now the right way. Segfault fixed, only 2D zoning, no 3D
zoning. Zone number and category label if present are printed before
Christian Schwartze wrote:
Dear GRASS users,
with r.watershed I get strange basin boundaries for some areas und I'm not able
to give account of it. Attached you can find that part of the basin map which
looks curiously. I means the sharp-edged regions...
Whats the reason?
This is most
This is actually a reply to v.clean process killed itself!? from Nikos [1]
The CLC2000 is also available as a raster, have you tried this alternative?
There are two raster versions, one with 100m resolution and one with
250m resolution.
I got the 100m resolution raster [2], it's the full
Christoff wrote:
Hi everybody,
Is there a way to extract a channels from the accumulation raster, e.g.
accumulation from r.watershed?
You can either set the threshold option in r.watershed and get stream
segments or use flow accumulation output and do something like r.mapcalc
channels =
My first reply was maybe a bit short and rude, let me try again.
Both r.watershed and r.terraflow produce various output maps and it is
not exactly clear to me what output you are interested in.
If you want flow accumulation, the threshold doesn't have an effect on
it. Flow accumulation is
margherita wrote:
Hi all
i have some question about the commands r.watershed and r.terraflow.
By using both commands i obtained from a DEM a flow accumulation with
the algorithm of the single flow direction and a flow accumulation
with the algorithm of the multi flow direction. In both
Georg Kaspar wrote:
ok, so I only need to specify depressions that do not loose water!?
Artificial depressions like postholes or pits for example!?
Rather something with a few hectares in size (at least), e.g. water
reservoirs where water is pumped out, no overground outflow. Postholes
and
Georg Kaspar wrote:
If these lakes have an outflow, i.e. water is leaving these lakes, the
results will be more realistic when you omit the depression input to
r.watershed and only use the (not filled) DEM.
If you are talking about the basins output having NULL values around
these depression,
Georg Kaspar wrote:
Hi,
when providing a binary depression layer for r.watershed, areas around
those depressions will be left out in the resulting basin map.
Maybe your basin threshold was too high, try with a lower value. Basins
are only calculated if there is a stream exceeding the
Georg Kaspar wrote:
On Thu, 29 Jan 2009 10:20:36 -0500, M S wrote:
In short, r.watershed, without depression input, will route water in
and *up* and out of depressions in the terrain to illustrate the
complete downward path. This is why no DEM filling is necessary. By
entering in known
Hamish wrote:
I notice that the newlines in the source code are all messed up.
After fixing, use svn propset svn:eol-style native main.c etc.
see http://trac.osgeo.org/grass/wiki/HowToSVN#Fileproperties
use 'svn proplist file.ext' for similar existing modules for hints.
Oops. I sort of
Hi list,
there is a new module in GRASS-AddOns to import GSHHS shorelines (Global
Self-consistent, Hierarchical, High-resolution Shoreline Database) named
v.in.gshhs. Actually this module is not new, it is resurrected and now
works with grass 6.4.
svn co
Stefan Mietke wrote:
run r.out.gdal -c
the -c flag supresses exporting of these long colortables, they cause
problems..
-c is not a valid flag ...
The -c flag for r.out.gdal is new in version 6.4. I don't know what
version you use, probably 6.3, there -c is indeed not a valid flag for
Stefan Mietke wrote:
[...]
Of course I have version 6.3!
6.4 is not stable yet, isn't it?
On the download page [1] it says that GRASS 6.3 is a testing version and
GRASS 6.4 is the next stable version. GRASS 6.4 is available as release
candidate 2, with binaries for Mac and Linux. If
Hamish wrote:
Bob Moskovitz wrote:
I followed your suggestion, but I'm still getting the
same problem. It seems strange that v.to.rast would create
a vector file that has flawed topology. Do you know of any
alternative to v.clean with rmarea?
v.db.addcol area
v.to.db option=area
Hi all,
some time ago I posted a new version of r.watershed with substantial
speed increase, but still with slight differences in the outputs
compared to the original version. This problem is solved, whether or not
these differences in flow direction and flow accumulation were critical.
Now the
Nikos Alexandris wrote:
r.info composite_b123 -tr
min=0
max=32767
datatype=CELL
[Raster MASK present]
1st attempt to export:
r.out.gdal in=composite_b123
out=/home/nik/grassdb/peloponnese/data/exports/composite_b123.tif
Exporting to GDAL data type: UInt16
Segmentation fault
Hi Peter,
as an interim solution you might try an alternative to v.generalize that
I called v.simplify, available here:
http://markus.metz.giswork.googlepages.com/line_simplification.tar.gz
The module works for me so far, but I still discover strange behaviour
now and then. I developed that
All I wanted to say is that for best allround compatibility, the GEOTiff
output should be kept as simple as possible. If a raster export is meant
to be used in a particular known application, the native raster file
format of this application if existing might be preferable.
The gdal defaults
Nikos Alexandris wrote:
I think I solved my problem by removing color tables
That doesn't solve the problem, I learned. If you remove the associated
colour table, r.out.gdal writes a completely black colour table.
Applications that read the colour table will consequently show a
completely
Nikos Alexandris wrote:
Markus,
I appreciate it that you clarify the details.
It seems I try but fail. Something is still wrong...
If you remove the associated
colour table, r.out.gdal writes a completely black colour table.
Applications that read the colour table will consequently
Nikos Alexandris wrote:
1. Using r.composite and exporting with r.out.gdal gives white as
nodata. Whenever I set nodata=0 I don't get a viewable photo
Weird, it might have something to do with exporting a composite, it
should work on single bands and groups.
3. GeoTiff metadata are lost
Nikos Alexandris wrote:
3. GeoTiff metadata are lost always (?) while exporting with
r.out.gdal.
Also when checking with gdalinfo?
No, I was talking about a known error [1]. How important is this error?
Oh, it is the colour table! That caused me headache too. Some viewers
Forgot to cc...
Sorry for the sloppy looking up, here is the solution for INTERLEAVE=PIXEL.
It is only supported for mulitband images, exporting or translating a
single band will always give INTERLEAVE=BAND. A look at the gdal source
code told me that this is apparently a gdal feature, not a
I think exporting colour tables is one big problem [also see 3, 4]:
GeoTIFFs exported from GRASS suddenly became readable after deleting the
colour table before exporting (my own fiddling around). IMHO, there
should be an option to export colour tables with default to no. There
should also be
Hello list,
there is now a new version of r.watershed.fast where results are even
more similar to r.watershed. They are still not 100% identical to
r.watershed, but I can't get it more similar. But it comes with a
further speed increase. I repeated the test of Moritz with the same
commands
Yes, there are some differences. Please look at where these differences
are located and if they are significantly changing the results. In flat
areas, there will be several possibilities about how water could flow.
This might also affect the flowpath further upstream. Both the original
version
Dear Chuck,
r.watershed is a much valued tool in GRASS, for me the best watershed
analsis tool not only in GRASS, therefore I thought about a a way to
keep the results identical too. I am also aware that the closer the
results produced by changes in the algorithm are to the results produced
Hello list,
I'm not sure if this list is the right place or rather the developer list.
For the A * Search algorithm in r.watershed (memory version without -m
flag set, r.watershed.ram), I implemented a binary min-heap instead of a
linear array to store points in ascending order relative to
1301 - 1346 of 1346 matches
Mail list logo
