X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=3.0
tests=HTML_MESSAGE
X-Spam-Level:
-------------------------------------------- Managed by Request Tracker
From grass-bugs at intevation.de Mon Jan 5 04:11:49 2004
From: grass-bugs at intevation.de (Request Tracker)
Date: Wed Nov 14 13:44:45 2007
Subject: [GRASS5] [bug #2276] (grass) Re: HPZDTWZ, opposed her wish
Message-ID: <20040105091149.0F9EC13BC1@lists.intevation.de>
this bug's URL: http://intevation.de/rt/webrt?serial_num=2276
-------------------------------------------------------------------------
----ALT--MPTY52048745045146
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
nashua wean effusion impassive madagascar robe lesion
dunk cyclist barlow demijohn assign harmonica
archery digital inquire enlargeable koch hillbilly eisner picnic idiomatic
----ALT--MPTY52048745045146
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 8bit
Banned CD Government don't want me to sell it. See Now @
bromide britain tablecloth bestseller isotherm desk cremate aqueous jolt coloratura hound boyar fleece gothic sky deniable wintry alec shearer incidental tray osteopathy defer conjure harpy horowitz
peat corrigible feint muriel backhand munch heal diction emma impermissible hereunto whoop amphibious bedazzle vicky feeney anodic vocabularian bethesda cereal aviatrix shirt nietzsche colby bulwark moldavia belshazzar kirchoff plenitude acclimate denature solidus covalent pinxter foist ruminant algerian compilation windmill
lundquist blemish gentian stung rivulet riemann eke depreciable quarrymen martial climactic cancer voodoo discussant prolate westerly swampy rotarian rabbi leatherwork thirtieth vaughan depress testimonial nbc husband moines biplane eloquent registrable bashaw cockle rank rumble rally westfield basophilic assign duopolist
nasturtium predatory conferred trudge davy sheik arrowroot omitting interpret work attack anheuser efflorescent unicorn drastic cornea flanagan cumbersome imprint yoder assault allis kate arlen hesitant afoul seashore consanguine dispelling eigenvector frizzle inspector gust edmund bootleg spiderwort scabrous maya lynch
posit dirac diffeomorphism pear barrow ocular chaw saskatchewan seaport carriage boyar chlordane apportion knockdown craftsman aggregate bolshevism gel greta courtroom messieurs crave conclusion fascism harmon orgiastic chuck across sicken cutlass admittance alyssum coin benedict opus
desiderata pole dewdrop stare boeotian sculpture centigrade dew fence cole bloodline catherine accessible mills operable pandora ulcerate bolshevist company colander siege gershwin drafty
actual bold happenstance dogleg aqua sinai mint fiche bottom capistrano grunt gallium belove sheriff desorption pillsbury scotsman fredholm stopwatch bakelite homecome annals talent airy pirogue thirty cutout
derbyshire einstein haiku cervantes epigrammatic choosy beet abbey beaumont upturn ample vendor dutchmen searchlight melanin aristotelian bridge radiosonde excerpt audit goblet auspices vreeland glutamine vowel belgium pea haven't pup sylvan they boustrophedon bloomington cutback hardbake accept defuse
warehouse mica roentgen empiric whittle cryptography germantown dormitory cecilia coercible
lorinda candid dagger mo automate peptide oboe beggary bock chafe backlash lobby enjoinder hologram therapy chalky dave conceptual grimaldi inconsequential backpack metal counterfeit
fe negotiate devote alaska centrist purine undulate carp autobiography competitive piedmont pout fletcher mcclain war dyke amphibious aile laotian decrypt competition incurrer pusey paranormal batavia compendium derby deface ernest synchrony opel barbecue monochromatic meltwater
Our US Licensed Doctors will
Prescribes Your Medication For Free
Medications Shipped Overnight To Your Do.
show
Me more
expedition southernmost audiotape latvia clarinet profusion vigorous fm wappinger criss bow scamp victorious convolve ingenuity ponce cherish elysee slang mortise lamp fugitive hydrangea incorruptible hutch satire creole ellsworth side uproar buss speedboat car dunham bromine spud pinwheel pegasus grosset solomon
churchwoman fuzz aniseikonic reginald russula incubus byline farthest patagonia shitepoke inboard pension haines valhalla epiphyseal granary colossi
fisk awaken carlin cytochemistry leeward leonard adolph awkward academia nominal penn tibet blind deft carmela orgiastic borroughs contretemps shed borne sunday cinnabar sulfide cravat augend flocculate dough classify
edgewise chalkline thomistic concentric earth flowerpot kaddish quartermaster verb transposable cautious don actuarial injurious betoken pseudo earn quit english bergstrom expulsion
kombu kipling koch dorothea cacophonist chosen polyphony inglorious hailstone edgy fail diabetes ndjamena
char bourbaki parapsychology hive peale atkins transshipping waist nautilus barrymore niagara throb amicable agriculture codetermine codicil penthouse wishy truism ywca cognate raze fellow accusative philodendron custer intellect acquitting minsky erato worth alamo guillemot multifarious throw commissary presence funereal
acanthus adamson sanderling cognitive upshot haphazard marriott stillbirth stride salient chaplain allure make glisten grandmother wham befog candlelight augusta genteel pathogen accipiter uniplex eclectic contractual elkhart calkins intuitive fingernail councilman emission sulfurous conferee contrive
cocoon eeoc avoidance merchant antiquary nazareth arduous befogging sis goldberg noah maroon convalescent pharmacology drunken indecisive ambition hydrochloride bondholder acadia sydney hereof dulse geoduck islamic chinamen melanesia sexton feminine dearth vida halfhearted sinusoidal oratory
darlene emphysematous beer hebrew rice circumscription smudgy looseleaf debugging bela precautionary whelan standeth became antipathy darpa
warsaw dazzle clinging deadlock bottommost nature autosuggestible temperance flimsy illimitable ablaze allergic winemake carpentry superfluity tepid punt craftsmen auschwitz buckeye aztec friar picnicking banach celesta northwestern psychopath ligand metabolite intellect salamander butene vacua
afro jamaica oppenheimer crud barry conspiracy phoneme denotation basemen cytolysis excel land arabesque p's productivity counterclockwise sideman bellingham breast euphoric fragmentation addis assay chomsky
----ALT--MPTY52048745045146--
--- Headers Follow ---
>From gjrcdgexmtoe@web.de Mon Jan 5 10:11:48 2004
Return-Path:
Delivered-To: grass-bugs@lists.intevation.de
Received: from mail.intevation.de (aktaia [212.95.126.10])
by lists.intevation.de (Postfix) with ESMTP id 1AEF313A08
for ; Mon, 5 Jan 2004 10:11:48 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
by mail.intevation.de (Postfix) with ESMTP id A1349372BF
for ; Mon, 5 Jan 2004 10:11:47 +0100 (CET)
Received: from MICROSOF-CA493B (unknown [203.217.117.100])
by mail.intevation.de (Postfix) with SMTP id 464AA36D7F
for ; Mon, 5 Jan 2004 10:11:40 +0100 (CET)
Received: from [203.217.117.100] by 2006h0sting.comIP with HTTP;
Mon, 05 Jan 2004 00:07:40 +0300
From: "Clayton Guthrie"
To: grass-bugs@intevation.de
Subject: Re: HPZDTWZ, opposed her wish
Mime-Version: 1.0
X-Mailer: mPOP Web-Mail 2.19
X-Originating-IP: [2006h0sting.comIP]
Date: Sun, 04 Jan 2004 16:04:40 -0500
Reply-To: "Clayton"
Content-Type: multipart/alternative;
boundary="--ALT--MPTY52048745045146"
Message-Id:
X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=3.0
tests=HTML_MESSAGE
X-Spam-Level:
-------------------------------------------- Managed by Request Tracker
From paul-grass at stjohnspoint.co.uk Mon Jan 5 07:50:23 2004
From: paul-grass at stjohnspoint.co.uk (Paul Kelly)
Date: Wed Nov 14 13:44:45 2007
Subject: [GRASS5] 5.3 shared libraries and other experimental changes
Message-ID:
Hello everyone
I made some changes to the 5.3 CVS that are quite experimental and will
probably break some things. However it allows to build the core GRASS
libraries as shared, which hugely reduces the size of the binary
distribution.
Please test it by adding the following option to the configure script:
--enable-gmake=no
This enables the alternate build mechanism, and I made some changes to the
Makefiles and used a more up-to-date version of the SC_CONFIG_CFLAGS macro
from the 5.7 aclocal.m4 (I took the latest from the Tcl CVS). This
SC_CONFIG_CFLAGS seems to have already fixed a lot of the issues discussed
in bug 2232 http://intevation.de/rt/webrt?serial_num=2232&display=History
I also added a section for Cygwin. This does not work currently as there
are problems with circular dependencies and resulting undefined symbols
when compiling libraries. In particular the dig2 and vect libraries had
circular dependencies. I didn't look into this more but it may just be a
compiler/linker flag we need like the "-undefined suppress" on OSX. There
was a new version of the OSX flags in Tcl but I commented this and copied
Markus's tried and tested version instead. Somebody could try changing
these flags just to see what happens if they have time.
r.terraflow doesn't compile properly also as its Gmakefile is non-standard
and the mk/genmake.sed conversion filter doesn't work on it. So it can't
be compiled with the alternate build mechanism.
If you wish to use the alternate build mechanism to build static
libraries, add --enable-shared=no as well. (--enable-shared=yes is the
default).
Feel free to fix up and tidy the changes I have made. Seems to work on
Linux (Red Hat 9) and IRIX (6.2) but I haven't tested anywhere else and
much needs tidied anyway. E.g. generating the makefiles for the alternate
build mechanism only needs to be done once but is done every time the
configure script is run, the way I have left it.
Other changes I made were
1) Change the name of the start-up script to grass53 (also for gmake and
gmakelinks). This is quite an important change and should probably go
higher up in this mail or maybe to the users' list.
2) Make --with-gdal the default as there are now several reports that the
gdalbridge code doesn't work.
3) Re-generate the binary nadgrids datum transformation files when
installing a binary distribution, as these are architecture-specific
files.
(For the alternate build mechanism make must be run from a separate build
directory; for make bindist and make srcdist you need to change back to
the top-level source directory and run make there.)
Something I kind of removed was that with mk/mid.mk.shlib (the old shared
library mechanism) the shared libraries had nice version numbers as part
of the filenames. SC_CONFIG_CFLAGS seems to put version numbers in for
some platforms but not very many. I hope it is all right without them as
the GRASS libraries will all be in their own version-specific
sub-directory anyway.
Please test with ./configure --enable-gmake=no and I would hope to make
this the default before the 5.3.0 release.
I will try to fix any bugs I have introduced with these changes but feel
free to tidy things and help with the Cygwin shared dll problem and
r.terraflow's Gmakefile would be much appreciated as well.
Paul
From paul at stjohnspoint.co.uk Mon Jan 5 07:47:08 2004
From: paul at stjohnspoint.co.uk (Paul Kelly)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] 5.3 shared libraries and other experimental changes
Message-ID:
Hello everyone
I made some changes to the 5.3 CVS that are quite experimental and will
probably break some things. However it allows to build the core GRASS
libraries as shared, which hugely reduces the size of the binary
distribution.
Please test it by adding the following option to the configure script:
--enable-gmake=no
This enables the alternate build mechanism, and I made some changes to the
Makefiles and used a more up-to-date version of the SC_CONFIG_CFLAGS macro
from the 5.7 aclocal.m4 (I took the latest from the Tcl CVS). This
SC_CONFIG_CFLAGS seems to have already fixed a lot of the issues discussed
in bug 2232 http://intevation.de/rt/webrt?serial_num=2232&display=History
I also added a section for Cygwin. This does not work currently as there
are problems with circular dependencies and resulting undefined symbols
when compiling libraries. In particular the dig2 and vect libraries had
circular dependencies. I didn't look into this more but it may just be a
compiler/linker flag we need like the "-undefined suppress" on OSX. There
was a new version of the OSX flags in Tcl but I commented this and copied
Markus's tried and tested version instead. Somebody could try changing
these flags just to see what happens if they have time.
r.terraflow doesn't compile properly also as its Gmakefile is non-standard
and the mk/genmake.sed conversion filter doesn't work on it. So it can't
be compiled with the alternate build mechanism.
If you wish to use the alternate build mechanism to build static
libraries, add --enable-shared=no as well. (--enable-shared=yes is the
default).
Feel free to fix up and tidy the changes I have made. Seems to work on
Linux (Red Hat 9) and IRIX (6.2) but I haven't tested anywhere else and
much needs tidied anyway. E.g. generating the makefiles for the alternate
build mechanism only needs to be done once but is done every time the
configure script is run, the way I have left it.
Other changes I made were
1) Change the name of the start-up script to grass53 (also for gmake and
gmakelinks). This is quite an important change and should probably go
higher up in this mail or maybe to the users' list.
2) Make --with-gdal the default as there are now several reports that the
gdalbridge code doesn't work.
3) Re-generate the binary nadgrids datum transformation files when
installing a binary distribution, as these are architecture-specific
files.
(For the alternate build mechanism make must be run from a separate build
directory; for make bindist and make srcdist you need to change back to
the top-level source directory and run make there.)
Something I kind of removed was that with mk/mid.mk.shlib (the old shared
library mechanism) the shared libraries had nice version numbers as part
of the filenames. SC_CONFIG_CFLAGS seems to put version numbers in for
some platforms but not very many. I hope it is all right without them as
the GRASS libraries will all be in their own version-specific
sub-directory anyway.
Please test with ./configure --enable-gmake=no and I would hope to make
this the default before the 5.3.0 release.
I will try to fix any bugs I have introduced with these changes but feel
free to tidy things and help with the Cygwin shared dll problem and
r.terraflow's Gmakefile would be much appreciated as well.
Paul
From neteler at itc.it Mon Jan 5 08:20:41 2004
From: neteler at itc.it (Markus Neteler)
Date: Wed Nov 14 13:44:46 2007
Subject: spam filter tuning - was: Re: [GRASS5] [bug #2276] (grass) Re: HPZDTWZ, opposed her wish
In-Reply-To: <20040105091149.0F9EC13BC1@lists.intevation.de>
References: <20040105091149.0F9EC13BC1@lists.intevation.de>
Message-ID: <20040105132041.GE15270@thuille.itc.it>
On Mon, Jan 05, 2004 at 10:11:49AM +0100, Request Tracker wrote:
> this bug's URL: http://intevation.de/rt/webrt?serial_num=2276
> -------------------------------------------------------------------------
>
> ----ALT--MPTY52048745045146
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 8bit
>
> nashua wean effusion impassive madagascar robe lesion
> dunk cyclist barlow demijohn assign harmonica
> archery digital inquire enlargeable koch hillbilly eisner picnic idiomatic
[...]
> Content-Type: multipart/alternative;
> boundary="--ALT--MPTY52048745045146"
> Message-Id:
> X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=3.0
> tests=HTML_MESSAGE
> X-Spam-Level:
Hi,
any suggestions how to deal with this type of spam (which contains
a set of random english words)?
Since the Request Tracker spam software fails, I am willing to apply
"bogofilter" to grass5. I am using "bogofilter" successfully for my
emails, but would have to tune it as well for above sort of spam.
With standard settings it suggests 50% spam probability on above
type of spam.
Hints welcome (even off-list is this is off-topic).
Maybe there is a bogofilter expert around.
Thanks
Markus
From glynn.clements at virgin.net Mon Jan 5 08:44:47 2004
From: glynn.clements at virgin.net (Glynn Clements)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] 5.3 shared libraries and other experimental changes
In-Reply-To:
References:
Message-ID: <16377.27215.246849.201821@cerise.nosuchdomain.co.uk>
Paul Kelly wrote:
> I also added a section for Cygwin. This does not work currently as there
> are problems with circular dependencies and resulting undefined symbols
> when compiling libraries. In particular the dig2 and vect libraries had
> circular dependencies. I didn't look into this more but it may just be a
> compiler/linker flag we need like the "-undefined suppress" on OSX.
Unlikely. Windows DLLs are quite different from Unix shared libraries.
In particular, Windows binaries (executables and DLLs) import specific
symbols from specific DLLs; OTOH, Unix binaries don't care where an
imported symbol comes from, so long as it actually gets provided.
AFAICT, the circular dig2/vect dependency must be recent; it doesn't
occur in the last version which I built. There were some circular
dependency issues with the DBMI code, but ISTR that Radim said that he
had fixed that.
> 3) Re-generate the binary nadgrids datum transformation files when
> installing a binary distribution, as these are architecture-specific
> files.
Is this related to cross-compilation?
--
Glynn Clements
From mlennert at club.worldonline.be Mon Jan 5 09:51:46 2004
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] 5.3 shared libraries and other experimental changes
In-Reply-To:
References:
Message-ID: <40060.164.15.134.155.1073314306.squirrel@moritz.homelinux.org>
Paul Kelly said:
> Hello everyone
> I made some changes to the 5.3 CVS that are quite experimental and will
> probably break some things. However it allows to build the core GRASS
> libraries as shared, which hugely reduces the size of the binary
> distribution.
>
> Please test it by adding the following option to the configure script:
> --enable-gmake=no
>
Works perfectly on Debian testing/unstable with following config:
/data/CVS/GRASSCVS/grass/configure --with-gdal --with-readline
--with-tcltk-includes=/usr/include/tcl8.4/
--with-postgres-includes="/usr/include/postgresql/
/usr/include/postgresql/internal/" --with-motif --with-proj
--enable-gmake=no
Very superficial testing has been succesful up to now.
However, when I add
--with-freetype --with-freetype-includes=/usr/include/freetype2
I get the following error in config.log (which I didn't get last time I
compiled):
configure:10927: checking for freetype/freetype.h
configure:10935: gcc -E -I/usr/include/freetype2 conftest.c >/dev/null
2>conftest.out
In file included from configure:10931:
/usr/include/freetype2/freetype/freetype.h:20:2: #error "`ft2build.h'
hasn't been included yet!"
/usr/include/freetype2/freetype/freetype.h:21:2: #error "Please always use
macros to include FreeType header files."
/usr/include/freetype2/freetype/freetype.h:22:2: #error "Example:"
/usr/include/freetype2/freetype/freetype.h:23:2: #error " #include
"
/usr/include/freetype2/freetype/freetype.h:24:2: #error " #include
FT_FREETYPE_H"
configure: failed program was:
#line 10930 "configure"
#include "confdefs.h"
#include
I use debain package libfreetype6-dev version 2.1.7-1 which installs
ft2build.h in /usr/include/.
Moritz
From paul-grass at stjohnspoint.co.uk Mon Jan 5 09:54:42 2004
From: paul-grass at stjohnspoint.co.uk (Paul Kelly)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] 5.3 shared libraries and other experimental changes
In-Reply-To: <16377.27215.246849.201821@cerise.nosuchdomain.co.uk>
References:
<16377.27215.246849.201821@cerise.nosuchdomain.co.uk>
Message-ID:
On Mon, 5 Jan 2004, Glynn Clements wrote:
>
> AFAICT, the circular dig2/vect dependency must be recent; it doesn't
> occur in the last version which I built. There were some circular
> dependency issues with the DBMI code, but ISTR that Radim said that he
> had fixed that.
Well I *think* that's what the problem was; I didn't have a good look at
it as I'd already spent time on other things. Perhaps it is not as bad as
that and just needs the compile re-ordered or something.
>
> > 3) Re-generate the binary nadgrids datum transformation files when
> > installing a binary distribution, as these are architecture-specific
> > files.
>
> Is this related to cross-compilation?
>
Yes---that would be the situation where you'd need to generate the files
upon installation to the target machine. We talked about this before---I
hope that is a satisfactory way to get around it.
From grass-bugs at intevation.de Mon Jan 5 10:19:04 2004
From: grass-bugs at intevation.de (Request Tracker)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] [bug #2277] (grass) sites data: ERROR: ebuf 158135,000000 nbuf 175101,000000
Message-ID: <20040105151904.7AE9E13A0F@lists.intevation.de>
this bug's URL: http://intevation.de/rt/webrt?serial_num=2277
-------------------------------------------------------------------------
Subject: sites data: ERROR: ebuf 158135,000000 nbuf 175101,000000
Platform: GNU/Linux/i386
grass obtained from: CVS
grass binary for platform: Compiled from Sources
GRASS Version: 5.3cvs checked out on 20040105
Tyring to access (d.sites, s.out.ascii) a sites file with the following format:
name|specprod8601
labels|east north Rcode varint varfloat comcod
158135,000000|175101,000000|#1 %116,198 %7,000 %23094
105265,000000|196713,000000|#2 %97,6064 %1,000 %44021
173626,000000|175036,000000|#3 %84,3267 %1,000 %24062
154166,000000|179702,000000|#4 %83,4805 %4,000 %23088
148799,000000|172180,000000|#5 %82,8372 %1,000 %21004
155340,000000|177049,000000|#6 %75,8749 %17,000 %23047
154556,000000|170726,000000|#7 %74,3438 %2,000 %21018
etc...531 sites
I get the follwing error:
ERROR: ebuf 158135,000000 nbuf 175101,000000
-------------------------------------------- Managed by Request Tracker
From glynn.clements at virgin.net Mon Jan 5 10:33:58 2004
From: glynn.clements at virgin.net (Glynn Clements)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] 5.3 shared libraries and other experimental changes
In-Reply-To:
References:
<16377.27215.246849.201821@cerise.nosuchdomain.co.uk>
Message-ID: <16377.33766.230672.996338@cerise.nosuchdomain.co.uk>
Paul Kelly wrote:
> > AFAICT, the circular dig2/vect dependency must be recent; it doesn't
> > occur in the last version which I built. There were some circular
> > dependency issues with the DBMI code, but ISTR that Radim said that he
> > had fixed that.
>
> Well I *think* that's what the problem was; I didn't have a good look at
> it as I'd already spent time on other things. Perhaps it is not as bad as
> that and just needs the compile re-ordered or something.
Sorry, my mistake. I was looking at the "ldd" output, which doesn't
show circular dependencies. However, examining the "nm" output
indicates that there is indeed a circular dependency, specifically
that dig2 requires V2_read_line in three files:
chk_inside.o: U V2_read_line
find_area.o: U V2_read_line
point_t_line.o: U V2_read_line
This isn't an issue on Unix, so long as any binary which links against
libdig2 also links against libvect. It is an issue for Windows DLLs.
Can anyone provide a quick summary of the relationship between libdig2
and libvect?
> > > 3) Re-generate the binary nadgrids datum transformation files when
> > > installing a binary distribution, as these are architecture-specific
> > > files.
> >
> > Is this related to cross-compilation?
> >
>
> Yes---that would be the situation where you'd need to generate the files
> upon installation to the target machine. We talked about this before---I
> hope that is a satisfactory way to get around it.
Yes, although the same issue also applies to src/fonts/for_grass.
--
Glynn Clements
From glynn.clements at virgin.net Mon Jan 5 10:13:21 2004
From: glynn.clements at virgin.net (Glynn Clements)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] 5.3 shared libraries and other experimental changes
In-Reply-To: <40060.164.15.134.155.1073314306.squirrel@moritz.homelinux.org>
References:
<40060.164.15.134.155.1073314306.squirrel@moritz.homelinux.org>
Message-ID: <16377.32529.688169.856604@cerise.nosuchdomain.co.uk>
Moritz Lennert wrote:
> > I made some changes to the 5.3 CVS that are quite experimental and will
> > probably break some things. However it allows to build the core GRASS
> > libraries as shared, which hugely reduces the size of the binary
> > distribution.
> >
> > Please test it by adding the following option to the configure script:
> > --enable-gmake=no
> >
>
> Works perfectly on Debian testing/unstable with following config:
>
> /data/CVS/GRASSCVS/grass/configure --with-gdal --with-readline
> --with-tcltk-includes=/usr/include/tcl8.4/
> --with-postgres-includes="/usr/include/postgresql/
> /usr/include/postgresql/internal/" --with-motif --with-proj
> --enable-gmake=no
>
> Very superficial testing has been succesful up to now.
>
>
> However, when I add
>
> --with-freetype --with-freetype-includes=/usr/include/freetype2
>
> I get the following error in config.log (which I didn't get last time I
> compiled):
>
>
> configure:10927: checking for freetype/freetype.h
> configure:10935: gcc -E -I/usr/include/freetype2 conftest.c >/dev/null
> 2>conftest.out
> In file included from configure:10931:
> /usr/include/freetype2/freetype/freetype.h:20:2: #error "`ft2build.h'
> hasn't been included yet!"
> /usr/include/freetype2/freetype/freetype.h:21:2: #error "Please always use
> macros to include FreeType header files."
> /usr/include/freetype2/freetype/freetype.h:22:2: #error "Example:"
> /usr/include/freetype2/freetype/freetype.h:23:2: #error " #include
> "
> /usr/include/freetype2/freetype/freetype.h:24:2: #error " #include
> FT_FREETYPE_H"
> configure: failed program was:
> #line 10930 "configure"
> #include "confdefs.h"
> #include
This has nothing to do with Paul's changes; you will get the same
error from any other version of GRASS.
Either use a different version of FreeType2, or build without it.
--
Glynn Clements
From grass-bugs at intevation.de Tue Jan 6 06:12:04 2004
From: grass-bugs at intevation.de (guest user via RT)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] [bug #2277] (grass) sites data: ERROR: ebuf 158135,000000 nbuf 175101,000000
Message-ID: <20040106111204.E489613B73@lists.intevation.de>
It must be '.' instead of ',' (we speak US here):
Eg
158135.000000 175101.000000 ...
Change it with a text editor.
Markus
-------------------------------------------- Managed by Request Tracker
From neteler at itc.it Tue Jan 6 09:20:56 2004
From: neteler at itc.it (Markus Neteler)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] 5.3 shared libraries and other experimental changes
In-Reply-To:
References:
Message-ID: <20040106142056.GC17460@thuille.itc.it>
Hello Paul,
thanks for the improvements - it compiles perfectly on Mandrake 9.1.
(I have modified the mk/Makefile.docs slightly).
I have no troubles to run 'make' in the main directory.
A (un)related question:
Must the links to front.end necessarily be hard links?
They are created in:
src/CMD/generic/MAKELINKS.sh
Markus
On Mon, Jan 05, 2004 at 12:47:08PM +0000, Paul Kelly wrote:
> Hello everyone
> I made some changes to the 5.3 CVS that are quite experimental and will
> probably break some things. However it allows to build the core GRASS
> libraries as shared, which hugely reduces the size of the binary
> distribution.
>
> Please test it by adding the following option to the configure script:
> --enable-gmake=no
>
> This enables the alternate build mechanism, and I made some changes to the
> Makefiles and used a more up-to-date version of the SC_CONFIG_CFLAGS macro
> from the 5.7 aclocal.m4 (I took the latest from the Tcl CVS). This
> SC_CONFIG_CFLAGS seems to have already fixed a lot of the issues discussed
> in bug 2232 http://intevation.de/rt/webrt?serial_num=2232&display=History
>
> I also added a section for Cygwin. This does not work currently as there
> are problems with circular dependencies and resulting undefined symbols
> when compiling libraries. In particular the dig2 and vect libraries had
> circular dependencies. I didn't look into this more but it may just be a
> compiler/linker flag we need like the "-undefined suppress" on OSX. There
> was a new version of the OSX flags in Tcl but I commented this and copied
> Markus's tried and tested version instead. Somebody could try changing
> these flags just to see what happens if they have time.
>
> r.terraflow doesn't compile properly also as its Gmakefile is non-standard
> and the mk/genmake.sed conversion filter doesn't work on it. So it can't
> be compiled with the alternate build mechanism.
>
> If you wish to use the alternate build mechanism to build static
> libraries, add --enable-shared=no as well. (--enable-shared=yes is the
> default).
>
> Feel free to fix up and tidy the changes I have made. Seems to work on
> Linux (Red Hat 9) and IRIX (6.2) but I haven't tested anywhere else and
> much needs tidied anyway. E.g. generating the makefiles for the alternate
> build mechanism only needs to be done once but is done every time the
> configure script is run, the way I have left it.
>
> Other changes I made were
>
> 1) Change the name of the start-up script to grass53 (also for gmake and
> gmakelinks). This is quite an important change and should probably go
> higher up in this mail or maybe to the users' list.
>
> 2) Make --with-gdal the default as there are now several reports that the
> gdalbridge code doesn't work.
>
> 3) Re-generate the binary nadgrids datum transformation files when
> installing a binary distribution, as these are architecture-specific
> files.
>
> (For the alternate build mechanism make must be run from a separate build
> directory; for make bindist and make srcdist you need to change back to
> the top-level source directory and run make there.)
>
> Something I kind of removed was that with mk/mid.mk.shlib (the old shared
> library mechanism) the shared libraries had nice version numbers as part
> of the filenames. SC_CONFIG_CFLAGS seems to put version numbers in for
> some platforms but not very many. I hope it is all right without them as
> the GRASS libraries will all be in their own version-specific
> sub-directory anyway.
>
> Please test with ./configure --enable-gmake=no and I would hope to make
> this the default before the 5.3.0 release.
> I will try to fix any bugs I have introduced with these changes but feel
> free to tidy things and help with the Cygwin shared dll problem and
> r.terraflow's Gmakefile would be much appreciated as well.
>
> Paul
>
--
Markus Neteler http://mpa.itc.it
ITC-irst - Centro per la Ricerca Scientifica e Tecnologica
MPBA - Predictive Models for Biol. & Environ. Data Analysis
Via Sommarive, 18 - 38050 Povo (Trento), Italy
From flias at ecosconsult.com.br Tue Jan 6 12:46:13 2004
From: flias at ecosconsult.com.br (Flavio)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] keeping Label after "break line"
Message-ID: <200401061546.13486.flias@ecosconsult.com.br>
All,
does anyone knows how to keep (store) the label of a polygno after we do a
break line. for instance: assume I have a polygno A and I want to split it
into 2 new polygnos B and C. Then, I want to assign the label of polygno A
to B and create new label for C.
I have seen some discution about this on the archives (July 2002 -
http://intevation.de/rt/webrt?serial_num=1177&display=History) about a patch
that could help resolve this problem. Is there any thing newer been done
about this? Does the patch works?
Thanks a lot...
Flavio
_________________________________
Protegido - Inflex com uvscan antivirus
Linux - Sendmail
From glynn.clements at virgin.net Tue Jan 6 16:57:28 2004
From: glynn.clements at virgin.net (Glynn Clements)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] [bug #2277] (grass) sites data: ERROR: ebuf 158135,000000 nbuf 175101,000000
In-Reply-To: <20040106111204.E489613B73@lists.intevation.de>
References: <20040106111204.E489613B73@lists.intevation.de>
Message-ID: <16379.12104.302691.845411@cerise.nosuchdomain.co.uk>
guest user via RT wrote:
> Tyring to access (d.sites, s.out.ascii) a sites file with the
> following format:
>
> name|specprod8601
> labels|east north Rcode varint varfloat comcod
> 158135,000000|175101,000000|#1 %116,198 %7,000 %23094
> 105265,000000|196713,000000|#2 %97,6064 %1,000 %44021
> 173626,000000|175036,000000|#3 %84,3267 %1,000 %24062
> 154166,000000|179702,000000|#4 %83,4805 %4,000 %23088
> 148799,000000|172180,000000|#5 %82,8372 %1,000 %21004
> 155340,000000|177049,000000|#6 %75,8749 %17,000 %23047
> 154556,000000|170726,000000|#7 %74,3438 %2,000 %21018
> etc...531 sites
>
> I get the follwing error:
>
> ERROR: ebuf 158135,000000 nbuf 175101,000000
> It must be '.' instead of ',' (we speak US here):
>
> Eg
> 158135.000000 175101.000000 ...
>
> Change it with a text editor.
Out of curiousity, how was that sites file generated? I'm fairly sure
that it wasn't with any standard GRASS module, but it might be some
obscure contrib module, or an add-on for which we might get queries
(in the same way that these lists often get queries regarding
GRASSlinks etc).
--
Glynn Clements
From glynn.clements at virgin.net Tue Jan 6 17:06:36 2004
From: glynn.clements at virgin.net (Glynn Clements)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] 5.3 shared libraries and other experimental changes
In-Reply-To: <20040106142056.GC17460@thuille.itc.it>
References:
<20040106142056.GC17460@thuille.itc.it>
Message-ID: <16379.12652.277513.225817@cerise.nosuchdomain.co.uk>
Markus Neteler wrote:
> thanks for the improvements - it compiles perfectly on Mandrake 9.1.
> (I have modified the mk/Makefile.docs slightly).
>
> I have no troubles to run 'make' in the main directory.
>
> A (un)related question:
>
> Must the links to front.end necessarily be hard links?
No; so long as front.end can get the module name from argv[0], it will
work.
The main advantage of using hard links is that all Unix systems
support them, whereas symbolic links were a BSD extension. OTOH, any
Unix system which doesn't have symbolic links probably wouldn't have a
lot of other things which GRASS requires, and probably wouldn't be
much use for anything except a museum exhibit.
> They are created in:
> src/CMD/generic/MAKELINKS.sh
The alternate build system doesn't use that script; "ln" is called
directly from the "links" target in the Makefile.
BTW, the other stuff which was tacked onto the end of the "links"
target doesn't belong there; I'll add a separate "post-compile"
target.
--
Glynn Clements
From mlennert at club.worldonline.be Wed Jan 7 05:10:11 2004
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] [bug #2277] (grass) sites data: ERROR: ebuf 158135,
000000 nbuf 175101,000000
In-Reply-To: <16379.12104.302691.845411@cerise.nosuchdomain.co.uk>
References: <20040106111204.E489613B73@lists.intevation.de>
<16379.12104.302691.845411@cerise.nosuchdomain.co.uk>
Message-ID: <45441.164.15.134.155.1073470211.squirrel@moritz.homelinux.org>
Glynn Clements said:
>
> guest user via RT wrote:
>
>> Tyring to access (d.sites, s.out.ascii) a sites file with the
>> following format:
>>
>> name|specprod8601
>> labels|east north Rcode varint varfloat comcod
>> 158135,000000|175101,000000|#1 %116,198 %7,000 %23094
>> 105265,000000|196713,000000|#2 %97,6064 %1,000 %44021
>> 173626,000000|175036,000000|#3 %84,3267 %1,000 %24062
>> 154166,000000|179702,000000|#4 %83,4805 %4,000 %23088
>> 148799,000000|172180,000000|#5 %82,8372 %1,000 %21004
>> 155340,000000|177049,000000|#6 %75,8749 %17,000 %23047
>> 154556,000000|170726,000000|#7 %74,3438 %2,000 %21018
>> etc...531 sites
>>
>> I get the follwing error:
>>
>> ERROR: ebuf 158135,000000 nbuf 175101,000000
>
>> It must be '.' instead of ',' (we speak US here):
>>
>> Eg
>> 158135.000000 175101.000000 ...
>>
>> Change it with a text editor.
>
> Out of curiousity, how was that sites file generated? I'm fairly sure
> that it wasn't with any standard GRASS module, but it might be some
> obscure contrib module, or an add-on for which we might get queries
> (in the same way that these lists often get queries regarding
> GRASSlinks etc).
No, it was certainly generated with a home made script. I often use R to
create data and colored circles or triangles that I then map out with
ps.map. For that I copy files directly into the sites directory (I guess I
should better use s.in.ascii...)
I don't know why I didn't notice this problem before, however...maybe I
never used this specific site file.
Moritz
From kwythers at umn.edu Wed Jan 7 10:24:50 2004
From: kwythers at umn.edu (Kirk R. Wythers)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] raster georectification
Message-ID:
I have a set of scanned maps that I want to georectify. However I am
unsure of the most efficient way to handle the three images (three
color bands) associated with each image. I have imported them into a
temporary xy location and can display with d.rgb (takes about 10
seconds to display). I have grouped all with i.group, and used i.target
to set up new target location and mapset. Now I am ready to use
i.points. My question is this: Since it looks like all three element
maps (rgb) need to have i.points run with associated coordinates,
should the three elements of the color table me merged first in order
to reduce the number of maps that need georeferencing, or is assigning
coordinates to all three bands the standard approach? I read in "Open
Source GIS: A Grass GIS Approach (Neteler and Mitsova) that one of the
reasons that scanned color maps are broken into color bands is to
reduce computational overhead and there by speed up image processing.
Does it make sence to merge these maps first in order to reduce number
of maps that need georectifying, or would I be more than paying for
that time savings with very slow image processing?
btw... using grass5.7
Thanks
Kirk
------------------------------------------------------------------------
Kirk R. Wythers tel: 612.625.2261
Dept. of Forest Resources fax: 612.625.5212
University of Minnesota email: kwythers@umn.edu
------------------------------------------------------------------------
From paul-grass at stjohnspoint.co.uk Wed Jan 7 10:49:15 2004
From: paul-grass at stjohnspoint.co.uk (Paul Kelly)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] Re: GRASS 5.3 with shared libs
In-Reply-To: <20040106131041.GA17381@thuille.itc.it>
References: <20040105171803.GC15597@thuille.itc.it>
<20040106110640.GB17041@thuille.itc.it> <20040106131041.GA17381@thuille.itc.it>
Message-ID:
Hello Markus
On Tue, 6 Jan 2004, Markus Neteler wrote:
> Hello Paul,
>
> I found and fixed the problem with 'documents':
> The problem was the identical directory name in the main dir,
> I renamed the target in mk/Makefile.in, now it works
> perfectly.
>
> Markus
>
> On Tue, Jan 06, 2004 at 12:06:40PM +0100, Markus Neteler wrote:
> > > >
> > > > Note that I was launching 'make' in the main source directory which
> > > > worked perfectly. Or should it be
> > >
> > > I don't understand how you got that to work as when I try that it builds
> > > using the old gmake5 system.
> >
> > Strange - not for me.
> >
> > I ran:
> >
> > [first elimination of all .o files, LIB* OBJ* ]
> >
> > rm Makefile
> > rm -rf dist.i686-pc-linux-gnu bin.i686-pc-linux-gnu/
> >
> > CFLAGS="-O3 -Wall" ./configure --with-proj --without-freetype \
> > --with-postgres-includes=/usr/include/pgsql \
> > --with-cxx \
> > --enable-gmake=no
> >
> > [creates all makefiles etc. One error:
I made a fresh checkout of the CVS on a RedHat 7.3 system and tried that
exact configure line from the top-level source directory and got this
error:
[...]
checking for source directory... /home/paulk/src/grass
checking for build directory... /home/paulk/src/grass
checking for Build Mechanism to be used... Alternate
configure: error: *** Build directory should not be the same as source
directory for the alternate build mechanism. Create a separate build
directory and run again, e.g. mkdir grass-build; cd grass-build;
../configure (see mk/README)
which is what I intended to happen as while it might be possible to run
the alternate build system from the top-level source directory it got very
messy with all the source directories filled up with .o files that weren't
easily removed. Also the 'old' Makefile got overwritten so you couldn't do
make bindist or make srcdist (I didn't bother copying these targets into
mk/Makefile.in yet).
The way I checked for the directory configure was being run from was like:
if test "$BUILD_MECH" = Alternate ; then
if test "$SRCDIR" = "$DSTDIR" ; then
AC_MSG_ERROR([*** Build directory should not be the same as source \
directory for the alternate build mechanism. Create a separate build \
directory and run again, e.g. mkdir grass-build; cd grass-build; ../configure \
(see mk/README)]);
else
SC_ENABLE_SHARED
fi
fi
in configure.in.
Perhaps there is something wrong with the second line above (not
portable)?
In general I thought with the alternate build system it must be run from a
separate build directory. That was also why I copied the error.log file
back to the top level source directory as the POST_INSTALL.sh script
looked for it there. Again, the contents of POST_INSTALL.sh could be
duplicated in mk/Makefile.in but I didn't want to change more things than
I had to to make it work.
Perhaps it would be nice if the alternate build system could create its
own build directory automatically if it detects it is being run from the
top-level of the source. I thought about this but decided that was being
too clever.
It is worth tidying it up though but I was under the impression that with
the alternate build system we really should use a separate build
directory (and that is how I tested it).
Moritz: did you do it this way?
Paul
From neteler at itc.it Wed Jan 7 11:00:16 2004
From: neteler at itc.it (Markus Neteler)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] Re: GRASS 5.3 with shared libs
In-Reply-To:
References: <20040105171803.GC15597@thuille.itc.it> <20040106110640.GB17041@thuille.itc.it> <20040106131041.GA17381@thuille.itc.it>
Message-ID: <20040107160016.GQ3467@thuille.itc.it>
Hello Paul
On Wed, Jan 07, 2004 at 03:49:15PM +0000, Paul Kelly wrote:
> Hello Markus
>
> On Tue, 6 Jan 2004, Markus Neteler wrote:
>
> > Hello Paul,
> >
> > I found and fixed the problem with 'documents':
> > The problem was the identical directory name in the main dir,
> > I renamed the target in mk/Makefile.in, now it works
> > perfectly.
> >
> > Markus
> >
> > On Tue, Jan 06, 2004 at 12:06:40PM +0100, Markus Neteler wrote:
> > > > >
> > > > > Note that I was launching 'make' in the main source directory which
> > > > > worked perfectly. Or should it be
> > > >
> > > > I don't understand how you got that to work as when I try that it builds
> > > > using the old gmake5 system.
> > >
> > > Strange - not for me.
> > >
> > > I ran:
> > >
> > > [first elimination of all .o files, LIB* OBJ* ]
> > >
> > > rm Makefile
> > > rm -rf dist.i686-pc-linux-gnu bin.i686-pc-linux-gnu/
> > >
> > > CFLAGS="-O3 -Wall" ./configure --with-proj --without-freetype \
> > > --with-postgres-includes=/usr/include/pgsql \
> > > --with-cxx \
> > > --enable-gmake=no
> > >
> > > [creates all makefiles etc. One error:
>
> I made a fresh checkout of the CVS on a RedHat 7.3 system and tried that
> exact configure line from the top-level source directory and got this
> error:
>
> [...]
> checking for source directory... /home/paulk/src/grass
> checking for build directory... /home/paulk/src/grass
> checking for Build Mechanism to be used... Alternate
> configure: error: *** Build directory should not be the same as source
> directory for the alternate build mechanism. Create a separate build
> directory and run again, e.g. mkdir grass-build; cd grass-build;
> ../configure (see mk/README)
Have never seen this message :-)
> which is what I intended to happen as while it might be possible to run
> the alternate build system from the top-level source directory it got very
> messy with all the source directories filled up with .o files that weren't
> easily removed.
Well, I easily remove them with a 'find' command on all '*.o' files.
> Also the 'old' Makefile got overwritten so you couldn't do
> make bindist or make srcdist (I didn't bother copying these targets into
> mk/Makefile.in yet).
In fact I didn't try make bindist or make srcdist as I use GRASS
directly from the ./dist.$ARCH directory. At time I am away from
that Mandrake box.
But those targets could be added, right?
> The way I checked for the directory configure was being run from was like:
>
> if test "$BUILD_MECH" = Alternate ; then
> if test "$SRCDIR" = "$DSTDIR" ; then
> AC_MSG_ERROR([*** Build directory should not be the same as source \
> directory for the alternate build mechanism. Create a separate build \
> directory and run again, e.g. mkdir grass-build; cd grass-build; ../configure \
> (see mk/README)]);
> else
> SC_ENABLE_SHARED
> fi
> fi
>
> in configure.in.
> Perhaps there is something wrong with the second line above (not
> portable)?
Mhh, no idea right now.
> In general I thought with the alternate build system it must be run from a
> separate build directory.
As I don't know how to do that, I happily launched it from the
main directory (which should be IMHO allowed).
> That was also why I copied the error.log file
> back to the top level source directory as the POST_INSTALL.sh script
> looked for it there. Again, the contents of POST_INSTALL.sh could be
> duplicated in mk/Makefile.in but I didn't want to change more things than
> I had to to make it work.
> Perhaps it would be nice if the alternate build system could create its
> own build directory automatically if it detects it is being run from the
> top-level of the source. I thought about this but decided that was being
> too clever.
>
> It is worth tidying it up though but I was under the impression that with
> the alternate build system we really should use a separate build
> directory (and that is how I tested it).
I still don't see the advantage to be forced to use a separate build
directory - please explain again.
> Moritz: did you do it this way?
>
> Paul
>
Markus
From paul-grass at stjohnspoint.co.uk Wed Jan 7 11:16:11 2004
From: paul-grass at stjohnspoint.co.uk (Paul Kelly)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] Re: GRASS 5.3 with shared libs
In-Reply-To: <20040107160016.GQ3467@thuille.itc.it>
References: <20040105171803.GC15597@thuille.itc.it>
<20040106110640.GB17041@thuille.itc.it> <20040106131041.GA17381@thuille.itc.it>
<20040107160016.GQ3467@thuille.itc.it>
Message-ID:
On Wed, 7 Jan 2004, Markus Neteler wrote:
> > I made a fresh checkout of the CVS on a RedHat 7.3 system and tried that
> > exact configure line from the top-level source directory and got this
> > error:
> >
> > [...]
> > checking for source directory... /home/paulk/src/grass
> > checking for build directory... /home/paulk/src/grass
> > checking for Build Mechanism to be used... Alternate
> > configure: error: *** Build directory should not be the same as source
> > directory for the alternate build mechanism. Create a separate build
> > directory and run again, e.g. mkdir grass-build; cd grass-build;
> > ../configure (see mk/README)
>
> Have never seen this message :-)
Yes that's very strange!
>
> > which is what I intended to happen as while it might be possible to run
> > the alternate build system from the top-level source directory it got very
> > messy with all the source directories filled up with .o files that weren't
> > easily removed.
>
> Well, I easily remove them with a 'find' command on all '*.o' files.
Yes that could be added to a makefile somewhere easily enough
>
> > Also the 'old' Makefile got overwritten so you couldn't do
> > make bindist or make srcdist (I didn't bother copying these targets into
> > mk/Makefile.in yet).
>
> In fact I didn't try make bindist or make srcdist as I use GRASS
> directly from the ./dist.$ARCH directory. At time I am away from
> that Mandrake box.
>
> But those targets could be added, right?
Yes certainly wouldn't be much more work at all.
> > It is worth tidying it up though but I was under the impression that with
> > the alternate build system we really should use a separate build
> > directory (and that is how I tested it).
>
> I still don't see the advantage to be forced to use a separate build
> directory - please explain again.
It was really just that I felt that was the way Glynn had designed it and
there would be fewer complications and things likely to go wrong if it is
done that way. I just wanted to minimise the amount of work I had to do to
get it working. But it looks now like it mightn't require many if any
(now) changes to run it from the normal place.
To do:
provide some way of deleting the *.o files.
Move the checks in POST_INSTALL.sh somewhere else (probably into
mk/Makefile?)
Add srcdist and bindist to mk/Makefile
Paul
From mlennert at club.worldonline.be Wed Jan 7 11:49:37 2004
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] Re: GRASS 5.3 with shared libs
In-Reply-To:
References:
<20040105171803.GC15597@thuille.itc.it><20040106110640.GB17041@thuille.itc.it>
<20040106131041.GA17381@thuille.itc.it>
Message-ID: <47664.164.15.134.155.1073494177.squirrel@moritz.homelinux.org>
Paul Kelly said:
> It is worth tidying it up though but I was under the impression that with
> the alternate build system we really should use a separate build
> directory (and that is how I tested it).
> Moritz: did you do it this way?
>
Yes, I create a grass_build directory and built in there. It worked
perfectly and instead of running a make clean fo some sorts, I just erased
the entire directory once I had installed GRASS.
Moritz
From mlennert at club.worldonline.be Wed Jan 7 11:57:44 2004
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] raster georectification
In-Reply-To:
References:
Message-ID: <47721.164.15.134.155.1073494664.squirrel@moritz.homelinux.org>
Kirk R. Wythers said:
> I have a set of scanned maps that I want to georectify. However I am
> unsure of the most efficient way to handle the three images (three
> color bands) associated with each image. I have imported them into a
> temporary xy location and can display with d.rgb (takes about 10
> seconds to display). I have grouped all with i.group, and used i.target
> to set up new target location and mapset. Now I am ready to use
> i.points. My question is this: Since it looks like all three element
> maps (rgb) need to have i.points run with associated coordinates,
Why do you need to run i.points three times ? Since they are grouped and
i.points and i.rectify work by group (you can determine which images in a
group you wish to rectify), you only have to use i.points once for
rectifying all images in a group.
> should the three elements of the color table me merged first in order
> to reduce the number of maps that need georeferencing, or is assigning
> coordinates to all three bands the standard approach? I read in "Open
> Source GIS: A Grass GIS Approach (Neteler and Mitsova) that one of the
> reasons that scanned color maps are broken into color bands is to
> reduce computational overhead and there by speed up image processing.
> Does it make sence to merge these maps first in order to reduce number
> of maps that need georectifying, or would I be more than paying for
> that time savings with very slow image processing?
It depends of what kind of processing you wish to do and what type of
image you have. Often one uses a specific band for specific analysis or
you can calculate indicators using the different bands, so it is generally
not advisable to merge them, not for speed reasons but for analytic
reasons.
However the merged image could help you with i.points since sometimes it
is easier to identify a point on a merged image than on an individual
band.
Moritz
From glynn.clements at virgin.net Wed Jan 7 12:24:04 2004
From: glynn.clements at virgin.net (Glynn Clements)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] Re: GRASS 5.3 with shared libs
In-Reply-To:
References: <20040105171803.GC15597@thuille.itc.it>
<20040106110640.GB17041@thuille.itc.it>
<20040106131041.GA17381@thuille.itc.it>
Message-ID: <16380.16564.509310.855404@cerise.nosuchdomain.co.uk>
Paul Kelly wrote:
> The way I checked for the directory configure was being run from was like:
>
> if test "$BUILD_MECH" = Alternate ; then
> if test "$SRCDIR" = "$DSTDIR" ; then
> AC_MSG_ERROR([*** Build directory should not be the same as source \
> directory for the alternate build mechanism. Create a separate build \
> directory and run again, e.g. mkdir grass-build; cd grass-build; ../configure \
> (see mk/README)]);
> else
> SC_ENABLE_SHARED
> fi
> fi
>
> in configure.in.
> Perhaps there is something wrong with the second line above (not
> portable)?
I suppose that it's possible that $SRCDIR and $DSTDIR could refer to
the same directory without being identical, although this seems
unlikely.
Both SRCDIR and DSTDIR are set from the output from $pwd, which is set
using AC_PATH_PROG, and so should contain the full path to the "pwd"
executable. I can't see how the "pwd" program could return different
strings for the same directory.
OTOH, if AC_PATH_PROG failed (which seems pretty unlikely), $pwd would
default to just "pwd", which may refer to a shell built-in, which can
return different strings for the same directory (e.g. if there are any
symlinks involved).
An alternative approach would be to check for the existence of a known
file. E.g. if $DSTDIR/configure exists, you're probably trying to
build in the source directory.
> In general I thought with the alternate build system it must be run from a
> separate build directory.
AFAIK, it will work if run from within the source directory. However,
it doesn't have a working "clean" target; it doesn't need one: you can
just run "rm -rf" on the build directory. But you certainly don't want
to do that if $SRCDIR == $DSTDIR.
> That was also why I copied the error.log file
> back to the top level source directory as the POST_INSTALL.sh script
> looked for it there. Again, the contents of POST_INSTALL.sh could be
> duplicated in mk/Makefile.in but I didn't want to change more things than
> I had to to make it work.
Alternatively, pass $DSTDIR to POST_INSTALL.sh and have it look for
$DSTDIR/error.log.
I removed the copying of error.log because the alternate build
mechanism isn't supposed to require write access to the source
directory (e.g. to allow building from a source tree which resides on
a read-only NFS export).
> Perhaps it would be nice if the alternate build system could create its
> own build directory automatically if it detects it is being run from the
> top-level of the source. I thought about this but decided that was being
> too clever.
That's my feeling too. That would require configure to choose a build
directory. The directory would definitely have to be writable, and
ideally would have to be on a filesystem with sufficient free space,
and it probably shouldn't choose the directory which you used last
time in case you still wanted to keep that build around (another
reason for the alternate build system was to support keeping multiple
builds around for the same architecture).
> It is worth tidying it up though but I was under the impression that with
> the alternate build system we really should use a separate build
> directory (and that is how I tested it).
That was the idea.
--
Glynn Clements
From kwythers at umn.edu Wed Jan 7 15:42:08 2004
From: kwythers at umn.edu (Kirk R. Wythers)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] raster georectification
In-Reply-To: <47721.164.15.134.155.1073494664.squirrel@moritz.homelinux.org>
References: <47721.164.15.134.155.1073494664.squirrel@moritz.homelinux.org>
Message-ID:
On Jan 7, 2004, at 10:57 AM, Moritz Lennert wrote:
>>
>
> Why do you need to run i.points three times ? Since they are grouped
> and
> i.points and i.rectify work by group (you can determine which images
> in a
> group you wish to rectify), you only have to use i.points once for
> rectifying all images in a group.
Perhaps I am misusing i.group. I started with 6 scanned maps, each of a
different geographic space representing adjacent townships and ranges
(essentially a 3X2 matrix of a single larger map). After importing into
GRASS, I was left with 3 color bands for each map (rgb). All 6 maps
need to be assembled into a single map with all color bands. I defined
a single group with i.group. I now believe that I should have defined 6
separate groups with i.group (one for each of the 6 geographic
locations). So the question is: in what order should these steps be
completed?
1. merge rgb bands into a single map for each of the 3 bands
2. georectify with i.points
3. overlay adjacent maps
>>
>
> It depends of what kind of processing you wish to do and what type of
> image you have.
These maps are hand drawn forest with color pencils (nothing fancy but
very detailed and of historic significance). I don't want to loose the
"wow" effect of looking at all the colors together until they get heads
up vectorized.
>
------------------------------------------------------------------------
Kirk R. Wythers tel: 612.625.2261
Dept. of Forest Resources fax: 612.625.5212
University of Minnesota email: kwythers@umn.edu
------------------------------------------------------------------------
From chris at fonnesbeck.org Wed Jan 7 15:57:57 2004
From: chris at fonnesbeck.org (Christopher Fonnesbeck)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] v.select attributes problem in 5.7
Message-ID: <2BC40F2C-4154-11D8-80E7-000A956FDAC0@fonnesbeck.org>
When running v.select on a vector coverage with attributes stored in a
relational database (MySQL), the new coverage of selected polygons is
associated with a new table that has as many entries as the original
table, even though the number of selected polygons is significantly
smaller. Is this a bug, or is there another way of getting an attribute
table that contains only the attributes for the selected polygons?
Running 5.7 on OSX 10.3
Thanks
Chris Fonnesbeck
--
Christopher J. Fonnesbeck ( c h r i s @ f o n n e s b e c k . o r g )
Georgia Cooperative Fish & Wildlife Research Unit, University of Georgia
From glynn.clements at virgin.net Wed Jan 7 20:22:48 2004
From: glynn.clements at virgin.net (Glynn Clements)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] raster georectification
In-Reply-To:
References:
<47721.164.15.134.155.1073494664.squirrel@moritz.homelinux.org>
Message-ID: <16380.45288.444791.665205@cerise.nosuchdomain.co.uk>
Kirk R. Wythers wrote:
> > Why do you need to run i.points three times ? Since they are grouped
> > and
> > i.points and i.rectify work by group (you can determine which images
> > in a
> > group you wish to rectify), you only have to use i.points once for
> > rectifying all images in a group.
>
> Perhaps I am misusing i.group. I started with 6 scanned maps, each of a
> different geographic space representing adjacent townships and ranges
> (essentially a 3X2 matrix of a single larger map). After importing into
> GRASS, I was left with 3 color bands for each map (rgb). All 6 maps
> need to be assembled into a single map with all color bands. I defined
> a single group with i.group. I now believe that I should have defined 6
> separate groups with i.group (one for each of the 6 geographic
> locations). So the question is: in what order should these steps be
> completed?
>
> 1. merge rgb bands into a single map for each of the 3 bands
> 2. georectify with i.points
> 3. overlay adjacent maps
If the 6 individual maps are just "tiles" of a single map, the logical
sequence is to patch them together first, then rectify the single
large map. Otherwise (i.e. if the individual maps use different
projections), you need to rectify them separately then patch the
results together.
The point which Moritz was making was that you don't need to rectify
the individual R/G/B bands separately. Each run of i.rectify will
simultaneously rectify all three bands (assuming that they have been
grouped).
You shouldn't actually need to merge the R/G/B bands at any point, and
doing so isn't desirable in most cases. When generating a composite
map, you usually have to reduce the colour depth, otherwise you end up
with massive colour tables which tend to make most operations
extremely slow (either that, or they just fail due to insufficient
memory).
The main situation where generating a composite map makes sense is for
a "preview" (particularly for programs which only allow the use of a
single image rather than separate channels).
E.g. you might generate a composite map (with a low colour depth) to
use when marking points in i.points, but you would actually rectify
the separate R/G/B channels (you might also wish to rectify the
composite map, or you could generate a new composite map from the
rectified channels).
--
Glynn Clements
From grass-bugs at intevation.de Wed Jan 7 23:06:09 2004
From: grass-bugs at intevation.de (Request Tracker)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] [bug #2278] (grass) error when make
Message-ID: <20040108040609.3047113BA5@lists.intevation.de>
this bug's URL: http://intevation.de/rt/webrt?serial_num=2278
-------------------------------------------------------------------------
Subject: error when make
Platform: GNU/Linux/i386
grass obtained from: Mirror of Trento site
grass binary for platform: Compiled from Sources
GRASS Version: grass5.7_exp_2003_10_11
Please enter error description here (and your name)
My name is Wu Yizhi
After install postgresql, and "configure" is correct. when "make", the error is as:
......
/usr/bin/ld: connot find -lpq
collect2:ld returned 1 exit status
make[3}:
......
-------------------------------------------- Managed by Request Tracker
From blazek at itc.it Thu Jan 8 04:34:28 2004
From: blazek at itc.it (Radim Blazek)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] v.select attributes problem in 5.7
In-Reply-To: <2BC40F2C-4154-11D8-80E7-000A956FDAC0@fonnesbeck.org>
References: <2BC40F2C-4154-11D8-80E7-000A956FDAC0@fonnesbeck.org>
Message-ID: <200401080934.i089YTT01940@janacek.itc.it.>
On Wednesday 07 January 2004 21:57, Christopher Fonnesbeck wrote:
> When running v.select on a vector coverage with attributes stored in a
> relational database (MySQL), the new coverage of selected polygons is
> associated with a new table that has as many entries as the original
> table, even though the number of selected polygons is significantly
> smaller. Is this a bug, or is there another way of getting an attribute
> table that contains only the attributes for the selected polygons?
>
> Running 5.7 on OSX 10.3
More or less bug, I did not have time to write db_copy_table_where()
so db_copy_table is used and all records are written to output.
Radim
From neteler at itc.it Thu Jan 8 07:19:08 2004
From: neteler at itc.it (Markus Neteler)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] [bug #2278] (grass) error when make
In-Reply-To: <20040108040609.3047113BA5@lists.intevation.de>
References: <20040108040609.3047113BA5@lists.intevation.de>
Message-ID: <20040108121908.GE2726@thuille.itc.it>
On Thu, Jan 08, 2004 at 05:06:09AM +0100, Request Tracker wrote:
> this bug's URL: http://intevation.de/rt/webrt?serial_num=2278
> -------------------------------------------------------------------------
>
> Subject: error when make
>
> Platform: GNU/Linux/i386
> grass obtained from: Mirror of Trento site
> grass binary for platform: Compiled from Sources
> GRASS Version: grass5.7_exp_2003_10_11
This version looks fairly old.
Please update from CVS or use a recent snapshot.
Markus
From chris at fonnesbeck.org Thu Jan 8 09:09:29 2004
From: chris at fonnesbeck.org (Christopher Fonnesbeck)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] v.select attributes problem in 5.7
In-Reply-To: <200401080934.i089YTT01940@janacek.itc.it.>
References: <2BC40F2C-4154-11D8-80E7-000A956FDAC0@fonnesbeck.org> <200401080934.i089YTT01940@janacek.itc.it.>
Message-ID: <4694C527-41E4-11D8-BB77-000A956FDAC0@fonnesbeck.org>
On Jan 8, 2004, at 4:34 AM, Radim Blazek wrote:
> On Wednesday 07 January 2004 21:57, Christopher Fonnesbeck wrote:
>> When running v.select on a vector coverage with attributes stored in a
>> relational database (MySQL), the new coverage of selected polygons is
>> associated with a new table that has as many entries as the original
>> table, even though the number of selected polygons is significantly
>> smaller. Is this a bug, or is there another way of getting an
>> attribute
>> table that contains only the attributes for the selected polygons?
>>
>> Running 5.7 on OSX 10.3
>
> More or less bug, I did not have time to write db_copy_table_where()
> so db_copy_table is used and all records are written to output.
>
Can I then use v.extract to get the proper attribute table?
Thanks,
Chris
--
Christopher J. Fonnesbeck ( c h r i s @ f o n n e s b e c k . o r g )
Georgia Cooperative Fish & Wildlife Research Unit, University of Georgia
From chris at fonnesbeck.org Thu Jan 8 10:06:50 2004
From: chris at fonnesbeck.org (Christopher Fonnesbeck)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] v.select attributes problem in 5.7
In-Reply-To: <200401080934.i089YTT01940@janacek.itc.it.>
References: <2BC40F2C-4154-11D8-80E7-000A956FDAC0@fonnesbeck.org> <200401080934.i089YTT01940@janacek.itc.it.>
Message-ID: <49612806-41EC-11D8-BB77-000A956FDAC0@fonnesbeck.org>
On Jan 8, 2004, at 4:34 AM, Radim Blazek wrote:
> On Wednesday 07 January 2004 21:57, Christopher Fonnesbeck wrote:
>> When running v.select on a vector coverage with attributes stored in a
>> relational database (MySQL), the new coverage of selected polygons is
>> associated with a new table that has as many entries as the original
>> table, even though the number of selected polygons is significantly
>> smaller. Is this a bug, or is there another way of getting an
>> attribute
>> table that contains only the attributes for the selected polygons?
>>
>> Running 5.7 on OSX 10.3
>
> More or less bug, I did not have time to write db_copy_table_where()
> so db_copy_table is used and all records are written to output.
>
I need to get some type of (temporary) solution to this problem, since
an output layer with the wrong attribute table is not very useful. Is
there a way of getting at the cats of the new coverage and using them
with v.extract? I don't mind doing some C programming, if thats what it
takes, but I am not experienced with the GRASS C API, so hints would be
welcome.
Thanks,
Chris
--
Christopher J. Fonnesbeck ( c h r i s @ f o n n e s b e c k . o r g )
Georgia Cooperative Fish & Wildlife Research Unit, University of Georgia
From michael.barton at asu.edu Thu Jan 8 11:40:11 2004
From: michael.barton at asu.edu (Michael Barton)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] making raster maps from vector maps with PostgreSQL data in GRASS 5.3
In-Reply-To: <200401080126.i081Q1S23642@grass.itc.it>
Message-ID: <53761C92-41F9-11D8-89C4-00039313C09E@asu.edu>
Here is the setup:
I have a vector area map with related information in a PostgreSQL
database. I can query and display the vector map using information from
any of the data fields in the PostgreSQL table.
What I'd like to do is create a series of raster maps of the vectora
areas in which the cat and/or label values are derived from a
corresponding series of field from the PostgreSQL file (e.g., raster
map1 using field 1, raster map2 using field 2, etc.)
How do I get data from a PostgreSQL field into the cat or label field
of a vector file so I can do a v.to.rast transformation?
Or is there another solution to this?
Thanks
Michael Barton
______________________________
Michael Barton, Professor & Curator
Department of Anthropology
Arizona State University
Tempe, AZ 85287-2402
USA
voice: 480-965-6262; fax: 480-965-7671
From neteler at itc.it Fri Jan 9 06:33:23 2004
From: neteler at itc.it (Markus Neteler)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] 5.3: shared libs and test in configure
Message-ID: <20040109113323.GE8941@thuille.itc.it>
Here an example that the test
if test "$SRCDIR" = "$DSTDIR" ; then
{ echo "configure: error: *** Build directory should not be the same as source \
can fail:
SRCDIR: /hardmnt/thuille1/ssi/cvsgrass_exp
DSTDIR: /ssi0/ssi/neteler/cvsgrass_exp
The situation is that I have changed into the source code
/ssi0/ssi/neteler/cvsgrass_exp/ directory via soft-link:
cd /ssi0/ssi/neteler/cvsgrass_exp/
thuille:cvsgrass_exp[304.48] pwd
/ssi0/ssi/neteler/cvsgrass_exp
thuille:cvsgrass_exp[305.49] /bin/pwd
/hardmnt/thuille1/ssi/cvsgrass_exp
Personally I enjoy that it fails as I can launch 'make' as
usual :-)
Markus
From grass-bugs at intevation.de Fri Jan 9 09:14:59 2004
From: grass-bugs at intevation.de (Request Tracker)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] [bug #2279] (grass) [No Subject Given]
Message-ID: <20040109141459.188BE13BCD@lists.intevation.de>
this bug's URL: http://intevation.de/rt/webrt?serial_num=2279
-------------------------------------------------------------------------
--- Headers Follow ---
>From qlcngneblwtobz@cnnic.net.cn Fri Jan 9 15:14:57 2004
Return-Path:
Delivered-To: grass-bugs@lists.intevation.de
Received: from mail.intevation.de (aktaia [212.95.126.10])
by lists.intevation.de (Postfix) with ESMTP id 4C63413BC5
for ; Fri, 9 Jan 2004 15:14:57 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
by mail.intevation.de (Postfix) with ESMTP id 3015C372BA
for ; Fri, 9 Jan 2004 15:14:57 +0100 (CET)
Received: from h0007e9974fdd.ne.client2.attbi.com (h0007e9974fdd.ne.client2.attbi.com [65.96.53.45])
by mail.intevation.de (Postfix) with SMTP id DC1BE372B9
for ; Fri, 9 Jan 2004 15:14:55 +0100 (CET)
Received: from [65.96.53.45] by 2005hosting.comIP with HTTP;
Fri, 09 Jan 2004 01:12:07 -0200
From: Kellie@intevation.de
Message-Id: <20040109141455.DC1BE372B9@mail.intevation.de>
Date: Fri, 9 Jan 2004 15:14:55 +0100 (CET)
X-Spam-Status: No, hits=2.3 tagged_above=-999.0 required=3.0 tests=BAYES_90,
NO_REAL_NAME
X-Spam-Level: **
To: undisclosed-recipients: ;
-------------------------------------------- Managed by Request Tracker
From michael.barton at asu.edu Fri Jan 9 11:52:12 2004
From: michael.barton at asu.edu (Michael Barton)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] making raster maps from vector maps with PostgreSQL data
in GRASS 5.3
In-Reply-To: <3FFECE4F.3070703@noaa.gov>
Message-ID: <2BB95FF8-42C4-11D8-BBF4-00039313C09E@asu.edu>
Tom,
Thanks for this suggestion.
On Friday, January 9, 2004, at 08:52 AM, Thomas Adams wrote:
> Michael,
>
> Iteresting you should ask this question since I had a similar need.
> What you need to do is this:
>
> (1) first do the v.to.rast conversion on your vector files, creating
> the raster equivalents
>
> (2) if you have the dig_cats files for the vector files, then simply
> copy them into the cats directory; the only thing is that the cats
> filenames & the cell file names must be the same - then you're done.
Actually I don't **think** that this is even necessary if you have
dig_cats. I **think** that v.to.rast will copy the vector attributes
into the proper raster cat & label files. The problem, of course is
that I **don't** have the dig_cats file and want to create it from a
PostgreSQL table column. However, barring an elegant solution to this,
what you recommend below will work even if it is 'brute force'. Thanks
again.
>
> (3) if you don't have the dig_cats files, you'll have to do a SQL
> query to dump the attributes to a text file by polygon area and then
> do a little file manipulation to get them into the format needed for
> Step-(2) above.
>
> Now, this may be a brute force way to do this and someone else will
> come along with something more elegant, but it will work.
>
Michael
> Regards,
> Tom
>
>
>
> Michael Barton wrote:
>
>> Here is the setup:
>>
>> I have a vector area map with related information in a PostgreSQL
>> database. I can query and display the vector map using information
>> from any of the data fields in the PostgreSQL table.
>>
>> What I'd like to do is create a series of raster maps of the vectora
>> areas in which the cat and/or label values are derived from a
>> corresponding series of field from the PostgreSQL file (e.g., raster
>> map1 using field 1, raster map2 using field 2, etc.)
>>
>> How do I get data from a PostgreSQL field into the cat or label field
>> of a vector file so I can do a v.to.rast transformation?
>>
>> Or is there another solution to this?
>>
>> Thanks
>> Michael Barton
>> ______________________________
>> Michael Barton, Professor & Curator
>> Department of Anthropology
>> Arizona State University
>> Tempe, AZ 85287-2402
>> USA
>>
>> voice: 480-965-6262; fax: 480-965-7671
>>
>> _______________________________________________
>> grass5 mailing list
>> grass5@grass.itc.it
>> http://grass.itc.it/mailman/listinfo/grass5
>
>
> --
> Thomas E Adams
> National Weather Service
> Ohio River Forecast Center
> 1901 South State Route 134
> Wilmington, OH 45177
>
> EMAIL: thomas.adams@noaa.gov
>
> VOICE: 937-383-0528
> FAX: 937-383-0033
>
>
>
______________________________
Michael Barton, Professor & Curator
Department of Anthropology
Arizona State University
Tempe, AZ 85287-2402
USA
voice: 480-965-6262; fax: 480-965-7671
From glynn.clements at virgin.net Fri Jan 9 13:37:38 2004
From: glynn.clements at virgin.net (Glynn Clements)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] 5.3: shared libs and test in configure
In-Reply-To: <20040109113323.GE8941@thuille.itc.it>
References: <20040109113323.GE8941@thuille.itc.it>
Message-ID: <16382.62706.657369.890086@cerise.nosuchdomain.co.uk>
Markus Neteler wrote:
> Here an example that the test
>
> if test "$SRCDIR" = "$DSTDIR" ; then
> { echo "configure: error: *** Build directory should not be the same as source \
>
>
> can fail:
>
> SRCDIR: /hardmnt/thuille1/ssi/cvsgrass_exp
> DSTDIR: /ssi0/ssi/neteler/cvsgrass_exp
>
> The situation is that I have changed into the source code
> /ssi0/ssi/neteler/cvsgrass_exp/ directory via soft-link:
>
> cd /ssi0/ssi/neteler/cvsgrass_exp/
>
> thuille:cvsgrass_exp[304.48] pwd
> /ssi0/ssi/neteler/cvsgrass_exp
>
> thuille:cvsgrass_exp[305.49] /bin/pwd
> /hardmnt/thuille1/ssi/cvsgrass_exp
Right. I appear to have been distracted by the fact that one of the
three cases uses $pwd (which will be set to "/bin/pwd"); however, the
other two just use "pwd" which will be the shell's built-in:
AC_PATH_PROG(pwd, pwd, pwd)
AC_MSG_CHECKING(for source directory)
if test -z "$srcdir" ; then
SRCDIR=`pwd`
else
SRCDIR=`(cd "$srcdir" ; $pwd)`
fi
AC_MSG_RESULT("$SRCDIR")
AC_MSG_CHECKING(for build directory)
DSTDIR=`pwd`
AC_MSG_RESULT("$DSTDIR")
For the $SRCDIR = $DSTDIR check to work correctly, we need to use $pwd
in all three cases. I'll fix this.
--
Glynn Clements
From glynn.clements at virgin.net Fri Jan 9 14:16:49 2004
From: glynn.clements at virgin.net (Glynn Clements)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] 5.3 shared libraries and other experimental changes
In-Reply-To:
References:
Message-ID: <16382.65057.501358.851620@cerise.nosuchdomain.co.uk>
Paul Kelly wrote:
> Feel free to fix up and tidy the changes I have made. Seems to work on
> Linux (Red Hat 9) and IRIX (6.2) but I haven't tested anywhere else and
> much needs tidied anyway. E.g. generating the makefiles for the alternate
> build mechanism only needs to be done once but is done every time the
> configure script is run, the way I have left it.
This didn't sink in the first time I read it.
I don't think that configure should do this. If you want to eliminate
the need for the "mk/mkmakefiles" step, it would be better to add the
"makefiles" target to the list of dependencies for the "all" target in
the Makefile. That way, re-creating the makefiles can be skipped by
specifying an explicit list of targets when running "make".
Also, if you wait until the top-level Makefile has been built, you can
use the rule:
%/makefile: %/Gmakefile
sed -f ${SRCDIR}/mk/genmake.sed < $< > $@
to only build the makefile if it doesn't exist or if the Gmakefile has
changed. I.e. instead of running:
sed -f ${SRCDIR}/mk/genmake.sed < $$dir/Gmakefile > $$dir/makefile
for each value of $dir, run:
${MAKE} $$dir/makefile
Or maybe it's time to finally abandon the use of gmake5 and just
require GNU make?
--
Glynn Clements
From grass-bugs at intevation.de Sat Jan 10 16:59:23 2004
From: grass-bugs at intevation.de (Request Tracker)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] [bug #2280] (grass) Bitte bemuehen Sie sich es fuer Kinder Gottes zu nutzen!
Message-ID: <20040110215923.9CA1713BCD@lists.intevation.de>
this bug's URL: http://intevation.de/rt/webrt?serial_num=2280
-------------------------------------------------------------------------
This is a multi-part message in MIME format
--8d5376e5-467f-49d4-a659-3ea8f750c20a
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Von: Fr. Serena Jones
Bitte bem=FChen Sie sich es f=FCr Kinder Gottes zu nutzen
Ich bin die obengenannte Person aus Kuwait.Ich bin mit Dr. Harry Jones, der =
neun Jahre lang f=FCr die Kuwaitsche Botschaft gearbeitet hatte, bevor er in =
2002 verstarb, verheiratet.
Wir waren elf Jahre verheiratet, ohne Kinder. Er erlag einer kurzen =
Krankheit, die nur vier Tage dauerte. Befor er starb, wurden wir als Christen =
wiedergeboren. Nach seinem Tod beschlo=DF ich nicht wieder zu heiraten und =
keine Kinder au=DFerhalb der Ehe zu bekommen, weil die Bibel dagegen ist.
Als mein Ehemann noch am Leben war, hat er die Summe von 8,6 Millionen U.S. =
Dollar bei einer Finanzen/Sicherheit Gesellschaft in Amsterdam/Holland =
hinterlegt. Im Augenblick befindet sich das Geld immer noch da.
Vor kurzem erfuhr ich von meinem Arzt, dass ich die n=E4chsten drei Monate =
nich durchhalten werde, wegen einer Krebskrankheit.
Was mich am meisten st=F6rt ist meine schlagartige Krankheit.
Meinen Zustand kennend, beschlo=DF ich diesen Fonds einer Kirche, oder noch =
besser, einem Christen, der das Geld wie ich es hier beschreibe nutzen wird, =
zu spenden.
Ich w=FCnsche mir eine Kirche, die diesen Fonds nutzen wird um Kirchen , =
Weisenh=E4user und Witwen, die das Wort Gottes verbreiten, zu unterst=FCtzen, =
und sicherstellt, dass das Haus Gottes aufrechterhalten wird. Die Bibel gibt =
uns zu verstehen,dass die Hand die gibt
gesegnet ist.
Ich habe mich dazu entschieden weil ich keine Kinder habe, die das Geld erben =
k=F6nnten, und die Verwandten meines Ehemannes keine Christen sind und ich =
m=F6chte nicht, dass das hart verdiente Geld meines Mannes von Ungl=E4ubigen =
missbraucht wird. Ich m=F6chte nicht, dass dieses Geld auf s=FCndhafter Weise =
benutzt wird. Deshalb kamm ich zu diesem gewagten Entschlu=DF.
Ich habe keine Angst vor dem Tod, weil ich wei=DF wohin ich gehe, Ich werde =
im Scho=DF Gottes sein.Exodus 14VS14 sagt, dass der Herr f=FCr mein Recht k=E4=
mpfen wird und dass ich meinen Frieden bewahren soll.
Ich brauche keine telefonische Kommunikation wegen meiner Gesundheit uns weil =
die Verwandten meines Mannes immer bei mir sind.
Ich m=F6chte nicht, dass sie von dieser Entwicklung erfahren. Mit Gott ist =
alles m=F6glich.
So bald ich Ihre Antwort bekomme werde ich Sie mit der Finanzen/Sicherheit =
Gesellschaft in Amsterdam/Holland in Verbindung setzen. Ich werde auch eine =
Vollmacht f=FCr Sie als Beg=FCnstigter ausstellen.
Ich m=F6chte, dass Sie und die Kirche immer f=FCr mich beten, weil der Herr =
mein Hirte ist.
Ich bin gl=FCcklich das Leben eines w=FCrdigem Christens gelebt zu haben. =
Wenn man Gott dienen will muss das im Geiste und Wahrheit sein.
Bitte beten Sie Ihr ganzes Leben.
Jede Versp=E4tung Ihrer Antwort wird mich veranlassen eine Kirche, oder einen =
Christen, f=FCr den selben Zweck zu suchen.
Bitte versichern Sie mich, dass Sie wie beschrieben handeln werden. Ich hoffe =
von Ihnen zu h=F6ren. Sie erreichen Mich unter email add: =
jonesserena@fsmail.net
--8d5376e5-467f-49d4-a659-3ea8f750c20a--
--- Headers Follow ---
>From jonesserena@fsmail.net Sat Jan 10 22:59:21 2004
Return-Path:
Delivered-To: grass-bugs@lists.intevation.de
Received: from mail.intevation.de (aktaia [212.95.126.10])
by lists.intevation.de (Postfix) with ESMTP
id 8C60713AAE; Sat, 10 Jan 2004 22:59:21 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
by mail.intevation.de (Postfix) with ESMTP
id 3ED6D372BA; Sat, 10 Jan 2004 22:59:22 +0100 (CET)
Received: from fsmail640.com (node-c-0505.a2000.nl [62.194.5.5])
by mail.intevation.de (Postfix) with SMTP
id 65BE536D7F; Sat, 10 Jan 2004 22:59:19 +0100 (CET)
From: serena jones
Reply-To: jonesserena@fsmail.net
Subject: Bitte bemuehen Sie sich es fuer Kinder Gottes zu nutzen!
Date: Sat, 10 Jan 2004 23:00:43 +0100
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8d5376e5-467f-49d4-a659-3ea8f750c20a"
Message-Id: <20040110215919.65BE536D7F@mail.intevation.de>
To: undisclosed-recipients: ;
X-Spam-Status: No, hits=0.8 tagged_above=-999.0 required=3.0 tests=BAYES_00,
MIME_BOUND_MANY_HEX, MSGID_FROM_MTA_SHORT
X-Spam-Level:
-------------------------------------------- Managed by Request Tracker
From grass-bugs at intevation.de Sat Jan 10 17:04:14 2004
From: grass-bugs at intevation.de (Request Tracker)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] [bug #2281] (grass) Bitte bemuehen Sie sich es fuer Kinder Gottes zu nutzen!
Message-ID: <20040110220414.2503B13BCD@lists.intevation.de>
this bug's URL: http://intevation.de/rt/webrt?serial_num=2281
-------------------------------------------------------------------------
This is a multi-part message in MIME format
--9ddb317c-1833-4594-af59-e5f3bb699b15
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Von: Fr. Serena Jones
Bitte bem=FChen Sie sich es f=FCr Kinder Gottes zu nutzen
Ich bin die obengenannte Person aus Kuwait.Ich bin mit Dr. Harry Jones, der =
neun Jahre lang f=FCr die Kuwaitsche Botschaft gearbeitet hatte, bevor er in =
2002 verstarb, verheiratet.
Wir waren elf Jahre verheiratet, ohne Kinder. Er erlag einer kurzen =
Krankheit, die nur vier Tage dauerte. Befor er starb, wurden wir als Christen =
wiedergeboren. Nach seinem Tod beschlo=DF ich nicht wieder zu heiraten und =
keine Kinder au=DFerhalb der Ehe zu bekommen, weil die Bibel dagegen ist.
Als mein Ehemann noch am Leben war, hat er die Summe von 8,6 Millionen U.S. =
Dollar bei einer Finanzen/Sicherheit Gesellschaft in Amsterdam/Holland =
hinterlegt. Im Augenblick befindet sich das Geld immer noch da.
Vor kurzem erfuhr ich von meinem Arzt, dass ich die n=E4chsten drei Monate =
nich durchhalten werde, wegen einer Krebskrankheit.
Was mich am meisten st=F6rt ist meine schlagartige Krankheit.
Meinen Zustand kennend, beschlo=DF ich diesen Fonds einer Kirche, oder noch =
besser, einem Christen, der das Geld wie ich es hier beschreibe nutzen wird, =
zu spenden.
Ich w=FCnsche mir eine Kirche, die diesen Fonds nutzen wird um Kirchen , =
Weisenh=E4user und Witwen, die das Wort Gottes verbreiten, zu unterst=FCtzen, =
und sicherstellt, dass das Haus Gottes aufrechterhalten wird. Die Bibel gibt =
uns zu verstehen,dass die Hand die gibt
gesegnet ist.
Ich habe mich dazu entschieden weil ich keine Kinder habe, die das Geld erben =
k=F6nnten, und die Verwandten meines Ehemannes keine Christen sind und ich =
m=F6chte nicht, dass das hart verdiente Geld meines Mannes von Ungl=E4ubigen =
missbraucht wird. Ich m=F6chte nicht, dass dieses Geld auf s=FCndhafter Weise =
benutzt wird. Deshalb kamm ich zu diesem gewagten Entschlu=DF.
Ich habe keine Angst vor dem Tod, weil ich wei=DF wohin ich gehe, Ich werde =
im Scho=DF Gottes sein.Exodus 14VS14 sagt, dass der Herr f=FCr mein Recht k=E4=
mpfen wird und dass ich meinen Frieden bewahren soll.
Ich brauche keine telefonische Kommunikation wegen meiner Gesundheit uns weil =
die Verwandten meines Mannes immer bei mir sind.
Ich m=F6chte nicht, dass sie von dieser Entwicklung erfahren. Mit Gott ist =
alles m=F6glich.
So bald ich Ihre Antwort bekomme werde ich Sie mit der Finanzen/Sicherheit =
Gesellschaft in Amsterdam/Holland in Verbindung setzen. Ich werde auch eine =
Vollmacht f=FCr Sie als Beg=FCnstigter ausstellen.
Ich m=F6chte, dass Sie und die Kirche immer f=FCr mich beten, weil der Herr =
mein Hirte ist.
Ich bin gl=FCcklich das Leben eines w=FCrdigem Christens gelebt zu haben. =
Wenn man Gott dienen will muss das im Geiste und Wahrheit sein.
Bitte beten Sie Ihr ganzes Leben.
Jede Versp=E4tung Ihrer Antwort wird mich veranlassen eine Kirche, oder einen =
Christen, f=FCr den selben Zweck zu suchen.
Bitte versichern Sie mich, dass Sie wie beschrieben handeln werden. Ich hoffe =
von Ihnen zu h=F6ren. Sie erreichen Mich unter email add: =
jonesserena@fsmail.net
--9ddb317c-1833-4594-af59-e5f3bb699b15--
--- Headers Follow ---
>From jonesserena@fsmail.net Sat Jan 10 23:04:13 2004
Return-Path:
Delivered-To: grass-bugs@lists.intevation.de
Received: from mail.intevation.de (aktaia [212.95.126.10])
by lists.intevation.de (Postfix) with ESMTP
id E356E13AAE; Sat, 10 Jan 2004 23:04:12 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
by mail.intevation.de (Postfix) with ESMTP
id 91E3C372BA; Sat, 10 Jan 2004 23:04:13 +0100 (CET)
Received: from fsmail590.com (node-c-0505.a2000.nl [62.194.5.5])
by mail.intevation.de (Postfix) with SMTP
id 1DF8F36D7F; Sat, 10 Jan 2004 23:04:09 +0100 (CET)
From: serena jones
Reply-To: jonesserena@fsmail.net
Subject: Bitte bemuehen Sie sich es fuer Kinder Gottes zu nutzen!
Date: Sat, 10 Jan 2004 23:05:35 +0100
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="9ddb317c-1833-4594-af59-e5f3bb699b15"
Message-Id: <20040110220409.1DF8F36D7F@mail.intevation.de>
To: undisclosed-recipients: ;
X-Spam-Status: No, hits=0.8 tagged_above=-999.0 required=3.0 tests=BAYES_00,
MIME_BOUND_MANY_HEX, MSGID_FROM_MTA_SHORT
X-Spam-Level:
-------------------------------------------- Managed by Request Tracker
From neteler at itc.it Sat Jan 10 17:44:18 2004
From: neteler at itc.it (Markus Neteler)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] GRASS and libc2.2/libc2.3 portability problem
In-Reply-To: <20040109145131.GD30715@thuille.itc.it>
References: <20040109145131.GD30715@thuille.itc.it>
Message-ID: <20040110224418.GB22856@thuille.itc.it>
It seems that I discovered a small (?) portability problem in GRASS 5.3/5.7:
- GRASS compiled on Redhat9/GLIBC_2.3 as network installation (NFS)
- using this GRASS binary on Redhat7/GLIBC_2.2 leads to an error:
baez:lib[264.8] ldd libgrass_gis.so
./libgrass_gis.so: /lib/libc.so.6: version `GLIBC_2.3' not found (required by ./libgrass_gis.so)
libgrass_datetime.so => /mpa_sw/ssi/BIO/software/GRASS5.3/grass5bin_cvs/grass53/lib/libgrass_datetime.so (0x40089000)
libz.so.1 => /usr/lib/libz.so.1 (0x40091000)
libm.so.6 => /lib/libm.so.6 (0x400ae000)
libc.so.6 => /lib/libc.so.6 (0x400d1000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
baez:lib[265.9] pwd
/mpa_sw/ssi/BIO/software/GRASS5.3/grass5bin_cvs/grass53/lib
baez:lib[266.10] ls -la /lib/libc.so.6
lrwxrwxrwx 1 root root 13 Jan 7 10:26 /lib/libc.so.6 -> libc-2.2.4.so
A quick web seach:
http://www.unidata.ucar.edu/projects/coohl/mhonarc/MailArchives/netcdf/msg04510.html
"> The problem is related to glibc. Anything on redhat9 with a glibc >=
> glibc-2.3.2-11.9 is causing the problems. Actually, any stock glibc
> from atleast 2.3.0 and on is causing problems.
>
> glibc is no longer exporting ctype_b.
> The offending line of code in netcdf is in libsrc/string.c.
> The line is:
> if(!isalnum(ch))
"
Now I checked libgis:
grep isalnum *.c
parser.c: if (!isalnum(*p) && !strchr(normal, *p))
A global search:
find . -type f -name "*.c" -exec grep -l isalnum {} \;
./src/mapdev/v.in.mif/main.c
./src/mapdev/v.out.e00/v.out.e00.c
./src/libes/gis/parser.c
./src/misc/m.in.e00/main.c
./src/raster/r.in.shape/main.c
./src/sites/s.in.dbf/dump.c
./src/sites/s.in.dbf/main.c
./src/sites/s.in.mif/main.c
./src/sites/s.in.shape/cmd/main.c
./src/sites/s.out.e00/s.out.e00.c
./src.contrib/SDTS/mapdev/v.in.sdts/dictionary.c
./src.garden/grass.postgresql/pg.in.dbf/pgdump.c
./src.garden/grass.postgresql/v.in.arc.pg/pgdump.c
./src.garden/grass.postgresql/v.in.shape.pg/main.c
In the mail above is suggestion to use (untested):
if(!isalnum((unsigned char)ch))
Certainly I prefer to leave this to an expert. Anything we
can do to avoid this portability problem?
Thanks,
Markus
From glynn.clements at virgin.net Sat Jan 10 22:09:06 2004
From: glynn.clements at virgin.net (Glynn Clements)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] GRASS and libc2.2/libc2.3 portability problem
In-Reply-To: <20040110224418.GB22856@thuille.itc.it>
References: <20040109145131.GD30715@thuille.itc.it>
<20040110224418.GB22856@thuille.itc.it>
Message-ID: <16384.48722.970497.307021@cerise.nosuchdomain.co.uk>
Markus Neteler wrote:
> It seems that I discovered a small (?) portability problem in GRASS 5.3/5.7:
>
> - GRASS compiled on Redhat9/GLIBC_2.3 as network installation (NFS)
> - using this GRASS binary on Redhat7/GLIBC_2.2 leads to an error:
>
> baez:lib[264.8] ldd libgrass_gis.so
> ./libgrass_gis.so: /lib/libc.so.6: version `GLIBC_2.3' not found (required by ./libgrass_gis.so)
> libgrass_datetime.so => /mpa_sw/ssi/BIO/software/GRASS5.3/grass5bin_cvs/grass53/lib/libgrass_datetime.so (0x40089000)
> libz.so.1 => /usr/lib/libz.so.1 (0x40091000)
> libm.so.6 => /lib/libm.so.6 (0x400ae000)
> libc.so.6 => /lib/libc.so.6 (0x400d1000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
Yep. In general, a binary (executable or shared library) requires the
specific major version of each of its dependencies for which it was
compiled.
GNU libc 2 has its own versioning mechanism, using versioned symbols.
Rather than incrementing the major version number every time an
incompatible change is made, they provide a new version of each
applicable function, but also keep the old version(s). When linking
against libc, the newest version is used.
The end result is that programs which were built for a particular
version of glibc can use that version or any later version; they can't
use an earlier version.
If you want binaries to be portable, use the oldest OS version that is
practical. If you use the latest version, the binaries are unlikely to
run on anything else (this is especially true for RedHat, who seem to
be more willing than other distributions to use the very latest
versions).
BTW, although other libraries don't generally use versioned symbols, a
similar issue applies. When a distribution switches to a later version
of a given library, they often provide the previous version as well
(usually in a separate "compatibility" package).
--
Glynn Clements
From neteler at itc.it Mon Jan 12 03:37:52 2004
From: neteler at itc.it (Markus Neteler)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] grass 5.0.3 in debian
In-Reply-To: <1073488749.1035.4.camel@localhost>
References: <20040105130845.GD13455@intevation.de> <1073311576.1020.55.camel@localhost> <20040107145228.GG3467@thuille.itc.it> <1073488749.1035.4.camel@localhost>
Message-ID: <20040112083752.GE3731@thuille.itc.it>
FYI,
the GRASS 5.0.3 package has been submitted to debian.
Hope that it's visible soon.
Markus
On Wed, Jan 07, 2004 at 04:19:10PM +0100, Federico Di Gregorio wrote:
> btw, grass 5.0.3 has been uploaded to debian.org; the package grass-doc
> is new so it will take a little bit to get processed. there are still
> bugs (like the missing manpages) but the new build scripts make
> maintenance much easier. bugs will be fixed soon.
>
> federico
>
> --
> Federico Di Gregorio http://people.initd.org/fog
> Debian GNU/Linux Developer fog@debian.org
> INIT.D Developer fog@initd.org
> 99.99999999999999999999% still isn't 100% but sometimes suffice. -- Me
From grass-bugs at intevation.de Mon Jan 12 03:44:50 2004
From: grass-bugs at intevation.de (guest user via RT)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] [bug #2174] (grass) Mac OSX startup: ERROR: Invalid return code
Message-ID: <20040112084450.4987713BA5@lists.intevation.de>
> [Valentine:~] bmadin% grass5
> Cleaning up temporary files.....
> Starting GRASS ...
> : command not foundtc/Init.sh:
Is this still an issue on Mac OSX?
Markus
-------------------------------------------- Managed by Request Tracker
From neteler at itc.it Mon Jan 12 04:03:33 2004
From: neteler at itc.it (Markus Neteler)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] Spamfilter added for RT Bugtracker mails
Message-ID: <20040112090333.GF3731@thuille.itc.it>
To get rid (hopefully) of most spams arriving in 'grass5'
mailing list via bugtracker, I have added a filter rule
to pipe RT mails through 'bogofilter':
Reply-To: guest user via RT
From: guest user via RT
To:
Cc: grass5@grass.itc.it
X-Request-ID: 2174
X-RT-Loop-Prevention: bug
X-Sender: guest
X-Managed-By: Request Tracker 1.0.7 (http://www.fsck.com/projects/rt)
X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=0.15.13.1
-> this line was added
Subject: [GRASS5] [bug #2174] (grass) Mac OSX startup: ERROR: Invalid return code
Errors-To: grass5-admin@grass.itc.it
X-BeenThere: grass5@grass.itc.it
X-Mailman-Version: 2.0.5
List-Help:
List-Post:
List-Subscribe: ,
The same filter has been applied also to 'weblist' (mailing list
dedicated to receive web site comments and requests).
Let me know in case of problems
Markus
From bernhard at intevation.de Mon Jan 12 04:46:32 2004
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] Spamfilter added for RT Bugtracker mails
In-Reply-To: <20040112090333.GF3731@thuille.itc.it>
References: <20040112090333.GF3731@thuille.itc.it>
Message-ID: <20040112094632.GA7146@intevation.de>
On Mon, Jan 12, 2004 at 10:03:33AM +0100, Markus Neteler wrote:
> To get rid (hopefully) of most spams arriving in 'grass5'
> mailing list via bugtracker, I have added a filter rule
> to pipe RT mails through 'bogofilter':
Note that we already have a spam filter running
here at Intevation before we accept entries in the bugtracker.
We are running spamassasin.
It also contains a bayesian spam filter component
in additions to other methods.
As you can see there is no total protection.
However we tuned it to minimise false positives.
> The same filter has been applied also to 'weblist' (mailing list
> dedicated to receive web site comments and requests).
>
> Let me know in case of problems
Let us know the number of false positives over the next month.
I'd rather have 10 false negatives than 1 false positive.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20040112/c772ca00/attachment.bin
From neteler at itc.it Mon Jan 12 05:17:27 2004
From: neteler at itc.it (Markus Neteler)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] Spamfilter added for RT Bugtracker mails
In-Reply-To: <20040112094632.GA7146@intevation.de>
References: <20040112090333.GF3731@thuille.itc.it> <20040112094632.GA7146@intevation.de>
Message-ID: <20040112101727.GK3731@thuille.itc.it>
On Mon, Jan 12, 2004 at 10:46:32AM +0100, Bernhard Reiter wrote:
> On Mon, Jan 12, 2004 at 10:03:33AM +0100, Markus Neteler wrote:
> > To get rid (hopefully) of most spams arriving in 'grass5'
> > mailing list via bugtracker, I have added a filter rule
> > to pipe RT mails through 'bogofilter':
>
> Note that we already have a spam filter running
> here at Intevation before we accept entries in the bugtracker.
> We are running spamassasin.
> It also contains a bayesian spam filter component
> in additions to other methods.
> As you can see there is no total protection.
> However we tuned it to minimise false positives.
Maybe that's the problem - it's not catching some obvious
mails. Note that I have additionally implemented some 60
rules in procmail to catch further spams (including some
missed from RT spamassasin).
Started in August 2002, these procmail rules have been catching
more than 2700 spams. A major help for me as I didn't had to
eliminate them from mailman's admin tool (otherwise mailman
would catch them except for RT mails).
> > The same filter has been applied also to 'weblist' (mailing list
> > dedicated to receive web site comments and requests).
On 'weblist' list, bogofilter has caught already 8 mails since
installation some hours ago.
> > Let me know in case of problems
>
> Let us know the number of false positives over the next month.
> I'd rather have 10 false negatives than 1 false positive.
Will do. It was trained on 6000 spams (filtered from my personal box)
and some thousand hams. So far I had 2 false positives which is
an exciting good ratio. I'm pretty happy with bogofilter
and want to let you participate :-)
So please don't feel offended, RT is configured well. I don't
see a problem to filter again, just to minimize the remaining
rubbish passing RT spamassasin in that current configuration.
Markus
From bernhard at intevation.de Mon Jan 12 08:29:13 2004
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] Spamfilter added for RT Bugtracker mails
In-Reply-To: <20040112101727.GK3731@thuille.itc.it>
References: <20040112090333.GF3731@thuille.itc.it> <20040112094632.GA7146@intevation.de> <20040112101727.GK3731@thuille.itc.it>
Message-ID: <20040112132913.GE18091@intevation.de>
On Mon, Jan 12, 2004 at 11:17:27AM +0100, Markus Neteler wrote:
> On Mon, Jan 12, 2004 at 10:46:32AM +0100, Bernhard Reiter wrote:
> > On Mon, Jan 12, 2004 at 10:03:33AM +0100, Markus Neteler wrote:
> > > To get rid (hopefully) of most spams arriving in 'grass5'
> > > mailing list via bugtracker, I have added a filter rule
> > > to pipe RT mails through 'bogofilter':
> >
> > Note that we already have a spam filter running
> > here at Intevation before we accept entries in the bugtracker.
> > We are running spamassasin.
> > It also contains a bayesian spam filter component
> > in additions to other methods.
> > As you can see there is no total protection.
> > However we tuned it to minimise false positives.
>
> Maybe that's the problem - it's not catching some obvious
> mails. Note that I have additionally implemented some 60
> rules in procmail to catch further spams (including some
> missed from RT spamassasin).
Oh nice.
I didn't know that you were putting so much effort into the tuning. :)
> Started in August 2002, these procmail rules have been catching
> more than 2700 spams. A major help for me as I didn't had to
> eliminate them from mailman's admin tool (otherwise mailman
> would catch them except for RT mails).
I've implemented something similiar for the FFII and its mailman
2.0.x installation. Hold spam message will automatically be removed.
2.1.4 versions might be able to do this themselfs.
> > Let us know the number of false positives over the next month.
> > I'd rather have 10 false negatives than 1 false positive.
>
> Will do. It was trained on 6000 spams (filtered from my personal box)
> and some thousand hams. So far I had 2 false positives which is
> an exciting good ratio. I'm pretty happy with bogofilter
> and want to let you participate :-)
>
> So please don't feel offended, RT is configured well. I don't
> see a problem to filter again, just to minimize the remaining
> rubbish passing RT spamassasin in that current configuration.
No problem.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20040112/a5c9006f/attachment.bin
From neteler at itc.it Mon Jan 12 08:40:38 2004
From: neteler at itc.it (Markus Neteler)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] Spamfilter added for RT Bugtracker mails
In-Reply-To: <20040112132913.GE18091@intevation.de>
References: <20040112090333.GF3731@thuille.itc.it> <20040112094632.GA7146@intevation.de> <20040112101727.GK3731@thuille.itc.it> <20040112132913.GE18091@intevation.de>
Message-ID: <20040112134037.GO3731@thuille.itc.it>
On Mon, Jan 12, 2004 at 02:29:13PM +0100, Bernhard Reiter wrote:
> On Mon, Jan 12, 2004 at 11:17:27AM +0100, Markus Neteler wrote:
> > On Mon, Jan 12, 2004 at 10:46:32AM +0100, Bernhard Reiter wrote:
> > > On Mon, Jan 12, 2004 at 10:03:33AM +0100, Markus Neteler wrote:
> > > > To get rid (hopefully) of most spams arriving in 'grass5'
> > > > mailing list via bugtracker, I have added a filter rule
> > > > to pipe RT mails through 'bogofilter':
> > >
> > > Note that we already have a spam filter running
> > > here at Intevation before we accept entries in the bugtracker.
> > > We are running spamassasin.
> > > It also contains a bayesian spam filter component
> > > in additions to other methods.
> > > As you can see there is no total protection.
> > > However we tuned it to minimise false positives.
> >
> > Maybe that's the problem - it's not catching some obvious
> > mails. Note that I have additionally implemented some 60
> > rules in procmail to catch further spams (including some
> > missed from RT spamassasin).
>
> Oh nice.
> I didn't know that you were putting so much effort into the tuning. :)
Well, it's better than deleting thousands of messages manually
from the mailman queue...
> > Started in August 2002, these procmail rules have been catching
> > more than 2700 spams. A major help for me as I didn't had to
> > eliminate them from mailman's admin tool (otherwise mailman
> > would catch them except for RT mails).
>
> I've implemented something similiar for the FFII and its mailman
> 2.0.x installation. Hold spam message will automatically be removed.
> 2.1.4 versions might be able to do this themselfs.
Sounds good - but as a more recent Mailman version needs python 2.x
this would require a complete reinstallation of 'grass.itc.it'.
I hesitate to reinstall it (kernel is updated if needed of course).
Never touch ...
[...ok ... ]
Markus
From bernhard at intevation.de Mon Jan 12 09:02:05 2004
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] Spamfilter added for RT Bugtracker mails
In-Reply-To: <20040112134037.GO3731@thuille.itc.it>
References: <20040112090333.GF3731@thuille.itc.it> <20040112094632.GA7146@intevation.de> <20040112101727.GK3731@thuille.itc.it> <20040112132913.GE18091@intevation.de> <20040112134037.GO3731@thuille.itc.it>
Message-ID: <20040112140205.GF30496@intevation.de>
On Mon, Jan 12, 2004 at 02:40:38PM +0100, Markus Neteler wrote:
> On Mon, Jan 12, 2004 at 02:29:13PM +0100, Bernhard Reiter wrote:
> > I've implemented something similiar for the FFII and its mailman
> > 2.0.x installation. Hold spam message will automatically be removed.
If you are interested I can explain how I did this for Mailman 2.0.x.
It is cronjob, just moving the marked emails away from the data directory.
> > 2.1.4 versions might be able to do this themselfs.
>
> Sounds good - but as a more recent Mailman version needs python 2.x
> this would require a complete reinstallation of 'grass.itc.it'.
> I hesitate to reinstall it (kernel is updated if needed of course).
> Never touch ...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20040112/acb7574b/attachment.bin
From michael.barton at asu.edu Mon Jan 12 11:41:59 2004
From: michael.barton at asu.edu (Michael Barton)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] Mac OSX startup error
In-Reply-To: <200401121144.i0CBi0S20840@grass.itc.it>
Message-ID: <3DAE0C1E-451E-11D8-A2C2-00039313C09E@asu.edu>
Markus,
This error has always shown up when TclTk is starting for GRASS. It
still does in grass 5.3 and 5.7 with the automatic note to 'inform the
developers'. There has never seemed to have been a problem in
functionality, so I have largely ignored it. Perhaps it is the cause of
the ever-growing menus and dialogs that I reported awhile back, but I
don't know.
Michael Barton
On Monday, January 12, 2004, at 04:44 AM, grass5-request@grass.itc.it
wrote:
> To:
> Cc: grass5@grass.itc.it
> Subject: [GRASS5] [bug #2174] (grass) Mac OSX startup: ERROR: Invalid
> return code
> Reply-To: guest user via RT
>
>
>> [Valentine:~] bmadin% grass5
>> Cleaning up temporary files.....
>> Starting GRASS ...
>> : command not foundtc/Init.sh:
>
> Is this still an issue on Mac OSX?
>
> Markus
>
______________________________
Michael Barton, Professor & Curator
Department of Anthropology
Arizona State University
Tempe, AZ 85287-2402
USA
voice: 480-965-6262; fax: 480-965-7671
From hamish_nospam at yahoo.com Tue Jan 13 01:13:50 2004
From: hamish_nospam at yahoo.com (Hamish)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] grass 5.0.3 in debian
In-Reply-To: <20040112083752.GE3731@thuille.itc.it>
References: <20040105130845.GD13455@intevation.de>
<1073311576.1020.55.camel@localhost>
<20040107145228.GG3467@thuille.itc.it>
<1073488749.1035.4.camel@localhost>
<20040112083752.GE3731@thuille.itc.it>
Message-ID: <20040113191350.5f454184.hamish_nospam@yahoo.com>
[Hi everyone, happy New Year]
> the GRASS 5.0.3 package has been submitted to debian.
Great! This'll make the Knoppix based distros really easy to put together as
well.
A couple of points about the new Debian package..
(mostly from looking at the Debian.ChangeLog & package page, I haven't
tested or even inspected the package so I could be mistaken on some of
these...)
- what happened to all the dependencies? they all seem to be missing.
e.g., look at
http://packages.debian.org/testing/science/grass
vs
http://packages.debian.org/unstable/science/grass
?
- add a dependency to the new gdal-bin package and build --with-gdal ?
This is in testing now.
- DBM patch & deps not needed as GRASS doesn't actually use DBM.
Build without.
> Added build-deps in control file:
> + libgdbm-dev for --with-dbm
- after changing to tcl/tk 8.4, does NVIZ still work??? could someone check?
> Build against tcl/tk 8.4 (Closes: #206844).
for possible fix, see
http://article.gmane.org/gmane.comp.gis.grass.devel/2036/
??
maybe fixed in the latest tcl/tk packages?
- The unstable package page (see above) says the package is 34mb,
Size: 34619.9
Installed size: 84920
Is it possible to build 5.0.3 with shared libs or is that 5.3+ only?
- What's with avoiding the freetype check? I've never had a problem with
the standard Debian version of freetype2..
> Include dir for freetype2 is /usr/include/freetype2/freetype
> + debian/rules
With Debian I've always used:
./configure --with-freetype --with-freetype-includes=/usr/include/freetype2
?
cheers,
Hamish
From glynn.clements at virgin.net Tue Jan 13 01:38:54 2004
From: glynn.clements at virgin.net (Glynn Clements)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] grass 5.0.3 in debian
In-Reply-To: <20040113191350.5f454184.hamish_nospam@yahoo.com>
References: <20040105130845.GD13455@intevation.de>
<1073311576.1020.55.camel@localhost>
<20040107145228.GG3467@thuille.itc.it>
<1073488749.1035.4.camel@localhost>
<20040112083752.GE3731@thuille.itc.it>
<20040113191350.5f454184.hamish_nospam@yahoo.com>
Message-ID: <16387.37502.132696.228346@cerise.nosuchdomain.co.uk>
Hamish wrote:
> - The unstable package page (see above) says the package is 34mb,
> Size: 34619.9
> Installed size: 84920
> Is it possible to build 5.0.3 with shared libs or is that 5.3+ only?
It's possible, but not officially supported. I wouldn't recommend it
for building distributions (except for e.g. iPAQ where the space
saving is a necessity).
--
Glynn Clements
From hamish_nospam at yahoo.com Tue Jan 13 02:40:46 2004
From: hamish_nospam at yahoo.com (Hamish)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] grass 5.0.3 in debian
In-Reply-To: <16387.37502.132696.228346@cerise.nosuchdomain.co.uk>
References: <20040105130845.GD13455@intevation.de>
<1073311576.1020.55.camel@localhost>
<20040107145228.GG3467@thuille.itc.it>
<1073488749.1035.4.camel@localhost>
<20040112083752.GE3731@thuille.itc.it>
<20040113191350.5f454184.hamish_nospam@yahoo.com>
<16387.37502.132696.228346@cerise.nosuchdomain.co.uk>
Message-ID: <20040113204046.369fa82e.hamish_nospam@yahoo.com>
> > - The unstable package page (see above) says the package is 34mb,
> > Size: 34619.9
> > Installed size: 84920
> > Is it possible to build 5.0.3 with shared libs or is that 5.3+ only?
>
> It's possible, but not officially supported. I wouldn't recommend it
> for building distributions (except for e.g. iPAQ where the space
> saving is a necessity).
Note the Debian ARM build is probably the easiest way to install GRASS
on an iPAQ..
Still, I'd agree that for the Debian package stability is the most
important issue.
Hamish
From hamish_nospam at yahoo.com Tue Jan 13 02:56:54 2004
From: hamish_nospam at yahoo.com (Hamish)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] Re: [GRASSLIST:2166] Re: i.ortho.photo in xwin
In-Reply-To: <16382.1847.225704.942772@cerise.nosuchdomain.co.uk>
References: <200401081939.i08Jdru1004446@darkwing.uoregon.edu>
<3FFDFC36.4010003@greenwoodmap.com>
<16382.1847.225704.942772@cerise.nosuchdomain.co.uk>
Message-ID: <20040113205654.67d23985.hamish_nospam@yahoo.com>
> > I don't know what might be happening in your case, but I can say
> > that i.ortho.photo works in Cygwin. And if you add
> > GRASS_STDERR: 1
> > to .grassrc5 you will disable the send mail and the message should
> > got to sdtout (your shell window) instead.
>
> Actually, I don't think that's true of photo.rectify.
>
> There is a facility for mailing errors to the user built into the
> libgis error functions (G_warning/G_fatal_error), and that can be
> disabled by setting GRASS_STDERR.
>
> However, photo.rectify has its own version of this functionality, and
> there doesn't appear to be an override. Unless you have a working
> "mail" program (which implies a working local mail system), you can't
> see the messages.
>
> OTOH, I suppose that you could create a dummy "mail" script which just
> appends its input to a log file.
should this be ripped out of the rectify programs? The speed/use of
modern UNIX computers makes this functionality a bit weird, and the user
can always background the job themselves if they want to do something
else.
code simplification and all that.
?,
Hamish
From frankie at debian.org Tue Jan 13 04:54:21 2004
From: frankie at debian.org (Francesco P. Lovergine)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] grass 5.0.3 in debian
In-Reply-To: <20040113191350.5f454184.hamish_nospam@yahoo.com>
References: <20040105130845.GD13455@intevation.de>
<1073311576.1020.55.camel@localhost> <20040107145228.GG3467@thuille.itc.it>
<1073488749.1035.4.camel@localhost> <20040112083752.GE3731@thuille.itc.it>
<20040113191350.5f454184.hamish_nospam@yahoo.com>
Message-ID: <20040113095421.GB4135@firewall.ba.issia.cnr.it>
On Tue, Jan 13, 2004 at 07:13:50PM +1300, Hamish wrote:
> [Hi everyone, happy New Year]
>
> > the GRASS 5.0.3 package has been submitted to debian.
>
> Great! This'll make the Knoppix based distros really easy to put together as
> well.
>
>
> A couple of points about the new Debian package..
> (mostly from looking at the Debian.ChangeLog & package page, I haven't
> tested or even inspected the package so I could be mistaken on some of
> these...)
>
>
> - what happened to all the dependencies? they all seem to be missing.
> e.g., look at
> http://packages.debian.org/testing/science/grass
> vs
> http://packages.debian.org/unstable/science/grass
> ?
>
>
Federico, dh_shlibdeps is missing in rules :-/
We need to re-release ASAP...
> - add a dependency to the new gdal-bin package and build --with-gdal ?
> This is in testing now.
>
We could consider this I think.
>
> - DBM patch & deps not needed as GRASS doesn't actually use DBM.
> Build without.
> > Added build-deps in control file:
> > + libgdbm-dev for --with-dbm
>
This is GDBM, not DBM. Ok, due for next release.
>
> - after changing to tcl/tk 8.4, does NVIZ still work??? could someone check?
> > Build against tcl/tk 8.4 (Closes: #206844).
> for possible fix, see
> http://article.gmane.org/gmane.comp.gis.grass.devel/2036/
> ??
> maybe fixed in the latest tcl/tk packages?
>
To be verified.
>
> - What's with avoiding the freetype check? I've never had a problem with
> the standard Debian version of freetype2..
> > Include dir for freetype2 is /usr/include/freetype2/freetype
> > + debian/rules
> With Debian I've always used:
> ./configure --with-freetype --with-freetype-includes=/usr/include/freetype2
> ?
>
You have to use the _current_ sid package for libfreetype6-dev (2.1.7-1.1) to see the
problem. In /usr/include/freetype2/freetype/freetype.h:
#ifndef FT_FREETYPE_H
#error "`ft2build.h' hasn't been included yet!"
#error "Please always use macros to include FreeType header files."
#error "Example:"
#error " #include "
#error " #include FT_FREETYPE_H"
#endif
this causes a configure test error and requires changes in a couple of files.
--
Francesco P. Lovergine
From kwythers at umn.edu Tue Jan 13 11:10:03 2004
From: kwythers at umn.edu (Kirk R. Wythers)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] grass 5.7 new location fails
Message-ID:
I am trying to create a new location in 5.7. I am attempting this from
the grass startup and I seem to be stuck in a loop.
1. I start grass
2. I get the gui that has a create new location button
3. I cd to the dir /usr/local/share/grassdata
3. If I hit the create new location button, grasss crashes with the
error:
ERROR: Invalid return code from gis_set.tcl.
Please advise GRASS developers of this error.
/usr/local/grass57/etc/Init.sh: line 497: LOCATION_NAME: parameter null
or not set
truffula:~ kirkw$
4. I try and restart grass, but get the error:
Cleaning up temporary files.....
Starting GRASS ...
ERROR: LOCATION_NAME not set
Error in startup script: can't read "env_location": no such variable
while executing
"set location $env_location"
(procedure "searchGISRC" line 23)
invoked from within
"searchGISRC $gisrc_name"
(file "/usr/local/grass57/etc/gis_set.tcl" line 1)
/usr/local/grass57/etc/Init.sh: line 497: LOCATION_NAME: parameter null
or not set
truffula:~ kirkw$
5. I rm the .grassrc57 file and the the sequence repeats...
Kirk
From glynn.clements at virgin.net Tue Jan 13 15:16:03 2004
From: glynn.clements at virgin.net (Glynn Clements)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] Cygwin binary package
Message-ID: <16388.20995.361993.982097@cerise.nosuchdomain.co.uk>
I have a report that one of the Cygwin binary packages on grass.itc.it
includes a broken version of NVIZ (linked against Cygwin's tcl84.dll,
which won't work).
Can someone either remove the package, or at least remove NVIZ from
it.
I neglected to ask which version (generic/xserver), although there
doesn't seem much point including NVIZ in the wingrass_generic
version.
--
Glynn Clements
From swlab at cornell.edu Tue Jan 13 17:55:30 2004
From: swlab at cornell.edu (SWlab)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] r.what
Message-ID: <200401131755.30232.swlab@cornell.edu>
Hello,
A silly question: does r.what work with x,y coordinates ? We just tried a
r.what in such a map, and the xs seem really strange (some of the values have
a * character). FYI, the top left corner of our maps is not 0,0, but
700.5,1000.5...
Any hint welcome !
Thanks a lot in advance
P.
--
Soil & Water Laboratory
Dept. of Biological & Environmental Engineering
Cornell University
ITHACA, NY 14853
Tel: (607)255.2463
From ametts2 at mindspring.com Tue Jan 13 19:13:58 2004
From: ametts2 at mindspring.com (Allan Metts)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] Position available - Senior Software Engineer
Message-ID: <6.0.1.1.2.20040113191307.027187f8@pop.mindspring.com>
My apologies if this is considered spam, but I'm pretty sure it's germane
and beneficial to the list membership...
AirSage Inc. is seeking an energetic Senior Software Engineer to expand and
enhance the company's unique product offering. AirSage creates software
that allows road traffic speeds and other information to be determined from
cellular network signalling data.
The qualified candidate will possess SEVEN OR MORE of the following
characteristics:
--*-- At least five years of solid C++ development experience, preferably
on both UNIX/Linux and Windows
--*-- Object-Oriented Analysis and Design (OOA&D) expertise
--*-- System Administration expertise on UNIX or Linux
--*-- Significant programming experience using the Standard C++ Library,
including the Standard Template Library (STL)
--*-- Distributed systems experience using CORBA or a similar technology
(ACE/TAO is a plus)
--*-- Geographic Information Systems (GIS) programming experience using
MapInfo, ESRI, GRASS, or a similar platform
--*-- Telecommunications Industry experience, or experience working with
Federal, State, and Municipal Transportation departments.
--*-- Excellent written communications skills
--*-- A driven, goal-oriented personality, and a willingness to take on
administrative, documentation, testing, or analysis tasks when necessary
--*-- An ability to work independently, yet sill provide regular and
insightful communication to upper management
Qualified candidates should send their resume as an email attachment to
jobs-gr@airsage.com. DO NOT REPLY TO THIS MAILING LIST!!! Please include
your salary history and highlights of particularly relevant experience in
the body of the email.
Work location is negotiable. Please do not apply if you are not
comfortable working in a fast-paced, entrepreneurial environment. AirSage
is an equal-opportunity employer.
From hamish_nospam at yahoo.com Tue Jan 13 19:18:48 2004
From: hamish_nospam at yahoo.com (Hamish)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] r.what
In-Reply-To: <200401131755.30232.swlab@cornell.edu>
References: <200401131755.30232.swlab@cornell.edu>
Message-ID: <20040114131848.1be27731.hamish_nospam@yahoo.com>
> A silly question: does r.what work with x,y coordinates ? We just
> tried a r.what in such a map, and the xs seem really strange (some of
> the values have a * character). FYI, the top left corner of our maps
> is not 0,0, but 700.5,1000.5...
GRASS:~> r.what --help
[...]
Parameters:
input Name of existing raster map
cache Size of point cache
default: 500
null Char string to represent no data cell
default: *
east_north Coordinates for query
so the *'s you are seeing represent null values.
using null=NaN or something might be more useful to you if you want to
export the data to Matlab, etc..
regards,
Hamish
From hamish_nospam at yahoo.com Tue Jan 13 21:33:13 2004
From: hamish_nospam at yahoo.com (Hamish)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] r.what
In-Reply-To: <200401131932.36586.swlab@cornell.edu>
References: <200401131755.30232.swlab@cornell.edu>
<20040114131848.1be27731.hamish_nospam@yahoo.com>
<200401131932.36586.swlab@cornell.edu>
Message-ID: <20040114153313.59bd047f.hamish_nospam@yahoo.com>
> Hamish, thanks for your answer, but that's not what I meant :
>
> Here's an example of result of r.what
> |*9.6|897|24.1
wierd. the line shouldn't start with "|" either.
> As you can see, the * character is where my 'x' should be, not where
> my values would. Checking with d.what.rast, the actual value should be
> 799.6 for this example. On about 500 points, only 10 of them have
> these strange coordinates. The * does not always represnt the same
> string (in the example here, it was '79', on some others, it was
> '13'... It would have been too easy to parse the result to a script to
> get proper results, you can imagine... Oh, and the problematic values
> are not on the borders: I have some sites on both sides that output
> proper coordinates. Do you have any idea of what may happen ?
what does the command line look like?
are you feeding postions from stdin or a file?
does setting null= to something other than * make it
"|NaN9.6|897|24.1" or "|NaN6|897|24.1"?
what computer platform? (ie newline problem)
if this is cygwin, could you open with TextPad? (www.textpad.com)
if this is mac, could you open & view with bbedit or nedit from fink?
what does a good data line look like? (ie querying one or two maps?)
looks to me like a bug -- the "79" of "799.6" gets over written by a
return without a newline and then the final queried value ("|*").
?
Hamish
From neteler at itc.it Wed Jan 14 10:00:24 2004
From: neteler at itc.it (Markus Neteler)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] Cygwin binary package
In-Reply-To: <16389.7758.584471.99519@cerise.nosuchdomain.co.uk>
References: <16388.20995.361993.982097@cerise.nosuchdomain.co.uk> <20040114090959.GB1243@thuille.itc.it> <16389.7758.584471.99519@cerise.nosuchdomain.co.uk>
Message-ID: <20040114150024.GA3168@thuille.itc.it>
On Wed, Jan 14, 2004 at 10:47:42AM +0000, Glynn Clements wrote:
>
> Markus Neteler wrote:
>
> > > I have a report that one of the Cygwin binary packages on grass.itc.it
> > > includes a broken version of NVIZ (linked against Cygwin's tcl84.dll,
> > > which won't work).
> > >
> > > Can someone either remove the package, or at least remove NVIZ from
> > > it.
> >
> > Is there much difference in having included a broken NVIZ instead
> > of no NVIZ?
>
> No NVIZ is easier to explain.
>
> The user reports that this was with wingrass_generic. Given that none
> of the OpenGL stuff (i.e. NVIZ & r3.showdspf.openGL) will work without
> an X server, wingrass_generic should probably be built using
> --without-opengl.
So some kind person should rebuild the package (using 5.0.3).
Then we replace the existing package.
Markus
From glynn.clements at virgin.net Wed Jan 14 17:48:16 2004
From: glynn.clements at virgin.net (Glynn Clements)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] Cygwin binary package
In-Reply-To: <20040114150024.GA3168@thuille.itc.it>
References: <16388.20995.361993.982097@cerise.nosuchdomain.co.uk>
<20040114090959.GB1243@thuille.itc.it>
<16389.7758.584471.99519@cerise.nosuchdomain.co.uk>
<20040114150024.GA3168@thuille.itc.it>
Message-ID: <16389.50992.140787.461929@cerise.nosuchdomain.co.uk>
Markus Neteler wrote:
> > > > I have a report that one of the Cygwin binary packages on grass.itc.it
> > > > includes a broken version of NVIZ (linked against Cygwin's tcl84.dll,
> > > > which won't work).
> > > >
> > > > Can someone either remove the package, or at least remove NVIZ from
> > > > it.
> > >
> > > Is there much difference in having included a broken NVIZ instead
> > > of no NVIZ?
> >
> > No NVIZ is easier to explain.
> >
> > The user reports that this was with wingrass_generic.
He's changed his mind; apparently it was wingrass_xserver. That
*should* be built with OpenGL and TclTk; however, you have to force it
to use xtcltk and not Cygwin's Tcl/Tk, e.g. using
--with-tcltk-includes=/usr/local/include --with-tcltk-libs=/usr/local/lib
If you don't have xtcltk, then at least use --without-tcltk.
It would be nice to have configure check that the version of Tcl/Tk
which it finds will actually work, but I have no idea how to detect
that.
--
Glynn Clements
From hamish_nospam at yahoo.com Thu Jan 15 00:26:50 2004
From: hamish_nospam at yahoo.com (Hamish)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] Re: [GRASSLIST:2232] can't find tk.h
In-Reply-To: <40061FD4.9030601@greenwoodmap.com>
References: <40061FD4.9030601@greenwoodmap.com>
Message-ID: <20040115182650.262ebfe3.hamish_nospam@yahoo.com>
> I am trying to build 5.0.3 on Cygwin, but configure is failing:
>
> checking for location of Tcl/Tk includes... /usr/local/include
> checking for tcl.h... yes
> checking for tk.h... no
>
> But I have
> --with-tcltk-includes=/usr/local/include
> and tk.h is in /usr/local/include !!!???
>
> I think I am cross-eyed from looking at this for too long. What is it
> that I am missing?
what does the end of "config.log" say?
Hamish
From hamish_nospam at yahoo.com Thu Jan 15 05:23:22 2004
From: hamish_nospam at yahoo.com (Hamish)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] horizontal legends with d.legend
Message-ID: <20040115232322.01ba106f.hamish_nospam@yahoo.com>
Hi,
I just added support for horizontal legend labels to d.legend in CVS.
I'd appreciate it if someone could test to make sure I didn't break
anything while I was at it.
screenshot:
http://bambi.otago.ac.nz/hamish/grass/horiz_legend.png
enjoy,
Hamish
From mthomas at gil.com.au Thu Jan 15 07:05:11 2004
From: mthomas at gil.com.au (Mike Thomas)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] Cygwin binary package
In-Reply-To: <16389.50992.140787.461929@cerise.nosuchdomain.co.uk>
References: <16388.20995.361993.982097@cerise.nosuchdomain.co.uk> <20040114090959.GB1243@thuille.itc.it> <16389.7758.584471.99519@cerise.nosuchdomain.co.uk> <20040114150024.GA3168@thuille.itc.it> <16389.50992.140787.461929@cerise.nosuchdomain.co.uk>
Message-ID: <400681F7.3080505@gil.com.au>
Hi there.
Whichever was the last version of Grass for which I sent a Cygwin binary
package, NVIZ was built into that package, tested and known to work.
Cheers
Mike Thomas
Glynn Clements wrote:
>Markus Neteler wrote:
>
>
>
>>>>>I have a report that one of the Cygwin binary packages on grass.itc.it
>>>>>includes a broken version of NVIZ (linked against Cygwin's tcl84.dll,
>>>>>which won't work).
>>>>>
>>>>>Can someone either remove the package, or at least remove NVIZ from
>>>>>it.
>>>>>
>>>>>
>>>>Is there much difference in having included a broken NVIZ instead
>>>>of no NVIZ?
>>>>
>>>>
>>>No NVIZ is easier to explain.
>>>
>>>The user reports that this was with wingrass_generic.
>>>
>>>
>
>He's changed his mind; apparently it was wingrass_xserver. That
>*should* be built with OpenGL and TclTk; however, you have to force it
>to use xtcltk and not Cygwin's Tcl/Tk, e.g. using
>
>--with-tcltk-includes=/usr/local/include --with-tcltk-libs=/usr/local/lib
>
>If you don't have xtcltk, then at least use --without-tcltk.
>
>It would be nice to have configure check that the version of Tcl/Tk
>which it finds will actually work, but I have no idea how to detect
>that.
>
>
>
From paul-grass at stjohnspoint.co.uk Thu Jan 15 08:22:08 2004
From: paul-grass at stjohnspoint.co.uk (Paul Kelly)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] Re: [GRASS-CVS] paul: grass/src/display/d.db main.c,1.8,1.9
In-Reply-To: <20040115121914.GC10202@thuille.itc.it>
References: <20040115111534.D3DFE13B55@lists.intevation.de>
<20040115121914.GC10202@thuille.itc.it>
Message-ID:
On Thu, 15 Jan 2004, Markus Neteler wrote:
> On Thu, Jan 15, 2004 at 12:15:34PM +0100, grass@intevation.de wrote:
> > Author: paul
> >
> > Update of /grassrepository/grass/src/display/d.db
> > In directory doto:/tmp/cvs-serv20635/d.db
> >
> > Modified Files:
> > main.c
> > Log Message:
> > snprintf removal (when updated to 5.7 can use G_asprintf)
>
>
> Hello Paul,
>
> while I don't know anything about snprintf, why not adding
> G_asprintf() to 5.3? Then it were solved.
>
> Sorry if this is a stupid question,
No not a stupid question at all, in fact in my local installation I have
G_asprintf() compiled into 5.3 (I used it for some tests with the proj
library a while ago).
Really I suppose the idea was just we didn't want to be making too many
'improvements' to 5.3. It would be nice to put it in---actually maybe that
wouldn't be too much work and it woud be good to have there for people who
wanted to make unofficial add-ons and improvements to 5.3/5.4 after it is
released.
At the moment all I was doing was tidying some things up still in
preparation for a 5.3.0 release, and I didn't have time to think about it
more.
Paul
From michael.barton at asu.edu Thu Jan 15 11:10:49 2004
From: michael.barton at asu.edu (Michael Barton)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] more GRASS 5.7 testing under MacOSX
In-Reply-To: <200401151101.i0FB11S12015@grass.itc.it>
Message-ID: <622A7D54-4775-11D8-BBC5-00039313C09E@asu.edu>
Getting ready for my class this semester, I downloaded and began
testing GRASS 5.7 again. I am using the 20 November 2003 binaries that
Markus has kindly made available. Some of these things may have been
dealt with in the current CVS snapshot, but I haven't yet had the
chance to try compiling it.
So far, I've seen a couple old bugs still in effect, and run into a new
one. Also, given that the new version is overall quite stable and
potentially useful, I want to add two requests.
1. Nviz still doesn't work. Trying to start it returns an error that
nviz2.2_script can't be found (even though it is indeed located in the
proper place). I tried to force run the script from within grass, but
it crashed before it started with several errors. If anyone is
interested, I can send these. I don't know if this is because Nviz
doesn't work with 5.7 yet, or it is a bug in the startup script.
2. In the display manager, when reorganizing the different map layers,
dragging a layer a little too far (it doesn't take much) below the
bottom-most layer starts an endless error loop that can only be exited
by crashing out of GRASS.
3. This may be new. d.what.vect is not functioning correctly. In normal
mode, it is supposed to return a new tcltk monitor with information
about fields that can be changed if needed. This does not happen. If I
am lucky, nothing happens; if unlucky, d.what.vect crashes with a
problem with child process error. I CAN get information about a vector
if I select the option to display it as text in a terminal window.
Toggling flash and exit functions seem to work fine.
4. Request. Can a menu system be made for the majority of the
commands--as in version 5.0.x? It could be pull downs across the top
(as in prior GRASS versions), along the side (as in ArcInfo and some
CAD programs), or floating pallets like in GIMP. I just can remember
ALL the commands.
5. The dialogs for the g.* (general) commands all seem to lack browse
buttons. Can browse buttons be added?
I think this is a very good and exciting product. I am strongly
suggesting it for the graduate students here.
Thanks very much
Michael
______________________________
Michael Barton, Professor & Curator
Department of Anthropology
Arizona State University
Tempe, AZ 85287-2402
USA
voice: 480-965-6262; fax: 480-965-7671
From neteler at itc.it Thu Jan 15 11:35:34 2004
From: neteler at itc.it (Markus Neteler)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] more GRASS 5.7 testing under MacOSX
In-Reply-To: <622A7D54-4775-11D8-BBC5-00039313C09E@asu.edu>
References: <200401151101.i0FB11S12015@grass.itc.it> <622A7D54-4775-11D8-BBC5-00039313C09E@asu.edu>
Message-ID: <20040115163534.GC29373@thuille.itc.it>
On Thu, Jan 15, 2004 at 09:10:49AM -0700, Michael Barton wrote:
> Getting ready for my class this semester, I downloaded and began
> testing GRASS 5.7 again. I am using the 20 November 2003 binaries that
> Markus has kindly made available. Some of these things may have been
> dealt with in the current CVS snapshot, but I haven't yet had the
> chance to try compiling it.
>
> So far, I've seen a couple old bugs still in effect, and run into a new
> one. Also, given that the new version is overall quite stable and
> potentially useful, I want to add two requests.
>
> 1. Nviz still doesn't work. Trying to start it returns an error that
> nviz2.2_script can't be found (even though it is indeed located in the
> proper place). I tried to force run the script from within grass, but
> it crashed before it started with several errors. If anyone is
> interested, I can send these. I don't know if this is because Nviz
> doesn't work with 5.7 yet, or it is a bug in the startup script.
>
Michael,
in 5.7, due to the above mentioned (path) problem NVIZ only runs
via command line:
nviz el=elevation vect=vect1[,vect2[,...]] [col=draperastermap]
One day we'll solve that...
> 2. In the display manager, when reorganizing the different map layers,
> dragging a layer a little too far (it doesn't take much) below the
> bottom-most layer starts an endless error loop that can only be exited
> by crashing out of GRASS.
Yes, a bad problem! I also face it.
[...]
Markus
From hamish_nospam at yahoo.com Thu Jan 15 22:51:10 2004
From: hamish_nospam at yahoo.com (Hamish)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] d.text.freetype enhancement
Message-ID: <20040116165110.4718f5f9.hamish_nospam@yahoo.com>
I just added some sutff to d.text.freetype which hopefully will make it
a bit more useful & standardized.
- added a flag to place text as percentage of frame window
(already has a flag to do so by pixels or by easting,northing)
- changed the color= option to accept R:G:B triplets in the same way
that d.vect.line & d.vect.area do. The old way was color=0xRRGGBB
I've kept it backwards compatible, but the old usage is now an
undocumented feature.
still to do:
a) figure out why some microsoft/mac TrueType fonts don't work.
b) figure out why the new Debian freetype2 library requires
#include "
#include FT_FREETYPE_H"
instead of
#include
(see ft2build.h header comments)
not sure how this affects older systems so I'm leaving it as-is.
Hamish
From glynn.clements at virgin.net Thu Jan 15 20:52:18 2004
From: glynn.clements at virgin.net (Glynn Clements)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] Re: [GRASSLIST:2243] rectification and display questions
In-Reply-To: <1F622B4E-4775-11D8-A798-000A95A721F0@umn.edu>
References: <1F622B4E-4775-11D8-A798-000A95A721F0@umn.edu>
Message-ID: <16391.17362.966729.956930@cerise.nosuchdomain.co.uk>
Kirk R. Wythers wrote:
> I am rectifying some raster images and have got a few questions for the
> list.
>
> 1. After setting points with i.points and running i.rectiy, I get the
> expected message that mail will be sent when job is completed. However
> I don't seem to get any mail (I assume it would be sent to the local
> machine's user account that is logged in and running grass). Is there a
> way to check or even change where mail is sent?
The system's logfiles may provide an indication of whether the mail
was sent. However, you can't change the destination; it's sent to the
current user, as determined by:
getpwuid(getuid())->pw_name
[Given the number of recent problems/queries regarding this "feature",
and the fact that we are now trying to support Cygwin and MacOSX
(which may not support this without significant configuration effort),
I suggest that we consider getting rid of it.]
> 2. After quitting grass and restarting in the new location and mapset
> (where i.rectify was projecting to), I can see the new files of the
> geocoded tiffs:
>
> g.list type=rast
> ----------------------------------------------
> raster files available in mapset ts2325:
> t59n.r10w.1.blue_r t59n.r10w.1.green_r t59n.r10w.1.red_r
>
> I just used a _r for the extension that i.rectify asked for...
>
> However, upon attempting to display in a monitor with r.rgb
You mean d.rgb, right?
> (after
> setting region with g.region), all I get is a nice black image. Is
> there something that I need to do to the color tables?
Quite possibly.
If the program which generated the maps didn't set the colour tables
correctly, you need to use "r.colors ... color=rules" to set a
grey-scale colour table which is appropriate for the data (typically,
black is 0 and white is the "100% intensity" value, e.g. 255 for 8-bit
integer data).
NB: you typically only need to use "color=rules" for the first map;
for the other two, you can use "rast=..." to copy the colour table
from the first map.
I can think of two likely reasons why the maps might be completely
black:
1. Something coerced floating-point data in the range 0.0 to 1.0 to
integers, resulting in all-zero output.
2. The data contains some extreme values (typically meant to represent
NULL but not interpreted as such), resulting in the colour table being
stretched over an extreme range, so that the "real" data only spans a
tiny proportion of the range.
The first step is to analyse the data with e.g. r.info (to check the
range), d.histogram (to check the distribution), d.legend (to
visualise the colour table) and/or d.rast (to view individual
channels).
--
Glynn Clements
From hamish_nospam at yahoo.com Fri Jan 16 01:48:15 2004
From: hamish_nospam at yahoo.com (Hamish)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] d.text enhancement
In-Reply-To: <20040116165110.4718f5f9.hamish_nospam@yahoo.com>
References: <20040116165110.4718f5f9.hamish_nospam@yahoo.com>
Message-ID: <20040116194815.0eee7a0d.hamish_nospam@yahoo.com>
Moving right along..
I just added some stuff to d.text which hopefully will make it
a bit more useful & standardized.
* added an at= option to place text as a percentage of window
height/width in the current display frame.
* added support to the color= option for R:G:B triplets
* added a -b flag to allow you to bold text from the command line.
Behaviour is same as before if you don't use the new options.
The common theme here is to be able to resize windows without having to
redo all your text, and have access to whatever colours you want.
enjoy (& let me know if it breaks),
Hamish
From woklist at charter.net Fri Jan 16 10:40:37 2004
From: woklist at charter.net (William K)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] d.text.freetype enhancement
In-Reply-To: <20040116165110.4718f5f9.hamish_nospam@yahoo.com>
References: <20040116165110.4718f5f9.hamish_nospam@yahoo.com>
Message-ID: <54C0E326-483A-11D8-9FE6-000A95DB713E@charter.net>
Hamish -
There is a dev version of freetype 2.1.8 that's been out a while (it's
pretty stable as far as I can tell). Debian might be using that now
(tho I couldn't say, since I'm on a Mac). This is a documented change
in the whole freetype setup as of v2.1.6. I also had to 'fix' the
d.text.freetype build after installing the new freetype. You probably
need to add a conditional thingy in the configure script and
d.text.freetype source to catch this.
On Jan 15, 2004, at 9:51 PM, Hamish wrote:
> b) figure out why the new Debian freetype2 library requires
> #include "
> #include FT_FREETYPE_H"
> instead of
> #include
>
> (see ft2build.h header comments)
>
> not sure how this affects older systems so I'm leaving it as-is.
-----
William Kyngesburye
http://webpages.charter.net/kyngchaos/
"Those people who most want to rule people are, ipso-facto, those least
suited to do it."
- A rule of the universe, from the HitchHiker's Guide to the Galaxy
From michael.barton at asu.edu Fri Jan 16 11:13:07 2004
From: michael.barton at asu.edu (Michael Barton)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] Testing Grass 5.3
In-Reply-To: <200401161101.i0GB11S19807@grass.itc.it>
Message-ID:
As with GRASS 5.7, I've been doing considerable testing of GRASS 5.3.
Overall, it is highly stable and works very well. Here are a couple of
minor items that perhaps could be fixed before it is released as stable.
1. v.transform does not operate correctly, at least under Mac OSX. It
requires an ASCII vector file as input, looks in the dig_ASCII folder,
but will not recognize an ASCII vector file unless it is put (manually
and incorrectly) into the dig folder. It produces an incomplete output
file (header and attributes, but no vectors). This was a problem on an
earlier release; I have tried this on the the 12 January CVS snapshot
and it is still a problem.
2. A small annoying item with r.colors under tcltk. If you check the
'rules' box, nothing happens. It **should** go to a terminal screen and
allow you to enter a set of color rules. This is what happens if you
use r.color via the terminal command line.
3. v.in.dxf doesn't work correctly with at least some dxf files with
attributes. It does nothing if attributes are attached. I've only tried
this with dxf files produced by MapInfo, so that may be the problem. If
anyone has some insight, they might look into it.
# 3 is also a problem under 5.0.x; I don't know if #1 & 2 are also
inherited from 5.0. So far, that's pretty much it that I've run into
that doesn't work as advertised. All told, that is extremely good.
_____________________________
C. Michael Barton, Professor & Curator
Department of Anthropology
Arizona State University
Tempe, AZ 85287-2402
Phone: 480-965-6262
Fax: 480-965-7671
From neteler at itc.it Fri Jan 16 11:31:47 2004
From: neteler at itc.it (Markus Neteler)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] more GRASS 5.7 testing under MacOSX
In-Reply-To: <622A7D54-4775-11D8-BBC5-00039313C09E@asu.edu>
References: <200401151101.i0FB11S12015@grass.itc.it> <622A7D54-4775-11D8-BBC5-00039313C09E@asu.edu>
Message-ID: <20040116163147.GC17320@thuille.itc.it>
On Thu, Jan 15, 2004 at 09:10:49AM -0700, Michael Barton wrote:
> Getting ready for my class this semester, I downloaded and began
> testing GRASS 5.7 again. I am using the 20 November 2003 binaries that
> Markus has kindly made available. Some of these things may have been
> dealt with in the current CVS snapshot, but I haven't yet had the
> chance to try compiling it.
>
[...]
> 5. The dialogs for the g.* (general) commands all seem to lack browse
> buttons. Can browse buttons be added?
Yes, done for g.copy, g.rename, g.remove (in 5.7 CVS). Do you
think of any other command?
> I think this is a very good and exciting product. I am strongly
> suggesting it for the graduate students here.
Great - hopefully they enjoy it,
Markus
From jeff.hamann at forestinformatics.com Thu Jan 15 15:43:05 2004
From: jeff.hamann at forestinformatics.com (Jeff D. Hamann)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] importing ASTER images using hdf2bin and r.in.bin?
Message-ID: <001301c3dba8$2e3c5380$0a00a8c0@rodan>
I've been trying to import ASTER images using the hdf2bin tool and then
importing the resulting files using r.in.bin with limited success. The
hdf2bin program gives be the a list of the following information:
Swath "TIR_Swath" has following mapping information:
Regular dimension mapping between geo and data fields:
GeoTrack/ImageLine,GeoXtrack/ImagePixel
Mapping increment = 70 83
Mapping offset = 0 0
Geolocation field(s): Latitude,Longitude
Data field(s): ImageData10,ImageData11,ImageData12,ImageData13,ImageData14
Swath "TIR_Swath" contains following field(s):
float64 SWATH_TIR_Swath_Latitude.dat (GeoTrack=11,GeoXtrack=11)
Data type: 64-bit floating point
Number of Dimensions: 2
Dim 1: "GeoTrack" = 11
Dim 2: "GeoXtrack" = 11
float64 SWATH_TIR_Swath_Longitude.dat (GeoTrack=11,GeoXtrack=11)
Data type: 64-bit floating point
Number of Dimensions: 2
Dim 1: "GeoTrack" = 11
Dim 2: "GeoXtrack" = 11
uint16 SWATH_TIR_Swath_ImageData10.dat (ImageLine=700,ImagePixel=830)
Data type: unsigned 16-bit integer
Number of Dimensions: 2
Dim 1: "ImageLine" = 700
Dim 2: "ImagePixel" = 830
uint16 SWATH_TIR_Swath_ImageData11.dat (ImageLine=700,ImagePixel=830)
Data type: unsigned 16-bit integer
Number of Dimensions: 2
Dim 1: "ImageLine" = 700
Dim 2: "ImagePixel" = 830
uint16 SWATH_TIR_Swath_ImageData12.dat (ImageLine=700,ImagePixel=830)
Data type: unsigned 16-bit integer
Number of Dimensions: 2
Dim 1: "ImageLine" = 700
Dim 2: "ImagePixel" = 830
The first three files import correctly, that is to say I can import them at
all and the rest give me the following:
GRASS:~ > r.in.bin input=SWATH_TIR_Swath_ImageData11.dat r=700 c=830
output=tir11
Using N=700.000000 S=0.000000 E=830.000000 W=0.000000
Bytes do not match File size
File Size 1162321 ... Total Bytes 581000
Try bytes=2 or adjusting input parameters
GRASS:~ >
Even when I include the bytes=2 argument, I get an error. Is there something
I'm doing wrong or is the file and/or GRASS broken? Or is there a better way
to import HDF-EOS files into grass? I'm running
GRASS 5.0.3 on cygwin and r.in.hdf isn't found and I haven't had the nerve
to try to compile GRASS with gdal support although I have been able to get
GRASS to build on my machine.
Thanks,
Jeff.
---
Jeff D. Hamann
Forest Informatics, Inc.
PO Box 1421
Corvallis, Oregon USA 97339-1421
(office) 541-754-1428
(cell) 541-740-5988
jeff.hamann@forestinformatics.com
www.forestinformatics.com
From neteler at itc.it Fri Jan 16 11:39:01 2004
From: neteler at itc.it (Markus Neteler)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] cd $LOCATION revisited
In-Reply-To: <4007ED74.6EF6B60A@unity.ncsu.edu>
References: <20040102173713.GA31941@thuille.itc.it> <20040110223530.GA22856@thuille.itc.it> <40008B00.2030900@unity.ncsu.edu> <20040111200506.GB2601@thuille.itc.it> <4001EDDF.6040106@unity.ncsu.edu> <20040112082502.GD3731@thuille.itc.it> <4007ED74.6EF6B60A@unity.ncsu.edu>
Message-ID: <20040116163901.GD17320@thuille.itc.it>
There is probably some confusion concerning $LOCATION variable:
[...]
Writing Helena (GRASS 5.3-CVS):
> > > if I work in GRASS on command line and I type
> > >
> > > GRASS:~ > cd $GISDBASE/$LOCATION_NAME/$MAPSET
> > > GRASS:~/grassdata/wake-spft/helena > pwd
> > > /home/helena/grassdata/wake-spft/helena
> > > GRASS:~/grassdata/wake-spft/helena > ls
> > > cats cell cellhd cell_misc colr dig dig_att dig_cats dig_plus
> > > fcell g3dcell hist WIND
Answer Markus (GRASS 5.3-CVS):
> > On a standard version it doesn't work:
> >
> > GRASS:~ > cd $GISDBASE/$LOCATION_NAME/$MAPSET
> > GRASS:// >
... confusing!
Clarification (desired behaviour?):
> I don't have any trick or modification - Jaro has explained it to me -
> when you start GRASS with tcltk interface the variables get set up and
> it works as written above.
> If you start with -text then I get what you have described
> as standard version. So far on the machines where I have tried it
> it works like this without any tricks
>
> Helena
For me it's strange if, depending how GRASS was started, $LOCATION
is set or not. Guess that this should be fixed.
Markus
From jeff.hamann at forestinformatics.com Fri Jan 16 13:16:58 2004
From: jeff.hamann at forestinformatics.com (Jeff D. Hamann)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] importing ASTER images using hdf2bin and r.in.bin?
Message-ID: <012e01c3dc5c$ee370130$0a00a8c0@rodan>
I've been trying to import ASTER images using the hdf2bin tool and then
importing the resulting files using r.in.bin with limited success. The
hdf2bin program gives be the a list of the following information:
Swath "TIR_Swath" has following mapping information:
Regular dimension mapping between geo and data fields:
GeoTrack/ImageLine,GeoXtrack/ImagePixel
Mapping increment = 70 83
Mapping offset = 0 0
Geolocation field(s): Latitude,Longitude
Data field(s): ImageData10,ImageData11,ImageData12,ImageData13,ImageData14
Swath "TIR_Swath" contains following field(s):
float64 SWATH_TIR_Swath_Latitude.dat (GeoTrack=11,GeoXtrack=11)
Data type: 64-bit floating point
Number of Dimensions: 2
Dim 1: "GeoTrack" = 11
Dim 2: "GeoXtrack" = 11
float64 SWATH_TIR_Swath_Longitude.dat (GeoTrack=11,GeoXtrack=11)
Data type: 64-bit floating point
Number of Dimensions: 2
Dim 1: "GeoTrack" = 11
Dim 2: "GeoXtrack" = 11
uint16 SWATH_TIR_Swath_ImageData10.dat (ImageLine=700,ImagePixel=830)
Data type: unsigned 16-bit integer
Number of Dimensions: 2
Dim 1: "ImageLine" = 700
Dim 2: "ImagePixel" = 830
uint16 SWATH_TIR_Swath_ImageData11.dat (ImageLine=700,ImagePixel=830)
Data type: unsigned 16-bit integer
Number of Dimensions: 2
Dim 1: "ImageLine" = 700
Dim 2: "ImagePixel" = 830
uint16 SWATH_TIR_Swath_ImageData12.dat (ImageLine=700,ImagePixel=830)
Data type: unsigned 16-bit integer
Number of Dimensions: 2
Dim 1: "ImageLine" = 700
Dim 2: "ImagePixel" = 830
The first three files import correctly, that is to say I can import them at
all and the rest give me the following:
GRASS:~ > r.in.bin input=SWATH_TIR_Swath_ImageData11.dat r=700 c=830
output=tir11
Using N=700.000000 S=0.000000 E=830.000000 W=0.000000
Bytes do not match File size
File Size 1162321 ... Total Bytes 581000
Try bytes=2 or adjusting input parameters
GRASS:~ >
Even when I include the bytes=2 argument, I get an error. Is there something
I'm doing wrong or is the file and/or GRASS broken? Or is there a better way
to import HDF-EOS files into grass? I'm running
GRASS 5.0.3 on cygwin and r.in.hdf isn't found and I haven't had the nerve
to try to compile GRASS with gdal support although I have been able to get
GRASS to build on my machine.
Thanks,
Jeff.
---
Jeff D. Hamann
Forest Informatics, Inc.
PO Box 1421
Corvallis, Oregon USA 97339-1421
(office) 541-754-1428
(cell) 541-740-5988
jeff.hamann@forestinformatics.com
www.forestinformatics.com
From glynn.clements at virgin.net Fri Jan 16 20:43:15 2004
From: glynn.clements at virgin.net (Glynn Clements)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] Testing Grass 5.3
In-Reply-To:
References: <200401161101.i0GB11S19807@grass.itc.it>
Message-ID: <16392.37683.973560.603265@cerise.nosuchdomain.co.uk>
Michael Barton wrote:
> 2. A small annoying item with r.colors under tcltk. If you check the
> 'rules' box, nothing happens. It **should** go to a terminal screen and
> allow you to enter a set of color rules. This is what happens if you
> use r.color via the terminal command line.
Whether or not to use an xterm is set on a per-module basis; it isn't
possible to only use one when certain options are used. So, we need to
enable the use of an xterm always.
Also, the tcltkgrass interface doesn't support the use of the rast=
option.
--
Glynn Clements
From glynn.clements at virgin.net Fri Jan 16 20:51:58 2004
From: glynn.clements at virgin.net (Glynn Clements)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] cd $LOCATION revisited
In-Reply-To: <20040116163901.GD17320@thuille.itc.it>
References: <20040102173713.GA31941@thuille.itc.it>
<20040110223530.GA22856@thuille.itc.it>
<40008B00.2030900@unity.ncsu.edu>
<20040111200506.GB2601@thuille.itc.it>
<4001EDDF.6040106@unity.ncsu.edu>
<20040112082502.GD3731@thuille.itc.it>
<4007ED74.6EF6B60A@unity.ncsu.edu>
<20040116163901.GD17320@thuille.itc.it>
Message-ID: <16392.38206.542229.579961@cerise.nosuchdomain.co.uk>
Markus Neteler wrote:
> > I don't have any trick or modification - Jaro has explained it to me -
> > when you start GRASS with tcltk interface the variables get set up and
> > it works as written above.
> > If you start with -text then I get what you have described
> > as standard version. So far on the machines where I have tried it
> > it works like this without any tricks
>
> For me it's strange if, depending how GRASS was started, $LOCATION
> is set or not. Guess that this should be fixed.
That behaviour is due to the following in gis_set.tcl:
button .frame0.frameBUTTONS.ok \
-text [G_msg "Use Selection"] \
-relief raised \
-padx 10 \
-command {
if { $mapset != "" } {
CheckLocation
puts stdout "GISDBASE='$database'; export GISDBASE;"
puts stdout "LOCATION_NAME='$location'; export LOCATION_NAME;"
puts stdout "MAPSET='$mapset'; export MAPSET;"
if {[string compare $location "##ERROR##"] != 0} {
putGRASSRC $gisrc_name
}
destroy .
}
}
button .frame0.frameBUTTONS.newLoc \
-text [G_msg "Create New Location"] \
-relief raised \
-padx 10 \
-command {
puts stdout "OLD_DB='$oldDb';"
puts stdout "OLD_LOC='$oldLoc';"
puts stdout "OLD_MAP='$oldMap';"
puts stdout "GISDBASE='$database'; export GISDBASE;"
puts stdout "LOCATION_NAME='##NONE##'; export LOCATION_NAME;"
puts stdout "MAPSET=''; export MAPSET;"
set location ""
set mapset ""
putGRASSRC $gisrc_name
destroy .
}
The "export" commands shouldn't be there.
--
Glynn Clements
From hamish_nospam at yahoo.com Sat Jan 17 02:18:45 2004
From: hamish_nospam at yahoo.com (Hamish)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] d.barscale enhancement, d.scale retirement
Message-ID: <20040117201845.3adb5656.hamish_nospam@yahoo.com>
Hi,
re. the state of affairs of d.scale and d.barscale
d.scale is buggy (at= backwards; mouse placement broken, ..), while
d.barscale is pretty much the same program but with the bugs fixed and
more/better features & options (eg omit bg color, text on top).
I just added a flag to d.barscale that makes it draw a d.scale style
line-scale instead of a bar-scale, thus making d.scale redundant.
I propose we now get rid of (or disable via the module build list)
d.scale for 5.3 and rename d.barscale d.scale in the 5.7 cvs.
Can it be removed from CVS/HEAD without damaging 5.0.x?
A lingering inconsistency between various d.* modules is the at=
placement option which places an item based on percentage of monitor
width & height. d.barscale makes [0%,0%] the top left. For the modules
I've added at= to, I've been working off of what d.frame does which is
to make [0%,0%] the bottom left (I figured d.frame was one of the oldest
d.* modules and so closest to any sort of design strategy).
Can we pick one and make all the same? I think consistency between
modules is more important than consistency between major releases of
GRASS.
comments?! criticisms!?
Hamish
From blazek at itc.it Mon Jan 19 03:54:37 2004
From: blazek at itc.it (Radim Blazek)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] Testing Grass 5.3
In-Reply-To:
References:
Message-ID: <200401190854.i0J8sc526655@janacek.itc.it.>
On Friday 16 January 2004 17:13, Michael Barton wrote:
> As with GRASS 5.7, I've been doing considerable testing of GRASS 5.3.
> Overall, it is highly stable and works very well. Here are a couple of
> minor items that perhaps could be fixed before it is released as stable.
>
> 1. v.transform does not operate correctly, at least under Mac OSX. It
> requires an ASCII vector file as input, looks in the dig_ASCII folder,
> but will not recognize an ASCII vector file unless it is put (manually
> and incorrectly) into the dig folder. It produces an incomplete output
> file (header and attributes, but no vectors). This was a problem on an
> earlier release; I have tried this on the the 12 January CVS snapshot
> and it is still a problem.
v.transform was rewritten to read and write vector binary file.
Radim
From afrigeri at email.it Mon Jan 19 13:32:12 2004
From: afrigeri at email.it (Alessandro Frigeri)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] GRASS57 v.label size type
Message-ID: <20040119183212.GA11586@terra15.sct.unipg.it>
Hello,
Working in a latlon dataset I noticed that v.label's size 1 (range
1-1000) produces huge ps.map labels in small areas (since label's size is in map
units).
Changing the type from TYPE_INTEGER to TYPE_DOUBLE all works flawlessy
and I'm able to give e.g. 0.1 as label size that output correctly in
ps.map output.
Here's the cvs diff:
Index: main.c
===================================================================
RCS file: /home/grass/grassrepository/grass51/vector/v.label/main.c,v
retrieving revision 1.2
diff -r1.2 main.c
111c111
< Size->type = TYPE_INTEGER;
---
> Size->type = TYPE_DOUBLE;
113c113
< Size->options = "1-1000";
---
> /*Size->options = "1-1000";*/
Hope it helps.
Cheers
Alessandro
--
Alessandro Frigeri
echo '>ti.liame@iregirfa<' | rev
From glynn.clements at virgin.net Tue Jan 20 01:46:04 2004
From: glynn.clements at virgin.net (Glynn Clements)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] Re: [GRASSLIST:2288] Re: s.sample gets killed
In-Reply-To: <20040120130659.4fb4a62d.hamish_nospam@yahoo.com>
References: <0565B2DC17E6AA4CADAF570A0520C7060A281D@EXCHANGE03.intra.dlr.de>
<20040120130659.4fb4a62d.hamish_nospam@yahoo.com>
Message-ID: <16396.52908.512088.804915@cerise.nosuchdomain.co.uk>
Hamish wrote:
> > I need to extract raster cell values for a large number (approx. 2.5
> > million) of sites. Unfortunately s.sample gets killed after probing a
> > few thousand sites without apparent reason. No error message is given,
> > just 'killed'. Has anybody encountered the same problem and found a
> > solution or workaround?
>
> Sounds like you are running out of memory.
>
> can you run "top" to watch the memory use while s.sample runs?
> hit "M" while top is running to sort processes by memory use.
>
> Maybe it is a memory leak -- does the memory use steadily grow as the
> program runs or is it all allocated at once? How big does it get? Please
> post results so we can fix it if need be.
It's almost certainly due to a memory leak in libgis.
s.sample calls G_readsites_xyz() in a loop; G_readsites_xyz() calls
G_site_new_struct() to allocate a Site structure and
G_site_free_struct() to free it.
G_site_new_struct() allocates the dim, str_att and dbl_att arrays, and
also allocates a buffer for each entry in the str_att array.
G_site_free_struct() frees these arrays, but *doesn't* free the
buffers in the str_att array.
The attached patch fixes that; however, it should probably be tested
before being commited. AFAICT, the following programs may be affected:
d.extend d.pan d.site.labels d.site.pg d.sites d.sites.qual
d.vect.labels d.what.sites d.zoom g.region m.in.e00 p.map p.map.new
ps.map r.cost r.random r.to.sites r.volume s.delaunay s.hull
s.in.ascii s.in.dbf s.info s.in.shape s.mask s.out.ascii s.out.e00
s.perturb s.proj s.qcount s.random s.sample s.surf.idw s.surf.rst
s.territory s.to.rast s.to.vect s.vol.rst s.voronoi s.what s.windavg
v.circle v.in.tig.lndmk v.surf.rst v.to.sites v.out.moss NVIZ
--
Glynn Clements
-------------- next part --------------
--- src/libes/gis/sites.c~ Thu Sep 4 22:59:41 2003
+++ src/libes/gis/sites.c Tue Jan 20 06:40:38 2004
@@ -241,7 +241,12 @@
if(s->dim_alloc)
G_free(s->dim);
if(s->str_alloc)
+ {
+ int i;
+ for (i = 0; i < s->str_alloc; i++)
+ G_free(s->str_att[i]);
G_free(s->str_att);
+ }
if(s->dbl_alloc)
G_free(s->dbl_att);
G_free(s);
From hamish_nospam at yahoo.com Tue Jan 20 05:22:42 2004
From: hamish_nospam at yahoo.com (Hamish)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] Re: updated r.terraflow compile error
In-Reply-To: <20040119081951.GB11044@thuille.itc.it>
References: <20040117144236.GA28657@thuille.itc.it>
<20040119112544.56f258b3.hamish_nospam@yahoo.com>
<20040119081951.GB11044@thuille.itc.it>
Message-ID: <20040120232242.1084d456.hamish_nospam@yahoo.com>
> > > the updated r.terraflow causes the automated Linux compilation
> > > of 5.7 to fail:
> > >
> > [...]
> > >
> > > It is a Redhat 7 system (grass.itc.it) - on my Mandrake 9.1 box
> > > it compiles well. Do you have an idea?
> > >
> > > A quick locate tells me
> > > /usr/include/c++/3.2.2/ostream
> > >
> > > Seems that r.terraflow is no longer compliant with gcc <= 3.2.2?
Apparently so.
> > I've got a RH 7.3 computer I can test it on, and both gcc 2.96 & 3.3 on
> > my debian one. I'll see what I can figure out.
>
> Thanks. Here a locate on 'grass.itc.it'
>
> /usr/include/php/Zend/zend_istdiostream.h
> /usr/include/g++-3/iostream
> /usr/include/g++-3/iostream.h
> /usr/include/g++-3/ostream.h
^^^^^^^^^ and there's the problem.
gcc 2.96 (g++) includes both a current and backwards compatible version
of iostream (and others), but it doesn't include a current "ostream".
So there's only ostream.h on gcc 2.96, and the compile fails. I guess we
are stuck with setting it to and seeing "depreciated" messages.
fyi Debian/testing with gcc 2.96, 3.2, and 3.3 has these:
/usr/include/g++-3/iostream.h
/usr/include/g++-3/iostream
/usr/include/g++-3/ostream.h
/usr/include/c++/3.2/backward/iostream.h
/usr/include/c++/3.2/backward/ostream.h
/usr/include/c++/3.2/iostream
/usr/include/c++/3.2/ostream
/usr/include/c++/3.3/backward/iostream.h
/usr/include/c++/3.3/backward/ostream.h
/usr/include/c++/3.3/iostream
/usr/include/c++/3.3/ostream
> /usr/include/g++-3/stdiostream.h
> /usr/include/g++-2/iostream
> /usr/include/g++-2/iostream.h
> /usr/include/g++-2/ostream.h
> /usr/include/g++-2/stdiostream.h
> /usr/include/aspell/app_ostream.hh
> bash-2.04$ gcc -v
> Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
> gcc version 2.96 20000731 (Red Hat Linux 7.2 2.96-112.7.1)
>
> If it is easier, I could also upgrade the compiler on that machine
> (but what about compatibility then?).
Better to make the code work for gcc 2.96, which is pretty standard.
It'll probably break for older versions of the compiler though, what
can one do? I'd rather not have "#ifdef GCC_3.3"s everywhere..
regards,
Hamish
From flias at ecosconsult.com.br Tue Jan 20 11:48:56 2004
From: flias at ecosconsult.com.br (Flavio)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] V.SUPPORT vs V.DIGIT??
Message-ID: <200401201448.56546.flias@ecosconsult.com.br>
Hi All,
I have couple of questions about V.SUPPORT vs V.DIGIT. As we know after we
break a line, we will lose the labels around the line being brooken. However,
I have found a patch (sorry, don't know who wrote it) which solves the
problem about keeping the labels of the areas. The problem is, for instance,
if I decided to change the label of the area been divided, grass will tell me
that the area has no label (eventhough I can see the label on the map ). So
what I have to do is to quit V.DIGIT, run V.SUPPORT re-open V.DIGIT and then
use the Un-Label area function.
Problem(1): In order to solve the problem of having quit V.DIGIT and run
V.SUPPORT after a line breaking, I have added the following code line:
sprintf(buffer, _("v.support map='%s' option=build"),map);
system(buffer);
right after a line is broken. However, is not working properly (topology is
not built) eventhough I quit V.DIGIT and re-open it, I'm still unable to
change or delete label (get message "Area not labeled").
Questions
1)Why runing V.SUPPORT from inside V.DIGIT doesn't work? Is that because
V.DIGIT locks "dig_plus"?
2) Is there a way to by-pass that?
Thanks a lot
Flavio
_________________________________
Protegido - Inflex com uvscan antivirus
Linux - Sendmail
From ltoma at bowdoin.edu Tue Jan 20 15:48:14 2004
From: ltoma at bowdoin.edu (Laura Toma)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] Re: updated r.terraflow compile error
In-Reply-To: <20040120232242.1084d456.hamish_nospam@yahoo.com>
Message-ID:
There should be a variable that tells the gcc version. Anybody knows
how it's called? I could add something like
#if version < 3.2.2
#include
#else
#include
On Tuesday, January 20, 2004, at 05:22 AM, Hamish wrote:
>>>> the updated r.terraflow causes the automated Linux compilation
>>>> of 5.7 to fail:
>>>>
>>> [...]
>>>>
>>>> It is a Redhat 7 system (grass.itc.it) - on my Mandrake 9.1 box
>>>> it compiles well. Do you have an idea?
>>>>
>>>> A quick locate tells me
>>>> /usr/include/c++/3.2.2/ostream
>>>>
>>>> Seems that r.terraflow is no longer compliant with gcc <= 3.2.2?
>
> Apparently so.
>
>
>>> I've got a RH 7.3 computer I can test it on, and both gcc 2.96 & 3.3
>>> on
>>> my debian one. I'll see what I can figure out.
>>
>> Thanks. Here a locate on 'grass.itc.it'
>>
>> /usr/include/php/Zend/zend_istdiostream.h
>> /usr/include/g++-3/iostream
>> /usr/include/g++-3/iostream.h
>> /usr/include/g++-3/ostream.h
>
> ^^^^^^^^^ and there's the problem.
>
> gcc 2.96 (g++) includes both a current and backwards compatible version
> of iostream (and others), but it doesn't include a current "ostream".
>
> So there's only ostream.h on gcc 2.96, and the compile fails. I guess
> we
> are stuck with setting it to and seeing "depreciated"
> messages.
>
>
>
> fyi Debian/testing with gcc 2.96, 3.2, and 3.3 has these:
> /usr/include/g++-3/iostream.h
> /usr/include/g++-3/iostream
> /usr/include/g++-3/ostream.h
>
> /usr/include/c++/3.2/backward/iostream.h
> /usr/include/c++/3.2/backward/ostream.h
> /usr/include/c++/3.2/iostream
> /usr/include/c++/3.2/ostream
>
> /usr/include/c++/3.3/backward/iostream.h
> /usr/include/c++/3.3/backward/ostream.h
> /usr/include/c++/3.3/iostream
> /usr/include/c++/3.3/ostream
>
>
>
>> /usr/include/g++-3/stdiostream.h
>> /usr/include/g++-2/iostream
>> /usr/include/g++-2/iostream.h
>> /usr/include/g++-2/ostream.h
>> /usr/include/g++-2/stdiostream.h
>> /usr/include/aspell/app_ostream.hh
>> bash-2.04$ gcc -v
>> Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
>> gcc version 2.96 20000731 (Red Hat Linux 7.2 2.96-112.7.1)
>>
>
>
>> If it is easier, I could also upgrade the compiler on that machine
>> (but what about compatibility then?).
>
> Better to make the code work for gcc 2.96, which is pretty standard.
>
> It'll probably break for older versions of the compiler though, what
> can one do? I'd rather not have "#ifdef GCC_3.3"s everywhere..
>
>
>
> regards,
> Hamish
>
-Laura
From hamish_nospam at yahoo.com Tue Jan 20 18:00:25 2004
From: hamish_nospam at yahoo.com (Hamish)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] Re: updated r.terraflow compile error
In-Reply-To:
References: <20040120232242.1084d456.hamish_nospam@yahoo.com>
Message-ID: <20040121120025.6cdf8395.hamish_nospam@yahoo.com>
> There should be a variable that tells the gcc version. Anybody knows
> how it's called? I could add something like
> #if version < 3.2.2
> #include
> #else
> #include
Yes, but what about compiling on a something that isn't gcc?
Anyone know what Solaris/SGI/Cygwin/MacOSX has?
?,
Hamish
> >>>> the updated r.terraflow causes the automated Linux compilation
> >>>> of 5.7 to fail:
...
> >> /usr/include/g++-3/iostream
> >> /usr/include/g++-3/iostream.h
> >> /usr/include/g++-3/ostream.h
> >
> > ^^^^^^^^^ and there's the problem.
> >
> > gcc 2.96 (g++) includes both a current and backwards compatible version
> > of iostream (and others), but it doesn't include a current "ostream".
> >
> > So there's only ostream.h on gcc 2.96, and the compile fails. I guess
> > we are stuck with setting it to and seeing "depreciated"
> > messages.
From chris at fonnesbeck.org Tue Jan 20 18:09:31 2004
From: chris at fonnesbeck.org (Christopher Fonnesbeck)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] Re: updated r.terraflow compile error
In-Reply-To: <20040121120025.6cdf8395.hamish_nospam@yahoo.com>
References: <20040120232242.1084d456.hamish_nospam@yahoo.com> <20040121120025.6cdf8395.hamish_nospam@yahoo.com>
Message-ID:
On Jan 20, 2004, at 6:00 PM, Hamish wrote:
>> There should be a variable that tells the gcc version. Anybody knows
>> how it's called? I could add something like
>> #if version < 3.2.2
>> #include
>> #else
>> #include
>
>
> Yes, but what about compiling on a something that isn't gcc?
>
> Anyone know what Solaris/SGI/Cygwin/MacOSX has?
>
OSX is gcc; version 3.1 or 3.3 depending on which version of the
development tools you have installed.
Chris
--
Christopher J. Fonnesbeck ( c h r i s @ f o n n e s b e c k . o r g )
Georgia Cooperative Fish & Wildlife Research Unit, University of Georgia
From paul-grass at stjohnspoint.co.uk Tue Jan 20 18:28:16 2004
From: paul-grass at stjohnspoint.co.uk (Paul Kelly)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] Re: updated r.terraflow compile error
In-Reply-To: <20040121120025.6cdf8395.hamish_nospam@yahoo.com>
References: <20040120232242.1084d456.hamish_nospam@yahoo.com>
<20040121120025.6cdf8395.hamish_nospam@yahoo.com>
Message-ID:
On Wed, 21 Jan 2004, Hamish wrote:
> > There should be a variable that tells the gcc version. Anybody knows
> > how it's called? I could add something like
> > #if version < 3.2.2
> > #include
> > #else
> > #include
>
>
> Yes, but what about compiling on a something that isn't gcc?
>
> Anyone know what Solaris/SGI/Cygwin/MacOSX has?
>
I thought it only compiled with g++ anyway:
http://grass.itc.it/pipermail/grass5/2003-March/007342.html
From Christoph.Deuchler at dlr.de Wed Jan 21 07:28:52 2004
From: Christoph.Deuchler at dlr.de (Deuchler, Christoph)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] RE: [GRASSLIST:2288] Re: s.sample gets killed
Message-ID: <0565B2DC17E6AA4CADAF570A0520C7060A2820@EXCHANGE03.intra.dlr.de>
Hamish, Glynn,
as you predicted, the memory use grows until the swap space is full and then the program crashes.
I added the lines to sites.c and recompiled the whole thing, but unfortunately the result is the same. Instead of 'killed' I now get a 'Bus Error' message. More ideas?
Thank you for your help
Christoph
-----Original Message-----
From: Glynn Clements [mailto:glynn.clements@virgin.net]
Sent: Tue 1/20/2004 7:46 AM
To: Hamish
Cc: Deuchler, Christoph; GRASSLIST@baylor.edu; grass5@grass.itc.it
Subject: Re: [GRASSLIST:2288] Re: s.sample gets killed
Hamish wrote:
> > I need to extract raster cell values for a large number (approx. 2.5
> > million) of sites. Unfortunately s.sample gets killed after probing a
> > few thousand sites without apparent reason. No error message is given,
> > just 'killed'. Has anybody encountered the same problem and found a
> > solution or workaround?
>
> Sounds like you are running out of memory.
>
> can you run "top" to watch the memory use while s.sample runs?
> hit "M" while top is running to sort processes by memory use.
>
> Maybe it is a memory leak -- does the memory use steadily grow as the
> program runs or is it all allocated at once? How big does it get? Please
> post results so we can fix it if need be.
It's almost certainly due to a memory leak in libgis.
s.sample calls G_readsites_xyz() in a loop; G_readsites_xyz() calls
G_site_new_struct() to allocate a Site structure and
G_site_free_struct() to free it.
G_site_new_struct() allocates the dim, str_att and dbl_att arrays, and
also allocates a buffer for each entry in the str_att array.
G_site_free_struct() frees these arrays, but *doesn't* free the
buffers in the str_att array.
The attached patch fixes that; however, it should probably be tested
before being commited. AFAICT, the following programs may be affected:
d.extend d.pan d.site.labels d.site.pg d.sites d.sites.qual
d.vect.labels d.what.sites d.zoom g.region m.in.e00 p.map p.map.new
ps.map r.cost r.random r.to.sites r.volume s.delaunay s.hull
s.in.ascii s.in.dbf s.info s.in.shape s.mask s.out.ascii s.out.e00
s.perturb s.proj s.qcount s.random s.sample s.surf.idw s.surf.rst
s.territory s.to.rast s.to.vect s.vol.rst s.voronoi s.what s.windavg
v.circle v.in.tig.lndmk v.surf.rst v.to.sites v.out.moss NVIZ
--
Glynn Clements
From neteler at itc.it Wed Jan 21 09:24:34 2004
From: neteler at itc.it (Markus Neteler)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] d.barscale enhancement, d.scale retirement
In-Reply-To: <20040117201845.3adb5656.hamish_nospam@yahoo.com>
References: <20040117201845.3adb5656.hamish_nospam@yahoo.com>
Message-ID: <20040121142434.GA12748@thuille.itc.it>
On Sat, Jan 17, 2004 at 08:18:45PM +1300, Hamish wrote:
> Hi,
>
> re. the state of affairs of d.scale and d.barscale
>
>
> d.scale is buggy (at= backwards; mouse placement broken, ..), while
> d.barscale is pretty much the same program but with the bugs fixed and
> more/better features & options (eg omit bg color, text on top).
>
> I just added a flag to d.barscale that makes it draw a d.scale style
> line-scale instead of a bar-scale, thus making d.scale redundant.
>
>
> I propose we now get rid of (or disable via the module build list)
> d.scale for 5.3 and rename d.barscale d.scale in the 5.7 cvs.
>
> Can it be removed from CVS/HEAD without damaging 5.0.x?
There is one limitation which needs to be sorted out before removing d.scale:
GRASS:~ > d.barscale -mt
ERROR: d.barscale does not work with a latitude-longitude location
GRASS:~ > d.scale -m
Use mouse to select the scale location:
Any Button: select point
Look OK [y] ?
[...]
Do you see a chance to extend d.barscale to work with Lat/Long?
Markus
From ltoma at bowdoin.edu Wed Jan 21 12:51:01 2004
From: ltoma at bowdoin.edu (Laura Toma)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] RE: [GRASSLIST:2288] Re: s.sample gets killed
In-Reply-To: <0565B2DC17E6AA4CADAF570A0520C7060A2820@EXCHANGE03.intra.dlr.de>
Message-ID: <6006B8BC-4C3A-11D8-8EF5-000A95892E04@bowdoin.edu>
If it crashes because it cannot allocate more memory, then running
'unlimit' in the shell before running grass may help.
-Laura
On Wednesday, January 21, 2004, at 07:28 AM, Deuchler, Christoph wrote:
> Hamish, Glynn,
> as you predicted, the memory use grows until the swap space is full
> and then the program crashes.
> I added the lines to sites.c and recompiled the whole thing, but
> unfortunately the result is the same. Instead of 'killed' I now get a
> 'Bus Error' message. More ideas?
>
> Thank you for your help
> Christoph
>
>
>
> -----Original Message-----
> From: Glynn Clements [mailto:glynn.clements@virgin.net]
> Sent: Tue 1/20/2004 7:46 AM
> To: Hamish
> Cc: Deuchler, Christoph; GRASSLIST@baylor.edu; grass5@grass.itc.it
> Subject: Re: [GRASSLIST:2288] Re: s.sample gets killed
>
> Hamish wrote:
>
>>> I need to extract raster cell values for a large number (approx. 2.5
>>> million) of sites. Unfortunately s.sample gets killed after probing a
>>> few thousand sites without apparent reason. No error message is
>>> given,
>>> just 'killed'. Has anybody encountered the same problem and found a
>>> solution or workaround?
>>
>> Sounds like you are running out of memory.
>>
>> can you run "top" to watch the memory use while s.sample runs?
>> hit "M" while top is running to sort processes by memory use.
>>
>> Maybe it is a memory leak -- does the memory use steadily grow as the
>> program runs or is it all allocated at once? How big does it get?
>> Please
>> post results so we can fix it if need be.
>
> It's almost certainly due to a memory leak in libgis.
>
> s.sample calls G_readsites_xyz() in a loop; G_readsites_xyz() calls
> G_site_new_struct() to allocate a Site structure and
> G_site_free_struct() to free it.
>
> G_site_new_struct() allocates the dim, str_att and dbl_att arrays, and
> also allocates a buffer for each entry in the str_att array.
> G_site_free_struct() frees these arrays, but *doesn't* free the
> buffers in the str_att array.
>
> The attached patch fixes that; however, it should probably be tested
> before being commited. AFAICT, the following programs may be affected:
>
> d.extend d.pan d.site.labels d.site.pg d.sites d.sites.qual
> d.vect.labels d.what.sites d.zoom g.region m.in.e00 p.map p.map.new
> ps.map r.cost r.random r.to.sites r.volume s.delaunay s.hull
> s.in.ascii s.in.dbf s.info s.in.shape s.mask s.out.ascii s.out.e00
> s.perturb s.proj s.qcount s.random s.sample s.surf.idw s.surf.rst
> s.territory s.to.rast s.to.vect s.vol.rst s.voronoi s.what s.windavg
> v.circle v.in.tig.lndmk v.surf.rst v.to.sites v.out.moss NVIZ
>
> --
> Glynn Clements
>
>
>
>
> _______________________________________________
> grass5 mailing list
> grass5@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5
>
From jeff.hamann at forestinformatics.com Wed Jan 21 15:59:46 2004
From: jeff.hamann at forestinformatics.com (Jeff D. Hamann)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] can't start mon under WinGeneric but can under X11, again...
Message-ID: <012101c3e061$80ce7750$0a00a8c0@rodan>
I've run into this problem before, only slightly different. I
d.mon stop=x0
$
./configure --without-gd --without-odbc --without-fftw --without-postgres --
without-opengl --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
GRASS is now configured for i686-pc-cygwin
Source directory: /home/hamannj/grass/grass-5.0.3
Build directory: /home/hamannj/grass/grass-5.0.3
Installation directory: /usr/local/grass5
C compiler: gcc -g -O2
FORTRAN compiler: f77
NVIZ: no
X11 support: yes
DBM support: no
JPEG support: yes
TIFF support: yes
PNG support: yes
GD support: no
Tcl/Tk support: yes
PostgreSQL support: no
OpenGL(R) support: no
ODBC support: no
FFTW support: no
BLAS support: no
LAPACK support: no
Motif support: no
FreeType support: no
GLw support: no
NLS support: no
Readline support: no
and then make...
I then ran make install and tried to run grass 5.0.3. When I attempted to
start a graphics window, I got the following:
------------------------------------------
GRASS:~ > d.mon start=x0
No socket to connect to for monitor .
Problem selecting x0. Will try once more
No socket to connect to for monitor .
GRASS:~ >
The graphics window works when I run from an X Window session, but I would
like to only run the generic build (not the X version, since this will be
run on a Windoze XP machine and having two window managers running is a bit
unsightly, but...)
Am I configuring the build correctly?
Thanks,
Jeff.
---
Jeff D. Hamann
Forest Informatics, Inc.
PO Box 1421
Corvallis, Oregon USA 97339-1421
(office) 541-754-1428
(cell) 541-740-5988
jeff.hamann@forestinformatics.com
www.forestinformatics.com
From glynn.clements at virgin.net Wed Jan 21 21:35:53 2004
From: glynn.clements at virgin.net (Glynn Clements)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] Re: [GRASSLIST:2304] Re: s.sample gets killed
In-Reply-To: <0565B2DC17E6AA4CADAF570A0520C7060A2820@EXCHANGE03.intra.dlr.de>
References: <0565B2DC17E6AA4CADAF570A0520C7060A2820@EXCHANGE03.intra.dlr.de>
Message-ID: <16399.14089.465427.881704@cerise.nosuchdomain.co.uk>
Deuchler, Christoph wrote:
> I added the lines to sites.c and recompiled the whole thing, but
> unfortunately the result is the same. Instead of 'killed' I now get a
> 'Bus Error' message. More ideas?
Unfortunately not.
Memory exceptions (i.e. "Segmentation Fault" or "Bus Error") are
almost impossible to track down without a suitable test case (and
sending me a 2.5-million entry sites file or an equally large raster
are out of the question).
Can you reproduce the error with one of the sample data sets (e.g.
spearfish), either alone or with a small additional sites file? Or
with data which can be generated? If so, post the details and I'll try
to reproduce it.
--
Glynn Clements
From glynn.clements at virgin.net Wed Jan 21 22:38:36 2004
From: glynn.clements at virgin.net (Glynn Clements)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] can't start mon under WinGeneric but can under X11, again...
In-Reply-To: <012101c3e061$80ce7750$0a00a8c0@rodan>
References: <012101c3e061$80ce7750$0a00a8c0@rodan>
Message-ID: <16399.17852.118017.959118@cerise.nosuchdomain.co.uk>
Jeff D. Hamann wrote:
> ./configure --without-gd --without-odbc --without-fftw --without-postgres --
> without-opengl --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
> and then make...
>
>
> I then ran make install and tried to run grass 5.0.3. When I attempted to
> start a graphics window, I got the following:
>
> ------------------------------------------
> GRASS:~ > d.mon start=x0
> No socket to connect to for monitor .
> Problem selecting x0. Will try once more
> No socket to connect to for monitor .
> GRASS:~ >
>
> The graphics window works when I run from an X Window session, but I would
> like to only run the generic build (not the X version, since this will be
> run on a Windoze XP machine and having two window managers running is a bit
> unsightly, but...)
>
> Am I configuring the build correctly?
No; you need to use --enable-w11 for the "generic" version. And
there's no point specifying --x-includes or --x-libraries in that
case.
AFAICT, you can install both the X11 and W11 ("generic") versions of
XDRIVER (obviously, they can't both be called XDRIVER.exe, so one of
them has to renamed), and modify etc/monitorcap, e.g.:
x0:driver/XDRIVER:X-windows graphics display: \
dev/fifo.1a dev/fifo.1b \
::any terminal
x1:driver/XDRIVER:X-windows graphics display: \
dev/fifo.2a dev/fifo.2b \
::any terminal
[snip]
w0:driver/WINDRIVER:Windows graphics display: \
dev/fifo.1a dev/fifo.1b \
::any terminal
w1:driver/WINDRIVER:Windows graphics display: \
dev/fifo.2a dev/fifo.2b \
::any terminal
and use e.g. "d.mon start=x0" or "d.mon start=w0" depending on which
you want to use. This won't work with anything which has the x0/x1/...
monitor names hardcoded (primarily tcltkgrass, but then tcltkgrass
only works with X in any case).
--
Glynn Clements
From hamish_nospam at yahoo.com Thu Jan 22 01:29:39 2004
From: hamish_nospam at yahoo.com (Hamish)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] Re: [GRASSLIST:2304] Re: s.sample gets killed
In-Reply-To: <16399.14089.465427.881704@cerise.nosuchdomain.co.uk>
References: <0565B2DC17E6AA4CADAF570A0520C7060A2820@EXCHANGE03.intra.dlr.de>
<16399.14089.465427.881704@cerise.nosuchdomain.co.uk>
Message-ID: <20040122192939.042630df.hamish_nospam@yahoo.com>
> > I added the lines to sites.c and recompiled the whole thing, but
> > unfortunately the result is the same. Instead of 'killed' I now get
> > a'Bus Error' message. More ideas?
>
> Unfortunately not.
>
> Memory exceptions (i.e. "Segmentation Fault" or "Bus Error") are
> almost impossible to track down without a suitable test case (and
> sending me a 2.5-million entry sites file or an equally large raster
> are out of the question).
>
> Can you reproduce the error with one of the sample data sets (e.g.
> spearfish), either alone or with a small additional sites file? Or
> with data which can be generated? If so, post the details and I'll try
> to reproduce it.
use s.random, but you have to modify it to allow n to be bigger than
32k. I made "int n" into "long int n" and commented out parm.nsites->options
(Maybe worth doing properly in CVS.. 32k is pretty small)
Spearfish:
g.region rast=elevation.dted
s.random sites=random_sites n=2500000 # (122mb)
s.sample input=random_sites rast=elevation.dted > sample_sites
and watch it go..
I think 3-4gig of virtual/swap memory will make it through the 2.5M points.
Hamish
From hamish_nospam at yahoo.com Thu Jan 22 02:12:04 2004
From: hamish_nospam at yahoo.com (Hamish)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] grass 5.0.3 in debian
In-Reply-To: <20040113095421.GB4135@firewall.ba.issia.cnr.it>
References: <20040105130845.GD13455@intevation.de>
<1073311576.1020.55.camel@localhost>
<20040107145228.GG3467@thuille.itc.it>
<1073488749.1035.4.camel@localhost>
<20040112083752.GE3731@thuille.itc.it>
<20040113191350.5f454184.hamish_nospam@yahoo.com>
<20040113095421.GB4135@firewall.ba.issia.cnr.it>
Message-ID: <20040122201204.6be7d5b1.hamish_nospam@yahoo.com>
> > > the GRASS 5.0.3 package has been submitted to debian.
> >
...
> > A couple of points about the new Debian package..
[I just installed it on a fresh machine]
...
> > - add a dependency to the new gdal-bin package and build --with-gdal
> > ? This is in testing now.
> >
>
> We could consider this I think.
Upon closer inspection that package only provides the executables
(gdalinfo, ogr2ogr, etc). It would need to depend on libgdal1, build
with libgdal1-dev, and I guess suggest gdal-bin.
It builds ok using libgdal1-dev, which looks like a CVS snapshot from
November. Didn't try actually importing anything though.
> > - after changing to tcl/tk 8.4, does NVIZ still work??? could
> > someone check?
> > > Build against tcl/tk 8.4 (Closes: #206844).
> > for possible fix, see
> > http://article.gmane.org/gmane.comp.gis.grass.devel/2036/
> > ??
> > maybe fixed in the latest tcl/tk packages?
> >
>
> To be verified.
Nope, it doesn't work here.. same segfault.
Putting -lpthreads in
src.contrib/GMSL/NVIZ2.2/src/Gmakefile 's XTRA_LDFLAGS
doesn't fix it anymore either. Maybe somewhere else?
Compiling against Tcl/Tk 8.3 does work however.
regards,
Hamish
From neteler at itc.it Thu Jan 22 03:53:09 2004
From: neteler at itc.it (Markus Neteler)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] can't start mon under WinGeneric but can under X11, again...
In-Reply-To: <16399.17852.118017.959118@cerise.nosuchdomain.co.uk>
References: <012101c3e061$80ce7750$0a00a8c0@rodan> <16399.17852.118017.959118@cerise.nosuchdomain.co.uk>
Message-ID: <20040122085309.GB13239@thuille.itc.it>
On Thu, Jan 22, 2004 at 03:38:36AM +0000, Glynn Clements wrote:
>
> Jeff D. Hamann wrote:
>
> > ./configure --without-gd --without-odbc --without-fftw --without-postgres --
> > without-opengl --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
>
> > and then make...
> >
> >
> > I then ran make install and tried to run grass 5.0.3. When I attempted to
> > start a graphics window, I got the following:
> >
> > ------------------------------------------
> > GRASS:~ > d.mon start=x0
> > No socket to connect to for monitor .
> > Problem selecting x0. Will try once more
> > No socket to connect to for monitor .
> > GRASS:~ >
> >
> > The graphics window works when I run from an X Window session, but I would
> > like to only run the generic build (not the X version, since this will be
> > run on a Windoze XP machine and having two window managers running is a bit
> > unsightly, but...)
> >
> > Am I configuring the build correctly?
>
> No; you need to use --enable-w11 for the "generic" version. And
> there's no point specifying --x-includes or --x-libraries in that
> case.
>
> AFAICT, you can install both the X11 and W11 ("generic") versions of
> XDRIVER (obviously, they can't both be called XDRIVER.exe, so one of
> them has to renamed), and modify etc/monitorcap, e.g.:
>
> x0:driver/XDRIVER:X-windows graphics display: \
> dev/fifo.1a dev/fifo.1b \
> ::any terminal
> x1:driver/XDRIVER:X-windows graphics display: \
> dev/fifo.2a dev/fifo.2b \
> ::any terminal
> [snip]
> w0:driver/WINDRIVER:Windows graphics display: \
> dev/fifo.1a dev/fifo.1b \
> ::any terminal
> w1:driver/WINDRIVER:Windows graphics display: \
> dev/fifo.2a dev/fifo.2b \
> ::any terminal
>
> and use e.g. "d.mon start=x0" or "d.mon start=w0" depending on which
> you want to use. This won't work with anything which has the x0/x1/...
> monitor names hardcoded (primarily tcltkgrass, but then tcltkgrass
> only works with X in any case).
>
As far as I remember you additionally need to run
d.mon select=x0
(even of that error above occurs).
Markus
From glynn.clements at virgin.net Thu Jan 22 04:32:34 2004
From: glynn.clements at virgin.net (Glynn Clements)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] Re: [GRASSLIST:2304] Re: s.sample gets killed
In-Reply-To: <20040122192939.042630df.hamish_nospam@yahoo.com>
References: <0565B2DC17E6AA4CADAF570A0520C7060A2820@EXCHANGE03.intra.dlr.de>
<16399.14089.465427.881704@cerise.nosuchdomain.co.uk>
<20040122192939.042630df.hamish_nospam@yahoo.com>
Message-ID: <16399.39090.556571.30614@cerise.nosuchdomain.co.uk>
Hamish wrote:
> > > I added the lines to sites.c and recompiled the whole thing, but
> > > unfortunately the result is the same. Instead of 'killed' I now get
> > > a'Bus Error' message. More ideas?
> >
> > Unfortunately not.
> >
> > Memory exceptions (i.e. "Segmentation Fault" or "Bus Error") are
> > almost impossible to track down without a suitable test case (and
> > sending me a 2.5-million entry sites file or an equally large raster
> > are out of the question).
> >
> > Can you reproduce the error with one of the sample data sets (e.g.
> > spearfish), either alone or with a small additional sites file? Or
> > with data which can be generated? If so, post the details and I'll try
> > to reproduce it.
>
> use s.random, but you have to modify it to allow n to be bigger than
> 32k. I made "int n" into "long int n" and commented out parm.nsites->options
There is no point in using a long. Any platform capable of running
GRASS will have a 32-bit int, which allows for 2,147,483,647 sites.
Also, the value of the n= option is parsed using atoi(), which returns
an int; subsequently casting it to a long won't recover lost bits. If
you really need more than 32 bits, you need to use strtol() (and a
64-bit system; either that, or a platform which has "long long" and
strtoq()).
> (Maybe worth doing properly in CVS.. 32k is pretty small)
Yep.
> Spearfish:
>
> g.region rast=elevation.dted
> s.random sites=random_sites n=2500000 # (122mb)
> s.sample input=random_sites rast=elevation.dted > sample_sites
>
> and watch it go..
>
>
> I think 3-4gig of virtual/swap memory will make it through the 2.5M points.
I was asking for a test case that generates the "Bus Error" message,
so that I can track it down.
--
Glynn Clements
From glynn.clements at virgin.net Thu Jan 22 05:04:52 2004
From: glynn.clements at virgin.net (Glynn Clements)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] grass 5.0.3 in debian
In-Reply-To: <20040122201204.6be7d5b1.hamish_nospam@yahoo.com>
References: <20040105130845.GD13455@intevation.de>
<1073311576.1020.55.camel@localhost>
<20040107145228.GG3467@thuille.itc.it>
<1073488749.1035.4.camel@localhost>
<20040112083752.GE3731@thuille.itc.it>
<20040113191350.5f454184.hamish_nospam@yahoo.com>
<20040113095421.GB4135@firewall.ba.issia.cnr.it>
<20040122201204.6be7d5b1.hamish_nospam@yahoo.com>
Message-ID: <16399.41028.172818.727485@cerise.nosuchdomain.co.uk>
Hamish wrote:
> > > > the GRASS 5.0.3 package has been submitted to debian.
> > >
> ...
> > > A couple of points about the new Debian package..
>
> [I just installed it on a fresh machine]
> > > - after changing to tcl/tk 8.4, does NVIZ still work??? could
> > > someone check?
> > > > Build against tcl/tk 8.4 (Closes: #206844).
> > > for possible fix, see
> > > http://article.gmane.org/gmane.comp.gis.grass.devel/2036/
> > > ??
> > > maybe fixed in the latest tcl/tk packages?
> > >
> >
> > To be verified.
>
>
> Nope, it doesn't work here.. same segfault.
> Putting -lpthreads in
> src.contrib/GMSL/NVIZ2.2/src/Gmakefile 's XTRA_LDFLAGS
> doesn't fix it anymore either. Maybe somewhere else?
>
> Compiling against Tcl/Tk 8.3 does work however.
Do you have both 8.3 and 8.4 on the same machine? If so, are you sure
that the headers, the link-time libraries and the run-time libraries
are all the same version?
FWIW, does Debian include the version number (e.g. libtk8.3.so) or
does it use libtk.so.0?
--
Glynn Clements
From stephen.clark at focus.ca Thu Jan 22 11:29:38 2004
From: stephen.clark at focus.ca (Stephen Clark)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] HOW to for scripting GRASS to do shortest route analysis on windows 2000 + display results in Mapserver
References: <20040105130845.GD13455@intevation.de><1073311576.1020.55.camel@localhost><20040107145228.GG3467@thuille.itc.it><1073488749.1035.4.camel@localhost><20040112083752.GE3731@thuille.itc.it><20040113191350.5f454184.hamish_nospam@yahoo.com><20040113095421.GB4135@firewall.ba.issia.cnr.it><20040122201204.6be7d5b1.hamish_nospam@yahoo.com> <16399.41028.172818.727485@cerise.nosuchdomain.co.uk>
Message-ID: <004b01c3e104$f1ae0be0$6c000a0a@sclark>
Hello,
Is there anyone that has tried to script GRASS to do shortest route analysis on windows 2000 and then display the results on Mapserver version 4.0.
thanks
Stephen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/grass-dev/attachments/20040122/f0ac54e8/attachment.html
From blazek at itc.it Thu Jan 22 11:17:04 2004
From: blazek at itc.it (Radim Blazek)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] HOW to for scripting GRASS to do shortest route analysis on windows 2000 + display results in Mapserver
In-Reply-To: <004b01c3e104$f1ae0be0$6c000a0a@sclark>
References: <20040105130845.GD13455@intevation.de> <16399.41028.172818.727485@cerise.nosuchdomain.co.uk> <004b01c3e104$f1ae0be0$6c000a0a@sclark>
Message-ID: <200401221617.i0MGH4b07631@janacek.itc.it.>
On Thursday 22 January 2004 17:29, Stephen Clark wrote:
> Hello,
>
> Is there anyone that has tried to script GRASS to do shortest route
> analysis on windows 2000 and then display the results on Mapserver version
> 4.0.
Yes, i have made such system, it works, but as it is so awful that
I must write GRASS Server, which responds queries send by client
via TCP/IP. Client is PHP module, using C library. Here is a part of
PHP example code which gets shortest path and draws it on the map:
$gserver = new grass_server();
$sp = new grass_points();
$ret = grass_shortest_path_coor($gserver, "road", $x1, $y1, $x2, $y2, &$costs, &$sp);
$spLine = ms_newLineObj();
for ( $i = 0; $i < $spPoints->n; $i++ ) {
$spLine->addXY( $spPoints->x[$i], $spPoints->y[$i]);
}
$spShape = ms_newShapeObj (MS_SHAPE_LINE);
$spShape->add($spLine);
$spLayer = $map->getLayerByName('sp');
$spShape->draw($map, $spLayer, $img);
GRASS Server already works, but it is not yet on the web, because it is
not finished. Anyway, on windows, some small changes will be necessary,
because sockets are bit different on unix and windows, I think.
Client needs nothing from GRASS package, so it should be possible to use
it without Cygwin, for example GRASS Server on Linux + Mapserver
on Windows.
Radim
From jeff.hamann at forestinformatics.com Thu Jan 22 13:52:17 2004
From: jeff.hamann at forestinformatics.com (Jeff D. Hamann)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] can't start mon under WinGeneric but can under X11, again...
References: <012101c3e061$80ce7750$0a00a8c0@rodan> <16399.17852.118017.959118@cerise.nosuchdomain.co.uk>
Message-ID: <011a01c3e118$dbe5efd0$0a00a8c0@rodan>
Glynn:
Thanks for the help. I tried you're suggestions to no avail.
When I built grass503 with the following configuration:
$
./configure --without-gd --without-odbc --without-fftw --without-postgres --
without-x --without-opengl --enable-w11
Could this be a cygwin problem, and if so how could I find out?
Jeff.
----- Original Message -----
From: "Glynn Clements"
To: "Jeff D. Hamann"
Cc:
Sent: Wednesday, January 21, 2004 7:38 PM
Subject: Re: [GRASS5] can't start mon under WinGeneric but can under X11,
again...
>
> Jeff D. Hamann wrote:
>
> >
./configure --without-gd --without-odbc --without-fftw --without-postgres --
> >
without-opengl --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
>
> > and then make...
> >
> >
> > I then ran make install and tried to run grass 5.0.3. When I attempted
to
> > start a graphics window, I got the following:
> >
> > ------------------------------------------
> > GRASS:~ > d.mon start=x0
> > No socket to connect to for monitor .
> > Problem selecting x0. Will try once more
> > No socket to connect to for monitor .
> > GRASS:~ >
> >
> > The graphics window works when I run from an X Window session, but I
would
> > like to only run the generic build (not the X version, since this will
be
> > run on a Windoze XP machine and having two window managers running is a
bit
> > unsightly, but...)
> >
> > Am I configuring the build correctly?
>
> No; you need to use --enable-w11 for the "generic" version. And
> there's no point specifying --x-includes or --x-libraries in that
> case.
>
> AFAICT, you can install both the X11 and W11 ("generic") versions of
> XDRIVER (obviously, they can't both be called XDRIVER.exe, so one of
> them has to renamed), and modify etc/monitorcap, e.g.:
>
> x0:driver/XDRIVER:X-windows graphics display: \
> dev/fifo.1a dev/fifo.1b \
> ::any terminal
> x1:driver/XDRIVER:X-windows graphics display: \
> dev/fifo.2a dev/fifo.2b \
> ::any terminal
> [snip]
> w0:driver/WINDRIVER:Windows graphics display: \
> dev/fifo.1a dev/fifo.1b \
> ::any terminal
> w1:driver/WINDRIVER:Windows graphics display: \
> dev/fifo.2a dev/fifo.2b \
> ::any terminal
>
> and use e.g. "d.mon start=x0" or "d.mon start=w0" depending on which
> you want to use. This won't work with anything which has the x0/x1/...
> monitor names hardcoded (primarily tcltkgrass, but then tcltkgrass
> only works with X in any case).
>
> --
> Glynn Clements
>
From glynn.clements at virgin.net Thu Jan 22 21:25:54 2004
From: glynn.clements at virgin.net (Glynn Clements)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] can't start mon under WinGeneric but can under X11, again...
In-Reply-To: <011a01c3e118$dbe5efd0$0a00a8c0@rodan>
References: <012101c3e061$80ce7750$0a00a8c0@rodan>
<16399.17852.118017.959118@cerise.nosuchdomain.co.uk>
<011a01c3e118$dbe5efd0$0a00a8c0@rodan>
Message-ID: <16400.34354.433691.923100@cerise.nosuchdomain.co.uk>
Jeff D. Hamann wrote:
> Thanks for the help. I tried you're suggestions to no avail.
>
> When I built grass503 with the following configuration:
>
> $
> ./configure --without-gd --without-odbc --without-fftw --without-postgres --
> without-x --without-opengl --enable-w11
With what result? No errors but no window?
Did you run "make clean" before/after re-running configure?
> Could this be a cygwin problem, and if so how could I find out?
Anything which works on Linux but not on Cygwin is likely to be a
Cygwin problem in some sense.
Were there any error messages in error.log? Does driver/XDRIVER.exe
actually exist?
--
Glynn Clements
From skouk at geo.aegean.gr Fri Jan 23 09:06:14 2004
From: skouk at geo.aegean.gr (Sotiris Koukoulas)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] Expression of Interest
Message-ID: <002a01c3e1ba$1020af50$4e89fbc3@lesvos.aegean.gr>
Apologies for any cross posting
This is a call for expression of Interest...
Dear all,
We (a research project team) wish to develop a user friendly module for
site suitability analysis within GRASS or preferably in GRASS for
Windows. This module will be used by local authorities (municipalities)
for decision support. As you can understand is should be a customised
application with good GUI so the user (e.g. municipality's GIS officer)
can use it without knowledge of Grass and its commands.
We would therefore be interested in employing someone with considerable
experience in these issues (e.g. a Grass developer) in order to work on
the issue and transfer some knowledge, related to developing
applications with GRASS, to our GIS team here. We are based in Lesvos
Island in Greece. The working environment is excellent (the Campus is
located near the sea with excellent view!). We have a dynamic team in
GIS, looking forward to extent our knowledge into Open Source GIS
Software. The period of employment will be flexible, 3-6 months (this
Spring/Summer) with a possibility of extension subject to the
availability of funds.
If you are interested please send me an email with a CV outlining your
experience.
Many thanks in advance,
Sotiris Koukoulas
Dr Sotirios Koukoulas
Lecturer (GIS)
Geography Dept.
University of the Aegean
University Hill
Mytilene 81100
email: skouk@geo.aegean.gr
From michael.barton at asu.edu Fri Jan 23 11:50:33 2004
From: michael.barton at asu.edu (Michael Barton)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] problems with i.in.erdas in GRASS 5.3
Message-ID: <42F189C7-4DC4-11D8-A4C9-000A956FE2E0@asu.edu>
I just tried use i.in.erdas to read in a multiband *.lan file of
LandsatTM images. It didn't work and produced the error listed below.
With i.in.erdas out of commission, there seems to be no way to get
multiband images into GRASS. I tried r.in.gdal (I have 1.1.9 installed)
and it wouldn't read *.lan images or geotiffs in multiband format. Any
suggestions?
I am using GRASS 5.3 (12 January 04 build) on a Mac OSX 10.2.8 system.
The *.lan file is a version 7.4 format file of 7 Landsat TM bands, with
a size of 375 Mb. Note below that it does recognize the file and read
the header correctly.
- - - i.in.erdas error - - -
Swapping Enabled
HEAD74
pack type ------------- 0 == 8 bit/pixel
number bands----------- 7
number cols,rows------- 7768, 7225
starting coordinate --- 1, 1
map type (int, float) - 1
number classes -------- 0
unit-type: ------------ N (N=None A=Acre H=Hectare O=Other)
area per pixel -------- 1.000000
map coordinate -------- 67089.500000, 4414792.500000
pixel size ------------ 28.500000, 28.500000
UTM coordinates used remember that the UTM zone is unknown
and must be set using the grass support function on the header file.
WARNING: G_set_fp_type() can only be called with FCELL_TYPE or
DCELL_TYPE
WARNING: G_set_fp_type() can only be called with FCELL_TYPE or
DCELL_TYPE
WARNING: G_set_fp_type() can only be called with FCELL_TYPE or
DCELL_TYPE
WARNING: G_set_fp_type() can only be called with FCELL_TYPE or
DCELL_TYPE
WARNING: G_set_fp_type() can only be called with FCELL_TYPE or
DCELL_TYPE
WARNING: G_set_fp_type() can only be called with FCELL_TYPE or
DCELL_TYPE
WARNING: G_set_fp_type() can only be called with FCELL_TYPE or
DCELL_TYPE
____________________
C. Michael Barton, Professor
Department of Anthropology
PO Box 872402
Arizona State University
Tempe, AZ 85287-2402
USA
Phone: 480-965-6262
Fax: 480-965-7671
From sholl at gmx.net Fri Jan 23 13:40:03 2004
From: sholl at gmx.net (Stephan Holl)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] PostGIS with GRASS 5.7
Message-ID: <20040123194003.1c2bd951@kermit.wg.de>
Dear GRASS-Developers,
while thinking about using GRASS 5.7 as a 'PostGIS-data-editor' I am
facing the problem, that areas are only read as boundaries by UMN
Mapserver.
You know about that, I guess.
But are there some workarounds to display GRASS-modified PostGIS-data
correctly in UMN Mapserver?!
Another question is about the user management with roles, views etc. in
Postgres.
Is it possible to apply this user management of Postgres to the db-user
who is modifying the PostGIS database?
Any suggestion would be highly appreciated.
Thank you
Stephan Holl
--
Stephan Holl
GnuPG Key-ID: 11946A09
19:27:54 up 4:56, 1 user, load average: 0.00, 0.00, 0.00
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20040123/6b8a1d08/attachment.bin
From jeff.hamann at forestinformatics.com Fri Jan 23 15:06:57 2004
From: jeff.hamann at forestinformatics.com (Jeff D. Hamann)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] can't start mon under WinGeneric but can under X11, again...
References: <012101c3e061$80ce7750$0a00a8c0@rodan><16399.17852.118017.959118@cerise.nosuchdomain.co.uk><011a01c3e118$dbe5efd0$0a00a8c0@rodan> <16400.34354.433691.923100@cerise.nosuchdomain.co.uk>
Message-ID: <001f01c3e1ec$74aa11a0$0a00a8c0@rodan>
Sorry for the delay and ambigious message, been off on other tasks...
I built the config and got no errors, no window either, but no errors. So
deciding to cut my losses, I went ahead and started X Window and used GRASS
that way...
My error.log file contains the following lines:
GRASS GIS compilation log
-------------------------
Start of compilation: Fri Jan 23 00:38:36 PST 2004
Errors:
End of compilation: Fri Jan 23 01:21:43 PST 2004
DONE generating GRASS GIS binary code
Which is a good sign.
What I'm really trying to do are the following:
1. Import ASTER data (all the bands).
2. Import a shape file from the area, create a site file from the
centerpoints and perform an image classification
3. Hopefully generate a DEM from the 3N and 3B bands from the ASTER import.
I've run to at least a couple of problems:
1. Importing ASTER images is a pain. I've only been able to import the first
three bands (actually 4 since band three is the same band twice) using
r.in.bin. The other bands won't import even when I use settings from hdf2bin
and use the exact numbers for rows and columns for the other bands. That.. I
just don't get...
2. I've been able to import the shapefile without incident, but don't know
how to project from one speriod to another and from one datum to another.
The Shapefile is in UTM10, NAD27/83, CLARKE66? and project to ASTER's UTM10
WGS84 WGS84.
I would at least like to be able to import the ASTER files so I tried to
compile (successfully) and use (not so successfully) the gdal libraries.
When I compiled and tried to run r.in.gdal, I got the
GRASS:~ > gdalinfo ast_l1b.hdf
ERROR 4: `ast_l1b.hdf' not recognised as a supported file format.
GDALOpen failed - 4
`ast_l1b.hdf' not recognised as a supported file format.
GRASS:~ >
GRASS:~ > r.in.gdal ast_l1b.hdf output=aster
GBBridgeInitialize() failed to find an suitable GDAL .DLL/.so file.
The following filenames were searched for:
o libgdal.1.1.so
o gdal.1.0.so
o gdal.so.1.0
o libgdal.so.1
The following locations were searched:
o /usr/local/grass5/lib
o System default locations.
System default locations may be influenced by:
LD_LIBRARY_PATH = /usr/local/grass5/lib
ERROR: Unable to initialize GDAL bridge (check libgdal
installation/LD_LIBRARY_PATH variable).
GRASS:~ >
When I built the gdal libraries, it generated a libgdal.1.1.dll, but didn't
put it in /usr/local/grass5 and the list of filesnames to search in GRASS
doesn't contain a dll extension (I'm guessing it's a documentation thing in
the code though).
I'm thinking this message just covers too much turf to resolve in one
message, so I'm hoping to solve a few of these problems as suggestions are
posted for :
1) gdal importing
2) projecting
3) using generic drivers instead of X Window
Thanks for the patience,
Jeff.
----- Original Message -----
From: "Glynn Clements"
To: "Jeff D. Hamann"
Cc:
Sent: Thursday, January 22, 2004 6:25 PM
Subject: Re: [GRASS5] can't start mon under WinGeneric but can under X11,
again...
>
> Jeff D. Hamann wrote:
>
> > Thanks for the help. I tried you're suggestions to no avail.
> >
> > When I built grass503 with the following configuration:
> >
> > $
> >
./configure --without-gd --without-odbc --without-fftw --without-postgres --
> > without-x --without-opengl --enable-w11
>
> With what result? No errors but no window?
>
> Did you run "make clean" before/after re-running configure?
>
> > Could this be a cygwin problem, and if so how could I find out?
>
> Anything which works on Linux but not on Cygwin is likely to be a
> Cygwin problem in some sense.
>
> Were there any error messages in error.log? Does driver/XDRIVER.exe
> actually exist?
>
> --
> Glynn Clements
>
From paul-grass at stjohnspoint.co.uk Fri Jan 23 16:32:37 2004
From: paul-grass at stjohnspoint.co.uk (Paul Kelly)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] can't start mon under WinGeneric but can under X11,
again...
In-Reply-To: <001f01c3e1ec$74aa11a0$0a00a8c0@rodan>
References: <012101c3e061$80ce7750$0a00a8c0@rodan><16399.17852.118017.959118@cerise.nosuchdomain.co.uk><011a01c3e118$dbe5efd0$0a00a8c0@rodan>
<16400.34354.433691.923100@cerise.nosuchdomain.co.uk> <001f01c3e1ec$74aa11a0$0a00a8c0@rodan>
Message-ID:
Partial answers to the GDAL problems:
1) If you use the latest CVS version of GDAL it is much more likely to
support the HDF format you need
2) After installing GDAL, compile GRASS using the --with-gdal option. It
should then pick up the libgdal*.dll properly.
It would seem that if you don't compile GRASS using the --with-gdal
option, r.in.gdal simply will not work. --with-gdal is now the default for
both 5.3 and 5.7.
> 2. I've been able to import the shapefile without incident, but don't know
> how to project from one speriod to another and from one datum to another.
> The Shapefile is in UTM10, NAD27/83, CLARKE66? and project to ASTER's UTM10
> WGS84 WGS84.
Just set up two separate locations using g.setproj and give the correct
answers to the relevant questions. If you are using 5.0.x you should give
the datum for the ASTER images as nad83, not wgs84, otherwise the datum
transformation code won't work when you are reprojecting from
nad27/clark66 using v.proj. With 5.3+ general datum transformations are
supported and you don't need to fudge it in this way (just put in wgs84).
Paul
From glynn.clements at virgin.net Fri Jan 23 23:11:52 2004
From: glynn.clements at virgin.net (Glynn Clements)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] can't start mon under WinGeneric but can under X11,
again...
In-Reply-To:
References: <012101c3e061$80ce7750$0a00a8c0@rodan>
<16399.17852.118017.959118@cerise.nosuchdomain.co.uk>
<011a01c3e118$dbe5efd0$0a00a8c0@rodan>
<16400.34354.433691.923100@cerise.nosuchdomain.co.uk>
<001f01c3e1ec$74aa11a0$0a00a8c0@rodan>
Message-ID: <16401.61576.565409.334963@cerise.nosuchdomain.co.uk>
Paul Kelly wrote:
> Partial answers to the GDAL problems:
>
> 1) If you use the latest CVS version of GDAL it is much more likely to
> support the HDF format you need
>
> 2) After installing GDAL, compile GRASS using the --with-gdal option. It
> should then pick up the libgdal*.dll properly.
> It would seem that if you don't compile GRASS using the --with-gdal
> option, r.in.gdal simply will not work. --with-gdal is now the default for
> both 5.3 and 5.7.
I suggest that the "bridge" code is removed altogether, and the
--with-gdal switch is changed to behave like the other --with-*
switches, i.e. --without-gdal would mean "don't build r.in.gdal".
--
Glynn Clements
From glynn.clements at virgin.net Fri Jan 23 23:06:10 2004
From: glynn.clements at virgin.net (Glynn Clements)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] problems with i.in.erdas in GRASS 5.3
In-Reply-To: <42F189C7-4DC4-11D8-A4C9-000A956FE2E0@asu.edu>
References: <42F189C7-4DC4-11D8-A4C9-000A956FE2E0@asu.edu>
Message-ID: <16401.61234.901053.514115@cerise.nosuchdomain.co.uk>
Michael Barton wrote:
> I just tried use i.in.erdas to read in a multiband *.lan file of
> LandsatTM images. It didn't work and produced the error listed below.
> With i.in.erdas out of commission, there seems to be no way to get
> multiband images into GRASS. I tried r.in.gdal (I have 1.1.9 installed)
> and it wouldn't read *.lan images or geotiffs in multiband format. Any
> suggestions?
>
> I am using GRASS 5.3 (12 January 04 build) on a Mac OSX 10.2.8 system.
> The *.lan file is a version 7.4 format file of 7 Landsat TM bands, with
> a size of 375 Mb. Note below that it does recognize the file and read
> the header correctly.
>
> - - - i.in.erdas error - - -
>
> Swapping Enabled
> HEAD74
> pack type ------------- 0 == 8 bit/pixel
> number bands----------- 7
> number cols,rows------- 7768, 7225
> starting coordinate --- 1, 1
> map type (int, float) - 1
> number classes -------- 0
> unit-type: ------------ N (N=None A=Acre H=Hectare O=Other)
> area per pixel -------- 1.000000
> map coordinate -------- 67089.500000, 4414792.500000
> pixel size ------------ 28.500000, 28.500000
>
> UTM coordinates used remember that the UTM zone is unknown
> and must be set using the grass support function on the header file.
> WARNING: G_set_fp_type() can only be called with FCELL_TYPE or
> DCELL_TYPE
i.in.erdas doesn't like the map type field, and appears not to like
floating-point at all:
if(erdashd.maptyp == 0) /* integer data */
data_type = CELL_TYPE;
if(erdashd.maptyp == 99) { /* floating-point data */
data_type = FCELL_TYPE;
G_fatal_error("Floating point import doesn't work yet.");
}
As neither of these two conditions are met, data_type ends up as -1,
which isn't a valid map type.
Do you know how map type 1 differs from map type 0?
--
Glynn Clements
From tlaronde at polynum.com Sat Jan 24 09:08:14 2004
From: tlaronde at polynum.com (Thierry Laronde)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] Some news: KerGIS
Message-ID: <20040124150814.A613@polynum.org>
Hello,
Some may wonder, after the discussions held in the late november, if I
have made some vaporware announces and if actually something is done.
Short answer: YES.
Long answer follows...
0. Introduction
In the end of November 2003 I have decided that it was more easy to
start from scratch from the last CERL public release of the public
domain GRASS than to start to reorganize and fix the code in the current
GNU GRASS.
The reasons are the following:
- CERL GRASS was developped by a very small core team, focusing on
general programs and functions, and having explicit goals. That is:
this code was consistent. So it is far more easy to evolve a
consistent, "small" code, than to try to fix code gathered from
distinct sources, not having the same goals nor skills, and
developping for customed applications with no overview in mind.
- to make the code evolve, one needs an overview. The same premises
lead to the same conclusion: more easy to gain this overview with
the smallest set of consistent code.
1. State after 2 months (calendar) -- 1 month (real coding time)
My premises were correct. Indeed the code is consistent. "Old" i.e. pre
C standardization, yes ---and this is a pain by itself. But the project
conducted by Michael Shapiro and Dave Gerdes _was_ conducted, and they
have anticipated a great deal about things that were not obvious to
many by the time.
The fact that GRASS (and indeed, until very recently _this_ GRASS) is
still here is due to this far-sighted leading. It's normal that after
more than ten years, the same code is no more far-sighted... but this
can be in no way attributed to its creators, but to _us_ who have made
nothing of this stuff.
There are places ---mainly with the vector code--- where some
disorganization is found. But this is because all was under construction
or under reorganization. There are a lot of TODO, and some duplication
of code that have conducted Dave Gerdes to plan to strenghten the code
(creation of the digitizer library, reorganization of the digitizing
stuff with incorporation of LTPlus and so on).
=> I have fixed these while fixing the code and put the libraries
where they belong and created, for example, the digitizer library.
So after this time, and after fixing the things explained in details
after (in short, standard C and POSIX, fix the code ---so there
is no more warnings from the compiler--- first reorganization), _all_
the libraries of the not X code, all the programs from general, display,
fonts, vector are UP and RUNNING, fixed and compile with:
COMPILE_FLAGS = -O -fno-builtin -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror
except one (newly created file) defining the new function G_read_line
which replaces the limited and unsafe G_gets, with dynamic allocation of
memory to absorb a not limited line and handling signals, since I use a
non local goto and gcc issues a non pertinent warning [gcc is a great
tool, it's just unfortunate that one can not specify to not stop on
"may" errors].
Here is the list:
src/libes/btree
src/libes/ibtree
src/libes/linkm
src/libes/gis
src/libes/display
src/libes/dig_atts
src/libes/digit
src/libes/vector
src/libes/vask
src/libes/transform
src/libes/segment
src/libes/rowio
src/libes/raster
src/libes/lock
src/libes/imagery
src/libes/icon
src/libes/proj
src/libes/coorcnv
src/libes/bitmap
src/libes/D
src/libes/digitizer
src/libes/build
src/display/devices/lib
src/display/devices/XDRIVER
src/display/devices/monitorcap
src/fonts/for_grass
src/display/d.3d
src/display/d.ask
src/display/d.colormode
src/display/d.colors
src/display/d.colortable
src/display/d.display
src/display/d.erase
src/display/d.font
src/display/d.frame
src/display/d.geodesic
src/display/d.graph
src/display/d.grid
src/display/d.his
src/display/d.histogram
src/display/d.icons
src/display/d.label
src/display/d.labels
src/display/d.legend
src/display/d.mapgraph
src/display/d.measure
src/display/d.menu
src/display/d.mon
src/display/d.p.labels
src/display/d.points
src/display/d.profile
src/display/d.rast
src/display/d.rast.arrow
src/display/d.rast.edit
src/display/d.rast.num
src/display/d.rast.zoom
src/display/d.rgb
src/display/d.rhumbline
src/display/d.save
src/display/d.scale
src/display/d.sites
src/display/d.text
src/display/d.title
src/display/d.vect
src/display/d.what.rast
src/display/d.what.vect
src/display/d.where
src/display/d.zoom
src/general/g.access
src/general/g.ask
src/general/g.filename
src/general/g.findfile
src/general/g.gisenv
src/general/g.help
src/general/g.manual
src/general/g.mapsets
src/general/g.region
src/general/g.menu.region
src/general/g.tempfile
src/general/g.setproj
src/general/g.version
src/general/gis
src/general/manage
src/vector/v.alabel
src/vector/v.apply.census
src/vector/v.area
src/vector/v.build
src/vector/v.cadlabel
src/vector/v.clean
src/vector/v.cutter
src/vector/v.digit
src/vector/v.extract
src/vector/v.in.arc
src/vector/v.in.ascii
src/vector/v.in.dlg
src/vector/v.in.dxf
src/vector/v.in.tig
src/vector/v.in.transects
src/vector/v.mkgrid
src/vector/v.out.arc
src/vector/v.out.dxf
src/vector/v.out.moss
src/vector/v.patch
src/vector/v.proj
src/vector/v.prune
src/vector/v.spag
src/vector/v.stats
src/vector/v.support
src/vector/v.to.rast
src/vector/v.to.sites
src/vector/v.transform
2. Fixing: Goals and Method
I want the code to compile smoothly on any standard C and POSIX
platform. This is a portability goal, but a consistency one too: the
standard C prototypes are the correct way to ensure that the functions
are used the way they are designed to be [and I have actually found
programs where this was not the case!]
The implication are simple: support of TERMIOS and that's all, no
support for the deprecated and not portable setruid(3) and setrgid(3).
The method was the following.
First, since the amount of work is huge, I have started by discarding
all the code that was obsolete or useless. By principe, I have kept all
the CERL code, and review first the contrib sources. The result is that
I have discarded everything in the contrib sources ---limited use,
licence problems, poor coding--- but general programs found in
the SCS.
I have only kept devices that I plan to use: i.e. PostScript for
hardcopy, X for display.
This was the first simplification.
While fixing the code I have made further ones, deleting junks
(including a SPARC core dump file!), backup, saved,
duplicates, unused (and useless) files and kept only 1 version, the
latest one (if there are problems in the latest ones, this needs to be
fixed but it is useless to keep all the others).
If I found a program whose utility was doubtful AND poorly coded I have
saved it in my unlimited storage device: /dev/null.
Further more, I have kept only the "cmd" version, since the huge
majority of the programs already used the parser. So the files of the
program live now directly under its subdirectory and not in the
/cmd. If the "interactive" version was totally different from
the "cli" one, i have created a new program: example (sole one at the
moment) g.region, where the "interactive" version is a menu driven one
=> creation of g.menu.region.
THERE IS NO MORE MAKELINKS DANCE.
If I found _inside a file_, unused portions of code I have deleted them
if they were useless, or resurrected portions that were usefull ones.
Example: v.digit
-> There were functions handy to identify (debug) one particular
element (and I was planning to modify the code to support this)
=> resurrected
-> There was one SCS extension usefull to everybody (Snap to line)
=> resurrected
Note: the original version do the Zoom is more handy and powerful
than the present ones (can widen the window i.e. see the whole map
with the portion presently displayed and can define a new zone)
=> this "original" version of v.digit is more handy than the
present one.
In mode details
2.A Algorithms
At the present no changes are attempted in this area so no bugs are
introduced while trying to suppress the old ones.
2.C Consistency
To ease the maintainance, there must be some style and some naming
conventions: I have modified the names so that a library is identified
clearly by a conventional prefix (gis had G_, I have created DZ_ for the
digitizer libray, B_ for the build one and so on).
General functions put in userland programs have been extracted from the
programs and put back in their libraries.
A first attempt has been made to avoid circular dependices between
libraries, and for example certain functions in GISLIB using VASKLIB
have been extracted and renammed and put back in VASKLIB, the goal
being, too, to avoid the ABAB dance when linking libraries with
reciprocal dependencies.
Headers have been created and standardized too with a common naming
scheme and so on.
Libraries and headers have been gathered in the correct places i.e. in
one place.
A common style is defined (beginning) for the name of files, headers,
the use of general functions (DEBUGF) and so on.
2.O Optimizations
"Early optimizations are the root of all evil".
Since I wanted to start by fixing the old code, I have, initially,
refrained from doing optimizations.
But I have finally decided to do the obvious ones (so obvious that these
should not imply new bugs).
The main optimizations are macros replacing functions simply calling
another function (without sharing static variables not accessible from
extern), and the suppression of GIS functions simply mimicking (with
limitations...) standard C ones (G_*alloc, string manipulations
functions). [not to mention in the case of the memory allocation that
some day one will want to "improve" them by doing a custom management,
and that programs were happily mixing G_*alloc with *alloc and free...]
AFTER THE FIRST TESTS, THESE SIMPLE OPTIMIZATIONS HAVE ALREADY
LED TO SPEED IMPROVMENTS
2.S Security
G_gets has been replaced with the secure (newly created) G_read_line
But the code remains unsafe, since there are a lot of sprintf spread all
around that don't limit nor check the amount of data they put in the
buffer
=> TODO
3. Future directions
I will continue to fix the code in this order:
paint (PostScript)
raster
sites
imagery
misc
and finally xgrass.
In the mean time (since the work is mainly boring, I need to have some
more exciting coding stuff) I will start developping new applications
in the DB field (where I keep strictly nothing).
Things to be fixed:
XDRIVER: only handle 8 bits depth -> improved, with GLX support
The combination is standard C, POSIX, X, GLX and Motif for the X
interface.
The goals are always:
0. Consistency, primitives not policies
1. Portability
2. Accuracy
3. Efficiency
4. Scalability
4. The name of the game
KerGIS
5. Licence
At the moment, BSD style one. The first public release will be done when
the code is fixed and the source tree reorganized.
To be continued...
--
Thierry Laronde (Alceste)
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
From bernhard at intevation.de Sat Jan 24 12:00:06 2004
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] Some news: KerGIS
In-Reply-To: <20040124150814.A613@polynum.org>
References: <20040124150814.A613@polynum.org>
Message-ID: <20040124170006.GB28805@intevation.de>
On Sat, Jan 24, 2004 at 03:08:14PM +0100, Thierry Laronde wrote:
> Some may wonder, after the discussions held in the late november, if I
> have made some vaporware announces and if actually something is done.
>
> Short answer: YES.
Thierry,
thanks for the heads up.
You are taking an interesting more radical approach.
I'll maintain the notion that was not possible in 1999,
but the time might be right for it now.
I would tend to protect the freedom of the code better
at least chosing LGPL as a license,
but this does not seem to be set in stone
so it is mood to have a longer argument about it as this point.
I am curious how KerGIS will work out
and wish the best
as the Free Software GIS community and GRASS can only win.
Bernhard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20040124/31bb6be9/attachment.bin
From paul-grass at stjohnspoint.co.uk Sat Jan 24 12:37:57 2004
From: paul-grass at stjohnspoint.co.uk (Paul Kelly)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] Some news: KerGIS
In-Reply-To: <20040124150814.A613@polynum.org>
References: <20040124150814.A613@polynum.org>
Message-ID:
Hello Thierry
On Sat, 24 Jan 2004, Thierry Laronde wrote:
[...]
> 2.S Security
>
> G_gets has been replaced with the secure (newly created) G_read_line
>
> But the code remains unsafe, since there are a lot of sprintf spread all
> around that don't limit nor check the amount of data they put in the
> buffer
> => TODO
>
Do you have an opinion on the G_asprintf() by Eric Miller that we use in
GRASS 5.7?:
http://grass.itc.it/pipermail/grass5/2002-May/005324.html
http://freegis.org/cgi-bin/viewcvs.cgi/grass51/lib/gis/asprintf.c?rev=1.1&content-type=text/vnd.viewcvs-markup
Also did you have a chance to have a good look at g.setproj (I see you
have kept it; I wouldn't)? I always thought it seems to be quite badly
written and had been done separately from v.proj and src/libes/proj,
which apparently were done by SCS, and had been done quite well and
consistently. I think the original idea was to create PROJ_INFO /
PROJ_UNITS manually with a text editor and g.setproj (perhaps originally
called m.setproj?) was added by somebody else.
As you have obviously been looking at the old code more than I have I am
just interested if you have formed an opinion on the evolution of the proj
library.
I look forward to hearing more about KerGIS.
Paul
From grass-bugs at intevation.de Sat Jan 24 16:50:21 2004
From: grass-bugs at intevation.de (Request Tracker)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] [bug #2298] (grass) Can't get it to start
Message-ID: <20040124215021.D0BC513B88@lists.intevation.de>
this bug's URL: http://intevation.de/rt/webrt?serial_num=2298
-------------------------------------------------------------------------
Subject: Can't get it to start
Platform: other
grass obtained from: Other (CDROM etc)
grass binary for platform: Compiled from Sources
GRASS Version: 5.0
When I try to run Grass all I get is a blank x window that is titled gis_set.tcl, but there is no text or anything in the window, and when I close the x screen, in the terminal I get
ERROR: LOCATION_NAME not set
/usr/lib/grass5/etc/Init.sh: line 345:GISDATABASE:parameter null or not full
-------------------------------------------- Managed by Request Tracker
From tlaronde at polynum.com Sun Jan 25 06:57:19 2004
From: tlaronde at polynum.com (Thierry Laronde)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] Some news: KerGIS
In-Reply-To: ; from paul-grass@stjohnspoint.co.uk on Sat, Jan 24, 2004 at 05:37:57PM +0000
References: <20040124150814.A613@polynum.org>
Message-ID: <20040125125719.B624@polynum.org>
Hello Paul,
On Sat, Jan 24, 2004 at 05:37:57PM +0000, Paul Kelly wrote:
>
> > 2.S Security
> >
> > G_gets has been replaced with the secure (newly created) G_read_line
> >
> > But the code remains unsafe, since there are a lot of sprintf spread all
> > around that don't limit nor check the amount of data they put in the
> > buffer
> > => TODO
> >
>
> Do you have an opinion on the G_asprintf() by Eric Miller that we use in
> GRASS 5.7?:
>
> http://grass.itc.it/pipermail/grass5/2002-May/005324.html
>
> http://freegis.org/cgi-bin/viewcvs.cgi/grass51/lib/gis/asprintf.c?rev=1.1&content-type=text/vnd.viewcvs-markup
No, no opinion since I have absolutely not looked of what has been done
(on a more general basis, when I have fixed the code and the program
was not working as expected I have debug it my way and not try to look
at what had been done previously to correct the thing).
>
> Also did you have a chance to have a good look at g.setproj (I see you
> have kept it; I wouldn't)? I always thought it seems to be quite badly
> written and had been done separately from v.proj and src/libes/proj,
> which apparently were done by SCS, and had been done quite well and
> consistently. I think the original idea was to create PROJ_INFO /
> PROJ_UNITS manually with a text editor and g.setproj (perhaps originally
> called m.setproj?) was added by somebody else.
As I have explained, _by principle_ I have kept all the programs
distributed by CERL throwing away duplicates, junk, multiple versions,
things that are useless to support now (hardware specific display
drivers, paint drivers, print management ---will be done with the system
tools) and, for programs for which I have some doubt if I will keep them
finally or not, I have been conservative UNLESS when I tried to fix
the code (C syntactic correctness) I stumble on errors that made
clear that the coder did not understand what he was doing.
Since I don't know if g.setproj will survive (and I know that there are
programs that I have fixed whose lifetime in KerGIS will be short) but I
had the average problems to fix it, it is still here.
There is another reason for this conservative approach.
For example, with the current v.digit in GNU GRASS, I have never been
able to digitize a non connected line, which leads to the chicken and
egg problem: if a line must be connected, I do you draw the first one?
BUT the original version of v.digit doesn't suffer from this: v.digit
issues a warning that the nodes are not connected, but the line is
created.
What I mean is that to have the complete overview, and to understand
what was the big picture and how things were meant to work together, we
need to see the original bare version. Relying on "features" of the
present programs, where people have blindy modified some things that may
have broken the whole, is dangerous.
For the PROJ library, I must say that I had a rough time with it at the
beginning. Since to track, generally, the uninitialized variables one
must read the code and the code must be reasonnably readable, I have
launched indent and on that particular library it was a disaster due to
the way it is coded.
I distate heartily the coding style and particularily the way the
pre-processor is used, but I must say that, from the strict C standard
point of view, this was a library that caused very little problems.
So my conclusions are that, even if I do not like the style, the
programmer understood what he was doing (and for contributions not
originating from CERL this is an assumption that do not generally
holds...).
For g.setproj and v.proj they were both developped by the same guy from
SCS: M.L.Holko. So... we will have to wait to see the whole picture.
Cheers,
--
Thierry Laronde (Alceste)
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
From tlaronde at polynum.com Sun Jan 25 07:14:58 2004
From: tlaronde at polynum.com (Thierry Laronde)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] Some news: KerGIS
In-Reply-To: <20040124170006.GB28805@intevation.de>; from bernhard@intevation.de on Sat, Jan 24, 2004 at 06:00:06PM +0100
References: <20040124150814.A613@polynum.org> <20040124170006.GB28805@intevation.de>
Message-ID: <20040125131458.C624@polynum.org>
Hello Bernhard,
On Sat, Jan 24, 2004 at 06:00:06PM +0100, Bernhard Reiter wrote:
>
> Thierry,
>
> thanks for the heads up.
>
> You are taking an interesting more radical approach.
> I'll maintain the notion that was not possible in 1999,
> but the time might be right for it now.
>
> I would tend to protect the freedom of the code better
> at least chosing LGPL as a license,
> but this does not seem to be set in stone
> so it is mood to have a longer argument about it as this point.
>
> I am curious how KerGIS will work out
> and wish the best
> as the Free Software GIS community and GRASS can only win.
Thanks. And for the curiosity about how KerGIS will work out, and what
it will be, the short answer again is: it will be what people will
make it.
But this will not be made randomly: a consistent error is
almost a truth, since if you have consistently made the very same error,
a simple translation can make the whole becomes the truth. So, for
people who are wondering, KerGIS will be on the cathedral side, and not
on the bazaar one...
Cheers,
--
Thierry Laronde (Alceste)
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
From bernhard at intevation.de Sun Jan 25 09:27:01 2004
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] Some news: KerGIS
In-Reply-To: <20040125125719.B624@polynum.org>
References: <20040124150814.A613@polynum.org> <20040125125719.B624@polynum.org>
Message-ID: <20040125142701.GB29805@intevation.de>
On Sun, Jan 25, 2004 at 12:57:19PM +0100, Thierry Laronde wrote:
> For example, with the current v.digit in GNU GRASS,
It is missleading to call GRASS like this.
GRASS is not part of the GNU project.
It is Free Software just happens to use the GNU GPL.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20040125/abe7aac8/attachment.bin
From neteler at itc.it Sun Jan 25 10:42:23 2004
From: neteler at itc.it (Markus Neteler)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] HTMLMAP driver: d.area (old) vs. d.vect.area
Message-ID: <20040125154223.GA31708@thuille.itc.it>
Hi,
the HTMLMAP driver seems to have some problems with
d.vect.area. As d.area is deprecated, the driver seems to
need an update to work with d.vect.area.
The problem might be related to the fact that d.area
was using R_polygon_abs() while d.vect.area doesn't.
Is there anything we can do for HTMLMAP driver?
I'm not too familiar with R_*() functions.
Markus
From tlaronde at polynum.com Sun Jan 25 12:00:02 2004
From: tlaronde at polynum.com (Thierry Laronde)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] Some news: KerGIS
In-Reply-To: <20040125142701.GB29805@intevation.de>; from bernhard@intevation.de on Sun, Jan 25, 2004 at 03:27:01PM +0100
References: <20040124150814.A613@polynum.org> <20040125125719.B624@polynum.org> <20040125142701.GB29805@intevation.de>
Message-ID: <20040125180002.A1143@polynum.org>
On Sun, Jan 25, 2004 at 03:27:01PM +0100, Bernhard Reiter wrote:
> On Sun, Jan 25, 2004 at 12:57:19PM +0100, Thierry Laronde wrote:
> > For example, with the current v.digit in GNU GRASS,
>
> It is missleading to call GRASS like this.
> GRASS is not part of the GNU project.
> It is Free Software just happens to use the GNU GPL.
Correct. It was just a lapsus. I have written GNU when I thought GPL. I,
for one, should have known better...
--
Thierry Laronde (Alceste)
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
From glynn.clements at virgin.net Sun Jan 25 16:51:28 2004
From: glynn.clements at virgin.net (Glynn Clements)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] HTMLMAP driver: d.area (old) vs. d.vect.area
In-Reply-To: <20040125154223.GA31708@thuille.itc.it>
References: <20040125154223.GA31708@thuille.itc.it>
Message-ID: <16404.14944.41530.191624@cerise.nosuchdomain.co.uk>
Markus Neteler wrote:
> the HTMLMAP driver seems to have some problems with
> d.vect.area. As d.area is deprecated, the driver seems to
> need an update to work with d.vect.area.
> The problem might be related to the fact that d.area
> was using R_polygon_abs() while d.vect.area doesn't.
>
> Is there anything we can do for HTMLMAP driver?
> I'm not too familiar with R_*() functions.
The only operations which HTMLMAP actually implements are
R_polygon_abs() and R_text(); everything else is a stub.
d.vect.area uses G_plot_area(), which fills an area by drawing lots of
horizontal lines (with R_move_abs() and R_cont_abs()). The driver only
gets to "see" the individual lines.
To make HTMLMAP work with d.vect.area, it would need functionality
similar to r.poly, i.e. converting the "rasterised" polygon back to
vectors. Also, you would need to use the legend= option so that each
polygon was a different colour, so that adjacent polygons can be
distinguished.
Alternatively, I suppose that you could create a map with lots of
1-pixel-high rectangles, although that would result in rather bloated
HTML.
--
Glynn Clements
From michael.barton at asu.edu Mon Jan 26 00:42:54 2004
From: michael.barton at asu.edu (Michael Barton)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] Re: importing aster data
In-Reply-To: <200401241101.i0OB11S13372@grass.itc.it>
Message-ID: <7CFC8956-4FC2-11D8-85A2-000393B95D74@asu.edu>
On Saturday, January 24, 2004, at 04:01 AM,
grass5-request@grass.itc.it wrote:
> 1) gdal importing
> 2) projecting
> 3) using generic drivers instead of X Window
>
I'll try to answer 1 & 2.
1. If you still have trouble with ASTER importing after trying a newer
version of GDAL, a workaround is to use Hypercube or Multispec. Both
are free programs. Hypercube is from the US military; Multispec is from
the Purdue University LARS lab and NASA. They will read in the HDF
files and allow you to resave the files in other formats. This might
help.
2. The way GRASS changes map/image projections, datums, etc is to...
a) create an import location in the projection and datum of the
map/image you want to import
b) import the map/image into the location
c) create a destination location in the projection and datum you
want to reproject the map/image into
d) working in the destination location, use r.proj or v.proj
(depending on whether the map/image is raster or vector) to reproject
the map/image from the import location to the destination location.
Michael Barton
_____________________________
C. Michael Barton, Professor & Curator
Department of Anthropology
Arizona State University
Tempe, AZ 85287-2402
Phone: 480-965-6262
Fax: 480-965-7671
From hamish_nospam at yahoo.com Mon Jan 26 01:32:11 2004
From: hamish_nospam at yahoo.com (Hamish)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] Some news: KerGIS
In-Reply-To: <20040125125719.B624@polynum.org>
References: <20040124150814.A613@polynum.org>
<20040125125719.B624@polynum.org>
Message-ID: <20040126193211.549abe2e.hamish_nospam@yahoo.com>
> What I mean is that to have the complete overview, and to understand
> what was the big picture and how things were meant to work together,
> we need to see the original bare version. Relying on "features" of the
> present programs, where people have blindy modified some things that
> may have broken the whole, is dangerous.
It would be most useful to those of us who are new to working on GRASS
and whom only really understand the underlying code in a superficial
manner if someone who did understand such things could throw together a
block diagram of the different components and how they all were/are
meant to fit together. It might help to reduce future code fragmentation
and make it easier for new people contribute to KerGIS/GRASS in a useful
and correct way.
thanks,
Hamish
From glynn.clements at virgin.net Mon Jan 26 04:52:13 2004
From: glynn.clements at virgin.net (Glynn Clements)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] problems with i.in.erdas in GRASS 5.3
In-Reply-To: <16401.61234.901053.514115@cerise.nosuchdomain.co.uk>
References: <42F189C7-4DC4-11D8-A4C9-000A956FE2E0@asu.edu>
<16401.61234.901053.514115@cerise.nosuchdomain.co.uk>
Message-ID: <16404.58189.536503.676350@cerise.nosuchdomain.co.uk>
Glynn Clements wrote:
> > I just tried use i.in.erdas to read in a multiband *.lan file of
> > LandsatTM images. It didn't work and produced the error listed below.
> > With i.in.erdas out of commission, there seems to be no way to get
> > multiband images into GRASS. I tried r.in.gdal (I have 1.1.9 installed)
> > and it wouldn't read *.lan images or geotiffs in multiband format. Any
> > suggestions?
> >
> > I am using GRASS 5.3 (12 January 04 build) on a Mac OSX 10.2.8 system.
> > The *.lan file is a version 7.4 format file of 7 Landsat TM bands, with
> > a size of 375 Mb. Note below that it does recognize the file and read
> > the header correctly.
> >
> > - - - i.in.erdas error - - -
> >
> > Swapping Enabled
> > HEAD74
> > pack type ------------- 0 == 8 bit/pixel
> > number bands----------- 7
> > number cols,rows------- 7768, 7225
> > starting coordinate --- 1, 1
> > map type (int, float) - 1
> > number classes -------- 0
> > unit-type: ------------ N (N=None A=Acre H=Hectare O=Other)
> > area per pixel -------- 1.000000
> > map coordinate -------- 67089.500000, 4414792.500000
> > pixel size ------------ 28.500000, 28.500000
> >
> > UTM coordinates used remember that the UTM zone is unknown
> > and must be set using the grass support function on the header file.
> > WARNING: G_set_fp_type() can only be called with FCELL_TYPE or
> > DCELL_TYPE
>
> i.in.erdas doesn't like the map type field, and appears not to like
> floating-point at all:
>
> if(erdashd.maptyp == 0) /* integer data */
> data_type = CELL_TYPE;
> if(erdashd.maptyp == 99) { /* floating-point data */
> data_type = FCELL_TYPE;
> G_fatal_error("Floating point import doesn't work yet.");
> }
>
> As neither of these two conditions are met, data_type ends up as -1,
> which isn't a valid map type.
>
> Do you know how map type 1 differs from map type 0?
This is a bug which was introduced in:
----------------------------
revision 1.9
date: 2003/09/18 16:54:57; author: markus; state: Exp; lines: +58 -23
added potential support for floating point maps, but I don't get the pixel values decoded, so still disabled.
----------------------------
[Note 5.0.0 to 5.0.3 inclusive all use revision 1.7 of this file, so
this only applies to 5.3.]
AFAICT, the maptyp field is actually the projection type:
if ((erdashd.maptyp == 1) || (mapcoord->answer)) {
if (set_uwindow(&erdashd,firstrow,lastrow,firstcol,lastcol) <0) {
fprintf(stderr,"Error in setting GRASS window cordsn");
exit(0);
}
}
else
if (set_window(firstrow,lastrow,firstcol,lastcol) <0) {
fprintf(stderr,"Error in setting GRASS window cordsn");
exit(0);
}
[set_uwindow() is UTM, set_window() is XY.]
The code which I cited in my original reply should probably look like
this:
if(erdashd.maptyp == 99) { /* floating-point data */
data_type = FCELL_TYPE;
G_fatal_error("Floating point import doesn't work yet.");
}
data_type = CELL_TYPE;
I've committed this to CVS.
--
Glynn Clements
From blazek at itc.it Mon Jan 26 05:02:45 2004
From: blazek at itc.it (Radim Blazek)
Date: Wed Nov 14 13:44:46 2007
Subject: [GRASS5] Some news: KerGIS
In-Reply-To: <20040124150814.A613@polynum.org>
References: <20040124150814.A613@polynum.org>
Message-ID: <200401261002.i0QA2jj02030@janacek.itc.it.>
On Saturday 24 January 2004 15:08, Thierry Laronde wrote:
> In the mean time (since the work is mainly boring, I need to have some
> more exciting coding stuff) I will start developping new applications
> in the DB field (where I keep strictly nothing).
Can you concretize 'DB field'?
> 4. The name of the game
>
> KerGIS
Much better than YAG, but what does 'Ker' mean?
And from your original plans :
> 6) Scalability: YAG must be able to run on clusters
> -> All non strictly interactive tools MUST run in batch mode
> -> Client/server architecture
> -> Multithreading (not a priority, but must be thought about)
Do you think that to make the code thread save may be postponed?
Radim
From neteler at itc.it Mon Jan 26 05:19:16 2004
From: neteler at itc.it (Markus Neteler)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] problems with i.in.erdas in GRASS 5.3
In-Reply-To: <16404.58189.536503.676350@cerise.nosuchdomain.co.uk>
References: <42F189C7-4DC4-11D8-A4C9-000A956FE2E0@asu.edu> <16401.61234.901053.514115@cerise.nosuchdomain.co.uk> <16404.58189.536503.676350@cerise.nosuchdomain.co.uk>
Message-ID: <20040126101916.GF2423@thuille.itc.it>
On Mon, Jan 26, 2004 at 09:52:13AM +0000, Glynn Clements wrote:
>
> Glynn Clements wrote:
>
> > > I just tried use i.in.erdas to read in a multiband *.lan file of
> > > LandsatTM images. It didn't work and produced the error listed below.
> > > With i.in.erdas out of commission, there seems to be no way to get
> > > multiband images into GRASS. I tried r.in.gdal (I have 1.1.9 installed)
> > > and it wouldn't read *.lan images or geotiffs in multiband format. Any
> > > suggestions?
> > >
> > > I am using GRASS 5.3 (12 January 04 build) on a Mac OSX 10.2.8 system.
> > > The *.lan file is a version 7.4 format file of 7 Landsat TM bands, with
> > > a size of 375 Mb. Note below that it does recognize the file and read
> > > the header correctly.
> > >
> > > - - - i.in.erdas error - - -
> > >
> > > Swapping Enabled
> > > HEAD74
> > > pack type ------------- 0 == 8 bit/pixel
> > > number bands----------- 7
> > > number cols,rows------- 7768, 7225
> > > starting coordinate --- 1, 1
> > > map type (int, float) - 1
> > > number classes -------- 0
> > > unit-type: ------------ N (N=None A=Acre H=Hectare O=Other)
> > > area per pixel -------- 1.000000
> > > map coordinate -------- 67089.500000, 4414792.500000
> > > pixel size ------------ 28.500000, 28.500000
> > >
> > > UTM coordinates used remember that the UTM zone is unknown
> > > and must be set using the grass support function on the header file.
> > > WARNING: G_set_fp_type() can only be called with FCELL_TYPE or
> > > DCELL_TYPE
> >
> > i.in.erdas doesn't like the map type field, and appears not to like
> > floating-point at all:
> >
> > if(erdashd.maptyp == 0) /* integer data */
> > data_type = CELL_TYPE;
> > if(erdashd.maptyp == 99) { /* floating-point data */
> > data_type = FCELL_TYPE;
> > G_fatal_error("Floating point import doesn't work yet.");
> > }
> >
> > As neither of these two conditions are met, data_type ends up as -1,
> > which isn't a valid map type.
> >
> > Do you know how map type 1 differs from map type 0?
>
> This is a bug which was introduced in:
>
> ----------------------------
> revision 1.9
> date: 2003/09/18 16:54:57; author: markus; state: Exp; lines: +58 -23
> added potential support for floating point maps, but I don't get the pixel values decoded, so still disabled.
> ----------------------------
Thanks for pointing that out.
Sorry for the bug.
>
> [Note 5.0.0 to 5.0.3 inclusive all use revision 1.7 of this file, so
> this only applies to 5.3.]
>
> AFAICT, the maptyp field is actually the projection type:
>
> if ((erdashd.maptyp == 1) || (mapcoord->answer)) {
> if (set_uwindow(&erdashd,firstrow,lastrow,firstcol,lastcol) <0) {
> fprintf(stderr,"Error in setting GRASS window cordsn");
> exit(0);
> }
> }
> else
> if (set_window(firstrow,lastrow,firstcol,lastcol) <0) {
> fprintf(stderr,"Error in setting GRASS window cordsn");
> exit(0);
> }
>
> [set_uwindow() is UTM, set_window() is XY.]
I found right now some docs:
http://www2.erdas.com/SupportSite/documentation/files/erdas7xfiles.pdf
In fact maptyp is the projection (the bug was introduced by reading other,
wrong documents).
Page 10 states:
"
The first number is the projection type. Valid values are numbers 1-20,
which correspond to the supported map projection types, listed below:
Type Projection
1 UTM
2 State Plane
[...]
It's not clear to me, how floating point LANs are read (that
was the motivation for my changes).
The module i.in.erdas seems to need an overhaul.
Or simply reverted to CVS version 1.8
Markus
From hamish_nospam at yahoo.com Mon Jan 26 05:21:19 2004
From: hamish_nospam at yahoo.com (Hamish)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] d.barscale enhancement, d.scale retirement
In-Reply-To: <20040121142434.GA12748@thuille.itc.it>
References: <20040117201845.3adb5656.hamish_nospam@yahoo.com>
<20040121142434.GA12748@thuille.itc.it>
Message-ID: <20040126232119.02935e9e.hamish_nospam@yahoo.com>
> > re. the state of affairs of d.scale and d.barscale
> >
> >
> > d.scale is buggy (at= backwards; mouse placement broken, ..), while
> > d.barscale is pretty much the same program but with the bugs fixed
> > and more/better features & options (eg omit bg color, text on top).
> >
> > I just added a flag to d.barscale that makes it draw a d.scale style
> > line-scale instead of a bar-scale, thus making d.scale redundant.
> >
> >
> > I propose we now get rid of (or disable via the module build list)
> > d.scale for 5.3 and rename d.barscale d.scale in the 5.7 cvs.
> >
> > Can it be removed from CVS/HEAD without damaging 5.0.x?
>
> There is one limitation which needs to be sorted out before removing
> d.scale:
>
> GRASS:~ > d.barscale -mt
> ERROR: d.barscale does not work with a latitude-longitude location
>
> GRASS:~ > d.scale -m
>
> Use mouse to select the scale location:
> Any Button: select point
> Look OK [y] ?
>
> [...]
>
> Do you see a chance to extend d.barscale to work with Lat/Long?
d.scale lets you draw something to the screen in Lat/Long, but it's
totally wrong. d.barscale is an improvement as it won't let you try.
So I don't think there's anything worth keeping d.scale around for now.
If one were to make d.scale/barscale work in lat/lon, how would you do
it? Use 1852*60*cos(lat) to favour the x-axis as the scale bar will be
horizontal? Regardless of what you do a one-dimensional scale will be
incorrect in the other dimension, and I'd rather not get into maximum
latitude/scale rules.
Hamish
From blazek at itc.it Mon Jan 26 05:23:43 2004
From: blazek at itc.it (Radim Blazek)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] PostGIS with GRASS 5.7
In-Reply-To: <20040123194003.1c2bd951@kermit.wg.de>
References: <20040123194003.1c2bd951@kermit.wg.de>
Message-ID: <200401261023.i0QANi602110@janacek.itc.it.>
On Friday 23 January 2004 19:40, Stephan Holl wrote:
> Dear GRASS-Developers,
>
> while thinking about using GRASS 5.7 as a 'PostGIS-data-editor' I am
> facing the problem, that areas are only read as boundaries by UMN
> Mapserver.
> You know about that, I guess.
>
> But are there some workarounds to display GRASS-modified PostGIS-data
> correctly in UMN Mapserver?!
>
> Another question is about the user management with roles, views etc. in
> Postgres.
> Is it possible to apply this user management of Postgres to the db-user
> who is modifying the PostGIS database?
>
> Any suggestion would be highly appreciated.
There are too many problems with PostGIS in GRASS, I thing, that
the best would be to remove or at leas disable PostGIS and maybe
shapefile and support only OGR sources as read only with pseudotopology.
Why do you need data stored in PostGIS? It is impossible to publish
the data anybody is working on. Editing may be done in GRASS native
and once finished, you can run v.out.ogr.
Radim
From tlaronde at polynum.com Mon Jan 26 08:16:00 2004
From: tlaronde at polynum.com (Thierry Laronde)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] Some news: KerGIS
In-Reply-To: <20040126193211.549abe2e.hamish_nospam@yahoo.com>; from hamish_nospam@yahoo.com on Mon, Jan 26, 2004 at 07:32:11PM +1300
References: <20040124150814.A613@polynum.org> <20040125125719.B624@polynum.org> <20040126193211.549abe2e.hamish_nospam@yahoo.com>
Message-ID: <20040126141600.A470@polynum.org>
On Mon, Jan 26, 2004 at 07:32:11PM +1300, Hamish wrote:
> > What I mean is that to have the complete overview, and to understand
> > what was the big picture and how things were meant to work together,
> > we need to see the original bare version. Relying on "features" of the
> > present programs, where people have blindy modified some things that
> > may have broken the whole, is dangerous.
>
>
> It would be most useful to those of us who are new to working on GRASS
> and whom only really understand the underlying code in a superficial
> manner if someone who did understand such things could throw together a
> block diagram of the different components and how they all were/are
> meant to fit together. It might help to reduce future code fragmentation
> and make it easier for new people contribute to KerGIS/GRASS in a useful
> and correct way.
The documentation is part of the project, and it is one of the most
important.
BTW, I will say it once and never repeat it after: I will certainly put
things and say things rather roughly when I analyze and criticize the
way things have happened. It is in no way a criticism on the individuals
it is just the constatation that with any project, despite the quality
of the persons, if the contributions are not planned and coordonnated,
the time spent is lost.
In no way I will proclam that I'm omniscient and "error free". No: I
make errors and will continue till the end. I'm simply trying to learn,
that is to make new ones.
Cheers,
--
Thierry Laronde (Alceste)
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
From glynn.clements at virgin.net Mon Jan 26 08:19:04 2004
From: glynn.clements at virgin.net (Glynn Clements)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] d.barscale enhancement, d.scale retirement
In-Reply-To: <20040126232119.02935e9e.hamish_nospam@yahoo.com>
References: <20040117201845.3adb5656.hamish_nospam@yahoo.com>
<20040121142434.GA12748@thuille.itc.it>
<20040126232119.02935e9e.hamish_nospam@yahoo.com>
Message-ID: <16405.5064.651992.707094@cerise.nosuchdomain.co.uk>
Hamish wrote:
> > Do you see a chance to extend d.barscale to work with Lat/Long?
>
> d.scale lets you draw something to the screen in Lat/Long, but it's
> totally wrong. d.barscale is an improvement as it won't let you try.
>
> So I don't think there's anything worth keeping d.scale around for now.
>
> If one were to make d.scale/barscale work in lat/lon, how would you do
> it? Use 1852*60*cos(lat) to favour the x-axis as the scale bar will be
> horizontal? Regardless of what you do a one-dimensional scale will be
> incorrect in the other dimension, and I'd rather not get into maximum
> latitude/scale rules.
How about marking the scale in degrees?
--
Glynn Clements
From tlaronde at polynum.com Mon Jan 26 09:30:11 2004
From: tlaronde at polynum.com (Thierry Laronde)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] Some news: KerGIS
In-Reply-To: <200401261002.i0QA2jj02030@janacek.itc.it.>; from blazek@itc.it on Mon, Jan 26, 2004 at 11:02:45AM +0100
References: <20040124150814.A613@polynum.org> <200401261002.i0QA2jj02030@janacek.itc.it.>
Message-ID: <20040126153011.B470@polynum.org>
On Mon, Jan 26, 2004 at 11:02:45AM +0100, Radim Blazek wrote:
> On Saturday 24 January 2004 15:08, Thierry Laronde wrote:
> > In the mean time (since the work is mainly boring, I need to have some
> > more exciting coding stuff) I will start developping new applications
> > in the DB field (where I keep strictly nothing).
>
> Can you concretize 'DB field'?
I will simply sketch them since everything is not curved in stone at the
moment. This is also a demonstration of the need of the overview (the
big picture).
In the following when I speak about DB, it is meant in the common sense
nowadays, i.e "data handled via RDBMs". The "GIS Data Base" will be
called simply the GIS Data Repository: GDR.
I will take the example of the vector, since this is the one I use
commonly.
At the moment, the embryo of the DB is, indeed, the attributes files.
The link between geometrical data and textual one was made via the
attributes (labels), these attributes being translated to text via
categories if somebody wanted.
So the DB was a one enregistrement with one field one.
A typical use ---I think--- now, is to put labels distinct for every
element in a layer (incrementally for example) and to link this label
with a field in a DB.
Consequences and future directions:
- The attributes are doomed to disappear as well as the categories
- Since the index used tend (and it's logical) to identify uniquely
an element, the future vector format MUST support directly an
identifier, and the format must be made so that one can specify the
size of the identifers in power of two tetrabytes (I follow Knuth
terminology, tetrabyte == 4 bytes, and a byte is 8 bits), so that
the format will be able to handle tremendous amount of data [NOTE:
not all the bits in the identifiants will be used for the
identification, since for example, if the vector format will be a
topological one, the some bits in the most significant
byte will be used to code the orientation of the element].
- KerGIS/GRASS is not a vectorial package per se, so the attributes
commonly found in CADs (vectorial formats coding inside the
attributes) will not be supported. The vectorial format will support
the geometrical definitions, incorporate the topological information
now found in the dig_plus (in fact I'm thinking of a special
topological format ---but I will not say anything more for the
moment since it is not the priority), the mean of the
"support/build" operation being precisely to generate a fast
searching index between geometrical elements and textuals attributes
(in this view, if someone wants to specify particular visual aspects
(color and so on) of elements, these will be placed in a table in a
DB).
=> Geometrical operations don't have to deal with attributes (you
SELECT elements on an attribute basis XOR geometrical basis [the
combination of the two is the combination of two distinct
selections], and in the DB you need only the identifiant of the
geometrical element NOT its geometrical definition (the geometrical
extensions of some RDBMs will not be used since it's, in my mind,
both from an efficiency and a logical point of view, an original
sin).
KegGIS shall support multiple distinct DB sources for a single layer.
These sources will be specified, in an URI style
(method:location_of_table#name_of_field_holding_the_identifiants) in a
newly created file in the GDR/$LOCATION/$MAPSET.
To be able to import data from different sources, a TEXT file, with
ASCII commands (the language will be specified via a
LANG= so that we can handle languages in 7, 8 bits,
or wyde chars for the text fields) with the following characteristics:
- No loss of precision is allowed: the format will handle (since
it's text, it's easy) infinite (to the extent of the place on mass
storage devices...) precision: the 1000 digits precision allowed by
PostgreSQL will still be here;
- No loss of features is allowed: functions will be described too;
- The format must be easy to read and easy to scan.
=> The reasons for the TEXT format are:
- The import/export modules will have not n x n possibilities,
but 2n : FOO->KerGIS_DB_FORMAT, KerGIS_DB_FORMAT->BLA
-> hence the "no loss" constraints [this is not the case for
example at the moment(say pg.in.dbf, but others are touched);
- The use of CVS will be eased, since it's easier with text
format and it's more efficient (for diffs);
- allowing simple editing, debugging, text manipulations;
A corresponding binary format will be designed which will be accessed
via the common scheme (-KerGIS DB Format will simply be another type).
=> This proper format will not have to be tremendously customizable or
efficient. It will be a fallback for simple applications or people not
having other RDBMs at disposal. The "functions" will not be supported at
least at the beginning.
a $GDR/$LOCATION/$MAPSET/db directory will be created.
>
> > 4. The name of the game
> >
> > KerGIS
>
> Much better than YAG, but what does 'Ker' mean?
Ker <-> core: the essentials
Kernel GIS i.e. must allow the developpement of applications linking
directly to "system calls" from the "graphical kernel".
Ker in a "mathematical" sense meaning that for every GIS application
ker(application) = KerGIS i.e. where others have one billion different
functions this can be done with a single well designed system
call in KerGIS (the mathematical correctness of the description is not
meant to be questionned too far; it's word play).
>
> And from your original plans :
> > 6) Scalability: YAG must be able to run on clusters
> > -> All non strictly interactive tools MUST run in batch mode
> > -> Client/server architecture
> > -> Multithreading (not a priority, but must be thought about)
>
> Do you think that to make the code thread save may be postponed?
As long as the base is not orthogonal, with the different parts
(analysis, device access, presentation layer and so on) not
clearly identified and insulated, this must not be attempted.
Once the reorganization is achieved AND the big picture is gained, this
will allow too the parallelizing of efforts.
--
Thierry Laronde (Alceste)
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
From bernhard at intevation.de Mon Jan 26 10:11:44 2004
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] Some news: KerGIS
In-Reply-To: <20040126141600.A470@polynum.org>
References: <20040124150814.A613@polynum.org> <20040125125719.B624@polynum.org> <20040126193211.549abe2e.hamish_nospam@yahoo.com> <20040126141600.A470@polynum.org>
Message-ID: <20040126151144.GE20984@intevation.de>
On Mon, Jan 26, 2004 at 02:16:00PM +0100, Thierry Laronde wrote:
> BTW, I will say it once and never repeat it after: I will certainly put
> things and say things rather roughly when I analyze and criticize the
> way things have happened. It is in no way a criticism on the individuals
> it is just the constatation that with any project, despite the quality
> of the persons, if the contributions are not planned and coordonnated,
> the time spent is lost.
Honest criticising will be no problem.
But you have to be careful of tying this to the process
(and thus decisions of persons).
You are looking at a certain state of GRASS
and you have several assumptions about the process.
I don't share all of them, especially your last concertation
is something I don't share to some parts.
Somehow you probably would not try KerGRASS now
if GRASS would not have been continued the way it did in 1999.
I believe that without GPL GRASS, we would not have seen KerGIS.
It is true that you or anybody could have started KerGIS earlier,
but nobody did. Now that GPL GRASS grew green enough to show the
potential and the advantages of Free Software are more known,
a radical approach to do a new Free Software GIS is not bad.
But this is what KerGIS is, this is why you rightfully gave
it a different name.
If you make general statements that are beyond the technology,
you might provoke counter arguments.
You can say: Technical this is in a bad state know.
You cannot say: the process was wrong, this is why the state is so,
without getting into general arguments.
> In no way I will proclam that I'm omniscient and "error free". No: I
> make errors and will continue till the end. I'm simply trying to learn,
> that is to make new ones.
I'd be interested in how you judge the potential of the other
Free Software GIS approaches. PostGIS in a way also starts
to be a GIS coming from the database side of things.
Thuban trying to be an interactive geodata viewer,
also becomes more and more a GIS as people refine the mean of GIS.
This probably would be a dissussion to be held on the FreeGIS list.
Bernhard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20040126/42f022af/attachment.bin
From paul-grass at stjohnspoint.co.uk Mon Jan 26 10:52:03 2004
From: paul-grass at stjohnspoint.co.uk (Paul Kelly)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] Re: GPJ_osr_to_grass()
In-Reply-To: <20031205112301.C7253@itc.it>
References: <20031205112301.C7253@itc.it>
Message-ID:
Hello Markus
On Fri, 5 Dec 2003, Markus Neteler wrote:
> Hello Paul,
>
> if you don't mind... I would like to ask you if you
> see a chance to revisit GPJ_osr_to_grass() again?
>
> It were great to have v.in.ogr capable of generating
> locations. The updated v.in.ogr/main.c I have written
> (maybe it works) but it is lacking above function.
I have made an attempt at this and put it into the 5.7 CVS now. The new
updated g.proj will also generate locations (although it doesn't set the
region like r.in.gdal does).
It can also set up locations using EPSG codes (passed in the form of a
PROJ.4 projection description---see the description.html for g.proj for
an example). To do this it needs some GDAL CSV files so
I have placed a local copy of these in the GRASS tree. I'm not sure which
ones exactly are needed so I have put nine in. Possibly we could update
these with improved versions later.
A nice side effect of this is that if the datum is specified by the EPSG
code but there are no datum transformation parameters given, if GRASS
recognises the datum name then g.proj will interactively prompt for
parameters using those already in the GRASS datumtransform.table.
At some stage it may also be possible to use g.proj to make an improved
startup for a new location (and new user), avoiding the use of g.setproj
if a geo-referenced file is available. But that is for somebody else to do
if they want.
You will probably remember that it was the bugfix in r.in.gdal by Andrey
last week that made this possible.
Paul
From tapadmin at swbell.net Mon Jan 26 11:10:41 2004
From: tapadmin at swbell.net (Tom Parker)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] r.in.gdal
Message-ID:
Hello All,
I'm trying to resolve the r.in.gdal segmentation fault mentioned several
times on the mailing list over the past year. The problem shows itself no
matter what type of raster file I try and import.
My sytem is redhat 9 with gdal/proj/grass all built from CVS.
After installing and/or building and installing several versions of both
grass and gdal as binaries or built from source the problem isn't fixed. If
there is a simple fix I'd love to know it or I'd be happy to try and help
fix the problem.
Regards,
Tom
From paul-grass at stjohnspoint.co.uk Mon Jan 26 11:52:45 2004
From: paul-grass at stjohnspoint.co.uk (Paul Kelly)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] Some news: KerGIS
In-Reply-To: <20040125131458.C624@polynum.org>
References: <20040124150814.A613@polynum.org> <20040124170006.GB28805@intevation.de>
<20040125131458.C624@polynum.org>
Message-ID:
Hello Thierry
On Sun, 25 Jan 2004, Thierry Laronde wrote:
>
> On Sat, Jan 24, 2004 at 06:00:06PM +0100, Bernhard Reiter wrote:
> >
[...]
> > You are taking an interesting more radical approach.
> > I'll maintain the notion that was not possible in 1999,
> > but the time might be right for it now.
> >
>
> Thanks. And for the curiosity about how KerGIS will work out, and what
> it will be, the short answer again is: it will be what people will
> make it.
>
> But this will not be made randomly: a consistent error is
> almost a truth, since if you have consistently made the very same error,
> a simple translation can make the whole becomes the truth. So, for
> people who are wondering, KerGIS will be on the cathedral side, and not
> on the bazaar one...
I was interested when you mentioned the cathedral and the bazaar, and it
prompted me to read a little bit (a few pages) of this paper:
http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/
While reading it and thinking how the bazaar approach resulted in quality
software in the case of Linux I thought about the similarities between
GRASS and Linux, which Bernhard has mentioned a few times, and why the
bazaar approach has not worked for GRASS and therefore you are trying the
cathedral approach.
It seems to me that the bazaar approach only works when you have good
quality control, and for a few years after the CERL support of GRASS ended
there was inadequate quality control or central authority and bugs got in.
And it is very hard to track them apart from some comments in the source
files, since this is before the introduction of the CVS server in 1999. Of
course many more bugs have been introduced since 1999 but they have been
much easier to track and revert with CVS in use.
But to counteract the bugs that were introduced when GRASS was 'drifting'
for a few years it would indeed seem that the only logical approach is to
start with the last CERL release, i.e. what you are doing. But once you
get it organised and tidied up and make a release, then providing you are
still interested in looking after it and providing quality control over
the improvements, the bazaar approach might once again become appropriate.
So I hope it works out well and I wish you the best of luck.
Incidentally, talking about when GRASS was drifting with no clear
technical leadership reminds me of a counter to one of Bernhard's pro-GPL
arguments for GRASS: that without the GPL, people would take all of GRASS
and make it into a proprietary product and not give anything back to the
GRASS community. I take it the example of this is Blackland GRASS; is this
correct? I would argue that because there was no clear technical
leadership or strong Open Source Free software GIS lobby at the time, that
it was not even an obvious course of action for people creating a
proprietary GRASS to give back some of their developments. (Of course I
do not know what was really going on then as I was not involved; I can
just get an idea by reading the old mailing list archives.)
I argue that with the more organised state that GRASS is in now, the pressure
on such a proprietary developer to give back developments to the GRASS
community would be much higher than it was when Blacklands GRASS was
developed. Partially I base this idea on discussions I have seen on the
GDAL list (GDAL has the BSD-style licence) where developers of proprietary
software are using GDAL and feel grateful for it and are putting pressure
on their bosses to release part of their product as Open Source.
Just thought I'd mention this as I haven't seen it discussed before. BTW
I'm not sure what the best licence for GRASS is and don't have a strong
opinion as long as it is some kind of open source that researchers can
play around with.
Paul
From bernhard at intevation.de Mon Jan 26 11:55:36 2004
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] r.in.gdal
In-Reply-To:
References:
Message-ID: <20040126165536.GB32650@intevation.de>
On Mon, Jan 26, 2004 at 10:10:41AM -0600, Tom Parker wrote:
> I'm trying to resolve the r.in.gdal segmentation fault mentioned several
> times on the mailing list over the past year. The problem shows itself no
> matter what type of raster file I try and import.
>
> My sytem is redhat 9 with gdal/proj/grass all built from CVS.
>
> After installing and/or building and installing several versions of both
> grass and gdal as binaries or built from source the problem isn't fixed. If
> there is a simple fix I'd love to know it or I'd be happy to try and help
> fix the problem.
Can you build with debugging support and try
to see what the traceback says?
Check: http://grass.itc.it/grassdevel.html
for links to the "debugging" hints
Are there any versions you didn't build yourself?
Bernhard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20040126/7897cdf7/attachment.bin
From neteler at itc.it Mon Jan 26 11:58:29 2004
From: neteler at itc.it (Markus Neteler)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] r.in.gdal
In-Reply-To: <20040126165536.GB32650@intevation.de>
References: <20040126165536.GB32650@intevation.de>
Message-ID: <20040126165829.GA23171@thuille.itc.it>
On Mon, Jan 26, 2004 at 05:55:36PM +0100, Bernhard Reiter wrote:
> On Mon, Jan 26, 2004 at 10:10:41AM -0600, Tom Parker wrote:
> > I'm trying to resolve the r.in.gdal segmentation fault mentioned several
> > times on the mailing list over the past year. The problem shows itself no
> > matter what type of raster file I try and import.
> >
> > My sytem is redhat 9 with gdal/proj/grass all built from CVS.
> >
> > After installing and/or building and installing several versions of both
> > grass and gdal as binaries or built from source the problem isn't fixed. If
> > there is a simple fix I'd love to know it or I'd be happy to try and help
> > fix the problem.
>
> Can you build with debugging support and try
> to see what the traceback says?
>
> Check: http://grass.itc.it/grassdevel.html
> for links to the "debugging" hints
>
> Are there any versions you didn't build yourself?
> Bernhard
An important bug was fixed Jan 23 (5.3-CVS), do you use that version?
Markus
From tlaronde at polynum.com Mon Jan 26 12:50:23 2004
From: tlaronde at polynum.com (Thierry Laronde)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] Some news: KerGIS
In-Reply-To: <20040126151144.GE20984@intevation.de>; from bernhard@intevation.de on Mon, Jan 26, 2004 at 04:11:44PM +0100
References: <20040124150814.A613@polynum.org> <20040125125719.B624@polynum.org> <20040126193211.549abe2e.hamish_nospam@yahoo.com> <20040126141600.A470@polynum.org> <20040126151144.GE20984@intevation.de>
Message-ID: <20040126185023.A909@polynum.org>
On Mon, Jan 26, 2004 at 04:11:44PM +0100, Bernhard Reiter wrote:
> On Mon, Jan 26, 2004 at 02:16:00PM +0100, Thierry Laronde wrote:
>
> > BTW, I will say it once and never repeat it after: I will certainly put
> > things and say things rather roughly when I analyze and criticize the
> > way things have happened. It is in no way a criticism on the individuals
> > it is just the constatation that with any project, despite the quality
> > of the persons, if the contributions are not planned and coordonnated,
> > the time spent is lost.
>
> Honest criticising will be no problem.
> But you have to be careful of tying this to the process
> (and thus decisions of persons).
To explain more:
1) If GPL GRASS had not existed, resurrected by Markus Neteler almost
alone some years ago, Public Domain GRASS would have been lost, and I,
as others, would never have the opportunity to derive something from it;
2) If I have not seen something working by working with GPL GRASS, I
will have not attempted what I'm doing.
=> So the work done is not lost on this basis but must be capitalized to
learn how to make things work better.
The "errors" made on the process are the errors that, to some extents,
_we_ ---in the libre software world--- all have made: to believe that
opening the sources will attract more developers and that people using
them will spontaneously try to contribute.
=> That's wrong. The english term "free" has the desastrous meaning
"gratis" when working on libre software have never been gratis for the
developers.
Now a libre software must work on the assumption that it will be not
given "gratis": the user that don't contribute code will contribute time
spent _for his own sake_ to learn how to use the software, and the only
users will have dedicated lists where they will be able to exchange and
help themselves [a reasonnably clear documentation shall be provided for
the beginners; it is in no way a design goal to have ununderstandable
documentation just to throw users away]. If they don't want to help
themselves and to work a little for their own sake, they can:
-stop using the software: it is in no way an obligation...
-pay someone for doing what they do not want to do: laziness is a
sin and the punition has to come...
Libre software is a school of energy, will and skills. Before libre
software, even if you had the will and the skills, if you do not have
the money you were blocked. Now, if you have the skills and the will
everything is at your reach. And if you have the will, you can gain
the skills by learning, and participating to such a huge project as
KerGIS/GRASS is highly beneficial [I have learned a lot simply by
fixing the code].
The second error is trying to be "kind" with contributions, that is to
think that accepting badly thought pieces of code will allow to keep
wanabees contributors and that being too direct will disgust people at
first attempt.
That's wrong. For the sake of everybody, the goal must be an improvement
of the quality of the code. A non optimal contribution is a lost, and a
non contribution is a status quo. In this case non contribution is
better since it is a gain compared to the loss.
The management has nothing to do with insults, sarcasms and so on (being
noted that it is sometimes difficult for non english native speakers to
translate accurately what they thought in the pseudo-english that we
use). I have heard remarks on my code sometimes, and I was not angry
against the one who criticized (if he were right) but against myself: I
was upset because of my "amour-propre". This has simply led me to show
that I could do better than that...
So, we have made errors. That's not unforgivable if we do not continue.
If we continue these will be faults.
>
> > In no way I will proclam that I'm omniscient and "error free". No: I
> > make errors and will continue till the end. I'm simply trying to learn,
> > that is to make new ones.
>
> I'd be interested in how you judge the potential of the other
> Free Software GIS approaches.
By intuition and by experiment, I do not believe this is the correct
way. At least, this is a way I do not want to follow.
There are enough people who already make the very same things. Let the
evolving GRASS still be what it is: a topological GIS. Do not make the
same errors as other, make our own ;)
--
Thierry Laronde (Alceste)
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
From tapadmin at swbell.net Mon Jan 26 12:43:14 2004
From: tapadmin at swbell.net (Tom Parker)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] r.in.gdal
In-Reply-To: <20040126165829.GA23171@thuille.itc.it>
Message-ID:
I did try installing various precompiled binaries as well as building from
source. If the update from 5.3 does not help I will follow up with the
debugging build.
Thanks,
Tom
-----Original Message-----
From: grass5-admin@grass.itc.it [mailto:grass5-admin@grass.itc.it]On
Behalf Of Markus Neteler
Sent: Monday, January 26, 2004 10:58 AM
To: grass-dev
Subject: Re: [GRASS5] r.in.gdal
On Mon, Jan 26, 2004 at 05:55:36PM +0100, Bernhard Reiter wrote:
> On Mon, Jan 26, 2004 at 10:10:41AM -0600, Tom Parker wrote:
> > I'm trying to resolve the r.in.gdal segmentation fault mentioned several
> > times on the mailing list over the past year. The problem shows itself
no
> > matter what type of raster file I try and import.
> >
> > My sytem is redhat 9 with gdal/proj/grass all built from CVS.
> >
> > After installing and/or building and installing several versions of both
> > grass and gdal as binaries or built from source the problem isn't fixed.
If
> > there is a simple fix I'd love to know it or I'd be happy to try and
help
> > fix the problem.
>
> Can you build with debugging support and try
> to see what the traceback says?
>
> Check: http://grass.itc.it/grassdevel.html
> for links to the "debugging" hints
>
> Are there any versions you didn't build yourself?
> Bernhard
An important bug was fixed Jan 23 (5.3-CVS), do you use that version?
Markus
_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5
From JGillette at rfmd.com Mon Jan 26 12:55:07 2004
From: JGillette at rfmd.com (John Gillette)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] r.in.gdal
Message-ID: <8EC17EE03C13464E8049ADA41C53EB9E759722@mail3>
Don't forget also the optimization trick, if you haven't
tried it already.
CFLAGS=-g ./configure ...
configure grass as normal and then re-compile r.in.gdal.
(I would assume you can rebuild only r.in.gdal with
gmake.)
This has fixed at least 2 other user's r.in.gdal (maybe),
one of whom was running Redhat 8.0.
My theory is that for Redhat >7, optimization is breaking
r.in.gdal.
Please let us know if you have tried this already or if it works.
John
> -----Original Message-----
> From: Bernhard Reiter [mailto:bernhard@intevation.de]
> Sent: Monday, January 26, 2004 11:56 AM
> To: grass-dev
> Subject: Re: [GRASS5] r.in.gdal
>
>
> On Mon, Jan 26, 2004 at 10:10:41AM -0600, Tom Parker wrote:
> > I'm trying to resolve the r.in.gdal segmentation fault
> mentioned several
> > times on the mailing list over the past year. The problem
> shows itself no
> > matter what type of raster file I try and import.
> >
> > My sytem is redhat 9 with gdal/proj/grass all built from CVS.
> >
> > After installing and/or building and installing several
> versions of both
> > grass and gdal as binaries or built from source the problem
> isn't fixed. If
> > there is a simple fix I'd love to know it or I'd be happy
> to try and help
> > fix the problem.
>
> Can you build with debugging support and try
> to see what the traceback says?
>
> Check: http://grass.itc.it/grassdevel.html
> for links to the "debugging" hints
>
> Are there any versions you didn't build yourself?
> Bernhard
>
From tlaronde at polynum.com Mon Jan 26 14:04:46 2004
From: tlaronde at polynum.com (Thierry Laronde)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] Some news: KerGIS
In-Reply-To: ; from paul-grass@stjohnspoint.co.uk on Mon, Jan 26, 2004 at 04:52:45PM +0000
References: <20040124150814.A613@polynum.org> <20040124170006.GB28805@intevation.de> <20040125131458.C624@polynum.org>
Message-ID: <20040126200446.B909@polynum.org>
Hello Paul,
On Mon, Jan 26, 2004 at 04:52:45PM +0000, Paul Kelly wrote:
> I was interested when you mentioned the cathedral and the bazaar, and it
> prompted me to read a little bit (a few pages) of this paper:
> http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/
> While reading it and thinking how the bazaar approach resulted in quality
> software in the case of Linux I thought about the similarities between
> GRASS and Linux, which Bernhard has mentioned a few times, and why the
> bazaar approach has not worked for GRASS and therefore you are trying the
> cathedral approach.
The problem with Eric S. Raymond's paper is that this plea for the
bazaar is based on a word play. The bazaar is not on the management side
it's the opportunity to accept improvements or new ideas coming from
a "non-authoritative" source.
The main driving force that _can_ be behind libre software is the
interconnection, that is the possibility to gather energies and skills
spread all around the earth and to combine good ideas that will be lost
in an classical university/enterprise environment where there are the
ones who have the right to speak and the other ones who have the right
to listen. But this is not a random incorporation: the sources are
random (good skills or ideas can come from a non expected side), but the
process is not.
This means too that the Internet is the definitive back-bone of the
libre software and that we must be very carefull with the laws being
made at the moment.
And note that if there is a bazaar this is a "bazaar of cathedrals".
When the sources were closed, it was impossible to anybody to start a
big project, since it meant start from scratch. With open sources, you
can with a reasonable amount of work construct your own cathedral if you
don't agree with the directions taken by others (the fork processes).
All the succesfull leading project are cathedrals (strictly driven ones)
: FSF is not a bazaar (it's very difficult to enter by the way), Linux
was not a bazaar (Linus Torvalds have endured a huge amount of
criticisms due to his refusals to incorporate some functionnalities),
4.4BSD Lite2 was not a bazaar (cf the Release Engineering paragraphs in
"The Design and Implementation of the 4.4BSD Operating System" by
McKusick, Bostic, Karels, Quarterman ---Addison-Wesley :
The CSRG [Computer System Research Group at the University of
California at Berkeley] was always a small group of software
developers. This resource limitation required careful
software-engineering management. Careful coordination was needed not
only of the CSRG personnel, but also of members of the general
community who contributed to the development of the system.[...]
[...]
This process illustrates an _advantage_ of having only a few
principal developers: The developers all knew the whole system
thoroughly enough to be able to coordinate their own work with that
of other people to produce a coherent final system. Companies with
large development organizations find this result difficult to
duplicate.
).
>[..]
> I argue that with the more organised state that GRASS is in now, the pressure
> on such a proprietary developer to give back developments to the GRASS
> community would be much higher than it was when Blacklands GRASS was
> developed. Partially I base this idea on discussions I have seen on the
> GDAL list (GDAL has the BSD-style licence) where developers of proprietary
> software are using GDAL and feel grateful for it and are putting pressure
> on their bosses to release part of their product as Open Source.
>
> Just thought I'd mention this as I haven't seen it discussed before. BTW
> I'm not sure what the best licence for GRASS is and don't have a strong
> opinion as long as it is some kind of open source that researchers can
> play around with.
I have the sentiment that to prevent a not fair use of libre software
the following is mandatory:
- Obligation of advertisement: one can not hide that one uses software
he has not developed -> this advertises the sources hence the project;
this moderates the prices [if one wants to make money he has to
justify about an added value] and this gives too an incitative to
work as a core developer [if you claim to be a good developer whose
work is derived from this one, it could be strange that you do not
contribute to the main project...]
- Allow to make money with it [and for this you must have the
opportunity to not give away the code you have developed]
- BUT the strict interdiction to put patents on derived work (I'm
fanatic about that). And this can be achieved (I have discussed about
this with RMS some times ago and he didn't think there was a easy way to
do it) with this kind of disposition I have found in a crypto software,
that is saying that if anybody derived a work from this library and put
patents on the derived work, ipso facto and immediately the provider of
the library will gain the patents for its own use.
As long as the software doesn't focus on the USER INTERFACE, where most
of the added value can be done, this will allow individuals,
universities and enterprises to contribute to the core while protecting
their business interests if any.
--
Thierry Laronde (Alceste)
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
From tapadmin at swbell.net Mon Jan 26 14:11:11 2004
From: tapadmin at swbell.net (Tom Parker)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] r.in.gdal
In-Reply-To: <8EC17EE03C13464E8049ADA41C53EB9E759722@mail3>
Message-ID:
I tried the 5.3 update with no luck, I'm going to switch to an older gdal
not the latest from cvs and see if that helps the 5.3 r.in.gdal patch.
-----Original Message-----
From: John Gillette [mailto:JGillette@rfmd.com]
Sent: Monday, January 26, 2004 11:55 AM
To: grass-dev; Tom Parker
Subject: RE: [GRASS5] r.in.gdal
Don't forget also the optimization trick, if you haven't
tried it already.
CFLAGS=-g ./configure ...
configure grass as normal and then re-compile r.in.gdal.
(I would assume you can rebuild only r.in.gdal with
gmake.)
This has fixed at least 2 other user's r.in.gdal (maybe),
one of whom was running Redhat 8.0.
My theory is that for Redhat >7, optimization is breaking
r.in.gdal.
Please let us know if you have tried this already or if it works.
John
> -----Original Message-----
> From: Bernhard Reiter [mailto:bernhard@intevation.de]
> Sent: Monday, January 26, 2004 11:56 AM
> To: grass-dev
> Subject: Re: [GRASS5] r.in.gdal
>
>
> On Mon, Jan 26, 2004 at 10:10:41AM -0600, Tom Parker wrote:
> > I'm trying to resolve the r.in.gdal segmentation fault
> mentioned several
> > times on the mailing list over the past year. The problem
> shows itself no
> > matter what type of raster file I try and import.
> >
> > My sytem is redhat 9 with gdal/proj/grass all built from CVS.
> >
> > After installing and/or building and installing several
> versions of both
> > grass and gdal as binaries or built from source the problem
> isn't fixed. If
> > there is a simple fix I'd love to know it or I'd be happy
> to try and help
> > fix the problem.
>
> Can you build with debugging support and try
> to see what the traceback says?
>
> Check: http://grass.itc.it/grassdevel.html
> for links to the "debugging" hints
>
> Are there any versions you didn't build yourself?
> Bernhard
>
From jeff.hamann at forestinformatics.com Mon Jan 26 15:00:39 2004
From: jeff.hamann at forestinformatics.com (Jeff D. Hamann)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] Re: KerGIS
Message-ID: <00a901c3e447$15c5a070$0a00a8c0@rodan>
I've been reading the current news on KerGIS this morning and I'm glad to
see the initiative regarding quality control and the addtional resources to
the underdeveloped and overworked GRASS developement pool. I've been wanting
to utilize GRASS (as well as contribute) for a couple of years now and (and
I'm not trying to gripe too much here and I'm not criticizing) it seems that
the goals are constantly shifting as well as feature creep regarding the
architecture. With all the development that has gone on in the last couple
of years, GRASS still cannot handle some of the most basic of vector and
database operations to satisfaction in a production environment. I think
GRASS can be an awsome GIS tool (and in lots of respects it *is* -- raster
and satellite processing mostly).
I read the news regarding KerGIS with great enthusiasm as I've wished for
such an event to happen for a couple of years. I think it just what the
doctor ordered for the code. No more gmake5, etc. Fixing and simplify and
remove optimizations! Yes, yes, yes... I've been thinking about doing this
for a couple fo years now, but since I've got to continue to produce and
can't spend the time to do anything other create small supporting packages,
I've not had the chance. As it stands now, I'm not sure where to contribute.
There are *at least* three code streams for GRASS (5.0, 5.3 and 5.7 -- not
to mention 4.3) This seems to be the opposite of fix and simplify. And none
of them seem to include the capabilites I need. In order for 5.7 to work, I
need the code for 5.3. Why? Shouldn't all that new code simply go into 5.3?
If I could get everthing to compile on my BSD platform, I would use it
there. If I could get everything to compile on cygwin, I'd use it there. But
they don't. There's just too many switches and options for a simple (for
example)
./configure
make --with-mysql
make install
to work (at least for the 5.0.3 source code). For the 5.7 source code, you
need 5.3 source code and the cygwin "weekly" binaries for 5.7 aren't availab
le. I've not seen a project with so much connection between code streams.
Why?
Almost all of my work is with vectors and the attributes, lots of attributes
of polygons (adjacency lists, unions, intersects, area calculations, and
attributes -- think FRAGSTATS woulodn't it be nice to have a version for
GRASS for people to build on). For my projects, I'm constantly moving files
between GRASS and Arc/Info and ArcView for projecting files across all sorts
of projections, datums and coordinate systems and I have yet to be able to
accomplish this in GRASS simply because I can't gdal/GRASS to work resulting
from some sort of goofy circular dependencies). My Database is MySQL and my
stats package is R (which seems to have be best model for development I've
seen so far). These are two great packages and the development process is
solid almost militant in nature. MySQL releases a couple of times per year
as does R and it seems GRASS has been limping along in the meantime. We need
help. Isn't there an institution that promotes the development of GRASS
where people can work on it full time? It seems that the overworked
developers are spread pretty thin and the project needs a small army of
people pushing on.
Okay, this seems a bit long winded so I'll shup now. And thanks for hearing
my pleas.
Thanks for the good work,
Jeff.
---
Jeff D. Hamann
Forest Informatics, Inc.
PO Box 1421
Corvallis, Oregon USA 97339-1421
(office) 541-754-1428
(cell) 541-740-5988
jeff.hamann@forestinformatics.com
www.forestinformatics.com
From neteler at itc.it Mon Jan 26 16:45:44 2004
From: neteler at itc.it (Markus Neteler)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] Re: KerGIS
In-Reply-To: <00a901c3e447$15c5a070$0a00a8c0@rodan>
References: <00a901c3e447$15c5a070$0a00a8c0@rodan>
Message-ID: <20040126214544.GA29999@thuille.itc.it>
On Mon, Jan 26, 2004 at 12:00:39PM -0800, Jeff D. Hamann wrote:
> I've been reading the current news on KerGIS this morning and I'm glad to
> see the initiative regarding quality control and the addtional resources to
> the underdeveloped and overworked GRASS developement pool. I've been wanting
> to utilize GRASS (as well as contribute) for a couple of years now and (and
> I'm not trying to gripe too much here and I'm not criticizing) it seems that
> the goals are constantly shifting as well as feature creep regarding the
> architecture. With all the development that has gone on in the last couple
> of years, GRASS still cannot handle some of the most basic of vector and
> database operations to satisfaction in a production environment. I think
> GRASS can be an awsome GIS tool (and in lots of respects it *is* -- raster
> and satellite processing mostly).
Did you ever try GRASS 5.7? If you refer to 4.x, 5.0-5.3: yes, vector
management is poor. But 5.7 is quite different. We would be glad to
hear comments why you (dis)like 5.7.
>
> I read the news regarding KerGIS with great enthusiasm as I've wished for
> such an event to happen for a couple of years. I think it just what the
> doctor ordered for the code. No more gmake5, etc. Fixing and simplify and
> remove optimizations! Yes, yes, yes...
Again 5.7: No more Gmakefile. Since 2001/2002 (can't remember precisely).
> I've been thinking about doing this
> for a couple fo years now, but since I've got to continue to produce and
> can't spend the time to do anything other create small supporting packages,
> I've not had the chance. As it stands now, I'm not sure where to contribute.
> There are *at least* three code streams for GRASS (5.0, 5.3 and 5.7 -- not
> to mention 4.3) This seems to be the opposite of fix and simplify.
Several developers prefer to work on 5.3 - even if things should have
been already merged into 5.7.
> And none
> of them seem to include the capabilites I need. In order for 5.7 to work, I
> need the code for 5.3. Why? Shouldn't all that new code simply go into 5.3?
No. Because then people would complain that backward compatibility is not there.
Indeed 5.3 should go into 5.7 while undergoing a code cleanup. But there
is not too much interest in that IMHO.
As long as the developers base for 5.7 is so small, we will have to live
with that odd "merge" problem. It's way to much work for "2.5 people" to
also merge 5.3 changes into 5.7 in case the code were replicated there.
> If I could get everthing to compile on my BSD platform, I would use it
> there.
5.7 was reported to compile successfully on FreeBSD. Did you try?
Then: I didn't see any error reports for BSD.
> If I could get everything to compile on cygwin, I'd use it there. But
> they don't.
You could simply download precompiled version from the grass.itc.it web
site (Linux, Cygwin, MacOSX soon).
> There's just too many switches and options for a simple (for
> example)
>
> ./configure
> make --with-mysql
> make install
>
> to work (at least for the 5.0.3 source code). For the 5.7 source code, you
> need 5.3 source code and the cygwin "weekly" binaries for 5.7 aren't availab
> le. I've not seen a project with so much connection between code streams.
> Why?
Because there aren't enough people to sort out this problem.
If it helped, we could merge the code into 5.7. But then I expect
a major desaster: 5.3 will receive changes and some developers
regularly ignore to update the relevant files in 5.7 as well.
I try to hunt for those files, but it's not that easy.
> Almost all of my work is with vectors and the attributes, lots of attributes
> of polygons (adjacency lists, unions, intersects, area calculations, and
> attributes -- think FRAGSTATS woulodn't it be nice to have a version for
> GRASS for people to build on). For my projects, I'm constantly moving files
> between GRASS and Arc/Info and ArcView for projecting files across all sorts
> of projections, datums and coordinate systems and I have yet to be able to
> accomplish this in GRASS simply because I can't gdal/GRASS to work resulting
> from some sort of goofy circular dependencies).
We are using gdal/GRASS daily - what's the problem on which platform?
> My Database is MySQL and my
> stats package is R (which seems to have be best model for development I've
> seen so far).
Yes, because R has x times so many developers.
> These are two great packages and the development process is
> solid almost militant in nature. MySQL releases a couple of times per year
> as does R and it seems GRASS has been limping along in the meantime. We need
> help. Isn't there an institution that promotes the development of GRASS
> where people can work on it full time? It seems that the overworked
> developers are spread pretty thin and the project needs a small army of
> people pushing on.
So you are welcome to participate. There are plenty of things to do.
> Okay, this seems a bit long winded so I'll shup now. And thanks for hearing
> my pleas.
>
> Thanks for the good work,
> Jeff.
Markus
From neteler at itc.it Mon Jan 26 16:46:48 2004
From: neteler at itc.it (Markus Neteler)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] r.in.gdal
In-Reply-To:
References: <8EC17EE03C13464E8049ADA41C53EB9E759722@mail3>
Message-ID: <20040126214648.GB29999@thuille.itc.it>
On Mon, Jan 26, 2004 at 01:11:11PM -0600, Tom Parker wrote:
> I tried the 5.3 update with no luck, I'm going to switch to an older gdal
> not the latest from cvs and see if that helps the 5.3 r.in.gdal patch.
Could you post the dataset in question somewhere? Then we could try
to replicate the problem.
Markus
>
> -----Original Message-----
> From: John Gillette [mailto:JGillette@rfmd.com]
> Sent: Monday, January 26, 2004 11:55 AM
> To: grass-dev; Tom Parker
> Subject: RE: [GRASS5] r.in.gdal
>
>
> Don't forget also the optimization trick, if you haven't
> tried it already.
>
> CFLAGS=-g ./configure ...
>
> configure grass as normal and then re-compile r.in.gdal.
> (I would assume you can rebuild only r.in.gdal with
> gmake.)
>
> This has fixed at least 2 other user's r.in.gdal (maybe),
> one of whom was running Redhat 8.0.
>
> My theory is that for Redhat >7, optimization is breaking
> r.in.gdal.
>
> Please let us know if you have tried this already or if it works.
>
> John
>
> > -----Original Message-----
> > From: Bernhard Reiter [mailto:bernhard@intevation.de]
> > Sent: Monday, January 26, 2004 11:56 AM
> > To: grass-dev
> > Subject: Re: [GRASS5] r.in.gdal
> >
> >
> > On Mon, Jan 26, 2004 at 10:10:41AM -0600, Tom Parker wrote:
> > > I'm trying to resolve the r.in.gdal segmentation fault
> > mentioned several
> > > times on the mailing list over the past year. The problem
> > shows itself no
> > > matter what type of raster file I try and import.
> > >
> > > My sytem is redhat 9 with gdal/proj/grass all built from CVS.
> > >
> > > After installing and/or building and installing several
> > versions of both
> > > grass and gdal as binaries or built from source the problem
> > isn't fixed. If
> > > there is a simple fix I'd love to know it or I'd be happy
> > to try and help
> > > fix the problem.
> >
> > Can you build with debugging support and try
> > to see what the traceback says?
> >
> > Check: http://grass.itc.it/grassdevel.html
> > for links to the "debugging" hints
> >
> > Are there any versions you didn't build yourself?
> > Bernhard
> >
>
> _______________________________________________
> grass5 mailing list
> grass5@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5
From tapadmin at swbell.net Mon Jan 26 17:02:57 2004
From: tapadmin at swbell.net (Tom Parker)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] r.in.gdal
In-Reply-To: <20040126214648.GB29999@thuille.itc.it>
Message-ID:
I will, I'm still trying to fix it myself but if I fail I'll certainly ask
for more help :)
-----Original Message-----
From: grass5-admin@grass.itc.it [mailto:grass5-admin@grass.itc.it]On
Behalf Of Markus Neteler
Sent: Monday, January 26, 2004 3:47 PM
To: grass-dev
Subject: Re: [GRASS5] r.in.gdal
On Mon, Jan 26, 2004 at 01:11:11PM -0600, Tom Parker wrote:
> I tried the 5.3 update with no luck, I'm going to switch to an older gdal
> not the latest from cvs and see if that helps the 5.3 r.in.gdal patch.
Could you post the dataset in question somewhere? Then we could try
to replicate the problem.
Markus
>
> -----Original Message-----
> From: John Gillette [mailto:JGillette@rfmd.com]
> Sent: Monday, January 26, 2004 11:55 AM
> To: grass-dev; Tom Parker
> Subject: RE: [GRASS5] r.in.gdal
>
>
> Don't forget also the optimization trick, if you haven't
> tried it already.
>
> CFLAGS=-g ./configure ...
>
> configure grass as normal and then re-compile r.in.gdal.
> (I would assume you can rebuild only r.in.gdal with
> gmake.)
>
> This has fixed at least 2 other user's r.in.gdal (maybe),
> one of whom was running Redhat 8.0.
>
> My theory is that for Redhat >7, optimization is breaking
> r.in.gdal.
>
> Please let us know if you have tried this already or if it works.
>
> John
>
> > -----Original Message-----
> > From: Bernhard Reiter [mailto:bernhard@intevation.de]
> > Sent: Monday, January 26, 2004 11:56 AM
> > To: grass-dev
> > Subject: Re: [GRASS5] r.in.gdal
> >
> >
> > On Mon, Jan 26, 2004 at 10:10:41AM -0600, Tom Parker wrote:
> > > I'm trying to resolve the r.in.gdal segmentation fault
> > mentioned several
> > > times on the mailing list over the past year. The problem
> > shows itself no
> > > matter what type of raster file I try and import.
> > >
> > > My sytem is redhat 9 with gdal/proj/grass all built from CVS.
> > >
> > > After installing and/or building and installing several
> > versions of both
> > > grass and gdal as binaries or built from source the problem
> > isn't fixed. If
> > > there is a simple fix I'd love to know it or I'd be happy
> > to try and help
> > > fix the problem.
> >
> > Can you build with debugging support and try
> > to see what the traceback says?
> >
> > Check: http://grass.itc.it/grassdevel.html
> > for links to the "debugging" hints
> >
> > Are there any versions you didn't build yourself?
> > Bernhard
> >
>
> _______________________________________________
> grass5 mailing list
> grass5@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5
_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5
From tapadmin at swbell.net Mon Jan 26 17:22:15 2004
From: tapadmin at swbell.net (Tom Parker)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] r.in.gdal
In-Reply-To:
Message-ID:
Hallelujah, it works.
proj-4.4.7
gdal-1.1.9
grass-5.3-cvs
seem to play nicely together.
I'm guessing the problem with the CVS version of gdal is related to a
problem I asked the gdal-dev list about last week. My C++ file readers that
depend on gdal/ogr/proj were reporting these errors in the console window.
ERROR 1: failed to load NAD27-83 correction file
...
ERROR 1: failed to load NAD27-83 correction file
ERROR 1: Reprojection failed, err = -38, further errors will be suppressed
on the transform object.
SO, I think that since I have been setting up my grass builds with this
configure command.
configure --without-postgres --without-odbc --without-fftw --with-gdal --wit
h-proj
It is failing to load the NAD27-83 correction file in r.in.gdal as well. My
initial attempts were just to add printf statements into main.c in the
r.in.gdal folder but that was less than helpful.
I will study the debugging hints now to see if I can be more helpful in the
future.
Thanks again.
Tom
-----Original Message-----
From: grass5-admin@grass.itc.it [mailto:grass5-admin@grass.itc.it]On
Behalf Of Tom Parker
Sent: Monday, January 26, 2004 4:03 PM
To: grass-dev
Subject: RE: [GRASS5] r.in.gdal
I will, I'm still trying to fix it myself but if I fail I'll certainly ask
for more help :)
-----Original Message-----
From: grass5-admin@grass.itc.it [mailto:grass5-admin@grass.itc.it]On
Behalf Of Markus Neteler
Sent: Monday, January 26, 2004 3:47 PM
To: grass-dev
Subject: Re: [GRASS5] r.in.gdal
On Mon, Jan 26, 2004 at 01:11:11PM -0600, Tom Parker wrote:
> I tried the 5.3 update with no luck, I'm going to switch to an older gdal
> not the latest from cvs and see if that helps the 5.3 r.in.gdal patch.
Could you post the dataset in question somewhere? Then we could try
to replicate the problem.
Markus
>
> -----Original Message-----
> From: John Gillette [mailto:JGillette@rfmd.com]
> Sent: Monday, January 26, 2004 11:55 AM
> To: grass-dev; Tom Parker
> Subject: RE: [GRASS5] r.in.gdal
>
>
> Don't forget also the optimization trick, if you haven't
> tried it already.
>
> CFLAGS=-g ./configure ...
>
> configure grass as normal and then re-compile r.in.gdal.
> (I would assume you can rebuild only r.in.gdal with
> gmake.)
>
> This has fixed at least 2 other user's r.in.gdal (maybe),
> one of whom was running Redhat 8.0.
>
> My theory is that for Redhat >7, optimization is breaking
> r.in.gdal.
>
> Please let us know if you have tried this already or if it works.
>
> John
>
> > -----Original Message-----
> > From: Bernhard Reiter [mailto:bernhard@intevation.de]
> > Sent: Monday, January 26, 2004 11:56 AM
> > To: grass-dev
> > Subject: Re: [GRASS5] r.in.gdal
> >
> >
> > On Mon, Jan 26, 2004 at 10:10:41AM -0600, Tom Parker wrote:
> > > I'm trying to resolve the r.in.gdal segmentation fault
> > mentioned several
> > > times on the mailing list over the past year. The problem
> > shows itself no
> > > matter what type of raster file I try and import.
> > >
> > > My sytem is redhat 9 with gdal/proj/grass all built from CVS.
> > >
> > > After installing and/or building and installing several
> > versions of both
> > > grass and gdal as binaries or built from source the problem
> > isn't fixed. If
> > > there is a simple fix I'd love to know it or I'd be happy
> > to try and help
> > > fix the problem.
> >
> > Can you build with debugging support and try
> > to see what the traceback says?
> >
> > Check: http://grass.itc.it/grassdevel.html
> > for links to the "debugging" hints
> >
> > Are there any versions you didn't build yourself?
> > Bernhard
> >
>
> _______________________________________________
> grass5 mailing list
> grass5@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5
_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5
_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5
From glynn.clements at virgin.net Mon Jan 26 18:09:30 2004
From: glynn.clements at virgin.net (Glynn Clements)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] Some news: KerGIS
In-Reply-To: <20040126185023.A909@polynum.org>
References: <20040124150814.A613@polynum.org>
<20040125125719.B624@polynum.org>
<20040126193211.549abe2e.hamish_nospam@yahoo.com>
<20040126141600.A470@polynum.org>
<20040126151144.GE20984@intevation.de>
<20040126185023.A909@polynum.org>
Message-ID: <16405.40490.373117.930328@cerise.nosuchdomain.co.uk>
Thierry Laronde wrote:
> The second error is trying to be "kind" with contributions, that is to
> think that accepting badly thought pieces of code will allow to keep
> wanabees contributors and that being too direct will disgust people at
> first attempt.
I haven't been paying much attention to this thread, but I would just
like to voice my agreement with the above.
--
Glynn Clements
From neteler at itc.it Tue Jan 27 04:29:49 2004
From: neteler at itc.it (Markus Neteler)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] r.in.gdal
In-Reply-To:
References:
Message-ID: <20040127092949.GA32077@thuille.itc.it>
On Mon, Jan 26, 2004 at 04:22:15PM -0600, Tom Parker wrote:
> Hallelujah, it works.
>
> proj-4.4.7
> gdal-1.1.9
> grass-5.3-cvs
>
> seem to play nicely together.
>
> I'm guessing the problem with the CVS version of gdal is related to a
> problem I asked the gdal-dev list about last week. My C++ file readers that
> depend on gdal/ogr/proj were reporting these errors in the console window.
>
> ERROR 1: failed to load NAD27-83 correction file
> ...
> ERROR 1: failed to load NAD27-83 correction file
> ERROR 1: Reprojection failed, err = -38, further errors will be suppressed
> on the transform object.
>
> SO, I think that since I have been setting up my grass builds with this
> configure command.
>
> configure --without-postgres --without-odbc --without-fftw --with-gdal --wit
> h-proj
>
> It is failing to load the NAD27-83 correction file in r.in.gdal as well. My
> initial attempts were just to add printf statements into main.c in the
> r.in.gdal folder but that was less than helpful.
>
> I will study the debugging hints now to see if I can be more helpful in the
> future.
Did you install the NAD27-83 correction files?
See
http://www.remotesensing.org/proj/faq.html
"How do I build/configure PROJ.4 to support datum shifting.
After downloading and unpacking the PROJ.4 source, also download and unpack the set of datum shift files. This would be a file like ftp://ftp.remotesensing.org/pub/proj/proj-nad27-1.1.tar.gz. This file should be unpacked within the proj/nad directory. Then proceed with the configuration, build and install. This will ensure that the build system knows about the grid shift files, and applies the ascii to binary preprocessing step.
How do I debug problems with NAD27/NAD83 datum shifting?
...
The PROJ_DEBUG environment can be defined (any value) to force extra output from the PROJ.4 library to stderr...
"
Once I had the same problem and installation of proj-nad27-1.1.tar.gz
helped together with recompilation of PROJ4.
Markus
From hamish_nospam at yahoo.com Tue Jan 27 04:59:12 2004
From: hamish_nospam at yahoo.com (Hamish)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] Re: KerGIS
In-Reply-To: <20040126214544.GA29999@thuille.itc.it>
References: <00a901c3e447$15c5a070$0a00a8c0@rodan>
<20040126214544.GA29999@thuille.itc.it>
Message-ID: <20040127225912.2520d745.hamish_nospam@yahoo.com>
> > : Jeff
> : Markus
------------
> > As it stands now, I'm not sure where to contribute.
Fixing things, or at least complaining about things, you need as you
need them is a good start I think. Over time this gets the
non-structural problems taken care of, and I think most GRASS's bugs
(from the user's perspective) are non-structural.
> > There are *at least* three code streams for GRASS (5.0, 5.3 and 5.7
> > -- not to mention 4.3) This seems to be the opposite of fix and
> > simplify.
I think at this point no one is directly working on 5.0, it's only old
business. So there are really two active branches. Actually only 1.5
branches really as 5.7 is only about 1.8 megabytes of code-- most of it
is automatically linked directly from the live 5.3 CVS and only exists
in one place. From the end user's perspective though, there is a tyranny
of choice.
> Several developers prefer to work on 5.3 - even if things should have
> been already merged into 5.7.
some feedback re. new business:
I don't really use vector or database support so using 5.7 isn't
critical for me. I do however need to use site data heavily, and the
simplicity & bash script-ability of the site_lists format (on the raw
ascii file level) makes me dependant on 5.3. If it wasn't for that I'd
use 5.7 in a minute. As I don't really work on the vector modules, any
improvements to the display or raster modules automatically get fed into
5.7 so I don't feel at all guilty about 'neglecting' it. I just have to
remember to update the man pages and ps.map and fight the urge to
clean up the sites modules.
None of this is structural work of course, just details.
I think the structural work for 5.3->5.7 is a full time job for someone.
Maybe I should look to see what I really need that couldn't be done
without anything more than s.in.ascii and s.out.ascii? Looking through
some scripts, not much actually! I seem to be somewhat addicted to
creating site_lists files manually with sed &/or Matlab though.
(s.univar was today's outside need, but that was to analyze some cell
stats on a raster map converted with r.to.sites; what a cludge! we need
a stats library! [again, I offer to help populate functions if someone
else lays down the framework; even though it should really be done by a
better coder/statistician than I])
> > And none of them seem to include the capabilites I need.
They never will unless people (repetitively) explain what is missing &
what they need.
> > In order for 5.7 to work, I need the code for 5.3. Why? Shouldn't
> > all that new code simply go into 5.3?
The idea, as I understand it, is for the 5.3 code branch (which includes
all the old 5.0 and 4.3- legacy code) to be retired almost as soon as it
is released. It has features (ie datum support) too important to be put
off until the official 5.7.0 release, yet too radical to go into the
stable 5.0 series. 5.7 is the opportunity for a vast clean up and
simplification of the GRASS code base-- we only transfer to it what is
actually used.
While we wait for that, I don't think it's too much to do as an end user
to rebuild 5.7 locally 3 or 4 times a year. You can write a script to
automate it or at least use as cut-and-paste notes for next time.. it's
a chore, but not 'hard'.
> > If I could get everything to compile on cygwin, I'd use it there.
> > But they don't.
What doesn't? Is there a bug report? (does r.terraflow compile, btw?)
> > There's just too many switches and options for a simple (for
> > example)
> >
> > ./configure
> > make --with-mysql
> > make install
Most of the "switches" (that I have to use, anyway) are really paths
pointing to where libraries/includes are. It'll never compile on say BSD
or even on both the two most popular Linux distributions without such
hints.
> > I've not seen a project with so much connection between code
> > streams. Why?
>
> Because there aren't enough people to sort out this problem.
> If it helped, we could merge the code into 5.7. But then I expect
> a major desaster: 5.3 will receive changes and some developers
> regularly ignore to update the relevant files in 5.7 as well.
> I try to hunt for those files, but it's not that easy.
Yes, it would be a huge pain to have to check in everything twice into
divergent code bases. The problem goes away as soon as 5.3 moves into
bug-fix-only mode though. It would be nice if we had a countdown to
5.3.0 todo-list on a webpage somewhere.
> > Almost all of my work is with vectors and the attributes, lots of
> > attributes of polygons (adjacency lists, unions, intersects, area
> > calculations, and attributes -- think FRAGSTATS woulodn't it be nice
> > to have a version for GRASS for people to build on).
So what's missing from 5.7?? I don't understand. What does 5.3 have that
5.7 is missing from for you? (besides simplicity of end-user building)
> > For my
> > projects, I'm constantly moving files between GRASS and Arc/Info and
> > ArcView for projecting files across all sorts of projections, datums
> > and coordinate systems and I have yet to be able to accomplish this
> > in GRASS simply because I can't gdal/GRASS to work resulting from
> > some sort of goofy circular dependencies).
So do you have problems with *both* PROJ.4 *and* GDAL/OGR then? I was
under the impression that the proj stuff was working really well in both
5.3 and 5.7...
What are the problems? Are there bug reports filed for them?
These are the sort of things that need to be fixed ASAP, IMO.
> > We need help. Isn't there an institution that promotes the
> > development of GRASS where people can work on it full time? It seems
> > that the overworked developers are spread pretty thin and the
> > project needs a small army of people pushing on.
If there are specific things you need fixed ASAP to make you more
productive so as to make your company more money, *especially* with
respect to PROJ.4 or GDAL, there are a number of people reading this
list who code for cash, probably for cheaper than an ESRI module, and it
might help break the log jam for others as well, which means more
support, which means more users, .. more support, etc.
> > And thanks for hearing my pleas.
ditto
regards & US$0.013,
Hamish
From neteler at itc.it Tue Jan 27 05:18:58 2004
From: neteler at itc.it (Markus Neteler)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] Re: KerGIS
In-Reply-To: <20040127225912.2520d745.hamish_nospam@yahoo.com>
References: <00a901c3e447$15c5a070$0a00a8c0@rodan> <20040126214544.GA29999@thuille.itc.it> <20040127225912.2520d745.hamish_nospam@yahoo.com>
Message-ID: <20040127101858.GF32077@thuille.itc.it>
On Tue, Jan 27, 2004 at 10:59:12PM +1300, Hamish wrote:
> > > : Jeff
> > : Markus
> ------------
>
[...]
> As I don't really work on the vector modules, any
> improvements to the display or raster modules automatically get fed into
> 5.7 so I don't feel at all guilty about 'neglecting' it.
This is actually not completely true.
E.g. (recent changes)
2004-01-24 02:53
* XDRIVER/XDRIVER24/Graph_Set.c: Erase window at startup (prevents
"transparent" window when starting without selecting).
... I had to merge. It's not clear to me why 5.7 is really *ignored*
by some developers. If 5.7 files (there are some due to necessary
changes) are not sync'ed, it will become more and more difficult to
maintain it. Why should we trace down bugs again if they are already
solved? A waste of time. Syncing these (few) files in 5.7 cannot be
so difficult. A bit frustrating at least for me.
[...]
> > > And none of them seem to include the capabilites I need.
>
> They never will unless people (repetitively) explain what is missing &
> what they need.
Agreed.
[...]
> > > There's just too many switches and options for a simple (for
> > > example)
> > >
> > > ./configure
> > > make --with-mysql
> > > make install
>
> Most of the "switches" (that I have to use, anyway) are really paths
> pointing to where libraries/includes are. It'll never compile on say BSD
> or even on both the two most popular Linux distributions without such
> hints.
Hint: Here are configure scripts:
5.0:
http://grass.itc.it/grass5/source/conf_scripts/
cygwin_generic/ 09-May-2003 17:28 -
cygwin_xserver/ 09-May-2003 17:28 -
linux/ 09-May-2003 17:30 -
5.7:
http://grass.itc.it/grass51/source/conf_scripts/
cygwin_xserver/ 08-Jan-2004 15:15 -
freebsd/ 12-Jan-2004 14:25 -
linux/ 08-Jan-2004 15:12 -
macosx/ 08-Jan-2004 15:13 -
5.7 also includes a ./debian/ directory. Instructions here:
http://mpa.itc.it/markus/grass57/debian/grass57deb/
> > > I've not seen a project with so much connection between code
> > > streams. Why?
> >
> > Because there aren't enough people to sort out this problem.
> > If it helped, we could merge the code into 5.7. But then I expect
> > a major desaster: 5.3 will receive changes and some developers
> > regularly ignore to update the relevant files in 5.7 as well.
> > I try to hunt for those files, but it's not that easy.
>
> Yes, it would be a huge pain to have to check in everything twice into
> divergent code bases. The problem goes away as soon as 5.3 moves into
> bug-fix-only mode though. It would be nice if we had a countdown to
> 5.3.0 todo-list on a webpage somewhere.
Such TODO list have been regularly ignored in the past.
[...]
> If there are specific things you need fixed ASAP to make you more
> productive so as to make your company more money, *especially* with
> respect to PROJ.4 or GDAL, there are a number of people reading this
> list who code for cash, probably for cheaper than an ESRI module, and it
> might help break the log jam for others as well, which means more
> support, which means more users, .. more support, etc.
Agreed.
[...]
Markus
From hamish_nospam at yahoo.com Tue Jan 27 06:04:04 2004
From: hamish_nospam at yahoo.com (Hamish)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] grass 5.0.3 in debian
In-Reply-To: <16399.41028.172818.727485@cerise.nosuchdomain.co.uk>
References: <20040105130845.GD13455@intevation.de>
<1073311576.1020.55.camel@localhost>
<20040107145228.GG3467@thuille.itc.it>
<1073488749.1035.4.camel@localhost>
<20040112083752.GE3731@thuille.itc.it>
<20040113191350.5f454184.hamish_nospam@yahoo.com>
<20040113095421.GB4135@firewall.ba.issia.cnr.it>
<20040122201204.6be7d5b1.hamish_nospam@yahoo.com>
<16399.41028.172818.727485@cerise.nosuchdomain.co.uk>
Message-ID: <20040128000404.32ce844b.hamish_nospam@yahoo.com>
> > > > > the GRASS 5.0.3 package has been submitted to debian.
And it is now in Debian/testing and slated for the next Debian release!
Congratulations and thanks to Federico and Francesco!
"apt-get install grass"
> > > > A couple of points about the new Debian package..
> > [I just installed it on a fresh machine]
>
> > > > - after changing to tcl/tk 8.4, does NVIZ still work??? could
> > > > someone check?
> > > > > Build against tcl/tk 8.4 (Closes: #206844).
> > > > for possible fix, see
> > > > http://article.gmane.org/gmane.comp.gis.grass.devel/2036/
> > > > ??
> > > > maybe fixed in the latest tcl/tk packages?
> > >
> > > To be verified.
> >
> > Nope, it doesn't work here.. same segfault.
> > Putting -lpthreads in
> > src.contrib/GMSL/NVIZ2.2/src/Gmakefile 's XTRA_LDFLAGS
> > doesn't fix it anymore either. Maybe somewhere else?
> >
> > Compiling against Tcl/Tk 8.3 does work however.
>
> Do you have both 8.3 and 8.4 on the same machine? If so, are you sure
> that the headers, the link-time libraries and the run-time libraries
> are all the same version?
I think I started out with only 8.4, but don't trust that.
Currently, I have the following installed:
tcl8.3 install
tcl8.3-dev install
tcl8.4 install
tcl8.4-dev install
tk8.3 install
tk8.3-dev install
tk8.4
tk8.3-dev conflicts with tk8.4-dev so the latter is removed.
GRASS compiles and NVIZ works.
After removing *8.3* packages from the system, the grass.deb package
still fails.
I'll have to check on which 'wish' is used, but I wouldn't think this
is accessed during building? And removing 'tk8.3' should fix it then,
but doesn't.
[then, after installing tk8.4-dev]
Building 5.0.3 from source, GRASS builds ok and NVIZ still fails.
Building 5.3-cvs from source, GRASS builds ok and NVIZ still fails.
> FWIW, does Debian include the version number (e.g. libtk8.3.so) or
> does it use libtk.so.0?
Everything is versioned. The file 'libtk.so.0' doesn't exist in the
Debian archive- not sure if that covers symlinks though.
/usr/lib/libtcl8.4.a
/usr/lib/libtcl8.4.so@ -> libtcl8.4.so.0
/usr/lib/libtcl8.4.so.0
/usr/lib/libtclstub8.4.a
/usr/lib/tcl8.4/[many]
/usr/include/tcl8.4/[many]
/usr/lib/libtk8.4.a
/usr/lib/libtk8.4.so@ -> libtk8.4.so.0
/usr/lib/libtk8.4.so.0
/usr/lib/libtkstub8.4.a
/usr/lib/tk8.4/[many]
/usr/bin/wish8.4
/usr/bin/wish@ -> /etc/alternatives/wish@ -> /usr/bin/wish8.4
(8.3 is along the same lines)
:( good idea though.
Hamish
From hamish_nospam at yahoo.com Tue Jan 27 06:37:17 2004
From: hamish_nospam at yahoo.com (Hamish)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] d.barscale enhancement, d.scale retirement
In-Reply-To: <16405.5064.651992.707094@cerise.nosuchdomain.co.uk>
References: <20040117201845.3adb5656.hamish_nospam@yahoo.com>
<20040121142434.GA12748@thuille.itc.it>
<20040126232119.02935e9e.hamish_nospam@yahoo.com>
<16405.5064.651992.707094@cerise.nosuchdomain.co.uk>
Message-ID: <20040128003717.0609dbb3.hamish_nospam@yahoo.com>
> > > Do you see a chance to extend d.barscale to work with Lat/Long?
> >
> > d.scale lets you draw something to the screen in Lat/Long, but it's
> > totally wrong. d.barscale is an improvement as it won't let you try.
> >
> > So I don't think there's anything worth keeping d.scale around for
> > now.
> >
> > If one were to make d.scale/barscale work in lat/lon, how would you
> > do it? Use 1852*60*cos(lat) to favour the x-axis as the scale bar
> > will be horizontal? Regardless of what you do a one-dimensional
> > scale will be incorrect in the other dimension, and I'd rather not
> > get into maximum latitude/scale rules.
>
> How about marking the scale in degrees?
Good idea. Would anyone use it though? I don't think I would in the form
of a bar scale. Maybe as an all around border in the style of the
d.barscale bar, but probably as part of ps.map for hard copies, not on
the display or for web/presentation graphics.
For Lat/Lon I've always preferred something like d.grid with text labels
at the map edge. Maybe that is worth focusing on first for the display.
I'm trying to remember if I ever got the degree symbol working outside
of d.text.freetype. No matter, easy enough to draw or make a small 'o'.
I can put together a nice compass rose for L/L as a consolation prize..
Too bad it stretches the wrong way or else I could stretch the E/W arms
to show map distortion.
Hamish
From tlaronde at polynum.com Tue Jan 27 07:03:02 2004
From: tlaronde at polynum.com (Thierry Laronde)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] Next news in 1 month
In-Reply-To: <20040124150814.A613@polynum.org>; from tlaronde@polynum.com on Sat, Jan 24, 2004 at 03:08:14PM +0100
References: <20040124150814.A613@polynum.org>
Message-ID: <20040127130302.B483@polynum.org>
Subject says it all. I will follow my planning and expect to have the
whole (without X/Motif) fixed in 1 month (calendar).
Cheers,
--
Thierry Laronde (Alceste)
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
From glynn.clements at virgin.net Tue Jan 27 08:15:29 2004
From: glynn.clements at virgin.net (Glynn Clements)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] Re: KerGIS
In-Reply-To: <20040127101858.GF32077@thuille.itc.it>
References: <00a901c3e447$15c5a070$0a00a8c0@rodan>
<20040126214544.GA29999@thuille.itc.it>
<20040127225912.2520d745.hamish_nospam@yahoo.com>
<20040127101858.GF32077@thuille.itc.it>
Message-ID: <16406.25713.872074.827079@cerise.nosuchdomain.co.uk>
Markus Neteler wrote:
> > As I don't really work on the vector modules, any
> > improvements to the display or raster modules automatically get fed into
> > 5.7 so I don't feel at all guilty about 'neglecting' it.
>
> This is actually not completely true.
>
> E.g. (recent changes)
>
> 2004-01-24 02:53
>
> * XDRIVER/XDRIVER24/Graph_Set.c: Erase window at startup (prevents
> "transparent" window when starting without selecting).
>
> ... I had to merge. It's not clear to me why 5.7 is really *ignored*
> by some developers.
Because it's a sufficiently radical departure from the existing code
base that it's effectively a separate project, and not everyone has
the time to work on two projects.
Maybe you should be asking whether it was really necessary fo 5.7 to
have its own version of Graph_set.c, given that the differences amount
to:
1. A different cursor.
2. The default background being white instead of black.
Does this really justify forking that file (and also Serve_Xevent.c,
solely for point 2)?
How many of the files which have been forked in 5.7 are really
necessary? I'm not counting cases where, all other things being equal,
the change would have been an improvement; because all other things
aren't equal.
Minimising divergence between the two code bases ought to carry *some*
weight (I'm not arguing how much weight, only that it should be
non-zero), and changes should only be made if they provide "enough"
benefit.
--
Glynn Clements
From neteler at itc.it Tue Jan 27 08:36:01 2004
From: neteler at itc.it (Markus Neteler)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] Re: KerGIS
In-Reply-To: <16406.25713.872074.827079@cerise.nosuchdomain.co.uk>
References: <00a901c3e447$15c5a070$0a00a8c0@rodan> <20040126214544.GA29999@thuille.itc.it> <20040127225912.2520d745.hamish_nospam@yahoo.com> <20040127101858.GF32077@thuille.itc.it> <16406.25713.872074.827079@cerise.nosuchdomain.co.uk>
Message-ID: <20040127133601.GL32077@thuille.itc.it>
On Tue, Jan 27, 2004 at 01:15:29PM +0000, Glynn Clements wrote:
>
> Markus Neteler wrote:
>
> > > As I don't really work on the vector modules, any
> > > improvements to the display or raster modules automatically get fed into
> > > 5.7 so I don't feel at all guilty about 'neglecting' it.
> >
> > This is actually not completely true.
> >
> > E.g. (recent changes)
> >
> > 2004-01-24 02:53
> >
> > * XDRIVER/XDRIVER24/Graph_Set.c: Erase window at startup (prevents
> > "transparent" window when starting without selecting).
> >
> > ... I had to merge. It's not clear to me why 5.7 is really *ignored*
> > by some developers.
>
> Because it's a sufficiently radical departure from the existing code
> base that it's effectively a separate project, and not everyone has
> the time to work on two projects.
>
> Maybe you should be asking whether it was really necessary fo 5.7 to
> have its own version of Graph_set.c, given that the differences amount
> to:
>
> 1. A different cursor.
> 2. The default background being white instead of black.
>
> Does this really justify forking that file (and also Serve_Xevent.c,
> solely for point 2)?
In my opinion there is no fork needed. I would appreciate to
see the 5.7 changes in 5.3.
> How many of the files which have been forked in 5.7 are really
> necessary? I'm not counting cases where, all other things being equal,
> the change would have been an improvement; because all other things
> aren't equal.
Several (most?) of the forks in libes/gis/, XDRIVER etc. could be
merged from 5.7 into 5.3. But this requires that someone else than
me checks it.
E.g: If 5.3 users prefer the black X-monitor over the white X-monitor
in 5.7, we cannot merge. The same applies to the improved cursor
in 5.7.
We'll certainly not replace the improvements in 5.7 with old code
from 5.3.
> Minimising divergence between the two code bases ought to carry *some*
> weight (I'm not arguing how much weight, only that it should be
> non-zero), and changes should only be made if they provide "enough"
> benefit.
Minimising divergence requires that 5.3 developers look at 5.7.
Unless they aren't willing to do that, the minimization of divergences
will have to wait, unfortunately.
Markus
From glynn.clements at virgin.net Tue Jan 27 08:39:55 2004
From: glynn.clements at virgin.net (Glynn Clements)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] grass 5.0.3 in debian
In-Reply-To: <20040128000404.32ce844b.hamish_nospam@yahoo.com>
References: <20040105130845.GD13455@intevation.de>
<1073311576.1020.55.camel@localhost>
<20040107145228.GG3467@thuille.itc.it>
<1073488749.1035.4.camel@localhost>
<20040112083752.GE3731@thuille.itc.it>
<20040113191350.5f454184.hamish_nospam@yahoo.com>
<20040113095421.GB4135@firewall.ba.issia.cnr.it>
<20040122201204.6be7d5b1.hamish_nospam@yahoo.com>
<16399.41028.172818.727485@cerise.nosuchdomain.co.uk>
<20040128000404.32ce844b.hamish_nospam@yahoo.com>
Message-ID: <16406.27179.786608.337566@cerise.nosuchdomain.co.uk>
Hamish wrote:
> After removing *8.3* packages from the system, the grass.deb package
> still fails.
>
> I'll have to check on which 'wish' is used, but I wouldn't think this
> is accessed during building?
No. "wish" isn't used by NVIZ in any way. However, the "nviz" script
itself uses tclsh (I strongly suggest replacing that with a Bourne
shell script; a simple "Segmentation fault" message is a lot less
confusing than the current 3-level Tcl backtrace).
> And removing 'tk8.3' should fix it then, but doesn't.
>
> [then, after installing tk8.4-dev]
> Building 5.0.3 from source, GRASS builds ok and NVIZ still fails.
> Building 5.3-cvs from source, GRASS builds ok and NVIZ still fails.
This is with no Tcl or Tk 8.3 files on the system, right?
Do the tkInt.h and tkIntDecls.h files from Debian's Tk 8.4 source code
match the tkInt8.4.h and tkIntDecls8.4.h files included in
NVIZ2.2/src?
Note: those files probably won't be included in any binary package;
that's why NVIZ includes copies. But NVIZ' copies *must* match the Tk
library which it uses.
Has anyone tried debugging this?
--
Glynn Clements
From bernhard at intevation.de Tue Jan 27 08:49:21 2004
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] Why are some 5.7 files diverging?
In-Reply-To: <16406.25713.872074.827079@cerise.nosuchdomain.co.uk>
References: <00a901c3e447$15c5a070$0a00a8c0@rodan> <20040126214544.GA29999@thuille.itc.it> <20040127225912.2520d745.hamish_nospam@yahoo.com> <20040127101858.GF32077@thuille.itc.it> <16406.25713.872074.827079@cerise.nosuchdomain.co.uk>
Message-ID: <20040127134921.GE24587@intevation.de>
On Tue, Jan 27, 2004 at 01:15:29PM +0000, Glynn Clements wrote:
> Markus Neteler wrote:
> > ... I had to merge. It's not clear to me why 5.7 is really *ignored*
> > by some developers.
>
> Because it's a sufficiently radical departure from the existing code
> base that it's effectively a separate project, and not everyone has
> the time to work on two projects.
That is too strongly worded, I'd say.
The situation was that we wanted to have people
make radical changes without interrupting the growing
trust old users started to gain in GRASS 5 development.
So Radim started out in agreement with many people
and did a good job. In fact he did not get enough feedback on his work.
When I see how many people now start to test 5.7 once in a while,
I would call that strategy a success.
> Maybe you should be asking whether it was really necessary fo 5.7 to
> have its own version of Graph_set.c
Those technical detail questions and feedbak certainly
is one that Radim asked for many times.
> Minimising divergence between the two code bases ought to carry *some*
> weight (I'm not arguing how much weight, only that it should be
> non-zero), and changes should only be made if they provide "enough"
> benefit.
It already carries _some_ weight.
I trust the 5.7 developers to make reasonable judgements.
However if you find places that can be improved
I guess they'd like feedback. :)
Bernhard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20040127/e973b944/attachment.bin
From mlennert at club.worldonline.be Tue Jan 27 10:25:10 2004
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] GRASS57: debian package build : dead symbolic links to 5.3 sources
Message-ID: <34615.164.15.134.155.1075217110.squirrel@moritz.homelinux.org>
Hello,
I am trying to use dpkg-buildpackage on 5.7. However, I have the following
problem:
in debian/rules the following defines the location of the 5.3 sources:
GRASS53SRC=../grass-5.3.0
this is correct for me as I have:
$ ls -l
total 20
drwxr-xr-x 23 mlennert mlennert 4096 2004-01-05 15:40 grass
drwxr-xr-x 21 mlennert mlennert 4096 2004-01-27 16:10 grass51
lrwxrwxrwx 1 mlennert mlennert 5 2004-01-27 15:24 grass-5.3.0 ->
grass
lrwxrwxrwx 1 mlennert mlennert 7 2004-01-27 15:24 grass-5.7.0 ->
grass51
However, in grass-5.7.0/include I have a series of dead links pointing to
../grass-5.3.0/src/include/*.h
This should be ../../grass-5.3.0/src/include/*.h
Where can I change the links that are created ?
Moritz
From neteler at itc.it Tue Jan 27 10:32:52 2004
From: neteler at itc.it (Markus Neteler)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] GRASS57: debian package build : dead symbolic links to 5.3 sources
In-Reply-To: <34615.164.15.134.155.1075217110.squirrel@moritz.homelinux.org>
References: <34615.164.15.134.155.1075217110.squirrel@moritz.homelinux.org>
Message-ID: <20040127153252.GD3741@thuille.itc.it>
On Tue, Jan 27, 2004 at 04:25:10PM +0100, Moritz Lennert wrote:
> Hello,
>
> I am trying to use dpkg-buildpackage on 5.7. However, I have the following
> problem:
>
> in debian/rules the following defines the location of the 5.3 sources:
>
> GRASS53SRC=../grass-5.3.0
>
> this is correct for me as I have:
>
> $ ls -l
> total 20
> drwxr-xr-x 23 mlennert mlennert 4096 2004-01-05 15:40 grass
> drwxr-xr-x 21 mlennert mlennert 4096 2004-01-27 16:10 grass51
> lrwxrwxrwx 1 mlennert mlennert 5 2004-01-27 15:24 grass-5.3.0 ->
> grass
> lrwxrwxrwx 1 mlennert mlennert 7 2004-01-27 15:24 grass-5.7.0 ->
> grass51
>
> However, in grass-5.7.0/include I have a series of dead links pointing to
> ../grass-5.3.0/src/include/*.h
>
> This should be ../../grass-5.3.0/src/include/*.h
>
> Where can I change the links that are created ?
In grass51/debian/rules you find the configuration. It seems,
that
- the link trick above doesn't work with 'make mix' done in
grass51/debian/rules
- something else not right.
Did you try to rename the dirs instead of linking?
Once we were able to make a debian package, if time, I'll
try again soon.
Markus
From sholl at gmx.net Tue Jan 27 11:17:07 2004
From: sholl at gmx.net (Stephan Holl)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] PostGIS with GRASS 5.7
References: <200401261023.i0QANi602110@janacek.itc.it.>
Message-ID: <19648.1075220227@www40.gmx.net>
> On Friday 23 January 2004 19:40, Stephan Holl wrote:
> > Dear GRASS-Developers,
> >
> > while thinking about using GRASS 5.7 as a 'PostGIS-data-editor' I am
> > facing the problem, that areas are only read as boundaries by UMN
> > Mapserver.
> > You know about that, I guess.
> >
> > But are there some workarounds to display GRASS-modified PostGIS-data
> > correctly in UMN Mapserver?!
> >
> > Another question is about the user management with roles, views etc. in
> > Postgres.
> > Is it possible to apply this user management of Postgres to the db-user
> > who is modifying the PostGIS database?
> There are too many problems with PostGIS in GRASS, I thing, that
> the best would be to remove or at leas disable PostGIS and maybe
> shapefile and support only OGR sources as read only with pseudotopology.
OK, thanks for your statement.
>
> Why do you need data stored in PostGIS? It is impossible to publish
> the data anybody is working on. Editing may be done in GRASS native
> and once finished, you can run v.out.ogr.
V.digit should be used to edit a postgis-database in order complete existing
data.
AFAIK there is permanent work on the data, so the postgis-data should be
edited by GRASS.
It should be stored in PostGIS, because the data is served through
mapserver, and the database-server is a PostGIS-Server.
So you think, there is no "easy" sollution to make GRASS-Postgis
UMN-mapserver compatible?!
Perhaps it would be possible to store my data as shapefiles, which can be
edited by v.digit.
I will think about that.
Anyway, thanks for your help.
Cheers
Stephan Holl
--
+++ GMX - die erste Adresse f?r Mail, Message, More +++
Bis 31.1.: TopMail + Digicam f?r nur 29 EUR http://www.gmx.net/topmail
From fog at debian.org Tue Jan 27 16:38:45 2004
From: fog at debian.org (Federico Di Gregorio)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] grass 5.0.3 in debian
In-Reply-To: <16406.27179.786608.337566@cerise.nosuchdomain.co.uk>
References: <20040105130845.GD13455@intevation.de>
<1073311576.1020.55.camel@localhost> <20040107145228.GG3467@thuille.itc.it>
<1073488749.1035.4.camel@localhost> <20040112083752.GE3731@thuille.itc.it>
<20040113191350.5f454184.hamish_nospam@yahoo.com>
<20040113095421.GB4135@firewall.ba.issia.cnr.it>
<20040122201204.6be7d5b1.hamish_nospam@yahoo.com>
<16399.41028.172818.727485@cerise.nosuchdomain.co.uk>
<20040128000404.32ce844b.hamish_nospam@yahoo.com>
<16406.27179.786608.337566@cerise.nosuchdomain.co.uk>
Message-ID: <1075239525.1477.41.camel@localhost>
Il mar, 2004-01-27 alle 14:39, Glynn Clements ha scritto:
[snip]
> Do the tkInt.h and tkIntDecls.h files from Debian's Tk 8.4 source code
> match the tkInt8.4.h and tkIntDecls8.4.h files included in
> NVIZ2.2/src?
>
> Note: those files probably won't be included in any binary package;
> that's why NVIZ includes copies. But NVIZ' copies *must* match the Tk
> library which it uses.
argh. this is evil. any well-done package should include all needed
header files as debian does in /usr/include/tcl8.4/tk-private/. anyway,
a diff does not report anything usefull (no real differences.)
should we revert to 8.3?
federico
--
Federico Di Gregorio http://people.initd.org/fog
Debian GNU/Linux Developer fog@debian.org
INIT.D Developer fog@initd.org
The devil speaks truth much oftener than he's deemed.
He has an ignorant audience. -- Byron (suggested by Alice Fontana)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Questa parte del messaggio =?ISO-8859-1?Q?=E8?= firmata
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20040127/0fb981a7/attachment.bin
From mlennert at club.worldonline.be Wed Jan 28 05:55:21 2004
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] GRASS57: debian package build : dead symbolic links
to 5.3 sources
In-Reply-To: <20040127153252.GD3741@thuille.itc.it>
References: <34615.164.15.134.155.1075217110.squirrel@moritz.homelinux.org>
<20040127153252.GD3741@thuille.itc.it>
Message-ID: <36297.164.15.134.155.1075287321.squirrel@moritz.homelinux.org>
Markus Neteler said:
> On Tue, Jan 27, 2004 at 04:25:10PM +0100, Moritz Lennert wrote:
>> Hello,
>> I am trying to use dpkg-buildpackage on 5.7. However, I have the following
>> problem:
>> in debian/rules the following defines the location of the 5.3 sources:
GRASS53SRC=../grass-5.3.0
>> this is correct for me as I have:
>> $ ls -l
>> total 20
>> drwxr-xr-x 23 mlennert mlennert 4096 2004-01-05 15:40 grass
drwxr-xr-x 21 mlennert mlennert 4096 2004-01-27 16:10 grass51
lrwxrwxrwx 1 mlennert mlennert 5 2004-01-27 15:24 grass-5.3.0
->
>> grass
>> lrwxrwxrwx 1 mlennert mlennert 7 2004-01-27 15:24 grass-5.7.0 ->
>> grass51
>> However, in grass-5.7.0/include I have a series of dead links pointing to
>> ../grass-5.3.0/src/include/*.h
>> This should be ../../grass-5.3.0/src/include/*.h
>> Where can I change the links that are created ?
>
> In grass51/debian/rules you find the configuration. It seems,
> that
> - the link trick above doesn't work with 'make mix' done in
> grass51/debian/rules
> - something else not right.
>
> Did you try to rename the dirs instead of linking?
I did and it doesn't work either, i.e. the links in grass-5.7.0/include
are again to ../grass-5.3.0 and not to ../../grass-5.3.0.
I solved the problem by replacing the relative path for
#path to GRASS 5.3 source code
GRASS53SRC=
to an absolute path.
Moritz
From glynn.clements at virgin.net Wed Jan 28 06:28:48 2004
From: glynn.clements at virgin.net (Glynn Clements)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] grass 5.0.3 in debian
In-Reply-To: <1075239525.1477.41.camel@localhost>
References: <20040105130845.GD13455@intevation.de>
<1073311576.1020.55.camel@localhost>
<20040107145228.GG3467@thuille.itc.it>
<1073488749.1035.4.camel@localhost>
<20040112083752.GE3731@thuille.itc.it>
<20040113191350.5f454184.hamish_nospam@yahoo.com>
<20040113095421.GB4135@firewall.ba.issia.cnr.it>
<20040122201204.6be7d5b1.hamish_nospam@yahoo.com>
<16399.41028.172818.727485@cerise.nosuchdomain.co.uk>
<20040128000404.32ce844b.hamish_nospam@yahoo.com>
<16406.27179.786608.337566@cerise.nosuchdomain.co.uk>
<1075239525.1477.41.camel@localhost>
Message-ID: <16407.40176.30719.755493@cerise.nosuchdomain.co.uk>
Federico Di Gregorio wrote:
> Il mar, 2004-01-27 alle 14:39, Glynn Clements ha scritto:
> [snip]
> > Do the tkInt.h and tkIntDecls.h files from Debian's Tk 8.4 source code
> > match the tkInt8.4.h and tkIntDecls8.4.h files included in
> > NVIZ2.2/src?
> >
> > Note: those files probably won't be included in any binary package;
> > that's why NVIZ includes copies. But NVIZ' copies *must* match the Tk
> > library which it uses.
>
> argh. this is evil. any well-done package should include all needed
> header files as debian does in /usr/include/tcl8.4/tk-private/.
Unfortunately, not including tkInt.h etc appears to be standard
practice; probably because they aren't required unless you are
creating your own widget classes.
Those headers aren't installed by Tk's "make install", and aren't
included in most vendors' binary packages. So, GRASS has to include
the tkInt.h and tkIntDecls.h files for the various Tk versions.
> anyway, a diff does not report anything usefull (no real
> differences.)
That's one possibility eliminated.
Has anything changed between 8.3 and 8.4 which would affect code which
creates new widget classes?
> should we revert to 8.3?
Tk 8.4 isn't going to go away, so NVIZ/Togl will have to deal with the
issues eventually.
Another line of approach would be to check whether the original Togl
code has had any changes for Tk 8.4.
--
Glynn Clements
From blazek at itc.it Wed Jan 28 08:05:10 2004
From: blazek at itc.it (Radim Blazek)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] PostGIS with GRASS 5.7
In-Reply-To: <19648.1075220227@www40.gmx.net>
References: <200401261023.i0QANi602110@janacek.itc.it.> <19648.1075220227@www40.gmx.net>
Message-ID: <200401281305.i0SD5BY21290@janacek.itc.it.>
On Tuesday 27 January 2004 17:17, Stephan Holl wrote:
> > Why do you need data stored in PostGIS? It is impossible to publish
> > the data anybody is working on. Editing may be done in GRASS native
> > and once finished, you can run v.out.ogr.
>
> V.digit should be used to edit a postgis-database in order complete
> existing data.
> AFAIK there is permanent work on the data, so the postgis-data should be
> edited by GRASS.
> It should be stored in PostGIS, because the data is served through
> mapserver, and the database-server is a PostGIS-Server.
Currently it is not possible to edit GRASS vectors with geometry stored in PostGIS.
You cannot use data which are under construction in mapserver, IMHO.
What kind of data, how often do you need to update the version in mapserver?
Data are edited by one or more users at the same time?
> So you think, there is no "easy" sollution to make GRASS-Postgis
> UMN-mapserver compatible?!
Yes, no easy solution.
> Perhaps it would be possible to store my data as shapefiles, which can be
> edited by v.digit.
> I will think about that.
No, shapefiles cannot be edited, the same problem - SFS as PosGIS.
Why native format and v.out.ogr is a problem?
Radim
From mlennert at club.worldonline.be Wed Jan 28 08:14:48 2004
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] grass5.7 v.shape.register: Illegal vector map name .
Character <.> not allowed.
Message-ID: <37064.164.15.134.155.1075295688.squirrel@moritz.homelinux.org>
Hello,
v.shape.register causes an error when trying to register a shape file:
GRASS 5.7.-cvs:~ > v.shape.register SHAPEFILES/communes
Registering SHAPE file into GRASS...
Illegal vector map name . Character <.> not allowed.
ERROR: Map name not SQL compliant.
communes.shp is registered now (first layer only).
The SHAPE files (.shp, shx and .dbf) were copied to:
/data/GRASSDATA/BELGIQUE5.1/shp
Trying to display the map, I get the same error:
GRASS 5.7.-cvs:~ > d.vect communes.shp
Illegal vector map name . Character <.> not allowed.
ERROR: Map name not SQL compliant.
When importing the file to native grass5.7 format with v.format,
everything works fine.
Moritz
From neteler at itc.it Wed Jan 28 09:46:47 2004
From: neteler at itc.it (Markus Neteler)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] GRASS57: debian package build : dead symbolic links to 5.3 sources
In-Reply-To: <36297.164.15.134.155.1075287321.squirrel@moritz.homelinux.org>
References: <34615.164.15.134.155.1075217110.squirrel@moritz.homelinux.org> <20040127153252.GD3741@thuille.itc.it> <36297.164.15.134.155.1075287321.squirrel@moritz.homelinux.org>
Message-ID: <20040128144647.GI10611@thuille.itc.it>
On Wed, Jan 28, 2004 at 11:55:21AM +0100, Moritz Lennert wrote:
> Markus Neteler said:
> > On Tue, Jan 27, 2004 at 04:25:10PM +0100, Moritz Lennert wrote:
> >> Hello,
> >> I am trying to use dpkg-buildpackage on 5.7. However, I have the following
> >> problem:
> >> in debian/rules the following defines the location of the 5.3 sources:
> GRASS53SRC=../grass-5.3.0
> >> this is correct for me as I have:
> >> $ ls -l
> >> total 20
> >> drwxr-xr-x 23 mlennert mlennert 4096 2004-01-05 15:40 grass
> drwxr-xr-x 21 mlennert mlennert 4096 2004-01-27 16:10 grass51
> lrwxrwxrwx 1 mlennert mlennert 5 2004-01-27 15:24 grass-5.3.0
> ->
> >> grass
> >> lrwxrwxrwx 1 mlennert mlennert 7 2004-01-27 15:24 grass-5.7.0 ->
> >> grass51
> >> However, in grass-5.7.0/include I have a series of dead links pointing to
> >> ../grass-5.3.0/src/include/*.h
> >> This should be ../../grass-5.3.0/src/include/*.h
> >> Where can I change the links that are created ?
> >
> > In grass51/debian/rules you find the configuration. It seems,
> > that
> > - the link trick above doesn't work with 'make mix' done in
> > grass51/debian/rules
> > - something else not right.
> >
> > Did you try to rename the dirs instead of linking?
>
> I did and it doesn't work either, i.e. the links in grass-5.7.0/include
> are again to ../grass-5.3.0 and not to ../../grass-5.3.0.
>
> I solved the problem by replacing the relative path for
>
> #path to GRASS 5.3 source code
> GRASS53SRC=
>
> to an absolute path.
Ah, now I understand: Maybe it depends in which directory you
launch 'dpkg-buildpackage'
?
Do you think I should change it to an absolute path?
Markus
From neteler at itc.it Wed Jan 28 09:53:55 2004
From: neteler at itc.it (Markus Neteler)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] grass5.7 v.shape.register: Illegal vector map name . Character <.> not allowed.
In-Reply-To: <37064.164.15.134.155.1075295688.squirrel@moritz.homelinux.org>
References: <37064.164.15.134.155.1075295688.squirrel@moritz.homelinux.org>
Message-ID: <20040128145355.GK10611@thuille.itc.it>
On Wed, Jan 28, 2004 at 02:14:48PM +0100, Moritz Lennert wrote:
> Hello,
>
> v.shape.register causes an error when trying to register a shape file:
>
> GRASS 5.7.-cvs:~ > v.shape.register SHAPEFILES/communes
> Registering SHAPE file into GRASS...
> Illegal vector map name . Character <.> not allowed.
> ERROR: Map name not SQL compliant.
> communes.shp is registered now (first layer only).
> The SHAPE files (.shp, shx and .dbf) were copied to:
> /data/GRASSDATA/BELGIQUE5.1/shp
>
> Trying to display the map, I get the same error:
>
> GRASS 5.7.-cvs:~ > d.vect communes.shp
> Illegal vector map name . Character <.> not allowed.
> ERROR: Map name not SQL compliant.
>
> When importing the file to native grass5.7 format with v.format,
> everything works fine.
v.shape.register needs an update to remove the '.shp'
extension (pipe to sed).
Would you be able to update and send it to me?
The test for valid map names we introduced recently
but forgot to think of v.shape.register (maybe v.shape.unregister
must be checked as well).
Markus
From neteler at itc.it Wed Jan 28 11:09:48 2004
From: neteler at itc.it (Markus Neteler)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] 5.7: v.in.ogr new feature
Message-ID: <20040128160948.GA12528@thuille.itc.it>
Hi,
now v.in.ogr is able to create locations from OGR sources
(implemented with much help from Paul Kelly).
Example:
GRASS 5.7.-cvs:~/test > ls roads.*
roads.dbf roads.prj roads.shp roads.shx
GRASS 5.7.-cvs:~/test > v.in.ogr dsn=roads.shp out=roadstest location=ogrtest
The roads.shp will be imported into a new location 'ogrtest'.
Otherwise (without 'location=' parameter) it will be tested,
if the projection defined in 'roads.prj' matches the current
location definition.
Please try and complain,
Markus
From grass-bugs at intevation.de Wed Jan 28 15:59:22 2004
From: grass-bugs at intevation.de (Request Tracker)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] [bug #2303] (grass) solicitud de descarga de software
Message-ID: <20040128205922.DEA8C13B84@lists.intevation.de>
this bug's URL: http://intevation.de/rt/webrt?serial_num=2303
-------------------------------------------------------------------------
Subject: solicitud de descarga de software
Platform: WindowsNT/2000/XP
grass binary for platform: Compiled from Sources
Please enter error description here (and your name)
-------------------------------------------- Managed by Request Tracker
From hmitaso at unity.ncsu.edu Wed Jan 28 20:51:11 2004
From: hmitaso at unity.ncsu.edu (Helena)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] r.slope.aspect in feet
Message-ID: <4018670F.8010806@unity.ncsu.edu>
Before GRASS5.3 is released I would like to point out that
if the data are in a coordinate system that uses feet
r.slope.aspect quietly converts x,y to meters while leaving z in feet
leading to greatly exagerrated slopes.
I looked into the code and it seems that
G_begin_distance_calculations(), G_distance,
automatically converts to meters.
Is this a desired behavior? If yes, r.slope.aspect should return a warning
as there is no way for the user to know that r.slope.aspect is converting
x,y to meters which means it is the users responsibility
to convert z to meters using zfactor, which is slightly indicated in help
and in manual but it is not really clear. Should this be fixed by
-adding the warning (and a sentence in manual that elevation MUST
be converted to meters by zfactor, now it sounds as if zfactor was there
for the case when x,y is in meters and z is in feet)
or
-skipping the conversion (that may be complicated)
Are there any other modules that could be negatively affected by this conversion?
For example, d.measure returns distances in meters, but it says "meters", so there is no
confusion, although the manual says "Line lengths are stated in the same units as
those of the current LOCATION", so for those who read the manual there is confusion.
On the other hand r.profile clearly states that it outputs the profile length
in meters (I assume that it uses G_begin_distance_calculations() too).
Moreover, if there are programs that output the distance without writing the unit,
e.g. piping it to another program, the automatic conversion may cause problems.
I really wish that feet and similar obscure units would go away but it seems that
we will have to deal with them for a while as the newest LIDAR-based DEMs and flood
maps in my state are all published in feet.
thank you for any help with this,
Helena
From hamish_nospam at yahoo.com Wed Jan 28 21:43:41 2004
From: hamish_nospam at yahoo.com (Hamish)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] Testing Grass 5.3
In-Reply-To: <16392.37683.973560.603265@cerise.nosuchdomain.co.uk>
References: <200401161101.i0GB11S19807@grass.itc.it>
<16392.37683.973560.603265@cerise.nosuchdomain.co.uk>
Message-ID: <20040129154341.1c9dc2b9.hamish_nospam@yahoo.com>
> > 2. A small annoying item with r.colors under tcltk. If you check the
> >
> > 'rules' box, nothing happens. It **should** go to a terminal screen
> > and allow you to enter a set of color rules. This is what happens if
> > you use r.color via the terminal command line.
>
> Whether or not to use an xterm is set on a per-module basis; it isn't
> possible to only use one when certain options are used. So, we need to
> enable the use of an xterm always.
For now I just removed the "color=rules" option from the menu. There
should be a message displayed telling the user they can use the command
line if they want to do something more complicated, but I don't know how
to do that..
> Also, the tcltkgrass interface doesn't support the use of the rast=
> option.
Added. Also added some missing color= options.
Hamish
From michael.barton at asu.edu Thu Jan 29 00:13:45 2004
From: michael.barton at asu.edu (Michael Barton)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] Testing Grass 5.3
In-Reply-To: <20040129154341.1c9dc2b9.hamish_nospam@yahoo.com>
Message-ID:
Hamish
Thanks. This will be an improvement to the menu. Thinking about it, is
it possible to do a r.colors ... colors=rules from the tcltk menu if it
is a separate menu selection (i.e., with its own dialog)?
Michael Barton
On Wednesday, January 28, 2004, at 07:43 PM, Hamish wrote:
>>> 2. A small annoying item with r.colors under tcltk. If you check the
>>>
>>> 'rules' box, nothing happens. It **should** go to a terminal screen
>>> and allow you to enter a set of color rules. This is what happens if
>>> you use r.color via the terminal command line.
>>
>> Whether or not to use an xterm is set on a per-module basis; it isn't
>> possible to only use one when certain options are used. So, we need to
>> enable the use of an xterm always.
>
> For now I just removed the "color=rules" option from the menu. There
> should be a message displayed telling the user they can use the command
> line if they want to do something more complicated, but I don't know
> how
> to do that..
>
>
>> Also, the tcltkgrass interface doesn't support the use of the rast=
>> option.
>
>
> Added. Also added some missing color= options.
>
>
>
> Hamish
>
____________________
C. Michael Barton, Professor
Department of Anthropology
PO Box 872402
Arizona State University
Tempe, AZ 85287-2402
USA
Phone: 480-965-6262
Fax: 480-965-7671
From michael.barton at asu.edu Thu Jan 29 00:20:17 2004
From: michael.barton at asu.edu (Michael Barton)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] Testing Grass 5.3 - v.transform
In-Reply-To: <200401190854.i0J8sc526655@janacek.itc.it>
Message-ID:
Radim
Just wanted to let you know. I tested v.transform by typing in the name
of a binary vector file (the browse button looks in the dig_ascii
instead of dig folder). It worked just fine. Thanks for the tip.
Michael
On Monday, January 19, 2004, at 01:54 AM, Radim Blazek wrote:
> On Friday 16 January 2004 17:13, Michael Barton wrote:
>> As with GRASS 5.7, I've been doing considerable testing of GRASS 5.3.
>> Overall, it is highly stable and works very well. Here are a couple of
>> minor items that perhaps could be fixed before it is released as
>> stable.
>>
>> 1. v.transform does not operate correctly, at least under Mac OSX. It
>> requires an ASCII vector file as input, looks in the dig_ASCII folder,
>> but will not recognize an ASCII vector file unless it is put (manually
>> and incorrectly) into the dig folder. It produces an incomplete output
>> file (header and attributes, but no vectors). This was a problem on an
>> earlier release; I have tried this on the the 12 January CVS snapshot
>> and it is still a problem.
>
> v.transform was rewritten to read and write vector binary file.
>
>
> Radim
>
____________________
C. Michael Barton, Professor
Department of Anthropology
PO Box 872402
Arizona State University
Tempe, AZ 85287-2402
USA
Phone: 480-965-6262
Fax: 480-965-7671
From michael.barton at asu.edu Thu Jan 29 00:40:50 2004
From: michael.barton at asu.edu (Michael Barton)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] question about status of grass 5.0.3 for windows
Message-ID:
I just tried to 'upgrade' a slightly older cygwin/wingrass installation
with new grass 5.0.3 binaries today and it wouldn't start. I was in a
hurry and didn't copy down the error message, but will do so if someone
wants to know it. It had to do with "lock.exe" and couldn't find
something in a cygwin.dll.
What I want to know is does anyone know the status of these binaries? I
remember reading something a week or two back about one set of binaries
being broken and being replaced. I downloaded these last week from the
site.
My Cygwin installation dates to last August, so I will update it and
try again. I don't use Windows much or Cygwin, but am trying to get
this set up for my students who do. I'm using the xwindows version of
the binaries and following the directions on the winGRASS binary site.
My main question is am I wasting my time and should revert to the
previous version. (And if so, where can I get a copy of the previous
binaries to distribute to others). Or have these been stable for other
people and I just need to work with them a bit?
Thanks for any advice.
Michael Barton
____________________
C. Michael Barton, Professor
Department of Anthropology
PO Box 872402
Arizona State University
Tempe, AZ 85287-2402
USA
Phone: 480-965-6262
Fax: 480-965-7671
From hamish_nospam at yahoo.com Wed Jan 28 19:20:14 2004
From: hamish_nospam at yahoo.com (Hamish)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] Re: [GRASSLIST:2373] Re:Re: grass57 compilation error
In-Reply-To:
References:
Message-ID: <20040129132014.65333995.hamish_nospam@yahoo.com>
> > > compiling grass57_exp_2004_01_17 in debian3.0.x woody i get the
> > > following error:
...
> > > direction.h:46: ostream: No such file or directory
...
> > The recent updates to r.terraflow introduced a new problem with
> > gcc <= 3.x. What gcc verison do you use?
...
> my gcc version is:
> gcc version 2.95.4 20011002 (Debian prerelease)
Fixed in CVS, should work for any gcc from 2.95 to 3.3 now.
gcc 2.95 has forward compatible headers for all the other include's[*],
but not ostream.h. So we still get ~four "depreciated" warnings when
compiled with gcc 3.3, but that's better than it not working at all with
gcc 2.95.
[*] i.e. gcc's fault, not any particular linux distro's, AFAICT.
We may have to think of something else if gcc 3.4 drops backwards
compatibility.
by the way, does it *really* only compile with gcc/g++? What's the
problem exactly?
Hamish
From otto.dassau at gmx.de Thu Jan 29 05:13:21 2004
From: otto.dassau at gmx.de (Otto Dassau)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] Error compiling g57
Message-ID: <4018DCC1.D83D576C@gmx.de>
Dear Developers,
Error compiling g57:
the v.kernel module doesn't compile. I downloaded and compiled this
morning
from CVS.
Otto
###### error message #########
make[2]: Wechsel in das Verzeichnis Verzeichnis
?/home/dassau/software/grass57/vector/v.kernel?
gcc -I/home/dassau/software/grass57/include
-I/home/dassau/software/grass57/dist.i686-pc-linux-gnu/include -g -Wall
-Wall -Wconversion -Wno-implicit-int -I/usr/local/include
-DUSE_GDAL_H
-I/usr/local/pgsql/include -I/home/dassau/software/grass57/include
-I/home/dassau/software/grass57/dist.i686-pc-linux-gnu/include \
-o OBJ.i686-pc-linux-gnu/main.o -c main.c
main.c: In function `main':
main.c:213: parse error before `double'
main.c:218: `n' undeclared (first use in this function)
main.c:218: (Each undeclared identifier is reported only once
main.c:218: for each function it appears in.)
main.c:219: `resL' undeclared (first use in this function)
main.c:220: `sigmaConv' undeclared (first use in this function)
main.c:222: `ii' undeclared (first use in this function)
main.c:223: `smooth' undeclared (first use in this function)
main.c:239: `L' undeclared (first use in this function)
main.c:51: warning: unused variable `gausmax'
main.c:43: warning: unused variable `term2'
main.c:42: warning: unused variable `term1'
main.c:37: warning: unused variable `E'
main.c:37: warning: unused variable `N'
main.c:36: warning: unused variable `gaussian'
main.c:34: warning: unused variable `col'
main.c:34: warning: unused variable `row'
main.c:252: warning: control reaches end of non-void function
main.c: At top level:
main.c:254: `sigma' undeclared here (not in a function)
main.c:254: `sigma' undeclared here (not in a function)
main.c:254: initializer element is not constant
main.c:254: warning: data definition has no type or storage class
main.c:255: `sigma' undeclared here (not in a function)
main.c:255: `sigma' undeclared here (not in a function)
main.c:255: initializer element is not constant
main.c:255: warning: data definition has no type or storage class
main.c:257: `sigma' undeclared here (not in a function)
main.c:257: initializer element is not constant
main.c:257: warning: data definition has no type or storage class
main.c:259: parse error before `if'
main.c:266: conflicting types for `Points'
main.c:261: previous declaration of `Points'
main.c:266: warning: initialization makes integer from pointer without a
cast
main.c:266: initializer element is not constant
main.c:266: warning: data definition has no type or storage class
main.c:267: conflicting types for `SPoints'
main.c:261: previous declaration of `SPoints'
main.c:267: warning: initialization makes integer from pointer without a
cast
main.c:267: initializer element is not constant
main.c:267: warning: data definition has no type or storage class
main.c:268: conflicting types for `SCats'
main.c:262: previous declaration of `SCats'
main.c:268: warning: initialization makes integer from pointer without a
cast
main.c:268: initializer element is not constant
main.c:268: warning: data definition has no type or storage class
main.c:270: `Net' undeclared here (not in a function)
main.c:270: initializer element is not constant
main.c:270: warning: data definition has no type or storage class
main.c:271: parse error before `3'
main.c:271: warning: data definition has no type or storage class
main.c:277: `Net' undeclared here (not in a function)
main.c:277: `line' undeclared here (not in a function)
main.c:277: warning: passing arg 2 of `Vect_read_line' makes pointer
from
integer without a cast
main.c:277: initializer element is not constant
main.c:277: warning: data definition has no type or storage class
main.c:278: parse error before `if'
main.c:280: conflicting types for `length'
main.c:275: previous declaration of `length'
main.c:280: warning: passing arg 1 of `Vect_line_length' makes pointer
from
integer without a cast
main.c:280: initializer element is not constant
main.c:280: warning: data definition has no type or storage class
main.c:281: `segmax' undeclared here (not in a function)
main.c:281: warning: data definition has no type or storage class
main.c:282: redefinition of `length'
main.c:280: `length' previously defined here
main.c:282: initializer element is not constant
main.c:282: warning: data definition has no type or storage class
main.c:284: parse error before `3'
main.c:284: warning: data definition has no type or storage class
main.c:289: `seg' undeclared here (not in a function)
main.c:289: initializer element is not constant
main.c:289: warning: data definition has no type or storage class
main.c:290: parse error before `&'
main.c:292: parse error before `3'
main.c:292: warning: data definition has no type or storage class
main.c:294: parse error before `&'
main.c:294: conflicting types for `compute_net_distance'
global.h:18: previous declaration of `compute_net_distance'
main.c:294: warning: data definition has no type or storage class
main.c:295: parse error before `*='
main.c:298: parse error before `3'
main.c:298: warning: data definition has no type or storage class
main.c:303: `seg' undeclared here (not in a function)
main.c:303: initializer element is not constant
main.c:303: warning: data definition has no type or storage class
main.c:304: warning: parameter names (without types) in function
declaration
main.c:304: warning: data definition has no type or storage class
main.c:306: warning: parameter names (without types) in function
declaration
main.c:306: warning: data definition has no type or storage class
main.c:307: parse error before `1'
main.c:309: parse error before `&'
main.c:309: conflicting types for `Vect_write_line'
/home/dassau/software/grass57/include/Vect.h:158: previous declaration
of
`Vect_write_line'
main.c:309: warning: data definition has no type or storage class
main.c:314: parse error before `&'
main.c:314: warning: data definition has no type or storage class
main.c:316: parse error before `&'
main.c:316: warning: data definition has no type or storage class
main.c:317: parse error before `&'
main.c:317: warning: data definition has no type or storage class
main.c:336: `row' undeclared here (not in a function)
main.c:336: `window' undeclared here (not in a function)
main.c:336: initializer element is not constant
main.c:336: warning: data definition has no type or storage class
main.c:337: `col' undeclared here (not in a function)
main.c:337: `window' undeclared here (not in a function)
main.c:337: initializer element is not constant
main.c:337: warning: data definition has no type or storage class
main.c:339: parse error before `&'
main.c:339: conflicting types for `compute_distance'
global.h:16: previous declaration of `compute_distance'
main.c:339: warning: data definition has no type or storage class
main.c:340: `col' undeclared here (not in a function)
main.c:340: variable `output_cell' has initializer but incomplete type
main.c:340: `multip' undeclared here (not in a function)
main.c:340: `gaussian' undeclared here (not in a function)
main.c:340: warning: data definition has no type or storage class
main.c:341: parse error before `if'
main.c:343: parse error before `2'
main.c:343: warning: data definition has no type or storage class
main.c:346: warning: parameter names (without types) in function
declaration
main.c:346: warning: data definition has no type or storage class
main.c:347: parse error before `}'
main.c:349: parse error before string constant
main.c:349: warning: data definition has no type or storage class
main.c:351: parse error before `&'
main.c:351: warning: data definition has no type or storage class
main.c:353: parse error before `0'
main.c:353: conflicting types for `exit'
/usr/include/stdlib.h:577: previous declaration of `exit'
main.c:353: warning: data definition has no type or storage class
main.c: In function `read_points':
main.c:368: warning: passing arg 1 of `calloc' as unsigned due to
prototype
main.c: In function `compute_all_distances':
main.c:396: warning: passing arg 1 of `calloc' as unsigned due to
prototype
main.c: In function `compute_all_net_distances':
main.c:433: warning: passing arg 1 of `calloc' as unsigned due to
prototype
main.c: At top level:
main.c:489: conflicting types for `compute_net_distance'
main.c:294: previous declaration of `compute_net_distance'
main.c:539: conflicting types for `compute_distance'
main.c:339: previous declaration of `compute_distance'
make[2]: *** [OBJ.i686-pc-linux-gnu/main.o] Fehler 1
make[2]: Verlassen des Verzeichnisses Verzeichnis
?/home/dassau/software/grass57/vector/v.kernel?
make[1]: *** [subdirs] Fehler 1
make[1]: Verlassen des Verzeichnisses Verzeichnis
?/home/dassau/software/grass57/vector?
make: *** [default] Fehler 1
From glynn.clements at virgin.net Thu Jan 29 06:05:01 2004
From: glynn.clements at virgin.net (Glynn Clements)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] question about status of grass 5.0.3 for windows
In-Reply-To:
References:
Message-ID: <16408.59613.874180.285318@cerise.nosuchdomain.co.uk>
Michael Barton wrote:
> I just tried to 'upgrade' a slightly older cygwin/wingrass installation
> with new grass 5.0.3 binaries today and it wouldn't start. I was in a
> hurry and didn't copy down the error message, but will do so if someone
> wants to know it. It had to do with "lock.exe" and couldn't find
> something in a cygwin.dll.
Please let us know the exact message when you can.
> What I want to know is does anyone know the status of these binaries? I
> remember reading something a week or two back about one set of binaries
> being broken and being replaced. I downloaded these last week from the
> site.
That was regarding NVIZ, which is often mis-compiled on Cygwin (unless
the right configure switches are used, it will normally build with
Cygwin's Tcl/Tk, which won't work).
> My Cygwin installation dates to last August, so I will update it and
> try again. I don't use Windows much or Cygwin, but am trying to get
> this set up for my students who do. I'm using the xwindows version of
> the binaries and following the directions on the winGRASS binary site.
>
> My main question is am I wasting my time and should revert to the
> previous version.
It's hard to say without seeing the exact error message.
--
Glynn Clements
From glynn.clements at virgin.net Thu Jan 29 06:00:13 2004
From: glynn.clements at virgin.net (Glynn Clements)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] Testing Grass 5.3
In-Reply-To:
References: <20040129154341.1c9dc2b9.hamish_nospam@yahoo.com>
Message-ID: <16408.59325.844852.898066@cerise.nosuchdomain.co.uk>
Michael Barton wrote:
> > For now I just removed the "color=rules" option from the menu. There
> > should be a message displayed telling the user they can use the command
> > line if they want to do something more complicated, but I don't know
> > how
> > to do that..
>
> Thanks. This will be an improvement to the menu. Thinking about it, is
> it possible to do a r.colors ... colors=rules from the tcltk menu if it
> is a separate menu selection (i.e., with its own dialog)?
Yes. There are already separate entries for "v.support option=build"
and "v.support option=edit".
The following module file should suffice:
interface_build {
{r.colors color=rules} 1
{Creates/Modifies the color table from a list of rules.}
{entry map {Raster map:} 0 raster}
{separator grey 1}
{checkbox -w {Don't overwrite existing color table.} "" -w}
{checkbox -q {Run quietly.} "" -q}
}
--
Glynn Clements
From glynn.clements at virgin.net Thu Jan 29 05:51:59 2004
From: glynn.clements at virgin.net (Glynn Clements)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] r.slope.aspect in feet
In-Reply-To: <4018670F.8010806@unity.ncsu.edu>
References: <4018670F.8010806@unity.ncsu.edu>
Message-ID: <16408.58831.66439.514228@cerise.nosuchdomain.co.uk>
Helena wrote:
> Before GRASS5.3 is released I would like to point out that
> if the data are in a coordinate system that uses feet
> r.slope.aspect quietly converts x,y to meters while leaving z in feet
> leading to greatly exagerrated slopes.
> I looked into the code and it seems that
> G_begin_distance_calculations(), G_distance,
> automatically converts to meters.
>
> Is this a desired behavior? If yes, r.slope.aspect should return a warning
> as there is no way for the user to know that r.slope.aspect is converting
> x,y to meters which means it is the users responsibility
> to convert z to meters using zfactor, which is slightly indicated in help
> and in manual but it is not really clear. Should this be fixed by
> -adding the warning (and a sentence in manual that elevation MUST
> be converted to meters by zfactor, now it sounds as if zfactor was there
> for the case when x,y is in meters and z is in feet)
>
> or
>
> -skipping the conversion (that may be complicated)
Probably neither.
GRASS knows what the X/Y units are from the PROJ_UNITS file. It
doesn't know what the Z units are, so it either has to be told or it
has to make an assumption.
I'm not sure that assuming that the Z units match the X/Y units is an
improvement over consistently assuming that the Z units are metres.
There is also the fact that, as the historical behaviour is to assume
metres, changing it to assume either feet or metres depending upon
PROJ_UNITS would break compatibility. Worse, it could result in
existing scripts suddenly giving wrong answers.
The least problematic fix would be to change:
parm.zfactor->required = NO;
to:
parm.zfactor->required = YES;
That would force the user to specify the units, eliminating the need
for any assumptions. Existing scripts would fail, but would do so
visibly.
--
Glynn Clements
From blazek at itc.it Thu Jan 29 06:11:00 2004
From: blazek at itc.it (Radim Blazek)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] Error compiling g57
In-Reply-To: <4018DCC1.D83D576C@gmx.de>
References: <4018DCC1.D83D576C@gmx.de>
Message-ID: <200401291111.i0TBB0b24661@janacek.itc.it.>
Yes,
we have found that as well, v.kernel does not compile with gcc2.*.
Stefano Menegon, original author of v.kernel, promised to solve this
until tomorrow (Italian tomorrow).
I'l remove v.kernel from vector/Makefile for now, do the same in your local copy.
Radim
On Thursday 29 January 2004 11:13, Otto Dassau wrote:
> Dear Developers,
>
> Error compiling g57:
>
> the v.kernel module doesn't compile. I downloaded and compiled this
> morning
> from CVS.
>
> Otto
>
> ###### error message #########
>
> make[2]: Wechsel in das Verzeichnis Verzeichnis
> ?/home/dassau/software/grass57/vector/v.kernel?
> gcc -I/home/dassau/software/grass57/include
> -I/home/dassau/software/grass57/dist.i686-pc-linux-gnu/include -g -Wall
> -Wall -Wconversion -Wno-implicit-int -I/usr/local/include
> -DUSE_GDAL_H
> -I/usr/local/pgsql/include -I/home/dassau/software/grass57/include
> -I/home/dassau/software/grass57/dist.i686-pc-linux-gnu/include \
> -o OBJ.i686-pc-linux-gnu/main.o -c main.c
> main.c: In function `main':
> main.c:213: parse error before `double'
> main.c:218: `n' undeclared (first use in this function)
> main.c:218: (Each undeclared identifier is reported only once
> main.c:218: for each function it appears in.)
> main.c:219: `resL' undeclared (first use in this function)
> main.c:220: `sigmaConv' undeclared (first use in this function)
> main.c:222: `ii' undeclared (first use in this function)
> main.c:223: `smooth' undeclared (first use in this function)
> main.c:239: `L' undeclared (first use in this function)
> main.c:51: warning: unused variable `gausmax'
> main.c:43: warning: unused variable `term2'
> main.c:42: warning: unused variable `term1'
> main.c:37: warning: unused variable `E'
> main.c:37: warning: unused variable `N'
> main.c:36: warning: unused variable `gaussian'
> main.c:34: warning: unused variable `col'
> main.c:34: warning: unused variable `row'
> main.c:252: warning: control reaches end of non-void function
> main.c: At top level:
> main.c:254: `sigma' undeclared here (not in a function)
> main.c:254: `sigma' undeclared here (not in a function)
> main.c:254: initializer element is not constant
> main.c:254: warning: data definition has no type or storage class
> main.c:255: `sigma' undeclared here (not in a function)
> main.c:255: `sigma' undeclared here (not in a function)
> main.c:255: initializer element is not constant
> main.c:255: warning: data definition has no type or storage class
> main.c:257: `sigma' undeclared here (not in a function)
> main.c:257: initializer element is not constant
> main.c:257: warning: data definition has no type or storage class
> main.c:259: parse error before `if'
> main.c:266: conflicting types for `Points'
> main.c:261: previous declaration of `Points'
> main.c:266: warning: initialization makes integer from pointer without a
> cast
> main.c:266: initializer element is not constant
> main.c:266: warning: data definition has no type or storage class
> main.c:267: conflicting types for `SPoints'
> main.c:261: previous declaration of `SPoints'
> main.c:267: warning: initialization makes integer from pointer without a
> cast
> main.c:267: initializer element is not constant
> main.c:267: warning: data definition has no type or storage class
> main.c:268: conflicting types for `SCats'
> main.c:262: previous declaration of `SCats'
> main.c:268: warning: initialization makes integer from pointer without a
> cast
> main.c:268: initializer element is not constant
> main.c:268: warning: data definition has no type or storage class
> main.c:270: `Net' undeclared here (not in a function)
> main.c:270: initializer element is not constant
> main.c:270: warning: data definition has no type or storage class
> main.c:271: parse error before `3'
> main.c:271: warning: data definition has no type or storage class
> main.c:277: `Net' undeclared here (not in a function)
> main.c:277: `line' undeclared here (not in a function)
> main.c:277: warning: passing arg 2 of `Vect_read_line' makes pointer
> from
> integer without a cast
> main.c:277: initializer element is not constant
> main.c:277: warning: data definition has no type or storage class
> main.c:278: parse error before `if'
> main.c:280: conflicting types for `length'
> main.c:275: previous declaration of `length'
> main.c:280: warning: passing arg 1 of `Vect_line_length' makes pointer
> from
> integer without a cast
> main.c:280: initializer element is not constant
> main.c:280: warning: data definition has no type or storage class
> main.c:281: `segmax' undeclared here (not in a function)
> main.c:281: warning: data definition has no type or storage class
> main.c:282: redefinition of `length'
> main.c:280: `length' previously defined here
> main.c:282: initializer element is not constant
> main.c:282: warning: data definition has no type or storage class
> main.c:284: parse error before `3'
> main.c:284: warning: data definition has no type or storage class
> main.c:289: `seg' undeclared here (not in a function)
> main.c:289: initializer element is not constant
> main.c:289: warning: data definition has no type or storage class
> main.c:290: parse error before `&'
> main.c:292: parse error before `3'
> main.c:292: warning: data definition has no type or storage class
> main.c:294: parse error before `&'
> main.c:294: conflicting types for `compute_net_distance'
> global.h:18: previous declaration of `compute_net_distance'
> main.c:294: warning: data definition has no type or storage class
> main.c:295: parse error before `*='
> main.c:298: parse error before `3'
> main.c:298: warning: data definition has no type or storage class
> main.c:303: `seg' undeclared here (not in a function)
> main.c:303: initializer element is not constant
> main.c:303: warning: data definition has no type or storage class
> main.c:304: warning: parameter names (without types) in function
> declaration
> main.c:304: warning: data definition has no type or storage class
> main.c:306: warning: parameter names (without types) in function
> declaration
> main.c:306: warning: data definition has no type or storage class
> main.c:307: parse error before `1'
> main.c:309: parse error before `&'
> main.c:309: conflicting types for `Vect_write_line'
> /home/dassau/software/grass57/include/Vect.h:158: previous declaration
> of
> `Vect_write_line'
> main.c:309: warning: data definition has no type or storage class
> main.c:314: parse error before `&'
> main.c:314: warning: data definition has no type or storage class
> main.c:316: parse error before `&'
> main.c:316: warning: data definition has no type or storage class
> main.c:317: parse error before `&'
> main.c:317: warning: data definition has no type or storage class
> main.c:336: `row' undeclared here (not in a function)
> main.c:336: `window' undeclared here (not in a function)
> main.c:336: initializer element is not constant
> main.c:336: warning: data definition has no type or storage class
> main.c:337: `col' undeclared here (not in a function)
> main.c:337: `window' undeclared here (not in a function)
> main.c:337: initializer element is not constant
> main.c:337: warning: data definition has no type or storage class
> main.c:339: parse error before `&'
> main.c:339: conflicting types for `compute_distance'
> global.h:16: previous declaration of `compute_distance'
> main.c:339: warning: data definition has no type or storage class
> main.c:340: `col' undeclared here (not in a function)
> main.c:340: variable `output_cell' has initializer but incomplete type
> main.c:340: `multip' undeclared here (not in a function)
> main.c:340: `gaussian' undeclared here (not in a function)
> main.c:340: warning: data definition has no type or storage class
> main.c:341: parse error before `if'
> main.c:343: parse error before `2'
> main.c:343: warning: data definition has no type or storage class
> main.c:346: warning: parameter names (without types) in function
> declaration
> main.c:346: warning: data definition has no type or storage class
> main.c:347: parse error before `}'
> main.c:349: parse error before string constant
> main.c:349: warning: data definition has no type or storage class
> main.c:351: parse error before `&'
> main.c:351: warning: data definition has no type or storage class
> main.c:353: parse error before `0'
> main.c:353: conflicting types for `exit'
> /usr/include/stdlib.h:577: previous declaration of `exit'
> main.c:353: warning: data definition has no type or storage class
> main.c: In function `read_points':
> main.c:368: warning: passing arg 1 of `calloc' as unsigned due to
> prototype
> main.c: In function `compute_all_distances':
> main.c:396: warning: passing arg 1 of `calloc' as unsigned due to
> prototype
> main.c: In function `compute_all_net_distances':
> main.c:433: warning: passing arg 1 of `calloc' as unsigned due to
> prototype
> main.c: At top level:
> main.c:489: conflicting types for `compute_net_distance'
> main.c:294: previous declaration of `compute_net_distance'
> main.c:539: conflicting types for `compute_distance'
> main.c:339: previous declaration of `compute_distance'
> make[2]: *** [OBJ.i686-pc-linux-gnu/main.o] Fehler 1
> make[2]: Verlassen des Verzeichnisses Verzeichnis
> ?/home/dassau/software/grass57/vector/v.kernel?
> make[1]: *** [subdirs] Fehler 1
> make[1]: Verlassen des Verzeichnisses Verzeichnis
> ?/home/dassau/software/grass57/vector?
> make: *** [default] Fehler 1
>
> _______________________________________________
> grass5 mailing list
> grass5@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5
From paul-grass at stjohnspoint.co.uk Thu Jan 29 06:26:01 2004
From: paul-grass at stjohnspoint.co.uk (Paul Kelly)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] Re: [GRASSLIST:2373] Re:Re: grass57 compilation error
In-Reply-To: <20040129132014.65333995.hamish_nospam@yahoo.com>
References:
<20040129132014.65333995.hamish_nospam@yahoo.com>
Message-ID:
On Thu, 29 Jan 2004, Hamish wrote:
> by the way, does it *really* only compile with gcc/g++? What's the
> problem exactly?
See http://grass.itc.it/pipermail/grass5/2003-February/007312.html for
ther errors when I tried the original version in GRASS with IRIX 6.2 CC
(C++ compiler).
Now it is much simpler:
(compiling with gmake53 because r.terraflow doesn't work with the new
build system)
SRC = /indigo-disk2/grass/grass/src
CMD = /indigo-disk2/grass/grass/src/CMD
UNUSED = /indigo-disk2/grass/grass/unused
HEADER = head.mips-sgi-irix6.2
ARCH = mips-sgi-irix6.2
GISBASE = /indigo-disk2/grass/grass/dist.mips-sgi-irix6.2
VERSION = 5.3-cvs 2003
#################################################################
/indigo-disk2/grass/grass/src.contrib/DUKE/r.terraflow
make -f OBJ.mips-sgi-irix6.2/make.rules
mkdir OBJ.mips-sgi-irix6.2/FLOAT ; true
mkdir: cannot create directory `OBJ.mips-sgi-irix6.2/FLOAT': File exists
mkdir OBJ.mips-sgi-irix6.2/SHORT ; true
mkdir: cannot create directory `OBJ.mips-sgi-irix6.2/SHORT': File exists
CC -c -I/indigo-disk2/grass/grass/src/include -I/usr/local/include -g -I/usr/local/include -I./IOStream/include -DUSER=\"paulk\" -DNODATA_FIX -D_FILE_OFFSET_BITS=64 -DELEV_FLOAT main.cc -o OBJ.mips-sgi-irix6.2/FLOAT/main.o
"common.h", line 46: error(4003): could not open source file "iostream"
#include
^
1 catastrophic error detected in the compilation of "main.cc".
Compilation terminated.
make: *** [OBJ.mips-sgi-irix6.2/FLOAT/main.o] Error 1
From neteler at itc.it Thu Jan 29 08:01:36 2004
From: neteler at itc.it (Markus Neteler)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] Testing Grass 5.3 - v.transform
In-Reply-To:
References: <200401190854.i0J8sc526655@janacek.itc.it>
Message-ID: <20040129130136.GB17393@thuille.itc.it>
On Wed, Jan 28, 2004 at 10:20:17PM -0700, Michael Barton wrote:
> Radim
>
> Just wanted to let you know. I tested v.transform by typing in the name
> of a binary vector file (the browse button looks in the dig_ascii
> instead of dig folder). It worked just fine. Thanks for the tip.
Michael,
this is not clear to me:
src/mapdev/v.transform/main.c
[...]
old->gisprompt = "old,dig,vector";
The version in 5.3-CVS refers to the dig file.
Where did you find the reference to dig_ascii? Maybe in 5.0.3?
Markus
>
> On Monday, January 19, 2004, at 01:54 AM, Radim Blazek wrote:
>
> >On Friday 16 January 2004 17:13, Michael Barton wrote:
> >>As with GRASS 5.7, I've been doing considerable testing of GRASS 5.3.
> >>Overall, it is highly stable and works very well. Here are a couple of
> >>minor items that perhaps could be fixed before it is released as
> >>stable.
> >>
> >>1. v.transform does not operate correctly, at least under Mac OSX. It
> >>requires an ASCII vector file as input, looks in the dig_ASCII folder,
> >>but will not recognize an ASCII vector file unless it is put (manually
> >>and incorrectly) into the dig folder. It produces an incomplete output
> >>file (header and attributes, but no vectors). This was a problem on an
> >>earlier release; I have tried this on the the 12 January CVS snapshot
> >>and it is still a problem.
> >
> >v.transform was rewritten to read and write vector binary file.
> >
> >
> >Radim
> >
> ____________________
> C. Michael Barton, Professor
> Department of Anthropology
> PO Box 872402
> Arizona State University
> Tempe, AZ 85287-2402
> USA
>
> Phone: 480-965-6262
> Fax: 480-965-7671
>
> _______________________________________________
> grass5 mailing list
> grass5@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5
From mlennert at club.worldonline.be Thu Jan 29 08:18:03 2004
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] GRASS57: debian package build : dead symbolic links
to 5.3 sources
In-Reply-To: <20040128144647.GI10611@thuille.itc.it>
References: <34615.164.15.134.155.1075217110.squirrel@moritz.homelinux.org>
<20040127153252.GD3741@thuille.itc.it>
<36297.164.15.134.155.1075287321.squirrel@moritz.homelinux.org>
<20040128144647.GI10611@thuille.itc.it>
Message-ID: <40226.164.15.134.155.1075382283.squirrel@moritz.homelinux.org>
Markus Neteler said:
> On Wed, Jan 28, 2004 at 11:55:21AM +0100, Moritz Lennert wrote:
>> Markus Neteler said:
>> > On Tue, Jan 27, 2004 at 04:25:10PM +0100, Moritz Lennert wrote:
>> >> Hello,
>> >> I am trying to use dpkg-buildpackage on 5.7. However, I have the
>> following
>> >> problem:
>> >> in debian/rules the following defines the location of the 5.3
>> sources:
>> GRASS53SRC=../grass-5.3.0
>> >> this is correct for me as I have:
>> >> $ ls -l
>> >> total 20
>> >> drwxr-xr-x 23 mlennert mlennert 4096 2004-01-05 15:40 grass
>> drwxr-xr-x 21 mlennert mlennert 4096 2004-01-27 16:10 grass51
>> lrwxrwxrwx 1 mlennert mlennert 5 2004-01-27 15:24 grass-5.3.0
>> ->
>> >> grass
>> >> lrwxrwxrwx 1 mlennert mlennert 7 2004-01-27 15:24
>> grass-5.7.0 ->
>> >> grass51
>> >> However, in grass-5.7.0/include I have a series of dead links
>> pointing to
>> >> ../grass-5.3.0/src/include/*.h
>> >> This should be ../../grass-5.3.0/src/include/*.h
>> >> Where can I change the links that are created ?
>> >
>> > In grass51/debian/rules you find the configuration. It seems,
>> > that
>> > - the link trick above doesn't work with 'make mix' done in
>> > grass51/debian/rules
>> > - something else not right.
>> >
>> > Did you try to rename the dirs instead of linking?
>>
>> I did and it doesn't work either, i.e. the links in grass-5.7.0/include
>> are again to ../grass-5.3.0 and not to ../../grass-5.3.0.
>>
>> I solved the problem by replacing the relative path for
>>
>> #path to GRASS 5.3 source code
>> GRASS53SRC=
>>
>> to an absolute path.
>
> Ah, now I understand: Maybe it depends in which directory you
> launch 'dpkg-buildpackage'
> ?
I thought that you always have to launch it in the directory in which
there is a debian/ subdirectory ?
> Do you think I should change it to an absolute path?
The absolute path will be different for everyone, so I don't know how this
could be done without manual intervention. Maybe a hint in a README.Debian
would be better ?
Moritz
From neteler at itc.it Thu Jan 29 08:31:46 2004
From: neteler at itc.it (Markus Neteler)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] GRASS57: debian package build : dead symbolic links to 5.3 sources
In-Reply-To: <40226.164.15.134.155.1075382283.squirrel@moritz.homelinux.org>
References: <34615.164.15.134.155.1075217110.squirrel@moritz.homelinux.org> <20040127153252.GD3741@thuille.itc.it> <36297.164.15.134.155.1075287321.squirrel@moritz.homelinux.org> <20040128144647.GI10611@thuille.itc.it> <40226.164.15.134.155.1075382283.squirrel@moritz.homelinux.org>
Message-ID: <20040129133146.GF17393@thuille.itc.it>
On Thu, Jan 29, 2004 at 02:18:03PM +0100, Moritz Lennert wrote:
> Markus Neteler said:
> > On Wed, Jan 28, 2004 at 11:55:21AM +0100, Moritz Lennert wrote:
> >> Markus Neteler said:
> >> > On Tue, Jan 27, 2004 at 04:25:10PM +0100, Moritz Lennert wrote:
> >> >> Hello,
> >> >> I am trying to use dpkg-buildpackage on 5.7. However, I have the
[...]
> >>
> >> I solved the problem by replacing the relative path for
> >>
> >> #path to GRASS 5.3 source code
> >> GRASS53SRC=
> >>
> >> to an absolute path.
> >
> > Ah, now I understand: Maybe it depends in which directory you
> > launch 'dpkg-buildpackage'
> > ?
>
> I thought that you always have to launch it in the directory in which
> there is a debian/ subdirectory ?
Yes, at least that is what I was doing (and it worked).
> > Do you think I should change it to an absolute path?
>
> The absolute path will be different for everyone, so I don't know how this
> could be done without manual intervention. Maybe a hint in a README.Debian
> would be better ?
Someone else (debian developer) recommended
mkdir /usr/src/grass/
cd /usr/src/grass/
to me. This path is now hardcoded in debian/rules.
If following the instructions, it should be fine now.
[Yes, it's not convenient, yes, code should be merged (but not downgraded)].
Markus
From mlennert at club.worldonline.be Thu Jan 29 09:44:18 2004
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] GRASS57: debian package build : dead symbolic links
to 5.3 sources
In-Reply-To: <20040129133146.GF17393@thuille.itc.it>
References: <34615.164.15.134.155.1075217110.squirrel@moritz.homelinux.org>
<20040127153252.GD3741@thuille.itc.it>
<36297.164.15.134.155.1075287321.squirrel@moritz.homelinux.org>
<20040128144647.GI10611@thuille.itc.it>
<40226.164.15.134.155.1075382283.squirrel@moritz.homelinux.org>
<20040129133146.GF17393@thuille.itc.it>
Message-ID: <40363.164.15.134.155.1075387458.squirrel@moritz.homelinux.org>
Markus Neteler said:
> On Thu, Jan 29, 2004 at 02:18:03PM +0100, Moritz Lennert wrote:
>> Markus Neteler said:
>> > On Wed, Jan 28, 2004 at 11:55:21AM +0100, Moritz Lennert wrote:
>> >> Markus Neteler said:
>> >> > On Tue, Jan 27, 2004 at 04:25:10PM +0100, Moritz Lennert wrote:
>> >> >> Hello,
>> >> >> I am trying to use dpkg-buildpackage on 5.7. However, I have the
> [...]
>> >>
>> >> I solved the problem by replacing the relative path for
>> >>
>> >> #path to GRASS 5.3 source code
>> >> GRASS53SRC=
>> >>
>> >> to an absolute path.
>> >
>> > Ah, now I understand: Maybe it depends in which directory you
>> > launch 'dpkg-buildpackage'
>> > ?
>>
>> I thought that you always have to launch it in the directory in which
>> there is a debian/ subdirectory ?
>
> Yes, at least that is what I was doing (and it worked).
>
>> > Do you think I should change it to an absolute path?
>>
>> The absolute path will be different for everyone, so I don't know how
>> this
>> could be done without manual intervention. Maybe a hint in a
>> README.Debian
>> would be better ?
>
> Someone else (debian developer) recommended
> mkdir /usr/src/grass/
> cd /usr/src/grass/
>
> to me. This path is now hardcoded in debian/rules.
I suppose this means that I should either link to the CVS tree from
/usr/src/grass or actually move the tree to there.
> If following the instructions, it should be fine now.
It works, the only disadvantage being that you need root access to use
/usr/src/grass.
Moritz
From mlennert at club.worldonline.be Thu Jan 29 09:48:07 2004
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] grass5.7 dpkg-buildpackage: /usr/bin/grass57 defines wrong GISBASE
Message-ID: <40368.164.15.134.155.1075387687.squirrel@moritz.homelinux.org>
Hello,
In the GRASS5.7 debian package created with dpkg-buildpackage, the
launching script /usr/bin/grass57 defines GISBASE as
GISBASE=/data/CVS/GRASSCVS/grass-5.7.0/debian/tmp/usr/grass57
i.e. the build directory.
Shouldn't this be /usr/grass57 ?
Moritz
From neteler at itc.it Thu Jan 29 09:56:45 2004
From: neteler at itc.it (Markus Neteler)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] GRASS57: debian package build : dead symbolic links to 5.3 sources
In-Reply-To: <40363.164.15.134.155.1075387458.squirrel@moritz.homelinux.org>
References: <34615.164.15.134.155.1075217110.squirrel@moritz.homelinux.org> <20040127153252.GD3741@thuille.itc.it> <36297.164.15.134.155.1075287321.squirrel@moritz.homelinux.org> <20040128144647.GI10611@thuille.itc.it> <40226.164.15.134.155.1075382283.squirrel@moritz.homelinux.org> <20040129133146.GF17393@thuille.itc.it> <40363.164.15.134.155.1075387458.squirrel@moritz.homelinux.org>
Message-ID: <20040129145645.GN17393@thuille.itc.it>
On Thu, Jan 29, 2004 at 03:44:18PM +0100, Moritz Lennert wrote:
> Markus Neteler said:
> > On Thu, Jan 29, 2004 at 02:18:03PM +0100, Moritz Lennert wrote:
> >> Markus Neteler said:
> >> > On Wed, Jan 28, 2004 at 11:55:21AM +0100, Moritz Lennert wrote:
> >> >> Markus Neteler said:
> >> >> > On Tue, Jan 27, 2004 at 04:25:10PM +0100, Moritz Lennert wrote:
> >> >> >> Hello,
> >> >> >> I am trying to use dpkg-buildpackage on 5.7. However, I have the
> > [...]
> >> >>
> >> >> I solved the problem by replacing the relative path for
> >> >>
> >> >> #path to GRASS 5.3 source code
> >> >> GRASS53SRC=
> >> >>
> >> >> to an absolute path.
> >> >
> >> > Ah, now I understand: Maybe it depends in which directory you
> >> > launch 'dpkg-buildpackage'
> >> > ?
> >>
> >> I thought that you always have to launch it in the directory in which
> >> there is a debian/ subdirectory ?
> >
> > Yes, at least that is what I was doing (and it worked).
> >
> >> > Do you think I should change it to an absolute path?
> >>
> >> The absolute path will be different for everyone, so I don't know how
> >> this
> >> could be done without manual intervention. Maybe a hint in a
> >> README.Debian
> >> would be better ?
> >
> > Someone else (debian developer) recommended
> > mkdir /usr/src/grass/
> > cd /usr/src/grass/
> >
> > to me. This path is now hardcoded in debian/rules.
>
> I suppose this means that I should either link to the CVS tree from
> /usr/src/grass or actually move the tree to there.
Yes, I think so.
> > If following the instructions, it should be fine now.
>
> It works, the only disadvantage being that you need root access to use
> /usr/src/grass.
Since I have low experience with Debian, please give advice how to
find a better solution.
Up to now it was "proof of concept" (and we needed an iPAQ version of 5.7).
Markus
From stephen.clark at focus.ca Thu Jan 29 11:19:06 2004
From: stephen.clark at focus.ca (Stephen Clark)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] When will grass 5.3 and 5.7 be available in Windows 2000
References: <4018DCC1.D83D576C@gmx.de> <200401291111.i0TBB0b24661@janacek.itc.it.>
Message-ID: <001301c3e683$9e715e80$6c000a0a@sclark>
Hi all,
Is there some time frame of when grass 5.3 and 5.7 will be available for Windows 2000.
I have Cygwin installed on my machine but am not very good at using it so I thought I might wait for the Binaries to become available.
If someone has a lot of patience I could try out the Cygwin compile and install though...
My interest is in the use of GDAL and especially Shape files with the route analysis module in GRASS combined with Mapserver to display the results.
thanks,
Stephen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/grass-dev/attachments/20040129/0371bf30/attachment.html
From michael.barton at asu.edu Thu Jan 29 11:41:39 2004
From: michael.barton at asu.edu (Michael Barton)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] v.transform semi-error
In-Reply-To: <200401291447.i0TEl1S30810@grass.itc.it>
Message-ID: <02D805A6-527A-11D8-88A6-00039313C09E@asu.edu>
Markus,
Happy to try to clarify now I that I've figured out why I've been
confused. When you use v.transform from the tcltk menu system, it says
to input an ascii vector map. If you click the browse button (labeled
"vector_ascii", as is the output map name browse button), it goes to
the dig_ascii to search for a map. If you select a map from there it
appears in the dialog window. However, when you try to run v.transform
(clicking the "run" button) it says file not found.
The problem seems to be that the tcltk menu system has not been updated
to reflect changes in v.transform. In the manual, it says binary vector
file and v.transform from the command line works as specified there.
Michael
On Thursday, January 29, 2004, at 07:47 AM,
grass5-request@grass.itc.it wrote:
> From: Markus Neteler
> Date: Thu Jan 29, 2004 6:01:36 AM America/Phoenix
> To: grass5@grass.itc.it
> Subject: Re: [GRASS5] Testing Grass 5.3 - v.transform
>
>
> On Wed, Jan 28, 2004 at 10:20:17PM -0700, Michael Barton wrote:
>> Radim
>>
>> Just wanted to let you know. I tested v.transform by typing in the
>> name
>> of a binary vector file (the browse button looks in the dig_ascii
>> instead of dig folder). It worked just fine. Thanks for the tip.
>
> Michael,
>
> this is not clear to me:
>
> src/mapdev/v.transform/main.c
> [...]
> old->gisprompt = "old,dig,vector";
>
> The version in 5.3-CVS refers to the dig file.
>
> Where did you find the reference to dig_ascii? Maybe in 5.0.3?
>
> Markus
>
>
>>
>> On Monday, January 19, 2004, at 01:54 AM, Radim Blazek wrote:
>>
>>> On Friday 16 January 2004 17:13, Michael Barton wrote:
>>>> As with GRASS 5.7, I've been doing considerable testing of GRASS
>>>> 5.3.
>>>> Overall, it is highly stable and works very well. Here are a couple
>>>> of
>>>> minor items that perhaps could be fixed before it is released as
>>>> stable.
>>>>
>>>> 1. v.transform does not operate correctly, at least under Mac OSX.
>>>> It
>>>> requires an ASCII vector file as input, looks in the dig_ASCII
>>>> folder,
>>>> but will not recognize an ASCII vector file unless it is put
>>>> (manually
>>>> and incorrectly) into the dig folder. It produces an incomplete
>>>> output
>>>> file (header and attributes, but no vectors). This was a problem on
>>>> an
>>>> earlier release; I have tried this on the the 12 January CVS
>>>> snapshot
>>>> and it is still a problem.
>>>
>>> v.transform was rewritten to read and write vector binary file.
>>>
>>>
>>> Radim
>>>
>> ____________________
>>
______________________________
Michael Barton, Professor & Curator
Department of Anthropology
Arizona State University
Tempe, AZ 85287-2402
USA
voice: 480-965-6262; fax: 480-965-7671
From mlennert at club.worldonline.be Thu Jan 29 12:38:04 2004
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] grass57 d.what.vect - dies silently after two clicks
Message-ID: <41093.164.15.134.155.1075397884.squirrel@moritz.homelinux.org>
Hello,
d.what.vect does not give any results and dies silently after the second
click on the map.
When launched via the display manager, the following error message appears:
child killed: write on pipe with no readers
child killed: write on pipe with no readers
while executing
"exec d.what.vect map=communes >@stdout 2>@stdout"
("eval" body line 1)
invoked from within
"eval "exec $cmd >@stdout 2>@stdout""
(procedure "Dm::execute" line 12)
invoked from within
"Dm::execute $cmd"
(procedure "DmVector::query" line 24)
invoked from within
"DmVector::query $sel"
("vector" arm line 2)
invoked from within
"switch $type {
raster {
DmRaster::query $sel
}
labels {
DmLabels::query $sel
}
vector ..."
(procedure "Dm::query" line 10)
invoked from within
"Dm::query"
("uplevel" body line 1)
invoked from within
"uplevel \#0 $cmd"
(procedure "Button::_release" line 18)
invoked from within
"Button::_release .mainframe.topf.tb0.bbox1.b4"
(command bound to event)
Moritz
From neteler at itc.it Thu Jan 29 15:31:47 2004
From: neteler at itc.it (Markus Neteler)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] v.transform semi-error
In-Reply-To: <02D805A6-527A-11D8-88A6-00039313C09E@asu.edu>
References: <200401291447.i0TEl1S30810@grass.itc.it> <02D805A6-527A-11D8-88A6-00039313C09E@asu.edu>
Message-ID: <20040129203147.GA3658@thuille.itc.it>
On Thu, Jan 29, 2004 at 09:41:39AM -0700, Michael Barton wrote:
> Markus,
>
> Happy to try to clarify now I that I've figured out why I've been
> confused. When you use v.transform from the tcltk menu system, it says
> to input an ascii vector map. If you click the browse button (labeled
> "vector_ascii", as is the output map name browse button), it goes to
> the dig_ascii to search for a map. If you select a map from there it
> appears in the dialog window. However, when you try to run v.transform
> (clicking the "run" button) it says file not found.
>
> The problem seems to be that the tcltk menu system has not been updated
> to reflect changes in v.transform. In the manual, it says binary vector
> file and v.transform from the command line works as specified there.
OK, I have fixed that in tcltkgrassi (but didn't test).
That's why 5.7 renders the menus automatically, no such update work :-)
Markus
>
> On Thursday, January 29, 2004, at 07:47 AM,
> grass5-request@grass.itc.it wrote:
>
> >From: Markus Neteler
> >Date: Thu Jan 29, 2004 6:01:36 AM America/Phoenix
> >To: grass5@grass.itc.it
> >Subject: Re: [GRASS5] Testing Grass 5.3 - v.transform
> >
> >
> >On Wed, Jan 28, 2004 at 10:20:17PM -0700, Michael Barton wrote:
> >>Radim
> >>
> >>Just wanted to let you know. I tested v.transform by typing in the
> >>name
> >>of a binary vector file (the browse button looks in the dig_ascii
> >>instead of dig folder). It worked just fine. Thanks for the tip.
> >
> >Michael,
> >
> >this is not clear to me:
> >
> >src/mapdev/v.transform/main.c
> >[...]
> > old->gisprompt = "old,dig,vector";
> >
> >The version in 5.3-CVS refers to the dig file.
> >
> >Where did you find the reference to dig_ascii? Maybe in 5.0.3?
> >
> >Markus
> >
> >
> >>
> >>On Monday, January 19, 2004, at 01:54 AM, Radim Blazek wrote:
> >>
> >>>On Friday 16 January 2004 17:13, Michael Barton wrote:
> >>>>As with GRASS 5.7, I've been doing considerable testing of GRASS
> >>>>5.3.
> >>>>Overall, it is highly stable and works very well. Here are a couple
> >>>>of
> >>>>minor items that perhaps could be fixed before it is released as
> >>>>stable.
> >>>>
> >>>>1. v.transform does not operate correctly, at least under Mac OSX.
> >>>>It
> >>>>requires an ASCII vector file as input, looks in the dig_ASCII
> >>>>folder,
> >>>>but will not recognize an ASCII vector file unless it is put
> >>>>(manually
> >>>>and incorrectly) into the dig folder. It produces an incomplete
> >>>>output
> >>>>file (header and attributes, but no vectors). This was a problem on
> >>>>an
> >>>>earlier release; I have tried this on the the 12 January CVS
> >>>>snapshot
> >>>>and it is still a problem.
> >>>
> >>>v.transform was rewritten to read and write vector binary file.
> >>>
> >>>
> >>>Radim
> >>>
> >>____________________
> >>
> ______________________________
> Michael Barton, Professor & Curator
> Department of Anthropology
> Arizona State University
> Tempe, AZ 85287-2402
> USA
>
> voice: 480-965-6262; fax: 480-965-7671
>
> _______________________________________________
> grass5 mailing list
> grass5@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5
From glynn.clements at virgin.net Thu Jan 29 16:30:20 2004
From: glynn.clements at virgin.net (Glynn Clements)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] v.transform semi-error
In-Reply-To: <20040129203147.GA3658@thuille.itc.it>
References: <200401291447.i0TEl1S30810@grass.itc.it>
<02D805A6-527A-11D8-88A6-00039313C09E@asu.edu>
<20040129203147.GA3658@thuille.itc.it>
Message-ID: <16409.31596.747598.631114@cerise.nosuchdomain.co.uk>
Markus Neteler wrote:
> > Happy to try to clarify now I that I've figured out why I've been
> > confused. When you use v.transform from the tcltk menu system, it says
> > to input an ascii vector map. If you click the browse button (labeled
> > "vector_ascii", as is the output map name browse button), it goes to
> > the dig_ascii to search for a map. If you select a map from there it
> > appears in the dialog window. However, when you try to run v.transform
> > (clicking the "run" button) it says file not found.
> >
> > The problem seems to be that the tcltk menu system has not been updated
> > to reflect changes in v.transform. In the manual, it says binary vector
> > file and v.transform from the command line works as specified there.
>
> OK, I have fixed that in tcltkgrassi (but didn't test).
>
> That's why 5.7 renders the menus automatically, no such update work :-)
How does it deal with the issues surrounding r.colors, as discussed in
the "Testing Grass 5.3" thread?
--
Glynn Clements
From hamish_nospam at yahoo.com Thu Jan 29 18:24:13 2004
From: hamish_nospam at yahoo.com (Hamish)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] Re: [GRASSLIST:2393] Mac OS X 10.2.x-5.3cvs e 5.7cvs binaries ready
In-Reply-To:
References:
Message-ID: <20040130122413.626f54d3.hamish_nospam@yahoo.com>
> New Mac OS X binaries for Grass (cvs_01_24_2004)
Are these for OSX 10.2 or 10.3, or does it matter?
> (d.text.freetype is the only module not compiled)
I was able to get this to compile using both Apple's X11 freetype2
lib and one installed from Fink. What's the error?
The following works for me anyway, change the last line to /sw/...
for Fink's one -- I think the OSX 10.3 freetype2 is newer though.
LDFLAGS="-s" ./configure --enable-shared \
--with-includes="/usr/X11R6/include /sw/include" \
--with-libs="/usr/X11R6/lib /sw/lib" \
--with-freetype \
--with-freetype-includes=/usr/X11R6/include/freetype2
regards,
Hamish
From hamish_nospam at yahoo.com Thu Jan 29 18:56:39 2004
From: hamish_nospam at yahoo.com (Hamish)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] grass 5.0.3 in debian
In-Reply-To: <16407.40176.30719.755493@cerise.nosuchdomain.co.uk>
References: <20040105130845.GD13455@intevation.de>
<1073311576.1020.55.camel@localhost>
<20040107145228.GG3467@thuille.itc.it>
<1073488749.1035.4.camel@localhost>
<20040112083752.GE3731@thuille.itc.it>
<20040113191350.5f454184.hamish_nospam@yahoo.com>
<20040113095421.GB4135@firewall.ba.issia.cnr.it>
<20040122201204.6be7d5b1.hamish_nospam@yahoo.com>
<16399.41028.172818.727485@cerise.nosuchdomain.co.uk>
<20040128000404.32ce844b.hamish_nospam@yahoo.com>
<16406.27179.786608.337566@cerise.nosuchdomain.co.uk>
<1075239525.1477.41.camel@localhost>
<16407.40176.30719.755493@cerise.nosuchdomain.co.uk>
Message-ID: <20040130125639.776e4099.hamish_nospam@yahoo.com>
> > anyway, a diff does not report anything usefull (no real
> > differences.)
>
> That's one possibility eliminated.
>
> Has anything changed between 8.3 and 8.4 which would affect code which
> creates new widget classes?
? Big 8.4 change I was aware of was the intoduction of threads & 64bit
support, which likely exposes subtle bugs that were previously sleeping
in the NVIZ code ??
> > should we revert to 8.3?
>
> Tk 8.4 isn't going to go away, so NVIZ/Togl will have to deal with the
> issues eventually.
Yes, but for the next Debian release there needs to be a working
package.
My suggestion would be to build a working package against 8.3, get that
into /testing, then rebuild with 8.4, upload to /unstable and file a
bug against it so the broken version doesn't get into testing(->stable).
I'd think that at this point Debian/Sarge is closer to release than
GRASS 5.0.4 or 5.3.0? (I mean by that I think Debian will release
sooner, not GRASS dragging on)
As it is only seen with Debian so far (??) it should be sorted out in
the Debian BTS by people familiar with Debian's TclTk.
> Another line of approach would be to check whether the original Togl
> code has had any changes for Tk 8.4.
I ran it through the debugger a while back, but don't have the energy to
do that right now, maybe it would help.
Hamish
From jeff.hamann at forestinformatics.com Fri Jan 30 03:15:26 2004
From: jeff.hamann at forestinformatics.com (Jeff D. Hamann)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] building grass and gdal support with HDF-EOS (ASTER L1B)
Message-ID: <000f01c3e709$378c0130$0a00a8c0@rodan>
Okay, I've been able to compile gdal-1.1.9 and GRASS5.3 (on my way to
building GRASS5.7) so I can import my ASTER images (EOS-HDF) and noticed
that when I built gdal and GRASS5.3
and run gdalinfo to make sure the build worked I didn't have hdf or hdf4
support as listed in the supported
$ gdalinfo --formats
Supported Formats:
VRT: Virtual Raster
GTiff: GeoTIFF
NITF: National Imagery Transmission Format
HFA: Erdas Imagine Images (.img)
SAR_CEOS: CEOS SAR Image
CEOS: CEOS Image
ELAS: ELAS
AIG: Arc/Info Binary Grid
AAIGrid: Arc/Info ASCII Grid
SDTS: SDTS Raster
DTED: DTED Elevation Raster
PNG: Portable Network Graphics
JPEG: JPEG JFIF
MEM: In Memory Raster
JDEM: Japanese DEM (.mem)
GIF: Graphics Interchange Format (.gif)
ESAT: Envisat Image Format
BSB: Maptech BSB Nautical Charts
XPM: X11 PixMap Format
BMP: MS Windows Device Independent Bitmap
PNM: Portable Pixmap Format (netpbm)
DOQ1: USGS DOQ (Old Style)
DOQ2: USGS DOQ (New Style)
ENVI: ENVI .hdr Labelled
EHdr: ESRI .hdr Labelled
PAux: PCI .aux Labelled
MFF: Atlantis MFF Raster
MFF2: Atlantis MFF2 (HKV) Raster
FujiBAS: Fuji BAS Scanner Image
GSC: GSC Geogrid
FAST: EOSAT FAST Format
L1B: NOAA Polar Orbiter Level 1b Data Set
FIT: FIT Image
USGSDEM: USGS Optional ASCII DEM
GXF: GeoSoft Grid Exchange Format
Needless to say, I figured it was built in and I only had to name the file
in r.in.gdal.So I ran
GRASS:~ > gdalinfo ast_l1b.hdf
ERROR 4: `ast_l1b.hdf' does not exist in the file system,
and is not recognised as a supported dataset name.
GDALOpen failed - 4
`ast_l1b.hdf' does not exist in the file system,
and is not recognised as a supported dataset name.
GRASS:~ >
I then ran gdalinfo (assuming the libs and command line tools are build with
the same code/settings) on a png file I have and I work perfectly.
GRASS:~ > gdalinfo --version
GDAL 1.1.9.0, released 2003/06/27
GRASS:~ > gdalinfo streams50.tif
Driver: GTiff/GeoTIFF
Size is 699, 537
Coordinate System is `'
Origin = (484525.000000,4671615.000000)
Pixel Size = (30.000000,-30.000000)
Corner Coordinates:
Upper Left ( 484525.000, 4671615.000)
Lower Left ( 484525.000, 4655505.000)
Upper Right ( 505495.000, 4671615.000)
Lower Right ( 505495.000, 4655505.000)
Center ( 495010.000, 4663560.000)
Band 1 Block=699x3 Type=Byte, ColorInterp=Red
Band 2 Block=699x3 Type=Byte, ColorInterp=Green
Band 3 Block=699x3 Type=Byte, ColorInterp=Blue
So my question is this, What's the trick to getting hdf compiled into gdal
so that I can use HDF_EOS so I can read ASTER L1B files (.hdf and .met)?
Thanks,
Jeff
---
Jeff D. Hamann
Forest Informatics, Inc.
PO Box 1421
Corvallis, Oregon USA 97339-1421
(office) 541-754-1428
(cell) 541-740-5988
jeff.hamann@forestinformatics.com
www.forestinformatics.com
From neteler at itc.it Fri Jan 30 03:26:51 2004
From: neteler at itc.it (Markus Neteler)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] v.transform semi-error
In-Reply-To: <16409.31596.747598.631114@cerise.nosuchdomain.co.uk>
References: <200401291447.i0TEl1S30810@grass.itc.it> <02D805A6-527A-11D8-88A6-00039313C09E@asu.edu> <20040129203147.GA3658@thuille.itc.it> <16409.31596.747598.631114@cerise.nosuchdomain.co.uk>
Message-ID: <20040130082651.GA5363@thuille.itc.it>
On Thu, Jan 29, 2004 at 09:30:20PM +0000, Glynn Clements wrote:
>
> Markus Neteler wrote:
>
> > > Happy to try to clarify now I that I've figured out why I've been
> > > confused. When you use v.transform from the tcltk menu system, it says
> > > to input an ascii vector map. If you click the browse button (labeled
> > > "vector_ascii", as is the output map name browse button), it goes to
> > > the dig_ascii to search for a map. If you select a map from there it
> > > appears in the dialog window. However, when you try to run v.transform
> > > (clicking the "run" button) it says file not found.
> > >
> > > The problem seems to be that the tcltk menu system has not been updated
> > > to reflect changes in v.transform. In the manual, it says binary vector
> > > file and v.transform from the command line works as specified there.
> >
> > OK, I have fixed that in tcltkgrassi (but didn't test).
> >
> > That's why 5.7 renders the menus automatically, no such update work :-)
>
> How does it deal with the issues surrounding r.colors, as discussed in
> the "Testing Grass 5.3" thread?
I think it doesn't.
So I change my statement to
"minimized update work with few outstanding issues".
You are welcome to suggest a solution.
Markus
From glynn.clements at virgin.net Fri Jan 30 08:01:07 2004
From: glynn.clements at virgin.net (Glynn Clements)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] v.transform semi-error
In-Reply-To: <20040130082651.GA5363@thuille.itc.it>
References: <200401291447.i0TEl1S30810@grass.itc.it>
<02D805A6-527A-11D8-88A6-00039313C09E@asu.edu>
<20040129203147.GA3658@thuille.itc.it>
<16409.31596.747598.631114@cerise.nosuchdomain.co.uk>
<20040130082651.GA5363@thuille.itc.it>
Message-ID: <16410.21907.615221.666218@cerise.nosuchdomain.co.uk>
Markus Neteler wrote:
> > > > Happy to try to clarify now I that I've figured out why I've been
> > > > confused. When you use v.transform from the tcltk menu system, it says
> > > > to input an ascii vector map. If you click the browse button (labeled
> > > > "vector_ascii", as is the output map name browse button), it goes to
> > > > the dig_ascii to search for a map. If you select a map from there it
> > > > appears in the dialog window. However, when you try to run v.transform
> > > > (clicking the "run" button) it says file not found.
> > > >
> > > > The problem seems to be that the tcltk menu system has not been updated
> > > > to reflect changes in v.transform. In the manual, it says binary vector
> > > > file and v.transform from the command line works as specified there.
> > >
> > > OK, I have fixed that in tcltkgrassi (but didn't test).
> > >
> > > That's why 5.7 renders the menus automatically, no such update work :-)
> >
> > How does it deal with the issues surrounding r.colors, as discussed in
> > the "Testing Grass 5.3" thread?
>
> I think it doesn't.
> So I change my statement to
> "minimized update work with few outstanding issues".
>
> You are welcome to suggest a solution.
More precisely, how does it decide if the program requires an xterm?
If it always requires one, that trivially solves the problem.
One option for dealing with the fact that r.colors sometimes requires
a terminal but usually doesn't would be to remove the color=rules
facility from r.colors and create a separate r.colors.rules program
for that case.
A couple of other points:
1. I already noted that the method of having multiple menu items (and
module files) for a single program was already being used for
v.support; presumably that won't work either. More generally,
auto-generated menus/dialogs won't work particularly well for programs
which have multiple "modes". Again, one solution is to split such
programs into several more specific components.
2. I'm wondering how many programs support using stdin as the input
file but don't have the "requires an xterm" flag set in their
(5.0/5.3) tcltkgrass module file.
3. More generally, if you want to make programs GUI-friendly, you need
to stop assuming that stdin exists. That includes use of "infile=-",
G_ask_*(), Vask etc.
--
Glynn Clements
From glynn.clements at virgin.net Fri Jan 30 08:28:35 2004
From: glynn.clements at virgin.net (Glynn Clements)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] grass 5.0.3 in debian
In-Reply-To: <20040130125639.776e4099.hamish_nospam@yahoo.com>
References: <20040105130845.GD13455@intevation.de>
<1073311576.1020.55.camel@localhost>
<20040107145228.GG3467@thuille.itc.it>
<1073488749.1035.4.camel@localhost>
<20040112083752.GE3731@thuille.itc.it>
<20040113191350.5f454184.hamish_nospam@yahoo.com>
<20040113095421.GB4135@firewall.ba.issia.cnr.it>
<20040122201204.6be7d5b1.hamish_nospam@yahoo.com>
<16399.41028.172818.727485@cerise.nosuchdomain.co.uk>
<20040128000404.32ce844b.hamish_nospam@yahoo.com>
<16406.27179.786608.337566@cerise.nosuchdomain.co.uk>
<1075239525.1477.41.camel@localhost>
<16407.40176.30719.755493@cerise.nosuchdomain.co.uk>
<20040130125639.776e4099.hamish_nospam@yahoo.com>
Message-ID: <16410.23555.947653.839114@cerise.nosuchdomain.co.uk>
Hamish wrote:
> > > anyway, a diff does not report anything usefull (no real
> > > differences.)
> >
> > That's one possibility eliminated.
> >
> > Has anything changed between 8.3 and 8.4 which would affect code which
> > creates new widget classes?
>
> ? Big 8.4 change I was aware of was the intoduction of threads & 64bit
> support, which likely exposes subtle bugs that were previously sleeping
> in the NVIZ code ??
Are you referring just to making Tcl/Tk thread-safe, or does it
actually use multiple threads automatically? If it's the latter, then
NVIZ may not work with 8.4 for the foreseeable future.
If it's the former, maybe NVIZ needs to be compiled with -D_REENTRANT?
I doubt that 64-bit support will be an issue, given that the problems
are occurring on x86.
> > Another line of approach would be to check whether the original Togl
> > code has had any changes for Tk 8.4.
I checked that; Togl hasn't been updated for 8.4.
> I ran it through the debugger a while back, but don't have the energy to
> do that right now, maybe it would help.
Just getting a backtrace at the point the segfault occurs might
provide useful information. Anything beyond that might be a
significant amount of work (and may require Tcl/Tk libs which were
built for debugging, i.e. with -g and without -O).
--
Glynn Clements
From glynn.clements at virgin.net Fri Jan 30 14:53:17 2004
From: glynn.clements at virgin.net (Glynn Clements)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] Cygwin binary package
In-Reply-To: <16388.20995.361993.982097@cerise.nosuchdomain.co.uk>
References: <16388.20995.361993.982097@cerise.nosuchdomain.co.uk>
Message-ID: <16410.46637.404133.258954@cerise.nosuchdomain.co.uk>
Glynn Clements wrote:
> I have a report that one of the Cygwin binary packages on grass.itc.it
> includes a broken version of NVIZ (linked against Cygwin's tcl84.dll,
> which won't work).
>
> Can someone either remove the package, or at least remove NVIZ from
> it.
I have a report that, contrary to the instructions in
documents/release_rules.txt, the version of NVIZ in the current Cygwin
binary package requires PostgreSQL (resulting in a Windows error
dialog if pq.dll is not present).
--
Glynn Clements
From neteler at itc.it Fri Jan 30 15:43:53 2004
From: neteler at itc.it (Markus Neteler)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] Cygwin binary package
In-Reply-To: <16410.46637.404133.258954@cerise.nosuchdomain.co.uk>
References: <16388.20995.361993.982097@cerise.nosuchdomain.co.uk> <16410.46637.404133.258954@cerise.nosuchdomain.co.uk>
Message-ID: <20040130204353.GC18274@thuille.itc.it>
On Fri, Jan 30, 2004 at 07:53:17PM +0000, Glynn Clements wrote:
>
> Glynn Clements wrote:
>
> > I have a report that one of the Cygwin binary packages on grass.itc.it
> > includes a broken version of NVIZ (linked against Cygwin's tcl84.dll,
> > which won't work).
> >
> > Can someone either remove the package, or at least remove NVIZ from
> > it.
>
> I have a report that, contrary to the instructions in
> documents/release_rules.txt, the version of NVIZ in the current Cygwin
> binary package requires PostgreSQL (resulting in a Windows error
> dialog if pq.dll is not present).
>
If packages should be removed, please let's have two independent
reports of non-functionality.
We have also the report that NVIZ works:
http://grass.itc.it/pipermail/grass5/2004-January/013411.html
And these requests are not clear to me:
http://grass.itc.it/pipermail/grass5/2004-January/013402.html
http://grass.itc.it/pipermail/grass5/2004-January/013408.html
with respect to above request(s).
So: Please post the URL to the file(s).
Markus
From neteler at itc.it Fri Jan 30 15:48:39 2004
From: neteler at itc.it (Markus Neteler)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] What's holding 5.3.0 release?
Message-ID: <20040130204839.GD18274@thuille.itc.it>
... the subject says all:
What's holding the 5.3.0 release?
The last month I received several comments telling that the current
situation of GRASS development for new programmers is confusing.
They see "5.0.3 stable" while most recommendations are "please use
5.3, it's much better and more widely tested".
In my opinion a 5.3.0 release is urgently needed.
And it should not be called "unstable" according to the
odd minor release number as it would be too discouraging to
stimulate new development.
Markus
From JGillette at rfmd.com Fri Jan 30 16:29:21 2004
From: JGillette at rfmd.com (John Gillette)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] What's holding 5.3.0 release?
Message-ID: <8EC17EE03C13464E8049ADA41C53EB9E759729@mail3>
> The last month I received several comments telling that the current
> situation of GRASS development for new programmers is confusing.
In fairness to you, Markus, I think the discussions on this list made
it clear what the plan is and what the differences between the versions
are.
Having said that, I do have questions about proj4 and r.in.gdal.
My understanding is that the proj4 library is not required for 5.3.
An internal version will be used if not found BUT there is a slight
difference in the versions and a small bug has been fixed in the
grass supplied version. This this correct and does it affect the
release of 5.3? Have we documented the difference?
For r.in.gdal, I made a small attempt to understand why some
people were having seg-fault problems. I still don't understand
this. Is there a difference in r.in.gdal in 5.3? A recent problem
was fixed, I think, relating to DEMS. Is this in the 5.3 version?
And I just remembered r.terraflow. Is that fixed to compile on
gcc 2.9x and >3.x now? I don't see it in the man pages for 5.3 on the
web. Will it be included for 5.3? I assume not.
(I am trying to be helpful here, not a nuisance.)
John
From paul-grass at stjohnspoint.co.uk Fri Jan 30 19:09:50 2004
From: paul-grass at stjohnspoint.co.uk (Paul Kelly)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] What's holding 5.3.0 release?
In-Reply-To: <20040130204839.GD18274@thuille.itc.it>
References: <20040130204839.GD18274@thuille.itc.it>
Message-ID:
On Fri, 30 Jan 2004, Markus Neteler wrote:
> ... the subject says all:
>
> What's holding the 5.3.0 release?
>
> The last month I received several comments telling that the current
> situation of GRASS development for new programmers is confusing.
> They see "5.0.3 stable" while most recommendations are "please use
> 5.3, it's much better and more widely tested".
>
> In my opinion a 5.3.0 release is urgently needed.
> And it should not be called "unstable" according to the
> odd minor release number as it would be too discouraging to
> stimulate new development.
Those two paragraphs may be a question for Bernhard as I recall he
promoted this separate stable / unstable branch arrangement. I posted my
thoughts on it before:
http://grass.itc.it/pipermail/grass5/2003-January/007012.html and also
agree with Markus' comments above except that 5.3 should still be called
unstable. Well not stable anyway. Maybe 'semi-stable'?
I will try and answer the first question: Off the top of my head here are
some things that should be fixed:
1) Remove gdalbridge code from r.in.gdal
2) Update internal GRASS PROJ library to remotesensing.org proj apart from
the local bugfixes (in this case disable the --with-proj option so we have
to use the internal fixed version) *and/or* change modules that convert
projected co-ordinates to lat/long to use pj_latlong_from_proj() function
(to workaround PROJ bug number 368
http://bugzilla.remotesensing.org/show_bug.cgi?id=368 )
3) Fix up glX dependencies in NVIZ (really I'm not too sure about the
status of this; probably good to release and let the bug reports flow in)
4) Fix conditional compilation of g3d modules for glX dependencies and
other variable OpenGL stuff
5) Various updates for v.in.dxf and v.in.dxf3d: an option to write to
category labels to dig_cats instead of dig_atts. Also some fixes people
have sent in should be merged (e.g. I remember something 8-bit character
encoding)
6) r.terraflow should only be compiled if g++ is detected; it won't work
with any other C++ compiler
7) Make --enable-gmake=no the default and use the alternate build
mechanism for shared libraries---this needs a few changes for Cygwin.
Maybe dig2 and vect libraries merged into one big library? Or else
compiled as static library. Also driverlib compiled statically.
But yes of course we can release now and put off these fixes until 5.3.1.
And I can probably do the release though it would take me a while. I would
need some instructions on how to sign the source code tarball (and
possibly the binaries).
Paul
From smitch at mac.com Fri Jan 30 19:41:46 2004
From: smitch at mac.com (Scott Mitchell)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] What's holding 5.3.0 release?
In-Reply-To:
References: <20040130204839.GD18274@thuille.itc.it>
Message-ID: <3F92E482-5386-11D8-94B7-000A95C5478C@mac.com>
What about "testing", as in the intermediate level used by Debian?
(also referred to in the posting that Paul responded to back last
January)
i.e. in the current situation, it could be that 5.0.x=stable,
5.3.x=testing, 5.3.7=unstable
It would also follow Debian's example in that the "stable" release
tends to be a little "behind the times" (critical bug fixes only), and
I for one have usually found the "testing" branch of Debian to be the
most useful... along the same lines, I tend to concentrate on GRASS
5.3.x (although the vector/raster concentrations play a larger role
there).
I agree with an earlier post that developers that have been following
the traffic shouldn't be too confused given the work that Markus et al
have put in to the "road maps"... but that users coming along can also
be confused. Maybe the above labels would be more illustrative.
My "off the top of my head" impressions....
Scott
On Jan 30, 2004, at 19:09, Paul Kelly wrote:
>> In my opinion a 5.3.0 release is urgently needed.
>> And it should not be called "unstable" according to the
>> odd minor release number as it would be too discouraging to
>> stimulate new development.
>
> Those two paragraphs may be a question for Bernhard as I recall he
> promoted this separate stable / unstable branch arrangement. I posted
> my
> thoughts on it before:
> http://grass.itc.it/pipermail/grass5/2003-January/007012.html and also
> agree with Markus' comments above except that 5.3 should still be
> called
> unstable. Well not stable anyway. Maybe 'semi-stable'?
>
----
Scott Mitchell, Assistant Professor, Carleton University
Department of Geography & Environmental Studies, Loeb A209
Mailing: Loeb B349, 1125 Colonel By Dr., Ottawa, ON K1S 5B6 Canada
1-613-520-2600 x2695 Fax: 613-520-4301 Scott_Mitchell@carleton.ca
From glynn.clements at virgin.net Fri Jan 30 20:58:34 2004
From: glynn.clements at virgin.net (Glynn Clements)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] Cygwin binary package
In-Reply-To: <20040130204353.GC18274@thuille.itc.it>
References: <16388.20995.361993.982097@cerise.nosuchdomain.co.uk>
<16410.46637.404133.258954@cerise.nosuchdomain.co.uk>
<20040130204353.GC18274@thuille.itc.it>
Message-ID: <16411.3018.43389.427946@cerise.nosuchdomain.co.uk>
Markus Neteler wrote:
> > > I have a report that one of the Cygwin binary packages on grass.itc.it
> > > includes a broken version of NVIZ (linked against Cygwin's tcl84.dll,
> > > which won't work).
> > >
> > > Can someone either remove the package, or at least remove NVIZ from
> > > it.
> >
> > I have a report that, contrary to the instructions in
> > documents/release_rules.txt, the version of NVIZ in the current Cygwin
> > binary package requires PostgreSQL (resulting in a Windows error
> > dialog if pq.dll is not present).
>
> If packages should be removed, please let's have two independent
> reports of non-functionality.
>
> We have also the report that NVIZ works:
>
> http://grass.itc.it/pipermail/grass5/2004-January/013411.html
NVIZ can be made to work on Cygwin; I've done so myself. It's also
very easy to successfully build an NVWISH2.2.exe which won't actually
run. It's equally easy to build it so it won't run if you don't have
PostgreSQL installed.
Note: the last two scenarios (won't run, won't run without PostgreSQL)
are easier to achieve than getting it correct, as they require fewer
switches (using the right Tcl/Tk requires --with-tcltk-{includes,libs}
while eliminating the PostgreSQL dependency requires --without-postgres).
> And these requests are not clear to me:
> http://grass.itc.it/pipermail/grass5/2004-January/013402.html
> http://grass.itc.it/pipermail/grass5/2004-January/013408.html
> with respect to above request(s).
>
> So: Please post the URL to the file(s).
The latest report refers to 5.0.3, Xserver, and is from a different
person to the previous report. The last-modified date on:
http://grass.itc.it/grass5/binary/windows_cygnus/wingrass_xserver/grass5.0.3_i686-pc-cygwin_bin.tar.gz
is 15-Nov-2003 03:45, which pre-dates the previous report. IOW, those
packages appear to be broken on two counts; using Cygwin's Tcl/Tk, and
NVIZ built with PostgreSQL. Note that the PostgreSQL issue wouldn't
show up if Cygwin's PostgreSQL package was installed.
--
Glynn Clements
From glynn.clements at virgin.net Fri Jan 30 21:13:48 2004
From: glynn.clements at virgin.net (Glynn Clements)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] What's holding 5.3.0 release?
In-Reply-To: <8EC17EE03C13464E8049ADA41C53EB9E759729@mail3>
References: <8EC17EE03C13464E8049ADA41C53EB9E759729@mail3>
Message-ID: <16411.3932.546301.975247@cerise.nosuchdomain.co.uk>
John Gillette wrote:
> For r.in.gdal, I made a small attempt to understand why some
> people were having seg-fault problems. I still don't understand
> this.
That's OK; nor does anyone else ;)
Seriously, there are a variety of reasons why r.in.gdal segfaults;
some of those reasons are better understood than others.
Some specifics which increase the likelyhood of r.in.gdal working are:
1. Using --with-gdal, so libgdal is linked directly rather than loaded
dynamically with dlopen().
2. Building GDAL with the --without-grass switch.
> Is there a difference in r.in.gdal in 5.3?
Only that --with-gdal is now the default.
--
Glynn Clements
From glynn.clements at virgin.net Fri Jan 30 21:42:54 2004
From: glynn.clements at virgin.net (Glynn Clements)
Date: Wed Nov 14 13:44:47 2007
Subject: [GRASS5] What's holding 5.3.0 release?
In-Reply-To: