Hello Sibylle,
I have bad news for you – you'll have to change your name (or at least
move GRASS DB to a folder without non-ascii characters in its path).
Thanks to Windows quirks (up to three different encodings for a single
session!), non-ascii chars are a frequent source of problems and there
And that WIKI is wrong. gis.h defines CELL as int thus only thing
guaranteed is that CELL will be able to store values in range from
-32767 to +32767. But by magic of C standard on my system CELL can
store values in range from -2147483647 to +2147483647 (as long as my
compiler uses
E cat = old_cat"
M.
pirmd., 2024. g. 15. janv., plkst. 16:48 — lietotājs Ken Mankoff
() rakstīja:
>
> Hi Maris,
>
> On 2024-01-15 at 02:10 -08, Maris Nartiss wrote...
> > v.edit tool=catadd/catdel is the thing you are looking for. Delete old
> > geometry, delete categor
Hi Ken,
v.edit tool=catadd/catdel is the thing you are looking for. Delete old
geometry, delete category of new geometry (if there is one), set old
cat value to the new geometry.
Good luck,
M.
pirmd., 2024. g. 15. janv., plkst. 04:56 — lietotājs Ken Mankoff via
grass-user () rakstīja:
>
> Hi,
>
If you are executing this command from a shell (e.g. bash), you must
escape or enclose in single quotes the pipe character.
Try:
v.db.update map=mymap column=xkey value='|'
Māris.
pirmd., 2023. g. 4. dec., plkst. 10:51 — lietotājs gisfisch--- via
grass-user () rakstīja:
>
> Hello list,
>
>
>
> I
Check that you also have -dev packages (if they are separate on your
Linux distro). Exact error message will be in the config.log file.
Without it it is hard to tell what went wrong as I have PDAL 2.3.0 and
it compiles fine.
Māris.
piektd., 2023. g. 24. nov., plkst. 17:21 — lietotājs Rich
If there are no changes you want to keep, just git reset --hard HEAD.
Māris.
piektd., 2023. g. 24. nov., plkst. 16:13 — lietotājs Rich Shepard via
grass-user () rakstīja:
>
> I've not used grass in a long time and want to update my source code to the
> current dev status as I've done before.
Hello Philip,
the key message is inability to locate libgdal.so.30. My guess – along
with installing some programs your IT department also upgraded other
software. Just run `locate libgdal.so` in a terminal to get a list of
all GDAL versions installed on your system. If 3.0 is missing, then
you'll
se=z
>
> Il giorno mar, 25/07/2023 alle 08.33 +0300, Maris Nartiss ha scritto:
> > Please provide your input data and computational region settings. I
> > was not able to reproduce the issue with my data.
> >
> > Māris.
> >
> > otrd., 2023. g. 25. jūl., plks
Please provide your input data and computational region settings. I
was not able to reproduce the issue with my data.
Māris.
otrd., 2023. g. 25. jūl., plkst. 07:17 — lietotājs bonushenricus
() rakstīja:
>
> Hello
> the problem isn't in my ASCII file or in v.in.lines
> but a bug in v.to.rast,
There are two options for PDAL – either disable completely (no import
tools for LAS files then) or provide paths for include and lib
directories. See ./configure --help for correct syntax of all
parameters. I have no idea if one can mix conda and native libs in a
single program.
Good luck,
Māris.
I think you need to interpolate and not simply convert vector lines to
raster lines. Make sure lines have an attribute with elevation (or z
coordinate) and use e.g. v.surf.rst module.
Māris.
trešd., 2023. g. 10. maijs, plkst. 17:29 — lietotājs Rich Shepard
() rakstīja:
>
> I need to convert a
On the first row you have specified a line with 5 coordinates and one
category (L 5 1).
You have not provided the last line containing that one category. Just
add „1 1“ (layer 1, cat 1) as a last row and you should be fine.
Māris.
pirmd., 2023. g. 8. maijs, plkst. 23:59 — lietotājs Rich Shepard
Peaking at the file list you provided, you are dealing with already
processed LiDAR data in raster (and shapefile) format. Thus r.in.gdal
is the way to go.
r.in.las (obsolete) and r.in.pdal (the new way to go) deal with raw
point clouds in LAS format. They perform point binning according to
Do you mean `pdal info file.las`?
Māris.
ceturtd., 2023. g. 27. apr., plkst. 01:35 — lietotājs Rich Shepard
() rakstīja:
>
> A long time ago I learned here the commands to summarize the pertinent
> content of LiDAR data files. I can't find it in my mail records. Please
> point me to a source of
Could you check the config.log file for an exact error message?
There was a fix for PDAL as pdal-config enforces C++11 although it
requires C++17:
https://github.com/OSGeo/grass/commit/cb8293e8d40c02857b3a15bac441f703339ba5fd
Māris.
svētd., 2023. g. 12. febr., plkst. 00:39 — lietotājs Rich
Hello Bernardo,
although a solution with r.mapcalc random could be made to work, I'd
say creating a new dedicated module is the way to go. Just an idea –
create neighbour count raster (how many cells with centre class are in
a sliding window), in second pass unroll classes based on their count
and
It worked? Strange, as i.smap requires signature generated by
i.gensigset and should not work with one generated by i.gensig (this
fact is even present in the documentation).
i.maxlik can work with signature file from i.gensig or i.cluster as
both programs generate signature file with same
otrd., 2022. g. 30. aug., plkst. 07:10 — lietotājs Wolf Bergenheim
() rakstīja:
>
> Hi Tom,
>
> 1) To point GRASS to the GISDBASE on the external drive, simply start GRASS
> once with
>
> grass /external_ntfs_mount/some_location/mapset
>
> Meaning that you give as argument the path to a mapset
As r.out.gdal uses GDAL library, it is bound to GDAL limitations.
According to the GDAL PG documentation, PG rasters are read-only:
https://gdal.org/drivers/raster/postgisraster.html#raster-postgisraster
Thus you can read but can not write PG rasters with GDAL.
Māris.
piektd., 2022. g. 26. aug.,
/20331ef5ee9f9b34ae692b42daa9d49006f4e28e
ceturtd., 2022. g. 28. apr., plkst. 20:14 — lietotājs Maris Nartiss
() rakstīja:
>
> Thank you, Frank.
> It is a bug in v.profile. I'll try to take a look into it. In the mean
> time you can track the issue here:
> https://github.com/OSGeo/grass/issues/2344
>
> Sorry f
Thank you, Frank.
It is a bug in v.profile. I'll try to take a look into it. In the mean
time you can track the issue here:
https://github.com/OSGeo/grass/issues/2344
Sorry for your inconvenience,
Māris.
otrd., 2022. g. 26. apr., plkst. 21:08 — lietotājs Frank David
() rakstīja:
>
> Hello,
>
> I
Hello Frank,
Could you elaborate on „first item“ as I just digitized a vector map
with three lines and crossed them with a profile and got back three
distances.
Things to check – do all lines have a CAT value in specified layer?
If you have a problem with a specific data set, you can send me it
One thing to always check – does your computational region contain
data you are analysing? Try to run `g.region rast=immagine` before
running i.atcorr.
Māris.
trešd., 2022. g. 26. janv., plkst. 18:13 — lietotājs
rakstīja:
>
> Dear all,
>
> I am having troubles in processing a Sentinel-2 image
This looks like a version mismatch between library GRASS was compiled
with and library used when running. If you are on a Gentoo system, run
revdep-rebuild. If you are not using Gentoo, ask your package provider
to do a full recompile. I would put my money on GDAL (and a smaller
bet on PROJ).
At the back r.fillnulls is calling other interpolation modules. Some
of them can run in parallel but they are using implicit approach in
selection of threads to run by detecting number of CPUs. My guess –
for some reason this magick code gets CPU count wrong and thus does
not utilize all CPUs
pirmd., 2021. g. 20. dec., plkst. 11:29 — lietotājs Uwe Fischer
() rakstīja:
>
> Hello Māris,
>
> thanks a lot. That is hard tobacco for a user like me. What do you mean 'ask
> the same rendering engine'?
This depends on how you are planning to use those frames around text.
If as a background
AFIAK no*
It is more tricky than it might seem as exact dimensions depend not
only on font size but also on selected font (see monospace vs
condensed fonts), kerning, styling (bold, italics). Thus final size of
bonding box of a string is a product of all of its properties. Thus
the best option to
If the computational region is set to match input map, r.neighbours
will produce output in the same resolution. r.resamp.* will work if
the computational region differs from the input map.
Do not use r.neighbours with a different computational region, as
GRASS internally is using nearest neighbour
2021-09-30 10:46 GMT+03:00, Margherita Di Leo :
>> What does this error message mean? Why is it trying to write in the
> /.grass7 folder ? And what does the name '_' refer to?
It means that you need to fix your environment before starting GRASS.
Check your $HOME setting.
Māris.
Check the file with ogr: ogrinfo -ro -so path/to/file_name.shp file_name
Māris.
2021-09-29 22:32 GMT+03:00, Rich Shepard :
> I created a new location using the .prj file for cross-section contour
> lines
> and successfully input CL_33_LDYX_20210712_CS_contour_lines.shp. When I
> tried to input
One option always is to set colours manually.
Māris.
2021-09-29 19:12 GMT+03:00, Rich Shepard :
> Looking at the raster and raster addon modules I don't see one that will
> allow more elevation/depth 'slices' for a given range. r.resample appears
> to
> reduce the 'slices'; can it be used to
pirmd., 2021. g. 20. sept., plkst. 19:58 — lietotājs Rich Shepard
() rakstīja:
> I've used r.colors only for terrestrial DEMs before and elevation was
> suitable for the projects, so today's look at the manual page was too
> superficial. I missed water, etopo2 and the options.
Feel free to create
(Multi Polygon)
Māris.
piektd., 2021. g. 17. sept., plkst. 18:30 — lietotājs Rich Shepard
() rakstīja:
>
> On Fri, 17 Sep 2021, Maris Nartiss wrote:
>
> > I don't have File GDB at hand to test it but it should be as simple as
> > pointing "input" to the fo
Hello Rich,
I don't have File GDB at hand to test it but it should be as simple as
pointing "input" to the folder of FGDB and setting "layer" to the name
of dataset in FGDB. You can get names of all layers in CLI with
"ogrinfo -ro -so /path/to/FGDB".
Good luck & let us know if you succeed.
Māris.
Don't forget to run make distclean before reconfiguring and
recompiling GRASS. If you would be on a Gentoo, I would suggest to run
revdep-rebuild that would rebuild all packages linking to proj. On
Ubuntu you just have to look for a PPA with GIS packages compiled with
the right proj version.
Hello Thomas,
I gave you a wrong path. Try this one:
ldd /home/teaiii/grass-7.8.5/dist.x86_64-pc-linux-gnu/lib/libgrass_gproj.so
The problem still boils down to having different incompatible system
libraries during compilation and runtime. You can also search for
libproj.so files in /usr/lib(64)
This is a know issue. Most likely you have two versions of PROJ
library installed. Make sure to have only one llibproj.so file
present.
Here's a check for it (one line – good, more than one – bad):
ldd /home/teaiii/grass-7.8.5/lib/libgrass_gproj.so | grep proj
Here's a old bug report:
Hello Robson,
although I did not completely understood your problem, here are a few
points for a start.
1. Import WRF data in into a new location/mapset with its coordinate
system matching WRF one;
2. Set computational region resolution to 1km (g.region res=1000 -a -p);
3. Run one of r.resamp.*
As a former Gentoo user, I feel your pain. Unfortunately there is
nothing we can do, you must rebuild wxgtk and then rebuild wxpython as
building one and not other with the same g++ version is a path to hard
to predict random failures. And pray the mighty toolchain goods that
you have only one
You'll have to recompile PDAL after GDAL upgrade.
Good luck,
Māris.
2021-04-25 21:15 GMT+03:00, Rich Shepard :
> The error is "libgdal.so.26, needed by /usr/lib64/libpdal_base.so, not
> found". That's because Slackware upgraded gdal so libgdal.so.28 is
> installed.
As there is no problem with pdal 2.1.0, it could be that something has
changed in pdal. Please take a look into config.log file to see the
actual error. If there isn't something that looks like a problem
specific to your machine, open a bug report and attach failing part of
config.log.
Māris.
the issue -- life is good again! Thank you so much!
>
> Best regards,
> Tom
>
> On Fri, Apr 16, 2021 at 2:00 AM Maris Nartiss wrote:
>
>> Recompiling GRASS will not help. Look at your environment settings. In
>> terminal examine output of env – most likely it contains
Recompiling GRASS will not help. Look at your environment settings. In
terminal examine output of env – most likely it contains some extra
python paths that should not be there.
Usual suspects of not playing nice are any python modules directly
(ctypes, SWIG, ...) utilizing code from external
Hello Frank,
old LAS reading tools were based on libLAS. Nowadays libLAS is not
included in most of modern distributions and thus any GRASS tools
depending on libLAS are disabled at compilation time.
There is a work in progress to move LAS reading to PDAL for GRASS 8.
v.in.pdal is already in the
The r.in.pdal from the PR is totally different beast than one located
in add-ons.
It is quite common for LAS files to lack coordinate system
information. In a such case it is your responsibility to handle its
correctness. If your location is in the same coordinate system as LAS
files, just use -o
Hello Andreas,
r.in.pdal still lacks metadata printing functionality and thus has not
been merged into the main branch yet. You can get the code from this
PR: https://github.com/OSGeo/grass/pull/1200
Let us know if there are any problems with r.in.pdal.
Best,
Māris.
2021-03-24 0:11 GMT+02:00,
Markus, output of r.univar and r.info both can have scientific
notation in their range outputs.
Giuseppe, at least on my system r.mapcalc for floating point
expressions (if one of operands is floating point) defaults to double
(stored as DCELL). Still to be safe you can convert one of operands
Hello Giuseppe,
I am too lazy to calculate binary representation of your numbers, but
your suspicion of insufficient precision of float seems to be spot-on.
If output is set to DCELL, then the result is exactly as you would
expect. Try yourself:
r.mapcalc expression="output=basin -
ng the Ordnance Survey grid so I can't expect a huge resource to
> look at a narrow application.
>
> Cheers,
>
> Dave
>
> On Mon, 15 Feb 2021 at 10:08, Maris Nartiss wrote:
>
>> Hello Dave,
>> QGIS hides a bit of GRASS complexity by making a guess for various
>&
Hello Dave,
QGIS hides a bit of GRASS complexity by making a guess for various
parameters. As with any guess – sometimes it works, sometimes it is a
miss (and user has no idea which is the case).
To get contours out of LAS files:
1) create a location with coordinate system matching one used by
Hello Dave,
r.contour should be working just fine. Your posted Warning is
harmless. Please try to run it in a pure GRASS session and not through
QGIS – in case of failure, it will be possible to get a reasonable
error message.
As for upgrading of GRASS – be ware – LiDAR tools depend on libLAS
Hello Erik,
try this in r.mapcalc:
new_dem = if(old_dem < 25, null(), old_dem)
old_dem – name of map with input DEM;
null() – value to assign to cells below 25 (could be 0 too).
Keep in mind – your approach will put under water everything below a
specified level even if there is a natural or
Don't want to bring bad news, but it looks more like an offset
overflow. You will not catch it with valgrind. Although it might catch
a bug leading to offset value explosion, most likely the main cause is
just code written for handling of small/medium datasets and not
large/huge ones (=imperfect
Hello Omkar,
if you want to get any answer, include errors as a text in the body of
your email instead of images. Just select the error in your console
and paste into email.
Good luck,
Māris.
___
grass-user mailing list
grass-user@lists.osgeo.org
Lack of mapset locking feature is not a fatal error but just a
warning. GRASS should work just fine even after issuing this warning.
If GRASS fails to start on your system, the actual error must be a
different one. Either you manage to get the real error message or just
have to wait for an update
1) Clean up ".tmp" directory located inside the last used mapset;
2) Remove the "~/.grass7/rc" file to force a clean start for GRASS. It
is safe as GRASS will generate a new one if rc file is missing.
Hope this helps,
Māris.
___
grass-user mailing list
Hello Ashutosh.
Compilation and development issues are better to ask in dev mailing list.
Also – do not send errors as images. I have no idea what the error
message you got was and I assume I am not the only one. MS Windows
does support copying text from terminal.
Māris.
2021-01-19 20:41
Dear GRASS GIS community,
I am honoured to be nominated for the PSC.
I am a geographer (Dr.geog.) and self-taught programmer. My first
introduction to GRASS was around autumn of 2004 (5.x time). I remember
being fascinated by its 3D visualisation capabilities. I decided to
get to know GRASS
Thank you Vincent & Vincent.
I managed to reproduce an issue with curvature tool – output result
differs significantly by each run.
You can track progress in GitHub issue tracker:
https://github.com/OSGeo/grass/issues/1168
In the mean time just disable OpenMP before running r.param.scale:
export
Please state your computation region settings. This seems like a
overflow / memory corruption and region settings might play a role
here.
Māris.
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
Please provide more information:
GRASS version
Python version
exact error message
I did not observe any errors while running command you provided (of
course I used different map names to match map names I had on my
system).
Māris.
otrd., 2020. g. 17. nov., plkst. 06:04 — lietotājs ming han
()
Hello Eric,
it is hard to say if I hit your bug or another one, but I managed to
reproduce crash and already reported it to the bug tracker:
https://github.com/OSGeo/grass/issues/1024
The problem seems to be with specifying parameter "restrict". If you
really need it, just wait for a fix as it
Valgrind leak check is needed only for developers as it tracks memory
consumption not its errors (although in this case it allowed to notice
OpenMP presence by shear luck). As your valgrind run is clean, this is
a dead end.
On my system I also have a OpenMP and pthreads configuration.
Hello Vincent,
start with running stress tests on your hardware. I always run at
least 24h memtest followed by several rounds of compiling kernel on
any new hardware. Allowed to catch a misbehaving motherboard of laptop
before I started to use it for my daily needs.
You could try to run process
Something like anisotropic diffusion described by Perona P. and Malik
J. 1990? https://en.wikipedia.org/wiki/Anisotropic_diffusion
I do have a working C module performing aforementioned noise reduction
(with optional Tukey's conductance function according to Black et al.
1998) but I haven't found
pirmd., 2020. g. 27. jūl., plkst. 05:52 — lietotājs Janet Choate
() rakstīja:
>
> I tried changing permissions on .gislock, i.e.
> -rwxrwxrwx+ 1 jchoate staff 4 Nov 15 2013 .gislock
Check permissions of folder containing .gislock file. Are you the
owner of that folder? Does it have rwx for
ceturtd., 2020. g. 23. jūl., plkst. 16:01 — lietotājs Micha Silver
() rakstīja:
> So to make rasters in 7.8 and have them available in 7.2 you will need to set
> the GRASS_COMPRESSOR environment variable in advance to "ZLIB" before
> creating the rasters in version 7.8. THen those should be
tl;dr Only master branch (7.9) has some wxPython-4.1 related fixes.
Unless you are ready to provide fixes, do not mix GRASS with wxPython
>4.0.
Māris.
___
grass-user mailing list
grass-user@lists.osgeo.org
otrd., 2020. g. 26. maijs, plkst. 01:00 — lietotājs Rich Shepard
() rakstīja:
>
> When I run 'make' it eventually fails because,
> v.in.pdal: error while loading shared libraries: libproj.so.15: cannot open
> shared object file: No such file or directory
>
> That's because proj-7.0.1 provides
Hello Brad.
piektd., 2020. g. 8. maijs, plkst. 05:36 — lietotājs Brad ReDacted
() rakstīja:
>
> Hello,
>
> IIRC, signatures cannot be handled as colors without significant modification
> to api.
>
> Is there a particular reason for not improving the API to be map portable and
> remove subgroups
Thanks, Vaclav, for taking initiative into your hands. Please send us
approximate time of the new startup screen discussion meeting.
All best,
Māris.
otrd., 2020. g. 5. maijs, plkst. 21:10 — lietotājs Vaclav Petras
() rakstīja:
>
> New URL (Zoom):
>
>
Hello lists (sorry for cross-posting),
as GRASS 8 starts to look less Duke Nukem Forever (a.k.a. never), it
is a chance to change some things in imagery part. Thus if you heavy
relay on imagery part of GRASS GIS, please find some time to give
small feedback.
GRASS 7.8.0 imagery groups gained
JFYI
GRASS is also hit hard by recent GDAL/OGR ESRI Shapefile encoding
saga. Importing ESRI Shapefile with non-latin text most likely will
corrupt Your text.
Symptoms - even when setting correct encoding for wxgui in
preferences, non-latin letters are shown grabbled and doubled (two
garbage
You are looking for v.patch
As I know Your next questions, here are answers for them:
You must set up region before interpolating with g.region. Use vect
option to limit boundaries and res to set desired resolution.
Don't forget to use -e option for v.patch to join attribute tables
too. They must
Hello,
there are two options:
1st - join both datasets into single one (GRASS vectors can contain
different geometries in single vector dataset) and use v.surf.rst (it
will use both line and point data)
2nd - convert lines to points with v.to.points and then join into
single point dataset.
finished (0 sec)
On Sat, Jan 12, 2013 at 12:52 PM, Maris Nartiss maris@gmail.com wrote:
Please, post output of v.build
2013/1/12 Brian Sanjeewa Rupasinghe jink...@gmail.com:
Hi,
I used v.category. But it too keeps on running failing to add
categories.
On Fri, Jan 11, 2013 at 11:28
on this is appreciated.
Cheers, Brian.
On Sun, Jan 13, 2013 at 2:10 PM, Maris Nartiss maris@gmail.com wrote:
Hello,
there are two options:
1st - join both datasets into single one (GRASS vectors can contain
different geometries in single vector dataset) and use v.surf.rst (it
will use both
Hello,
as a (not so active) GRASS developer, I also use 7 for almost all my
daily needs. I agree about all nice things of using 7 previously
stated, still I also must give a fat warning - some code in 7 is not
yet tested enough. There are new bugs present in 7 only too.
Here is (infamous) example
Try to run on Your vector dataset:
v.category option=add type=centroid
Then export with v.out.ogr.
Reason - v.out.ogr is working correctly and Your centroids have no
CATs and thus are not exported. That would explain not correctly
created - an empty shapefile.
Hope it helps,
Maris.
2013/1/11
Please, post output of v.build
2013/1/12 Brian Sanjeewa Rupasinghe jink...@gmail.com:
Hi,
I used v.category. But it too keeps on running failing to add categories.
On Fri, Jan 11, 2013 at 11:28 PM, Maris Nartiss maris@gmail.com wrote:
Try to run on Your vector dataset:
v.category
a lot of NULL values in the produced raster?
Martin
Fra: Maris Nartiss [maris@gmail.com]
Sendt: 7. desember 2012 10:19
To: Martin Album Ytre-Eide
Emne: Re: [GRASS-user] v.to.rast not working?
Check the size of computational region. Just decrease
Hello all,
I just have commited to trunk (GRASS 7) a new version of r.fillnulls
that is filling each hole separately. On my test dataset it is giving
significantly better results than old one and provides ~2x speed up in
comparison with previous version (with a cost of increased disk use).
To
If they are not accessed at a same time, then only problem will be
with vector data. GRASS 7 uses a bit different vector data storage
format and thus vector data can be used (displayed) only after a
v.build run. It's a bit annoying and I don't know if it can introduce
any problems (I mean when
Hello,
please check following things:
1) water level at seed point/area is above terrain (provided DEM);
2) seed point/area is located within current computational region
(just run g.region rast=my_dem before r.lake);
3) seed point/area has values 0 (quirk of current implementation).
Good luck!
Hello Alexander,
if You are not willing to make it into GRASS addon, then, please,
submit it to issue tracking system so it doesn't get lost in ML.
Thanks!
Maris.
2012/8/22 Alexander Muriy amu...@gmail.com:
Hi, Janet and all.
can anyone tell me how to make 2 rasters out of my 1 along a user
Hello,
You have to run r.example from within GRASS work session. It wouldn't
work outside of GRASS work session unless You set up necessary
environmental variables so it would be more easy for You just to start
GRASS work session.
Maris.
2012/7/17 Albert Saribekyan albertsaribek...@rambler.ru:
Hello,
r.example should compile with provided Make file just fine. Most of
std* things are handled by main Make file and You have to provide
specific things, still I don't see anything specific in Your provided
example. Main Make file is made when You run ./configure in main GRASS
source
Hello Chad,
I assume You are trying to run it on MS Windows.
Please check following - does Your home folder path contains any
non-latin letters? If yes, try to create a new Windows user i.e.
grass and run GRASS from there.
Also worth to check if Your antivirus program / malware defence system
Hello,
but do original, unsmoothed vector also contains two lines?
Where those lines generated in GRASS or some other (not so
intelligent) software?
If manual splitting and deleting unnecessary parts is not an option,
I would suggest to play around with v.clean. Don't forget to make a
backup, as
Hello,
the problem is that some layer names have non-latin (Estonian) letters
and current code is not ready to handle such cases. I can try to look
at the code later (have to test changes) (as soon as I will recover
from Jaanipaev).
Still Maaamet watermarks their WMS service, what could interfere
v.profile is designed to do exactly what You are looking for.
http://grass.osgeo.org/wiki/GRASS_AddOns#v.profile
Maris.
2012/5/10 Carlos Grohmann carlos.grohm...@gmail.com:
Hi all
I'm thinking if there is a way to project a series of points into a line,
but this projection must be in a
Just a small correction - every WMS service provider must support
EXCEPTION=XML as a request parameter and return a XML document in case
of an error (see i.e. WMS 1.3.0 7.3.3.11). Every WMS client
implementation just playing with parameters without parsing XML is
doomed to fail (sooner or later).
If Your GRASS version has changed, most likely also GDAL version has
changed. Just look into GDAL changelog for any cell is point vs cell
is area type changes for Your raster format.
Also - for the next time don't forget to add info about raster format
You where trying to import.
Maris.
2012.
Hello,
I would suggest to use v.what.rast with multiple runs - one for each
of the raster maps. It's more simple than passing around coordinate
pairs.
Or if other sampling strategies are required (i.e. with bilinear
interpolation), the v.sample is the right tool.
Maris.
For the record: I created a ticket with a request to create a separate
tool with requested functionality.
http://trac.osgeo.org/grass/ticket/1627
Maris.
___
grass-user mailing list
grass-user@lists.osgeo.org
Hello Rich,
with Your provided data it's not possible to tell if You can do something.
Things to check:
1) the size of Your computational region. On 32bit system You might
hit a memory limits.
2) check Your OpenGL system. Does glxinfo and glxgears work fine?
3) run nviz under gdb and generate
Hello,
it seems that You are looking for v.db.connect, as You need to
reconnect existing vector data sets to a different database. (Or, if
You are careful, just edit MAPSET/vector/MYMAP/dbln file.)
As goes for a GUI crash, please, report it in the issue tracker, as
WXGUI shouldn't crash if DB
Hello,
just a small notice - v.delaunay will create a 3D triangulation if
input map is a 3D map. To get a meaningful result, first shift points
from 2D to 3D by v.transform and only then apply the v.delaunay
module.
Maris.
2012/3/17 TheGeographer dalur...@googlemail.com:
@Ben: I've tried that
Hello,
are You certain that it's not just a problem with data?
Have You run Your analysis at DEM native resolution? Try to g.region
rast=MyDEM before calculating aspect.
Also how reprojection was done?
Maris.
2012/3/12 leonidas leonidas_lia...@yahoo.gr:
I run r.slope.aspect on Aster DEM
1 - 100 of 236 matches
Mail list logo
