Hi Markus,
On 04/25/2016 11:27 PM, Markus Neteler wrote:
I have now submitted the changes along with the addition of some code
comments as per your emails in:
https://trac.osgeo.org/grass/changeset/68308
Hope I got it right! If yes, I'll backport that.
Yes, that all looks correct to me.
No
On 04/25/2016 09:47 PM, Markus Neteler wrote:
Paul, still struggling with "SIRGAS2000"
https://trac.osgeo.org/grass/ticket/2456#comment:15
(g.proj versus testepsg output). Needs a different trick?
Hi Markus,
It looks to me like the canonical and equivalent names are the wrong way
round. I wil
Hi Markus, Even,
On 04/24/2016 10:29 PM, Markus Neteler wrote:
Hi Paul,
you are probably the person with most insights into lib/proj/convert.c.
I try to debug why the North Carolina Location cannot be generated
properly (EPSG 3358) but comes out like this:
grass71 -c epsg:3358 ~/grassdata/
On 04/25/2016 09:12 PM, Even Rouault wrote:
Le lundi 25 avril 2016 22:02:20, Paul Kelly a écrit :
[...]
Perhaps there is a better / more correct way to get the co-ordinate
system definition from GDAL than by requesting it as a "+init=epsg:"
PROJ string?
Yes,
On Thu, 10 Sep 2015, GRASS GIS wrote:
see https://grass.osgeo.org/grass70/manuals/g.mkfontcap.html
there is a -s flag:
-s Write font configuration file to standard output instead of
$GISBASE/etc
a feasable way may be:
- another flag e.g. to write fontcap file to %APPDATA%GRASS7 where alread
Hello, I occasionally still glance at GRASS e-mails sometimes, and this
thread just caught my eye!
On 20/08/14 22:35, Vaclav Petras wrote:
On Wed, Aug 20, 2014 at 5:14 PM, Markus Neteler mailto:nete...@osgeo.org>> wrote:
The discussion was in 2008, for some pointers, see
http://lists.
Michael Barton wrote:
> On Oct 3, 2012, at 6:14 AM, Paul Kelly
> wrote:
>
>> Glynn Clements wrote:
>>> Consider whether the existing option should be renamed to datum_trans=.
>>> The abbreviation rules in 7.0 should accept datumtrans= as an
>>> abbr
Glynn Clements wrote:
Consider whether the existing option should be renamed to datum_trans=.
The abbreviation rules in 7.0 should accept datumtrans= as an
abbreviation, but will also accept e.g. dt= or dtrans=.
Sounds like a good idea to me. Since we're breaking compatibility with
the script
Hi Michael,
Michael Barton wrote:
Thanks for the information Paul. This is a good tip to know for command-line typing. It
is unfortunate, however, that this undocumented call was used in the Python scripting
library. I agree with you that using "datum" for datums makes enormous sense.
So hope
Michael Barton wrote:
Arrgg.
Before Paul's update to g.proj today, it turns out that g.proj would
actually accept the argument "datum" as equivalent of the argument
"datatrans", even though this is not in the manual. I don't know if that
was intentional or an accident. So g.proj datumtrans=1 cou
Markus Neteler wrote:
I do agree that getting the datum lost is bad. Perhaps we could enhance
g.proj to write it to PROJ_INFO when using the "Select coordinate system" way
of creating locations. Proof of concept:
GRASS 6.4.3svn (newLocation2):~ > eval `g.gisenv`
GRASS 6.4.3svn (newLocation2):~
Hi Michael,
On Sun, 30 Sep 2012, Michael Barton wrote:
[...]
The only way to generate a proj4 string interactively is to pick the
appropriate values from a table. When g.proj was still an interactive terminal
module, running it would bring up the lists from these tables to generate a
proper
Michael Barton wrote:
Thanks for the information Paul,
This is directly a g.proj problem rather than a proj4 problem per se--although
I don't know how g.proj uses proj4. So it may be indirectly something to do
with proj4 too.
g.proj does not use PROJ.4 for importing projection definitions at
Hello all,
Markus has prompted me to try and give some insight into what is going
on here, which I will gladly try to do:
Michael Barton wrote:
Markus,
It looks like some datums are not being recognized by g.proj. When this
happens, datum transform information is not returned. Take a look at
On Fri, 30 Jul 2010, Hamish wrote:
Glynn:
Ah; so pj_get_def() returns a definition using spaces both
as an argument separator and within arguments?
In which case, we need a more robust alternative to
pj_get_def().
I guess the alternative is to remove the step whereby (in g.proj) the set
of
On Thu, 29 Jul 2010, Hamish wrote:
... still no-go. at the 6.4.0svn msys prompt:
GRASS 6.4> g.proj -j
+proj=utm
+zone=13
+a=6378206.4
+rf=294.9786982
+no_defs
+nadgrids=c:/Program
Files/GRASS-64-SVN/etc/nad/conus
+to_meter=1.0
.. so g.proj is broken ..
Oops - well I've just committed a chan
On Thu, 10 Jun 2010, Wolf Bergenheim wrote:
On Thu, Jun 10, 2010 at 09:10, Seth Price wrote:
Which came from here:
http://newtrac.osgeo.org/grass/log/grass-addons/r.sun_horizon/r.sun2/rsunlib.c?rev=25783
The comments say it came from JRC, but what is that?
The JRC seems to be the European C
On Wed, 19 May 2010, Paul Kelly wrote:
On Mon, 17 May 2010, Maciej Sieczka wrote:
Does this sound acceptable for now - in particular are there any
differences between Pulkovo 1942 and Pulkovo 1942 (58) that are worth
worrying about?
I don't know.
OK well I will guess that any differ
On Mon, 17 May 2010, Maciej Sieczka wrote:
GRASS already has the correct parameters for Poland. The problem is
that it doesn't recognise the datum name "Pulkovo_1942_58"; it is
looking for "Pulkovo_1942". I would recommend the patch below for
working around this problem.
Index: lib/proj/conve
Hi Maciej, Markus,
On Sat, 15 May 2010, Markus Neteler wrote:
On Sat, May 15, 2010 at 2:53 PM, Maciej Sieczka wrote:
OK now, so this was actually a revert of a massive update which broke
things.
Right - personally, I find it to be a major problem that we are out of
synch with GDAL now.
I
On Tue, 13 Apr 2010, Jachym Cepicky wrote:
Hi,
I can not get reasonable result (compared with v.surf.rst) from
v.surf.idw using attached input vector points
is it possible, that v.surf.idw is kind of broken?
Hello,
I can confirm that I can reproduce the strangeness, that it only happens
when
On Mon, 15 Mar 2010, Markus Neteler wrote:
On Mon, Mar 15, 2010 at 4:10 PM, Paul Kelly
wrote:
On Mon, 15 Mar 2010, Markus Neteler wrote:
On Mon, Mar 15, 2010 at 8:44 AM, Hamish wrote:
Paul wrote:
...
I can confirm that
svn merge -c -41248 .
fixes 6.4 release branch.
OK, so please
On Mon, 15 Mar 2010, Markus Neteler wrote:
On Mon, Mar 15, 2010 at 8:44 AM, Hamish wrote:
Paul wrote:
...
I haven't had time to test reverting the CSV files yet but
(I wonder how CSV files could mess up a logic but how knows...
Of course let's revert in 6.4 if this breaks things)
Hi Mark
Hello all,
I have a little more insight on this. See below.
On Fri, 12 Mar 2010, Paul Kelly wrote:
On Fri, 12 Mar 2010, Markus Neteler wrote:
On Fri, Mar 12, 2010 at 8:38 PM, Martin Landa
wrote:
Hi,
2010/3/12 Massimo Di Stefano :
"location wizard -> select epsg code -> search
On Fri, 12 Mar 2010, Markus Neteler wrote:
On Fri, Mar 12, 2010 at 8:38 PM, Martin Landa wrote:
Hi,
2010/3/12 Massimo Di Stefano :
"location wizard -> select epsg code -> search for : 3004"
in the paste release (build less than 1 month ago) after select the
epsg:code(3004)
grass prompt me
On Sat, 6 Mar 2010, Helmut Kudrnovsky wrote:
from the grass-windows-point-of-view:
I've tested in the last days a lot the issues in
http://trac.osgeo.org/grass/ticket/908
r40857 (see http://trac.osgeo.org/grass/ticket/908#comment:9) should be
backported to grass64. g.mkfontcap with this fixes
On Mon, 15 Feb 2010, Helena Mitasova wrote:
v.delaunay results look OK but I am not sure what they would be used for
without the z-values.
http://skagit.meas.ncsu.edu/~helena/grasswork/delaunay_poly.png
I remember that there was some effort to get the z-values added to create a 3D
vector
but I
On Wed, 10 Feb 2010, Markus Metz wrote:
I found two code snippets in the segment library (all branches) that look
fishy to me:
the first is in relbr6 here
https://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/lib/segment/format.c#L135
should
if (lseek(fd, 0L, SEEK_SET) == (o
On Wed, 3 Feb 2010, Franz Schiller wrote:
Hello All
Regarding a message that Hamish sent me a last week ago, related with:
FWIW, I try to copy custom stuff into a dir outside the install
dir which is pointed to by the GRASS_ADDON_PATH environment
variable, that way I can replace & upgrade gra
On Thu, 14 Jan 2010, Paolo Cavallini wrote:
Hi all.
Reading the recent post of Glynn:
Right now, I'm actively trying to think of ways to make life harder for anyone
trying
to use the GRASS libraries for anything except GRASS modules.
http://trac.osgeo.org/grass/ticket/869#comment:1
I wonder i
never got it finished.
Paul
-- Forwarded message --
Date: Mon, 18 Aug 2008 11:27:41 +0200
From: Martin Pavlovsky
To: Paul Kelly
Subject: Re: Possible Extension
[...]
I am just finishing the testing of v.delaunay2 module. The module can output
delaunay triangulation as a set of
And another comment from Martin about the algorithm used in the current
GRASS v.voronoi:
I started studying Fortune sweepline algorithm. As soon as I make any
significant progress with the implementation, I will inform you. As a
matter of fact, original version of v.voronoi/delaunay uses a For
Hello all,
If I understand correctly, the patch is attempting to solve two separate
issues:
1) When starting GRASS by double-clicking on the grass64.sh icon, the user
doesn't get a terminal window in which to enter GRASS commands.
2) GRASS doesn't exit properly because the Init.sh runs in th
On Sun, 12 Jul 2009, Massimiliano Cannata wrote:
maybe this can help (CH1903 to WGS84):
http://www.swisstopo.admin.ch/internet/swisstopo/en/home/products/software/products/skripts.html
Not sure which problem you mean it can help with? As far as I can see that
is a quick approximation to conve
On Fri, 26 Jun 2009, Hamish wrote:
fyi I've posted a valgrind error for the module into the relevant
bug report. IMO a good way to continue with this bug is to tackle
that known error and see if it fixes it.
Hi Hamish,
I saw that and looked at it briefly yesterday but it appeared to be only
i
On Thu, 25 Jun 2009, Markus GRASS wrote:
[...]
very little about in this case. E.g. for completely random access
there might not be a lot of gain.
It is completely random, the next chunk to be read/written can be
anywhere in the file.
[...]
But if there was random access only within a certa
On Wed, 24 Jun 2009, Markus GRASS wrote:
Paul Kelly wrote:
On Tue, 23 Jun 2009, Markus GRASS wrote:
My implementation is completely file based, also when creating or
updating a vector. This comes obviously with a speed penalty because
reading in memory is faster than reading from file. With
On Tue, 23 Jun 2009, Markus GRASS wrote:
My implementation is completely file based, also when creating or
updating a vector. This comes obviously with a speed penalty because
reading in memory is faster than reading from file. With all sorts of
tricks and relying on the system to cache files, t
On Tue, 16 Jun 2009, Michael Barton wrote:
In GRASS, displaying Layer 1 will show all objects for some vector
topologies, and only ID 1 and 2 for other topologies. However, by putting
values into cat for Layer 1, you can also display ID's 3 & 4 for Layer 1. You
can achieve the same effect by q
On Tue, 16 Jun 2009, Markus GRASS wrote:
GRASS vector layers are very different...and this is one of the
problems with calling them layers. GRASS vector "layers" are simply
cat values assigned to a single set of vector objects. A vector map of
roads with layers 1 and 2 displays the same vector o
On Mon, 15 Jun 2009, Michael Barton wrote:
GRASS vector layers are very different...and this is one of the problems with
calling them layers. GRASS vector "layers" are simply cat values assigned to
a single set of vector objects. A vector map of roads with layers 1 and 2
displays the same vect
On Fri, 12 Jun 2009, Hamish wrote:
As Michael mentioned, any difference in opinion probably arises from the
native English speakers vs. not. Whereas the non-native speakers take a
much more literal view of the word than the native speakers would. I
would expect native speakers to consider the wo
On Tue, 9 Jun 2009, Moritz Lennert wrote:
What is the status of lib/gis/datumtransform.table ? Trying to do some
reprojection between LL-WGS84 (epsg 4326) and belgian lambert 72
(epsg:31370), I see some problems due to the parameters in that file:
- in the proj epsg file (Rel. 4.6.0, 21 Dec 2
On Mon, 25 May 2009, Hamish wrote:
Hamish:
g.setproj doesn't let you run it from a XY location.
is that really necessary?
it makes it hard to import unprojected imagery, reset to
known bounds with r.region, and then change into a lat/lon
location. note in that workflow the raster's cellhd/
fil
On Sat, 25 Apr 2009, Markus Neteler wrote:
I think we can remove the files and the associated stuff you mentioned if
these conditions are true:
* The .csv files are always installed by default with GDAL
* A GDAL installation is not considered a working installation if these
files are not pre
On Thu, 9 Apr 2009, Colin Nielsen wrote:
Question for those who are testing: do you prefer the msys version
(with a functioning terminal) or the other one (which runs
grass64.bat)? Both is probably confusing, but I don't want to remove
the older grass64.bat option without consultation from those
On Tue, 17 Mar 2009, G. Allegri wrote:
I know that the Windows Vista grass users community is not so wide, anyway I
would like to know if someone is thinking about the problem I posted
sometime ago and if someone else can reproduce it.
Whenever I try to create a new Location (in my case from eps
On Tue, 10 Mar 2009, G. Allegri wrote:
Hello list.
I've just setup grass from osgeo4w. I'm a Linux user but I need to
develop some grass scripts on windows.
When launching it from grass64.bat as tcltk iface, I obtain the
classic prompt for location. I try to set it from EPSG codes but when
I've
On Mon, 12 Jan 2009, Hamish wrote:
Hi & happy new year everybody,
after svn up, libogsf in develbranch_6 does not build:
gsd_img_mpeg.c: In function 'gsd_close_mpeg':
gsd_img_mpeg.c:439: error: incompatible type for argument 1 of 'url_fclose'
make[2]: *** [OBJ.i686-pc-linux-gnu/gsd_img_mpeg.o
On Tue, 23 Dec 2008, Glynn Clements wrote:
Trying to run nviz brings up a further error - see attached -
unfortunately no time to look into it further now.
I can't reproduce this. Does the file appear to be valid?
No - it's not there actually. Didn't take much further looking into... the
cul
On Mon, 22 Dec 2008, Glynn Clements wrote:
Paul Kelly wrote:
I had a problem compiling nviz from the 6.4 release branch on Windows,
with unrecognised Tcl/Tk symbols. Reverting r32244 to put the Tcl/Tk
library flags in among the other library linking flags seems to fix it:
http
I had a problem compiling nviz from the 6.4 release branch on Windows,
with unrecognised Tcl/Tk symbols. Reverting r32244 to put the Tcl/Tk
library flags in among the other library linking flags seems to fix it:
http://trac.osgeo.org/grass/changeset/32244
I haven't committed as I don't understan
On Sun, 21 Dec 2008, Martin Landa wrote:
Hi,
I am currently trying to compile GRASS (releasebranch_6_4) under MS
Windows [1].
TODO:
* compile with regex
I can report it works fine with the Gnuwin32 regex packages. Another issue
is that Cairo support in the 6.4 configure script requires the
On Sun, 21 Dec 2008, William Kyngesburye wrote:
On Dec 21, 2008, at 3:35 PM, Michael Barton wrote:
I just tried compiling GRASS 7 with OS X. Most went fine. I got a few
errors
Error in...
/Users/cmbarton/grass_dev/grass7_src/lib/proj
Doesn't recognize the NAD2BIN environmental variable
Had
On Fri, 19 Dec 2008, Martin Landa wrote:
Hi,
2008/12/19 Paul Kelly :
OK, on the other side, I don't see any reason why to postpone the
decision.
Just so we have time to discuss it all properly. I get the impression Markus
wants to create the release branch and tag 6.4.0RC1 this evening
On Fri, 19 Dec 2008, Martin Landa wrote:
Hi,
2008/12/19 Paul Kelly :
[...]
group of modules
nviz
in GRASS6:
nviz_cmd becomes nviz.cmd
Well as I said above I feel it is a bad idea to make any last minute changes
now if we're intending to tag 6.4.0RC1 imminently, so I'd vote f
On Fri, 19 Dec 2008, Martin Landa wrote:
Hi,
2008/12/19 Markus Neteler :
Call it nviz2?
nviz -> TCL/TK GUI
nviz2 -> cmd line based module
seems to be confusing for me...
I vote for d.3d.
or we can leave it as nviz_cmd and go ahead to 6.4.0RC1...
considering d.nviz which should be also
On Fri, 19 Dec 2008, Markus Neteler wrote:
On Fri, Dec 19, 2008 at 1:03 PM, Martin Landa wrote:
Hi,
2008/12/19 Martin Landa :
Call it nviz2?
nviz -> TCL/TK GUI
nviz2 -> cmd line based module
seems to be confusing for me...
I vote for d.3d.
or we can leave it as nviz_cmd and go ahead t
On Thu, 18 Dec 2008, Michael Barton wrote:
On Dec 18, 2008, at 4:21 AM,
wrote:
Date: Thu, 18 Dec 2008 12:21:17 +0100
From: "Martin Landa"
Subject: Re: [GRASS-dev] 6.4rc1
To: Hamish
Cc: grass-dev
Message-ID:
Content-Type: text/plain; charset=ISO-8859-1
Hi,
2008/12/1 Martin Land
On Thu, 18 Dec 2008, Markus Neteler wrote:
On Wed, Dec 17, 2008 at 9:11 PM, Paul Kelly
wrote:
#392: backport G_is_c_null_value() to devbr6
Comment (by hamish):
For rc2, to completely replace null_val.c or not? I am still a bit unsure-
is there actually a bug in the current devbr6 version
On Thu, 18 Dec 2008, Martin Landa wrote:
Hi,
2008/12/1 Martin Landa :
2008/12/1 Hamish :
so what remains todo befor 6.4rc1? IMO lib API and module list should be
frozen at that point, which means creating releasebranch_6_4. No need to
I also added to the list nviz_cmd module. I am not sure
GRASS GIS wrote:
#392: backport G_is_c_null_value() to devbr6
--+-
Reporter: hamish | Owner: grass-dev@lists.osgeo.org
Type: task | Status: new
Priority: major| Mile
On Mon, 1 Dec 2008, Martin Landa wrote:
Hi,
2008/12/1 Hamish <[EMAIL PROTECTED]>:
so what remains todo befor 6.4rc1? IMO lib API and module list should be
frozen at that point, which means creating releasebranch_6_4. No need to
I also added to the list nviz_cmd module. I am not sure about it
Hi Markus
On Wed, 19 Nov 2008, Markus Neteler wrote:
Hi,
would it be complicated to add an "exclude_pattern" parameter to
g.mlist/g.mremove?
Example: I want to select only the gpcp_1dd_p1d_*_count maps but not the monthly
counts:
g.mlist type=rast patt="gpcp_1dd_p1d_*_count"
What about
g.m
On Tue, 18 Nov 2008, Martin Landa wrote:
Hi,
2008/11/18 Paul Kelly <[EMAIL PROTECTED]>:
backport this?
No specific ideas on this change, but if we're working towards a stable
settled down 6.x then I don't think the type of miscellaneous cleanups that
Glynn is doing in 7.x ar
On Tue, 18 Nov 2008, Markus Neteler wrote:
On Tue, Nov 18, 2008 at 2:41 AM, <[EMAIL PROTECTED]> wrote:
Author: glynn
Date: 2008-11-17 20:41:17 -0500 (Mon, 17 Nov 2008)
New Revision: 34353
Removed:
grass/trunk/imagery/i.fft/fft_colors.c
grass/trunk/imagery/i.fft/globals.h
grass/trunk/ima
On Wed, 5 Nov 2008, Patton, Eric wrote:
AFAICT `g.proj -wf` doesn't include grid file, while `g.proj -jf` does.
So I think my "best use `g.proj -wf` in that case" might be wrong as it
drops the grid file, so really best to use:
IN_PROJ="`g.proj -jf` +wktext"
http://trac.osgeo.org/gdal/ticket/2
On Tue, 4 Nov 2008, Markus Neteler wrote:
On Tue, Nov 4, 2008 at 8:41 AM, Hamish <[EMAIL PROTECTED]> wrote:
I am running a large number of processing jobs on a
cluster and the job manager output is cluttered with
control chars from G_percent().
It would be great to have a switch (or detection m
On Mon, 3 Nov 2008, Hamish wrote:
MN:
We can certainly freeze devel_grass6 and just tag RC1
directly from that and test it rigorously. But are we
sure that nobody inserts new features?
new Vect fns req'd for v.buffer2 should be merged ASAP then.
Was the issue with the linkm library ever re
On Sun, 2 Nov 2008, Markus Neteler wrote:
Hi Paul, all,
On Sun, Nov 2, 2008 at 5:59 PM, Paul Kelly
<[EMAIL PROTECTED]> wrote:
Hi Markus
On Sun, 2 Nov 2008, Markus Neteler wrote:
(cc Tim Sutton)
On Mon, Oct 27, 2008 at 7:30 AM, Hamish <[EMAIL PROTECTED]> wrote:
Paul wrot
Hi Markus
On Sun, 2 Nov 2008, Markus Neteler wrote:
(cc Tim Sutton)
On Mon, Oct 27, 2008 at 7:30 AM, Hamish <[EMAIL PROTECTED]> wrote:
Paul wrote:
I still think at some point a 6.4 release branch will be needed (when we
want to add new features) but I think we should put off creating it as
l
On Tue, 28 Oct 2008, Hamish wrote:
Paul, I notice a bit of grass-specific Proj stuff in the CVS history,
is that going to be a big pain?
Not at all - the PROJ code is quite simple as GSHHS data has no datum and
the amount of PROJ-related code can be reduced a few lines further in 6.x
by usin
Hi Yann,
Thought I would comment too so you know it is not just Glynn who sees
there is a problem here.
On Mon, 27 Oct 2008, Yann Chemin wrote:
Hello Glynn,
since I rewrote the code, and tested it, I know quite much what I do
with the bitshifts, the image input, and the classification result
On Fri, 24 Oct 2008, Markus Neteler wrote:
On Fri, Oct 24, 2008 at 1:45 AM, Paul Kelly
<[EMAIL PROTECTED]> wrote:
So I feel there is no real option but to go straight to 6.4.0. I'm still not
sure if we need a release branch though.
You mean we should just tag RC1 from develb
On Thu, 23 Oct 2008, Glynn Clements wrote:
Paul Kelly wrote:
I'd be more concerned about 6.3.1, as there have been a fair number of
straightforward bug-fixes since 6.3.0.
Well, I know easily 50 fixes which I have NOT backported to 6.3.svn, knowing,
that 6.4.0.RCX is forthcoming soon.
On Wed, 22 Oct 2008, Markus Neteler wrote:
On Wed, Oct 22, 2008 at 5:27 PM, Glynn Clements
<[EMAIL PROTECTED]> wrote:
I'd be more concerned about 6.3.1, as there have been a fair number of
straightforward bug-fixes since 6.3.0.
Well, I know easily 50 fixes which I have NOT backported to 6.3.s
Hello Markus
On Tue, 21 Oct 2008, Markus Neteler wrote:
Hi,
let me suggest to create the GRASS 6.4.0 release branch the next
days to get started with stability tests. The last release is long time
ago and more and more efforts go into GRASS 7 (which is good).
Time to get 6.4.0 out of the doors
On Mon, 20 Oct 2008, Glynn Clements wrote:
Moritz Lennert wrote:
How about for GRASS 7 on all platforms, turning d.mon into a script that
runs an image display program that initialises the image it displays
from GRASS_PNGFILE and automatically refreshes the display when the file
is modified?
On Sun, 19 Oct 2008, Glynn Clements wrote:
Except that d.mon isn't specific to XDRIVER, nor is the lack of
monitors on Windows.
And AFAICT, the legacy display architecture was originally designed
for Tektronix 41xx (and similar) terminals; X support came later.
Yes I think so too - IIRC in th
On Sun, 12 Oct 2008, Markus Neteler wrote:
Any objections (the motivation is obvious)? I would also update
Hi Markus,
Can you elaborate on the motivation? As it is I feel an obvious objection is
that this implies there is no other way to import raster and vector data
than through GDAL and OGR
On Sat, 11 Oct 2008, Markus Neteler wrote:
Hi,
I would like to rename a set of modules as outlined in
http://grass.osgeo.org/wiki/GRASS_7_ideas_collection#rename
Raster:
* rename r.in.gdal to r.import
* rename r.out.gdal to r.export
Vector:
* rename v.in.ogr to v.import
* rename v.out.ogr to
On Sun, 12 Oct 2008, Ivan Shmakov wrote:
Doesn't C require an explicit initial value for `initialized'
here?
Well, as it is a static variable it will be initialised to zero.
$ nl -ba grass-trunk-r33586/lib/htmldriver/Driver.c
...
20 const struct driver *HTML_Driver(void
On Tue, 7 Oct 2008, Glynn Clements wrote:
Paul Kelly wrote:
+#ifdef HAVE_LARGEFILES
+ filesize = ftello(in_fp);
+#else
filesize = ftell(in_fp);
+#endif
Can we add library functions, G_fseek() and G_ftell(), which use an
off_t. The functions would use fseeko/ftello if
On Tue, 7 Oct 2008, Paul Kelly wrote:
I'm not sure if this is by design or by accident that it
works like this but it's quite neat really.
Sorry that was a confusing statement - I meant that the fact that the large
file support in config.h can be activated by #define USE_LARGE
On Tue, 7 Oct 2008, Markus Neteler wrote:
On Tue, Oct 7, 2008 at 11:53 AM, Paul Kelly
<[EMAIL PROTECTED]> wrote:
Are there any really huge files anybody can test it with?
For easily create a huge DEM file, do this:
Actually, thinking clearly, it's a huge input text points fi
On Mon, 6 Oct 2008, Hamish wrote:
Paul Kelly wrote:
I looked in r.in.xyz which only uses fseek() and
ISTR discussion about it handling huge files recently,
although perhaps that involved reading from stdin.
fwiw the fseek() there is just to grab the filesize so G_percent() can
know where 100
On Tue, 7 Oct 2008, Glynn Clements wrote:
Paul Kelly wrote:
main.cpp includes ; I wonder if the problem is due to the fact
isnan() is a C99 function? Should it be changed?
Yes. This came up about a month ago:
http://lists.osgeo.org/pipermail/grass-dev/2008-September/039910.html
I
I'm not sure if it's relevant, but the wxpython GUI requires the pywin32
package to be installed. Perhaps this includes some workarounds for this
sort of thing - I haven't looked into it to see. But I don't like the
idea of requiring lots of extra packages - installing wxpython on top of
Python
On Mon, 6 Oct 2008, Andrew Danner wrote:
fseek is not the same as fseeko.
int fseek(FILE *stream, long offset, int whence);
int fseeko(FILE *stream, off_t offset, int whence);
If large file support is enabled, fseeko will convert off_t to a 64 bit type
even on a 32-bit OS. I'm not sure if lo
On Mon, 6 Oct 2008, Glynn Clements wrote:
Oops. It turns out that Python doesn't understand %PATHEXT% (but it
least it's consistent; it doesn't work with .bat or .cmd files
either).
It looks to me like it doesn't work with .exe either, i.e. it doesn't
assume the extension - e.g. trying to run
i.atcorr uses the isnan() function which seems to cause compilation to
fail on Windows:
sh-2.04$ make
c++ -I/c/grass/grass7/dist.i686-pc-mingw32/include -I/c/grass/extra/include -O2 -s
-I/c/grass/extra/include -DPACKAGE=\""grassmods"\"
-I/c/grass/grass7/dist.i686-pc-mingw32/include -o OBJ.i
In some recent enhancements to the iostream library,
include/iostream/ami_stream.h had a call to fseek() changed to fseeko().
This now doesn't compile on Windows; a sample error is:
sh-2.04$ make
make OBJ.i686-pc-mingw32
make[1]: Entering directory `/c/grass/grass7/lib/iostream'
make[1]: `OBJ.i
On Sun, 5 Oct 2008, Glynn Clements wrote:
Also, should we change windows_launch.bat to invoke Python on the
scripts, or just install the scripts with a .py extension and add .PY
to PATHEXT?
windows_launch.bat was only needed because there was no way to persuade
Tcl on Windows to execute any f
On Wed, 24 Sep 2008, Hamish wrote:
[sorry for the cross-posting, I'm casting the idea net wide]
is this license GPL2 compatible?
is this license DFSG compatible? *
"There is no warranty whatsoever. Use at your own risk.
This code may be freely redistributed under the condition that the copyr
On Sat, 6 Sep 2008, Martin Landa wrote:
Hi,
2008/9/6 Paul Kelly <[EMAIL PROTECTED]>:
Except for one thing: the g.mremove script has dview= rather than
3dview=. The C modules has 3dview=, and both versions of g.mlist use
type=3dview. I'm not sure if there's a reason for this, o
On Sat, 6 Sep 2008, Martin Landa wrote:
Hi,
2008/9/6 Glynn Clements <[EMAIL PROTECTED]>:
Except for one thing: the g.mremove script has dview= rather than
3dview=. The C modules has 3dview=, and both versions of g.mlist use
type=3dview. I'm not sure if there's a reason for this, or if it was
j
On Thu, 21 Aug 2008, Paul Kelly wrote:
On Thu, 21 Aug 2008, Glynn Clements wrote:
Paul Kelly wrote:
AFAICT, the only "core" GDAL dependencies are the OSR stuff in
lib/proj and g.proj, and the vector library's support for v.external.
In which case, it really ought to be po
On Thu, 21 Aug 2008, Glynn Clements wrote:
Paul Kelly wrote:
AFAICT, the only "core" GDAL dependencies are the OSR stuff in
lib/proj and g.proj, and the vector library's support for v.external.
In which case, it really ought to be possible to get a usable version
of GRA
On Wed, 20 Aug 2008, Glynn Clements wrote:
AFAICT, the only "core" GDAL dependencies are the OSR stuff in
lib/proj and g.proj, and the vector library's support for v.external.
In which case, it really ought to be possible to get a usable version
of GRASS with no GDAL dependency in any of the lib
On Tue, 19 Aug 2008, Marco Pasetti wrote:
Dear Robert,
How to run WinGRASS with non-english interface?
I tried different methods without success.
http://www.nabble.com/-GRASS5--Re%3A--GRASSLIST%3A5600--How-to-start-GRASS-in-another-language--p8590987.html
sincerely,
--
Robert Szczepanek
I
1 - 100 of 182 matches
Mail list logo
