> > 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
d is useful to some folks.
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
ble
*shift:n where n is the amount to shift the color table
*nv:r:g:b color to use 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 n
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
thank
dule help pages more, although the "module of the day" does
help with that and we have the GUI help + g.manual never 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
> >>
wiki page":
http://grass.osgeo.org/wiki/Special:Random
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
p's
question or not.
(GDAL's virtual-raster 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
g we can help
with? what's the problem you are stuck on? maybe someone here
has a bright idea to get past it.
cheers,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
uot;best placed labels" was the motivation for v.label.sa (one day
to be merged into v.label as a flag)
??,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
4.1, so only present
in development snapshot builds; db.out.ogr works in the last
official release.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
to sid
#apt-get update && apt-get upgrade
# at this point I usually copy + bzip2 the fresh image.
#ssh -p user@localhost
#scp -P file user@localhost:
hope it helps,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
> 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 `...`".
ld be a lot more 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@list
to add the spaces to make them 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
rt for other formats, 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 m
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
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
instead
of asking the Makefile to do it? hmm maybe not, there is still
just one set of *.o files)
I just have bad 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.
&
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-su
eats the
purpose, although I guess depending on gdal >= 2.0.0 would be
reasonable enough.
2c,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
up at the cost 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
___
le=`seq -s"," 5 10 95`
?
or is a linear 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
___
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@
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 messag
> > > > 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 p
place
-$CMD
+eval $CMD
Actually, I'm not really sure why that $CMD + g.message is needed
at all. Maybe 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
> >> > 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 variab
case because the string contains a '=', which
confuses the parser.
Hamish
ps- those curly brackets do nothing..
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
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
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
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
nvoluted) Maybe the python version 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
e to
do an emergency release due to some critical data-corruption or copyright bug.
just something to consider,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
orth of computations as the dev branch had a new+unnoticed bug
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
__
. (I suppose cycles are cheap these days
but it seems expensive to exhaustively check every single abbrev vs. all
other options' possible abbrevs. but I guess it is safer than leaving it
to the eye of the programmer)
shrug,
Hamish
ps- slightly off-topic, but I'd like to keep discussion
Hamish wrote:
> addon environ variable can have multiples, you need to spit
> on the first ":".
ugg, C:\ probably doesn't like that.
H
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
upon request. should we stay with that and/or is a specific install
target needed? (why is a python clone needed
there? to help with menu integration? is there a bug in wingrass
I don't know about?)
Hamish
___
grass-dev mailing list
gr
Hi,
wrt, but not limited to the test suite, see also wish #618 "rfe:
r.md5sum"
https://trac.osgeo.org/grass/ticket/618
maybe it is a useful tool to have in the mix.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists
e same seed. (currently only implemented for
r.mapcalc?)
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
a very very good reason.
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
semivariograms..
> I am most probably convert it to version 7
I guess the rows,cols,bytes per cell options could easily be
picked up automatically from the input map's header.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://
good luck lately with importing 10 years of QuikSCAT
observations and 6 years of US Navy & NARR met model historical
0-hour forecasts as GRIB files*. [*r.region needed to fix gdal
grid registration bug]
Hamish
___
grass-dev mailing list
grass-dev
is ready for non-developers to use, but I think I might be alone in working
that way and don't ask that anyone follows that method.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
). To keep it multi-platform, it is important to handle paths
> in windows and unix.
see the g.tempfile module, G_tempfile() C function, and grass.tempfile()
python function. -> $MAPSET/.tmp/
have fun,
Hamish
___
grass-dev mailing list
grass-dev@l
nts: a spatial index
> which would make spatial queries and selections much faster.
I believe that Howard & co. have been experimenting with different spatial
index methods for points in the development version of libLAS, with good
results. It's probably worth comparing notes about lessons
MMetz:
> > I discovered a bug in v.in.ascii: from a point file with |
> > as field separator like
> >
> > 1|2|3||5|6
> >
> > only the first 3 columns will be imported because column 4
> > is empty which means that columns 5 and 6 are skipped.
Hami
I take it that without topology it runs in just seconds?
my RAID runs at ~300mb/sec. 1.3m points isn't pushing memory
limits into swap space. there's no real tough math happening
here, just moving bits around... me thinks it's time to break
out the profiling tools. a
less now that qgis has
more plugins offering the functionality with less grass-layer weirdness
to deal with?
osgeo.org's drupal surely can do polls, but maybe wait until the recent
LDAP dust has settled there..
slashgeo.org is another more generic site with geo-poll
other information
> could be relevant.
Hi,
just as a debugging test, do you observe the same behaviour
in tcl/tk NVIZ? What you describe sounds somewhat familiar, the
rerendering in the tcltk version has always been a bit jumpy. I
try to sit perfectl
added to select signal strength, etc.
but I might overload the z= column parameter to accept strings for that(?).
(MBIO is for MB-System's multibeam sonar input library, Bob Covill already
has this integrated in a custom fork)
cheers,
Hamish
> _
y
to contribute my spare dev time to help someone else's profits.
..delicate balance.. the most valuable thing we have is the
goodwill of the community -the codebase would have been dead many
years ago without it- and we must protect that above all else.
2c shrug,
Hamish
___
Martin wrote:
> Hamish please could you backport ps.map's -b flag to
> relbr64? wx.psmap uses this flag.
sure. (but tomorrow as it's really late here)
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/
nst spaces in path names. "Double
quote" instead. Use ${} when you need to protect the variable
name from alphanumeric or _ (etc) which would be confused as part
of the variable name. ${} gets evaluated at the expansion stage,
not the command evaluation stage.
Hamish
___
Hamish:
> > finally we should consider what happens on Ubuntu and
> > possibly OSX where by default there is no root pw & sudo
> > is used;
William:
> I'm not sure what you mean. I've never had any
> problems running sudo, either directly in the terminal or
Hamish wrote:
> finally we should consider what happens on Ubuntu and possibly OSX where
> by default there is no root pw & sudo is used;
new -u flag added for that in 6.5svn r46259. haven't tested so didn't
backport to 6.4 yet.
> and if we should test for MSYS and issu
Hi,
Hamish wrote:
> note there is still a minor difference between g.extension(.sh)
> in 6.4.svn and 6.5.svn, the default install dir (prefix) is
> given as $GRASS_ADDON_PATH in 6.5 while $GISBASE in 6.4.
>
> For package-installs GISBASE is most probably readonly, so
> GRASS_A
already has a file there the
script needs to exit with an error instead of deleting their
prior work without asking.
https://trac.osgeo.org/grass/changeset/44325
cheers,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org
bage values:
r.mapcalc "invert = if(isnull(map), 1, null()"
r.grow in=invert out=invert_buf1
r.mapcalc "MASK = if(isnull(invert_buf1), 1, null()"
r.mapcalc "crop = map"
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
ASS_AddOns#d.barb
http://trac.osgeo.org/grass/browser/grass-addons/display/d.barb
screenshot: (style=arrow)
http://bambi.otago.ac.nz/hamish/grass/screenshots/narr-a_221_20100629_1800_000_10m_winds.png
maybe g.extension works to install it if you compiled grass yourself?
(I haven't tri
you ASAP if you have an opinion or are willing to help mentor any
of those.
best,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
ns). 5+ years from now when python 3 has taken
over, would grass6 still be able to run on a modern system?
[such as you could do today if you want access to grass5's
no-memory-overhead sites functionality] From a long-term
maintenance perspective ANSI-C and Bourne scripts take very
little effor
Hamish wrote:
> is there any reason not to exit with a fatal error if the user tries to
> run v.to.db option=azimuth from a lat/lon location? (the result is
> useless)
Also, in an ongoing effort to stop people shooting themselves in the foot,
I would suggest to add a warning to v.to.
, I would have it G_fatal_error() at the end of v.to.db's
parse_command_line().
?,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
instead.
Hi,
can you provide an example of for when it would be useful?
under what conditions is an error non-fatal?
i.e. when would it be preferable over simply using
G_important_message("ERROR: ...") ?
Hamish
___
grass-dev mailing li
will often be
what is used in the more relaxed settings of overhead-projector
presentations, the GUI, and web images, and so be more "human"
friendly than scientific writing tends to be.
2c,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
ODIS Swath Reprojection Tool for Level 1B or 2 data and can be used to
create a GeoTiff."
https://lpdaac.usgs.gov/lpdaac/tools/modis_reprojection_tool
https://lpdaac.usgs.gov/lpdaac/tools/modis_reprojection_tool_swath
Hamish
___
grass-dev maili
ules on more than ~3 GiB of data.
Although it's an obvious target, I didn't mention the segment library
in the parallelization suggestions as I seemed to recall the
disatisfaction with the current implimentation.
If would be cool if a replacement for the segment library could be
(re)bui
Radim wrote:
>>> If there are 10 maps open in QGIS, it starts 1 executables
>>> in about 1 second. That is probably a bit slow.
Hamish:
> > It can also take multiple input coords in a single call, so
> > you can at least queue you queries into bigger sized chunk
s in a single call, so you can at least
queue you queries into bigger sized chunks if you like, which
would ease the pain a little.
as a long term solution, would a from-scratch LGPL native GDAL
driver help? ... Possible Summer of Code project for someone?
Soeren wrote:
> I am really sorry for that, it was my fault. I made my
> changes within the wrong source directory and committed it.
no worries, it could happen to anyone..
regards,
Hamish
___
grass-dev mailing list
gra
s, but no one wants
to use it, g.extention is at its core fundamentally a hack (I say as a
coauthor), etc.--there's still a lot of maturing of ideas to do. The
wiki addons page is getting rather long, but we aren't on the scale of
needing something like CRAN yet..
- &q
d.
https://trac.osgeo.org/grass/changeset/45707
not sure of the best approach to wind that back.
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
g that a
lot of the DB stuff is already run as a separate process, so
some advantage of a multi-core system there.
I'd be interested to hear what non-IO bound modules people spend
a lot of time waiting for. Also if there are any memory-bound
bottlenecks around?
2c,
Hamish
___
-i -e 's+shlex.split+utils.split+g' \
-e 's+import shlex+import utils+g' *.py
all the power, much less mess!
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
e map.
yeah, I know that one (mea culpa). if there's not already a bug report
open for it please create one.
here's the code from ps/ps.map/map_info.c
/* draw the background box */
if (m_info.bgcolor != -999) { /* skip if "none" */
set_rgb_color(m_info.bgcol
.x86_64-unknown-
linux-gnu/etc/gui/wxpython/gui_modules/psmap.py", line 309,
in _showErrMsg
showTraceback = False)
TypeError
:
__init__() got an unexpected keyword argument
'showTraceback'
is that part of the threading problem listed o
fixed. And please to avoid wasted effort and bad
feelings all around, do drop me an email before any structural/
more-than-trivial changes to the backend.
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
> > Author: hamish
> > Date: 2011-03-23 05:18:35 -0700 (Wed, 23 Mar 2011)
> > New Revision: 45737
> >
> > Added:
> > grass/trunk/gui/images/silesia_splash.png
> > Log:
> > restore silesia_splash.png
> >
> > Copied: grass/trunk/gui/
Hamish:
> > ps- re. r45719 "winGRASS: include some gdal plugins", can you
> > confirm that these plugins are license compatible? (may have
> > been left out on purpose)
Martin:
> currently it's gdal-ecw and gdal-mrsid.
AFAIU those are supplied as plugins and
Martin wrote:
> > > $ grass70 -c /home/martin/grassdata/test1
> > > g.proj -p
> > > XY location (unprojected)
Hamish:
> create XY by default? I'm not so sure about that. I'd think
> it much better to exit with an error if location type could
> not b
gion bounds were using
the curses stuff AFAIR, but that's east enough to replace.
?
cheers,
Hamish
ps- re. r45719 "winGRASS: include some gdal plugins", can you
confirm that these plugins are license compatible? (may have been
left out on purpose)
than "import gis".
I'd assume most people have more than one GIS software installed,
and many GIS software do python these days, so would the change
lead to conflicts? or would it just be exposed internally?
Hamish
___
grass-dev
g as it does no harm let's
leave it there for now and only backport if needed / once we get
more info.
I think JEF or someone may have put it back into osgeo4w as a
favour to us.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http:
Helmut wrote:
> >I'm still getting an error in g.region:
> >
> >Errors in:
> >/c/osgeo4w/usr/src/grass6_devel/general/g.region
...
> printwindow.c:3:22: projects.h: No such file or directory
Hi,
try temporary solution in 6.5svn r45469.
see also http://trac.o
Helmut wrote:
> >> i can confirm this with your recent changes in svn
> >> with r45429 etc. for grass6-develbranch.
Hamish:
> > fwiw, that needs to be reverted, then audited and real fixes
> > committed piecemeal. it's a collection of private patches and
> &
.org/osgeo4w/ticket/34
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Markus N wrote:
> I wonder if v.generalize should work in LatLong? I tried to use the
> displacement but the result is identical. Maybe a map unit (threshold
> given in meters but currently considered in map units = degree?).
did you run v.build.polylines first?
7;t working.
??
WRT g.region's use of proj4-dev's projects.h, I'm responsible for adding
that to the code so I'll comment within the ticket and on the osgeo4w bug
for that which I wasn't previously aware of (or had forgotten about if
that be the case).
Hamish
Hamish wrote:
> fprintf(PS.fp, "B F BW stroke\n");
>
> I assume I've got to modify the "B F BW" before the stroke,
> but not sure what to, and can't find any decent reference for
> it on a search of the 'net.
> I could figure out that &quo
decent reference for it on a search
of the 'net.
I could figure out that "F" means to fill the box.
?
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
> find out how to size the legend.
is the "at: bottom,top,left,right" text not showing up above the
wxPy module GUI's at= entry box, as it does in the tcltk module
GUI? I thought Martin had implemented that recently.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
nored if < 0;")
"chdangle;" _("change the type of boundary dangle to line, "
"threshold ignored if < 0, input line type is ignored;")
...
in the code?
?,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
last year on the proj4 mailing list).
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Martin:
> >> If so, why don't change some "standard" or "conventions" in
> >> GRASS7? ;-)
Hamish:
> > because there's nothing really wrong with the old way?
> > If there seem to many buttons in the GUI for a module,
> > maybe the GU
ls later on. (this paragraph was not awkward on purpose, just regular
awkward :)
as per usual, patches welcome from all; those with commit access are
responsible for committing, and they are personally responsible for
reviewing and signing off on anything and everything the
re allows shell scripts to create new data base files
as well as use existing ones.
"""
(g.findfile cares if it exists, returns "" for answers if not)
perhaps in trunk its functionality could be covered by g.findfile + a new
flag?
Hamish
__
case we might think more about modifying this one or adding a new
module/script/python.tool to deal with g.findmap (script to see if g.mlist
regex=^mapname$ returns an answer?).
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http:/
Hamish:
> > re. https://trac.osgeo.org/grass/changeset/45050
...
> > what's the justification for introducing non-standard
> > behavior into v.info?
Martin:
> are you referring to GRASS6?
both 6 and 7.
> If so, why don't change some "standard" or &qu
rstanding why file= would ever be passed a
qualified name in the first place? so why is the change needed?
perhaps it is the file= option's description which is the
misleading thing? .. a hold over from grass <=5 when vector bits
were also at the mapse
when the correct usage is
like [/path/to/]filename.ext.
https://trac.osgeo.org/grass/changeset/44339/grass/branches/releasebranch_6_4/lib/gis/parser.c
hoping for improved discussion,
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.
501 - 600 of 1773 matches
Mail list logo
