an error message
saying you should try to use a projected location instead.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
(lat): 1852*60 : 1 as the cheap and dirty projection.
for global lat/lon views you probably wouldn't want to do that
though.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
before 5.0.0)
Hamish
ps- tested with a really old libpng 1.2.15, it built ran ok.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Hamish:
For grass 6.x g.extension.sh installs into
GRASS_ADDON_PATH, are there any objections to
installing the addon man pages to e.g.
~/.grass6/addons/docs/man/ instead of
~/.grass6/addons/man/ ?
Martin:
I would keep manual pages where they are. At
least the current directory layout
Glynn wrote:
The add-ons directory should follow exactly the
same structure as the main $GISBASE directory.
perhaps for grass7, but 10 years worth of backwards
compatibility with the implementations in grass5 and
grass6 says otherwise for those.
Hamish
for the man page moving and symlink replacement
I'd like to backport that before 6.4.2rc3, aka ASAP.
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
where we really
really go bug-fixes-only for the 6.4 line, but as long as
backporting wxnviz bits does not touch code outside of
gui/wxpython/ I don't mind it being allowed to go from 40% to
80% for 6.4.3. I would not be very happy with deep changes to
lib/ogsf however.
2c,
Hamish
ps- what's
is used.
[*] actually since I now notice that 6.4.2rc2
shipped with the broken g.extension install bug,
I've backported them just now in r49320. fwiw this
would have been done for rc2 but it went out the
door before I got the warning that its release was
imminent.
please test (relbr64),
Hamish
be done directly from the command
line with inkscape, btw.
regards,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Hamish:
Depending on the graphical complexity, also
consider adding them as grass symbols, so that they
could be used seamlessly both by the regular GUI
map window and the ps.map composer. (and a much
wider audience)
there are already 2 north arrows, 2 compasses, and
[5] other
Hamish:
- bin/ and script/ do not really belong in
GRASS_ADDON_PATH,because GRASS_ADDON_PATH was
not meant to be GRASS_ADDON_BASE.
Martin:
no worries here, just you reverted something
which was working.
It was an unneeded work around for another problem
that had since been fixed
); please don't change anything in the mean
time.
regards,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Hamish wrote:
simple, clean, consistent, and doesn't stop others
from working the way they want to work.
well, maybe consistent for all sets/perspectives is
the part we're working on right now. :-)
Hamish
___
grass-dev mailing list
grass-dev
fuzzy memories of years ago,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
hamish:
undo r49166: units, vdatum, and title can not be
eval'd so needed to be split out. on doing that it was
apparent that -g needs to act the same as g.region and
v.info modules -- basic region info only. -s is debatable to
belong to -g or not, but -gs is very easy if needed.
Martin
blocks?
In that case no -- K.I.S.S. and don't have 1/2 dozen n= enviro
variables overwriting each other.
best,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
due to r49183 move prototypes from include/
to include/defs. Some fixes have been trickling in
since, so try, try, again.. (+distclean)
Hamish
ps- please please let there be some communication,
proposal, justification, and discussion before
unilateral decisions to make major changes to the
code
not be a fan of library-specific error handling anyway, make what-
ever solution available for all from libgis.
what's the practical use case you've found which could use it?
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http
() then
eval `r.info -g` will fail.
(for `r.info -t` I've always had to use `cut -f2- -d=` instead of eval)
also a bunch of scripts and python libs should be updated if the usage
changes.
comments?
thanks,
Hamish
___
grass-dev mailing list
grass-dev
Hamish wrote:
I am not so sure about r49166. I don't really
mind about adding map type and res to -g to make
it more like 'g.region -g', but wonder if things
like vertical datum and data units should only
export if they actually exist.
Note -t can't be included, as if the title contains
realistically make it to 80%, and 90% with effort.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
boot.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
that
the reuse and misuse of the existing variables is leading us in
circles.
(again, AFAIK it is just gr65 run from $src/bin.x86.../grass65
where g.extension.sh has troubles right now)
we'll get there eventually, it is so very close...
Hamish
___
grass-dev
Hamish committed:
- GRASS_ADDON_PATH=$HOME/.grass6/addons/bin:$HOME/.grass6/addons/scripts
+ GRASS_ADDON_PATH=$HOME/.grass6/addons
Martin wrote:
I *really* do not understand this change! It goes completely
against your opinion [1]!
...
[1] http://lists.osgeo.org/pipermail/grass-user
Author: hamish
Date: 2011-11-06 13:02:08 -0800 (Sun, 06 Nov 2011)
New Revision: 49122
Modified:
grass/branches/develbranch_6/include/Make/Man.make
Log:
MODULE_TOPDIR refers to the source code dir, not
the installed ARCH_DISTDIR. see the first line of the main
Makefile
Hamish:
yeah but the change before it most probably just broke *all* man page
building for a regular fresh full build(!)... (I didn't try, but it is
wrong, so probably..)
Martin:
of course I have tried that before I committed this change,
nothing was broken!
shrug. did you distclean
and folks probably don't bother us much with errors in
their personal workflows.
greets from SFO,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
to automatically prepend the $PATH,
then why not make that easy for those who want to use it?
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Glynn wrote:
In any case, there doesn't appear to be a
supported programmatic method for determining
that a map is a reclass.
at the filesystem level, checking the first line of
cellhd/$map_name gives you the info.
Hamish
___
grass-dev mailing
Hamish:
the main thing I'd like to see get done before rc1 is
an answer on the double call to $(MAKE) if INST_NOW=y is
passed to Grass.make.
...
Markus N:
Is this solved?
some minor cleaning still needed, but hopefully it is now working
well enough for release.
go,
Hamish
Glynn wrote:
Make itself doesn't have any quoting mechanism, so you
can't have spaces in any path which is used as part of
a target or prerequisite, or an include directive, or
which is processed by make functions (patsubst, wildcard,
etc).
Hamish:
as there will be spaces in both
--- On Thu, 9/29/11, Helmut Kudrnovsky hel...@web.de wrote:
Glynn:
Also, AFAICT the installer doesn't attempt to fix ${prefix}
to match the actual installation directory, so if the user
chooses a different location, Platform.make will be wrong.
Hamish:
right; not really sure how to do
?)
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Hamish wrote:
the main thing I'd like to see get done before rc1 is an answer on
the double call to $(MAKE) if INST_NOW=y is passed to Grass.make.
AFAICT that's the only thing left blocking g.extension[.sh] from
finally working with the Ubuntu Debian packages by users
without
Markus Metz wrote:
I agree. v.db.univar should have options 'map' and 'layer', not
'table', 'driver', and 'database'. Otherwise it would need to be
called db.univar, not v.db.univar.
since there is already a v.univar module like that, renaming to db.univar
seems like the path to take.
Hamish
software. (see also the
live dvd)
viva v.{in|out}.gpsbabel
best,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Hamish wrote:
one that failed was d.barb, it failed looking for
-lfreetype, although libfreetype6.so.* is found in /usr/lib.
That won't help; it would have to be using -lfreetype6
rather than -lfreetype.
sorry my mistake, /usr/lib/libfreetype.so.6* exists from the main
debian package
Hamish wrote:
This looks like it will fail if there are spaces in
the path names:
[...]
Glynn wrote:
Single quotes:
make MODULE_TOPDIR=$GISBASE \
ARCH_INC='-I$GISBASE/include'
'-I${MYINST_DIR}/include' '-I$TMPDIR/$DIST_DIR/include' \
ARCH_LIBPATH='-L$GISBASE/lib'
'-L${MYINST_DIR
to life
to further test #1452 (wingrass broken datum trans. selection in the wx
loc'n wiz [not sure if it is a symptom of the broken epsg file currently
in proj 4.7.1svn or not]).
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http
it?
besides the r.info list which is there now, how about new -p and
-g flags added to r.reclass to print them in form or csv format?
(out= would need the conditionally-required magic flag in trunk)
or perhaps a new -c flag for r.info for that?
Hamish
Martin wrote:
* `input=-` means that it will read data from standard input,
so the command waits for that (it will wait for eternity if
you do not provide any input;-)
Hamish:
I don't have a solution to that (probably common) problem,
Martin:
try r48444 (trunk). When providing opt=- GUI
in this regard;
doing so respects the users' confidence to invest their energy
(once) and get on with their work, and makes grass a more
dependable platform to base their infrastructure/work flow on.
this is a blocker for 6.4.2.
thanks,
Hamish
___
grass-dev
arrays in the general/abstract sense
(which many of the changes in r48435 seem to be, but I think it is
useful to introduce the voxel term there as it makes the
association clear, and there are limited chances to introduce the
term).
thanks,
Hamish
___
grass
for discussion on a proposed solution which does not
make the CLI experience more annoying.
http://trac.osgeo.org/grass/ticket/886
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
-
understanding what stdin means, so the problem does not go away
completely.
shrug,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
/.
regards,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Hi,
r48353 deleted trunk/display/displaydrivers.html; is the info that
was in that available elsewhere? would it be better to expand that
page rather than just delete it?
lib/cairodriver/, htmldriver/, pngdriver/, and psdriver/ are still
present and relevant.
thanks,
Hamish
Michael wrote:
Is there a way to find out the color value for every cat
value in a raster map?
r.stats -n fields --quiet | r.what.color -i fields
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo
Hamish wrote:
hmmm, it would seem I never committed the DebianGIS patch to fix the build
dir from the build-server's value to the end-user's installed value:
sudo sed -i -e 's+^\(GRASS_HOME[ ]*=\) /build/.*+\1 ${INST_DIR}+' \
-e 's+^\(RUN_GISBASE[ ]*=\) /build/.*+\1 ${INST_DIR
could rip the menu bar off into a floating window, but not
close it without taking down the rest of the window with it.
thanks a bunch,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Luca wrote:
Hi devs, is there a correspondent function to G_debug() in
python?
grass.debug(value = [%s] % some_string, debug = 2)
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
#map
r.mapcalc map.blue = b#map
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
.
big matrix datasets is why Matlab/Octave/Scilab ( raster GIS) was
invented ;-)
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
don't guarantee that
it actually matches the expanded terms?
should g.setproj delete the PROJ_EPSG file when it runs?
perhaps Paul is lurking and could offer some perspective?
perhaps we should cc the PROJ4 mailing list for repercussions
we haven't considered?
Hamish
been there since r.sun2 was introduced.
(candidate for backporting to 6.4)
Besides fixing the rotation bug this makes the module run a few
percent faster.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo
on other computers. Am I
the only one that think it looks really tiny?
it looks a wee bit small to me too, but I wonder how well the
usage section fits for those working on a small netbook?
Hamish
ps- I just tried: ctrl-mouse wheel doesn't help
Hamish:
v.out.ogr can certainly _not_ export to anything that
gpsbabel supports.
Markus M:
But see
http://gdal.org/ogr/drv_gpsbabel.html
hmmm, a most interesting and welcome development.
none the less, wrt v.out.gps I'd still argue for a separate,
specialized, and easy to use front end
of it in trunk any more.
thanks,
Hamish
ps- note I still need to port (aka rewrite) the v.in.gpsbabel
shell script to v.in.gps (python) in trunk. v.in.garmin can be
dropped (it has richer support for older Garmin hardware).
https://trac.osgeo.org/grass/changeset/45975
=${CMDLINE}
fi
probably we should continue this thread in bug reports.
thanks for the testing,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Hamish:
how do the two compare performance wise? are the options/
flags 100% backwards compatible? give identical results?
Markus Metz:
We (you and me and others) had this exact discussion
previously.
Excerpts from the previous discussion:
v.rast.stats does not scale at all, for e.g
should be aware if we've meant to backport something but
forgotten to do it.
Any reason to wait any longer for 6.4.2rc1?
letting go is hard to do,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass
, both reported and not.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
there since the
1990s, and perhaps the 1980s too? since stability = discipline *
time, and one of our great strengths is time. whenever we cut
old roots and reset that clock to 0 it's a great loss to one of
our core assets.
thanks,
Hamish
___
grass-dev mailing
, wxGUI: they do not have the many years of
assumptions built upon them, both by us, our users' personal
scripts, and 3rd parties; so do what improvements you like.
(.grass6/wx etc, and .grass7/all sounds good to me)
thanks,
Hamish
___
grass-dev mailing
Hamish:
re. ~/.grassrc6, do not mess with the location of
longstanding support files. 6.x is the **stable** branch
which should have its core firmly in bug-fix-only mode.
[I'm just talking about the ~/.grassrc6 gisenv file on unix here]
Martin:
6.4 is stable branch, not 6.5.
I
Hamish:
please revert unix ~/.grassrc6 bits of r47956 for 6.5
immediately.
Martin:
disagreed. Martin
if our opinions cancel each other out, the matter is up to the
consensus of the rest of the group then.
best,
Hamish
___
grass-dev mailing list
)
also consider renaming g.transform to m.transform.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
to know what the plan is. tx
cheers,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Martin wrote:
Also note that nviz is going to be removed from trunk when
wxNviz will be completed (I hope soon).
Hamish:
well, no. there's no reason to remove it in the short term,
even as the wx version matures nicely. an optional tcl/tk
dependency in the source code costs very little
Hamish wrote:
perhaps to phrase my words better: I would rather
appreciate it if you didn't remove code which I'm actively
using.
well, I know I can phrase my words better-- s/you didn't/we didn't/
cheers,
Hamish
___
grass-dev mailing list
grass
to some folks.
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
too far
away.
I think it would be nice and helpful to have something like
a wiki item of the day at the starting page
grass.osgeo.org.
any opinion on this? any ideas how this could be
implemented?
Hamish:
sure, just point to the URL for go to a random wiki page:
http
Glynn:
The iostream library uses size_t. However, r.terraflow
itself had a bug (scale then cast instead of cast then scale),
which should be fixed by r47641.
in the same class, but sort of unrelated- any thoughts on #1107?
https://trac.osgeo.org/grass/ticket/1107
thanks,
Hamish
for NULL values
**:r:g:b color to use for undefined (beyond color rules)
[^^] sometime seen when FP max goes beyond integer max, or color
table borrowed from a nearby raster who's range isn't quite as
big.
don't really know, just some ideas,
Hamish
it would be nice and helpful to have something like
a wiki item of the day at the starting page grass.osgeo.org.
any opinion on this? any ideas how this could be implemented?
sure, just point to the URL for go to a random wiki page:
http://grass.osgeo.org/wiki/Special:Random
Hamish
format is another wonderful cpu-saving
device worth mentioning btw)
http://www.gdal.org/gdal_vrttut.html
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
is
made.
slight variation backported to 6.4 in r47410. please test.
note that test -n is the same as ! -z for a non-zero length
string.
note the breakage was introduced after 6.4.1, so only present
in development snapshot builds; db.out.ogr works in the last
official release.
Hamish
work.
which variables exactly would be better controlled by modules
directly? (eg FONT needs to be unique per-module not per-monitor,
but GRASS_WIDTH,HEIGHT are unique per-monitor)
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http
Hamish wrote:
which variables exactly would be better controlled by
modules directly?
Glynn:
Anything where you want the user to be able to change the
setting via a module rather than requiring the user to use
export or eval `...`.
I ask because I'm having trouble imagining examples
forward compatible.
pthreads doesn't parse, it breaks up the processing into multiple threads
internally for a performance gain.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Soeren wrote:
Should such a strong external dependency really be
considered?
Glynn:
GDAL is already almost mandatory.
Hamish:
the bit I worry about is putting so much of the core
functionality onto a 3rd party sole-supplier over which
we have limited control.
Markus
flashbacks of spending a lot of time re-sync'ing
fixes to i.points, i.vpoints, ..., after their cloned graphing
code had diverged for many years.
(hoping this means we can have the best of both worlds!)
That's the aim.
great,
Hamish
___
grass-dev
,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Hi,
can we move the test files into $MODULE/testsuite/ or similar?
I'm just looking at grass7/raster/r.colors/ and the test files
really dominate the module dir.
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http
, unless we add external
dependencies and system() calls which are not very portable.
(maybe just PPM GIF are allowed directly from tcl/tk?)
the Wx version shouldn't be limited by that.
rough memory,
Hamish
___
grass-dev mailing list
grass-dev
be
reasonable enough.
2c,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Michael wrote:
Any wxgui action causes a lot of
output to the terminal in the current svn version of GRASS
7. Here is an example from adding a raster and a vector to
the layer manager.
D1/5:
...
what goes `g.gisenv` say about the GRASS_DEBUG level? Is it set
to 0? (aka debug messages
Hamish:
what goes `g.gisenv` say about the GRASS_DEBUG level?
Is it set to 0? (aka debug messages off)
Martin
it should be `DEBUG` not `GRASS_DEBUG`, right?
right.
H
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org
split like for standard 2D contour lines less
confusing for the viewer to understand?
(I'm working with heavily vertically stratified data and the
linear approach isn't working very well)
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
of worse
performance of scattered large non-point datasets?
is time to run d.vect in a sub-region of the overall map a good
way to test the performance difference?
(hoping this means we can have the best of both worlds!)
thanks,
Hamish
___
grass-dev
CMD=v.build map=${VECT}@${MAPSET}
- g.message $CMD
+ g.message message=$CMD
Hamish:
Needed in this case because the string contains a '=',
which confuses the parser.
Glynn:
That should really be fixed in the parser. Even in 6.x, an
option name cannot contain a space
CMD=v.build map=${VECT}@${MAPSET}
Hamish:
ps- those curly brackets do nothing..
Markus M:
also no harm
yes and no-
sure it's a minor issue, but they help propagate
the myth that curly brackets can be used to safely
quote shell variables, which is harmful also has
the consequence
as a g.message -d debug or verbose message, or is
it there for instructive purposes..?
shrug,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
MMetz:
CMD=v.build map=${VECT}@${MAPSET}
- g.message $CMD
+ g.message message=$CMD
$CMD
done
MNeteler:
... is this a needed change?
...
Most are without this parameter...
Needed in this case because the string contains a '=', which
confuses the parser.
Hamish
ps
,
this might be done by linking to the row in the table for the
command on the main page. or maybe adjusting the macro to point
to the sub-page is easier than creating the dynamic table?
ideas? comments? solutions?
thanks,
Hamish
___
grass-dev mailing list
Hamish wrote:
I've got a 3D raster with a very skewed distribution.
For viewing the slices (r3.to.rast) I'd like to use a
single set of color rules for all of the z-levels.
So I'd like to run the ever-amazing 'r.colors -e' to
equalize over the full distribution, but how to do
that for all
for that could be overkill.
btw, I believe the AV responsible for parts of the G3D code is Alfonso Vitti.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
of r.in.wms
in grass7 source code is not as complicated?
best,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
in it.. well, I could go on but the point is that now as a result I am
uber-cautious about what goes into the stable branch, that's all. (Some
push-back from me being too cautious sometimes is healthy of course :)
Hamish
___
grass-dev mailing list
grass-dev
401 - 500 of 1486 matches
Mail list logo
