Martin:
I would not say that GRASS 6 supports wxPython 2.9. Please note
that 2.9 is dev version!
added to known issues,
https://trac.osgeo.org/grass/wiki/Release/6.4.3RC4-News#Knownissues
go go go,
Hamish
___
grass-dev mailing list
grass-dev
Markus Metz:
AFAIK, BLAS and LAPACK are not used.
have a look at lib/gmath/
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Yann wrote:
in preparation of the grass code sprint in Prague,
I would like to gather planetary applications.
So far I have:
1 - Isis2grass (ellipsoid table already ported by Hamish, g.isis3mt to
add to trunk, CLI integration to do)
2 - started to write r.crater, will try to finish
maintain its own environment so it's own region
override enviro variables. or simply unset the wxGUI display overrides
and just use the mapset's real computational region read directly from
the WIND file?
regards,
Hamish
___
grass-dev mailing list
grass
different
than r.example)
r.stats also will calculate values from multiple rasters,
along with xy coordinates in one pass. These are a couple
of the reasons I used r.stat to collect data on rasters.
see also r.out.xyz for a r.stats wrapper/front end for xy coord
output.
Hamish
.
Anyone who can confirm?
sounds related: https://trac.osgeo.org/grass/ticket/2012
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
to add .decode('utf8') somewhere?
http://washort.twistedmatrix.com/2010/11/unicode-in-python-and-how-to-prevent-it.html
thanks,
Hamish
I wrote:
Also, I'm seeing a unicode error vs. layer Title string in the
6.4.3svn's
r.in.wms1's wxGUI wrapper. It's not to do with r.in.wms2.py, so
in trunk.
Traceback (most recent call last):
File /home/hamish/src/grass/svn/grass65/dist.x86_64
-unknown-linux-gnu/etc/wxpython/modules/ogc_services.py,
line 216, in OnConnect
self.list.LoadData(layers)
File /home/hamish/src/grass/svn/grass65/dist.x86_64
-unknown-linux-gnu/etc/wxpython/modules
?), but the funny thing is that for MS Windows the
opposite is true, only GPU support for the i7 chip not Xeon. Performance is
probably not so great for the Ivy Bridge chips, but it's good as an
already-there learning platform.
thanks,
Hamish
___
grass-dev
universities around the world have a
hard time seeing very far past the $ signs for anything and everything.
:-/
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Nikos
Wouldn't a dedicated import script for Landsat products be useful? Like
r.in.aster for example -- though, maybe it would be better called
i.landsat.import?
see also r.in.modis
I think r.in.* is the correct pattern to follow.
regards,
Hamish
to
understand (?)
perhaps - r.stats.cover and r.stats.quantile?
we should also add r.stats (and perhaps r.univar) into this discussion.
r.stats - r.stats.summary ?
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman
Hamish wrote:
anything else to add?
MarkusN:
It is not clear to me (lost in too many emails):
- if g.extension is sufficiently ok now
AFAIK, yes. On Mac OSX Michael reported some success for grass6,
but problems remain with grass7.
- if Python scripts run on Windows
which ones? addons
.
If it is not fixable it should be at least mentioned on the
known issues web page
http://grasswiki.osgeo.org/wiki/WinGRASS_Current_Status#Raster_modules
right, a ticket to refer back to would be good though.
Hamish
___
grass-dev mailing list
grass-dev
I've worked through the changelog and the 6.4.3rc4 release summary page seems
in order now,
https://trac.osgeo.org/grass/wiki/Release/6.4.3RC4-News
anything else to add?
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http
/r.colors/thumbnails
(d.colortable called using the PNG driver there)
see also
https://trac.osgeo.org/grass/ticket/2009#comment:5
http://grasswiki.osgeo.org/wiki/Color_tables
http://grasswiki.osgeo.org/wiki/Talk:Color_tables
and grey.log, grey.eq and random thumbnails still need some work.
Hamish
array size gets limited
by the GPU memory limit.
Are the dependencies only the OpenCL headers and the libcl or something
more?
I think that's it, but I'm still learning.
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http
it
easier to experiement with.
regards,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
something more than just set
EXTRA_INC = $(PROJINC) $(OCLINCPATH)
in r.sun's Makefile.
re. the libs, see also the needed? comment in the Makefile. Maybe
one of those need to be enabled.
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
that was falling down in the valley. :)
regards,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
grass.start_command() and raster.mapcalc_start()
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
)
ret = p.communicate()[0]
regards,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
, mipsel, powerpc, powerpcspe, s390, sh4, and sparc.
regards,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
scripts there are all written in Bourne shell we
should still support it for users' personal scripts and
interoperability between versions.
regards,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass
Hamish:
g.gui.rlisetup.py naming
Luca wrote:
For the name I think it is more consistent with the other
grass7 GUI modules
I was questioning that naming convention for all
the grass7 gui modules, not g.gui.rlisetup.py in
particular.
Since they launch and run fine from the command line
it before too long.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
but-compatible fork, and hopefully these
troubles become less.
And yes, for the grass7 code just leave off --with-ffmpeg
since it isn't used in the wxNVIZ currently/yet.
regards,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
= Greenwich,
but that may just be left off as matching the default.
I'll have a look at the code... perhaps due to a glitch in the last commit
there.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Hamish:
hmmm, I tested that a couple weeks ago and it was working, but now it
doesn't work for me
nope, there is only code for generating the +proj4 terms in the Summary page
for epsg and custom +proj terms (incl. defined from the table).
(location_wizard.py line ~ 1659)
from geofile, wkt
in
this scope
fwiw as a pre-release test I built the 6.4.3svn Debian
package yesterday in Debian/sid (wx2.8), it was all ok.
I'll try in a ubuntu 13.04 vm..
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo
on the
desktop icon, at the C:\ prompt do a little cut and paste to
cd into the startup dir, then cut and paste the target startup
command.
then when it fails you get a chance to see the error without the
window disappearing.
Hamish
___
grass-dev
Martin
these headers should be checked by configuration script I would say.
afaik they (generally) are, it's just that the functions keep on
getting renamed and jumping between libs, so it's a moving target,
and it's a bit much to do a test compile for every function call
used.
regards,
Hamish
d.barscale is the first of the display modules, did the db/ modules build ok
before that? or were the display modules the
first ones to try to be built?
Hamish
Seth wrote:
If I compile the latest GRASS v7,
'make' gets to a point in the compile
and stops indefinitely. Does this happen
the door
asap and keep an improved r.li as a goal for 6.4.4. I looked at the
list of r.li bugs in the trac system earlier, it is in need of some
care. AFAICT it's nothing fatal, just many small fixes to work through.
regards,
Hamish
___
grass-dev mailing
Hamish:
grass/trunk/demolocation/PERMANENT/PROJ_INFO
Log:
no defaults not needed here. (see /usr/share/proj/proj_def.dat)
MarkusN:
... then our mechanism to generate EPSG 4326 is suboptimal
yes, that is known since 'g.proj -c' first arrived; grass's
datum and projection support is better
Markus N wrote:
the RC4 will be released on Thursday, June 20th...
so we move on!
Hamish:
why not tag it today?
MarkusN:
You had a few things you wanted to get in before given your
previous emails...
AFAIK that's all solved or postponed now, we're ready to go.
(and I am busy
Hamish wrote:
in the case of the demolocation PROJ_INFO file I think
it's enough to just craft it by hand to make it as it should
be.
MarkusN:
Well, then this should be followed by a test if v.unpack
works with it. All problems arose while trying to transfer
a country map (from
:
...
perhaps we could drop some of the the hardly-used columns and
make it even smaller?
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
.
what's the status of using ctypes in grass7 to access libgis
and the other C libraries? can it be relied on for core needs?
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Hamish wrote:
status update time,
no blockers, critical bugs triaged, AFAICT we're good to go.
the main two remaining from my perspective are GRASS_PYTHON
in env.bat
For wingrass GRASS_PYTHON in env.bat is now set in all branches
to C:\Program Files\GRASS\etc\extrabin\python.exe
Yann wrote:
GRASS g.region -p after setting up a location from that
shapefile
the important result to see is that of 'g.proj -p'. (i.e. the
PROJ_INFO file)
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org
t.vect.mapcalc.
seeing that it seems to share much with r.mapcalc, it would
be good to document on the wiki/help pages where its syntax
diverges from r.mapcalc, and document in the code which design
decisions were inherited directly from r.mapcalc.
thanks and have fun,
Hamish
announcements and make sure all
the packing scripts still work in the next week or two while
that is being tested, and then get the final release out by the
end of the month, hopefully without much in the way of changes.
?
thanks,
Hamish
___
grass-dev
it with a log()/log() trick, but would
pow() and log10() also be broken?
??
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
' was here
gmake: *** [OBJ.powerpc-ibm-aix7.1.0.0/vect.o] Error 1
As workaround, renaming of nearest would likely do it as
in:
http://trac.osgeo.org/grass/changeset/55563/grass/trunk/lib/gis/plot.c
done in trunk r56661.
Hamish
Hamish
___
grass-dev
10px to 5px (even better if it could deal with diff't
screen DPIs)
Hamish
ps- background (etopo1) is a bit crude as r.in.onearth stopped
working again/JPL changed their tiled WMS again?
pps- er, the vector query tool defaults to edit mode?attachment
Author: hamish
Date: 2013-06-05 19:09:55 -0700 (Wed, 05 Jun 2013)
New Revision: 56622
Modified: grass/branches/develbranch_6/mswindows/env.bat
Log:
default to explictly using GRASS's bundled python.exe
to avoid startup breakage
Markus N wrote:
let's backport to relbranch64
; now it basically is and we can move on.
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
6.4.4 as soon
as that's ready.
#: go through changelog for new and fix bullet points, add to trac wiki page
#: write the 6.4.3 release announcement and press release
todo.
regards,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http
location?
(or use gdalwarp as appropriate)
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
to all, we were spoilt for choice this year, all
student submissions were good and worth considering.
best,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
for more community engaement. that
doesn't really apply to Stepan, more to help welcome in/integrate
those new to the project.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
;
the idea (and challenge) of g.extension is that it just works.
If you are going to do your own thing, installing shell and
python scripts is just a matter of putting the downloaded file in
the right place, no need for anything fancy.
regards,
Hamish
Hamish wrote:
the main thing remaining IMO is to get the location wizard
working correctly with proj 4.8.0. (the datum transform opts
were getting reset to the new proj4 defaults regardless of
what you selected)
...
changes now ported to all branches.
MarkusN wrote:
Good - no break
notes this one is a bit too complicated for official backport
consideration, but people can do what they like at home.
regards,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
-addons/tools/svngrep script to help avoid
some false positives in doing the recursive greps.
Hamish
ps- Martin, any comment on #1971? thanks
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
/source/SUBMITTING
and think that I'm ready to submit the code. What's the next
step?
Hi Brian,
see
https://trac.osgeo.org/grass/wiki/HowToContribute#WriteaccesstotheGRASS-Addons-SVNrepository
regards,
Hamish
___
grass-dev mailing list
grass-dev
time for the weekend update,
Hamish wrote:
fwiw, my to-fix list is now shorter, the main thing remaining
IMO is to get the location wizard working correctly with proj
4.8.0. (the datum transform opts were getting reset to the new
proj4 defaults regardless of what you selected) There are so
Yann wrote:
Using the new location button in the wxgui, this happens
as soon as you press the button? or do you enter some values
first? is 'ellipse.table.solar.system' being installed in
$GISBASE/etc/proj/ ?
(it works for me running out of src/dist.x86*/)
Hamish
Traceback (most recent
do it with a pipe through 'grep -v',
NULL=9.99
grep -vw $NULL infile.csv | v.in.ascii ...
and try to make the regex in the grep search as explicit as
possible to avoid false positives.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
9998 might be fastest of all.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Yann wrote:
/usr/local/grass-7.0.svn/etc/gui/wxpython/location_wizard/wizard.py,
line 2008, in __readData
ellipse, rest = line.split( , 1)
ValueError: need more than 1 value to unpack
(for the archives, this was a local debug edit conflict, svn copy
was ok all along)
Hamish
, so it would be good to have an idea of
what (if anything) you'd be available for.
thanks a bunch happy travels,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
.
wxGUI/wxPython experts, 3D-4D experts, satellite/PCA experts,
this means you! :-)
It's still unknown how many slots we end up with, but what ever
that ends up being I think it will be another great summer.
thanks,
Hamish
___
grass-dev mailing list
grass
) for datum transforms
/ -- traceback error (fixed?)
#1967: wxPy loc'n wiz: doesn't allow ellipsoid without datum
best,
Hamish
ps- trac load seems to have gotten worse, often get a can't even connect to the
server now.
___
grass-dev mailing list
grass
datum code
-
The python code is incomplete, I need some help to finish it.
see https://trac.osgeo.org/grass/ticket/1513#comment:3
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo
Moritz wrote:
Comment(by hamish):
(argh.. trac logouts continue..)
I only get them when I connect via http (due to issues with
our proxy server constantly changing the IP visible to
trac), but not when connected via https.
well at least it isn't just me. :) I seem to get it some times
://trac.osgeo.org/grass/report/16
all wingrass bugs: https://trac.osgeo.org/grass/report/14
all wxgui bugs:https://trac.osgeo.org/grass/report/15
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass
~10
bug reports to look at)
So please pick your favorite component/area of expertise and
have a look to make sure something wasn't forgotten. :)
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo
had support in the GRASS raster engine for a number of years.
see also http://grasswiki.osgeo.org/wiki/Planetary_mapping
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
?) path for
people who want to do Mapnik rendering of GRASS data.
happy to see lots of rendering options to fill the many niches,
and glad to see all this get more attention,
Hamish
ps- if you haven't already tried out TileMill, give it a look..
___
grass
it
wasn't designed for because of some deficiency in the other.
regards,
Hamish
ps- you will find an alternalte ps.* vector legend design in
the ps.output addon module.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman
Hamish:
-#% description: Allows to join a table to a vector map table.
+#% description: Joins a database table to a vector map table.
MarkusN wrote:
-- please don't break the translations if not really needed!
it's bad English to leave out the pronoun, also it was written
a bit too much
Hamish:
is the i18n maintenance something that could be scripted to
make it be less work?
MarkusN:
If you have a cmd line software to translate messages, yes :)
The rest is already scripted except for the human work to
actually translate to PL, DE, IT, JA, etc.
You really shouldn't
Hi,
just a small adjustment to wingrass-
etc/env.bat adds %GISBASE%/gpsbabel to the %PATH%, the dir
exists but it is empty and GPSBabel.exe is in %GISBASE%/extrabin/.
ok to remove the empty dir and from the PATH too, leaving the .exe
in extrabin?
Hamish
of it.
for another thread: how to annotate that the div class=code
EXAMPLES which use Bourne shell loops and line continuations\
require special care to be used in wingrasses or the wxGUI
command line? I don't think just getting rid of them all is
a good solution.
Hamish
[re. what to backport to 6.4.svn]
Hamish wrote:
A number or nviz diffs exist too, maybe should be looked at
at some point by the authors. (seems to be Tcl 8.6 api updates,
+)
There are changes in nviz too, but I think this is the one that
caught my eye: (lib/form/form.c)
https
Hamish wrote:
kompare/kdiff3/meld were all a bit annoying to set up with
regex filters to avoid $Date$, OBJ.*, .svn/, dist.*, etc.,
I should write down some notes in the wiki while it's still
fresh in my mind, but it's too late for today.
-- https://trac.osgeo.org/grass/wiki/HowToBackport
Hamish:
Log:
run 'optipng -o5' to compress (merge from devbr6)
Markus Neteler wrote:
How about abusing grass-addons/tools/module_svn_propset.sh
for this job to not forget about it every time?
If you like, but it would have to run every time, which can take
many minutes for large runs
Markus N wrote:
... since Hamish currently backports more from dev6, I'll
postpone RC3 for some hours or whatever suitable.
thanks, I'm done for now, but there's one outstanding difference
between relbr64 and devbr6 for r.watershed that MarkusM might
have a look at (see below). I mostly focused
what it is refering to. Which is
tricky to get right, but not an impossible task.
(I've no great suggestions)
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Markus N wrote:
If there are no objections, I can try to prepare RC3 by
tomorrow.
yes please. :)
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
import filter,
just that be careful to avoid automatically fixing data for
cases that don't ask for it / happen to look bad but are
actually not.
can you provide an example of what the numbers you are seeing
look like?
Hamish
___
grass-dev mailing list
-devs way?
note also discussion about this in the g.version ticket on trac.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
the coding part of the program runs
from June 17 - September 23.
http://wiki.osgeo.org/wiki/Google_Summer_of_Code_2013_Administrative#How_to_register_as_a_mentor
http://wiki.osgeo.org/wiki/Google_Summer_of_Code_2013
http://grasswiki.osgeo.org/wiki/GRASS_SoC_Ideas_2013
thanks,
Hamish
/lib/python/script/array.py#L238
Glynn:
It was probably added during development and not reverted.
just to note that verbose=True argument for r.in.bin is present in all
branches, and has been there for some years (for better or worse).
Hamish
as intermediary steps in scripts are a good match for 'core'.
re. other modules to consider-
One day I'd like to put the finishing touches on d.barb in g6
addons and then port it to g7 with an eye to getting it into
g7 core for its d.rast.arrow-for-vectors capabilities.
time, time, time..
best,
Hamish
submit a full bug report,
with preprocessed source if appropriate.
See file:///usr/share/doc/gcc-4.7/README.Bugs for instructions.
[...]
?
Hamish
--- On Thu, 4/4/13, Launchpad Buildd System nore...@launchpad.net wrote:
From: Launchpad Buildd System nore...@launchpad.net
Subject: [Build #4465448
Markus Metz wrote:
I changed r.in.gdal in r55625 such that GDAL GDT_Float64 is
now imported as GRASS DCELL (64 bit floating point). The
original and the
re-import are now identical.
Should this change be backported to GRASS 6?
yes please.
thanks for noticing,
Hamish
-s' for common compiled C modules calling tcl/tk
forms.
regards,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
as a near-last page the nsi
installer I think.
Please let's just focus our energy on fixing bugs and so getting the release
out..
best,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Martin wrote:
If nobody will fix it, we can release GRASS without binaries for
Windows ;-)
If nobody fixes it, we will have to release GRASS without binaries for Windows
:-/
best,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http
, where it skips over empty maps but
doesn't warn you when none of the input maps contain data);
and the f_range file in cell_misc/ for it is 0 bytes.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass
Yann:
In the same way as there is a pixel based function to assess a
NULL pixel value, it would be very interesting to have a
function to test an all NULL raster map status.
see 'r.info -r' for overall map, or r.univar for within-region window.
?
Hamish
some of my little
helper shortcut scripts to grass-addons/tools/, which makes
merging recent changes between branches very simple.
best,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
be the same. The interesting case is OpenCL, where your
video card can run 500 GPU units..
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
as well. The bigger
concern I think is remaining imagery library and i.* modules
which do not like @mapset. (I'm guessing some remain)
(and in future vector maps won't have to be sql compliant too)
Hamish
___
grass-dev mailing list
grass-dev
significant digits are useful. A little bit extra probably doesn't
hurt.
1 / 2^8 = 0.00390625
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
to the orginal, internally. It could make a table/
dictionary of map names vs. img_1, img_2, ... safe column names
then work with the safe names. Make the program[mer] do the hard
work, not the end user.. :)
best,
Hamish
___
grass-dev mailing list
grass
101 - 200 of 1486 matches
Mail list logo
