Hamish wrote:
Martin wrote:
in GRASS 7 we can support as key column also non-integer
columns,
just because we can, doesn't mean we should ...
+1
The key column is used to link attributes to vector features through the
category number assigned to vector features. Category
Martin Landa wrote:
Hi all,
most of the functions in Vlib takes layer number as argument. To
support layer names we need just change their prototypes to use 'const
char *' instead of 'int' and update all modules. Then layer will found
by number and if failed by name - see Vect_get_field2().
Michael Barton wrote:
I just tried to copy a vector file from within GRASS 7. The file is
from a couple years back and uses a dbf data table. I got an odd error
message.
g.copy vect=w...@baltic,wind
Copy vector w...@baltic to current mapset as wind
DBMI-SQLite driver error:
Error in
Paolo Cavallini wrote:
Hi Daniel.
Thanks for your reply. I'm trying to generalize (and smooth) polygons, not
lines, so your suggestion do not apply.
No, Daniel's suggestions do apply because you want to generalize
boundaries. If an area is defined by many short boundaries, there is
Hi Laura,
Laura Toma wrote:
my experience is that , if you want to see how an application would
behave with 500 MB of RAM, you have to physically reboot the machine
with 500 MB of RAM (it's very easy to do this on a Mac, and relatively
easy on Linux. on windows, i don't know).
if the
=30 in order to
get 312 million cells, sorry!
Markus M
-Laura
On Nov 14, 2009, at 6:51 AM, Markus Metz wrote:
Hi Laura,
Laura Toma wrote:
my experience is that , if you want to see how an application would
behave with 500 MB of RAM, you have to physically reboot the machine
with 500 MB
Please try trunk r39785.
According to the comments in the code, the auxiliary table is used to
store info about overlapping zones and is dropped at the end. The
auxiliary table is always created and used, also when no output vector
for display (QGIS output) is given.
Markus M
helena
,
if You understand taht code - how complex (usefull) would be getting
rid of DB at all? I mean - is it possible to store temporary data into
some faster data structure (file?) and thus eliminate all DB
dependencies for this module?
Maris.
2009/11/23, Markus Metz markus.metz.gisw...@googlemail.com
, and you are the best person to re-try these tests as you know how to
tweak it.
I'll get back about what terracost is doing and why it has such large
files after we see these new numbers.
-Laura
On Nov 17, 2009, at 3:51 PM, Markus Metz wrote:
Hi Laura,
Laura Toma wrote:
Hi Markus
Markus Neteler wrote:
Forwarded to the list upon request from T Laronde.
On Fri, Dec 4, 2009 at 3:27 PM, tlaro...@polynum.com wrote:
IMO, the first thing you should do is to create a lexicon, that is a
list of normalised words for GRASS and their meaning; this will avoid
the confusion
description is not topologically correct. If your
description of the actual state is correct, then this is a mess
that has failed to capture the very nature of topology.
For example for this:
On Mon, Dec 07, 2009 at 09:37:55AM +0100, Markus Metz wrote:
In grass, primitive features
Hi Martin,
r39814 broke native vector support because boundaries were not copied,
even if they belonged to an area with a cat in the given layer. Fixed in
39975 and 39976. Please make sure that OGR support does not interfere
with native vector support;-)
The behaviour of v.clean calling the
Err, module dialogs no longer size correctly on opening (Linux Fedora 10
and Fedora 12), was just fine before r39983 and r39984, now the lower
part is not visible, missing are the essential buttons close, apply, ok,
help for the d.* modules and close, run, copy, help for other modules,
Michael Barton wrote:
Maybe I just missed the announcement. But I was surprised to find that
areas no longer displayed as areas in GRASS 7, but only as boundaries.
After trying multiple vector area files and considerable futzing with
various settings I got an error that said that the topology
Vector topology must be rebuilt in grass7 with v.build for grass6
vectors in order to have topology available.
Up to now, grass7 vectors are fully compatible with grass6 vectors:
grass6 can work with grass7 vectors. Not the other way around, because
in grass7, the spatial index is again
Hamish wrote:
Michael wrote:
Somewhere along the line, we could probably use a script that
automatically runs v.build on all vectors in a mapset to build
the file based spatial index.
it could be called v.build.all. ;-)
(we have been down this road before during grass 5.7 ...)
Isaac Ullah wrote:
[...]
So, how can I make all 159 individual areas have unique category
numbers?!?!?
I think you have to delete all categories first, because v.category will
only add a category to a vector object if none is set (that information
is missing in the manual AFAICT). Or you
trac server gives problems, doesn't send new comment to list, see
https://trac.osgeo.org/grass/ticket/788#comment:7
GRASS GIS wrote:
#788: r.out.gdal and nodata
--+-
Reporter: frankie | Owner:
Markus Neteler wrote:
On Tue, Jan 5, 2010 at 11:06 AM, Markus Neteler nete...@osgeo.org wrote:
On Tue, Jan 5, 2010 at 9:55 AM, Martin Landa landa.mar...@gmail.com wrote:
I wonder if we can release 6.4.0,
...
I personally vote for going ahead and publishing this week RC6
Hamish wrote:
Michael:
A big blocker was fixed yesterday - v.delauany broken on Mac and
Windows.
(everyone needs to test the heck out of it now of course)
Suggested testing in spearfish:
start with the reduced archsites vector provided by Michael, 11 points:
Markus Neteler wrote:
Martin Landa wrote:
Hi all,
I wonder if we can release 6.4.0
I see:
A) winGRASS related:
* 580 WinGRASS: $GISBASE/etc/gui/scripts/ require something like $(EXE) to run
- status unclear to me
* 759 r.patch non-functional in WinGRASS 6.4 svn on Vista
-
Martin Landa wrote:
Hi,
direct OGR read access is implemented in the most of vector modules
[1]. You can access OGR layer directly (i.e. without linking it via
v.external) using 'map' and 'layer' parameters, e.g.
v.extract input=PG:dbname=nc_spm...@ogr layer=busstopsall
where=STREET_1 =
I updated v.voronoi in trunk r40286 and devbr6 r40288 to use much less
memory, it's also a bit faster. There is still work to do on it, but it
does much better now. The memory bottleneck is now no longer the
triangulation but topology building. Please test.
Markus M
Glynn Clements wrote:
Markus Metz wrote:
For the final version I would very much like to see a reasonably stable
Windows version, and it seems realistic to get this out soon.
The Windows version is hampered by a lack of Windows developers. Most
of the Windows development is being
Because of r40217, Rast_close() and Rast_unopen() can no longer be
called unconditionally. That gives me errors when a MASK is present:
ERROR: Invalid descriptor: 0
The following patch to lib/raster works for me but I'm not sure if this
is the right way
Index: init.c
Thanks for the quick fix!
It's working now, but I had to make one small change in order to get
GRASS started with msys terminal:
In C:\GRASS\bin\grass64 I changed
if [ -z $GRASS_PYTHON ] ; then\r
GRASS_PYTHON=python; export GRASS_PYTHON\r
fi\r
to
if [ -z $GRASS_PYTHON ]; then
Oops. I will look into it, works just fine here, also Linux 64bit.
what does g.region -p say?
Markus M
Pietro Zambelli wrote:
Hi all!
I'm Pietro and this is my first message here! So be patient if my information is
lacking in something.
I try to run r.cost on grass70 from svn but I have
Fixed in r40584, I hope.
Pietro Zambelli wrote:
Hi all!
I'm Pietro and this is my first message here! So be patient if my information is
lacking in something.
I try to run r.cost on grass70 from svn but I have this output message:
GRASS GIS 7.0 svn:40557-40571
===
$ r.cost
I get compile errors in trunk, at various places:
undefined reference to `G_open_mail'
undefined reference to `G_close_pager'
undefined reference to `G_close_mail'
undefined reference to `G_open_pager'
Is it possible that pager.c is missing in the svn repository? That file
is mentioned in
details on r40831:
Performance has been increased for all modules by reducing the default
segment size, interpolation settings are not affected. Previously, the
modules seemed to be optimized for settings where only one segment was
needed. As soon as several segments where needed, processing
, there is a problem with sqlite, it is much slower
than dbf, no idea if this is a problem of my system or of the grass
sqlite driver or of the way auxiliary tables are accessed by the lidar
tools.
Markus M
Thanks!
Maris.
2010/2/5, Markus Metz markus.metz.gisw...@googlemail.com:
details
more updates in r40860, mostly documentation
Hamish wrote:
Markus Metz wrote:
The core of the lidar tools is the lidarlib, that is AFAICT
robust and working. Bugs are most likely in modules, so I'll try
to add comments there. I have reorganized the code for v.surf.bspline
in the hope
Casey Vandenberg wrote:
Hi,
I know this problem has crept up before for some people, but has
anyone encountered this, or resolved this problem using a 9.10 build
of Ubuntu?
Any advice would be appreciated,
It seems there are two versions of grass installed, you are using
6.4.0svn, and
trac doesn't send the new comment to the ml???
see
https://trac.osgeo.org/grass/ticket/807#comment:10
GRASS GIS wrote:
#807: r.watershed doesnt consider longer distance to diagonal neighbouring
pixels
-+--
Reporter:
Patton, Eric wrote:
Hi,
I trying to decipher the meaning of the description of the r.out.gdal
–f flag. Currently, it reads:
“Force raster export also if data loss may occur”
The long description would be that the -f flag does not have any effect
if no data loss occurs. Only if the export
I found two code snippets in the segment library (all branches) that
look fishy to me:
the first is in relbr6 here
https://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/lib/segment/format.c#L135
should
if (lseek(fd, 0L, SEEK_SET) == (off_t) - 1) {
not be
if (lseek(fd,
Paul Kelly wrote:
Markus Metz wrote:
should
if (lseek(fd, 0L, SEEK_SET) == (off_t) - 1) {
not be
if (lseek(fd, 0L, SEEK_SET) == (off_t) -1) {
Hello Markus,
Well, looks like a bug in the indent program that got confused by the
cast and thought the - was being used as a binary rather
Glynn Clements wrote:
Actually, looking at the code in context, I'd write:
static void write_int(int fd, int n)
{
if (write(fd, n, sizeof(int)) != sizeof(int))
G_fatal_error(%s, strerror(errno));
}
Lets face it: you aren't going to be
Glynn Clements wrote:
I would use:
static int write_int(int fd, int n)
{
if (write(fd, n, sizeof(int)) != sizeof(int)) {
G_warning(%s, strerror(errno));
return 0;
}
return 1;
}
fixed in
running make in gui/wypython in grass64 gives me
Traceback (most recent call last):
File gui_modules/menudata.py, line 76, in module
gettext.install('grasswxpy', os.path.join(os.getenv(GISBASE),
'locale'), unicode=True)
File /usr/lib64/python2.5/posixpath.py, line 62, in join
elif path
Markus Neteler wrote:
On Thu, Feb 18, 2010 at 11:37 PM, Markus Metz
markus.metz.gisw...@googlemail.com wrote:
running make in gui/wypython in grass64 gives me
Traceback (most recent call last):
File gui_modules/menudata.py, line 76, in module
gettext.install('grasswxpy', os.path.join
GRASS GIS wrote:
#659: probable memory leak in v.surf.bspline
-+--
Reporter: hamish | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: closed
Priority: normal |
G. Allegri wrote:
I open a new post on the argument because it's something more general
that me and my collegues need to unsertstand.
I've tried to make the point with the various vector structures and
modes in grass7 and I admit to be a bit confused.
- v.external is meant to read ogr data
. Polygons do not need to be clean, but then nobody can guarantee for
the results.
Even with v.external?
Yes.
Markus M
2010/4/19 Markus Metz
G. Allegri wrote:
I open a new post on the argument because it's something more general
that me and my collegues need to unsertstand.
I've tried
G. Allegri wrote:
Markus Metz:
v.select requires a spatial index which in turn requires (at least some
basic information stored in) topology. Doing the same operation without a
spatial index would be much slower. BTW, v.select should be faster in GRASS
7 than in GRASS 6.x, particularly
On Tue, Apr 20, 2010 at 10:25 AM, G. Allegri gioha...@gmail.com wrote:
But even a simple overlay can give wrong results if the data is not
topologically clean... I personally cherish the fact that GRASS doesn't
make
it easy to do things quick and dirty.
Probably we mean different things,
On Wed, Apr 21, 2010 at 2:19 PM, G. Allegri gioha...@gmail.com wrote:
These are respectable points of view. As I've repeated many times in
this post, I don't expect Grass to work different. My only questions
was: is it possible to do not-topological processing in Grass? Given
its data
Isaac Ullah wrote:
[The new r.landscape.evol.py] takes advantage of the advanced MFD flow
routing capabilities of the newly
updated r.watershed module, which produced more accurate stream networks,
and flow accumulation values.
Nice, but r.landscape.evol.py works only with the GRASS 6.5
It seems that grass_gis is not in the library path. Usually it is in
install_path/grass-version/lib, I think. This path needs to be
added, on e.g. Linux to /etc/ld.so.conf.d/ (check your distro) where
you could add a file like grass.conf with the path to the grass
library directory in it.
HTH,
Soeren Gebbert wrote:
Hello,
A while back I did some crude profiling of the v.lidar tools and found
that it was spending lots and lots of time in the Tcholetsky decomposition
loop (3-for loops deep).
That's better now because the matrix is a bit smaller.
Yes, its a nice symmetric band
the backporting of the 6.5 version of r.watershed to 6.4 ;-)
or you make r.terraflow the default, with a flag indicating to use
r.watershed.
Anyway, IMHO, newly updated addons should run in 6.4 with the default settings.
Markus M
Markus Metz wrote:
Isaac Ullah wrote:
[The new
On Wed, Apr 28, 2010, Soeren Gebbert wrote:
Hmm, if I understand the code right, only the innermost for loop [of the
tchol solver] can be
executed in parallel because the first two for-loops need results of
previous runs (not possible to run i + 1 before i, same for j). But I don't
know
Hi all,
there is a new module in grass7 for raster interpolation called
r.resamp.bspline, based on the lidar tool methods. NULL cells are
filled on the go, no need to fill them first. Alternatively, the
module only interpolates NULL cells in the input raster, running quite
fast in this mode. The
On Fri, May 7, 2010 at 11:38 AM, Martin Landa landa.mar...@gmail.com wrote:
Hi,
2010/5/7 Markus Metz markus.metz.gisw...@googlemail.com:
there is a new module in grass7 for raster interpolation called
r.resamp.bspline, based on the lidar tool methods. NULL cells are
filled on the go, no need
... because in the python script there is in line 120
reg = grass.region()
but it should be the python equivalent to bash
eval `g.region -gm | grep res`
note the -m flag. This is necessary because the input buffer distance
for r.buffer must be in meters.
Markus M
Markus Metz wrote:
... because in the python script there is in line 120
reg = grass.region()
but it should be the python equivalent to bash
eval `g.region -gm | grep res`
note the -m flag. This is necessary because the input buffer distance
for r.buffer must be in meters.
Fixed
On Fri, May 7, 2010 at 2:19 PM, Glynn Clements gl...@gclements.plus.com wrote:
Markus Metz wrote:
BTW, this module should probably stay in `raster/` instead of
`vector\lidar`.
For compilation it is easier if it is in vector/lidar because it uses
stuff in lidarlib. Otherwise it will fail
Hi Sara,
your help is highly appreciated! There are no new commands, only one
in grass7 called r.resamp.bspline. Contrary to v.surf.bspline, it uses
a raster map as input and resamples that map to the resolution and
extends of the current computational region. The existing commands
have been
starting grass7 r42212 gives me
Starting GRASS GIS...
Traceback (most recent call last):
File
/home/markus/src/grass-7.0.svn/dist.x86_64-unknown-linux-gnu/etc/gui/wxpython/gis_set.py,
line 37, in module
from gui_modules import help
ImportError: cannot import name help
Error in GUI startup.
Martin Landa wrote:
Hi Markus,
Markus Metz:
related to r42204 where help.py was moved to ghelp.py?
yes, hopefully fixed in r42213.
Sorry not here. Now I get
Traceback (most recent call last):
File
/home/markus/src/grass-7.0.svn/dist.x86_64-unknown-linux-gnu/etc/gui/wxpython/wxgui.py
Martin Landa wrote:
Hi,
Markus Metz:
Sorry not here. Now I get
Traceback (most recent call last):
File
/home/markus/src/grass-7.0.svn/dist.x86_64-unknown-linux-gnu/etc/gui/wxpython/wxgui.py,
line 94, in module
from gui_modules.help import MenuTreeWindow
ImportError: No module
On Wed, May 12, 2010 at 1:11 PM, Glynn Clements
gl...@gclements.plus.com wrote:
Markus Metz wrote:
#ifdef __MINGW32__
#define off_t off64_t
#define fseeko fseeko64
#define ftello ftello64
#endif
in config.h have any effect?
If you do that, you will also need to fix lseek() and stat
I can't save the display to graphics file in grass65 and grass7, error
message appears only when closing wxGUI, not when hitting OK:
(python:18571): Gdk-CRITICAL **: gdk_draw_drawable: assertion
`GDK_IS_DRAWABLE (drawable)' failed
works fine in grass64, and worked fine before in grass65 and
Markus Metz wrote:
The windows position is no longer properly restored when opening
wxGUI. Maybe that has something to do with my dual screen setup, so I
tried all combinations of display on one monitor, layer manager on the
other monitor, display and layer manager on first monitor, display
Glynn Clements wrote:
Markus Metz wrote:
Also, are there any cases where we pass an off_t to a third-party
library? Because that would require the library to use a 64-bit off_t
(this is one of the reasons why _FILE_OFFSET_BITS=64 has to be
explicitly enabled).
But even
On Fri, May 14, 2010 at 8:31 PM, Glynn Clements
gl...@gclements.plus.com wrote:
Markus Metz wrote:
To avoid confusion, on MINGW32 it would be better to not use
_FILE_OFFSET_BITS=64 and don't set USE_LARGEFILES and HAVE_LARGEFILES
even if LFS is requested? Unset/undefine somewhere
On Fri, May 14, 2010 at 8:39 PM, Glynn Clements
gl...@gclements.plus.com wrote:
Helmut Kudrnovsky wrote:
In summary, it seems that grass libraries have no access to a 64-bit
off_t when compiled in MINGW32, also with ./configure
--enable-largefile.
maybe FYI:
GCC for both x64 x86
Michael Barton wrote:
I just discovered that save to graphics file is broken in GRASS 6.5. I
haven't seen this come thought the list yet. Has anyone else noticed it?
I'm working with r38990 from a couple weeks back. Mac OS X 10.6
It fails completely silently. Nothing gets saved to disk but no
William Kyngesburye wrote:
The Mac makefile doesn't do any of the GRASS compilation, only the Mac
startup compilation. gui/wxpython is always compiled, regardless of the
system.
Maybe wxpython now needs something from a folder that is compiled after it
(visualization, locale, man, swig),
Glynn Clements wrote:
Markus Metz wrote:
In GRASS, config.h does not know about __MINGW32__ even if __MINGW32__
is (somewhere else) defined, thus off_t is not redefined for mingw32,
and I placed the redefinitions for testing in another header. Looks
like a lot of hacking to get LFS
Glynn Clements wrote:
Markus Metz wrote:
In 6.x, LFS is enabled for specific libraries or modules using e.g.:
ifneq ($(USE_LARGEFILES),)
EXTRA_CFLAGS = -D_FILE_OFFSET_BITS=64
endif
in the corresponding Makefile. This needs to be done on a case-by-case
basis
Glynn Clements wrote:
Markus Metz wrote:
So, how about
#ifdef __MINGW32__
#if defined(__MINGW32__) defined(_FILE_OFFSET_BITS) _FILE_OFFSET_BITS
== 64
+/* add/remove as needed */
#define off_t off64_t
#define fseeko fseeko64
#define ftello ftello64
+#define lseek lseek64
Martin Landa wrote:
Hi,
2010/5/19 svn_gr...@osgeo.org:
Added:
grass/trunk/vector/lidar/lidarlib/lidar.h
Removed:
grass/trunk/vector/lidar/lidarlib/PolimiFunct.h
probably lidarlib/ could be moved to lib/ and r.resamp.bspline to raster/ (?).
It's planned, but one step after another,
Glynn Clements wrote:
Markus Metz wrote:
Alternatively, I found 26 files in trunk using struct stat. All these
would need to be modified by hand...
I would guess that many of them only use it for the st_size field. In
which case, adding off_t G_file_size(const char *filename) would
reduce
Glynn Clements wrote:
Markus Metz wrote:
At least clean_temp, d.font, g.mkfontcap, g.access need stat(), no way
to replace that with a more portable version to get time and/or mode?
[snip]
g.access actually uses the permissions. G_recursive_copy() reads the
permissions to copy them
Markus Neteler wrote:
Hi,
is below a backport candidate?
AFAICT, this applies only to devbr and trunk, and it's in there already.
I do not understand the change in main.c because ...
Modified: grass/trunk/raster/r.drain/main.c
Hamish wrote:
Helena wrote:
Maybe I am overlooking it but the man
page for r.watershed does not say what units
the option flow should be in - I am guessing it is
fraction of 1 (or percent given as decimal - e.g. 50% will
be 0.5)
so should flow amount read as fraction or something
like
Helena Mitasova wrote:
Maybe I am overlooking it but the man page for r.watershed does not say what
units
the option flow should be in - I am guessing it is fraction of 1 (or
percent given as decimal - e.g. 50% will be 0.5)
so should flow amount read as fraction or something like that, so
GRASS GIS wrote:
#1088: r.fillnulls: support other interpolation methods
-+--
Reporter: kyngchaos | Owner: grass-...@…
Type: enhancement | Status: new
Priority: normal | Milestone: 6.5.0
António Rocha:
Hi there
I have installed the latest WinGRASS binary release
Are you using WinGRASS-6.4.SVN-r42618-1-Setup.exe or another version?
and I tried to use the
georrectify functionality but I got an error. Immediately after I select
image from where to get the GCP's, the
numbers separated by :
António Rocha:
Markus I cannot remember unfortunely. I will uninstall and intall exacly the
latest and get back to you and the mailing list.
Back in 30 minutes
Antonio
Markus Metz wrote:
António Rocha:
Hi there
I have installed the latest WinGRASS binary
... IS that expected?
Yes, any maps to be displayed for the target location must be added
through the regular GIS layer manager and will be displayed in the
main (or currently active) display.
Markus Metz wrote:
Back to ML:
I fixed that only 3 days ago in r42618, a previous version could show
Markus Neteler wrote:
time to get out 6.4.0final :-)
Please...
Please check the list at
https://trac.osgeo.org/grass/query?status=newstatus=assignedstatus=reopenedgroup=typepriority=blockerpriority=criticalmilestone=6.4.0order=id
Several of the entries seem to be (almost?) solved but
Hamish wrote:
[snip]
RC bugs according to the trac'er:
https://trac.osgeo.org/grass/report/13
The one blocker applies to Windows 7 only. My point was that for Linux
and IIUC also MAC 6.4 is stable. GRASS is not part of a Windows7
installation, but available through Linux repositories, e.g.
Eric Patton wrote:
Hi,
I've encountered the following error launching the wxgui from Grass 6.5
using today's svn checkout:
(I get several screens worth of the following text)
Looks like Martin Landa is printing out the settings for debugging?
There is new print stuff as of r42689 in
I need a working 6.5 for other bugs, so I fixed nviz_tools.py and
preferences.py in r42720 and r42721
The warning
WARNING: Nviz extension (3D view mode) disabled. Reason: No module named ogsf
is still there, but Martin is going to replace the cpp nviz version
with a python version, IIUC, so no
[reply outside tracker because not part of original ticket]
Comment(by hamish):
Replying to [comment:37 mmetz]:
Well, then we have to change the way modules are presented in the menus.
[aside] can we have a README.howto file in the gui/wxpython/xml/ dir?
Every time I edit
Mohammed Rashad wrote:
I would like to manage grass imagery modules (trying to make gui modules for
imagery tools).
Can anyone give me any suggestions or tips which I should follow during
development.
If anyone is willing to mentor me I am happy to be a student of you.
I am nearly finished
Martin Landa wrote:
Hi,
2010/7/15 Markus Metz markus.metz.gisw...@googlemail.com:
I am nearly finished with a wxGUI version of i.points, based on the
georectifier, but with two panes, more functionality and some more
safety nets. This, once I have submitted it, plus the georectifier
could
Hamish wrote:
excellent do see the imagery modules getting some attention.
fyi spend some time exploring i.vpoints too, besides the mouse-only dual-
window method there is some nice stuff hiding in there there like reverse
projecting vector overlays from the target Location, 1st, 2nd, 3rd
Hamish wrote:
just a quick wish, could the right panel hide away with a triangle
button, like in tcltk NVIZ in the bottom-left to hide the control
panel.
Different solution: if no target map is specified for display, the
target display is hidden. A map can be added later on to the target
Why does g.transform overwrite the POINTS file [1]? This module is not
supposed to modify the POINTS file IIUC. It seems the coordinates of
the control points do not change. Not a serious issue, but if there is
no need to overwrite existing files, better don't do it?
Markus M
[1]
Helmut Kudrnovsky wrote:
- release 6.4.0 now as-is
there is strange behaviour in the map display.
auto-rendering is enabled.
if you deselect all your raster- or vector-maps in the layer manager for
displaying,
the last map is though always displayed.
if you erase the display and
Helmut Kudrnovsky wrote:
some random testing in a self compiled wingrass7 (r42884) on WinVista32 with
nc-sample-dataset:
raster/r.resamp.bspline
r.resamp.bspline --verbose input=elevat...@permanent output=rresampbspline
spline step in ew direction 15
spline step in ns direction 15
Glynn Clements wrote:
r42876 implements a fairly invasive change to the raster window
handling in 7.0. Specifically:
1. Modules which read and write maps at different resolutions now make
use of the ability to set separate input and output windows
(Rast_set_input_window() and
Markus Neteler wrote:
the two (!) remaining blocker bugs are:
* https://trac.osgeo.org/grass/ticket/1115
- Mac OSX only? Seems to be a wxpython 2.8.10.1 problem (wasn't there
something similar recently in the new i.points?)
Not related to the problem the new i.points had with
Glynn Clements wrote:
r42876 implements a fairly invasive change to the raster window
handling in 7.0. Specifically:
1. Modules which read and write maps at different resolutions now make
use of the ability to set separate input and output windows
(Rast_set_input_window() and
Martin Landa wrote:
Hi,
2010/8/3 svn_gr...@osgeo.org:
else {
- fprintf(stdout,
- _(layer %d table %s in database
%s through driver
- %s with key %s\n), fi-number,
-
it. OK?
Markus M
Markus Metz wrote:
Martin Landa wrote:
Hi,
2010/8/3 svn_gr...@osgeo.org:
else {
- fprintf(stdout,
- _(layer %d table %s in database
%s through driver
Markus Metz wrote:
That was too fast. There is a problem with the new format. It works
just fine for standard output for one layer, but it has broken some
modules and wxGUI which rely on one line per layer in the form
layer/name;table;key;database;driver
layer/name;table;key;database;driver
501 - 600 of 1175 matches
Mail list logo
