of swig
again, if not, at least the ./configure script should throw an error
when --with-python is given instead of doing what it does now fail at
compile-time.
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http
Hamish wrote:
in related issues swig/python/ still fails to build due to
too-old(?) swig ver 1.3.29, [...]
Glynn:
AFAIK, that version with SWIG will work with older versions of Python.
The core problem is that your distro ships a version of of SWIG which
isn't compatible
them. If you want
a 1px frame use border=1 in the img src.
..png please.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Hamish wrote:
I added a new lib/external/README.license file to explain
things.
AFAICT the SUBMITTING file and RFCs do not require adjustment.
Soeren:
Ok, i will put ccmath into lib/external together with the
lgpl.license file and a README.
actually there is nothing about the GPL
Markus:
An option might be to make a local Makefile hack to substitute
part of the generated HTML file with a replacement including
these images.
Hamish wrote:
I don't think that's needed; just put the images in the main
body of description.html, as the color options get repeated
Py_ssize_t;
+# define PY_SSIZE_T_MAX INT_MAX
+# define PY_SSIZE_T_MIN INT_MIN
+#endif
+
%}
%rename(my_def) def;
yes, with that patch a fresh build completes successfully.
thanks,
Hamish
___
grass-dev mailing list
grass-dev
/Raster_color_tables
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[this will probably bounce off the qgis list, feel free to fwd if it
doesn't turn up]
Hamish ha scritto:
I added another new symbol in SVN called extra/fish. It's based on
the one in QGIS.
Paolo:
Why don't we share symbols and icons across programs, without having to
duplicate the efforts
? Is it seen in the wild or is
it just an unused nice idea someone had?
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
(void *buf)
{
free(buf);
}
most of the G_malloc() stuff justs adds bounds checking and
prepares error messages; there are no #ifdefs in lib/gis/alloc.c
for Windows. I can't say that won't change in the future, but
for now...
Hamish
___
grass-dev
Soeren:
IMHO it may be difficult to re-license the ccmath library under
the GPL ... .
Hamish:
why? Term 3 of the LGPL exists to describe exactly how to do that.
Soeren:
I am not concerned about the technical way, but about
agreement of the original author of ccmath. Maybe i am
wrong
%. :-/
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
/ only d.rast.edit.tcl uses a $total variable.
But maybe something in addons does. not sure
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
, the m.eigensystem module (addons),
and R-stats can give you some confidence in one flavour over another.
I'd guess it is highly likely that you are correct and this source was
adapted from Fortran beginnings.
Hamish
___
grass-dev mailing list
' the COPYING file need any adjustment to cover this.
But a formal decision on that may be a matter for the PSC.
As long as everything in the lib/ccmath/ dir falls under the same (GPL
compatible) license and the LGPL.txt file is placed in that dir I'd be
happy.
Hamish
[*] a web search for ccmath found
to squeeze from it?
perhaps that's poorly worded: not that DCELL == double, but that
size(double) in one place == size(double) in another.
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
/changeset/38436
... maybe others
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
now uses a
python parser which understands shell quoting on the Cmd line.
But that might only be present in the very latest build.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
/HowToContribute#WriteaccesstotheMainGRASS-SVNrepository
cheers,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Soeren wrote:
| Data Description:
|generated by r.mapcalc
|sin(col() * 5) * col() + cos(row() * 5) * row() + 200
nice test pattern
H
___
grass-dev mailing list
grass-dev@lists.osgeo.org
with v.external
593 WinGRASS GIS.m: cannot select maps from mapset GUI
637 Problems with paths in the TCL/TK Windows GUI
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Helena Mitasova wrote:
I am still wondering why tcltk browser shows files that
start with . ?
It is my understanding that that is a feature of the tcltk file
picker, and there is nothing we can do about it.
Hamish
___
grass-dev mailing
the BEGIN initialization anyway?
I don't think it is strictly needed, but it is good habit to do so.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Hamish wrote:
how about adding something like this to the awk script:
(sorry about that being so rough+buggy, but you get the idea)
H
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Markus Neteler wrote:
echo 345.551054 1 1
364.229489 1 1
382.907925 1 3 | awk ...
R = (sumXY - sumX*sumY/tot)/((sumsqX - sumX^2/tot)*(sumsqY -
sumY^2/tot))^0.5;
sumsqY = 5
sumY = 5
tot = 5
thus (sumsqY - sumY^2/tot))^0.5 = 0
Hamish
the GRASS DOS prompt show the same?
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
for a better answer than I can
give, but AFAIK they are harmless and can be deleted.
Hamish
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
might help.
?
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
could work (even partially) for maps without topology
built. e.g. massive LIDAR datasets.
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
is the reason to use G_done_msg( ); instead of G_done_msg(); ?
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Helena wrote:
and the button Use mouse to size place legend
should be disabled if possible
to avoid people spending too much time on figuring out how
to make it work
Hi,
just to note - if done for 6.x that would be via a wrapper --script.
Hamish
on
the road)
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
for reference, I assume python has
all the tools you need built in, tcltk can be pursuaded, ...
which leaves msys's /bin/sh.
I find msys to be too large complex to simply say msys does or
does not support this or that as a blanket statement.
Hamish
is dependent on the browser you
give for GRASS_HTML_BROWSER.
AFAIK g.manual is now fixed on WinGrass, we just wait for new
builds to confirm.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
the limit
of what I can do with that.
https://trac.osgeo.org/grass/log/grass/branches/develbranch_6/gui/tcltk/gis.m
(+ more, see ticket svn log)
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman
response in that case?
what's the status of forwarding from Baylor? we don't seem to
get any spam from that end ...
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
or '...' before 'OGRSpatialReferenceH'
make[1]: *** [OBJ.x86_64-unknown-linux-gnu/proj_wrap.o] Error 1
make[1]: Leaving directory `/usr/local/src/grass/svn/grass65/swig/python'
make: *** [default] Error 2
?
thanks,
Hamish
___
grass-dev mailing list
layers of .bat before it which complicates
things. (I am unable to test wingrass right now as well)
Hamish
ps-
-Inline Attachment Follows-
has anything changed re. mailing list attachment-stripping policy recently?
___
grass-dev
Hamish wrote:
many/most modules fail to build with:
[...]
main.c:45: undefined reference to `G_add_keyword'
it seems to be there in gisdefs.h . ??
Glynn:
Defined in lib/gis/parser.c. This suggests that it's linking against
an old version of the library.
What about
Hamish:
building relbr6.4 swig/python/ from Debian/Etch (swig
version 1.3.29-2.1) fails with:
[...]
utils_wrap.c: In function 'pyseq_to_ptr':
utils_wrap.c:2495: error: 'Py_ssize_t' undeclared (first use in this
function)
utils_wrap.c:2495: error: (Each undeclared identifier
Hamish:
building relbr6.4 swig/python/ from Debian/Etch (swig
version 1.3.29-2.1) fails with:
[...]
utils_wrap.c: In function 'pyseq_to_ptr':
utils_wrap.c:2495: error: 'Py_ssize_t' undeclared (first use in this
function)
[...]
Markus:
See
http://n2.nabble.com/grass7
Hamish:
building relbr6.4 swig/python/ from Debian/Etch (swig
version 1.3.29-2.1) fails with:
[...]
utils_wrap.c: In function 'pyseq_to_ptr':
utils_wrap.c:2495: error: 'Py_ssize_t' undeclared (first use in this function)
[...]
a #include Python.h seems in order.
I am trying
Hamish:
so (IIUC) swig 1.3.29 requires python = 2.5 ?
I can get a little further if I iteratively add this patch to *_wrap.c:
--- grass_wrap.c.ORIG 2009-07-20 13:06:52.0 +1200
+++ grass_wrap.c2009-07-20 13:07:15.0 +1200
@@ -111,6 +111,11 @@
/* Python.h has to appear
/grass/svn/trunk/dist.i686-pc-linux-gnu/include/grass/vector.h:478:
error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token
make: *** [OBJ.i686-pc-linux-gnu/allocation.o] Error 1
?
thanks,
Hamish
___
grass-dev mailing list
grass-dev
understand why user focused distros don't set that up by default.
OT tip2: more signal by not recording duplicates in .history file:
export HISTCONTROL=ignoredups
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org
Hamish wrote:
Debian/Lenny on 64bit:
--
many/most modules fail to build with:
[...]
main.c:45: undefined reference to `G_add_keyword'
it seems to be there in gisdefs.h . ??
Glynn:
Defined in lib/gis/parser.c. This suggests that it's linking against
Hamish:
so (IIUC) swig 1.3.29 requires python = 2.5 ?
Glynn:
FWIW, the wrappers generated by SWIG 1.3.36 have:
IOW, you should just need a newer version of SWIG.
aka ask users to upgrade their OS in order to install a user app. :-/
If this can not be worked around, anyone know what
Hamish wrote:
svn/trunk/dist.x86_64-unknown-linux-gnu/lib$ ldd
libgrass_gis.so
linux-vdso.so.1 = (0x7fffb79ff000)
! -libgrass_datetime.so = /usr/lib/grass/lib/libgrass_datetime.so
(0x7fdbaf4e5000)
libpthread.so.0 = /lib/libpthread.so.0 (0x7fdbaf2c9000
any opportunity here to kill off some more library-internal global variables?
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
?
besides the basic --script for the GUI menu structure, it would be nice
to also have:
--shell-script or --bourne-script
and
--python-script
which would modify script() to fill in the basic shebang and have to be
in grass to use this ### your code goes here ### stuff.
Hamish
previous discussion about this topic.
besides the grass-dev thread see also minor mention here
https://trac.osgeo.org/qgis/ticket/1133
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo
.
Comments?
see this earlier discussion from March 2007:
http://thread.gmane.org/gmane.comp.gis.grass.devel/19258/
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Glynn wrote:
r.neighbors doesn't propagate nulls, but computes the aggregate over
the non-null cells. It doesn't even have an option to propagate nulls.
ah, good to know. thanks for the explanation.
help pages updated in SVN to mention this.
Hamish
replacement.
(wxGviz is a horrible pun on gee-whiz == wow btw)
if not, file and directory names should be wxnviz.* not nviz.*
IMO.
regards,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass
) using MS VS.
The OSGeo4W installer does this; links for anyone interested:
http://trac.osgeo.org/grass/wiki/CompileOnWindowsMSVC
http://trac.osgeo.org/grass/browser/grass/trunk/mswindows/osgeo4w
http://trac.osgeo.org/osgeo4w/wiki/pkg-grass#PackagerNotes
Hamish
mapsets.
that's a blocker.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Glynn wrote:
Installing extensions via the GUI should install them for
an individual user, not system-wide.
perhaps default to ~/.grass/addons/ ?
(together with rename of .grassrc7 in trunk (it's not a rc file).
call that ~/.grass/init ? or?)
Hamish
in a form suitable for
easy Doxygen integration?
should clean-room author aim for MIT/X (full integration into
GDAL release) or LGPL (more in line with the spirit of our
project; continues as a GDAL plugin) ?
Hamish
___
grass-dev mailing list
. v.in.ascii seems to manage it.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
.
I've fixed this in 7.x with r38126. However, menuform.py
still tries to run the script using its basename.
should this be backported? if so, to which branches?
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http
not.
[**] loss of focus is a cost which must be balanced against continuity
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
then to learn Python. Python
is quite easy language to learn for newcomers. Shell scripts
are simply not good choice for writing sometimes quite
complicated GRASS scripts.
I completely agree. All the same, often they are quite useful
and powerful.
regards,
Hamish
Hamish:
So (IIU this C*), why should the removal of shell script
support not be reverted? What does it cost us to keep shell
script support?**
[*] I suspect I may not.
Glynn:
The support which has been removed is limited to the
build system.
Thank you for the clarification; sorry
to modify a map you'll need to hit the force redraw button.
not sure about the wxGUI, I don't have that near me right now, but I
expect there will be a similar button.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http
Moritz Lennert wrote:
Working with 6.4rc5 compiled as deb
packages on Ubuntu Intrepid, many of
my students had trouble with the map display in the wxgui,
today. I've not
been able to reproduce it systematically, yet, and so am
hesitant to file
this as a bug, but would like to know if
are, and will be very common in the future
( the future is now in many cases). Keep overheads of all types low and
the rest will take care of itself.
aka life's a compromise, do your best.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http
Glynn wrote:
I'm not entirely sure about interp.c. There might be non-raster uses
for it, although DCELL should be changed to double if it's kept in
libgis.
move to lib/gmath ?
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
. ... interested to learn why topology would
be useful for points-only data.
In general I'm fairly happy with the no-topology solution for lidar
data in grass, but a few targeted modules (eg v.info) really need to
be modified to deal with them.
Hamish
ps- we still need to hunt through the archives
http://download.osgeo.org/grass/grass6_progman/pythonlib.html
Moritz wrote:
Do I see correctly that there is no PDF version of it available ?
try 'make pdfdocs'
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http
why was #include grass/raster.h added to this file:
https://trac.osgeo.org/grass/changeset?new=grass%2Ftrunk%2Fvector%2Flidar%2Flidarlib%2FTcholBand.c%4038014old=grass%2Ftrunk%2Fvector%2Flidar%2Flidarlib%2FTcholBand.c%4037969
I'm assuming there are other false positives.
?
Hamish
() function??
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
search finds some non-portable chatter about setaffinity and
binding, but nothing very clear about how to undo the behaviour.
if it's an OS /proc thing, it seems like a weird choice for the default.
?,
Hamish
___
grass-dev mailing list
grass-dev
Jyothish Soman wrote:
I think that will be the parallel
version of the code given in the link. Sorry, I dont have
the resources right now to check the validity of the code,
my laptop is fried, working from a common terminal.
Just add -fopenmp flag in the make file for the code
Hamish
to
libgis, and everything which uses the remaining fields needs
to be moved to libraster.
for my 2c the region belongs to libgis, as it is also used for
display bounds and by region cropping input=/output= flags for
some vector modules.
Hamish
then - the new v.in.ogr GPX driver.
scripts/v.out.gps/v.out.gps
to be ported.
visualization/nviz/scripts/nviz
unused? (or if used, just a 1-liner)
note nviz from File menu in wxGUI on WinGrass currently fails for
unknown reasons. (process complete: 0 sec)
Hamish
/resources/postflight.in
build scripts.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
1
#define PRE_EDGE2
#define PRE_UNKNOWN 3
In v.lidar.growing I don't see any of these clearly but I guess they
must be there.
... I am a little confused. I'd like to update the v.lidar.edgedetection
man page to say what cat 0 in its output means.
thanks,
Hamish
scripts/d.out.gpsdrive/d.out.gpsdrive
Hamish:
If a method is found, it would be nice to recreate a d.out.file too,
as that is very useful.
Glynn:
d.out.file is meaningless in 7.0, as there is no current monitor to
get a list of displayed commands from.
But this looks more like
allocated for it?
looks like a bug to me.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
hope that
recent changes in trunk do not preclude using/installing shell
script modules cleanly, and would protest loudly if that is the
case. It's one thing not to ship any, it's another very
different thing to deny their use.
regards,
Hamish
(still no time to port v.*.gps etc, and won't have
these extensions working under MS Windows.
have you tried the updated simplified build instructions using osgeo4w
as the framework?
https://trac.osgeo.org/grass/wiki/CompileOnWindows
then hopefully it is mostly a matter of making sure the PATH order is
correct. (??)
Hamish
import them with v.in.ogr you get like 50 different
layers. DXF is another.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Hamish:
[...]/trunk/dist.i686-pc-linux-gnu/include
-I/usr/local/src/grass/svn/trunk/dist.i686-pc-linux-gnu/include
-o OBJ.i686-pc-linux-gnu/utils_wrap.o -c utils_wrap.c
utils_wrap.c: In function 'pyseq_to_ptr':
utils_wrap.c:2495: error: 'Py_ssize_t' undeclared (first use
: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token
make: *** [OBJ.i686-pc-linux-gnu/allocation.o] Error 1
include/Vect.h:474 is just after
#ifdef HAVE_GEOS
...
not sure what's wrong with that.
(libgeos-dev ver 2.2.3-3)
thanks,
Hamish
Hamish:
map - layer (Map Layer)
layer - catset (Category Set)
to be honest, I'm not a fan of either.
map - layer: no need for change; layer is less meaningful
in this context
(my POV is not from the GUI layer-list perspective, so the
metaphor makes little sense)
Martin:
I
.
then feed that column name to the 'v.distance column=' option.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
srtm tiles and grass's raster maps I think it is normal that
the cell edges seem to hang 1/2 a cell beyond exact round
numbers.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Rodelec Neuba wrote:
hi this is my first grass complete grass script in C.
I was trying to draw a rectangle around the map region.
Moritz wrote:
You do know that there is v.in.region ?
also d.region.box in wiki addons.
Hamish
Hamish wrote:
due to the grid vs cell center registration difference between
srtm tiles and grass's raster maps I think it is normal that
the cell edges seem to hang 1/2 a cell beyond exact round
numbers.
(which in this case causes a slight overlap)
Hamish
Hamish wrote:
due to the grid vs cell center registration difference
between srtm tiles and grass's raster maps I think it is
normal that the cell edges seem to hang 1/2 a cell beyond
exact round numbers.
(which in this case causes a slight overlap)
and can be solved by cropping
Francesco Paolo Lovergine wrote:
Just for note r37784 can be packaged straight on with only one
minor change due to a fix for g++ 4.4 merged in, so I can upload it
into sid just after the release...
already done,
http://trac.osgeo.org/grass/changeset/36940
Hamish
ps- how to symlink
regional sets with significant differences. How far appart are
points transformed using the two 7-term paramerts? 10s of meters?
just a few cm?
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass
Glynn:
The GRASS startup scripts should have already added this
directory to PYTHONPATH.
note that for GRASS 6 this wasn't happening until a few days ago due to
a typo in init.sh.
Hamish
___
grass-dev mailing list
grass-dev
Glynn wrote:
However, some of those wrappers will be unusable because of an
inability to pass an argument from Python or return the result to
Python.
is NumPtr of any help here? (see examples/m.distance.py)
https://trac.osgeo.org/grass/browser/grass/trunk/swig/python/NumPtr
Hamish
/etc/python.
fwiw, this fix was committed to 6.4 and 6.5 svns 2 days ago:
http://trac.osgeo.org/grass/changeset/37641
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
it. After
looking at the message again it may have been a mistake to include it
since the real problem was a version issue with MSys' make (3.79.1 vs
3.81).
Either way I'll remove it from the wiki since it is no longer needed.
ok, thanks.
Thanks for all the work including those bugfixes Hamish
): $(DEPENDENCIES)
- $(call linker)
-
-define objs_rule
-$(BIN)/$(1)$(EXE): $$(patsubst %.o,$(OBJDIR)/%.o,$$($$(subst .,_,$(1)_OBJS)))
+define objs_rule
+$(BIN)/$(1)$(EXE): $$(patsubst %.o,$(OBJDIR)/%.o,$$($$(subst
.,_,$(1)_OBJS)))$(DEPENDENCIES)
+ $$(call linker)
?
Hamish
Hamish wrote:
while reviewing streamlining the WinGrass build instructions I notice
a work-around is given for the grass 7 Make/Multi.make file which looks
like it might be a bug. It is step 4 for building GRASS 7:
https://trac.osgeo.org/grass/wiki/CompileOnWindows#Grass-7.0.svntrunk
Markus wrote:
it would be nice to have a -c flag (current mapset only)
in g.list and g.mlist to easily list in a selective way.
Currently I always have to run g.gisenv to fetch the current
mapset name and use mapset=name.
Or is there already a way to restrict the output to the
current
- draw a grid with numbers 4700 4750 4800 ...
but
major 5 and round 7 - draw 470 475 480 ...
what they print on the topo maps here is like the top example here:
http://bambi.otago.ac.nz/hamish/grass/dev/coord.html
ie kilometers(pos5,4) are 2 font sizes larger, meters(pos3,2,1) are
smaller
901 - 1000 of 1486 matches
Mail list logo
