announcement!
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
(but this time in areas with slightly better internet access
than from the fjord I was in last week!). So don't expect much non-SoC
traffic from me for a little while yet, but I'll do my best to be
responsive on SoC issues. :)
cheers,
Hamish
ps- willing but as-yet unregistered mentors should see
be preferred for a local end-user
pre-packaged copy?
advantages? disadvantages?
thanks for any suggestion,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
from the command line?
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Author: hamish
Date: 2012-02-19 18:49:59 -0800 (Sun, 19 Feb 2012)
New Revision: 50892
Modified:
grass-web/trunk/grass64/main.inc
Log:
prep for 6.4.2
I have all prepared locally, just not submitted to expect the
binaries..
The plan is (err was!) to submit
'nuff said
H
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
files dir enviro variable and redirect all to
clones in $GISBASE/erc/...
also please be careful not to distribute any license problematic
redistributable dlls on the official osgeo servers embedded
within gpl installers.
cheers,
Hamish
___
grass-dev
is not in the config file
but does have a ../man or man subdirectory
/usr/local/src/grass/svn/grass65/dist.i686-pc-linux-gnu/man is already in the
manpath
...
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman
around 'export PATH' in Init.sh somehow [6.5svn])
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
for sie,se sin,sn and lambda_i,lambda option key names in trunk)
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
check the link in the
interim just after tagging while we wait for the source to propagate to
the mirrors and the binaries to be built.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Helena wrote:
Hamish, do you know whether there is anything that needs to be done
from our side to help OSGeo become participating organization
or is somebody working on the application already?
Org applications are due in about two weeks
and I haven't seen much happening on OSGeo lists
nature of grass might make it more suitable
for custom do-one-thing-well digital field notebook/data entry apps.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Helena wrote:
I read all of the documents listed below and they look
good, I don't see anything that needs to be changed,
Martin:
same here. Thanks for preparing these materials.
cheers, and thanks too to Michael for doing the copy editing.
Hamish
: (??)
* i.atcorr - Add support for VGT1_spot4, VGT2_spot5 sensors
thanks a bunch,
Hamish
ps- it would be great to add screenshots of the new GUI tools to
http://grass.osgeo.org/screenshots/gui.php
I see the graphical modeler has nice one in its help page already which
could be reused
to be sent to a link to download
it now? and let the user do the rest?
cheers,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
and MATLAB).
any reason not to use r.in.mat, r.out.mat for that? i.e. any short-
comings in those tools which should be addressed?
regards,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
pointed to r.example and v.example here:
http://grass.osgeo.org/wiki/GRASS_Programming_Howto#Raster_Modules
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
there is still lots
of room for improvement.
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Hamish wrote:
I have not read through the 1300 changelog entries
since 6.4.1
(oops, 1300 changes since 6.4.0; 750 since 6.4.1)
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
to.
was it only ever in tcl/tk gis.m?
(the r.colors frontend looks good in wxGUI)
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
-
time. (qgis might have to have some logic to guard
against ambiguous duplicates in that case though)
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
manifest files should be skipped, hopefully fixed in r50626.
just wondering about a more general solution; what happens if you search
for the executable bit when run from Windows, where such a distinction may
not exist?
if (access(filepath, X_OK) == 0) {
G_message(is exe);
}
?,
Hamish
it necessary. All code for dbmscap
* file is commented here.
*
* Instead of in dbmscap file db_read_dbmscap() searches
* for available dbmi drivers in $(GISBASE)/driver/db/ */
...
/* START OF OLD CODE FOR dbmscap FILE - NOT USED, BUT KEEP IT FOR FUTURE */
#if 0
...
Hamish
it.
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
gui_modules
}}}
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
,area.
note the boundaries themselves are not acted upon,
and v.centroids is a simple wrapper around
v.category option=add type=area
label=Add missing centroids to closed
boundaries
might be expanded with ... to create areas
Hamish
___
grass-dev
to boundaries
with v.type.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
vector/MAP/head (if present): todo. (I'm out of time)
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
. If not, how did
you create that location? Was it created as x,y then changed
to UTM by some manual method?
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
don't think a .prj file with v.pack is enough to catch all cases, or
robust enough. the mis-copy could just as well be a manual filesystem copy
as a v.pack transportation)
Hamish
ps- FWIW, r.pack and r.unpack, and v.pack and v.unpack, should share
the same source dirs. I am unhappy that r.[un
].
they are there for a (very good) reason.
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
/abstract_grass641.txt
usually I'd help with that but I'm just heading off
to sea for a while.
(+ extended errata for things like r.nulls on wingrass if that doesn't get
fixed in time)
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http
, and/or
imagemagick build dependencies for GRASS just for this.
thus I think the frequency is too low and the file
bloat is too small to worry about the extra effort.
(plus a little bit of paint program editing at the
pixel level might be needed if things didn't scale well)
Hamish
?
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Hamish ha scritto:
It seems from that bug report that you are building
against grass trunk?
Paolo wrote:
not: 6.4.1
sorry, I saw in http://hub.qgis.org/issues/4667
references to:
r.external.all.py
v.out.ogr.pg.py
qgis.v.kernel.rast.py
db.connect-login.pg.py
and just saw the 'trunk
Hamish:
my thinking was that many grass devs probably can not keep up with the
qgis-dev mailing list traffic, and many qgis devs probably can not keep
up with the grass-dev ML traffic. so if there was a low volume ML for
interested parties from both dev teams it would be easier to keep up
those work, but see also g.extension does not work on a Mac
https://trac.osgeo.org/grass/ticket/854
since so much has changed since then I think we need to have the
Mac extension build+install re-tested as if it were new.
thanks,
Hamish
___
grass-dev
Hamish wrote:
v.transects.py doesn't install correctly for me on linux either using
g.extension.sh, but I didn't really expect it to since it's
a python script not a shell script,
actually it was not a Makefile problem, it was a g.extension.sh problem,
hopefully now fixed in svn. ISTR
. all grass6 help page examples have been
changed to make them version neutral.
the wxgui command line may or may not care too.. worth
a try.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
have your article
published, then you would have to wait to put it in the grass addons repo
too, which is open to GPL-compatible code only. (as per rfc2)
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo
Martin wrote:
6.4.2RC3 also available in OSGeo4W framework,
testing welcomed.
does that ship the proj 4.7.0 release, or 4.7.1svn with
its location wizard-breaking epsg file?
(see https://trac.osgeo.org/grass/ticket/1452)
Hamish
___
grass-dev
the time the wx wizard was
written? I know the todo was discussed.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
away from
the need to restart GRASS for it to take effect (ie update $PATH).
fwiw it doesn't have to be a one or the other thing, although that does
get a bit messy. and since it's fundamentally an environment variable
(ie $PATH) which needs to be modified ...
Hamish
process
can't hijack the settings of another one. If you
had started the gui from that terminal with g.gui
I expect it could have worked. but you can't adjust
an already running process from another one.
Hamish:
you need to set it before starting GRASS in
order for it to get picked up
wingrass? maybe it is an osgeo4w packaging
thing??
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
to rearrange init.sh to add some conditional magic into
$MAPSET/.bashrc so a value in ~/.grass.bashrc would be added to the
shell's $PATH, but it is invasive enough that I would not like to touch
it before 6.4.2. Also you'd have to do the same for csh and MinGW/other
shells.
Hamish
Sören wrote:
The GRASS ATLAS wrapper is and example for such
an approach. ATLAS can be used, but in case it
is not installed, the default GRASS implementation
is used.
Hamish:
Oh, I did not know that was there. We can work on
adding it to trunk's ./configure next.
Sören:
We can do
Hamish wrote:
ps- does any one know if the equivalent of the
jobs and wait shell commands exist for
launching modules from python?
Michael:
I know that an equivalent of wait exists. I don't know
about jobs, but the answer is probably. We've experimented
with this some on the HPC here
Hamish:
btw, my current feeling about the
~/.grass$MAJOR/addons$MAJOR.$MINOR.$BUGVER
specific path to protect from binary GIS_H incompatibility is that it
may be better to create a ~/.grass65/ in addition to ~/.grass64 to keep
the two separate.
Martin wrote:
do you mean also
are supposed to know what they are doing,
i.e. reinstall any addon after every `svn up`.
...
Apparently this issue is far from resolved, therefore I
would opt for releasing rc3 asap and fix that in 6.4.3.
fine with me..
Hamish
___
grass-dev mailing list
for not dropping the wxPy version from 6.x
There was discussion about replacing g.extension (bash script) by
Python version in GRASS 6. Hamish was strictly against that.
And I very much still am. The question is more for the python version
to justify its inclusion in 6.x; the bourne script one
fails too.
OpenGL system vs NVIZ/OGSF compiled in OpenGL system?
the same setup was working fine for me until now, not sure what changed.
export LIBGL_ALWAYS_INDIRECT=1 nviz ?
yes, that fixes it, (glxgears too)
thanks,
Hamish
___
grass-dev mailing
to export the LD_LIBRARY_PATH= environment variable
at run time to add the lib dir into the library search path temporarily.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
inherit exported vars from their parent.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
cleaner as the main (only?) ABI conflict is developers going back
and forth between 6.4 and 6.5.
what do you think?
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
reference to `G__gisinit(char const*, char const*)'
Hamish wrote:
how does the Makefile look?
?
maybe add the grass lib dir to your /etc/ld.so.conf file, then
as root run ldconfig. then the grass libs will be in the library
search path.
please try that.
as root:
echo /usr/lib/grass64/lib
is obviously
right or wrong.
and what about the abandoned DB entries for each non-chosen cat? it is
impossible to merge them into a single record, although maybe creating
multiple layers could be a way around that?
Hamish
___
grass-dev mailing list
to have your preferences carry through,
but will those wx files stay forward+backward compatible for all .grass6/
and .grass7/ ?
2c,
Hamish
ps- outstanding question: should sudo/system wide installs of addons
done with g.extension.py be allowed to delete files from the main
$GISBASE base
is added to the environment.. it's
there if you want to use it, and not if you don't.
that does not preclude the wxGUI having a Preference setting
to add some dirs to the copy of the $PATH it maintains, starting
with any existing GRASS_ADDON_PATH enviro variable that was
there when it launched.
Hamish
Hamish wrote:
it doesn't work to put GRASS_ADDON_PATH into .grass.bashrc,
you need to export it from your ~/.bashrc or ~/.profile.
(and it is too invasive to start appending to those automatically)
Martin:
hm, and what's the purpose or `.grass.bashrc` I thought it should be a
place
:
http://osxdaily.com/2011/07/22/access-user-library-folder-in-os-x-lion/
afaik the system-wide /Library is still world visible.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
them, no need to do that manually AFAIK. (I don't know
if that is also true for etc/ ?) or was this causing problems??
cheers,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
)
did you use type=centroid to select areas?
(the centroid holds the area's attribute info)
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
of the cleaned original?
v.extract cat=1- might help too.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
do any more damage,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
be needed,
but I suspect we'd have the same people testing as who would for
6.5svn, so a rc3 might get a wider audience. shrug
(Also I would s/GRASS_ADDON_PATH/GRASS_ADDON_BASE/ in trunk)
best,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
to r.out.tiff.
to preserve full colors you'll want to use r.out.png, r.out.tiff
or r.out.ppm, not r.out.gdal (which focuses on exporting data
correctly, as opposed to only caring about the visual image).
Hamish
___
grass-dev mailing list
grass-dev
Hi,
Author: hamish
Date: 2011-12-04 16:05:50 -0800 (Sun, 04 Dec 2011)
New Revision: 49533
Modified:
grass/branches/develbranch_6/gui/scripts/g.extension.py
Log:
avoid unnecessary build clutter in private installs
(see #1501, sync with r49527);
only create build dirs
Hamish:
* wxGUI extension removal:
I don't think it is very wise to rely on a volatile
generated file on a remote server to decide which files to
delete on my local machine.
...
Was there some win32 reason to do that, or..?
Martin:
The main reason is that some of the modules install
(tokens);
continue;
}
so points falling exactly on the upper bound of the range are considered
only once, and belong to the horizontal slice above the current one.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org
the r3.in.xyz wrapper script,
no modifications to r.in.xyz are needed.
let me know if it works(!), and what sort of 3D interpolation could be
used to fill in the voids between the stars if a too-fine resolution
was used. (export to 3D vector then v.vol.rst?)
Hamish
Hamish:
wrt r.walk: I would think to start with parallelizing r.cost, then
porting the method over to r.walk. Both modules use the segment
library, so coding it to process each segment in its own thread
seems like the way to do that.
[I have since studied r.cost and the segment library
of their self-authored scripts in there? If that
must stay for some reason, there should at least be a Are you really sure
you want to do this? dialog, as non-accidentally deleting users' personal
scripts will not be good for business.
thanks,
Hamish
___
grass-dev
Hamish:
wrt v.surf.rst, I've been playing with its lib/gmath/lu.c LU
decomposition function. can anyone figure a way to get the
following to work?
[...]
Sören wrote:
Hamish, please do not optimize the LU code as it should be removed (NR
licence issue). Have a look at the other direct
parts.
fwiw I don't really consider parallelization to be optimizing anything,
rather just a way to throw more brute force at the problem.
Attachment FYI
very impressive. the v.surf.icw addon script thanks you.
Hamish
___
grass-dev mailing list
the website without making it into the
wiki [fixed])
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
exploring)
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
a AC_OPENMP macro, but don't
know if that applies to version 2.13. I'm guessing
that it doesn't.
http://www.gnu.org/software/autoconf/manual/html_node/Generic-Compiler-Characteristics.html#Generic-Compiler-Characteristics
Hamish
___
grass-dev mailing list
down on
big jobs. running all segments at once negates that
advantage. (but of course you can limit the number
of threads launched at run time using environment
variables if that is a problem)
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
is that sh.exe ignores PATHEXT, right?
I'm pretty sure that is correct, PATHEXT is only
recognized by DOS cmd.exe
if sh.exe (bash) does too it will only be because
the MinGW folks have added custom support for it.
but I would guess that they won't have done that.
Hamish
the hogs I've just added a
section to the wiki about profiling python scripts:
http://grass.osgeo.org/wiki/GRASS_Debugging#Profiling_python_scripts
which just points you to this page:
http://docs.python.org/library/profile.html
Hamish
___
grass-dev
to perhaps justify it,
but for Windows.. not so much.
2c,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Author: hamish
Date: 2011-12-02 02:38:18 -0800 (Fri, 02 Dec 2011)
New Revision: 49486
Added:
grass-addons/grass6/raster
Log:
test to see how well trac deals with symlinks. should appear in unix as
a symlink, on MS
Windows as a regular file
Martin:
I think that it would
/flattening overlapping areas is not appropriate.
for things like neighboring land parcels, political lines, or
land/sea boundaries non-topological is a nightmare, but for
other tasks it can occasionally be very useful.
Hamish
___
grass-dev mailing list
the range of angle values once
0 and 180 have been taken out.
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
, there is/was the
r.cva module for cumulative viewshed analysis. Unfortunately (AFAIU) the
author could never convince the university he worked for to allow him
to release the code for that as GPL.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http
Markus Neteler wrote:
how about replacing r.los with r.viewshed?
needs fixing:
grass65/dist.i686-pc-linux-gnu/include/grass/iostream/replacementHeapBlock.h:146:
warning: 'str' may be used uninitialized in this function
(3 times).
Hamish
___
grass
without error. (58 sec for full compile!)
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
is the most
appropriate to obtain/pipe the percentage from the command... given it
can be done?
try the GRASS_MESSAGE_FORMAT=gui environment variable.
see http://grass.osgeo.org/grass70/manuals/html70_user/variables.html#enviro
Hamish
___
grass-dev
in a disposable VM
which is wiped clean at the end of each session
after backing up the data.
(getting user level shell access from grass modules
would be very easy)
good luck,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org
:]]' was ok though.
On 1 another unrelated squeeze box I got the same
effect, but on a third I got the expected behaviour.
?! no aliases, md5sums of binaries match, case
sensitive searches of non-regex strings work.. weird
Hamish
___
grass-dev mailing
Hamish wrote:
strangely 'grep -r OPT_GIS_[a-z]' and egrep both
returned [A-Z] as well, and I had to save the result
to a file and do the search with vim.
'grep -r OPT_GIS_[[:lower:]]' was ok though.
On 1 another unrelated squeeze box I got the same
effect, but on a third I got the expected
Hamish:
I am looking to add OpenMP support to v.surf.bspline
...
Sören wrote:
Try r49406.
You need to separate the computation for j == 0 and j 0.
nice, thanks.
b) 3.5x speedup is very nice, but any way to improve
on that 40% efficiency loss?
The speedup is better as larger
Martin:
I would still incline to use `-g` for shell
script output as used in others modules.
I have counted more than 45 modules in trunk
which use `-g` for shell script style output.
Hamish:
huh? I don't understand what you are talking about.
Martin:
OK, sorry for wrong counting
in __iee754_log(). G_ludcmp() also looks like very low hanging
fruit. (great!)
h) is it possible /or desirable to use (aka outsource) pre-optimized
pre-threaded BLAS or LAPACK libraries for our linear algebra needs?
thanks,
Hamish
___
grass-dev
. These things
do not have to be mutually exclusive. But -g does
have to stay shell-script (ie eval) safe.
I don't see any reason why `r.info` or `v.info`
should be exceptions.
?! they aren't !?
If you want to see an exception, look at d.what.rast
-t terse output flag.
Hamish
could spend our finite energy
and time on..
through flexibility comes strength,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Hamish wrote:
perhaps for grass7, but 10 years worth of backwards
compatibility with the implementations in grass5 and
grass6 says otherwise for those.
I think perhaps I should say something about why GRASS_ADDON_PATH
came to be. This isn't THE history, but it is a history; you
were there I
301 - 400 of 1486 matches
Mail list logo
