From hamish_nospam at yahoo.com Sun Apr 1 05:15:47 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Sun Apr 1 05:16:00 2007 Subject: [GRASSGUI] Re: [GRASS-dev] menu help In-Reply-To: References: Message-ID: <20070401151547.03bbed48.hamish_nospam@yahoo.com> Michael Barton wrote: > > The best thing for the long run would be work work with the keyword > section of the interface description that Markus set up and arrange > the keys so that they could build a menu automatically. Then we > wouldn't have to manually maintain the hundreds of commands. Keywords can help self-organize a new menu tree, but ultimately the final cut will have to be crafted by hand. Hamish From nicholas.g.lawrence at mainroads.qld.gov.au Mon Apr 2 01:47:06 2007 From: nicholas.g.lawrence at mainroads.qld.gov.au (nicholas.g.lawrence@mainroads.qld.gov.au) Date: Mon Apr 2 01:47:37 2007 Subject: [GRASS-dev] discussion: replacing ps.map In-Reply-To: <20070330140517.GA3927@polynum.com> Message-ID: >Thierry Laronde (Alceste) > ---because PostScript is a standard Exactly what do you mean by this? Is PostScript a de-facto standard? Like microsoft word.doc? Or is it a standard recognised by ISO? (standard de-jure?) nick ************************************************************ Opinions contained in this e-mail do not necessarily reflect the opinions of the Queensland Department of Main Roads, Queensland Transport or Maritime Safety Queensland, or endorsed organisations utilising the same infrastructure. If you have received this electronic mail message in error, please immediately notify the sender and delete the message from your computer. ************************************************************ From glynn at gclements.plus.com Mon Apr 2 05:09:29 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Apr 2 05:09:36 2007 Subject: [GRASS-dev] discussion: replacing ps.map In-Reply-To: References: <20070330140517.GA3927@polynum.com> Message-ID: <17936.29673.217803.363282@cerise.gclements.plus.com> nicholas.g.lawrence@mainroads.qld.gov.au wrote: > >Thierry Laronde (Alceste) > > ---because PostScript is a standard > > Exactly what do you mean by this? > > Is PostScript a de-facto standard? Like microsoft word.doc? > > Or is it a standard recognised by ISO? (standard de-jure?) Yes, sort of, and no. It's a de-facto standard, not a de-jure standard. But unlike MS-Word, PostScript is extensively documented, and a free (GPL) implementation (Ghostscript) is available for all common platforms. FWIW, the reference documentation is available from: http://partners.adobe.com/public/developer/ps/index_specs.html -- Glynn Clements From glynn at gclements.plus.com Mon Apr 2 09:34:49 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Apr 2 09:34:51 2007 Subject: [GRASS-dev] discussion: replacing ps.map In-Reply-To: <17932.16901.672831.128404@cerise.gclements.plus.com> References: <17930.59855.699533.647215@cerise.gclements.plus.com> <17932.16901.672831.128404@cerise.gclements.plus.com> Message-ID: <17936.45593.765285.836412@cerise.gclements.plus.com> Glynn Clements wrote: > The original unscaled raster function R_RGB_raster() is only used by > i.point, i.vpoints and i.class. They could be changed to use the > scaled raster functions with 1:1 scaling, although I'm not sure that I > understand them well enough to test any changes, and I'm not sure if > it's worth the effort (AFAIK, they should all be obsolete soon). I've changed them to use the scaled raster functions (D_draw_d_raster rather than D_d_raster). i.points seems to work okay (although I'm not all that familiar with it), and the other two have almost identical code. Even so, I'd appreciate it if someone could test these changes. -- Glynn Clements From tlaronde at polynum.com Mon Apr 2 11:21:31 2007 From: tlaronde at polynum.com (tlaronde@polynum.com) Date: Mon Apr 2 11:18:15 2007 Subject: [GRASS-dev] discussion: replacing ps.map In-Reply-To: <17933.38854.857497.325623@cerise.gclements.plus.com> References: <17929.35602.196088.815592@cerise.gclements.plus.com> <20070327224018.3aec7e67@localhost.localdomain> <460A273A.1060109@club.worldonline.be> <20070328092330.GA928@polynum.com> <17930.59855.699533.647215@cerise.gclements.plus.com> <17932.40292.139762.620114@cerise.gclements.plus.com> <1175258317.17362.1.camel@linux.home> <20070330140517.GA3927@polynum.com> <17933.38854.857497.325623@cerise.gclements.plus.com> Message-ID: <20070402092131.GB296@polynum.com> On Sat, Mar 31, 2007 at 12:05:42AM +0100, Glynn Clements wrote: > > tlaronde@polynum.com wrote: > > > My remark about the fact that the DRAWLIB (mistakenly called RASTERLIB) > > Not really. It was designed for raster graphics devices, and in many > regards is only suitable for them. > > The name reflects the fact that it targets raster devices, not that it > draws raster images. > > In that sense, PostScript is also a raster graphics system; you can't > fully implement it on e.g. a plotter. Yes and no. PostScript is a vector language, as is METAFONT and so on. The fact that, generally, the final step is to convert these vectorial descriptions in raster is an implementation detail. The man pages for the DRAWLIB (RASTERLIB) mentions: A!ll graphics standards in industry are aimed at CAD-CAM vector applications. GRASS, being raster based in its primary data format, requires the ability to work directly with a device's pixles. This library provides that capability while interfacing itself to commercially available vector graphics. So the "raster" was more taken from the source (the original GRASS, before the development of the vector) than for the target. >>> In theory, PostScript could be use as the DRAWLIB language. But I don't > There are two issues here: whether the graphics API supports > PostScript output, and whether it supports anything else. > > Supporting PostScript output is definitely worthwhile, IMHO. Any d.* > module should be able to generate PostScript with better quality than > by rendering to an image then converting the image to PostScript. > > OTOH, if we were to make PostScript *the* graphics API, d.* modules > would have far more flexibility in their output than with anything > else that we are likely to be able to come up with. The existing API > would just be a compatibility library for existing code. Well, I think I do not quite agree about the way the implementation has to be made. AFAIK, rendering (displaying) in GRASS GPL is made by displaying a previously composed PNG image (Am I right?). In KerGIS, for displaying, I do not have the intention to pass by an intermediate step: the xdriver is a direct implementation of the DRAWLIB opcode. There can be a psdriver, that is a PostScript implementation of the DRAWLIB opcode. But, since for hardcopy and the mixing of arbitrary text (with all the kerning, and even, why not? mathematical text and so on), for this particular task, dedicated programs will be used to render chunks (label blocks, images of text) to allow the full power of say a TeX like formatting system, but for display, whether, in fast mode, only the outline of the images (bounding box) will be used, or the precomputed images (chunks) will be displayed with the normal display functions (not everything will be precomputed by passing by PostScript). ISTR that, three years ago, when I rewrote the xdriver for KerGIS and was first able to use v.digit(1) in KerGIS (coming from GRASS GPL 5.0), I was surprised to see that the display was fast (without having made any optimization). If you do first render via PNG, that is if there is indeed an intermediate step in GRASS GPL, this is not a surprise. Interactivity must be very responsive. -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C From glynn at gclements.plus.com Mon Apr 2 11:49:44 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Apr 2 11:49:51 2007 Subject: [GRASS-dev] discussion: replacing ps.map In-Reply-To: <20070402092131.GB296@polynum.com> References: <17929.35602.196088.815592@cerise.gclements.plus.com> <20070327224018.3aec7e67@localhost.localdomain> <460A273A.1060109@club.worldonline.be> <20070328092330.GA928@polynum.com> <17930.59855.699533.647215@cerise.gclements.plus.com> <17932.40292.139762.620114@cerise.gclements.plus.com> <1175258317.17362.1.camel@linux.home> <20070330140517.GA3927@polynum.com> <17933.38854.857497.325623@cerise.gclements.plus.com> <20070402092131.GB296@polynum.com> Message-ID: <17936.53688.64455.451195@cerise.gclements.plus.com> tlaronde@polynum.com wrote: > AFAIK, rendering (displaying) in GRASS GPL is made by displaying a > previously composed PNG image (Am I right?). That's how gis.m works; it doesn't apply when using display drivers. -- Glynn Clements From cavallini at faunalia.it Mon Apr 2 11:56:49 2007 From: cavallini at faunalia.it (Paolo Cavallini) Date: Mon Apr 2 11:56:56 2007 Subject: [GRASS-dev] compile error? Message-ID: <4610D361.7050207@faunalia.it> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all. I'm getting an error during compilation (yet, I tried running make distclean, but it doesn't help). Any explanation? Thanks. pc ===================================== Installing with make install... ======================= Installation results ======================= echo /home/paolo/Desktop/buildpackage/grass6/bin.i686-pc-linux-gnu/grass63 /home/paolo/Desktop/buildpackage/grass6/bin.i686-pc-linux-gnu/grass63 /bin/sh: line 5: [: =: unary operator expected make[1]: Entering directory `/home/paolo/Desktop/buildpackage/grass6' test -d /usr/local/grass-6.3.cvs || mkdir -p -m 755 /usr/local/grass-6.3.cvs test -d /usr/local/bin || mkdir -p -m 755 /usr/local/bin sed -e "s#^GISBASE.*#GISBASE=/usr/local/grass-6.3.cvs#" /home/paolo/Desktop/ buildpackage/grass6/bin.i686-pc-linux-gnu/grass63 > /usr/local/bin/grass63 chmod a+x /usr/local/bin/grass63 sed -e "s#^WINGISBASE.*#WINGISBASE=/usr/local/grass-6.3.cvs#" /home/paolo/De sktop/buildpackage/grass6/bin.i686-pc-linux-gnu/grass63.bat > /usr/local/bin /grass63.bat chmod a+x /usr/local/bin/grass63.bat cd /home/paolo/Desktop/buildpackage/grass6/dist.i686-pc-linux-gnu ; tar cBf - - bin | (cd /usr/local/grass-6.3.cvs ; tar xBf - ) 2>/dev/null make[1]: [real-install] Error 2 (ignored) cd /home/paolo/Desktop/buildpackage/grass6/dist.i686-pc-linux-gnu ; tar cBf - - bwidget | (cd /usr/local/grass-6.3.cvs ; tar xBf - ) 2>/dev/null cd /home/paolo/Desktop/buildpackage/grass6/dist.i686-pc-linux-gnu ; tar cBf - - docs | (cd /usr/local/grass-6.3.cvs ; tar xBf - ) 2>/dev/null make[1]: [real-install] Error 2 (ignored) cd /home/paolo/Desktop/buildpackage/grass6/dist.i686-pc-linux-gnu ; tar cBf - - driver | (cd /usr/local/grass-6.3.cvs ; tar xBf - ) 2>/dev/null make[1]: [real-install] Error 2 (ignored) cd /home/paolo/Desktop/buildpackage/grass6/dist.i686-pc-linux-gnu ; tar cBf - - etc | (cd /usr/local/grass-6.3.cvs ; tar xBf - ) 2>/dev/null make[1]: [real-install] Error 2 (ignored) cd /home/paolo/Desktop/buildpackage/grass6/dist.i686-pc-linux-gnu ; tar cBf - - fonts | (cd /usr/local/grass-6.3.cvs ; tar xBf - ) 2>/dev/null cd /home/paolo/Desktop/buildpackage/grass6/dist.i686-pc-linux-gnu ; tar cBf - man | (cd /usr/local/grass-6.3.cvs ; tar xBf - ) 2>/dev/null make[1]: [real-install] Error 2 (ignored) cd /home/paolo/Desktop/buildpackage/grass6/dist.i686-pc-linux-gnu ; tar cBf - scripts | (cd /usr/local/grass-6.3.cvs ; tar xBf - ) 2>/dev/null if [ 1 -eq 1 ] ; then cd /home/paolo/Desktop/buildpackage/grass6/dist.i686-p c-linux-gnu ; tar cBf - locale | (cd /usr/local/grass-6.3.cvs ; tar xBf - ) 2>/dev/null ; fi make[1]: *** [real-install] Error 2 make[1]: Leaving directory `/home/paolo/Desktop/buildpackage/grass6' make: *** [install] Error 2 **** Installation failed. Aborting package creation. - -- Paolo Cavallini http://www.faunalia.it/pc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGENNg/NedwLUzIr4RAm/yAJ0TmttS7r9BglwnLioSGnE3zezj+ACgtgrO T6ssS+kYLARdG/Xiwqnk0+o= =gAU6 -----END PGP SIGNATURE----- From glynn at gclements.plus.com Mon Apr 2 13:21:24 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Apr 2 13:21:26 2007 Subject: [GRASS-dev] discussion: replacing ps.map In-Reply-To: <17936.45593.765285.836412@cerise.gclements.plus.com> References: <17930.59855.699533.647215@cerise.gclements.plus.com> <17932.16901.672831.128404@cerise.gclements.plus.com> <17936.45593.765285.836412@cerise.gclements.plus.com> Message-ID: <17936.59188.242469.82716@cerise.gclements.plus.com> Glynn Clements wrote: > > The original unscaled raster function R_RGB_raster() is only used by > > i.point, i.vpoints and i.class. They could be changed to use the > > scaled raster functions with 1:1 scaling, although I'm not sure that I > > understand them well enough to test any changes, and I'm not sure if > > it's worth the effort (AFAIK, they should all be obsolete soon). > > I've changed them to use the scaled raster functions (D_draw_d_raster > rather than D_d_raster). i.points seems to work okay (although I'm not > all that familiar with it), and the other two have almost identical > code. Even so, I'd appreciate it if someone could test these changes. Also changed: photo.2target and photo.2image. -- Glynn Clements From neteler at itc.it Mon Apr 2 16:35:34 2007 From: neteler at itc.it (Markus Neteler) Date: Mon Apr 2 16:35:36 2007 Subject: [GRASS-dev] compile error? In-Reply-To: <4610D361.7050207@faunalia.it> References: <4610D361.7050207@faunalia.it> Message-ID: <20070402143534.GC3154@bartok.itc.it> On Mon, Apr 02, 2007 at 11:56:49AM +0200, Paolo Cavallini wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi all. > I'm getting an error during compilation (yet, I tried running make > distclean, but it doesn't help). > Any explanation? > Thanks. > pc > ===================================== > Installing with make install... > > ======================= Installation results ======================= > echo /home/paolo/Desktop/buildpackage/grass6/bin.i686-pc-linux-gnu/grass63 > /home/paolo/Desktop/buildpackage/grass6/bin.i686-pc-linux-gnu/grass63 > /bin/sh: line 5: [: =: unary operator expected ... Fixed in CVS. MACOSX_APP must be quoted in the Makefile. Markus From woklist at kyngchaos.com Mon Apr 2 17:17:58 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Mon Apr 2 17:18:13 2007 Subject: [GRASS-dev] compile error? In-Reply-To: <20070402143534.GC3154@bartok.itc.it> References: <4610D361.7050207@faunalia.it> <20070402143534.GC3154@bartok.itc.it> Message-ID: <4D9BA27B-BA00-4F32-A695-4E0B4EAB64DD@kyngchaos.com> Sorry about that. Would this also affect when it's used in ifeq() ? ie: ifeq ($(MACOSX_APP),1) On Apr 2, 2007, at 9:35 AM, Markus Neteler wrote: > On Mon, Apr 02, 2007 at 11:56:49AM +0200, Paolo Cavallini wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi all. >> I'm getting an error during compilation (yet, I tried running make >> distclean, but it doesn't help). >> Any explanation? >> Thanks. >> pc >> ===================================== >> Installing with make install... >> >> ======================= Installation results ======================= >> echo /home/paolo/Desktop/buildpackage/grass6/bin.i686-pc-linux-gnu/ >> grass63 >> /home/paolo/Desktop/buildpackage/grass6/bin.i686-pc-linux-gnu/grass63 >> /bin/sh: line 5: [: =: unary operator expected > ... > > Fixed in CVS. MACOSX_APP must be quoted in the Makefile. > > Markus > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev ----- William Kyngesburye http://www.kyngchaos.com/ "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 cavallini at faunalia.it Mon Apr 2 17:25:20 2007 From: cavallini at faunalia.it (Paolo Cavallini) Date: Mon Apr 2 17:25:24 2007 Subject: [GRASS-dev] compile error? In-Reply-To: <20070402143534.GC3154@bartok.itc.it> References: <4610D361.7050207@faunalia.it> <20070402143534.GC3154@bartok.itc.it> Message-ID: <46112060.4090304@faunalia.it> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks. However, it still fails: Installing with make install... ========================= Installation results ====================== echo /home/paolo/Desktop/buildpackage/grass6/bin.i686-pc-linux-gnu/grass63 /home/paolo/Desktop/buildpackage/grass6/bin.i686-pc-linux-gnu/grass63 make[1]: Entering directory `/home/paolo/Desktop/buildpackage/grass6' test -d /usr/local/grass-6.3.cvs || mkdir -p -m 755 /usr/local/grass-6.3.cvs test -d /usr/local/bin || mkdir -p -m 755 /usr/local/bin sed -e "s#^GISBASE.*#GISBASE=/usr/local/grass-6.3.cvs#" /home/paolo/Desktop/buildpackage/grass6/bin.i686-pc-linux-gnu/grass63 > /usr/local/bin/grass63 chmod a+x /usr/local/bin/grass63 sed -e "s#^WINGISBASE.*#WINGISBASE=/usr/local/grass-6.3.cvs#" /home/paolo/Desktop/buildpackage/grass6/bin.i686-pc-linux-gnu/grass63.bat > /usr/local/bin/grass63.bat chmod a+x /usr/local/bin/grass63.bat cd /home/paolo/Desktop/buildpackage/grass6/dist.i686-pc-linux-gnu ; tar cBf - bin | (cd /usr/local/grass-6.3.cvs ; tar xBf - ) 2>/dev/null make[1]: [real-install] Error 2 (ignored) cd /home/paolo/Desktop/buildpackage/grass6/dist.i686-pc-linux-gnu ; tar cBf - bwidget | (cd /usr/local/grass-6.3.cvs ; tar xBf - ) 2>/dev/null cd /home/paolo/Desktop/buildpackage/grass6/dist.i686-pc-linux-gnu ; tar cBf - docs | (cd /usr/local/grass-6.3.cvs ; tar xBf - ) 2>/dev/null make[1]: [real-install] Error 2 (ignored) cd /home/paolo/Desktop/buildpackage/grass6/dist.i686-pc-linux-gnu ; tar cBf - driver | (cd /usr/local/grass-6.3.cvs ; tar xBf - ) 2>/dev/null make[1]: [real-install] Error 2 (ignored) cd /home/paolo/Desktop/buildpackage/grass6/dist.i686-pc-linux-gnu ; tar cBf - etc | (cd /usr/local/grass-6.3.cvs ; tar xBf - ) 2>/dev/null make[1]: [real-install] Error 2 (ignored) cd /home/paolo/Desktop/buildpackage/grass6/dist.i686-pc-linux-gnu ; tar cBf - fonts | (cd /usr/local/grass-6.3.cvs ; tar xBf - ) 2>/dev/null cd /home/paolo/Desktop/buildpackage/grass6/dist.i686-pc-linux-gnu ; tar cBf - man | (cd /usr/local/grass-6.3.cvs ; tar xBf - ) 2>/dev/null make[1]: [real-install] Error 2 (ignored) cd /home/paolo/Desktop/buildpackage/grass6/dist.i686-pc-linux-gnu ; tar cBf - scripts | (cd /usr/local/grass-6.3.cvs ; tar xBf - ) 2>/dev/null if [ 1 -eq 1 ] ; then cd /home/paolo/Desktop/buildpackage/grass6/dist.i686-pc-linux-gnu ; tar cBf - - locale | (cd /usr/local/grass-6.3.cvs ; tar xBf - ) 2>/dev/null ; fi make[1]: *** [real-install] Error 2 make[1]: Leaving directory `/home/paolo/Desktop/buildpackage/grass6' make: *** [install] Error 2 Markus Neteler ha scritto: > On Mon, Apr 02, 2007 at 11:56:49AM +0200, Paolo Cavallini wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi all. >> I'm getting an error during compilation (yet, I tried running make >> distclean, but it doesn't help). >> Any explanation? >> Thanks. >> pc >> ===================================== >> Installing with make install... >> >> ======================= Installation results ======================= >> echo /home/paolo/Desktop/buildpackage/grass6/bin.i686-pc-linux-gnu/grass63 >> /home/paolo/Desktop/buildpackage/grass6/bin.i686-pc-linux-gnu/grass63 >> /bin/sh: line 5: [: =: unary operator expected > ... > > Fixed in CVS. MACOSX_APP must be quoted in the Makefile. > > Markus > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > - -- Paolo Cavallini http://www.faunalia.it/pc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGESBg/NedwLUzIr4RApg9AJ9fiv/VjmbUEvze9El5gCzHCRvvwQCfdeas A9ulRamKHmjhCybQAvaF5lk= =007o -----END PGP SIGNATURE----- From carlos.grohmann at gmail.com Mon Apr 2 17:36:00 2007 From: carlos.grohmann at gmail.com (=?ISO-8859-1?Q?Carlos_"Gu=E2no"_Grohmann?=) Date: Mon Apr 2 17:36:03 2007 Subject: [GRASS-dev] call other grasss module inside a C program Message-ID: Hello, what is the best way to use a GRASS existing module (like v.surf.rst) from inside a C program? thanks -- +-----------------------------------------------------------+ Carlos Henrique Grohmann - Guano Geologist M.Sc - Doctorate Student at IGc-USP - Brazil Linux User #89721 - carlos dot grohmann at gmail dot com +-----------------------------------------------------------+ _________________ "Good morning, doctors. I have taken the liberty of removing Windows 95 from my hard drive." --The winning entry in a "What were HAL's first words" contest judged by 2001: A SPACE ODYSSEY creator Arthur C. Clarke From jachym.cepicky at gmail.com Mon Apr 2 17:45:04 2007 From: jachym.cepicky at gmail.com (Jachym Cepicky) Date: Mon Apr 2 17:45:07 2007 Subject: [GRASS-dev] call other grasss module inside a C program In-Reply-To: References: Message-ID: hi, for example take a look at raster/r.report/stats.c jachym 2007/4/2, Carlos Gu?no Grohmann : > Hello, > > what is the best way to use a GRASS existing module (like v.surf.rst) > from inside a C program? > > thanks > > -- > +-----------------------------------------------------------+ > Carlos Henrique Grohmann - Guano > Geologist M.Sc - Doctorate Student at IGc-USP - Brazil > Linux User #89721 - carlos dot grohmann at gmail dot com > +-----------------------------------------------------------+ > _________________ > "Good morning, doctors. I have taken the liberty of removing Windows > 95 from my hard drive." > --The winning entry in a "What were HAL's first words" contest judged > by 2001: A SPACE ODYSSEY creator Arthur C. Clarke > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > -- Jachym Cepicky e-mail: jachym.cepicky gmail com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub From grass-codei at wald.intevation.org Mon Apr 2 21:44:26 2007 From: grass-codei at wald.intevation.org (grass-codei@wald.intevation.org) Date: Mon Apr 2 21:44:29 2007 Subject: [GRASS-dev] [grass-code I][352] raster color table change is not honoured on Map Display Message-ID: <20070402194426.AE3C81973F8C@pyrosoma.intevation.org> code I item #352, was opened at 2007-04-02 21:44 Status: Open Priority: 3 Submitted By: Maciej Sieczka (msieczka) Assigned to: Nobody (None) Summary: raster color table change is not honoured on Map Display Issue type: module bug Issue status: None GRASS version: CVS HEAD GRASS component: gis.m Operating system: all Operating system version: GRASS CVS checkout date, if applies (YYMMDD): 070402 Initial Comment: To reproduce, in spearfish: 1. add a raster to gis.m layer list, eg. the landuse 2. display it 3. r.colors landuse color=random 4. refresh display - the color table on display remains unchanged To make gis.m honour color table change, one has to reove the raster, add the raster again and re-display it. Maciek ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=352&group_id=21 From woklist at kyngchaos.com Mon Apr 2 22:30:12 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Mon Apr 2 22:30:27 2007 Subject: [GRASS-dev] possible etc file finder function Message-ID: Per my note about accessing user addon modules outside the GRASS application installation, such as in their home folder, I made an attempt at a function to locate a file in configured etc locations. I'm not much of a C programmer, and really I just modified a copy of find_file.c. Tear it apart and give it to me straight ^_^ The 3 possible etc folder locations it will look are: 1: the user's home folder 2: a globa/system folder 3: the GRASS application folder (or, the current default) It needs a couple configured vars to set the user and global folders. I put these in in a new etc.h. The user dir is relative to HOME and the global should be an absolute dir. ie, for OSX: #define ETC_PATH_USER "Library/GRASS/6.3/Modules/etc" #define ETC_PATH_GLOBAL "/Library/GRASS/6.3/Modules/etc" Existing, builtin, modules don't need to be changed to use this. It's really only necessary for external modules that have support data files. v.in.dwg would be an example, if that was built and installed outside the GRASS application (and that is probably necessary for binary distributions). -------------- next part -------------- Skipped content of type multipart/appledouble-------------- next part -------------- ----- William Kyngesburye http://www.kyngchaos.com/ "Mon Dieu! but they are all alike. Cheating, murdering, lying, fighting, and all for things that the beasts of the jungle would not deign to possess - money to purchase the effeminate pleasures of weaklings. And yet withal bound down by silly customs that make them slaves to their unhappy lot while firm in the belief that they be the lords of creation enjoying the only real pleasures of existence.... - the wisdom of Tarzan From tutey at o2.pl Mon Apr 2 23:31:06 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Mon Apr 2 23:31:10 2007 Subject: [GRASS-dev] enable forwarding all GRASS GForge traffic to grass-dev ML? Message-ID: <4611761A.70609@o2.pl> Hi! Currently it is not possible to CC any email when replying to a ticket from the GForge trackers. Neither it is possible to CC GForge via email. This hampers the information flow. I have reported this issue to GForge maintainers several weeks ago [1], but there is no solution foreseen it seems. In the report I mention, I wrote that propably enabling such a permanent CC to grass-dev ML might not be welcome, as the list is high traffic anyway. However, thinking about it more, I came to conclusion that the extra traffic would be less problematic than the lack of info flow we face currently. Given the cons and pros, would anybody object enabling all the discussion taking place in GRASS GForge trackers to be forwarded to grass-dev ML? At least until a CC option becomes available in GForge. Please say what you think. Maciek [1]http://wald.intevation.org/tracker/index.php?func=detail&aid=300&group_id=1&atid=162 From joel.pitt at gmail.com Tue Apr 3 02:34:29 2007 From: joel.pitt at gmail.com (Joel Pitt) Date: Tue Apr 3 02:34:32 2007 Subject: [GRASS-dev] r.mapcalc addition In-Reply-To: References: <17724.57228.750143.658056@cerise.gclements.plus.com> <20061024121511.7d38f93a.hamish_nospam@yahoo.com> <17725.25974.885838.30852@cerise.gclements.plus.com> <20061024150200.550b414e.hamish_nospam@yahoo.com> <17726.28802.640455.412055@cerise.gclements.plus.com> Message-ID: Hi there, I was just checking the latest CVS and saw that my r.mapcalc addition hadn't been added yet. I was hoping someone with appropriate permissions could do so. My dispersal simulation tool (which I hope to release properly in a few months) requires the addition to function correctly. Much thanks, Joel ---------- Forwarded message ---------- From: Joel Pitt Date: Oct 26, 2006 9:39 PM Subject: Re: [GRASS-dev] r.mapcalc addition To: Glynn Clements Cc: Hamish , grass-dev@grass.itc.it On 10/25/06, Glynn Clements wrote: > > However, I'll follow Glynn's suggestion and read the seed in the > > evaluate() function. This will be more robust if other functions are > > implemented that call the RNG. > > > > On this topic, would there be any call for implementing more > > complicated probability distribution functions? Or is the philosophy > > of mapcalc to have the simplest elements necessary? > > A Gaussian distribution might be useful, as you can't readily > implement that using existing r.mapcalc functions (the usual > implementation uses iteration, which r.mapcalc doesn't support). > > For enhancements which might be useful to other users, I'd suggest > posting an announcement (or the code itself) to the list. If enough > people express an interest in having the functionality built in, we > can add it. > > Adding new functions is quite straightforward; OTOH, we don't want to > bloat r.mapcalc with code which is unlikely to be used by anyone but > its author. > > For more complex tasks, there's always R/GRASS. r.mapcalc will always > be bound by its structural limitations (row-by-row processing, > inability to define new functions, etc). I've attached a diff of evaluate.c and the related html files that I'm aware of. Turns out it was alot simpler adding the functionality as a environment variable :) -- -Joel "Wish not to seem, but to be, the best." -- Aeschylus -- -Joel "Unless you try to do something beyond what you have mastered, you will never grow." -C.R. Lawton -------------- next part -------------- A non-text attachment was scrubbed... Name: r.mapcalc.diff Type: text/x-patch Size: 2419 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070403/ffc7ac60/r.mapcalc.bin From hamish_nospam at yahoo.com Tue Apr 3 02:53:45 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Apr 3 02:53:51 2007 Subject: [GRASS-dev] enable forwarding all GRASS GForge traffic to grass-dev ML? In-Reply-To: <4611761A.70609@o2.pl> References: <4611761A.70609@o2.pl> Message-ID: <20070403125345.14b0ede6.hamish_nospam@yahoo.com> Maciej Sieczka wrote: > > In the report I mention, I wrote that propably enabling such a > permanent CC to grass-dev ML might not be welcome, as the list is high > traffic anyway. However, thinking about it more, I came to conclusion > that the extra traffic would be less problematic than the lack of info > flow we face currently. I agree. > Given the cons and pros, would anybody object enabling all the > discussion taking place in GRASS GForge trackers to be forwarded to > grass-dev ML? At least until a CC option becomes available in GForge. it would be nice if the cc'd emails only contained new bug comments. * skip messages from minor tracker edits. eg "priority changed to ..." * don't include full bug history in each email, only the newest comment. otherwise too much noise. at minimum a "cc" field in the bug tracker would let us manually enter grass-dev, as the old system did. Maybe add grass-dev as an interested party in the bug report? Also how to enable reply-to-bug from grass-dev? thanks, Hamish From glynn at gclements.plus.com Tue Apr 3 04:27:20 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Apr 3 04:27:23 2007 Subject: [GRASS-dev] compile error? In-Reply-To: <4D9BA27B-BA00-4F32-A695-4E0B4EAB64DD@kyngchaos.com> References: <4610D361.7050207@faunalia.it> <20070402143534.GC3154@bartok.itc.it> <4D9BA27B-BA00-4F32-A695-4E0B4EAB64DD@kyngchaos.com> Message-ID: <17937.48008.929205.616939@cerise.gclements.plus.com> William Kyngesburye wrote: > > Fixed in CVS. MACOSX_APP must be quoted in the Makefile. > > Would this also affect when it's used in ifeq() ? ie: > > ifeq ($(MACOSX_APP),1) No, that's okay. It's only in (some) shell commands where it needs to be quoted. -- Glynn Clements From glynn at gclements.plus.com Tue Apr 3 04:30:37 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Apr 3 04:30:40 2007 Subject: [GRASS-dev] compile error? In-Reply-To: <46112060.4090304@faunalia.it> References: <4610D361.7050207@faunalia.it> <20070402143534.GC3154@bartok.itc.it> <46112060.4090304@faunalia.it> Message-ID: <17937.48205.344099.730263@cerise.gclements.plus.com> Paolo Cavallini wrote: > Thanks. However, it still fails: > > Installing with make install... > > ========================= Installation results ====================== > echo /home/paolo/Desktop/buildpackage/grass6/bin.i686-pc-linux-gnu/grass63 > /home/paolo/Desktop/buildpackage/grass6/bin.i686-pc-linux-gnu/grass63 > make[1]: Entering directory `/home/paolo/Desktop/buildpackage/grass6' > test -d /usr/local/grass-6.3.cvs || mkdir -p -m 755 /usr/local/grass-6.3.cvs > test -d /usr/local/bin || mkdir -p -m 755 /usr/local/bin > sed -e "s#^GISBASE.*#GISBASE=/usr/local/grass-6.3.cvs#" > /home/paolo/Desktop/buildpackage/grass6/bin.i686-pc-linux-gnu/grass63 > > /usr/local/bin/grass63 > chmod a+x /usr/local/bin/grass63 > sed -e "s#^WINGISBASE.*#WINGISBASE=/usr/local/grass-6.3.cvs#" /home/paolo/Desktop/buildpackage/grass6/bin.i686-pc-linux-gnu/grass63.bat > /usr/local/bin/grass63.bat > chmod a+x /usr/local/bin/grass63.bat > cd /home/paolo/Desktop/buildpackage/grass6/dist.i686-pc-linux-gnu ; tar cBf - bin | (cd /usr/local/grass-6.3.cvs ; tar xBf - ) 2>/dev/null > make[1]: [real-install] Error 2 (ignored) > cd /home/paolo/Desktop/buildpackage/grass6/dist.i686-pc-linux-gnu ; tar cBf - bwidget | (cd /usr/local/grass-6.3.cvs ; tar xBf - ) 2>/dev/null > cd /home/paolo/Desktop/buildpackage/grass6/dist.i686-pc-linux-gnu ; tar cBf - docs | (cd /usr/local/grass-6.3.cvs ; tar xBf - ) 2>/dev/null > make[1]: [real-install] Error 2 (ignored) > cd /home/paolo/Desktop/buildpackage/grass6/dist.i686-pc-linux-gnu ; tar cBf - driver | (cd /usr/local/grass-6.3.cvs ; tar xBf - ) 2>/dev/null > make[1]: [real-install] Error 2 (ignored) > cd /home/paolo/Desktop/buildpackage/grass6/dist.i686-pc-linux-gnu ; tar cBf - etc | (cd /usr/local/grass-6.3.cvs ; tar xBf - ) 2>/dev/null > make[1]: [real-install] Error 2 (ignored) > cd /home/paolo/Desktop/buildpackage/grass6/dist.i686-pc-linux-gnu ; tar cBf - fonts | (cd /usr/local/grass-6.3.cvs ; tar xBf - ) 2>/dev/null > cd /home/paolo/Desktop/buildpackage/grass6/dist.i686-pc-linux-gnu ; tar cBf - man | (cd /usr/local/grass-6.3.cvs ; tar xBf - ) 2>/dev/null > make[1]: [real-install] Error 2 (ignored) > cd /home/paolo/Desktop/buildpackage/grass6/dist.i686-pc-linux-gnu ; tar cBf - scripts | (cd /usr/local/grass-6.3.cvs ; tar xBf - ) 2>/dev/null > if [ 1 -eq 1 ] ; then cd /home/paolo/Desktop/buildpackage/grass6/dist.i686-pc-linux-gnu ; tar cBf - - locale | (cd /usr/local/grass-6.3.cvs ; tar xBf - ) 2>/dev/null ; fi Can you try running the failing commands manually without the "2>/dev/null", e.g. cd /home/paolo/Desktop/buildpackage/grass6/dist.i686-pc-linux-gnu tar cBf - bin | (cd /usr/local/grass-6.3.cvs ; tar xBf - ) -- Glynn Clements From glynn at gclements.plus.com Tue Apr 3 04:37:16 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Apr 3 04:37:17 2007 Subject: [GRASS-dev] possible etc file finder function In-Reply-To: References: Message-ID: <17937.48604.33930.960338@cerise.gclements.plus.com> William Kyngesburye wrote: > Per my note about accessing user addon modules outside the GRASS > application installation, such as in their home folder, I made an > attempt at a function to locate a file in configured etc locations. > > I'm not much of a C programmer, and really I just modified a copy of > find_file.c. Tear it apart and give it to me straight ^_^ > > The 3 possible etc folder locations it will look are: > > 1: the user's home folder > 2: a globa/system folder > 3: the GRASS application folder (or, the current default) > > It needs a couple configured vars to set the user and global > folders. I put these in in a new etc.h. The user dir is relative to > HOME and the global should be an absolute dir. ie, for OSX: > > #define ETC_PATH_USER "Library/GRASS/6.3/Modules/etc" > #define ETC_PATH_GLOBAL "/Library/GRASS/6.3/Modules/etc" > > Existing, builtin, modules don't need to be changed to use this. > It's really only necessary for external modules that have support > data files. v.in.dwg would be an example, if that was built and > installed outside the GRASS application (and that is probably > necessary for binary distributions). I don't think that what you are trying do is practical. Add-on modules should just go into $GISBASE. However, if you want to make a module look elsewhere for its data files, use an environment variable rather than a compile-time setting. -- Glynn Clements From glynn at gclements.plus.com Tue Apr 3 04:51:51 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Apr 3 04:51:54 2007 Subject: [GRASS-dev] r.mapcalc addition In-Reply-To: References: <17724.57228.750143.658056@cerise.gclements.plus.com> <20061024121511.7d38f93a.hamish_nospam@yahoo.com> <17725.25974.885838.30852@cerise.gclements.plus.com> <20061024150200.550b414e.hamish_nospam@yahoo.com> <17726.28802.640455.412055@cerise.gclements.plus.com> Message-ID: <17937.49479.495381.462519@cerise.gclements.plus.com> Joel Pitt wrote: > Hi there, I was just checking the latest CVS and saw that my r.mapcalc > addition hadn't been added yet. > > I was hoping someone with appropriate permissions could do so. Done. -- Glynn Clements From kyngchaos at kyngchaos.com Tue Apr 3 05:32:46 2007 From: kyngchaos at kyngchaos.com (William Kyngesburye) Date: Tue Apr 3 05:33:02 2007 Subject: [GRASS-dev] possible etc file finder function In-Reply-To: <17937.48604.33930.960338@cerise.gclements.plus.com> References: <17937.48604.33930.960338@cerise.gclements.plus.com> Message-ID: <5C6FDF07-BB9F-4E9C-987D-A6AF93461E4E@kyngchaos.com> On Apr 2, 2007, at 9:37 PM, Glynn Clements wrote: > I don't think that what you are trying do is practical. Add-on modules > should just go into $GISBASE. > As I suggested in a previous message to the list, putting addon modules in GISBASE is actually the impractical part. http://grass.itc.it/pipermail/grass-dev/2007-March/029975.html Especiallly on OSX, *adding* to an already installed application (.app package) is not recommended. And a non-admin user will simply not be able to do that. > However, if you want to make a module look elsewhere for its data > files, use an environment variable rather than a compile-time setting. > Fully controlling by the env var is probably a good idea, so it's like PATH and [DY]LD_LIBRARY_PATH. hmmm. I'd have to figure out how to split strings in C to reduce it to one env var that works like the other env vars. Any comments on the C itself? I wasn't sure about memory allocation stuff, I'm not good with that. ----- William Kyngesburye http://www.kyngchaos.com/ "This is a question about the past, is it? ... How can I tell that the past isn't a fiction designed to account for the discrepancy between my immediate physical sensations and my state of mind?" - The Ruler of the Universe From joel.pitt at gmail.com Tue Apr 3 05:48:09 2007 From: joel.pitt at gmail.com (Joel Pitt) Date: Tue Apr 3 05:48:11 2007 Subject: [GRASS-dev] No longer able to open a mapset by symbolic link Message-ID: Hi all, I just retrieved the latest weekly CVS snapshot for GRASS and found I'm no longer able to access mapsets that are referred to by symbolic links in linux. Is this intended behaviour (possibly related to the windows port)? Or a bug? Strangely the symbolic link is displayed as being an available mapset, but when trying to change to that mapset the mapset is said to not exist: ---- GRASS 6.3.cvs (nzmg):~/gis_databases/nzmg > g.mapsets mapset=test2 ERROR: [test2] - no such mapset Available mapsets: PERMANENT gypsy_moth lhumile lhumile.old test test2 ---- test2 is a copy of test, but in ~/: ---- GRASS 6.3.cvs (nzmg):~/gis_databases/nzmg > ls gypsy_moth lhumile -> /media/simulations/gis_databases/nzmg/lhumile lhumile.old PERMANENT test test2 -> /home/joel/test2/ ---- Permission of all the files/directories look fine. I'll submit a bug request, but wasn't sure whether this behaviour has been discussed and decided as intended. I hope not, because I use it to separate out simulation results (huge and stored on an external server/HDD) and input data for the simulations (stored locally). Thanks, -- -Joel "Unless you try to do something beyond what you have mastered, you will never grow." -C.R. Lawton From michael.barton at asu.edu Tue Apr 3 05:59:07 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Apr 3 05:59:14 2007 Subject: [GRASS-dev] menu help In-Reply-To: <200703291936.38067.rnuske@gwdg.de> Message-ID: These are nice. They cover some of the potential needs, though I'm not sure if they do all of them. Michael On 3/29/07 10:36 AM, "Robert Nuske" wrote: > >> We could also use an artistic type for icon design. I already need a couple >> that don?t yet exist (for overlay layers and map display decorations). > > sorry, I am not, > but what about the Silk Icons > > http://www.famfamfam.com/lab/icons/silk/ > > that set contains some nice geo-icons > > cheers, > robert > > __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Tue Apr 3 06:08:20 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Apr 3 06:08:29 2007 Subject: [GRASS-dev] menu help In-Reply-To: <1a486f560703300225t46fa5456g432e19c1e819f727@mail.gmail.com> Message-ID: Daniel, I can help with the TclTk part. But I need to know what to do. I am not familiar with JSON. Michael On 3/30/07 2:25 AM, "Daniel Calvelo" wrote: > On 3/29/07, Hamish wrote: >> Michael Barton wrote: >>> >>> If anyone out there who is not working on the other code is feeling >>> energetic and/or has a bit of time on their hands, we could use having >>> the wxPython menu updated to match all the commands and structure now >>> in the TclTk one. >> >> could a script do it? > > For the most part, I think so. But in the tcl version (and also in the > python counterpart) there are some commands embedded in the > definitions. Those must be hand-tuned to each back-end. > > I suggest porting the menu structure to JSON (in preference of XML) > with special markers for these actions, and use the same source for > building both tcl and python guis. That would also allow for > different menu combinations switchable at run-time depending on user > preferences. (AFAICT wxGRASS does present a different interface > according to the "user level" in which it is started.) > > I could do the python part, but I'm practically illiterate in tcl. > >> automation is good. > > Absolutely. Just as duplication is bad... in code anyway. > > Daniel. __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From joel.pitt at gmail.com Tue Apr 3 06:16:15 2007 From: joel.pitt at gmail.com (Joel Pitt) Date: Tue Apr 3 06:16:18 2007 Subject: [GRASS-dev] Re: No longer able to open a mapset by symbolic link In-Reply-To: References: Message-ID: After searching through the code, the problem seems to be: if (stat (path, &info) != 0) return -1; changing to: if (G_lstat (path, &info) != 0) return -1; if (!S_ISDIR(info.st_mode)) return -1; in lib/gis/mapset_msc.c - and S_ISDIR, from what comments say, doesn't treat links as directories, even if they point to one. -J On 4/3/07, Joel Pitt wrote: > Hi all, > > I just retrieved the latest weekly CVS snapshot for GRASS and found > I'm no longer able to access mapsets that are referred to by symbolic > links in linux. > > Is this intended behaviour (possibly related to the windows port)? Or a bug? > > Strangely the symbolic link is displayed as being an available mapset, > but when trying to change to that mapset the mapset is said to not > exist: > > ---- > GRASS 6.3.cvs (nzmg):~/gis_databases/nzmg > g.mapsets mapset=test2 > ERROR: [test2] - no such mapset > > Available mapsets: > > PERMANENT gypsy_moth lhumile lhumile.old test test2 > ---- > test2 is a copy of test, but in ~/: > ---- > GRASS 6.3.cvs (nzmg):~/gis_databases/nzmg > ls > gypsy_moth > lhumile -> /media/simulations/gis_databases/nzmg/lhumile > lhumile.old > PERMANENT > test > test2 -> /home/joel/test2/ > ---- > Permission of all the files/directories look fine. > > I'll submit a bug request, but wasn't sure whether this behaviour has > been discussed and decided as intended. I hope not, because I use it > to separate out simulation results (huge and stored on an external > server/HDD) and input data for the simulations (stored locally). > > Thanks, > -- > -Joel > > "Unless you try to do something beyond what you have mastered, you > will never grow." -C.R. Lawton > -- -Joel "Unless you try to do something beyond what you have mastered, you will never grow." -C.R. Lawton From glynn at gclements.plus.com Tue Apr 3 06:28:32 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Apr 3 06:29:21 2007 Subject: [GRASS-dev] No longer able to open a mapset by symbolic link In-Reply-To: References: Message-ID: <17937.55280.228654.831177@cerise.gclements.plus.com> Joel Pitt wrote: > I just retrieved the latest weekly CVS snapshot for GRASS and found > I'm no longer able to access mapsets that are referred to by symbolic > links in linux. > > Is this intended behaviour (possibly related to the windows port)? Or a bug? > > Strangely the symbolic link is displayed as being an available mapset, > but when trying to change to that mapset the mapset is said to not > exist: > > ---- > GRASS 6.3.cvs (nzmg):~/gis_databases/nzmg > g.mapsets mapset=test2 > ERROR: [test2] - no such mapset > > Available mapsets: > > PERMANENT gypsy_moth lhumile lhumile.old test test2 > ---- > test2 is a copy of test, but in ~/: > ---- > GRASS 6.3.cvs (nzmg):~/gis_databases/nzmg > ls > gypsy_moth > lhumile -> /media/simulations/gis_databases/nzmg/lhumile > lhumile.old > PERMANENT > test > test2 -> /home/joel/test2/ > ---- > Permission of all the files/directories look fine. > > I'll submit a bug request, but wasn't sure whether this behaviour has > been discussed and decided as intended. I hope not, because I use it > to separate out simulation results (huge and stored on an external > server/HDD) and input data for the simulations (stored locally). AFAIK, having symlinks to mapset directories has never been intentionally supported; it just happened to work. -- Glynn Clements From glynn at gclements.plus.com Tue Apr 3 06:35:07 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Apr 3 06:35:28 2007 Subject: [GRASS-dev] possible etc file finder function In-Reply-To: <5C6FDF07-BB9F-4E9C-987D-A6AF93461E4E@kyngchaos.com> References: <17937.48604.33930.960338@cerise.gclements.plus.com> <5C6FDF07-BB9F-4E9C-987D-A6AF93461E4E@kyngchaos.com> Message-ID: <17937.55675.14086.123958@cerise.gclements.plus.com> William Kyngesburye wrote: > Any comments on the C itself? I wasn't sure about memory allocation > stuff, I'm not good with that. The main issue I see is that sprintf() doesn't return a pointer to the buffer, so you can't you it as an argument to access(). Also, what is "if (ETC_PATH_USER)" etc supposed to be testing? -- Glynn Clements From joel.pitt at gmail.com Tue Apr 3 06:41:04 2007 From: joel.pitt at gmail.com (Joel Pitt) Date: Tue Apr 3 06:41:09 2007 Subject: [GRASS-dev] No longer able to open a mapset by symbolic link In-Reply-To: <17937.55280.228654.831177@cerise.gclements.plus.com> References: <17937.55280.228654.831177@cerise.gclements.plus.com> Message-ID: On 4/3/07, Glynn Clements wrote: > > I'll submit a bug request, but wasn't sure whether this behaviour has > > been discussed and decided as intended. I hope not, because I use it > > to separate out simulation results (huge and stored on an external > > server/HDD) and input data for the simulations (stored locally). > > AFAIK, having symlinks to mapset directories has never been > intentionally supported; it just happened to work. I've worked out a simple solution. In lib/gis/paths.c : int G_lstat(const char *file_name, struct stat *buf) { #ifdef __MINGW32__ return stat(file_name, buf); #else return lstat(file_name, buf); #endif } lstat(...) stats the link itself. Is there any reason why stat(...), which follows a link instead, can't be used for both platforms? -- -Joel "Unless you try to do something beyond what you have mastered, you will never grow." -C.R. Lawton From glynn at gclements.plus.com Tue Apr 3 07:29:31 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Apr 3 07:30:35 2007 Subject: [GRASS-dev] No longer able to open a mapset by symbolic link In-Reply-To: References: <17937.55280.228654.831177@cerise.gclements.plus.com> Message-ID: <17937.58939.431629.374924@cerise.gclements.plus.com> Joel Pitt wrote: > > > I'll submit a bug request, but wasn't sure whether this behaviour has > > > been discussed and decided as intended. I hope not, because I use it > > > to separate out simulation results (huge and stored on an external > > > server/HDD) and input data for the simulations (stored locally). > > > > AFAIK, having symlinks to mapset directories has never been > > intentionally supported; it just happened to work. > > I've worked out a simple solution. In lib/gis/paths.c : > > int G_lstat(const char *file_name, struct stat *buf) > { > #ifdef __MINGW32__ > return stat(file_name, buf); > #else > return lstat(file_name, buf); > #endif > } > > lstat(...) stats the link itself. Is there any reason why stat(...), > which follows a link instead, can't be used for both platforms? Some of the uses of G_lstat() require the use of lstat(); e.g. G_remove() uses it for directory traversal, which should treat symlinks as leaf nodes (i.e. shouldn't traverse symlinks to directories as if they were directories). It may be worth having a separate G_stat() function, but G_lstat() cannot be changed. -- Glynn Clements From cavallini at faunalia.it Tue Apr 3 08:20:16 2007 From: cavallini at faunalia.it (Paolo Cavallini) Date: Tue Apr 3 08:20:23 2007 Subject: [GRASS-dev] compile error? In-Reply-To: <17937.48205.344099.730263@cerise.gclements.plus.com> References: <4610D361.7050207@faunalia.it> <20070402143534.GC3154@bartok.itc.it> <46112060.4090304@faunalia.it> <17937.48205.344099.730263@cerise.gclements.plus.com> Message-ID: <4611F220.2090406@faunalia.it> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Glynn. Thanks for help. I removed the old directory (/usr/local/grass-6.3.cvs), and make install went smoothly. All the best. pc Glynn Clements ha scritto: > Paolo Cavallini wrote: > >> Thanks. However, it still fails: >> ... > Can you try running the failing commands manually without the > "2>/dev/null", e.g. > > cd /home/paolo/Desktop/buildpackage/grass6/dist.i686-pc-linux-gnu > tar cBf - bin | (cd /usr/local/grass-6.3.cvs ; tar xBf - ) > - -- Paolo Cavallini http://www.faunalia.it/pc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGEfIg/NedwLUzIr4RAqEZAJwPJfqkul9sJj4Gk3Cshqjh2UKXiACePRwz pc3jKz8wOckp5NThCOn/c7E= =kOr3 -----END PGP SIGNATURE----- From jachym.cepicky at gmail.com Tue Apr 3 10:18:03 2007 From: jachym.cepicky at gmail.com (Jachym Cepicky) Date: Tue Apr 3 10:18:06 2007 Subject: [GRASS-dev] Re: discussion: replacing ps.map In-Reply-To: References: Message-ID: Hi, for having general picture, here [1] is PDF [11MB] with map symbols used in czech forestry (NOTE: symbol pictures are starting on page 31). It would be great to be able to create such maps in GRASS. Currently, I think that the biggest problem is line styling. Maybe it would be interesting to follow the polygon way: If lines could be drawn using some eps pattern, this would be solved. Jachym [1] http://les-ejk.cz/tmp/czech-forest-maps.pdf 2007/3/27, Jachym Cepicky : > Hallo, > > while ps.map is nice tool for creating hard copy maps in GRASS, it is > not sufficient for some more complicated tasks and correct me if I'm > wrong, there is no _real_ maintainer of it's code, who would be able > to write new functions for it. > > Now, when new wxPython GUI is stepping forward, I'm thinking about, > how to write future GRASS mapcomposer. > > I see two interesting tools in today's FOSS4G world, which could be > used as back end for new Mapcomposer, and which would so replace > functionality of ps.map: > > 1) UMN MapServer > 2) GMT > > MapServer > ------------- > UMN MapServer is far known tool, which has well documented > configuration file and large community. I suppose, most of the > GRASS-users are already familiar with it. MapServer produces nice > graphical output in desired resolution and format. I is possible to > use PDF as output format: > http://mapserver.gis.umn.edu/docs/howto/pdf-output Tasks, like label > placement and so on are already solved in MapServer. GRASS would > became also a GUI for MapServer configuration file. It is possible to > access GRASS (vectors and rasters) from MapServer (both are using > gdal). > > Size (ubuntu package): 7548kB + python-mapscript 1500 kB > > GMT > ------ > Sorry, I do not know much about GMT. I just know, this is a tool, > which is able to create nice maps and there are already some bindings > for GRASS. I would say, it has not as large community as MapServer > has. > > Size (ubuntu package): 9904 kB > > Both solutions are introducing new dependency. The benefit would be > "outsourcing" of our efforts. Why to reinvent a wheel, if there are > already tools, which are able to produce nice maps, tested and used? > > What do you think? Any experience with some of this tools? I would > vote for MapServer. > > Jachym > -- > Jachym Cepicky > e-mail: jachym.cepicky gmail com > URL: http://les-ejk.cz > GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub > -- Jachym Cepicky e-mail: jachym.cepicky gmail com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub From neteler at itc.it Tue Apr 3 10:27:27 2007 From: neteler at itc.it (Markus Neteler) Date: Tue Apr 3 10:41:00 2007 Subject: [GRASS-dev] No longer able to open a mapset by symbolic link In-Reply-To: <17937.55280.228654.831177@cerise.gclements.plus.com> References: <17937.55280.228654.831177@cerise.gclements.plus.com> Message-ID: <46120FEF.3@itc.it> Glynn Clements wrote on 04/03/2007 06:28 AM: > Joel Pitt wrote: > > >> I just retrieved the latest weekly CVS snapshot for GRASS and found >> I'm no longer able to access mapsets that are referred to by symbolic >> links in linux. >> >> Is this intended behaviour (possibly related to the windows port)? Or a bug? >> ... > AFAIK, having symlinks to mapset directories has never been > intentionally supported; it just happened to work. > I am long term user of such mapset links, it would be a major problem for us to no longer have this possibility. Just to express interest in this issue... Markus ------------------ ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler ITC -> since 1 March 2007 Fondazione Bruno Kessler ------------------ From neteler at itc.it Tue Apr 3 10:36:26 2007 From: neteler at itc.it (Markus Neteler) Date: Tue Apr 3 10:41:03 2007 Subject: [GRASS-dev] enable forwarding all GRASS GForge traffic to grass-dev ML? In-Reply-To: <20070403125345.14b0ede6.hamish_nospam@yahoo.com> References: <4611761A.70609@o2.pl> <20070403125345.14b0ede6.hamish_nospam@yahoo.com> Message-ID: <4612120A.8040009@itc.it> Hamish wrote on 04/03/2007 02:53 AM: > ... > it would be nice if the cc'd emails only contained new bug comments. > * skip messages from minor tracker edits. > eg "priority changed to ..." > * don't include full bug history in each email, only the newest comment. > I also dislike that all stuff is included (you never find the relevant piece, also due to the "fancy" ordering style within the report. If someone wants the history, s/he can go to the tracker. > otherwise too much noise. at minimum a "cc" field in the bug tracker > would let us manually enter grass-dev, as the old system did. > Sounds like a good idea. > Maybe add grass-dev as an interested party in the bug report? > > Also how to enable reply-to-bug from grass-dev? > The current cc: noreply@wald.intevation.org is rather useless. thanks markus ------------------ ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler ITC -> since 1 March 2007 Fondazione Bruno Kessler ------------------ From glynn at gclements.plus.com Tue Apr 3 11:19:50 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Apr 3 11:19:55 2007 Subject: [GRASS-dev] Re: discussion: replacing ps.map In-Reply-To: References: Message-ID: <17938.7222.214580.238597@cerise.gclements.plus.com> Jachym Cepicky wrote: > for having general picture, here [1] is PDF [11MB] with map symbols > used in czech forestry (NOTE: symbol pictures are starting on page > 31). > > It would be great to be able to create such maps in GRASS. Currently, > I think that the biggest problem is line styling. Maybe it would be > interesting to follow the polygon way: If lines could be drawn using > some eps pattern, this would be solved. > > Jachym > > [1] http://les-ejk.cz/tmp/czech-forest-maps.pdf I get a 404 "Not Found" error for that URL. While you can fill areas (including stroked paths) with arbitrary patterns, those patterns won't be oriented to follow the path. If you want complex line styles, you generally have to do most of the work yourself. -- Glynn Clements From glynn at gclements.plus.com Tue Apr 3 11:34:45 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Apr 3 11:34:48 2007 Subject: [GRASS-dev] No longer able to open a mapset by symbolic link In-Reply-To: <46120FEF.3@itc.it> References: <17937.55280.228654.831177@cerise.gclements.plus.com> <46120FEF.3@itc.it> Message-ID: <17938.8117.39792.631929@cerise.gclements.plus.com> Markus Neteler wrote: > >> I just retrieved the latest weekly CVS snapshot for GRASS and found > >> I'm no longer able to access mapsets that are referred to by symbolic > >> links in linux. > >> > >> Is this intended behaviour (possibly related to the windows port)? Or a bug? > >> ... > > AFAIK, having symlinks to mapset directories has never been > > intentionally supported; it just happened to work. > > I am long term user of such mapset links, it would be a major problem for us > to no longer have this possibility. Just to express interest in this > issue... In that case, we need to add a G_stat(), and change some uses of G_lstat() to G_stat(). Current users of G_lstat() are: general/manage/lib/do_copy.c recursive_copy(), used by do_copy(), used by g.copy lib/gis/mapset_msc.c G__mapset_permissions(), G__mapset_permissions2() lib/gis/remove.c recursive_remove(), used by G_remove() lib/gis/unix_socks.c _get_make_sock_path(), used by G_sock_get_fname() lib/gis/user_config.c _make_toplevel(), _make_sublevels(), both used by G_rc_path() AFAICT, the problems are due to G__mapset_permissions() and/or G__mapset_permissions2(). These can probably be safely changed to use stat() instead. recursive_copy() and recursive_remove() perform directory traversal, which should only recurse into actual subdirectories, not symlinks to directories The other cases check whether a directory already exists prior to creating it. It's debatable what they should do if the chosen subdirectory name refers to an existing symlink. -- Glynn Clements From jachym.cepicky at gmail.com Tue Apr 3 12:01:14 2007 From: jachym.cepicky at gmail.com (Jachym Cepicky) Date: Tue Apr 3 12:01:16 2007 Subject: [GRASS-dev] Re: discussion: replacing ps.map In-Reply-To: <17938.7222.214580.238597@cerise.gclements.plus.com> References: <17938.7222.214580.238597@cerise.gclements.plus.com> Message-ID: Hi, 2007/4/3, Glynn Clements : > > Jachym Cepicky wrote: > > > for having general picture, here [1] is PDF [11MB] with map symbols > > used in czech forestry (NOTE: symbol pictures are starting on page > > 31). > > > > It would be great to be able to create such maps in GRASS. Currently, > > I think that the biggest problem is line styling. Maybe it would be > > interesting to follow the polygon way: If lines could be drawn using > > some eps pattern, this would be solved. > > > > Jachym > > > > [1] http://les-ejk.cz/tmp/czech-forest-maps.pdf > > I get a 404 "Not Found" error for that URL. sorry, I did not noticed, that the upload failed - I posted it here: http://wwwold.fle.czu.cz/~jachym/tmp/czech-forest-maps.pdf > > While you can fill areas (including stroked paths) with arbitrary > patterns, those patterns won't be oriented to follow the path. If you > want complex line styles, you generally have to do most of the work > yourself. > > -- > Glynn Clements > "Myself" means to edit the resulting Post Script file(?). Thanks Jachym -- Jachym Cepicky e-mail: jachym.cepicky gmail com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub From grass-codei at wald.intevation.org Tue Apr 3 12:35:58 2007 From: grass-codei at wald.intevation.org (grass-codei@wald.intevation.org) Date: Tue Apr 3 12:36:01 2007 Subject: [GRASS-dev] [grass-code I][353] g.mlist through gis.m in GRASS6.2 and 6.3 Message-ID: <20070403103558.809101800153@pyrosoma.intevation.org> code I item #353, was opened at 03/04/2007 10:35 Status: Open Priority: 3 Submitted By: Aldo Clerici (clerici) Assigned to: Nobody (None) Summary: g.mlist through gis.m in GRASS6.2 and 6.3 Issue type: other bad feature Issue status: None GRASS version: 6.2.1 GRASS component: gis.m Operating system: Linux Operating system version: GRASS CVS checkout date, if applies (YYMMDD): 070310 Initial Comment: In the g.mlist panel (File -> Manage maps and volumes -> List maps using expressions and 'wildcards') is written "map name search pattern, must be 'quoted'. (default:all):" Actually the option works only if the string is not quoted. A.Clerici ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=353&group_id=21 From glynn at gclements.plus.com Tue Apr 3 12:53:47 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Apr 3 12:53:51 2007 Subject: [GRASS-dev] Re: discussion: replacing ps.map In-Reply-To: References: <17938.7222.214580.238597@cerise.gclements.plus.com> Message-ID: <17938.12859.778482.880923@cerise.gclements.plus.com> Jachym Cepicky wrote: > > While you can fill areas (including stroked paths) with arbitrary > > patterns, those patterns won't be oriented to follow the path. If you > > want complex line styles, you generally have to do most of the work > > yourself. > > "Myself" means to edit the resulting Post Script file(?). I mean that the application has to draw styled lines using a sequence of primitives. E.g. if you want a double line (#1000 on p39), you have to draw two lines, with the correct offsets. If you want arrows, you have to place and draw each arrow-head. IOW, you can't just set a style which the "stroke" operator will then apply to a path. With the built-in line-stroking operation, the style is limited to a combination of colour (or fill pattern), dash pattern, caps, and joins. Any fill pattern is applied without reference to the line's alignment or orientation. -- Glynn Clements From glynn at gclements.plus.com Tue Apr 3 12:59:14 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Apr 3 12:59:15 2007 Subject: [GRASS-dev] [grass-code I][353] g.mlist through gis.m in GRASS6.2 and 6.3 In-Reply-To: <20070403103558.809101800153@pyrosoma.intevation.org> References: <20070403103558.809101800153@pyrosoma.intevation.org> Message-ID: <17938.13186.155120.876236@cerise.gclements.plus.com> grass-codei@wald.intevation.org wrote: > In the g.mlist panel (File -> Manage maps and volumes -> List maps > using expressions and 'wildcards') is written "map name search > pattern, must be 'quoted'. (default:all):" > Actually the option works only if the string is not quoted. IOW: option descriptions should not assume that the module is being run from a shell. Fixed in CVS. -- Glynn Clements From woklist at kyngchaos.com Tue Apr 3 16:00:59 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Tue Apr 3 16:01:15 2007 Subject: [GRASS-dev] possible etc file finder function In-Reply-To: <17937.55675.14086.123958@cerise.gclements.plus.com> References: <17937.48604.33930.960338@cerise.gclements.plus.com> <5C6FDF07-BB9F-4E9C-987D-A6AF93461E4E@kyngchaos.com> <17937.55675.14086.123958@cerise.gclements.plus.com> Message-ID: <8CB45BB3-04A1-4B36-A8D7-4843B5305133@kyngchaos.com> Yes, it's these sort of C details I have problems with. On Apr 2, 2007, at 11:35 PM, Glynn Clements wrote: > William Kyngesburye wrote: > >> Any comments on the C itself? I wasn't sure about memory allocation >> stuff, I'm not good with that. > > The main issue I see is that sprintf() doesn't return a pointer to the > buffer, so you can't you it as an argument to access(). > How would this be done, then? > Also, what is "if (ETC_PATH_USER)" etc supposed to be testing? > Testing whether it is not empty. I tried to use an example from elsewhere, but maybe the difference between a variable and a define makes this not usable? Though, if I switch to using an env var, this will not be needed. ----- William Kyngesburye http://www.kyngchaos.com/ "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 tutey at o2.pl Tue Apr 3 18:17:38 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Tue Apr 3 18:17:42 2007 Subject: [GRASS-dev] enable forwarding all GRASS GForge traffic to grass-dev ML? In-Reply-To: <4612120A.8040009@itc.it> References: <4611761A.70609@o2.pl> <20070403125345.14b0ede6.hamish_nospam@yahoo.com> <4612120A.8040009@itc.it> Message-ID: <46127E22.4090306@o2.pl> Markus Neteler wrote: > Hamish wrote on 04/03/2007 02:53 AM: >> ... >> it would be nice if the cc'd emails only contained new bug comments. >> * skip messages from minor tracker edits. >> eg "priority changed to ..." It is not possible currently. >> * don't include full bug history in each email, only the newest comment. Not possible currently either. Each email from GForge trackers will include the full thread. I didn't design it. That's how it is. > I also dislike that all stuff is included (you never find the relevant > piece, also due to the "fancy" ordering style within the report. That's a GForge bad feature which I can't fix. Maybe our GForge host, the Intevation, can. If they can't, maybe it is an issue in GForge in general and we should ask GForge devs to fix that. Before doing that, I'd love to hear from Intevation. Like I said, I have reported the problem few weeks ago [1] and there was not answer yet. > If someone wants the history, s/he can go to the tracker. >> otherwise too much noise. at minimum a "cc" field in the bug tracker >> would let us manually enter grass-dev, as the old system did. > Sounds like a good idea. That's what I asked for in [1]. >> Maybe add grass-dev as an interested party in the bug report? That's what I asked about in this thread. So, should I? Mind that each email from GForge trackers will include the whole thread (all messages), with the original message on top, the most recent next, and all older messages after that, in chronological order (newer first, older next). >> Also how to enable reply-to-bug from grass-dev? I don't think it is possible currently. And I'm not sure it is needed. Other widely used tracking systems (Bugzilla, Trac) require one to use an online interface too and users got used to it. What is missing in GForge, is an option to CC an arbitrary email, eg. a mailing list, when a consultation is needed. [1]http://wald.intevation.org/tracker/index.php?func=detail&aid=300&group_id=1&atid=162 Maciek From glynn at gclements.plus.com Tue Apr 3 18:24:16 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Apr 3 18:24:18 2007 Subject: [GRASS-dev] possible etc file finder function In-Reply-To: <8CB45BB3-04A1-4B36-A8D7-4843B5305133@kyngchaos.com> References: <17937.48604.33930.960338@cerise.gclements.plus.com> <5C6FDF07-BB9F-4E9C-987D-A6AF93461E4E@kyngchaos.com> <17937.55675.14086.123958@cerise.gclements.plus.com> <8CB45BB3-04A1-4B36-A8D7-4843B5305133@kyngchaos.com> Message-ID: <17938.32688.67724.353321@cerise.gclements.plus.com> William Kyngesburye wrote: > >> Any comments on the C itself? I wasn't sure about memory allocation > >> stuff, I'm not good with that. > > > > The main issue I see is that sprintf() doesn't return a pointer to the > > buffer, so you can't you it as an argument to access(). > > How would this be done, then? sprintf(path, "%s/%s/%s", G_home(), ETC_PATH_USER, name); if (access(path,0) == 0) ... > > Also, what is "if (ETC_PATH_USER)" etc supposed to be testing? > > > Testing whether it is not empty. I tried to use an example from > elsewhere, but maybe the difference between a variable and a define > makes this not usable? If you want to test whether a macro is defined, you need to use "#ifdef ..." or "#if defined(...)". -- Glynn Clements From dylan.beaudette at gmail.com Tue Apr 3 18:47:10 2007 From: dylan.beaudette at gmail.com (Dylan Beaudette) Date: Tue Apr 3 18:46:14 2007 Subject: [GRASS-dev] Re: discussion: replacing ps.map In-Reply-To: <17938.12859.778482.880923@cerise.gclements.plus.com> References: <17938.12859.778482.880923@cerise.gclements.plus.com> Message-ID: <200704030947.11204.dylan.beaudette@gmail.com> On Tuesday 03 April 2007 03:53, Glynn Clements wrote: > Jachym Cepicky wrote: > > > While you can fill areas (including stroked paths) with arbitrary > > > patterns, those patterns won't be oriented to follow the path. If you > > > want complex line styles, you generally have to do most of the work > > > yourself. > > > > "Myself" means to edit the resulting Post Script file(?). > > I mean that the application has to draw styled lines using a sequence > of primitives. E.g. if you want a double line (#1000 on p39), you have > to draw two lines, with the correct offsets. If you want arrows, you > have to place and draw each arrow-head. > > IOW, you can't just set a style which the "stroke" operator will then > apply to a path. With the built-in line-stroking operation, the style > is limited to a combination of colour (or fill pattern), dash pattern, > caps, and joins. Any fill pattern is applied without reference to the > line's alignment or orientation. I know that there has been considerable effort to make all of these things possible in GRASS-- if we do not go the route of using GMT as the hard-copy rendering engine, perhaps we can learn something from their postscript rendering and styling code...? just a thought -- Dylan Beaudette Soils and Biogeochemistry Graduate Group University of California at Davis 530.754.7341 From grass-codei at wald.intevation.org Tue Apr 3 19:29:40 2007 From: grass-codei at wald.intevation.org (grass-codei@wald.intevation.org) Date: Tue Apr 3 19:29:44 2007 Subject: [GRASS-dev] [grass-code I][354] v.digit freeze after "Display attributes" --> "New feature" Message-ID: <20070403172940.283531800153@pyrosoma.intevation.org> code I item #354, was opened at 2007-04-03 19:29 Status: Open Priority: 3 Submitted By: Maximilian Krambach (vagabund) Assigned to: Nobody (None) Summary: v.digit freeze after "Display attributes" --> "New feature" Issue type: module bug Issue status: None GRASS version: 6.2.1 GRASS component: tcl/tk GUI Operating system: Linux Operating system version: ubuntu edgy GRASS CVS checkout date, if applies (YYMMDD): Initial Comment: In v.digit, the following combination causes the v.digit gui (and the monitor v.digit is working with) to freeze. 1. display attribute of some feature [...some work...] 2. new feature --> entering new label; submitting [...] 3. display attribute of another feature [...] 4. new feature --> creating it the two windows freeze the moment the "label" form pops up The monitor then is unaccessible by grass, the vector map's topology is damaged afterwards, but can be restored with v.build; the last entered new feature is added to the map. When exiting grass via "exit", the two windows remain, but they can be closed when exiting grass by killing the terminal grass has been started with. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=354&group_id=21 From glynn at gclements.plus.com Tue Apr 3 20:36:08 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Apr 3 20:36:11 2007 Subject: [GRASS-dev] Re: discussion: replacing ps.map In-Reply-To: <200704030947.11204.dylan.beaudette@gmail.com> References: <17938.12859.778482.880923@cerise.gclements.plus.com> <200704030947.11204.dylan.beaudette@gmail.com> Message-ID: <17938.40600.115376.150678@cerise.gclements.plus.com> Dylan Beaudette wrote: > > > > While you can fill areas (including stroked paths) with arbitrary > > > > patterns, those patterns won't be oriented to follow the path. If you > > > > want complex line styles, you generally have to do most of the work > > > > yourself. > > > > > > "Myself" means to edit the resulting Post Script file(?). > > > > I mean that the application has to draw styled lines using a sequence > > of primitives. E.g. if you want a double line (#1000 on p39), you have > > to draw two lines, with the correct offsets. If you want arrows, you > > have to place and draw each arrow-head. > > > > IOW, you can't just set a style which the "stroke" operator will then > > apply to a path. With the built-in line-stroking operation, the style > > is limited to a combination of colour (or fill pattern), dash pattern, > > caps, and joins. Any fill pattern is applied without reference to the > > line's alignment or orientation. > > I know that there has been considerable effort to make all of these things > possible in GRASS-- if we do not go the route of using GMT as the hard-copy > rendering engine, perhaps we can learn something from their postscript > rendering and styling code...? According to the section on pen attributes: http://gmt.soest.hawaii.edu/gmt/doc/html/GMT_Docs/node56.html GMT doesn't appear to offer any line styles beyond those which are provided directly by PostScript. -- Glynn Clements From neteler at itc.it Tue Apr 3 21:12:39 2007 From: neteler at itc.it (Markus Neteler) Date: Tue Apr 3 21:12:41 2007 Subject: [GRASS-dev] nviz volume fails: unknown shade style returned in get_drawmode In-Reply-To: <1175620662.18887.2.camel@linuxmain.localhost> References: <45DF070A.7060006@itc.it> <17887.13792.924195.433541@cerise.gclements.plus.com> <20070304160313.GA16116@bartok.itc.it> <1173041718.8880.4.camel@linuxmain.localhost> <20070323203501.GA17758@bartok.itc.it> <1174695495.22185.4.camel@linuxmain.localhost> <20070403133518.GC30640@bartok.itc.it> <1175612506.11307.9.camel@linuxmain.localhost> <20070403153610.GB19042@bartok.itc.it> <1175620662.18887.2.camel@linuxmain.localhost> Message-ID: <20070403191239.GB5568@bartok.itc.it> Hi all, Bob was so kind to fix the NVIZ volume problem in CVS. Please test it, too. thanks, Bob! Markus On Tue, Apr 03, 2007 at 02:17:42PM -0300, Bob Covill wrote: > Hi Markus, > > I have submitted the fix to CVS. I have tested it by loading both from > the command line and the GUI, and it seems to work. If you could also > test to make sure this does not break anything else. > > -- > Bob > > On Tue, 2007-04-03 at 17:36 +0200, Markus Neteler wrote: > > Hi Bob, > > > > On Tue, Apr 03, 2007 at 12:01:45PM -0300, Bob Covill wrote: > > > Hi Markus, > > > > > > This does seem to be a mystery. I tried "g.region -dp" and it still > > > worked? > > > > I am on a 64bit box, may this be the difference? Or Redhat, > > or the gcc version or... > > > > > I then traced the error messages from below. I looked at how volumes are > > > loaded from the command line it appears that none of the attributes are > > > set (which is why it is complaining). When loaded from inside nviz there > > > is a call to Nnew_map_obj (to load the file) and then set_att to set the > > > attributes. > > > > > > I have attached a test version of map_obj.c from nviz/src for you to > > > try. Essentially I set some default atts when a volume is loaded. So > > > when you run > > > nviz el=dem500 vol=precip3d.500z50 > > > you should see > > > Loading Data > > > Update elev null mask > > > Loading Data > > > translating colors from fp > > > VOL DEBUG: set vol atts for 81721 > > > VOL DEBUG: done setting vol pars > > > recalculating normals... > > > > > > If this still crashes then there is something else going on, but we can > > > eliminate the above. If this does fix it then we should try and clean up > > > how volumes are loaded. > > > > > > I will keep my fingers crossed! > > > > Great job!! It works!! > > I don't manage to crash it any more... please submit it > > to CVS. > > > > thanks a million, > > > > Markus From grass-codei at wald.intevation.org Tue Apr 3 22:15:40 2007 From: grass-codei at wald.intevation.org (grass-codei@wald.intevation.org) Date: Tue Apr 3 22:15:43 2007 Subject: [GRASS-dev] [grass-code I][355] A lot of processes around while working Message-ID: <20070403201540.9ADDF1973F82@pyrosoma.intevation.org> code I item #355, was opened at 2007-04-03 22:15 Status: Open Priority: 3 Submitted By: Francesco Lovergine (frankie) Assigned to: Nobody (None) Summary: A lot of processes around while working Issue type: module bug Issue status: None GRASS version: 6.2.1 GRASS component: gis.m Operating system: Linux Operating system version: Debian sid GRASS CVS checkout date, if applies (YYMMDD): Initial Comment: While using georectifier a lot of pending defuncts appear for g.region. It seems (?) parent does not loop on wait() while managing SIGCHLD process as it should. All processes are closed when gm.tcl is terminated. frankie 5484 1 2 16:49 pts/11 00:00:32 wish /usr/lib/grass/etc/gm/gm.tcl -name gm_tcl frankie 5525 5484 0 16:49 pts/11 00:00:00 [g.region] frankie 5527 5484 0 16:50 pts/11 00:00:00 [g.region] frankie 5529 5484 0 16:50 pts/11 00:00:00 [g.region] frankie 5590 5484 0 16:50 pts/11 00:00:00 [g.region] frankie 5602 5484 0 16:50 pts/11 00:00:00 [g.region] frankie 5605 5484 0 16:50 pts/11 00:00:00 [g.region] frankie 5608 5484 0 16:50 pts/11 00:00:00 [g.region] frankie 5616 5484 0 16:50 pts/11 00:00:00 [g.region] frankie 5623 5484 0 16:50 pts/11 00:00:00 [g.region] frankie 5654 5484 0 16:50 pts/11 00:00:00 [g.region] frankie 5683 5484 0 16:50 pts/11 00:00:00 [g.region] frankie 5706 5484 0 16:51 pts/11 00:00:00 [g.region] frankie 5718 5484 0 16:51 pts/11 00:00:00 [g.region] frankie 5729 5484 0 16:51 pts/11 00:00:00 [g.region] frankie 5739 5484 0 16:52 pts/11 00:00:00 [g.region] frankie 5751 5484 0 16:52 pts/11 00:00:00 [g.region] frankie 5763 5484 0 16:52 pts/11 00:00:00 [g.region] frankie 5774 5484 0 16:53 pts/11 00:00:00 [g.region] frankie 5784 5484 0 16:53 pts/11 00:00:00 [g.region] frankie 5794 5484 0 16:53 pts/11 00:00:00 [g.region] frankie 5805 5484 0 16:54 pts/11 00:00:00 [g.region] frankie 5821 5484 0 16:54 pts/11 00:00:00 [g.region] frankie 5922 5484 0 16:55 pts/11 00:00:00 [g.region] frankie 5932 5484 0 16:56 pts/11 00:00:00 [g.region] frankie 5943 5484 0 16:56 pts/11 00:00:00 [g.region] frankie 5955 5484 0 16:57 pts/11 00:00:00 [g.region] frankie 5965 5484 0 16:57 pts/11 00:00:00 [g.region] frankie 6030 5484 0 16:58 pts/11 00:00:00 [g.region] frankie 6054 5484 0 16:58 pts/11 00:00:00 [g.region] frankie 6086 5484 0 16:58 pts/11 00:00:00 [g.region] frankie 6096 5484 0 16:58 pts/11 00:00:00 [g.region] frankie 6128 5484 0 16:58 pts/11 00:00:00 [g.region] frankie 6160 5484 0 16:58 pts/11 00:00:00 [g.region] ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=355&group_id=21 From grass-codei at wald.intevation.org Tue Apr 3 22:22:52 2007 From: grass-codei at wald.intevation.org (grass-codei@wald.intevation.org) Date: Tue Apr 3 22:22:54 2007 Subject: [GRASS-dev] [grass-code I][356] Georectifier auto-extension Message-ID: <20070403202252.41EEA1973F82@pyrosoma.intevation.org> code I item #356, was opened at 2007-04-03 22:22 Status: Open Priority: 3 Submitted By: Francesco Lovergine (frankie) Assigned to: Nobody (None) Summary: Georectifier auto-extension Issue type: module bad feature Issue status: None GRASS version: 6.2.1 GRASS component: gis.m Operating system: Linux Operating system version: Debian sid GRASS CVS checkout date, if applies (YYMMDD): Initial Comment: Georectifier calls i.rectify with a pid extension. This is quite bad. For instance, when rectifying an hyperspectral image with bands numbered 1..200, you will get many rasters with long random suffixes such as: myimage.4812345 which is ugly. It would be much more sane asking the user an extension (e.g. I prefer a 'R' suffix for manually rectified images). ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=356&group_id=21 From massimo.costantini at gmail.com Tue Apr 3 23:11:45 2007 From: massimo.costantini at gmail.com (massimo costantini) Date: Tue Apr 3 23:11:49 2007 Subject: [GRASS-dev] Modellizzazione di processi Message-ID: Salve Per la mia tesi di laurea ho lavorato allo svlippu di moduli per un'ambiente di modellizzazione di processi biologici all'interno di un GIS, attualmente lavoro su Grass per la prodizione di cartografia digitale. Volevo chiedervi se ? mai stato ipotizzata la creazione di un'ambiente di modellazione di processi? ossia un qualcosa di pi? potente e interattivo di r.mapcalc? Grazie Massimo Costantini From michael.barton at asu.edu Wed Apr 4 00:48:30 2007 From: michael.barton at asu.edu (Michael Barton) Date: Wed Apr 4 00:48:35 2007 Subject: [GRASS-dev] [grass-code I][356] Georectifier auto-extension In-Reply-To: <20070403202252.41EEA1973F82@pyrosoma.intevation.org> Message-ID: This is doable, but complicated, involving creating another dialog box. I'm trying to focus my development efforts on the new wxPython GUI and do only minor improvements, optimizing, and bug fixing with the TclTk version of 6.3 (which is enhanced in a number of respects over the 6.2.1 version that you are using). Sorry, but I only have so much time and am devoting too much already to GRASS GUI development (because I enjoy it). It would be fine if someone else wanted to add this enhancement. Michael On 4/3/07 1:22 PM, "grass-codei@wald.intevation.org" wrote: > code I item #356, was opened at 2007-04-03 22:22 > Status: Open > Priority: 3 > Submitted By: Francesco Lovergine (frankie) > Assigned to: Nobody (None) > Summary: Georectifier auto-extension > Issue type: module bad feature > Issue status: None > GRASS version: 6.2.1 > GRASS component: gis.m > Operating system: Linux > Operating system version: Debian sid > GRASS CVS checkout date, if applies (YYMMDD): > > > Initial Comment: > Georectifier calls i.rectify with a pid extension. This is quite bad. For > instance, when rectifying an hyperspectral image with bands numbered 1..200, > you will get many rasters with long random suffixes such as: > > myimage.4812345 > > which is ugly. It would be much more sane asking the user an extension (e.g. I > prefer a 'R' suffix for manually rectified images). > > ---------------------------------------------------------------------- > > You can respond by visiting: > http://wald.intevation.org/tracker/?func=detail&atid=204&aid=356&group_id=21 > > __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From hamish_nospam at yahoo.com Wed Apr 4 04:06:03 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Apr 4 04:06:16 2007 Subject: [GRASS-dev] enable forwarding all GRASS GForge traffic to grass-dev ML? In-Reply-To: <46127E22.4090306@o2.pl> References: <4611761A.70609@o2.pl> <20070403125345.14b0ede6.hamish_nospam@yahoo.com> <4612120A.8040009@itc.it> <46127E22.4090306@o2.pl> Message-ID: <20070404140603.4485a4b0.hamish_nospam@yahoo.com> Maciej Sieczka wrote: > > >> Maybe add grass-dev as an interested party in the bug report? > > That's what I asked about in this thread. So, should I? Mind that each > email from GForge trackers will include the whole thread (all > messages), with the original message on top, the most recent next, and > all older messages after that, in chronological order (newer first, > older next). probably do not do that until the noise issues are worked out. more noise = less productivity too much noise = less developers > >> Also how to enable reply-to-bug from grass-dev? > > I don't think it is possible currently. And I'm not sure it is needed. > Other widely used tracking systems (Bugzilla, Trac) require one to use > an online interface too and users got used to it. What is missing in > GForge, is an option to CC an arbitrary email, eg. a mailing list, > when a consultation is needed. and vice versa. Replies (answers) to comments cc'd to the mailing list could automatically be logged in the bug's history as well. Hamish From hamish_nospam at yahoo.com Wed Apr 4 04:12:10 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Apr 4 04:12:22 2007 Subject: [GRASS-dev] No longer able to open a mapset by symbolic link In-Reply-To: <17938.8117.39792.631929@cerise.gclements.plus.com> References: <17937.55280.228654.831177@cerise.gclements.plus.com> <46120FEF.3@itc.it> <17938.8117.39792.631929@cerise.gclements.plus.com> Message-ID: <20070404141210.5b1c1adc.hamish_nospam@yahoo.com> Markus wrote: > I am long term user of such mapset links, it would be a major > problem for us to no longer have this possibility. Just to express > interest in this issue... me too. Hamish From hamish_nospam at yahoo.com Wed Apr 4 04:16:44 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Apr 4 04:17:01 2007 Subject: [GRASS-dev] menu help In-Reply-To: References: <1a486f560703300225t46fa5456g432e19c1e819f727@mail.gmail.com> Message-ID: <20070404141644.4f678f71.hamish_nospam@yahoo.com> Daniel wrote: > > I suggest porting the menu structure to JSON (in preference of XML) Michael wrote: > I am not familiar with JSON. http://www.json.org there are a number of python toolboxes for it listed on the above page, as for Tcl/Tk a quick web search brings: http://wiki.tcl.tk/13419 http://www.ensta.fr/~diam/tcl/online/tcllib/json.html Hamish From hamish_nospam at yahoo.com Wed Apr 4 04:22:35 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Apr 4 04:22:52 2007 Subject: [GRASS-dev] Re: discussion: replacing ps.map In-Reply-To: <17938.12859.778482.880923@cerise.gclements.plus.com> References: <17938.7222.214580.238597@cerise.gclements.plus.com> <17938.12859.778482.880923@cerise.gclements.plus.com> Message-ID: <20070404142235.0ec897e1.hamish_nospam@yahoo.com> Glynn Clements wrote: > > I mean that the application has to draw styled lines using a sequence > of primitives. E.g. if you want a double line (#1000 on p39), you have > to draw two lines, with the correct offsets. v.parallel or v.buffer > If you want arrows, you have to place and draw each arrow-head. script which does: v.to.db opt=slope + awk + v.in.ascii form=standard + v.patch ? Hamish From glynn at gclements.plus.com Wed Apr 4 04:38:49 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Apr 4 04:39:01 2007 Subject: [GRASS-dev] [grass-code I][355] A lot of processes around while working In-Reply-To: <20070403201540.9ADDF1973F82@pyrosoma.intevation.org> References: <20070403201540.9ADDF1973F82@pyrosoma.intevation.org> Message-ID: <17939.4025.767638.501869@cerise.gclements.plus.com> grass-codei@wald.intevation.org wrote: > code I item #355, was opened at 2007-04-03 22:15 > Status: Open > Priority: 3 > Submitted By: Francesco Lovergine (frankie) > Assigned to: Nobody (None) > Summary: A lot of processes around while working > Issue type: module bug > Issue status: None > GRASS version: 6.2.1 > GRASS component: gis.m > Operating system: Linux > Operating system version: Debian sid > GRASS CVS checkout date, if applies (YYMMDD): > > > Initial Comment: > > While using georectifier a lot of pending defuncts appear for > g.region. It seems (?) parent does not loop on wait() while managing > SIGCHLD process as it should. All processes are closed when gm.tcl is > terminated. > > > frankie 5484 1 2 16:49 pts/11 00:00:32 wish /usr/lib/grass/etc/gm/gm.tcl -name gm_tcl > frankie 5525 5484 0 16:49 pts/11 00:00:00 [g.region] > frankie 5527 5484 0 16:50 pts/11 00:00:00 [g.region] > frankie 5529 5484 0 16:50 pts/11 00:00:00 [g.region] [snip] AFAICT, this is due to MapCanvas::set_wind; it should be using "exec" rather than "open |...". -- Glynn Clements From neteler at itc.it Wed Apr 4 09:54:30 2007 From: neteler at itc.it (Markus Neteler) Date: Wed Apr 4 09:54:52 2007 Subject: [GRASS-dev] Re: GRASS SVN migration In-Reply-To: <200703131559.33835.bernhard@intevation.de> References: <17908.16039.431289.828167@cerise.gclements.plus.com> <45F6B891.6090900@itc.it> <200703131559.33835.bernhard@intevation.de> Message-ID: <461359B6.9080106@itc.it> Bernhard Reiter wrote on 03/13/2007 03:59 PM: > On Tuesday 13 March 2007 15:43, Markus Neteler wrote: > >> Martin Landa wrote on 03/13/2007 02:05 PM: >> > > >>> no exact timeline exists AFAIK. There is plan to migrate to SVN in >>> connection to GRASS7. I hope it will be done soon. >>> > > >> we would like to do the SVN migration rather sooner than later. >> > > Fine. > I think wald is ready for this in principle. > > >> We offer to play with a full snapshot of the CVS repository here locally >> (kindly receiving a copy from you) and try to migrate it here at IRST >> in a local server to see how it works for branches etc. >> >> Then we'll report back and give suggestions for the real migration >> > > This would be helpful of course, we did some scripting here for the last > few migrations we did, so we do have some experience. > (Maybe Bernhard H. or Thomas have some pointers.) > > >> Please let us know if you could package the CVS repository server-side into >> a tarball. >> > > Sure we could pack it up. All modules would be 585 MByte. > Can you send my your OpenPGP key, we could place it on an access controlled > area so you can download and send you the link. > > Hi Bernhard, could we get the ball rolling? If you need anything from me/us, please let me know. Thanks markus ------------------ ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler ITC -> since 1 March 2007 Fondazione Bruno Kessler ------------------ From neteler at itc.it Wed Apr 4 09:56:39 2007 From: neteler at itc.it (Markus Neteler) Date: Wed Apr 4 09:56:51 2007 Subject: [GRASS-dev] Re: discussion: replacing ps.map In-Reply-To: <20070404142235.0ec897e1.hamish_nospam@yahoo.com> References: <17938.7222.214580.238597@cerise.gclements.plus.com> <17938.12859.778482.880923@cerise.gclements.plus.com> <20070404142235.0ec897e1.hamish_nospam@yahoo.com> Message-ID: <46135A37.9050308@itc.it> Hamish wrote on 04/04/2007 04:22 AM: > Glynn Clements wrote: > >> I mean that the application has to draw styled lines using a sequence >> of primitives. E.g. if you want a double line (#1000 on p39), you have >> to draw two lines, with the correct offsets. >> > > v.parallel or v.buffer > Note that v.parallel is partially broken as it produces unconnected lines if you generate a parallel line to a polyline. Markus ------------------ ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler ITC -> since 1 March 2007 Fondazione Bruno Kessler ------------------ From thomas at intevation.de Wed Apr 4 10:08:24 2007 From: thomas at intevation.de (Thomas Arendsen Hein) Date: Wed Apr 4 10:13:23 2007 Subject: [GRASS-dev] Re: GRASS SVN migration In-Reply-To: <461359B6.9080106@itc.it> References: <17908.16039.431289.828167@cerise.gclements.plus.com> <45F6B891.6090900@itc.it> <200703131559.33835.bernhard@intevation.de> <461359B6.9080106@itc.it> Message-ID: <20070404080824.GA7190@intevation.de> * Markus Neteler [20070404 09:54]: > Bernhard Reiter wrote on 03/13/2007 03:59 PM: > > On Tuesday 13 March 2007 15:43, Markus Neteler wrote: > >> Please let us know if you could package the CVS repository server-side into > >> a tarball. > > > > Sure we could pack it up. All modules would be 585 MByte. > > Can you send my your OpenPGP key, we could place it on an access controlled > > area so you can download and send you the link. > > could we get the ball rolling? If you need anything from me/us, please > let me know. Seems as if the list moderators didn't let my previous message (sent Tue, 13 Mar 2007) through. I wrote: | The GRASS CVS repository is available via anonymous rsync since July 2002 | at rsync://rsync.intevation.de/grass Thomas -- thomas@intevation.de - http://intevation.de/~thomas/ - OpenPGP key: 0x5816791A Intevation GmbH, Osnabr?ck - Registereintrag: Amtsgericht Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From wegmann at biozentrum.uni-wuerzburg.de Wed Apr 4 10:12:50 2007 From: wegmann at biozentrum.uni-wuerzburg.de (Martin Wegmann) Date: Wed Apr 4 10:14:40 2007 Subject: [GRASS-dev] errors in: messages Message-ID: <200704041012.50170.wegmann@biozentrum.uni-wuerzburg.de> hello, I get various "errors in:" messages after an update. So far I did not find similar threats on the mailing lists. After a cvs update, make distclean - configure - make, a long list of "errors in:" is prompted (see below). I deleted my old cvs folder and removed the grass files in /usr/local and did a fresh cvs but still the same error appears. It is a temporal problem or did I forget something? Using debian testing. TIA Martin Errors in: ...//grass/grass6/lib/proj ...//grass/grass6/lib/vector/Vlib ...//grass/grass6/lib/sites ...//grass/grass6/lib/rst/interp_float ...//grass/grass6/lib/ogsf ...//grass/grass6/db/drivers/ogr ...//grass/grass6/display/d.extend ...//grass/grass6/display/d.extract ...//grass/grass6/display/d.grid ...//grass/grass6/display/d.path ...//grass/grass6/display/d.vect ...//grass/grass6/display/d.vect.chart ...//grass/grass6/display/d.what.vect ...//grass/grass6/display/d.where ...//grass/grass6/display/d.zoom ...//grass/grass6/general/g.proj ...//grass/grass6/general/g.region/cmd ...//grass/grass6/general/g.setproj ...//grass/grass6/general/manage/cmd ...//grass/grass6/general/manage/lister ...//grass/grass6/imagery/i.vpoints ...//grass/grass6/ps/ps.map ...//grass/grass6/raster/r.carve ...//grass/grass6/raster/r.contour ...//grass/grass6/raster/r.cost ...//grass/grass6/raster/r.drain ...//grass/grass6/raster/r.flow ...//grass/grass6/raster/r.le/r.le.setup ...//grass/grass6/raster/r.out.gdal ...//grass/grass6/raster/r.proj ...//grass/grass6/raster/r.proj.seg ...//grass/grass6/raster/r.random ...//grass/grass6/raster/r.region ...//grass/grass6/raster/r.resamp.rst ...//grass/grass6/raster/r.sun ...//grass/grass6/raster/r.sunmask ...//grass/grass6/raster/r.to.vect ...//grass/grass6/raster/r.volume ...//grass/grass6/raster/r.walk ...//grass/grass6/raster/simwe/simlib ...//grass/grass6/raster/simwe/r.sim.water ...//grass/grass6/raster/simwe/r.sim.sediment ...//grass/grass6/raster/r.in.gdal ...//grass/grass6/vector/v.buffer ...//grass/grass6/vector/v.build ...//grass/grass6/vector/v.build.polylines ...//grass/grass6/vector/v.category ...//grass/grass6/vector/v.clean ...//grass/grass6/vector/v.convert ...//grass/grass6/vector/v.db.connect ...//grass/grass6/vector/v.db.select ...//grass/grass6/vector/v.distance ...//grass/grass6/vector/v.drape ...//grass/grass6/vector/v.edit ...//grass/grass6/vector/v.extract ...//grass/grass6/vector/v.extrude ...//grass/grass6/vector/v.hull ...//grass/grass6/vector/v.info ...//grass/grass6/vector/v.in.ascii ...//grass/grass6/vector/v.in.db ...//grass/grass6/vector/v.in.dxf ...//grass/grass6/vector/v.in.region ...//grass/grass6/vector/v.in.sites ...//grass/grass6/vector/v.kcv ...//grass/grass6/vector/v.kernel ...//grass/grass6/vector/v.label ...//grass/grass6/vector/v.lrs/lib ...//grass/grass6/vector/v.lrs/v.lrs.create ...//grass/grass6/vector/v.lrs/v.lrs.segment ...//grass/grass6/vector/v.lrs/v.lrs.label ...//grass/grass6/vector/v.lrs/v.lrs.where ...//grass/grass6/vector/v.proj ...//grass/grass6/vector/v.mkgrid ...//grass/grass6/vector/v.neighbors ...//grass/grass6/vector/v.net ...//grass/grass6/vector/v.net.alloc ...//grass/grass6/vector/v.net.iso ...//grass/grass6/vector/v.net.path ...//grass/grass6/vector/v.net.salesman ...//grass/grass6/vector/v.net.steiner ...//grass/grass6/vector/v.normal ...//grass/grass6/vector/v.out.ascii ...//grass/grass6/vector/v.out.dxf ...//grass/grass6/vector/v.out.pov ...//grass/grass6/vector/v.out.svg ...//grass/grass6/vector/v.out.vtk ...//grass/grass6/vector/v.overlay ...//grass/grass6/vector/v.parallel ...//grass/grass6/vector/v.patch ...//grass/grass6/vector/v.perturb ...//grass/grass6/vector/v.split ...//grass/grass6/vector/v.qcount ...//grass/grass6/vector/v.random ...//grass/grass6/vector/v.reclass ...//grass/grass6/vector/v.sample ...//grass/grass6/vector/v.segment ...//grass/grass6/vector/v.select ...//grass/grass6/vector/v.support ...//grass/grass6/vector/v.surf.idw ...//grass/grass6/vector/v.surf.rst ...//grass/grass6/vector/v.transform ...//grass/grass6/vector/v.to.db ...//grass/grass6/vector/v.to.points ...//grass/grass6/vector/v.to.rast ...//grass/grass6/vector/v.to.rast3 ...//grass/grass6/vector/v.type ...//grass/grass6/vector/v.univar ...//grass/grass6/vector/v.voronoi ...//grass/grass6/vector/v.what ...//grass/grass6/vector/v.what.rast ...//grass/grass6/vector/v.vol.rst ...//grass/grass6/vector/lidar/lidarlib ...//grass/grass6/vector/lidar/v.surf.bspline ...//grass/grass6/vector/lidar/v.outlier ...//grass/grass6/vector/lidar/v.lidar.correction ...//grass/grass6/vector/lidar/v.lidar.edgedetection ...//grass/grass6/vector/lidar/v.lidar.growing ...//grass/grass6/vector/v.out.ogr ...//grass/grass6/vector/v.in.ogr ...//grass/grass6/vector/v.external ...//grass/grass6/vector/v.digit ...//grass/grass6/visualization/nviz -- Finished compilation: Tue Apr 3 18:48:46 CEST 2007 (In case of errors please change into the directory with error and run 'make') make: *** [default] Error 1 From neteler at itc.it Wed Apr 4 10:15:23 2007 From: neteler at itc.it (Markus Neteler) Date: Wed Apr 4 10:15:25 2007 Subject: [GRASS-dev] Re: GRASS SVN migration In-Reply-To: <20070404080824.GA7190@intevation.de> References: <17908.16039.431289.828167@cerise.gclements.plus.com> <45F6B891.6090900@itc.it> <200703131559.33835.bernhard@intevation.de> <461359B6.9080106@itc.it> <20070404080824.GA7190@intevation.de> Message-ID: <20070404081522.GA29717@bartok.itc.it> On Wed, Apr 04, 2007 at 10:08:24AM +0200, Thomas Arendsen Hein wrote: > * Markus Neteler [20070404 09:54]: > > Bernhard Reiter wrote on 03/13/2007 03:59 PM: > > > On Tuesday 13 March 2007 15:43, Markus Neteler wrote: > > >> Please let us know if you could package the CVS repository server-side into > > >> a tarball. > > > > > > Sure we could pack it up. All modules would be 585 MByte. > > > Can you send my your OpenPGP key, we could place it on an access controlled > > > area so you can download and send you the link. > > > > could we get the ball rolling? If you need anything from me/us, please > > let me know. > > Seems as if the list moderators didn't let my previous message (sent Tue, 13 > Mar 2007) through. In fact, it was there in the long queue of mostly trapped spam. I don't have the time to check the 14 mailman queues here regularly... > I wrote: > > | The GRASS CVS repository is available via anonymous rsync since July 2002 > | at rsync://rsync.intevation.de/grass Oh, I didn't know that. Thanks for the hint. Markus > Thomas > > -- > thomas@intevation.de - http://intevation.de/~thomas/ - OpenPGP key: 0x5816791A > Intevation GmbH, Osnabr?ck - Registereintrag: Amtsgericht Osnabr?ck, HR B 18998 > Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From hamish_nospam at yahoo.com Wed Apr 4 10:23:11 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Apr 4 10:23:23 2007 Subject: [GRASS-dev] tcl Map Display gui updates Message-ID: <20070404202311.4337b9fc.hamish_nospam@yahoo.com> Hi, I have just done some cosmetic updates to the Tcl/Tk GUI Map Display window. Measurement tool now auto-formats. The output is like: "5.939 km" instead of "5939.234567" (map units = meters) "5.939 miles" instead of "34567.000000" (map units = [US surv] feet) "45.123 minutes" instead of "0.75205" (map units = degrees) etc. I don't think people will parsing the measure tool's output, so it changes units on the fly. Map Display status bar (bottom of window) is a bit more readable. I've only enforced number of sig digits for mouse-over updates, not while in zoom, pan, measure mode. I wanted to make sure there were no objections before spending the time to do those. please test. Hamish From hamish_nospam at yahoo.com Wed Apr 4 10:33:14 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Apr 4 10:33:29 2007 Subject: [GRASS-dev] errors in: messages In-Reply-To: <200704041012.50170.wegmann@biozentrum.uni-wuerzburg.de> References: <200704041012.50170.wegmann@biozentrum.uni-wuerzburg.de> Message-ID: <20070404203314.38fa7658.hamish_nospam@yahoo.com> Martin Wegmann wrote: > > I get various "errors in:" messages after an update. So far I did not > find similar threats on the mailing lists. > > After a cvs update, make distclean - configure - make, a long list of > "errors in:" is prompted (see below). > > I deleted my old cvs folder and removed the grass files in /usr/local > and did a fresh cvs but still the same error appears. > > It is a temporal problem or did I forget something? > > Using debian testing. > > TIA Martin > > Errors in: > ...//grass/grass6/lib/proj --snip-- > (In case of errors please change into the directory with error and run > 'make') please do that, starting with lib/proj note nothing has changed in lib/proj in a month. is ".../" real or a search & replace? Hamish From wegmann at biozentrum.uni-wuerzburg.de Wed Apr 4 10:39:55 2007 From: wegmann at biozentrum.uni-wuerzburg.de (Martin Wegmann) Date: Wed Apr 4 10:41:41 2007 Subject: [GRASS-dev] errors in: messages In-Reply-To: <20070404203314.38fa7658.hamish_nospam@yahoo.com> References: <200704041012.50170.wegmann@biozentrum.uni-wuerzburg.de> <20070404203314.38fa7658.hamish_nospam@yahoo.com> Message-ID: <200704041039.55676.wegmann@biozentrum.uni-wuerzburg.de> On Wednesday 04 April 2007 10:33, Hamish wrote: > Martin Wegmann wrote: > > I get various "errors in:" messages after an update. So far I did not > > find similar threats on the mailing lists. > > > > After a cvs update, make distclean - configure - make, a long list of > > "errors in:" is prompted (see below). > > > > I deleted my old cvs folder and removed the grass files in /usr/local > > and did a fresh cvs but still the same error appears. > > > > It is a temporal problem or did I forget something? > > > > Using debian testing. > > > > TIA Martin > > > > Errors in: > > ...//grass/grass6/lib/proj > > --snip-- > > > (In case of errors please change into the directory with error and run > > 'make') > > please do that, starting with lib/proj baliola@wpf063:~/software/grass/grass6$ cd lib/proj/ baliola@wpf063:~/software/grass/grass6/lib/proj$ make gcc -shared -o /home/baliola/software/grass/grass6/dist.i686-pc-linux-gnu/lib/libgrass_gproj.6.3.cvs.so -L/home/baliola/software/grass/grass6/dist.i686-pc-linux-gnu/lib -Wl,--export-dynamic -Wl,-rpath-link,/home/baliola/software/grass/grass6/dist.i686-pc-linux-gnu/lib OBJ.i686-pc-linux-gnu/get_proj.o OBJ.i686-pc-linux-gnu/do_proj.o OBJ.i686-pc-linux-gnu/convert.o OBJ.i686-pc-linux-gnu/datum.o OBJ.i686-pc-linux-gnu/ellipse.o -lgrass_gis -lgrass_datetime -lz -lproj -L/usr/local/lib -lgdal -lodbc -lodbcinst -ljasper -lmfhdf -ldf -lgif -ljpeg -ltiff -lpng -lnetcdf -lcfitsio -L/usr/local/grass-6.3.cvs//lib -lgrass_vect -lgrass_dig2 -lgrass_dgl -lgrass_rtree -lgrass_linkm -lgrass_dbmiclient -lgrass_dbmibase -lgrass_I -lgrass_gproj -lgrass_vask -lgrass_gmath -lgrass_gis -lgrass_datetime -lpq -L/usr/lib -lpq -lz -lm -lrt -ldl && \ (cd /home/baliola/software/grass/grass6/dist.i686-pc-linux-gnu/lib; ln -f -s libgrass_gproj.6.3.cvs.so /home/baliola/software/grass/grass6/dist.i686-pc-linux-gnu/lib/libgrass_gproj.so) /usr/bin/ld: cannot find -lgrass_vect collect2: ld returned 1 exit status make: *** [/home/baliola/software/grass/grass6/dist.i686-pc-linux-gnu/lib/libgrass_gproj.6.3.cvs.so] Error 1 > note nothing has changed in lib/proj in a month. > > is ".../" real or a search & replace? I replaced the path to the grass folder, it is in my home directory. Martin From rnuske at gwdg.de Wed Apr 4 10:48:53 2007 From: rnuske at gwdg.de (Robert Nuske) Date: Wed Apr 4 10:48:55 2007 Subject: [GRASS-dev] menu help In-Reply-To: References: Message-ID: <200704041048.53761.rnuske@gwdg.de> I got the impression from the website that he might be willing to design additional icons if needed (might be even more motivating if the project and potential user base is big ;-). robert > These are nice. They cover some of the potential needs, though I'm not sure > if they do all of them. > > Michael > > On 3/29/07 10:36 AM, "Robert Nuske" wrote: > >> We could also use an artistic type for icon design. I already need a > >> couple that don?t yet exist (for overlay layers and map display > >> decorations). > > > > sorry, I am not, > > but what about the Silk Icons > > > > http://www.famfamfam.com/lab/icons/silk/ > > > > that set contains some nice geo-icons > > > > cheers, > > robert > > __________________________________________ > Michael Barton, Professor of Anthropology > School of Human Evolution & Social Change > Center for Social Dynamics & Complexity > Arizona State University > > phone: 480-965-6213 > fax: 480-965-7671 > www: http://www.public.asu.edu/~cmbarton > > > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev -- ____________________________________ Robert Nuske Institute for Forest Biometrics & Applied Computer Science Buesgenweg 4 37077 Goettingen GERMANY Phone: +49-551-39-2362 Fax : +49-551-39-3465 From glynn at gclements.plus.com Wed Apr 4 12:08:08 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Apr 4 12:08:12 2007 Subject: [GRASS-dev] errors in: messages In-Reply-To: <200704041039.55676.wegmann@biozentrum.uni-wuerzburg.de> References: <200704041012.50170.wegmann@biozentrum.uni-wuerzburg.de> <20070404203314.38fa7658.hamish_nospam@yahoo.com> <200704041039.55676.wegmann@biozentrum.uni-wuerzburg.de> Message-ID: <17939.30984.51612.124448@cerise.gclements.plus.com> Martin Wegmann wrote: > > > I get various "errors in:" messages after an update. So far I did not > > > find similar threats on the mailing lists. > > > > > > After a cvs update, make distclean - configure - make, a long list of > > > "errors in:" is prompted (see below). > > > > > > I deleted my old cvs folder and removed the grass files in /usr/local > > > and did a fresh cvs but still the same error appears. > > > > > > It is a temporal problem or did I forget something? > > > > > > Using debian testing. > > > > > > TIA Martin > > > > > > Errors in: > > > ...//grass/grass6/lib/proj > > > > --snip-- > > > > > (In case of errors please change into the directory with error and run > > > 'make') > > > > please do that, starting with lib/proj > > baliola@wpf063:~/software/grass/grass6$ cd lib/proj/ > baliola@wpf063:~/software/grass/grass6/lib/proj$ make > gcc -shared -o /home/baliola/software/grass/grass6/dist.i686-pc-linux-gnu/lib/libgrass_gproj.6.3.cvs.so -L/home/baliola/software/grass/grass6/dist.i686-pc-linux-gnu/lib -Wl,--export-dynamic -Wl,-rpath-link,/home/baliola/software/grass/grass6/dist.i686-pc-linux-gnu/lib > OBJ.i686-pc-linux-gnu/get_proj.o OBJ.i686-pc-linux-gnu/do_proj.o > OBJ.i686-pc-linux-gnu/convert.o OBJ.i686-pc-linux-gnu/datum.o > OBJ.i686-pc-linux-gnu/ellipse.o -lgrass_gis -lgrass_datetime -lz -lproj -L/usr/local/lib -lgdal -lodbc -lodbcinst -ljasper -lmfhdf -ldf -lgif -ljpeg -ltiff -lpng -lnetcdf -lcfitsio -L/usr/local/grass-6.3.cvs//lib -lgrass_vect -lgrass_dig2 -lgrass_dgl -lgrass_rtree -lgrass_linkm -lgrass_dbmiclient -lgrass_dbmibase -lgrass_I -lgrass_gproj -lgrass_vask -lgrass_gmath -lgrass_gis -lgrass_datetime -lpq -L/usr/lib -lpq -lz -lm -lrt -ldl > && \ > (cd /home/baliola/software/grass/grass6/dist.i686-pc-linux-gnu/lib; > ln -f -s > libgrass_gproj.6.3.cvs.so /home/baliola/software/grass/grass6/dist.i686-pc-linux-gnu/lib/libgrass_gproj.so) > /usr/bin/ld: cannot find -lgrass_vect As libgrass_gproj library doesn't use libgrass_vect, this is almost certainly a GDAL issue (i.e. your GDAL library was built with GRASS support, but you've removed the GRASS installation on which it depends). If that is the case, you will first need to re-install GDAL; if you're building it from source, you'll need to build without GRASS support. -- Glynn Clements From glynn at gclements.plus.com Wed Apr 4 12:15:25 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Apr 4 12:15:27 2007 Subject: [GRASS-dev] discussion: replacing ps.map In-Reply-To: <17936.59188.242469.82716@cerise.gclements.plus.com> References: <17930.59855.699533.647215@cerise.gclements.plus.com> <17932.16901.672831.128404@cerise.gclements.plus.com> <17936.45593.765285.836412@cerise.gclements.plus.com> <17936.59188.242469.82716@cerise.gclements.plus.com> Message-ID: <17939.31421.384601.500919@cerise.gclements.plus.com> Glynn Clements wrote: > > > The original unscaled raster function R_RGB_raster() is only used by > > > i.point, i.vpoints and i.class. They could be changed to use the > > > scaled raster functions with 1:1 scaling, although I'm not sure that I > > > understand them well enough to test any changes, and I'm not sure if > > > it's worth the effort (AFAIK, they should all be obsolete soon). > > > > I've changed them to use the scaled raster functions (D_draw_d_raster > > rather than D_d_raster). i.points seems to work okay (although I'm not > > all that familiar with it), and the other two have almost identical > > code. Even so, I'd appreciate it if someone could test these changes. > > Also changed: photo.2target and photo.2image. Having eliminated all use of the unscaled raster operations, I've removed them from the drivers, and moved the scaled raster operations into the drivers. This should all be transparent to the user but, like any change to the driver protocol, the changes are relatively invasive, so there's always the possibility of bugs creeping in. Also, direct rendering can now produce PostScript as an alternative to PNG or PPM files. The GRASS_RENDER_IMMEDIATE environment variable has been extended to accept values of PNG (generate PNG or PPM output, equivalent to GRASS_RENDER_IMMEDIATE=TRUE) and PS (generate PostScript output). -- Glynn Clements From michael.barton at asu.edu Wed Apr 4 15:56:58 2007 From: michael.barton at asu.edu (Michael Barton) Date: Wed Apr 4 15:57:12 2007 Subject: [GRASS-dev] [grass-code I][355] A lot of processes around while working In-Reply-To: <17939.4025.767638.501869@cerise.gclements.plus.com> Message-ID: This is because of the need to run g.region -gp and read the results back, in order to get current region information. Michael On 4/3/07 7:38 PM, "Glynn Clements" wrote: > > grass-codei@wald.intevation.org wrote: > >> code I item #355, was opened at 2007-04-03 22:15 >> Status: Open >> Priority: 3 >> Submitted By: Francesco Lovergine (frankie) >> Assigned to: Nobody (None) >> Summary: A lot of processes around while working >> Issue type: module bug >> Issue status: None >> GRASS version: 6.2.1 >> GRASS component: gis.m >> Operating system: Linux >> Operating system version: Debian sid >> GRASS CVS checkout date, if applies (YYMMDD): >> >> >> Initial Comment: >> >> While using georectifier a lot of pending defuncts appear for >> g.region. It seems (?) parent does not loop on wait() while managing >> SIGCHLD process as it should. All processes are closed when gm.tcl is >> terminated. >> >> >> frankie 5484 1 2 16:49 pts/11 00:00:32 wish >> /usr/lib/grass/etc/gm/gm.tcl -name gm_tcl >> frankie 5525 5484 0 16:49 pts/11 00:00:00 [g.region] >> frankie 5527 5484 0 16:50 pts/11 00:00:00 [g.region] >> frankie 5529 5484 0 16:50 pts/11 00:00:00 [g.region] > > [snip] > > AFAICT, this is due to MapCanvas::set_wind; it should be using "exec" > rather than "open |...". __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Wed Apr 4 15:59:01 2007 From: michael.barton at asu.edu (Michael Barton) Date: Wed Apr 4 15:59:09 2007 Subject: [GRASS-dev] tcl Map Display gui updates In-Reply-To: <20070404202311.4337b9fc.hamish_nospam@yahoo.com> Message-ID: Thanks Hamish. These make the output more readable, as well as aesthetically pleasing. Michael On 4/4/07 1:23 AM, "Hamish" wrote: > Hi, > > I have just done some cosmetic updates to the Tcl/Tk GUI Map Display > window. > > > Measurement tool now auto-formats. The output is like: > "5.939 km" instead of "5939.234567" (map units = meters) > "5.939 miles" instead of "34567.000000" (map units = [US surv] feet) > "45.123 minutes" instead of "0.75205" (map units = degrees) > etc. I don't think people will parsing the measure tool's output, so it > changes units on the fly. > > > Map Display status bar (bottom of window) is a bit more readable. > I've only enforced number of sig digits for mouse-over updates, not > while in zoom, pan, measure mode. I wanted to make sure there were no > objections before spending the time to do those. > > > please test. > > > Hamish > > __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From jachym.cepicky at gmail.com Wed Apr 4 17:00:34 2007 From: jachym.cepicky at gmail.com (Jachym Cepicky) Date: Wed Apr 4 17:00:36 2007 Subject: [GRASS-dev] PNG driver - slow? Message-ID: Hi, export GRASS_PNGFILE=/tmp/pokus.png export GRASS_RENDER_IMMEDIATE=TRUE time d.vect map=soils@PERMANENT real 0m0.197s user 0m0.166s sys 0m0.019s time d.vect map=soils@PERMANENT color=yellow fcolor=yellow cats=32 width=3 real 0m13.767s user 0m13.611s sys 0m0.098s Why is the second case so slow? Is it a bug in PNG driver? What can I do, so it is rendered faster? Thanks Jachym -- Jachym Cepicky e-mail: jachym.cepicky gmail com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub From massimo.costantini at gmail.com Wed Apr 4 19:30:18 2007 From: massimo.costantini at gmail.com (massimo costantini) Date: Wed Apr 4 19:30:20 2007 Subject: [GRASS-dev] Process Modellizzation Message-ID: Hi, for my degree I've worked on developing of software module for an modellization environment for bioligic's process of a GIS. I want to ask if exist a project for Grass that impement a modellizzation environment for process, someting more powerfull and interactive then r.mapcalc Thanks to all Massimo Costantini From glynn at gclements.plus.com Wed Apr 4 21:06:54 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Apr 4 21:06:58 2007 Subject: [GRASS-dev] [grass-code I][355] A lot of processes around while working In-Reply-To: References: <17939.4025.767638.501869@cerise.gclements.plus.com> Message-ID: <17939.63310.727841.309429@cerise.gclements.plus.com> Michael Barton wrote: > >> frankie 5484 1 2 16:49 pts/11 00:00:32 wish > >> /usr/lib/grass/etc/gm/gm.tcl -name gm_tcl > >> frankie 5525 5484 0 16:49 pts/11 00:00:00 [g.region] > >> frankie 5527 5484 0 16:50 pts/11 00:00:00 [g.region] > >> frankie 5529 5484 0 16:50 pts/11 00:00:00 [g.region] > > > > [snip] > > > > AFAICT, this is due to MapCanvas::set_wind; it should be using "exec" > > rather than "open |...". > > This is because of the need to run g.region -gp and read the results back, > in order to get current region information. Nope. The code in question is: proc MapCanvas::set_wind {mon args overwrite} { variable zoom_attrs global devnull set values [MapCanvas::currentzoom $mon] set options {} foreach attr $zoom_attrs value $values { if {$attr != "rows" && $attr != "cols"} { lappend options "$attr=$value" } } if {$overwrite == 1} { open [concat "|g.region --o" $options $args "2> $devnull"] } else { open [concat "|g.region" $options $args "2> $devnull"] } } Nothing is using the returned descriptor. More importantly, nothing is closing it, so the process will remain a zombie forever. This should be using exec, not open. -- Glynn Clements From tutey at o2.pl Wed Apr 4 21:07:32 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Wed Apr 4 21:07:39 2007 Subject: [GRASS-dev] enable forwarding all GRASS GForge traffic to grass-dev ML? In-Reply-To: <20070404140603.4485a4b0.hamish_nospam@yahoo.com> References: <4611761A.70609@o2.pl> <20070403125345.14b0ede6.hamish_nospam@yahoo.com> <4612120A.8040009@itc.it> <46127E22.4090306@o2.pl> <20070404140603.4485a4b0.hamish_nospam@yahoo.com> Message-ID: <4613F774.2080404@o2.pl> Hamish wrote: > Maciej Sieczka wrote: >>>> Maybe add grass-dev as an interested party in the bug report? >> That's what I asked about in this thread. So, should I? Mind that each >> email from GForge trackers will include the whole thread (all >> messages), with the original message on top, the most recent next, and >> all older messages after that, in chronological order (newer first, >> older next). > > probably do not do that until the noise issues are worked out. > more noise = less productivity > too much noise = less developers OK. Maciek From michael.barton at asu.edu Wed Apr 4 21:20:06 2007 From: michael.barton at asu.edu (Michael Barton) Date: Wed Apr 4 21:20:16 2007 Subject: [GRASS-dev] [grass-code I][355] A lot of processes around while working In-Reply-To: <17939.63310.727841.309429@cerise.gclements.plus.com> Message-ID: Thanks. This is easily fixable. Michael On 4/4/07 12:06 PM, "Glynn Clements" wrote: > > Michael Barton wrote: > >>>> frankie 5484 1 2 16:49 pts/11 00:00:32 wish >>>> /usr/lib/grass/etc/gm/gm.tcl -name gm_tcl >>>> frankie 5525 5484 0 16:49 pts/11 00:00:00 [g.region] >>>> frankie 5527 5484 0 16:50 pts/11 00:00:00 [g.region] >>>> frankie 5529 5484 0 16:50 pts/11 00:00:00 [g.region] >>> >>> [snip] >>> >>> AFAICT, this is due to MapCanvas::set_wind; it should be using "exec" >>> rather than "open |...". >> >> This is because of the need to run g.region -gp and read the results back, >> in order to get current region information. > > Nope. The code in question is: > > proc MapCanvas::set_wind {mon args overwrite} { > variable zoom_attrs > global devnull > > set values [MapCanvas::currentzoom $mon] > > set options {} > foreach attr $zoom_attrs value $values { > if {$attr != "rows" && $attr != "cols"} { > lappend options "$attr=$value" > } > } > > if {$overwrite == 1} { > open [concat "|g.region --o" $options $args "2> $devnull"] > } else { > open [concat "|g.region" $options $args "2> $devnull"] > } > } > > Nothing is using the returned descriptor. More importantly, nothing is > closing it, so the process will remain a zombie forever. > > This should be using exec, not open. __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From glynn at gclements.plus.com Wed Apr 4 21:25:05 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Apr 4 21:25:10 2007 Subject: [GRASS-dev] PNG driver - slow? In-Reply-To: References: Message-ID: <17939.64401.313718.203239@cerise.gclements.plus.com> Jachym Cepicky wrote: > export GRASS_PNGFILE=/tmp/pokus.png > export GRASS_RENDER_IMMEDIATE=TRUE > > time d.vect map=soils@PERMANENT > real 0m0.197s > user 0m0.166s > sys 0m0.019s > > time d.vect map=soils@PERMANENT color=yellow fcolor=yellow cats=32 width=3 > real 0m13.767s > user 0m13.611s > sys 0m0.098s > > > Why is the second case so slow? Is it a bug in PNG driver? What can I > do, so it is rendered faster? My guess is the width=3. The "thick line" code in the PNG driver is a truly awful hack (see store_xy() in lib/pngdriver/Draw_line.c). -- Glynn Clements From gnelson at uiuc.edu Wed Apr 4 21:44:49 2007 From: gnelson at uiuc.edu (Jerry Nelson) Date: Wed Apr 4 21:45:03 2007 Subject: [GRASS-dev] help needed with r.terracost Message-ID: <003b01c776f1$b4dfa4e0$3e40ae80@ace.uiuc.edu> Prof. Laura Toma and her students at Bowdoin U. developed a raster module called r.terracost that computes cost surfaces for REALLY BIG rasters. The problem, for me, is that she did it for grass 5.x, I'm using grass 6.3, and I'm not a C programmer. She reports that all that is really needed is to update the make file. I was wondering if any C programmer out there might be interested enough to make this work in 6.3. The source code can be found at http://www.bowdoin.edu/~ltoma/research.html. Any help appreciated! Thanks, Jerry -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070404/8c5a12a4/attachment.html From frankie at debian.org Wed Apr 4 22:08:59 2007 From: frankie at debian.org (Francesco P. Lovergine) Date: Wed Apr 4 22:08:48 2007 Subject: [GRASS-dev] Re: GRASS SVN migration In-Reply-To: <20070404081522.GA29717@bartok.itc.it> References: <17908.16039.431289.828167@cerise.gclements.plus.com> <45F6B891.6090900@itc.it> <200703131559.33835.bernhard@intevation.de> <461359B6.9080106@itc.it> <20070404080824.GA7190@intevation.de> <20070404081522.GA29717@bartok.itc.it> Message-ID: <20070404200858.GA11184@ba.issia.cnr.it> On Wed, Apr 04, 2007 at 10:15:23AM +0200, Markus Neteler wrote: > In fact, it was there in the long queue of mostly trapped spam. I don't > have the time to check the 14 mailman queues here regularly... > listadmin is tiny python tool to manage mailman lists -- Francesco P. Lovergine From michael.barton at asu.edu Wed Apr 4 23:09:42 2007 From: michael.barton at asu.edu (Michael Barton) Date: Wed Apr 4 23:09:50 2007 Subject: [GRASS-dev] [grass-code I][355] A lot of processes around while working In-Reply-To: <17939.63310.727841.309429@cerise.gclements.plus.com> Message-ID: Fixed in cvs. Michael On 4/4/07 12:06 PM, "Glynn Clements" wrote: > > Michael Barton wrote: > >>>> frankie 5484 1 2 16:49 pts/11 00:00:32 wish >>>> /usr/lib/grass/etc/gm/gm.tcl -name gm_tcl >>>> frankie 5525 5484 0 16:49 pts/11 00:00:00 [g.region] >>>> frankie 5527 5484 0 16:50 pts/11 00:00:00 [g.region] >>>> frankie 5529 5484 0 16:50 pts/11 00:00:00 [g.region] >>> >>> [snip] >>> >>> AFAICT, this is due to MapCanvas::set_wind; it should be using "exec" >>> rather than "open |...". >> >> This is because of the need to run g.region -gp and read the results back, >> in order to get current region information. > > Nope. The code in question is: > > proc MapCanvas::set_wind {mon args overwrite} { > variable zoom_attrs > global devnull > > set values [MapCanvas::currentzoom $mon] > > set options {} > foreach attr $zoom_attrs value $values { > if {$attr != "rows" && $attr != "cols"} { > lappend options "$attr=$value" > } > } > > if {$overwrite == 1} { > open [concat "|g.region --o" $options $args "2> $devnull"] > } else { > open [concat "|g.region" $options $args "2> $devnull"] > } > } > > Nothing is using the returned descriptor. More importantly, nothing is > closing it, so the process will remain a zombie forever. > > This should be using exec, not open. __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Wed Apr 4 23:12:55 2007 From: michael.barton at asu.edu (Michael Barton) Date: Wed Apr 4 23:12:59 2007 Subject: [GRASS-dev] FW: [grass-code I][355] A lot of processes around while working - Georectifier In-Reply-To: <20070404202300.2F5FD1973F9B@pyrosoma.intevation.org> Message-ID: I just looked at georect.tcl All 'open' calls to g.region are to return values and are followed by closes. So I'm not sure where this is from. Using the georectifier does also use the map display. So maybe it is due to the issue I just fixed by switching open to exec for calling g.region in the set_wind procedure. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton ------ Forwarded Message > From: > Reply-To: > Date: Wed, 4 Apr 2007 22:23:00 +0200 (CEST) > To: > Subject: [grass-code I][355] A lot of processes around while working > > code I item #355, was opened at 2007-04-03 22:15 > Status: Open > Priority: 3 > Submitted By: Francesco Lovergine (frankie) >> Assigned to: Michael Barton (michael) > Summary: A lot of processes around while working > Issue type: module bug > Issue status: None > GRASS version: 6.2.1 > GRASS component: gis.m > Operating system: Linux > Operating system version: Debian sid > GRASS CVS checkout date, if applies (YYMMDD): > > > Initial Comment: > While using georectifier a lot of pending defuncts appear for g.region. It > seems (?) parent does not loop on wait() while managing SIGCHLD process as it > should. All processes are closed when gm.tcl is terminated. > > > > frankie 5484 1 2 16:49 pts/11 00:00:32 wish > /usr/lib/grass/etc/gm/gm.tcl -name gm_tcl > frankie 5525 5484 0 16:49 pts/11 00:00:00 [g.region] > frankie 5527 5484 0 16:50 pts/11 00:00:00 [g.region] > frankie 5529 5484 0 16:50 pts/11 00:00:00 [g.region] > frankie 5590 5484 0 16:50 pts/11 00:00:00 [g.region] > frankie 5602 5484 0 16:50 pts/11 00:00:00 [g.region] > frankie 5605 5484 0 16:50 pts/11 00:00:00 [g.region] > frankie 5608 5484 0 16:50 pts/11 00:00:00 [g.region] > frankie 5616 5484 0 16:50 pts/11 00:00:00 [g.region] > frankie 5623 5484 0 16:50 pts/11 00:00:00 [g.region] > frankie 5654 5484 0 16:50 pts/11 00:00:00 [g.region] > frankie 5683 5484 0 16:50 pts/11 00:00:00 [g.region] > frankie 5706 5484 0 16:51 pts/11 00:00:00 [g.region] > frankie 5718 5484 0 16:51 pts/11 00:00:00 [g.region] > frankie 5729 5484 0 16:51 pts/11 00:00:00 [g.region] > frankie 5739 5484 0 16:52 pts/11 00:00:00 [g.region] > frankie 5751 5484 0 16:52 pts/11 00:00:00 [g.region] > frankie 5763 5484 0 16:52 pts/11 00:00:00 [g.region] > frankie 5774 5484 0 16:53 pts/11 00:00:00 [g.region] > frankie 5784 5484 0 16:53 pts/11 00:00:00 [g.region] > frankie 5794 5484 0 16:53 pts/11 00:00:00 [g.region] > frankie 5805 5484 0 16:54 pts/11 00:00:00 [g.region] > frankie 5821 5484 0 16:54 pts/11 00:00:00 [g.region] > frankie 5922 5484 0 16:55 pts/11 00:00:00 [g.region] > frankie 5932 5484 0 16:56 pts/11 00:00:00 [g.region] > frankie 5943 5484 0 16:56 pts/11 00:00:00 [g.region] > frankie 5955 5484 0 16:57 pts/11 00:00:00 [g.region] > frankie 5965 5484 0 16:57 pts/11 00:00:00 [g.region] > frankie 6030 5484 0 16:58 pts/11 00:00:00 [g.region] > frankie 6054 5484 0 16:58 pts/11 00:00:00 [g.region] > frankie 6086 5484 0 16:58 pts/11 00:00:00 [g.region] > frankie 6096 5484 0 16:58 pts/11 00:00:00 [g.region] > frankie 6128 5484 0 16:58 pts/11 00:00:00 [g.region] > frankie 6160 5484 0 16:58 pts/11 00:00:00 [g.region] > > > ---------------------------------------------------------------------- > > You can respond by visiting: > http://wald.intevation.org/tracker/?func=detail&atid=204&aid=355&group_id=21 ------ End of Forwarded Message From hamish_nospam at yahoo.com Thu Apr 5 08:30:30 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Apr 5 08:30:35 2007 Subject: [GRASS-dev] gis.m crashes on zoom-out Message-ID: <20070405183030.438e5df3.hamish_nospam@yahoo.com> Hi, found a bug in gis.m zoom out tool. start gis.m, select zoom out, draw a box, and poof! gis.m crashes. happens always in a lat long location when you zoom out past 90NS 180EW view or a bit harder to trigger in spearfish, but crashes on the 4th or 5th zoom out when the rows*cols gets to be something silly like 500e6*500e6. presumably g.region exits with an error which isn't handled well. testing with a few revisions of mapcanvas.tcl: (the oldest error handling gives the most useful debug info here) mapcanvas.tcl rev <= 1.57: popup window: ERROR: ** invalid input ** ERROR: ** invalid input ** while executing "close $input" (procedure "MapCanvas::runprograms" line 40) invoked from within "MapCanvas::runprograms $mon [expr {$mymodified != 0}]" (procedure "MapCanvas::drawmap" line 38) [...] mapcanvas.tcl rev 1.58, .59: popup window: child process exited abnormally child process exited abnormally while executing "close $input" (procedure "MapCanvas::runprograms" line 40) invoked from within "MapCanvas::runprograms $mon [expr {$mymodified != 0}]" (procedure "MapCanvas::drawmap" line 38) [...] mapcanvas.tcl rev 1.60 and newer: gis.m crashes completely with "child process exited abnormally" printed at the terminal prompt. 6.2.1 spearfish + huge region gives this error: ERROR: Invalid region: North must be larger than South ERROR: Invalid region: North must be larger than South while executing "close $input" (procedure "MapCanvas::runprograms" line 39) invoked from within "MapCanvas::runprograms $mon [expr {$mymodified != 0}]" (procedure "MapCanvas::drawmap" line 38) 6.2.1 lat/lon + beyond 90NS gives this error: ERROR: ** invalid input ** ERROR: ** invalid input ** while executing "close $input" (procedure "MapCanvas::runprograms" line 39) invoked from within "MapCanvas::runprograms $mon [expr {$mymodified != 0}]" (procedure "MapCanvas::drawmap" line 38) Hamish (away for the next week+) From hamish_nospam at yahoo.com Thu Apr 5 09:00:36 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Apr 5 09:00:47 2007 Subject: [GRASS-dev] discussion: replacing ps.map In-Reply-To: <200703301848.l2UImtCt061882@smtp.spinn.net> References: <200703271700.l2RH0ksx037876@smtp.spinn.net> <200703272136.l2RLavxR089601@smtp.spinn.net> <20070329185103.31387478.hamish_nospam@yahoo.com> <1175174154.20390.25.camel@linux.home> <20070330191440.484c093e.hamish_nospam@yahoo.com> <200703301848.l2UImtCt061882@smtp.spinn.net> Message-ID: <20070405190036.4e7419d4.hamish_nospam@yahoo.com> [d.labels placement with rotation is getting there, partial replacement code is now in CVS (disabled, but working)] roger wrote: > mapinfo is placed with a coordinate system in inches, originating at > the bottom left of the map and increasing up and to the right. Other > ps.map commands that use lengths (rather than percents) use a > coordinate system that starts at the top left and increases down and > to the right. I'll look into it, but if it is inconsistent we can't change it until GRASS 7 as this will break many peoples scripts/templates. > The content of the mapinfo block isn't configurable > and includes region information that I would probably never place on > a map. mapinfo is made up of scale + region. If you only want scale use the text or comment instruction to write "SCALE: $scale" text. > Also, the mapinfo product was never drawn with a bounding > box, even when the bounding box color was specified. yes I think I remember this bug. it does get the box if it is placed within the map box but not outside?? Work around: use the rectangle tool to place a box behind it. > vlegends is placed with a coordinate system like that used for > mapinfo, except that if the mapinfo block is present, the origin of > the legend is at the bottom left of the information block rather than > at the bottom left of the map. Y coordinates less than 0 were > ignored (this is documented behavior), which means that the legend > will always be attached without a margin to the bottom edge of either > the mapinfo block or the map itself. > > It would be nice to have a consistent means of locating features on a > map, and it would be nice to be able to set locations below the map. > > The example map I used had data from 3 vector files - two with areas > and one with points. The legend produced by vlegend never contained > more than 2 entries. It appeared to pick up the first area vector > and skip all subsequent area vectors. I also plotted 4 separate > polygons from one of the files with a different color for each > polygon. That was done with 4 varea entries in the ps.map > configuration file, each specifying a different cat number and a > different color. The legend still contained only one entry -- the > entry for first varea in the configuration file. this is not my experience, but I hardly ever do any vector stuff beyond a simple coastline, and not thematic vector stuff, so I may not have run into it and have not worked on vlegends much at all. > The legend contained an entry for the point data, but no entry for the > boundary lines. ?perhaps only features with cats get listed? > All of the vector features were grouped together into one legend. It > would be nice to separate them. In fact, it would generally be a > good thing to be able to select what vector features appeared in the > legend. sorting by vpoints, vlines, vareas would be nice. can't sort maps directly as vector maps may contain all three of those. An option for a vector map to skip the legend might be nice. > When the legend was split into more than one column I got a different > box around each column. That should be configurable. I would > normally prefer that the legend fall entirely within one box. The > spacing between columns was large and also not configurable; it > should be configurable. > > The user should be able to specify the width and/or style of the > border line drawn around the legend. It would also be good to > specify the margin between the legend content and the bounding line. my feeling is that if the defaults look really good, the user won't ever think to want a control to adjust the fine details. I'd like to have the default look really good first, and then see which adjustments are still frustrating not to have -- rather than provide complicated 747 cockpit control panel from the start. > The user should be able to add a title for the legend. For vlegends that's doable. For raster legends I hope to add G_set_raster_units() and G_get_raster_units() to write/read a simple string containing raster data units (set from "r.support units=") which will be stored in $MAPSET/cell_misc/$RASTERMAP/units. Raster legends and things like lat/lon NVIZ and r.shaded.relief could use the tag if it existed. please make use of the bug/wish trackers. Hamish From grass-codei at wald.intevation.org Thu Apr 5 12:01:55 2007 From: grass-codei at wald.intevation.org (grass-codei@wald.intevation.org) Date: Thu Apr 5 12:01:58 2007 Subject: [GRASS-dev] [grass-code I][359] GRASS fails to build with make -j3 Message-ID: <20070405100155.BE9171973F9B@pyrosoma.intevation.org> code I item #359, was opened at 2007-04-05 12:01 Status: Open Priority: 4 Submitted By: Maciej Sieczka (msieczka) Assigned to: Nobody (None) Summary: GRASS fails to build with make -j3 Issue type: other bug Issue status: None GRASS version: CVS HEAD GRASS component: build Operating system: all Operating system version: GRASS CVS checkout date, if applies (YYMMDD): 050407 Initial Comment: On multi cpu machines it is possible to speed up compilation time greatly using the -j switch with make (eg. -j3 for 2 cpus). make -j3 works fine on my dual core Intel with all the software I'm building from source (including eg. PROJ, GEOS, HDF4, POSTGIS, GDAL, QT4). But when I build GRASS with make -j3, plenty of errors crop out after "Waiting for unfinished jobs...." information. In a result, no single GRASS module is build properly. However, GRASS builds fine on the same machine if -j3 is not used. configure and make logs attached. Maciek ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=359&group_id=21 From glynn at gclements.plus.com Thu Apr 5 14:42:28 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Apr 5 14:42:36 2007 Subject: [GRASS-dev] FW: [grass-code I][355] A lot of processes around while working - Georectifier In-Reply-To: References: <20070404202300.2F5FD1973F9B@pyrosoma.intevation.org> Message-ID: <17940.61108.994637.975978@cerise.gclements.plus.com> Michael Barton wrote: > I just looked at georect.tcl > > All 'open' calls to g.region are to return values and are followed by > closes. So I'm not sure where this is from. > > Using the georectifier does also use the map display. So maybe it is due to > the issue I just fixed by switching open to exec for calling g.region in the > set_wind procedure. I'm fairly sure that's the case. I searched for "g.region" in the gis.m code, and the one in MapCanvas::set_wind is the only one which looked wrong. -- Glynn Clements From glynn at gclements.plus.com Thu Apr 5 14:48:20 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Apr 5 14:48:25 2007 Subject: [GRASS-dev] gis.m crashes on zoom-out In-Reply-To: <20070405183030.438e5df3.hamish_nospam@yahoo.com> References: <20070405183030.438e5df3.hamish_nospam@yahoo.com> Message-ID: <17940.61460.168535.770304@cerise.gclements.plus.com> Hamish wrote: > found a bug in gis.m zoom out tool. > > start gis.m, select zoom out, draw a box, and poof! gis.m crashes. > > happens always in a lat long location when you zoom out past 90NS 180EW > view or a bit harder to trigger in spearfish, but crashes on the 4th or > 5th zoom out when the rows*cols gets to be something silly like 500e6*500e6. > > > presumably g.region exits with an error which isn't handled well. Yep. If you spawn a child process with "open |...", any errors are reported by way of the corresponding "close" throwing an exception. Tcl's definition of "error" includes anything being written to stderr (so any warnings are treated as errors), as well as a non-zero exit code. Any calls to "close" on a subprocess pipe should be enclosed in a catch statement. -- Glynn Clements From roger at spinn.net Thu Apr 5 14:36:42 2007 From: roger at spinn.net (Roger Miller) Date: Thu Apr 5 14:50:21 2007 Subject: [GRASS-dev] discussion: replacing ps.map In-Reply-To: <20070405190036.4e7419d4.hamish_nospam@yahoo.com> References: <200703271700.l2RH0ksx037876@smtp.spinn.net> <200703272136.l2RLavxR089601@smtp.spinn.net> <20070329185103.31387478.hamish_nospam@yahoo.com> <1175174154.20390.25.camel@linux.home> <20070330191440.484c093e.hamish_nospam@yahoo.com> <200703301848.l2UImtCt061882@smtp.spinn.net> <20070405190036.4e7419d4.hamish_nospam@yahoo.com> Message-ID: <1175776603.14231.5.camel@linux.home> On Thu, 2007-04-05 at 19:00 +1200, Hamish wrote: > [d.labels placement with rotation is getting there, partial replacement > code is now in CVS (disabled, but working)] Hamish, Thanks for addressing the problems. Roger From glynn at gclements.plus.com Thu Apr 5 15:05:53 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Apr 5 15:05:57 2007 Subject: [GRASS-dev] [grass-code I][359] GRASS fails to build with make -j3 In-Reply-To: <20070405100155.BE9171973F9B@pyrosoma.intevation.org> References: <20070405100155.BE9171973F9B@pyrosoma.intevation.org> Message-ID: <17940.62513.704845.161917@cerise.gclements.plus.com> grass-codei@wald.intevation.org wrote: > code I item #359, was opened at 2007-04-05 12:01 > Status: Open > Priority: 4 > Submitted By: Maciej Sieczka (msieczka) > Assigned to: Nobody (None) > Summary: GRASS fails to build with make -j3 > Issue type: other bug > Issue status: None > GRASS version: CVS HEAD > GRASS component: build > Operating system: all > Operating system version: > GRASS CVS checkout date, if applies (YYMMDD): 050407 > > > Initial Comment: > On multi cpu machines it is possible to speed up compilation time > greatly using the -j switch with make (eg. -j3 for 2 cpus). > > make -j3 works fine on my dual core Intel with all the software I'm > building from source (including eg. PROJ, GEOS, HDF4, POSTGIS, GDAL, > QT4). > > But when I build GRASS with make -j3, plenty of errors crop out > after "Waiting for unfinished jobs...." information. In a result, no > single GRASS module is build properly. However, GRASS builds fine on > the same machine if -j3 is not used. > > configure and make logs attached. The first thing I notice is that the first error is usually a missing header file, e.g.: copy.c:7:28: error: grass/datetime.h: No such file or directory adj_cellhd.c:14:23: error: grass/gis.h: No such file or directory This is due to the "headers" target in the "libs" directory being run in parallel with other jobs. This specific issue can probably be solved by changing lib/Makefile from: default: headers subdirs to: default: subdirs subdirs: headers This should prevent the subdirs target from being run before the headers target has completed. However: I'm not sure whether parallel make will actually be useful with the existing Makefiles, due to the use of a shell "for" loop for building subdirectories: subdirs: @list='$(SUBDIRS)'; \ for subdir in $$list; do \ echo $$subdir ; \ $(MAKE) -C $$subdir || echo $(CURDIR)/$$subdir >> $(GRASS_HOME)/error.log; \ done [From include/Make/Dir.make] To have the subdirectories built in parallel, you would need to use something like: .PHONY: subdirs $(SUBDIRS) subdirs: $(SUBDIRS) $(SUBDIRS): $(MAKE) -C $@ -- Glynn Clements From hamish_nospam at yahoo.com Thu Apr 5 16:18:49 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Apr 5 16:18:59 2007 Subject: [GRASS-dev] gis.m crashes on zoom-out In-Reply-To: <17940.61460.168535.770304@cerise.gclements.plus.com> References: <20070405183030.438e5df3.hamish_nospam@yahoo.com> <17940.61460.168535.770304@cerise.gclements.plus.com> Message-ID: <20070406021849.3823fe38.hamish_nospam@yahoo.com> > Hamish wrote: > > found a bug in gis.m zoom out tool. > > > > start gis.m, select zoom out, draw a box, and poof! gis.m crashes. > > > > happens always in a lat long location when you zoom out past 90NS > > 180EW view or a bit harder to trigger in spearfish, but crashes on > > the 4th or 5th zoom out when the rows*cols gets to be something > > silly like 500e6*500e6. > > > > > > presumably g.region exits with an error which isn't handled well. Glynn Clements wrote: > Yep. > > If you spawn a child process with "open |...", any errors are reported > by way of the corresponding "close" throwing an exception. Tcl's > definition of "error" includes anything being written to stderr (so > any warnings are treated as errors), as well as a non-zero exit code. > > Any calls to "close" on a subprocess pipe should be enclosed in a > catch statement. gui/tcltk/gis.m$ grep close * | grep -v catch finds this one in georect.tcl proc GRMap::zoom_gregion { args} { and in histogram.tcl: proc GmHist::display { node mod } { and in rastnums.tcl: proc GmRnums::display { node mod } { and in runandoutput.tcl: proc guarantee_xmon {} { ..maybe more? I don't see the open|g.region in mapcanvas.tcl which triggers this bug? I seem to remember the georect tool crashing gis.m had been reported. No time right now to actually fix these myself. Hamish From glynn at gclements.plus.com Thu Apr 5 18:34:08 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Apr 5 18:34:10 2007 Subject: [GRASS-dev] gis.m crashes on zoom-out In-Reply-To: <20070406021849.3823fe38.hamish_nospam@yahoo.com> References: <20070405183030.438e5df3.hamish_nospam@yahoo.com> <17940.61460.168535.770304@cerise.gclements.plus.com> <20070406021849.3823fe38.hamish_nospam@yahoo.com> Message-ID: <17941.9472.210910.297736@cerise.gclements.plus.com> Hamish wrote: > > Hamish wrote: > > > found a bug in gis.m zoom out tool. > > > > > > start gis.m, select zoom out, draw a box, and poof! gis.m crashes. > > > > > > happens always in a lat long location when you zoom out past 90NS > > > 180EW view or a bit harder to trigger in spearfish, but crashes on > > > the 4th or 5th zoom out when the rows*cols gets to be something > > > silly like 500e6*500e6. > > > > > > > > > presumably g.region exits with an error which isn't handled well. > > Glynn Clements wrote: > > Yep. > > > > If you spawn a child process with "open |...", any errors are reported > > by way of the corresponding "close" throwing an exception. Tcl's > > definition of "error" includes anything being written to stderr (so > > any warnings are treated as errors), as well as a non-zero exit code. > > > > Any calls to "close" on a subprocess pipe should be enclosed in a > > catch statement. > > > gui/tcltk/gis.m$ grep close * | grep -v catch > > > finds this one in georect.tcl > proc GRMap::zoom_gregion { args} { > > and in histogram.tcl: > proc GmHist::display { node mod } { > > and in rastnums.tcl: > proc GmRnums::display { node mod } { > > and in runandoutput.tcl: > proc guarantee_xmon {} { > > > ..maybe more? > > > I don't see the open|g.region in mapcanvas.tcl which triggers this bug? Line 585, in Mapcanvas::runprograms: if {[catch {close $input} error]} { puts $error exit 1 } It catches the error, then prints the error message and exits. Not really much point in catching it. -- Glynn Clements From neteler at itc.it Thu Apr 5 18:45:12 2007 From: neteler at itc.it (Markus Neteler) Date: Thu Apr 5 18:45:13 2007 Subject: [GRASS-dev] enable forwarding all GRASS GForge traffic to grass-dev ML? In-Reply-To: <4613F774.2080404@o2.pl> References: <4611761A.70609@o2.pl> <20070403125345.14b0ede6.hamish_nospam@yahoo.com> <4612120A.8040009@itc.it> <46127E22.4090306@o2.pl> <20070404140603.4485a4b0.hamish_nospam@yahoo.com> <4613F774.2080404@o2.pl> Message-ID: <46152798.2040003@itc.it> Maciej Sieczka wrote on 04/04/2007 09:07 PM: > Hamish wrote: > >> Maciej Sieczka wrote: >> >>>>> Maybe add grass-dev as an interested party in the bug report? >>>>> >>> That's what I asked about in this thread. So, should I? Mind that each >>> email from GForge trackers will include the whole thread (all >>> messages), with the original message on top, the most recent next, and >>> all older messages after that, in chronological order (newer first, >>> older next). >>> >> probably do not do that until the noise issues are worked out. >> more noise = less productivity >> too much noise = less developers >> > > OK. > > Maciek > > ... now a Gforge bug report: http://wald.intevation.org/tracker/index.php?func=detail&aid=360&group_id=1&atid=162 You may "Monitor" it (take the left "Monitor" link, not the top one). Markus ------------------ ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler ITC -> since 1 March 2007 Fondazione Bruno Kessler ------------------ From woklist at kyngchaos.com Thu Apr 5 19:50:49 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Thu Apr 5 19:50:55 2007 Subject: [GRASS-dev] html browser or help browser? Message-ID: <4685C3D1-BAED-4AB7-A927-A8006FB72EE6@kyngchaos.com> I have a patch ready to fix the (potential) html_browser run problem on OSX (OSX .app executables shouldn't be run directly from the CLI). But I was wondering about the GRASS_HTML_BROWSER usage - as far as I can tell it's only used for viewing help files, but the name suggests it could be used for general web html browsing, if a module had some web link in it for some reason. Is GRASS_HTML_BROWSER intended only for help viewing, or general web viewing also? ----- William Kyngesburye http://www.kyngchaos.com/ Earth: "Mostly harmless" - revised entry in the HitchHiker's Guide to the Galaxy From woklist at kyngchaos.com Fri Apr 6 06:18:50 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Fri Apr 6 06:19:01 2007 Subject: [GRASS-dev] discussion: replacing ps.map In-Reply-To: <17939.31421.384601.500919@cerise.gclements.plus.com> References: <17930.59855.699533.647215@cerise.gclements.plus.com> <17932.16901.672831.128404@cerise.gclements.plus.com> <17936.45593.765285.836412@cerise.gclements.plus.com> <17936.59188.242469.82716@cerise.gclements.plus.com> <17939.31421.384601.500919@cerise.gclements.plus.com> Message-ID: I'm having a problem building libraster now. I get a bunch of multiple definitions errors between the linked pngdriver and psdriver when linking the raster library. _true_color _height _width _init_color_table My last build was Apr 2, and successful. On Apr 4, 2007, at 5:15 AM, Glynn Clements wrote: > Having eliminated all use of the unscaled raster operations, I've > removed them from the drivers, and moved the scaled raster operations > into the drivers. This should all be transparent to the user but, like > any change to the driver protocol, the changes are relatively > invasive, so there's always the possibility of bugs creeping in. > > Also, direct rendering can now produce PostScript as an alternative to > PNG or PPM files. The GRASS_RENDER_IMMEDIATE environment variable has > been extended to accept values of PNG (generate PNG or PPM output, > equivalent to GRASS_RENDER_IMMEDIATE=TRUE) and PS (generate PostScript > output). > ----- William Kyngesburye http://www.kyngchaos.com/ All generalizations are dangerous, even this one. From jachym.cepicky at centrum.cz Fri Apr 6 09:22:19 2007 From: jachym.cepicky at centrum.cz (=?ISO-8859-2?Q?J=E1chym_=C8epick=FD?=) Date: Fri Apr 6 09:22:22 2007 Subject: [GRASS-dev] discussion: replacing ps.map In-Reply-To: <17932.40292.139762.620114@cerise.gclements.plus.com> References: <17929.35602.196088.815592@cerise.gclements.plus.com> <20070327224018.3aec7e67@localhost.localdomain> <460A273A.1060109@club.worldonline.be> <20070328092330.GA928@polynum.com> <17930.59855.699533.647215@cerise.gclements.plus.com> <17932.40292.139762.620114@cerise.gclements.plus.com> Message-ID: Hi, the PS driver works nice, thanks! What about d.text.freetype ? I wonder how complicated it would be to implement too..? Jachym 2007/3/30, Glynn Clements : > > Glynn Clements wrote: > > > > > Thierry, I have a very vague memory that you said something about KerGIS > > > > being able to directly produce vectorized output. Is this true ? How do > > > > you do this ? > > > > > > By using the legacy RASTERLIB now called DRAWLIB in KerGIS. The > > > documentation about the library is misleading. It is not raster oriented > > > if you take juste the library that is just an API and a communication > > > facility to monitors. The API is a drawing API: you draw not only raster > > > images, but lines, polylines etc. > > > > > > In KerGIS, there is only one driver: the X11 one. And it uses the X11 > > > vector drawing XLIB functions for lines etc. > > > > > > In this sense, it is not difficult to implement a psdriver. > > > > It isn't difficult to implement, but it won't necessarily be of much > > use given the existing API. > > FWIW, I've committed a basic PostScript driver to CVS. > > It's behaviour is similar to the PNG driver. The output file is > controlled by $GRASS_PSFILE, defaulting to "map.ps". If > $GRASS_TRUECOLOR == "TRUE", it will generate colour output, otherwise > grey-scale. > > $GRASS_{WIDTH,HEIGHT} specify the monitor dimensions in points > (1/72"), and all coordinates are interpreted as points. This means > that all drawing primitives are snapped to a 1-point grid, although > rendering will be performed at the actual device resolution. > > At present, there are doubtless many things which don't work > correctly, or are sub-optimal (especially polygon filling, which > currently uses the generic software renderer, i.e. lots of horizontal > lines). > > Masked images (e.g. "d.rast -o") require level 3 PostScript; colour > images require level 2 or a level 1 implementation which supports the > colorimage operator. Unmasked grey-scale images should work on > anything. > > Anything which doesn't explicitly specify a line width (i.e. probably > everything except "d.vect ... width=...") will end up using a line > width of zero, which is probably not much use on a printer. > > -- > Glynn Clements > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > -- Jachym Cepicky e-mail: jachym.cepicky gmail com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub From hamish_nospam at yahoo.com Fri Apr 6 09:22:44 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Apr 6 09:22:51 2007 Subject: [GRASS-dev] improved d.labels rendering Message-ID: <20070406192244.5a4ee513.hamish_nospam@yahoo.com> Hi, Text rotation now works properly in d.labels for any justification setting. Also placement is improved for all center and lower justified text. Even multi-line labels are working correctly. Only lightly tested so far. For TrueType fonts you need to set the path to the font name in the v.label step. (run-time override won't work anymore) Hamish From glynn at gclements.plus.com Fri Apr 6 13:12:40 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Apr 6 13:12:44 2007 Subject: [GRASS-dev] discussion: replacing ps.map In-Reply-To: References: <17930.59855.699533.647215@cerise.gclements.plus.com> <17932.16901.672831.128404@cerise.gclements.plus.com> <17936.45593.765285.836412@cerise.gclements.plus.com> <17936.59188.242469.82716@cerise.gclements.plus.com> <17939.31421.384601.500919@cerise.gclements.plus.com> Message-ID: <17942.11048.534533.376037@cerise.gclements.plus.com> William Kyngesburye wrote: > I'm having a problem building libraster now. I get a bunch of > multiple definitions errors between the linked pngdriver and psdriver > when linking the raster library. > > _true_color > _height > _width > _init_color_table Can you find out whether the Mac linker has an option to ignore duplicate symbols (at least for the case where none of the symbols are actually being imported)? If it does, adding that switch to the definition of SHLIB_LD in SC_CONFIG_CFLAGS (in aclocal.m4) is the appropriate solution. If it doesn't, I can give these functions/variables unique names, but that's really just a workaround; this issue is likely to crop up again in the future. -- Glynn Clements From glynn at gclements.plus.com Fri Apr 6 13:27:12 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Apr 6 13:27:17 2007 Subject: [GRASS-dev] discussion: replacing ps.map In-Reply-To: References: <17929.35602.196088.815592@cerise.gclements.plus.com> <20070327224018.3aec7e67@localhost.localdomain> <460A273A.1060109@club.worldonline.be> <20070328092330.GA928@polynum.com> <17930.59855.699533.647215@cerise.gclements.plus.com> <17932.40292.139762.620114@cerise.gclements.plus.com> Message-ID: <17942.11920.264665.707513@cerise.gclements.plus.com> J-B?chym ?epick? wrote:-A > the PS driver works nice, thanks! > > What about d.text.freetype ? I wonder how complicated it would be to > implement too..? Huh? d.text.freetype should work with the PS driver, although it will rasterise the bitmaps at a resolution of 1 point, then embed the bitmaps. Also, d.text.freetype and d.font.freetype are redundant. d.text, d.text.new, and d.font all work with FreeType fonts (again, the actual fonts will be rasterised). If you're talking about using PostScript fonts, it wouldn't be particularly hard to pass R_font() along to the driver (R_text() can already be overriden by the driver). However: 1. PostScript tends to use non-standard encodings. You can reliably create ISO-8859-1 versions of built-in fonts (ps.map does this), but anything beyond that is problematic. 2. Implementing R_get_text_box() would be a lot of work, and would require that you had the corresponding AFM/PFM files (and the driver would have to know where to find them). -- Glynn Clements From jachym.cepicky at gmail.com Fri Apr 6 14:08:20 2007 From: jachym.cepicky at gmail.com (Jachym Cepicky) Date: Fri Apr 6 14:08:22 2007 Subject: [GRASS-dev] discussion: replacing ps.map In-Reply-To: <17942.11920.264665.707513@cerise.gclements.plus.com> References: <17929.35602.196088.815592@cerise.gclements.plus.com> <20070327224018.3aec7e67@localhost.localdomain> <460A273A.1060109@club.worldonline.be> <20070328092330.GA928@polynum.com> <17930.59855.699533.647215@cerise.gclements.plus.com> <17932.40292.139762.620114@cerise.gclements.plus.com> <17942.11920.264665.707513@cerise.gclements.plus.com> Message-ID: hi, tahanks for you answer 2007/4/6, Glynn Clements : > > J-B?chym ?epick? wrote:-A > > > the PS driver works nice, thanks! > > > > What about d.text.freetype ? I wonder how complicated it would be to > > implement too..? > > Huh? > > d.text.freetype should work with the PS driver, although it will > rasterise the bitmaps at a resolution of 1 point, then embed the > bitmaps. d.mon PS d.text.freetype font=luximr text="hallo, world" at=10,10 d.mon stop=PS gv map.ps document is not opend same for d.font && d.text What am I missing? In standard monitor it works nice, PNG driver too.. Thanks a lot Jachym > > Also, d.text.freetype and d.font.freetype are redundant. d.text, > d.text.new, and d.font all work with FreeType fonts (again, the actual > fonts will be rasterised). > > If you're talking about using PostScript fonts, it wouldn't be > particularly hard to pass R_font() along to the driver (R_text() can > already be overriden by the driver). However: > > 1. PostScript tends to use non-standard encodings. You can reliably > create ISO-8859-1 versions of built-in fonts (ps.map does this), but > anything beyond that is problematic. > > 2. Implementing R_get_text_box() would be a lot of work, and would > require that you had the corresponding AFM/PFM files (and the driver > would have to know where to find them). > > -- > Glynn Clements > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > -- Jachym Cepicky e-mail: jachym.cepicky gmail com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub From glynn at gclements.plus.com Fri Apr 6 15:54:15 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Apr 6 15:54:19 2007 Subject: [GRASS-dev] discussion: replacing ps.map In-Reply-To: References: <17929.35602.196088.815592@cerise.gclements.plus.com> <20070327224018.3aec7e67@localhost.localdomain> <460A273A.1060109@club.worldonline.be> <20070328092330.GA928@polynum.com> <17930.59855.699533.647215@cerise.gclements.plus.com> <17932.40292.139762.620114@cerise.gclements.plus.com> <17942.11920.264665.707513@cerise.gclements.plus.com> Message-ID: <17942.20743.15986.354201@cerise.gclements.plus.com> Jachym Cepicky wrote: > hi, > tahanks for you answer > > 2007/4/6, Glynn Clements : > > > > J-B?chym ?epick? wrote:-A > > > > > the PS driver works nice, thanks! > > > > > > What about d.text.freetype ? I wonder how complicated it would be to > > > implement too..? > > > > Huh? > > > > d.text.freetype should work with the PS driver, although it will > > rasterise the bitmaps at a resolution of 1 point, then embed the > > bitmaps. > > d.mon PS > d.text.freetype font=luximr text="hallo, world" at=10,10 > d.mon stop=PS > > gv map.ps > > document is not opend Oops. There are a couple of bugs in the bitmap code. The first is in the prolog; the string is allocated with one byte per pixel, when it should be one bit, causing too much data to be read. Index: lib/psdriver/psdriver.ps =================================================================== RCS file: /grassrepository/grass6/lib/psdriver/psdriver.ps,v retrieving revision 1.2 diff -u -r1.2 psdriver.ps --- lib/psdriver/psdriver.ps 30 Mar 2007 06:29:35 -0000 1.2 +++ lib/psdriver/psdriver.ps 6 Apr 2007 13:48:00 -0000 @@ -39,7 +39,7 @@ /BITMAP { gsave 4 2 roll translate - 1 index string /tmpstr exch def + 1 index 7 add 8 idiv string /tmpstr exch def true [1 0 0 1 0 0] {currentfile tmpstr readhexstring pop} imagemask grestore } bind def If you make this change to the map.ps file, the file should display, but you'll notice the second bug; the accumulator wasn't being cleared, resulting in "echoes": Index: lib/psdriver/Draw_bitmap.c =================================================================== RCS file: /grassrepository/grass6/lib/psdriver/Draw_bitmap.c,v retrieving revision 1.1 diff -u -r1.1 Draw_bitmap.c --- lib/psdriver/Draw_bitmap.c 30 Mar 2007 04:51:23 -0000 1.1 +++ lib/psdriver/Draw_bitmap.c 6 Apr 2007 13:48:00 -0000 @@ -25,6 +25,7 @@ { output("%02X", acc); bit = 0x80; + acc = 0; } } Both of these are fixed in CVS, and it appears to work. > same for d.font && d.text > > What am I missing? That I said "should work" rather than "does work" ;) This time, I have actually tested it. -- Glynn Clements From woklist at kyngchaos.com Fri Apr 6 16:02:33 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Fri Apr 6 16:02:44 2007 Subject: [GRASS-dev] discussion: replacing ps.map In-Reply-To: <17942.11048.534533.376037@cerise.gclements.plus.com> References: <17930.59855.699533.647215@cerise.gclements.plus.com> <17932.16901.672831.128404@cerise.gclements.plus.com> <17936.45593.765285.836412@cerise.gclements.plus.com> <17936.59188.242469.82716@cerise.gclements.plus.com> <17939.31421.384601.500919@cerise.gclements.plus.com> <17942.11048.534533.376037@cerise.gclements.plus.com> Message-ID: On Apr 6, 2007, at 6:12 AM, Glynn Clements wrote: > William Kyngesburye wrote: > >> I'm having a problem building libraster now. I get a bunch of >> multiple definitions errors between the linked pngdriver and psdriver >> when linking the raster library. >> >> _true_color >> _height >> _width >> _init_color_table > > Can you find out whether the Mac linker has an option to ignore > duplicate symbols (at least for the case where none of the symbols are > actually being imported)? > > If it does, adding that switch to the definition of SHLIB_LD in > SC_CONFIG_CFLAGS (in aclocal.m4) is the appropriate solution. > > If it doesn't, I can give these functions/variables unique names, but > that's really just a workaround; this issue is likely to crop up again > in the future. The flag to manually make them warnings is -multiply_defined warning (or suppress). But it's really an effect of using a flat namespace. -flat_namespace (and -fno-common) might be a holdover from the early Mac days building GRASS, when there were probably issues. The default on OSX, since 10.1, is a two-level namespace, where multiply- defined symbols are a warning by default. I removed -flat_namespace from my SHLIB_LD in platform.make (quick-n- dirty hack). The multiply-defined symbols don't break the raster library linking now. But instead I have an undefined symbol in the display library: ld: Undefined symbols: _PS_Driver referenced from libgrass expected to be defined in / Applications/GRASS-6.3.app/Contents/Resources/lib/ libgrass_psdriver.dylib (that 'libgrass' got truncated, it's really libgrass_display - it's an intentional quirk of the OSX linker) ----- William Kyngesburye http://www.kyngchaos.com/ "Time is an illusion - lunchtime doubly so." - Ford Prefect From jachym.cepicky at gmail.com Fri Apr 6 16:07:58 2007 From: jachym.cepicky at gmail.com (Jachym Cepicky) Date: Fri Apr 6 16:08:01 2007 Subject: [GRASS-dev] discussion: replacing ps.map In-Reply-To: <17942.20743.15986.354201@cerise.gclements.plus.com> References: <20070327224018.3aec7e67@localhost.localdomain> <460A273A.1060109@club.worldonline.be> <20070328092330.GA928@polynum.com> <17930.59855.699533.647215@cerise.gclements.plus.com> <17932.40292.139762.620114@cerise.gclements.plus.com> <17942.11920.264665.707513@cerise.gclements.plus.com> <17942.20743.15986.354201@cerise.gclements.plus.com> Message-ID: Glynn, I confirm, it works like a charm now!! thanks a lot btw: what do you think about replacement of ps.map with new PS driver && d.* commands? would it be easier to add line styles and area fillings to ps.map (where it partely is, at least the areas) or to d.rast/d.vect ? I think, it would be great to have only one set of tools for both - data displaying and hard copy maps preparation... jachym 2007/4/6, Glynn Clements : > > Jachym Cepicky wrote: > > > hi, > > tahanks for you answer > > > > 2007/4/6, Glynn Clements : > > > > > > J-B?chym ?epick? wrote:-A > > > > > > > the PS driver works nice, thanks! > > > > > > > > What about d.text.freetype ? I wonder how complicated it would be to > > > > implement too..? > > > > > > Huh? > > > > > > d.text.freetype should work with the PS driver, although it will > > > rasterise the bitmaps at a resolution of 1 point, then embed the > > > bitmaps. > > > > d.mon PS > > d.text.freetype font=luximr text="hallo, world" at=10,10 > > d.mon stop=PS > > > > gv map.ps > > > > document is not opend > > Oops. There are a couple of bugs in the bitmap code. > > The first is in the prolog; the string is allocated with one byte per > pixel, when it should be one bit, causing too much data to be read. > > Index: lib/psdriver/psdriver.ps > =================================================================== > RCS file: /grassrepository/grass6/lib/psdriver/psdriver.ps,v > retrieving revision 1.2 > diff -u -r1.2 psdriver.ps > --- lib/psdriver/psdriver.ps 30 Mar 2007 06:29:35 -0000 1.2 > +++ lib/psdriver/psdriver.ps 6 Apr 2007 13:48:00 -0000 > @@ -39,7 +39,7 @@ > /BITMAP { > gsave > 4 2 roll translate > - 1 index string /tmpstr exch def > + 1 index 7 add 8 idiv string /tmpstr exch def > true [1 0 0 1 0 0] {currentfile tmpstr readhexstring pop} imagemask > grestore > } bind def > > If you make this change to the map.ps file, the file should display, > but you'll notice the second bug; the accumulator wasn't being > cleared, resulting in "echoes": > > Index: lib/psdriver/Draw_bitmap.c > =================================================================== > RCS file: /grassrepository/grass6/lib/psdriver/Draw_bitmap.c,v > retrieving revision 1.1 > diff -u -r1.1 Draw_bitmap.c > --- lib/psdriver/Draw_bitmap.c 30 Mar 2007 04:51:23 -0000 1.1 > +++ lib/psdriver/Draw_bitmap.c 6 Apr 2007 13:48:00 -0000 > @@ -25,6 +25,7 @@ > { > output("%02X", acc); > bit = 0x80; > + acc = 0; > } > } > > Both of these are fixed in CVS, and it appears to work. > > > same for d.font && d.text > > > > What am I missing? > > That I said "should work" rather than "does work" ;) > > This time, I have actually tested it. > > -- > Glynn Clements > -- Jachym Cepicky e-mail: jachym.cepicky gmail com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub From glynn at gclements.plus.com Fri Apr 6 16:29:45 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Apr 6 16:29:50 2007 Subject: [GRASS-dev] discussion: replacing ps.map In-Reply-To: References: <17930.59855.699533.647215@cerise.gclements.plus.com> <17932.16901.672831.128404@cerise.gclements.plus.com> <17936.45593.765285.836412@cerise.gclements.plus.com> <17936.59188.242469.82716@cerise.gclements.plus.com> <17939.31421.384601.500919@cerise.gclements.plus.com> <17942.11048.534533.376037@cerise.gclements.plus.com> Message-ID: <17942.22873.983794.982715@cerise.gclements.plus.com> William Kyngesburye wrote: > >> I'm having a problem building libraster now. I get a bunch of > >> multiple definitions errors between the linked pngdriver and psdriver > >> when linking the raster library. > >> > >> _true_color > >> _height > >> _width > >> _init_color_table > > > > Can you find out whether the Mac linker has an option to ignore > > duplicate symbols (at least for the case where none of the symbols are > > actually being imported)? > > > > If it does, adding that switch to the definition of SHLIB_LD in > > SC_CONFIG_CFLAGS (in aclocal.m4) is the appropriate solution. > > > > If it doesn't, I can give these functions/variables unique names, but > > that's really just a workaround; this issue is likely to crop up again > > in the future. > > The flag to manually make them warnings is -multiply_defined warning > (or suppress). But it's really an effect of using a flat namespace. > -flat_namespace (and -fno-common) might be a holdover from the early > Mac days building GRASS, when there were probably issues. The > default on OSX, since 10.1, is a two-level namespace, where multiply- > defined symbols are a warning by default. > > I removed -flat_namespace from my SHLIB_LD in platform.make (quick-n- > dirty hack). The multiply-defined symbols don't break the raster > library linking now. I'll change that in CVS. > But instead I have an undefined symbol in the > display library: > > ld: Undefined symbols: > _PS_Driver referenced from libgrass expected to be defined in / > Applications/GRASS-6.3.app/Contents/Resources/lib/ > libgrass_psdriver.dylib It appears to be using the version in /Applications rather than the local version. This suggests that the linker needs something similar to the -Wl,-rpath-link switch which is used on Linux: CC_SEARCH_FLAGS='-Wl,-rpath-link,${LIB_RUNTIME_DIR}' This tells the linker where to look for dependencies. Without that, you will need to ensure that the lib directory of any installed version of GRASS isn't searched automatically (e.g. due to $DYLD_LIBRARY_PATH or similar). > (that 'libgrass' got truncated, it's really libgrass_display - it's > an intentional quirk of the OSX linker) It's libgrass_raster which actually references PS_Driver(). Linking libgrass_raster will find the correct version of libgrass_psdriver due to the -L switches. But when linking libgrass_display against libgrass_raster, the -L switches will only tell it where to find -lraster itself; its dependencies will normally be looked for using the loader's settings ($DYLD_LIBRARY_PATH etc). -- Glynn Clements From grass-codei at wald.intevation.org Fri Apr 6 16:37:29 2007 From: grass-codei at wald.intevation.org (grass-codei@wald.intevation.org) Date: Fri Apr 6 16:37:31 2007 Subject: [GRASS-dev] [grass-code I][361] v.edit segfaults Message-ID: <20070406143729.6E01E1973F9B@pyrosoma.intevation.org> code I item #361, was opened at 2007-04-06 16:37 Status: Open Priority: 3 Submitted By: Jachym Cepicky (jachym) Assigned to: Martin Landa (martinl) Summary: v.edit segfaults Issue type: module bug Issue status: None GRASS version: CVS HEAD GRASS component: vector Operating system: Linux Operating system version: RH8 GRASS CVS checkout date, if applies (YYMMDD): 6.4. Initial Comment: v.edit tool=catadd coords=223.26666667,493.28958333 map=train cats=0 Segmentation fault ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=361&group_id=21 From neteler at itc.it Fri Apr 6 17:00:29 2007 From: neteler at itc.it (Markus Neteler) Date: Fri Apr 6 17:00:31 2007 Subject: [GRASS-dev] Proposal: release 6.2.2 Message-ID: <20070406150028.GF25552@bartok.itc.it> Hi, I think that we have accumulated enough bugfixes to get out 6.2.2 by next week. Since it is a bugfix release only, I don't feel that we need a long testing phase. I suggest to get out a release candidate by next week which can then be compiled and tested and hopefully published asap. Markus From glynn at gclements.plus.com Fri Apr 6 17:06:03 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Apr 6 17:06:13 2007 Subject: [GRASS-dev] discussion: replacing ps.map In-Reply-To: References: <20070327224018.3aec7e67@localhost.localdomain> <460A273A.1060109@club.worldonline.be> <20070328092330.GA928@polynum.com> <17930.59855.699533.647215@cerise.gclements.plus.com> <17932.40292.139762.620114@cerise.gclements.plus.com> <17942.11920.264665.707513@cerise.gclements.plus.com> <17942.20743.15986.354201@cerise.gclements.plus.com> Message-ID: <17942.25051.314376.859730@cerise.gclements.plus.com> Jachym Cepicky wrote: > btw: what do you think about replacement of ps.map with new PS driver > && d.* commands? > > would it be easier to add line styles and area fillings to ps.map > (where it partely is, at least the areas) or to d.rast/d.vect ? I > think, it would be great to have only one set of tools for both - data > displaying and hard copy maps preparation... It would certainly be *easier* to change ps.map, as ps.map generates PostScript directly. d.* commands are limited to whatever the raster library provides. If you want to add an additional operation to the graphics API, you currently have to: 1. Add a R_* function to lib/raster/com_proto.c 2. Add its prototype to include/raster.h 3. Add a field to "struct transport" in lib/raster/transport.h 4. Add an intitialiser for the field to "loc_trans" in lib/raster/com_io.c 5. Add an intitialiser for the field to "rem_trans" in lib/raster/com_io.c 6. Add a LOC_* version to lib/raster/loc_proto.c 7. Add a REM_* version to lib/raster/rem_proto.c 8. Add an opcode to include/graphics.h 9. Add a "case" to lib/driver/command.c 10. Add a COM_* version to lib/driver/.c 11. Add its prototype to lib/driver/driver.h 12. Add a field to "struct driver" in lib/driver/driver.h 13. Add a PNG_* version to lib/pngdriver/.c 14. Add the prototype to lib/pngdriver/pngdriver.h 15. Add an intitialiser for the field in lib/pngdriver/Driver.c 16. Add a PS_* version to lib/psdriver/.c 17. Add the prototype to lib/psdriver/psdriver.h 18. Add an intitialiser for the field in lib/psdriver/Driver.c 19. Add a XD_* version to display/drivers/XDRIVER/.c 20. Add the prototype to display/drivers/XDRIVER/XDRIVER.h 21. Add an intitialiser for the field in display/drivers/XDRIVER/main.c 22. Add a NULL intitialiser for the field in display/drivers/HTMLMAP/main.c If we can eliminate monitors in favour of direct rendering, we can eliminate steps 3 through 12. The R_* function would become the COM_* function, with no need to dispatch based upon local/remote transport. If we can eliminate XDRIVER in favour of a GUI which uses PPM/PNG images, that loses 3 steps. If we can eliminate the PNG driver in favour of "gs -sDEVICE=ppmraw", that loses another 3 (as well as giving better quality). Ultimately, if the PS driver was the only driver, we'd be down to just steps 1 and 2. The R_* function would become the PS_* function; there would be no need to dispatch based upon the current driver. More significantly, additional cases wouldn't need necessarily need new R_* functions; the module could just generate PostScript code directly. -- Glynn Clements From glynn at gclements.plus.com Fri Apr 6 17:08:31 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Apr 6 17:08:37 2007 Subject: [GRASS-dev] No longer able to open a mapset by symbolic link In-Reply-To: <17938.8117.39792.631929@cerise.gclements.plus.com> References: <17937.55280.228654.831177@cerise.gclements.plus.com> <46120FEF.3@itc.it> <17938.8117.39792.631929@cerise.gclements.plus.com> Message-ID: <17942.25199.728200.369661@cerise.gclements.plus.com> Glynn Clements wrote: > > >> I just retrieved the latest weekly CVS snapshot for GRASS and found > > >> I'm no longer able to access mapsets that are referred to by symbolic > > >> links in linux. > > >> > > >> Is this intended behaviour (possibly related to the windows port)? Or a bug? > > >> ... > > > AFAIK, having symlinks to mapset directories has never been > > > intentionally supported; it just happened to work. > > > > I am long term user of such mapset links, it would be a major problem for us > > to no longer have this possibility. Just to express interest in this > > issue... > > In that case, we need to add a G_stat(), and change some uses of > G_lstat() to G_stat(). > > Current users of G_lstat() are: > > general/manage/lib/do_copy.c > recursive_copy(), used by do_copy(), used by g.copy > > lib/gis/mapset_msc.c > G__mapset_permissions(), G__mapset_permissions2() > > lib/gis/remove.c > recursive_remove(), used by G_remove() > > lib/gis/unix_socks.c > _get_make_sock_path(), used by G_sock_get_fname() > > lib/gis/user_config.c > _make_toplevel(), _make_sublevels(), both used by G_rc_path() > > AFAICT, the problems are due to G__mapset_permissions() and/or > G__mapset_permissions2(). These can probably be safely changed to use > stat() instead. FWIW, I've changed these two to use G_stat(), so symlinks to mapsets should work now. -- Glynn Clements From glynn at gclements.plus.com Fri Apr 6 17:14:10 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Apr 6 17:14:20 2007 Subject: [GRASS-dev] PNG driver - slow? In-Reply-To: <17939.64401.313718.203239@cerise.gclements.plus.com> References: <17939.64401.313718.203239@cerise.gclements.plus.com> Message-ID: <17942.25538.683141.353817@cerise.gclements.plus.com> Glynn Clements wrote: > > export GRASS_PNGFILE=/tmp/pokus.png > > export GRASS_RENDER_IMMEDIATE=TRUE > > > > time d.vect map=soils@PERMANENT > > real 0m0.197s > > user 0m0.166s > > sys 0m0.019s > > > > time d.vect map=soils@PERMANENT color=yellow fcolor=yellow cats=32 width=3 > > real 0m13.767s > > user 0m13.611s > > sys 0m0.098s > > > > > > Why is the second case so slow? Is it a bug in PNG driver? What can I > > do, so it is rendered faster? > > My guess is the width=3. > > The "thick line" code in the PNG driver is a truly awful hack (see > store_xy() in lib/pngdriver/Draw_line.c). I've replaced this with a more reasonable implementation. However, note that the PNG driver doesn't have a proper polyline implementation; it just draws each segment as a separate line. This is fine for single-pixel lines, but for thicker lines the lack of proper joins may be noticeable. -- Glynn Clements From soerengebbert at gmx.de Fri Apr 6 17:23:16 2007 From: soerengebbert at gmx.de (=?ISO-8859-2?Q?S=F6ren_Gebbert?=) Date: Fri Apr 6 17:24:01 2007 Subject: [GRASS-dev] discussion: replacing ps.map In-Reply-To: <17942.20743.15986.354201@cerise.gclements.plus.com> References: <17929.35602.196088.815592@cerise.gclements.plus.com> <20070327224018.3aec7e67@localhost.localdomain> <460A273A.1060109@club.worldonline.be> <20070328092330.GA928@polynum.com> <17930.59855.699533.647215@cerise.gclements.plus.com> <17932.40292.139762.620114@cerise.gclements.plus.com> <17942.11920.264665.707513@cerise.gclements.plus.com> <17942.20743.15986.354201@cerise.gclements.plus.com> Message-ID: <461665E4.4050102@gmx.de> Hi Glynn, thanks a lot for your effort. The PS driver is working great for me and i have a couple of questions about it: 1.) If i use d.erase to erase the monitor, an ERASE statement is added to map.ps. Using the d.erase command after i have added raster or vector maps results in rerendering the "erased" content. Is there a way to reset the map.ps file to avoid rerendering of "old" maps after using d.erase? I need to stop the PS driver and restart it again to avoid rerendering. 2.) The d.vect module works fine, the lines are really smooth if the line width is set to 1. If i choose a larger line width, polylines are broken into pieces spearfish60 example: d.mon PS d.vect roads color=black width=4 d.vect roads color=white width=1 gv map.ps Is there a way to avoid this? Well, i guess this is not an easy task. 3.) I don't know how to tell the PS driver to use real colors, is there documentation available? eg.: g.manual -m psdriver 4.) I would love to see a doxygen documentation of the driver library, so i can understand how it works :) 5.) Is there a way to create eps output? This would be great, especially to use the created maps within other documents. (latex ...) IMHO the psdriver is absolutely fantastic. Thanks! Best regards Soeren Glynn Clements schrieb: > Jachym Cepicky wrote: > >> hi, >> tahanks for you answer >> >> 2007/4/6, Glynn Clements : >>> J-B?chym ?epick? wrote:-A >>> >>>> the PS driver works nice, thanks! >>>> >>>> What about d.text.freetype ? I wonder how complicated it would be to >>>> implement too..? >>> Huh? >>> >>> d.text.freetype should work with the PS driver, although it will >>> rasterise the bitmaps at a resolution of 1 point, then embed the >>> bitmaps. >> d.mon PS >> d.text.freetype font=luximr text="hallo, world" at=10,10 >> d.mon stop=PS >> >> gv map.ps >> >> document is not opend > > Oops. There are a couple of bugs in the bitmap code. > > The first is in the prolog; the string is allocated with one byte per > pixel, when it should be one bit, causing too much data to be read. > > Index: lib/psdriver/psdriver.ps > =================================================================== > RCS file: /grassrepository/grass6/lib/psdriver/psdriver.ps,v > retrieving revision 1.2 > diff -u -r1.2 psdriver.ps > --- lib/psdriver/psdriver.ps 30 Mar 2007 06:29:35 -0000 1.2 > +++ lib/psdriver/psdriver.ps 6 Apr 2007 13:48:00 -0000 > @@ -39,7 +39,7 @@ > /BITMAP { > gsave > 4 2 roll translate > - 1 index string /tmpstr exch def > + 1 index 7 add 8 idiv string /tmpstr exch def > true [1 0 0 1 0 0] {currentfile tmpstr readhexstring pop} imagemask > grestore > } bind def > > If you make this change to the map.ps file, the file should display, > but you'll notice the second bug; the accumulator wasn't being > cleared, resulting in "echoes": > > Index: lib/psdriver/Draw_bitmap.c > =================================================================== > RCS file: /grassrepository/grass6/lib/psdriver/Draw_bitmap.c,v > retrieving revision 1.1 > diff -u -r1.1 Draw_bitmap.c > --- lib/psdriver/Draw_bitmap.c 30 Mar 2007 04:51:23 -0000 1.1 > +++ lib/psdriver/Draw_bitmap.c 6 Apr 2007 13:48:00 -0000 > @@ -25,6 +25,7 @@ > { > output("%02X", acc); > bit = 0x80; > + acc = 0; > } > } > > Both of these are fixed in CVS, and it appears to work. > >> same for d.font && d.text >> >> What am I missing? > > That I said "should work" rather than "does work" ;) > > This time, I have actually tested it. > From woklist at kyngchaos.com Fri Apr 6 17:32:05 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Fri Apr 6 17:32:17 2007 Subject: [GRASS-dev] discussion: replacing ps.map In-Reply-To: <17942.22873.983794.982715@cerise.gclements.plus.com> References: <17930.59855.699533.647215@cerise.gclements.plus.com> <17932.16901.672831.128404@cerise.gclements.plus.com> <17936.45593.765285.836412@cerise.gclements.plus.com> <17936.59188.242469.82716@cerise.gclements.plus.com> <17939.31421.384601.500919@cerise.gclements.plus.com> <17942.11048.534533.376037@cerise.gclements.plus.com> <17942.22873.983794.982715@cerise.gclements.plus.com> Message-ID: <0A51C570-7C47-413C-BF47-C2CF52B6B35E@kyngchaos.com> On Apr 6, 2007, at 9:29 AM, Glynn Clements wrote: >> But instead I have an undefined symbol in the >> display library: >> >> ld: Undefined symbols: >> _PS_Driver referenced from libgrass expected to be defined in / >> Applications/GRASS-6.3.app/Contents/Resources/lib/ >> libgrass_psdriver.dylib > > It appears to be using the version in /Applications rather than the > local version. > In my haste to get off to work, I didn't notice that ^_^ > This suggests that the linker needs something similar to the > -Wl,-rpath-link switch which is used on Linux: > > CC_SEARCH_FLAGS='-Wl,-rpath-link,${LIB_RUNTIME_DIR}' > > This tells the linker where to look for dependencies. > > Without that, you will need to ensure that the lib directory of any > installed version of GRASS isn't searched automatically (e.g. due to > $DYLD_LIBRARY_PATH or similar). Hm, in the GRASS way of linking, all libs are linked in directly, whether they are indirect or not. Shouldn't the psdriver lib be linked to raster lib then? Currently grass.make has: RASTERLIB = -l$(RASTER_LIBNAME) $(PNGDRIVERLIB) $(DRIVERLIB) $ (GISLIB) If I add $(PSDRIVERLIB) to that, it doesn't try to link the installed libraries and everything builds successfully. ----- William Kyngesburye http://www.kyngchaos.com/ "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 jachym.cepicky at gmail.com Fri Apr 6 17:44:54 2007 From: jachym.cepicky at gmail.com (Jachym Cepicky) Date: Fri Apr 6 17:44:57 2007 Subject: [GRASS-dev] PNG driver - slow? In-Reply-To: <17942.25538.683141.353817@cerise.gclements.plus.com> References: <17939.64401.313718.203239@cerise.gclements.plus.com> <17942.25538.683141.353817@cerise.gclements.plus.com> Message-ID: Thanks, Glynn, I just used it in new GUI function - you select objects in attribute table and they are displayed with d.vect col=yellow width=3 in map display.. It works great, thanks again! jachym 2007/4/6, Glynn Clements : > > Glynn Clements wrote: > > > > export GRASS_PNGFILE=/tmp/pokus.png > > > export GRASS_RENDER_IMMEDIATE=TRUE > > > > > > time d.vect map=soils@PERMANENT > > > real 0m0.197s > > > user 0m0.166s > > > sys 0m0.019s > > > > > > time d.vect map=soils@PERMANENT color=yellow fcolor=yellow cats=32 width=3 > > > real 0m13.767s > > > user 0m13.611s > > > sys 0m0.098s > > > > > > > > > Why is the second case so slow? Is it a bug in PNG driver? What can I > > > do, so it is rendered faster? > > > > My guess is the width=3. > > > > The "thick line" code in the PNG driver is a truly awful hack (see > > store_xy() in lib/pngdriver/Draw_line.c). > > I've replaced this with a more reasonable implementation. > > However, note that the PNG driver doesn't have a proper polyline > implementation; it just draws each segment as a separate line. This is > fine for single-pixel lines, but for thicker lines the lack of proper > joins may be noticeable. > > -- > Glynn Clements > -- Jachym Cepicky e-mail: jachym.cepicky gmail com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub From cavallini at faunalia.it Fri Apr 6 17:46:27 2007 From: cavallini at faunalia.it (Paolo Cavallini) Date: Fri Apr 6 17:46:42 2007 Subject: [GRASS-dev] Proposal: release 6.2.2 In-Reply-To: <20070406150028.GF25552@bartok.itc.it> References: <20070406150028.GF25552@bartok.itc.it> Message-ID: <46166B53.7000505@faunalia.it> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 BTW: what is the roadmap for 6.3? pc Markus Neteler ha scritto: > Hi, > > I think that we have accumulated enough bugfixes to get > out 6.2.2 by next week. Since it is a bugfix release > only, I don't feel that we need a long testing phase. > > I suggest to get out a release candidate by next > week which can then be compiled and tested and > hopefully published asap. > > Markus - -- Paolo Cavallini http://www.faunalia.it/pc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGFmtS/NedwLUzIr4RAm07AJ9Wj47Qu/BYm8RAFQ8Lt9VJf4whKgCgoDn6 QI6QM7IULWVnNDd979b5B5k= =YZs8 -----END PGP SIGNATURE----- From jachym.cepicky at gmail.com Fri Apr 6 17:53:24 2007 From: jachym.cepicky at gmail.com (Jachym Cepicky) Date: Fri Apr 6 17:53:28 2007 Subject: [GRASS-dev] Proposal: release 6.2.2 In-Reply-To: <46166B53.7000505@faunalia.it> References: <20070406150028.GF25552@bartok.itc.it> <46166B53.7000505@faunalia.it> Message-ID: Hi, AFAIK, here is something: http://grass.gdf-hannover.de/wiki/GRASS_6.3_Feature_Plan jachym 2007/4/6, Paolo Cavallini : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > BTW: what is the roadmap for 6.3? > pc > > Markus Neteler ha scritto: > > Hi, > > > > I think that we have accumulated enough bugfixes to get > > out 6.2.2 by next week. Since it is a bugfix release > > only, I don't feel that we need a long testing phase. > > > > I suggest to get out a release candidate by next > > week which can then be compiled and tested and > > hopefully published asap. > > > > Markus > - -- > Paolo Cavallini > http://www.faunalia.it/pc > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFGFmtS/NedwLUzIr4RAm07AJ9Wj47Qu/BYm8RAFQ8Lt9VJf4whKgCgoDn6 > QI6QM7IULWVnNDd979b5B5k= > =YZs8 > -----END PGP SIGNATURE----- > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > -- Jachym Cepicky e-mail: jachym.cepicky gmail com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub From glynn at gclements.plus.com Fri Apr 6 17:58:24 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Apr 6 17:58:27 2007 Subject: [GRASS-dev] discussion: replacing ps.map In-Reply-To: <0A51C570-7C47-413C-BF47-C2CF52B6B35E@kyngchaos.com> References: <17930.59855.699533.647215@cerise.gclements.plus.com> <17932.16901.672831.128404@cerise.gclements.plus.com> <17936.45593.765285.836412@cerise.gclements.plus.com> <17936.59188.242469.82716@cerise.gclements.plus.com> <17939.31421.384601.500919@cerise.gclements.plus.com> <17942.11048.534533.376037@cerise.gclements.plus.com> <17942.22873.983794.982715@cerise.gclements.plus.com> <0A51C570-7C47-413C-BF47-C2CF52B6B35E@kyngchaos.com> Message-ID: <17942.28192.428130.823036@cerise.gclements.plus.com> William Kyngesburye wrote: > > This suggests that the linker needs something similar to the > > -Wl,-rpath-link switch which is used on Linux: > > > > CC_SEARCH_FLAGS='-Wl,-rpath-link,${LIB_RUNTIME_DIR}' > > > > This tells the linker where to look for dependencies. > > > > Without that, you will need to ensure that the lib directory of any > > installed version of GRASS isn't searched automatically (e.g. due to > > $DYLD_LIBRARY_PATH or similar). > > Hm, in the GRASS way of linking, all libs are linked in directly, > whether they are indirect or not. Shouldn't the psdriver lib be > linked to raster lib then? Currently grass.make has: > > RASTERLIB = -l$(RASTER_LIBNAME) $(PNGDRIVERLIB) $(DRIVERLIB) $(GISLIB) > > If I add $(PSDRIVERLIB) to that, it doesn't try to link the installed > libraries and everything builds successfully. Currently, we do that to allow for the --disable-shared case; it shouldn't actually be necessary for shared libraries. OTOH, RASTERLIB needs $(PSDRIVERLIB) to the same extent that it needs $(PNGDRIVERLIB), so it should be added so long as we're listing dependencies explicitly. Fixed in CVS. -- Glynn Clements From woklist at kyngchaos.com Fri Apr 6 18:14:06 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Fri Apr 6 18:14:13 2007 Subject: [GRASS-dev] discussion: replacing ps.map In-Reply-To: <17942.28192.428130.823036@cerise.gclements.plus.com> References: <17930.59855.699533.647215@cerise.gclements.plus.com> <17932.16901.672831.128404@cerise.gclements.plus.com> <17936.45593.765285.836412@cerise.gclements.plus.com> <17936.59188.242469.82716@cerise.gclements.plus.com> <17939.31421.384601.500919@cerise.gclements.plus.com> <17942.11048.534533.376037@cerise.gclements.plus.com> <17942.22873.983794.982715@cerise.gclements.plus.com> <0A51C570-7C47-413C-BF47-C2CF52B6B35E@kyngchaos.com> <17942.28192.428130.823036@cerise.gclements.plus.com> Message-ID: Thanks. GRASS build is happy again. On Apr 6, 2007, at 10:58 AM, Glynn Clements wrote: > William Kyngesburye wrote: > >> RASTERLIB = -l$(RASTER_LIBNAME) $(PNGDRIVERLIB) $(DRIVERLIB) $ >> (GISLIB) >> >> If I add $(PSDRIVERLIB) to that, it doesn't try to link the installed >> libraries and everything builds successfully. > > Currently, we do that to allow for the --disable-shared case; it > shouldn't actually be necessary for shared libraries. > I've wondered about that, so that's the reason for the explicit linking. > OTOH, RASTERLIB needs $(PSDRIVERLIB) to the same extent that it needs > $(PNGDRIVERLIB), so it should be added so long as we're listing > dependencies explicitly. > > Fixed in CVS. > > -- > Glynn Clements ----- William Kyngesburye http://www.kyngchaos.com/ "History is an illusion caused by the passage of time, and time is an illusion caused by the passage of history." - Hitchhiker's Guide to the Galaxy From glynn at gclements.plus.com Fri Apr 6 18:26:37 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Apr 6 18:26:44 2007 Subject: [GRASS-dev] discussion: replacing ps.map In-Reply-To: <461665E4.4050102@gmx.de> References: <17929.35602.196088.815592@cerise.gclements.plus.com> <20070327224018.3aec7e67@localhost.localdomain> <460A273A.1060109@club.worldonline.be> <20070328092330.GA928@polynum.com> <17930.59855.699533.647215@cerise.gclements.plus.com> <17932.40292.139762.620114@cerise.gclements.plus.com> <17942.11920.264665.707513@cerise.gclements.plus.com> <17942.20743.15986.354201@cerise.gclements.plus.com> <461665E4.4050102@gmx.de> Message-ID: <17942.29885.624221.963542@cerise.gclements.plus.com> S-B?ren Gebbert wrote:-A > thanks a lot for your effort. > The PS driver is working great for me > and i have a couple of questions about it: > > 1.) If i use d.erase to erase the monitor, an ERASE statement is added to map.ps. > Using the d.erase command after i have added raster or vector maps results in > rerendering the "erased" content. > Is there a way to reset the map.ps file to avoid rerendering of > "old" maps after using d.erase? Only ... > I need to stop the PS driver and restart it again to avoid rerendering. ... like this. The PS driver simply appends all output to $GRASS_PSFILE. It could truncate the file (although that will only work for files, not pipes or e.g. /dev/stdout) upon erase, or it could close and re-open the file. It's not entirely clear what the "correct" solution is. Is there a reason why you might want to send graphics to the driver when you are subsequently going to erase them? With the existing behaviour, the ERASE procedure can be redefined in the prolog ($GISBASE/etc/psdriver.ps) to do something else. E.g. it could call "showpage", so you could generate a multi-page file, using ERASE for page breaks. > 2.) The d.vect module works fine, the lines are really smooth if the line width is set to 1. > If i choose a larger line width, polylines are broken into pieces > spearfish60 example: > d.mon PS > d.vect roads color=black width=4 > d.vect roads color=white width=1 > gv map.ps > > Is there a way to avoid this? Well, i guess this is not an easy task. Modify d.vect to generate polylines (R_polyline_abs()) rather than individual line segments (R_{move,cont}_abs()). Unlike the PNG driver, the PS driver implements polylines as a single stroked path. If you send it a polyline, you'll get joins (rather than caps) between the segments. This is a good example of what I mean when I say that the main problem with implementing a PostScript driver is the way that modules use the graphics API. Note that being able to change the line width is a relatively recent feature (2005/08/09). Back when lines were always single-pixel, there wasn't any difference between a polyline and lots of individual segments. Also note that the PS driver cannot realistically convert move/cont operations into polylines, as a polyline has to be "stroke"d in a single operation. > 3.) I don't know how to tell the PS driver to use real colors, is there documentation available? > eg.: g.manual -m psdriver "real" colours? As opposed to imaginary colours? ;) If you're getting monochrome output, use: export GRASS_TRUECOLOR=TRUE to get colour PostScript. I made monochrome the default because that results in the most portable code (a minimal level 1 PostScript implementation doesn't support colour). > 4.) I would love to see a doxygen documentation of the driver library, > so i can understand how it works :) Regarding the graphics subsystem, documentation tends to become inaccurate faster than it gets written. > 5.) Is there a way to create eps output? This would be great, especially to use the created maps > within other documents. (latex ...) Try ps2epsi (normally included with Ghostscript). -- Glynn Clements From dylan.beaudette at gmail.com Fri Apr 6 18:54:33 2007 From: dylan.beaudette at gmail.com (Dylan Beaudette) Date: Fri Apr 6 18:54:44 2007 Subject: [GRASS-dev] discussion: replacing ps.map In-Reply-To: <17942.25051.314376.859730@cerise.gclements.plus.com> References: <17942.25051.314376.859730@cerise.gclements.plus.com> Message-ID: <200704060954.33294.dylan.beaudette@gmail.com> On Friday 06 April 2007 08:06, Glynn Clements wrote: > Jachym Cepicky wrote: > > btw: what do you think about replacement of ps.map with new PS driver > > && d.* commands? > > > > would it be easier to add line styles and area fillings to ps.map > > (where it partely is, at least the areas) or to d.rast/d.vect ? I > > think, it would be great to have only one set of tools for both - data > > displaying and hard copy maps preparation... I still like this approach, however a more seamless method like that used in R would be ideal: output is created based on the driver function which is called png(), x11(), pdf(), etc. Note that I am not in a position to implement this... :( > It would certainly be *easier* to change ps.map, as ps.map generates > PostScript directly. Would we then be limited to the functionality of ps.map? > d.* commands are limited to whatever the raster library provides. If > you want to add an additional operation to the graphics API, you > currently have to: > > 1. Add a R_* function to lib/raster/com_proto.c > 2. Add its prototype to include/raster.h > 3. Add a field to "struct transport" in lib/raster/transport.h > 4. Add an intitialiser for the field to "loc_trans" in lib/raster/com_io.c > 5. Add an intitialiser for the field to "rem_trans" in lib/raster/com_io.c > 6. Add a LOC_* version to lib/raster/loc_proto.c > 7. Add a REM_* version to lib/raster/rem_proto.c > 8. Add an opcode to include/graphics.h > 9. Add a "case" to lib/driver/command.c > 10. Add a COM_* version to lib/driver/.c > 11. Add its prototype to lib/driver/driver.h > 12. Add a field to "struct driver" in lib/driver/driver.h > 13. Add a PNG_* version to lib/pngdriver/.c > 14. Add the prototype to lib/pngdriver/pngdriver.h > 15. Add an intitialiser for the field in lib/pngdriver/Driver.c > 16. Add a PS_* version to lib/psdriver/.c > 17. Add the prototype to lib/psdriver/psdriver.h > 18. Add an intitialiser for the field in lib/psdriver/Driver.c > 19. Add a XD_* version to display/drivers/XDRIVER/.c > 20. Add the prototype to display/drivers/XDRIVER/XDRIVER.h > 21. Add an intitialiser for the field in display/drivers/XDRIVER/main.c > 22. Add a NULL intitialiser for the field in display/drivers/HTMLMAP/main.c > > If we can eliminate monitors in favour of direct rendering, we can > eliminate steps 3 through 12. The R_* function would become the COM_* > function, with no need to dispatch based upon local/remote transport. > > If we can eliminate XDRIVER in favour of a GUI which uses PPM/PNG > images, that loses 3 steps. If we can eliminate the PNG driver in > favour of "gs -sDEVICE=ppmraw", that loses another 3 (as well as > giving better quality). I think that striving for quality would be a good thing. I usually compose maps at 2x the resolution and then downscale with the current PNG driver. > Ultimately, if the PS driver was the only driver, we'd be down to just > steps 1 and 2. The R_* function would become the PS_* function; there > would be no need to dispatch based upon the current driver. If this were the only driver this might solve a couple of issues in a single step: high quality on screen output, AND high quality print output. The slowness of the PS driver might make working with data more cumbersome, however the current monitors are a bit slow anyways... > More significantly, additional cases wouldn't need necessarily need > new R_* functions; the module could just generate PostScript code > directly. This would be nice if we knew how long it would take to compose the image. Here are some more time comparisons for composition of separate RGB channels with d.rgb. region: rows: 1638 cols: 2160 Xmon real 0m1.439s user 0m1.288s sys 0m0.048s PNG real 0m1.419s user 0m1.288s sys 0m0.032s PS real 0m4.651s user 0m3.836s sys 0m0.132s I also noticed that the PS driver only supports grayscale, perhaps this was mentioned previously. Overall great work Gylnn - this thread has spawned some very interesting conversation and development! Cheers, -- Dylan Beaudette Soils and Biogeochemistry Graduate Group University of California at Davis 530.754.7341 From dylan.beaudette at gmail.com Fri Apr 6 19:02:59 2007 From: dylan.beaudette at gmail.com (Dylan Beaudette) Date: Fri Apr 6 19:03:08 2007 Subject: [GRASS-dev] discussion: replacing ps.map In-Reply-To: <17942.29885.624221.963542@cerise.gclements.plus.com> References: <461665E4.4050102@gmx.de> <17942.29885.624221.963542@cerise.gclements.plus.com> Message-ID: <200704061003.00080.dylan.beaudette@gmail.com> On Friday 06 April 2007 09:26, Glynn Clements wrote: > If you're getting monochrome output, use: > > ????????export GRASS_TRUECOLOR=TRUE > > to get colour PostScript. > > I made monochrome the default because that results in the most > portable code (a minimal level 1 PostScript implementation doesn't > support colour). Great! I just tried this with excellent results. Perhaps the longer rendering time for the PS driver is that it is rendering the raster data at the highest possible resolution. The output from a simple d.rast + d.vect is comparable to the quality of GMT-produced output. Cheers, -- Dylan Beaudette Soils and Biogeochemistry Graduate Group University of California at Davis 530.754.7341 From glynn at gclements.plus.com Fri Apr 6 19:59:51 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Apr 6 19:59:55 2007 Subject: [GRASS-dev] discussion: replacing ps.map In-Reply-To: <200704060954.33294.dylan.beaudette@gmail.com> References: <17942.25051.314376.859730@cerise.gclements.plus.com> <200704060954.33294.dylan.beaudette@gmail.com> Message-ID: <17942.35479.34267.238135@cerise.gclements.plus.com> Dylan Beaudette wrote: > > It would certainly be *easier* to change ps.map, as ps.map generates > > PostScript directly. > > Would we then be limited to the functionality of ps.map? Well, you would be limited to whatever functionality it currently possesses plus whatever functionality you are willing to add. Mostly, you're limited by the fact that it's a monolithic application, so adding new functionality means re-compiling it, whereas with separate d.* modules you can just add new ones. In practical terms, you're also limited by the existing structure. The main point is that ps.map commands simply store their data; PostScript generation only commences once the entire file has been read. > > d.* commands are limited to whatever the raster library provides. If > > you want to add an additional operation to the graphics API, you > > currently have to: > > > > 1. Add a R_* function to lib/raster/com_proto.c > > 2. Add its prototype to include/raster.h > > 3. Add a field to "struct transport" in lib/raster/transport.h > > 4. Add an intitialiser for the field to "loc_trans" in lib/raster/com_io.c > > 5. Add an intitialiser for the field to "rem_trans" in lib/raster/com_io.c > > 6. Add a LOC_* version to lib/raster/loc_proto.c > > 7. Add a REM_* version to lib/raster/rem_proto.c > > 8. Add an opcode to include/graphics.h > > 9. Add a "case" to lib/driver/command.c > > 10. Add a COM_* version to lib/driver/.c > > 11. Add its prototype to lib/driver/driver.h > > 12. Add a field to "struct driver" in lib/driver/driver.h > > 13. Add a PNG_* version to lib/pngdriver/.c > > 14. Add the prototype to lib/pngdriver/pngdriver.h > > 15. Add an intitialiser for the field in lib/pngdriver/Driver.c > > 16. Add a PS_* version to lib/psdriver/.c > > 17. Add the prototype to lib/psdriver/psdriver.h > > 18. Add an intitialiser for the field in lib/psdriver/Driver.c > > 19. Add a XD_* version to display/drivers/XDRIVER/.c > > 20. Add the prototype to display/drivers/XDRIVER/XDRIVER.h > > 21. Add an intitialiser for the field in display/drivers/XDRIVER/main.c > > 22. Add a NULL intitialiser for the field in display/drivers/HTMLMAP/main.c > > > > If we can eliminate monitors in favour of direct rendering, we can > > eliminate steps 3 through 12. The R_* function would become the COM_* > > function, with no need to dispatch based upon local/remote transport. > > > > If we can eliminate XDRIVER in favour of a GUI which uses PPM/PNG > > images, that loses 3 steps. If we can eliminate the PNG driver in > > favour of "gs -sDEVICE=ppmraw", that loses another 3 (as well as > > giving better quality). > > I think that striving for quality would be a good thing. I usually compose > maps at 2x the resolution and then downscale with the current PNG driver. Oversampling with the PNG driver is less than ideal, due to the fact that most modules which draw lines use single-pixel lines. This is also an issue for the PS driver; at 2400dpi, "single pixel" is a synonym for "invisible". If necessary, you can modify the WIDTH procedure in psdriver.ps to set a reasonable minimum value. Also, the line width will initially start at PostScript's default of 1 point (again, this is easy to change by editing the prolog). > > Ultimately, if the PS driver was the only driver, we'd be down to just > > steps 1 and 2. The R_* function would become the PS_* function; there > > would be no need to dispatch based upon the current driver. > > If this were the only driver this might solve a couple of issues in a single > step: high quality on screen output, AND high quality print output. The > slowness of the PS driver might make working with data more cumbersome, > however the current monitors are a bit slow anyways... The driver itself shouldn't be particularly slow, but actually rendering the PostScript might be. One issue is that the PS driver doesn't undersample the data based upon the output resolution, as it doesn't know the output resolution when it's generating the data. It wouldn't be hard to add an option to do this, although for rasters you can obtain the same effect by changing the region resolution. > > More significantly, additional cases wouldn't need necessarily need > > new R_* functions; the module could just generate PostScript code > > directly. > > This would be nice if we knew how long it would take to compose the image. > Here are some more time comparisons for composition of separate RGB channels > with d.rgb. > > region: > rows: 1638 > cols: 2160 > > Xmon > real 0m1.439s > user 0m1.288s > sys 0m0.048s > > PNG > real 0m1.419s > user 0m1.288s > sys 0m0.032s > > PS > real 0m4.651s > user 0m3.836s > sys 0m0.132s Timings for raster output (d.rast, d.rgb, d.his) are largely meaningless unless you know the region dimensions (rows x cols) relative to the screen size. The reason is that D_draw_raster() and D_draw_raster_RGB() return the next source row which will actually be displayed. If the region resolution is higher than the screen resolution (downsampling), d.rast etc will only read the rows which are actually going to be displayed. PostScript conceptually has infinite resolution, so d.rast etc can never skip rows when using the PostScript driver. As both the raster I/O and colour lookups can be quite expensive, this can make a significant difference. > I also noticed that the PS driver only supports grayscale, perhaps this was > mentioned previously. You have to explicitly set GRASS_TRUECOLOR=TRUE to get colour output. -- Glynn Clements From soerengebbert at gmx.de Fri Apr 6 20:53:02 2007 From: soerengebbert at gmx.de (=?ISO-8859-2?Q?S=F6ren_Gebbert?=) Date: Fri Apr 6 20:53:48 2007 Subject: [GRASS-dev] discussion: replacing ps.map In-Reply-To: <17942.29885.624221.963542@cerise.gclements.plus.com> References: <17929.35602.196088.815592@cerise.gclements.plus.com> <20070327224018.3aec7e67@localhost.localdomain> <460A273A.1060109@club.worldonline.be> <20070328092330.GA928@polynum.com> <17930.59855.699533.647215@cerise.gclements.plus.com> <17932.40292.139762.620114@cerise.gclements.plus.com> <17942.11920.264665.707513@cerise.gclements.plus.com> <17942.20743.15986.354201@cerise.gclements.plus.com> <461665E4.4050102@gmx.de> <17942.29885.624221.963542@cerise.gclements.plus.com> Message-ID: <4616970E.5040608@gmx.de> Glynn Clements schrieb: > S-B?ren Gebbert wrote:-A > >> thanks a lot for your effort. >> The PS driver is working great for me >> and i have a couple of questions about it: >> >> 1.) If i use d.erase to erase the monitor, an ERASE statement is added to map.ps. >> Using the d.erase command after i have added raster or vector maps results in >> rerendering the "erased" content. >> Is there a way to reset the map.ps file to avoid rerendering of >> "old" maps after using d.erase? > > Only ... > >> I need to stop the PS driver and restart it again to avoid rerendering. > > ... like this. > > The PS driver simply appends all output to $GRASS_PSFILE. > > It could truncate the file (although that will only work for files, > not pipes or e.g. /dev/stdout) upon erase, or it could close and > re-open the file. > > It's not entirely clear what the "correct" solution is. > > Is there a reason why you might want to send graphics to the driver > when you are subsequently going to erase them? Well, i was expecting a similar behaviour like the XDRIVER. Erasing the monitor to visualize new maps. In case of the PS driver i'm using kghostview or gv as monitor. > With the existing behaviour, the ERASE procedure can be redefined in > the prolog ($GISBASE/etc/psdriver.ps) to do something else. E.g. it > could call "showpage", so you could generate a multi-page file, using > ERASE for page breaks. That's interesting i will try this out. > >> 2.) The d.vect module works fine, the lines are really smooth if the line width is set to 1. >> If i choose a larger line width, polylines are broken into pieces >> spearfish60 example: >> d.mon PS >> d.vect roads color=black width=4 >> d.vect roads color=white width=1 >> gv map.ps >> >> Is there a way to avoid this? Well, i guess this is not an easy task. > > Modify d.vect to generate polylines (R_polyline_abs()) rather than > individual line segments (R_{move,cont}_abs()). Unlike the PNG driver, > the PS driver implements polylines as a single stroked path. If you > send it a polyline, you'll get joins (rather than caps) between the > segments. > > This is a good example of what I mean when I say that the main problem > with implementing a PostScript driver is the way that modules use the > graphics API. > > Note that being able to change the line width is a relatively recent > feature (2005/08/09). Back when lines were always single-pixel, there > wasn't any difference between a polyline and lots of individual > segments. > > Also note that the PS driver cannot realistically convert move/cont > operations into polylines, as a polyline has to be "stroke"d in a > single operation. > >> 3.) I don't know how to tell the PS driver to use real colors, is there documentation available? >> eg.: g.manual -m psdriver > > "real" colours? As opposed to imaginary colours? ;) > > If you're getting monochrome output, use: > > export GRASS_TRUECOLOR=TRUE > > to get colour PostScript. Its working great! > > I made monochrome the default because that results in the most > portable code (a minimal level 1 PostScript implementation doesn't > support colour). > >> 4.) I would love to see a doxygen documentation of the driver library, >> so i can understand how it works :) > > Regarding the graphics subsystem, documentation tends to become > inaccurate faster than it gets written. That hopefully does not mean that no documentation will be written at all. ;) > >> 5.) Is there a way to create eps output? This would be great, especially to use the created maps >> within other documents. (latex ...) > > Try ps2epsi (normally included with Ghostscript). > That's the tool i need, thanks. Soeren From glynn at gclements.plus.com Fri Apr 6 22:11:16 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Apr 6 22:11:19 2007 Subject: [GRASS-dev] discussion: replacing ps.map In-Reply-To: <4616970E.5040608@gmx.de> References: <17929.35602.196088.815592@cerise.gclements.plus.com> <20070327224018.3aec7e67@localhost.localdomain> <460A273A.1060109@club.worldonline.be> <20070328092330.GA928@polynum.com> <17930.59855.699533.647215@cerise.gclements.plus.com> <17932.40292.139762.620114@cerise.gclements.plus.com> <17942.11920.264665.707513@cerise.gclements.plus.com> <17942.20743.15986.354201@cerise.gclements.plus.com> <461665E4.4050102@gmx.de> <17942.29885.624221.963542@cerise.gclements.plus.com> <4616970E.5040608@gmx.de> Message-ID: <17942.43364.530363.219661@cerise.gclements.plus.com> S-B?ren Gebbert wrote:-A > >> 1.) If i use d.erase to erase the monitor, an ERASE statement is added to map.ps. > >> Using the d.erase command after i have added raster or vector maps results in > >> rerendering the "erased" content. > >> Is there a way to reset the map.ps file to avoid rerendering of > >> "old" maps after using d.erase? > > > > Only ... > > > >> I need to stop the PS driver and restart it again to avoid rerendering. > > > > ... like this. > > > > The PS driver simply appends all output to $GRASS_PSFILE. > > > > It could truncate the file (although that will only work for files, > > not pipes or e.g. /dev/stdout) upon erase, or it could close and > > re-open the file. > > > > It's not entirely clear what the "correct" solution is. > > > > Is there a reason why you might want to send graphics to the driver > > when you are subsequently going to erase them? > > Well, i was expecting a similar behaviour like the XDRIVER. > Erasing the monitor to visualize new maps. In case of the PS driver > i'm using kghostview or gv as monitor. If you want to use the PS driver interactively, then the existing behaviour is correct. E.g.: GRASS_PSFILE=/dev/stdout d.mon start=PS | gs -q -dNOPAUSE -dBATCH -sDEVICE=x11 - >&/dev/null & As the driver's output is going to a pipe, there's no way to "erase" any PostScript commands which have already been written. But sending "erasepage" (which is the default implementation of the ERASE procedure) will clear the display. -- Glynn Clements From soerengebbert at gmx.de Fri Apr 6 22:35:26 2007 From: soerengebbert at gmx.de (=?ISO-8859-15?Q?S=F6ren_Gebbert?=) Date: Fri Apr 6 22:36:11 2007 Subject: [GRASS-dev] gpde library updates Message-ID: <4616AF0E.2000603@gmx.de> Hi, i just committed some gpde library updates. Including: * different mean calculation algorithms (arithmetic, geometric, harmonic and quadratic mean) * upwidning stabilization * better solute transport implementation * fixed gradient field computation * documentation update * and much more I have moved the gpde global header files from grass6/include to grass6/lib/gpde. The header files are copied before compilation to $(GISBASE)/include/grass/. (Thanks for the explanation Glynn) All global definitions and typedefs are now available in the doxygen documentation. Best regards Soeren From soerengebbert at gmx.de Fri Apr 6 22:48:45 2007 From: soerengebbert at gmx.de (=?ISO-8859-15?Q?S=F6ren_Gebbert?=) Date: Fri Apr 6 22:49:28 2007 Subject: [GRASS-dev] r.univar, r3.univar and r3.stats Message-ID: <4616B22D.60305@gmx.de> Hi, i have replaced r.univar with a new version which is able to handle raster and volume maps. Now two modules are created: r.univar and r3.univar. The code for booth modules is located in raster/r.univar2. A separate manpage for each module exists. Also i would like to announce that i have committed a new statistic module called r3.stats to CVS some weeks ago. r3.stats calculates volume statistics based on raster3d maps. It is a new implementation and not related to r.stats (this will hopefully changed in the future). r3.stats can be used to compute: * the volume of geological layers * the volume of deposits (sand, ore, oil, water ...) * the volume of polluted groundwater or soils .... conclusion: Two new statistic modules are available for volume maps. Please test them and let me know if something is missing. Best regards Soeren From soerengebbert at gmx.de Sat Apr 7 01:34:18 2007 From: soerengebbert at gmx.de (=?ISO-8859-2?Q?S=F6ren_Gebbert?=) Date: Sat Apr 7 01:35:03 2007 Subject: [GRASS-dev] discussion: replacing ps.map In-Reply-To: <17942.29885.624221.963542@cerise.gclements.plus.com> References: <17929.35602.196088.815592@cerise.gclements.plus.com> <20070327224018.3aec7e67@localhost.localdomain> <460A273A.1060109@club.worldonline.be> <20070328092330.GA928@polynum.com> <17930.59855.699533.647215@cerise.gclements.plus.com> <17932.40292.139762.620114@cerise.gclements.plus.com> <17942.11920.264665.707513@cerise.gclements.plus.com> <17942.20743.15986.354201@cerise.gclements.plus.com> <461665E4.4050102@gmx.de> <17942.29885.624221.963542@cerise.gclements.plus.com> Message-ID: <4616D8FA.5030808@gmx.de> Hi, Glynn Clements schrieb: >> 2.) The d.vect module works fine, the lines are really smooth if the line width is set to 1. >> If i choose a larger line width, polylines are broken into pieces >> spearfish60 example: >> d.mon PS >> d.vect roads color=black width=4 >> d.vect roads color=white width=1 >> gv map.ps >> >> Is there a way to avoid this? Well, i guess this is not an easy task. > > Modify d.vect to generate polylines (R_polyline_abs()) rather than > individual line segments (R_{move,cont}_abs()). Unlike the PNG driver, > the PS driver implements polylines as a single stroked path. If you > send it a polyline, you'll get joins (rather than caps) between the > segments. > > This is a good example of what I mean when I say that the main problem > with implementing a PostScript driver is the way that modules use the > graphics API. > > Note that being able to change the line width is a relatively recent > feature (2005/08/09). Back when lines were always single-pixel, there > wasn't any difference between a polyline and lots of individual > segments. > > Also note that the PS driver cannot realistically convert move/cont > operations into polylines, as a polyline has to be "stroke"d in a > single operation. I have patched d.vect to use R_polyline_abs. Now lines of widths greater then 1 are are smoothed by the PS driver. I have tested the code with the XDRIVER, pngdriver and psdriver. The code seems to work, but i needed to add some memory allocation stuff, so the memory usage is a bit higher and it should be a bit slower than the G_plot_line approach (with move and cont functions). Everyone is welcome to test it. If no problems appear, i will submit these changes to CVS. Best regards Soeren The patch: cvs server: Diffing . Index: plot1.c =================================================================== RCS file: /home/grass/grassrepository/grass6/display/d.vect/plot1.c,v retrieving revision 1.26 diff -u -r1.26 plot1.c --- plot1.c 26 Feb 2007 10:50:37 -0000 1.26 +++ plot1.c 6 Apr 2007 23:29:24 -0000 @@ -191,6 +191,7 @@ } } + if ( !(type & ltype) ) continue; if ( chcat ) { @@ -452,14 +453,22 @@ R_RGB_color(color->r, color->g, color->b); } } + /* Plot the lines */ if ( Points->n_points == 1 ) { /* line with one coor */ G_plot_line(x[0], y[0], x[0], y[0]); } else { - for(i=1; i < Points->n_points; i++) { - G_plot_line(x[0], y[0], x[1], y[1]); - x++; - y++; + G_debug(3, "d.vect::plot1: plot polyline"); + /*Allocate memory for the window position arrays*/ + int *x_int = G_calloc(Points->n_points, sizeof(int)); + int *y_int = G_calloc(Points->n_points, sizeof(int)); + /*convert map coordinates into window x,y positions*/ + for(i=0; i < Points->n_points; i++) { + G_plot_where_xy(x[i], y[i], &x_int[i], &y_int[i]); } + /*Draw the polyline*/ + R_polyline_abs(x_int, y_int, Points->n_points); + G_free(x_int); + G_free(y_int); } } } From glynn at gclements.plus.com Sat Apr 7 08:47:35 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Apr 7 08:47:39 2007 Subject: [GRASS-dev] discussion: replacing ps.map In-Reply-To: <4616D8FA.5030808@gmx.de> References: <17929.35602.196088.815592@cerise.gclements.plus.com> <20070327224018.3aec7e67@localhost.localdomain> <460A273A.1060109@club.worldonline.be> <20070328092330.GA928@polynum.com> <17930.59855.699533.647215@cerise.gclements.plus.com> <17932.40292.139762.620114@cerise.gclements.plus.com> <17942.11920.264665.707513@cerise.gclements.plus.com> <17942.20743.15986.354201@cerise.gclements.plus.com> <461665E4.4050102@gmx.de> <17942.29885.624221.963542@cerise.gclements.plus.com> <4616D8FA.5030808@gmx.de> Message-ID: <17943.16007.570967.710046@cerise.gclements.plus.com> S-B?ren Gebbert wrote:-A > I have patched d.vect to use R_polyline_abs. Now lines of widths greater then 1 are > are smoothed by the PS driver. > > I have tested the code with the XDRIVER, pngdriver and psdriver. The code seems to work, > but i needed to add some memory allocation stuff, so the memory usage is a bit higher > and it should be a bit slower than the G_plot_line approach (with move and cont functions). > > Everyone is welcome to test it. If no problems appear, i will submit these changes to CVS. Unfortunately, there's a bit more to it than that. 1. G_plot_line handles longitude wrap-around (try plotting something which crosses the 180th meridian). 2. G_plot_line is using D_{move,cont}_abs(), which clip against the frame (try using a square region, so that there are blank bands on the left and right sides of the monitor). I already had to deal with something similar for filled polygons; see plot_polygon() at the top of plot1.c, and the render= option. FWIW, I've already added a D_polyline_clip() function, which should handle both of the above issues (although it hasn't been extensively tested). I would suggest adding a plot_polyline() function which uses either the render= setting or a separate option (e.g. lrender=). That allows people to compare the new implementation against the old one without having to keep an old version of d.vect around. -- Glynn Clements From grass-codei at wald.intevation.org Sat Apr 7 11:56:18 2007 From: grass-codei at wald.intevation.org (grass-codei@wald.intevation.org) Date: Sat Apr 7 11:56:22 2007 Subject: [GRASS-dev] [grass-code I][362] g.region option overwrite Message-ID: <20070407095618.973A41973F8B@pyrosoma.intevation.org> code I item #362, was opened at 07/04/2007 09:56 Status: Open Priority: 3 Submitted By: Aldo Clerici (clerici) Assigned to: Nobody (None) Summary: g.region option overwrite Issue type: module bad feature Issue status: None GRASS version: 6.2 GRASS component: general Operating system: Linux Operating system version: GRASS CVS checkout date, if applies (YYMMDD): 070407 Initial Comment: The option Overwrite in the g.region panel (Options) seems ineffective. The region name is overwritten anyway. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=362&group_id=21 From grass-codei at wald.intevation.org Sat Apr 7 12:10:20 2007 From: grass-codei at wald.intevation.org (grass-codei@wald.intevation.org) Date: Sat Apr 7 12:10:23 2007 Subject: [GRASS-dev] [grass-code I][363] Overwrite in r.patch Message-ID: <20070407101020.D6AFE1973F9B@pyrosoma.intevation.org> code I item #363, was opened at 07/04/2007 10:10 Status: Open Priority: 3 Submitted By: Aldo Clerici (clerici) Assigned to: Nobody (None) Summary: Overwrite in r.patch Issue type: module bad feature Issue status: None GRASS version: 6.2 GRASS component: raster Operating system: Linux Operating system version: GRASS CVS checkout date, if applies (YYMMDD): 070407 Initial Comment: The option Overwrite in the r.patch panel seems ineffective. The name of the resultant map is overwritten anyway ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=363&group_id=21 From glynn at gclements.plus.com Sat Apr 7 12:23:31 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Apr 7 12:23:40 2007 Subject: [GRASS-dev] discussion: replacing ps.map In-Reply-To: <17942.11920.264665.707513@cerise.gclements.plus.com> References: <17929.35602.196088.815592@cerise.gclements.plus.com> <20070327224018.3aec7e67@localhost.localdomain> <460A273A.1060109@club.worldonline.be> <20070328092330.GA928@polynum.com> <17930.59855.699533.647215@cerise.gclements.plus.com> <17932.40292.139762.620114@cerise.gclements.plus.com> <17942.11920.264665.707513@cerise.gclements.plus.com> Message-ID: <17943.28963.418899.895317@cerise.gclements.plus.com> Glynn Clements wrote: > Also, d.text.freetype and d.font.freetype are redundant. d.text, > d.text.new, and d.font all work with FreeType fonts (again, the actual > fonts will be rasterised). FWIW, I've extended d.text.new to support all of the options previously supported by d.text.freetype (added: font=, path=, charset= and -c), and replaced d.text.freetype with a script which simply calls d.text.new. Also, d.font.freetype uses R_font() instead of R_font_freetype(); the latter function (and its infrastructure) has now been removed. [Actually, I may as well add a -l switch to d.font and replace d.font.freetype with a script which calls d.font. I've only just noticed that d.font is already reading the freetypecap file to get the option list for the font= option.] -- Glynn Clements From soerengebbert at gmx.de Sat Apr 7 12:26:38 2007 From: soerengebbert at gmx.de (=?ISO-8859-2?Q?S=F6ren_Gebbert?=) Date: Sat Apr 7 12:27:23 2007 Subject: [GRASS-dev] discussion: replacing ps.map In-Reply-To: <17943.16007.570967.710046@cerise.gclements.plus.com> References: <17929.35602.196088.815592@cerise.gclements.plus.com> <20070327224018.3aec7e67@localhost.localdomain> <460A273A.1060109@club.worldonline.be> <20070328092330.GA928@polynum.com> <17930.59855.699533.647215@cerise.gclements.plus.com> <17932.40292.139762.620114@cerise.gclements.plus.com> <17942.11920.264665.707513@cerise.gclements.plus.com> <17942.20743.15986.354201@cerise.gclements.plus.com> <461665E4.4050102@gmx.de> <17942.29885.624221.963542@cerise.gclements.plus.com> <4616D8FA.5030808@gmx.de> <17943.16007.570967.710046@cerise.gclements.plus.com> Message-ID: <461771DE.9000409@gmx.de> Hi, Glynn Clements schrieb: > S-B?ren Gebbert wrote:-A > >> I have patched d.vect to use R_polyline_abs. Now lines of widths greater then 1 are >> are smoothed by the PS driver. >> >> I have tested the code with the XDRIVER, pngdriver and psdriver. The code seems to work, >> but i needed to add some memory allocation stuff, so the memory usage is a bit higher >> and it should be a bit slower than the G_plot_line approach (with move and cont functions). >> >> Everyone is welcome to test it. If no problems appear, i will submit these changes to CVS. > > Unfortunately, there's a bit more to it than that. > > 1. G_plot_line handles longitude wrap-around (try plotting something > which crosses the 180th meridian). > > 2. G_plot_line is using D_{move,cont}_abs(), which clip against the > frame (try using a square region, so that there are blank bands on the > left and right sides of the monitor). > > I already had to deal with something similar for filled polygons; see > plot_polygon() at the top of plot1.c, and the render= option. > > FWIW, I've already added a D_polyline_clip() function, which should > handle both of the above issues (although it hasn't been extensively > tested). > > I would suggest adding a plot_polyline() function which uses either > the render= setting or a separate option (e.g. lrender=). That allows > people to compare the new implementation against the old one without > having to keep an old version of d.vect around. > Done. The patch is attached. Soeren -------------- next part -------------- Index: area.c =================================================================== RCS file: /home/grass/grassrepository/grass6/display/d.vect/area.c,v retrieving revision 1.29 diff -u -r1.29 area.c --- area.c 15 Feb 2007 02:54:53 -0000 1.29 +++ area.c 7 Apr 2007 10:22:21 -0000 @@ -325,7 +325,7 @@ /* boundary */ if ( bcolor ) { - int i, j; + int i; Vect_get_area_points ( Map, area, Points ); if (rgb) { R_RGB_color ((unsigned char) red, (unsigned char) grn, (unsigned char) blu); @@ -333,15 +333,13 @@ else { R_RGB_color(bcolor->r, bcolor->g, bcolor->b); } - for ( i = 0; i < Points->n_points - 1; i++) { - G_plot_line (Points->x[i], Points->y[i], Points->x[i+1], Points->y[i+1]); - } + /*use different user defined render methods*/ + plot_polyline ( Points->x, Points->y, Points->n_points); for ( i = 0; i < n_isles; i++) { isle = Vect_get_area_isle ( Map, area, i ); Vect_get_isle_points ( Map, isle, Points ); - for ( j = 0; j < Points->n_points - 1; j++) { - G_plot_line (Points->x[j], Points->y[j], Points->x[j+1], Points->y[j+1]); - } + /*use different user defined render methods*/ + plot_polyline ( Points->x, Points->y, Points->n_points); } } } /* end for */ Index: local_proto.h =================================================================== RCS file: /home/grass/grassrepository/grass6/display/d.vect/local_proto.h,v retrieving revision 1.19 diff -u -r1.19 local_proto.h --- local_proto.h 15 Feb 2007 02:54:53 -0000 1.19 +++ local_proto.h 7 Apr 2007 10:22:21 -0000 @@ -11,5 +11,6 @@ int attr(struct Map_info *, int, char *, struct cat_list *, LATTR *, int); int zcoor(struct Map_info *, int, LATTR *); int test_bg_color (const char*); -void plot_polygon(double *, double *, int); +inline void plot_polygon(double *, double *, int); +inline void plot_polyline(double *, double *, int); Index: main.c =================================================================== RCS file: /home/grass/grassrepository/grass6/display/d.vect/main.c,v retrieving revision 1.86 diff -u -r1.86 main.c --- main.c 20 Feb 2007 13:15:42 -0000 1.86 +++ main.c 7 Apr 2007 10:22:22 -0000 @@ -85,7 +85,7 @@ int i, stat = 0, type, area, display; int chcat = 0; int r, g, b; - int has_color, has_fcolor; + int has_color = 0, has_fcolor = 0; struct color_rgb color, fcolor; int size; int default_width; @@ -305,7 +305,15 @@ render_opt->multiple = NO; render_opt->answer = "g" ; render_opt->options = "g,r,d,c"; - render_opt->description= _("Rendering method for filled polygons"); + render_opt->description= _("Rendering method for filled polygons and polylines" + "\n g - use the gislib render functions" + "\n features: clipping support" + "\n r - use the raster graphics library functions" + "\n features: smoothed polylines (PS driver)" + "\n d - use the display library render functions" + "\n features: smoothed polyline (PS driver)" + "\n c - use the display library render functions" + "\n features: clipping support"); /* please remove before GRASS 7 released */ verbose_flag = G_define_flag (); Index: plot1.c =================================================================== RCS file: /home/grass/grassrepository/grass6/display/d.vect/plot1.c,v retrieving revision 1.26 diff -u -r1.26 plot1.c --- plot1.c 26 Feb 2007 10:50:37 -0000 1.26 +++ plot1.c 7 Apr 2007 10:22:22 -0000 @@ -11,9 +11,19 @@ #include #include +#define RENDER_POLYLINE 0 +#define RENDER_POLYGON 1 + +/*local functions*/ +static inline void local_plot_poly(double *xf, double *yf, int n, int type); + +/*global render switch*/ int render; -static void local_plot_polygon(double *xf, double *yf, int n) +/* *************************************************************** */ +/* function to plot polygons and polylines ***************** */ +/* the parameter type switches render mode ***************** */ +static void local_plot_poly(double *xf, double *yf, int n, int type) { static int *xi, *yi; static int nalloc; @@ -32,9 +42,52 @@ yi[i] = (int) floor(0.5 + D_u_to_d_row(yf[i])); } - R_polygon_abs(xi, yi, n); + if(type == RENDER_POLYGON) + R_polygon_abs(xi, yi, n); + else + R_polyline_abs(xi, yi, n); +return; } +/* *************************************************************** */ +/* function to use different render methods for polylines ******** */ +/* *************************************************************** */ +void plot_polyline(double *xf, double *yf, int n) +{ + int i; + + switch (render) + { + case RENDER_GPP: + for(i=1; i < n; i++) { + G_plot_line(xf[0], yf[0], xf[1], yf[1]); + xf++; + yf++; + } + break; + case RENDER_DP: + D_polyline(xf, yf, n); + break; + case RENDER_DPC: + D_polyline_clip(xf, yf, n); + break; + case RENDER_RPA: + local_plot_poly(xf, yf, n, RENDER_POLYLINE); + break; + default: + for(i=1; i < n; i++) { + G_plot_line(xf[0], yf[0], xf[1], yf[1]); + xf++; + yf++; + } + break; + } +return; +} + +/* *************************************************************** */ +/* function to use different render methods for polygons ******** */ +/* *************************************************************** */ void plot_polygon(double *xf, double *yf, int n) { switch (render) @@ -49,14 +102,18 @@ D_polygon_clip(xf, yf, n); break; case RENDER_RPA: - local_plot_polygon(xf, yf, n); + local_plot_poly(xf, yf, n, RENDER_POLYGON); break; default: G_plot_polygon(xf, yf, n); break; } +return; } +/* *************************************************************** */ +/* *************************************************************** */ +/* *************************************************************** */ int plot1 ( struct Map_info *Map, int type, int area, struct cat_list *Clist, const struct color_rgb *color, const struct color_rgb *fcolor, @@ -191,6 +248,7 @@ } } + if ( !(type & ltype) ) continue; if ( chcat ) { @@ -452,14 +510,12 @@ R_RGB_color(color->r, color->g, color->b); } } + /* Plot the lines */ if ( Points->n_points == 1 ) { /* line with one coor */ - G_plot_line(x[0], y[0], x[0], y[0]); + D_polydots_clip(x, y, Points->n_points); } else { - for(i=1; i < Points->n_points; i++) { - G_plot_line(x[0], y[0], x[1], y[1]); - x++; - y++; - } + /*use different user defined render methods*/ + plot_polyline(x, y, Points->n_points); } } } From grass-codep at wald.intevation.org Sat Apr 7 13:09:08 2007 From: grass-codep at wald.intevation.org (grass-codep@wald.intevation.org) Date: Sat Apr 7 13:09:11 2007 Subject: [GRASS-dev] [grass-code P][364] Tiny patch for building Message-ID: <20070407110908.B10131973F9B@pyrosoma.intevation.org> code P item #364, was opened at 2007-04-07 13:09 Status: Open Priority: 3 Submitted By: Francesco Lovergine (frankie) Assigned to: Nobody (None) Summary: Tiny patch for building Patch status: None Patch type: fix GRASS component: build GRASS version: 6.2 GRASS CVS checkout date, if applies (YYMMDD): Initial Comment: While building for debian, programming manual is generated in a second phase. In the following case the 3 files are already present and read-only, so build fails. diff -urNad grass-6.2.2~20070406~/scripts/r.in.wms/Makefile grass-6.2.2~20070406/scripts/r.in.wms/Makefile --- grass-6.2.2~20070406~/scripts/r.in.wms/Makefile 2007-04-07 12:52:36.000000000 +0200 +++ grass-6.2.2~20070406/scripts/r.in.wms/Makefile 2007-04-07 12:54:38.000000000 +0200 @@ -6,4 +6,4 @@ default: script $(MKDIR) $(GISBASE)/etc/r.in.wms/ - cp r.in.gdalwarp wms.request wms.download $(GISBASE)/etc/r.in.wms/ + cp -f r.in.gdalwarp wms.request wms.download $(GISBASE)/etc/r.in.wms/ ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=205&aid=364&group_id=21 From glynn at gclements.plus.com Sat Apr 7 13:39:18 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Apr 7 13:39:22 2007 Subject: [GRASS-dev] discussion: replacing ps.map In-Reply-To: <17943.28963.418899.895317@cerise.gclements.plus.com> References: <17929.35602.196088.815592@cerise.gclements.plus.com> <20070327224018.3aec7e67@localhost.localdomain> <460A273A.1060109@club.worldonline.be> <20070328092330.GA928@polynum.com> <17930.59855.699533.647215@cerise.gclements.plus.com> <17932.40292.139762.620114@cerise.gclements.plus.com> <17942.11920.264665.707513@cerise.gclements.plus.com> <17943.28963.418899.895317@cerise.gclements.plus.com> Message-ID: <17943.33510.244266.240530@cerise.gclements.plus.com> Glynn Clements wrote: > [Actually, I may as well add a -l switch to d.font and replace > d.font.freetype with a script which calls d.font. I've only just > noticed that d.font is already reading the freetypecap file to get the > option list for the font= option.] Done. Both d.text.freetype and d.font.freetype are now essentially just aliases for d.text.new and d.font respectively. -- Glynn Clements From glynn at gclements.plus.com Sat Apr 7 13:43:26 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Apr 7 13:43:28 2007 Subject: [GRASS-dev] [grass-code P][364] Tiny patch for building In-Reply-To: <20070407110908.B10131973F9B@pyrosoma.intevation.org> References: <20070407110908.B10131973F9B@pyrosoma.intevation.org> Message-ID: <17943.33758.180260.596782@cerise.gclements.plus.com> grass-codep@wald.intevation.org wrote: > Initial Comment: > While building for debian, programming manual is generated in a second phase. > In the following case the 3 files are already present and read-only, so build fails. > > > > diff -urNad grass-6.2.2~20070406~/scripts/r.in.wms/Makefile grass-6.2.2~20070406/scripts/r.in.wms/Makefile > --- grass-6.2.2~20070406~/scripts/r.in.wms/Makefile 2007-04-07 12:52:36.000000000 +0200 > +++ grass-6.2.2~20070406/scripts/r.in.wms/Makefile 2007-04-07 12:54:38.000000000 +0200 > @@ -6,4 +6,4 @@ > > default: script > $(MKDIR) $(GISBASE)/etc/r.in.wms/ > - cp r.in.gdalwarp wms.request wms.download $(GISBASE)/etc/r.in.wms/ > + cp -f r.in.gdalwarp wms.request wms.download $(GISBASE)/etc/r.in.wms/ This should use $(INSTALL) instead of "cp", e.g. for file in r.in.gdalwarp wms.request wms.download ; do $(INSTALL) $$file ; done -- Glynn Clements From glynn at gclements.plus.com Sat Apr 7 14:05:25 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Apr 7 14:05:27 2007 Subject: [GRASS-dev] discussion: replacing ps.map In-Reply-To: <461771DE.9000409@gmx.de> References: <17929.35602.196088.815592@cerise.gclements.plus.com> <20070327224018.3aec7e67@localhost.localdomain> <460A273A.1060109@club.worldonline.be> <20070328092330.GA928@polynum.com> <17930.59855.699533.647215@cerise.gclements.plus.com> <17932.40292.139762.620114@cerise.gclements.plus.com> <17942.11920.264665.707513@cerise.gclements.plus.com> <17942.20743.15986.354201@cerise.gclements.plus.com> <461665E4.4050102@gmx.de> <17942.29885.624221.963542@cerise.gclements.plus.com> <4616D8FA.5030808@gmx.de> <17943.16007.570967.710046@cerise.gclements.plus.com> <461771DE.9000409@gmx.de> Message-ID: <17943.35077.104825.421335@cerise.gclements.plus.com> S-B?ren Gebbert wrote:-A > >> I have patched d.vect to use R_polyline_abs. Now lines of widths greater then 1 are > >> are smoothed by the PS driver. > >> > >> I have tested the code with the XDRIVER, pngdriver and psdriver. The code seems to work, > >> but i needed to add some memory allocation stuff, so the memory usage is a bit higher > >> and it should be a bit slower than the G_plot_line approach (with move and cont functions). > >> > >> Everyone is welcome to test it. If no problems appear, i will submit these changes to CVS. > > > > Unfortunately, there's a bit more to it than that. > > > > 1. G_plot_line handles longitude wrap-around (try plotting something > > which crosses the 180th meridian). > > > > 2. G_plot_line is using D_{move,cont}_abs(), which clip against the > > frame (try using a square region, so that there are blank bands on the > > left and right sides of the monitor). > > > > I already had to deal with something similar for filled polygons; see > > plot_polygon() at the top of plot1.c, and the render= option. > > > > FWIW, I've already added a D_polyline_clip() function, which should > > handle both of the above issues (although it hasn't been extensively > > tested). > > > > I would suggest adding a plot_polyline() function which uses either > > the render= setting or a separate option (e.g. lrender=). That allows > > people to compare the new implementation against the old one without > > having to keep an old version of d.vect around. > > > > Done. The patch is attached. I intend to apply this, subject to a few changes: plot_poly{gon,line} aren't declared "inline", as the "inline" keyword isn't ANSI C89 (C99 and GCC extension), and there isn't much benefit to inlining in this case. The option descriptions use the ->descriptions field; embedding formatting information in the ->description field is unsupported (e.g. it may not work with --tcltk, --html-description etc). The G_plot_line() loop uses array indexing rather than pointer arithmetic, as the former tends to be easier to read. -- Glynn Clements From soerengebbert at gmx.de Sat Apr 7 14:28:18 2007 From: soerengebbert at gmx.de (=?ISO-8859-2?Q?S=F6ren_Gebbert?=) Date: Sat Apr 7 14:29:03 2007 Subject: [GRASS-dev] discussion: replacing ps.map In-Reply-To: <17943.35077.104825.421335@cerise.gclements.plus.com> References: <17929.35602.196088.815592@cerise.gclements.plus.com> <20070327224018.3aec7e67@localhost.localdomain> <460A273A.1060109@club.worldonline.be> <20070328092330.GA928@polynum.com> <17930.59855.699533.647215@cerise.gclements.plus.com> <17932.40292.139762.620114@cerise.gclements.plus.com> <17942.11920.264665.707513@cerise.gclements.plus.com> <17942.20743.15986.354201@cerise.gclements.plus.com> <461665E4.4050102@gmx.de> <17942.29885.624221.963542@cerise.gclements.plus.com> <4616D8FA.5030808@gmx.de> <17943.16007.570967.710046@cerise.gclements.plus.com> <461771DE.9000409@gmx.de> <17943.35077.104825.421335@cerise.gclements.plus.com> Message-ID: <46178E62.8000302@gmx.de> Glynn Clements schrieb: > S?ren Gebbert wrote: > >>>> I have patched d.vect to use R_polyline_abs. Now lines of widths greater then 1 are >>>> are smoothed by the PS driver. >>>> >>>> I have tested the code with the XDRIVER, pngdriver and psdriver. The code seems to work, >>>> but i needed to add some memory allocation stuff, so the memory usage is a bit higher >>>> and it should be a bit slower than the G_plot_line approach (with move and cont functions). >>>> >>>> Everyone is welcome to test it. If no problems appear, i will submit these changes to CVS. >>> Unfortunately, there's a bit more to it than that. >>> >>> 1. G_plot_line handles longitude wrap-around (try plotting something >>> which crosses the 180th meridian). >>> >>> 2. G_plot_line is using D_{move,cont}_abs(), which clip against the >>> frame (try using a square region, so that there are blank bands on the >>> left and right sides of the monitor). >>> >>> I already had to deal with something similar for filled polygons; see >>> plot_polygon() at the top of plot1.c, and the render= option. >>> >>> FWIW, I've already added a D_polyline_clip() function, which should >>> handle both of the above issues (although it hasn't been extensively >>> tested). >>> >>> I would suggest adding a plot_polyline() function which uses either >>> the render= setting or a separate option (e.g. lrender=). That allows >>> people to compare the new implementation against the old one without >>> having to keep an old version of d.vect around. >>> >> Done. The patch is attached. > > I intend to apply this, subject to a few changes: > > plot_poly{gon,line} aren't declared "inline", as the "inline" keyword > isn't ANSI C89 (C99 and GCC extension), and there isn't much benefit > to inlining in this case. > > The option descriptions use the ->descriptions field; embedding > formatting information in the ->description field is unsupported (e.g. > it may not work with --tcltk, --html-description etc). > > The G_plot_line() loop uses array indexing rather than pointer > arithmetic, as the former tends to be easier to read. > I have modified the sources to fulfil hopefully your suggestions. Feel free to modify the patch in any way you think. New patch is attached. Best regards Soeren -------------- next part -------------- Index: area.c =================================================================== RCS file: /home/grass/grassrepository/grass6/display/d.vect/area.c,v retrieving revision 1.29 diff -u -r1.29 area.c --- area.c 15 Feb 2007 02:54:53 -0000 1.29 +++ area.c 7 Apr 2007 12:23:46 -0000 @@ -325,7 +325,7 @@ /* boundary */ if ( bcolor ) { - int i, j; + int i; Vect_get_area_points ( Map, area, Points ); if (rgb) { R_RGB_color ((unsigned char) red, (unsigned char) grn, (unsigned char) blu); @@ -333,15 +333,13 @@ else { R_RGB_color(bcolor->r, bcolor->g, bcolor->b); } - for ( i = 0; i < Points->n_points - 1; i++) { - G_plot_line (Points->x[i], Points->y[i], Points->x[i+1], Points->y[i+1]); - } + /*use different user defined render methods*/ + plot_polyline ( Points->x, Points->y, Points->n_points); for ( i = 0; i < n_isles; i++) { isle = Vect_get_area_isle ( Map, area, i ); Vect_get_isle_points ( Map, isle, Points ); - for ( j = 0; j < Points->n_points - 1; j++) { - G_plot_line (Points->x[j], Points->y[j], Points->x[j+1], Points->y[j+1]); - } + /*use different user defined render methods*/ + plot_polyline ( Points->x, Points->y, Points->n_points); } } } /* end for */ Index: local_proto.h =================================================================== RCS file: /home/grass/grassrepository/grass6/display/d.vect/local_proto.h,v retrieving revision 1.19 diff -u -r1.19 local_proto.h --- local_proto.h 15 Feb 2007 02:54:53 -0000 1.19 +++ local_proto.h 7 Apr 2007 12:23:46 -0000 @@ -12,4 +12,5 @@ int zcoor(struct Map_info *, int, LATTR *); int test_bg_color (const char*); void plot_polygon(double *, double *, int); +void plot_polyline(double *, double *, int); Index: main.c =================================================================== RCS file: /home/grass/grassrepository/grass6/display/d.vect/main.c,v retrieving revision 1.86 diff -u -r1.86 main.c --- main.c 20 Feb 2007 13:15:42 -0000 1.86 +++ main.c 7 Apr 2007 12:23:47 -0000 @@ -85,7 +85,7 @@ int i, stat = 0, type, area, display; int chcat = 0; int r, g, b; - int has_color, has_fcolor; + int has_color = 0, has_fcolor = 0; struct color_rgb color, fcolor; int size; int default_width; @@ -305,7 +305,7 @@ render_opt->multiple = NO; render_opt->answer = "g" ; render_opt->options = "g,r,d,c"; - render_opt->description= _("Rendering method for filled polygons"); + render_opt->description= _("Rendering method for filled polygons and polylines"); /* please remove before GRASS 7 released */ verbose_flag = G_define_flag (); Index: plot1.c =================================================================== RCS file: /home/grass/grassrepository/grass6/display/d.vect/plot1.c,v retrieving revision 1.26 diff -u -r1.26 plot1.c --- plot1.c 26 Feb 2007 10:50:37 -0000 1.26 +++ plot1.c 7 Apr 2007 12:23:48 -0000 @@ -11,9 +11,19 @@ #include #include +#define RENDER_POLYLINE 0 +#define RENDER_POLYGON 1 + +/*local functions*/ +static void local_plot_poly(double *xf, double *yf, int n, int type); + +/*global render switch*/ int render; -static void local_plot_polygon(double *xf, double *yf, int n) +/* *************************************************************** */ +/* function to plot polygons and polylines ***************** */ +/* the parameter type switches render mode ***************** */ +static void local_plot_poly(double *xf, double *yf, int n, int type) { static int *xi, *yi; static int nalloc; @@ -32,9 +42,46 @@ yi[i] = (int) floor(0.5 + D_u_to_d_row(yf[i])); } - R_polygon_abs(xi, yi, n); + if(type == RENDER_POLYGON) + R_polygon_abs(xi, yi, n); + else + R_polyline_abs(xi, yi, n); +return; } +/* *************************************************************** */ +/* function to use different render methods for polylines ******** */ +/* *************************************************************** */ +void plot_polyline(double *xf, double *yf, int n) +{ + int i; + + switch (render) + { + case RENDER_GPP: + for(i=1; i < n; i++) + G_plot_line(xf[i - 1], yf[i - 1], xf[i], yf[i]); + break; + case RENDER_DP: + D_polyline(xf, yf, n); + break; + case RENDER_DPC: + D_polyline_clip(xf, yf, n); + break; + case RENDER_RPA: + local_plot_poly(xf, yf, n, RENDER_POLYLINE); + break; + default: + for(i=1; i < n; i++) + G_plot_line(xf[i - 1], yf[i - 1], xf[i], yf[i]); + break; + } +return; +} + +/* *************************************************************** */ +/* function to use different render methods for polygons ******** */ +/* *************************************************************** */ void plot_polygon(double *xf, double *yf, int n) { switch (render) @@ -49,14 +96,18 @@ D_polygon_clip(xf, yf, n); break; case RENDER_RPA: - local_plot_polygon(xf, yf, n); + local_plot_poly(xf, yf, n, RENDER_POLYGON); break; default: G_plot_polygon(xf, yf, n); break; } +return; } +/* *************************************************************** */ +/* *************************************************************** */ +/* *************************************************************** */ int plot1 ( struct Map_info *Map, int type, int area, struct cat_list *Clist, const struct color_rgb *color, const struct color_rgb *fcolor, @@ -191,6 +242,7 @@ } } + if ( !(type & ltype) ) continue; if ( chcat ) { @@ -452,14 +504,12 @@ R_RGB_color(color->r, color->g, color->b); } } + /* Plot the lines */ if ( Points->n_points == 1 ) { /* line with one coor */ - G_plot_line(x[0], y[0], x[0], y[0]); + D_polydots_clip(x, y, Points->n_points); } else { - for(i=1; i < Points->n_points; i++) { - G_plot_line(x[0], y[0], x[1], y[1]); - x++; - y++; - } + /*use different user defined render methods*/ + plot_polyline(x, y, Points->n_points); } } } From neteler at itc.it Sat Apr 7 14:49:50 2007 From: neteler at itc.it (Markus Neteler) Date: Sat Apr 7 14:49:52 2007 Subject: [GRASS-dev] discussion: replacing ps.map In-Reply-To: <17943.33510.244266.240530@cerise.gclements.plus.com> References: <17929.35602.196088.815592@cerise.gclements.plus.com> <20070327224018.3aec7e67@localhost.localdomain> <460A273A.1060109@club.worldonline.be> <20070328092330.GA928@polynum.com> <17930.59855.699533.647215@cerise.gclements.plus.com> <17932.40292.139762.620114@cerise.gclements.plus.com> <17942.11920.264665.707513@cerise.gclements.plus.com> <17943.28963.418899.895317@cerise.gclements.plus.com> <17943.33510.244266.240530@cerise.gclements.plus.com> Message-ID: <20070407124950.GA22553@bartok.itc.it> On Sat, Apr 07, 2007 at 12:39:18PM +0100, Glynn Clements wrote: > > Glynn Clements wrote: > > > [Actually, I may as well add a -l switch to d.font and replace > > d.font.freetype with a script which calls d.font. I've only just > > noticed that d.font is already reading the freetypecap file to get the > > option list for the font= option.] > > Done. > > Both d.text.freetype and d.font.freetype are now essentially just > aliases for d.text.new and d.font respectively. Great, thanks - this is reducing the confusion. Question: Is there still a reason to keep d.text since d.text.new seems to provide the same (and more) parameters? Markus From neteler at itc.it Sat Apr 7 14:53:55 2007 From: neteler at itc.it (Markus Neteler) Date: Sat Apr 7 14:53:57 2007 Subject: [GRASS-dev] [grass-code P][364] Tiny patch for building In-Reply-To: <17943.33758.180260.596782@cerise.gclements.plus.com> References: <20070407110908.B10131973F9B@pyrosoma.intevation.org> <17943.33758.180260.596782@cerise.gclements.plus.com> Message-ID: <20070407125355.GB22553@bartok.itc.it> On Sat, Apr 07, 2007 at 12:43:26PM +0100, Glynn Clements wrote: > > grass-codep@wald.intevation.org wrote: > > > Initial Comment: > > While building for debian, programming manual is generated in a second phase. > > In the following case the 3 files are already present and read-only, so build fails. > > > > > > > > diff -urNad grass-6.2.2~20070406~/scripts/r.in.wms/Makefile grass-6.2.2~20070406/scripts/r.in.wms/Makefile > > --- grass-6.2.2~20070406~/scripts/r.in.wms/Makefile 2007-04-07 12:52:36.000000000 +0200 > > +++ grass-6.2.2~20070406/scripts/r.in.wms/Makefile 2007-04-07 12:54:38.000000000 +0200 > > @@ -6,4 +6,4 @@ > > > > default: script > > $(MKDIR) $(GISBASE)/etc/r.in.wms/ > > - cp r.in.gdalwarp wms.request wms.download $(GISBASE)/etc/r.in.wms/ > > + cp -f r.in.gdalwarp wms.request wms.download $(GISBASE)/etc/r.in.wms/ > > This should use $(INSTALL) instead of "cp", e.g. > > for file in r.in.gdalwarp wms.request wms.download ; do $(INSTALL) $$file ; done Submitted as for file in r.in.gdalwarp wms.request wms.download ; do $(INSTALL) -m 755 $$file $(GISBASE)/etc/r.in.wms/ ; done Markus From glynn at gclements.plus.com Sat Apr 7 15:07:12 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Apr 7 15:07:15 2007 Subject: [GRASS-dev] discussion: replacing ps.map In-Reply-To: <20070407124950.GA22553@bartok.itc.it> References: <17929.35602.196088.815592@cerise.gclements.plus.com> <20070327224018.3aec7e67@localhost.localdomain> <460A273A.1060109@club.worldonline.be> <20070328092330.GA928@polynum.com> <17930.59855.699533.647215@cerise.gclements.plus.com> <17932.40292.139762.620114@cerise.gclements.plus.com> <17942.11920.264665.707513@cerise.gclements.plus.com> <17943.28963.418899.895317@cerise.gclements.plus.com> <17943.33510.244266.240530@cerise.gclements.plus.com> <20070407124950.GA22553@bartok.itc.it> Message-ID: <17943.38784.175095.175966@cerise.gclements.plus.com> Markus Neteler wrote: > > > [Actually, I may as well add a -l switch to d.font and replace > > > d.font.freetype with a script which calls d.font. I've only just > > > noticed that d.font is already reading the freetypecap file to get the > > > option list for the font= option.] > > > > Done. > > > > Both d.text.freetype and d.font.freetype are now essentially just > > aliases for d.text.new and d.font respectively. > > Great, thanks - this is reducing the confusion. > > Question: Is there still a reason to keep d.text since d.text.new seems > to provide the same (and more) parameters? AFAICT, no. d.text.new appears to accept all of the options/flags which d.text accepts, so d.text should be able to be replaced in the same way as d.text.freetype. -- Glynn Clements From gnelson at uiuc.edu Sat Apr 7 15:13:39 2007 From: gnelson at uiuc.edu (Gerald Nelson) Date: Sat Apr 7 15:13:42 2007 Subject: [GRASS-dev] terracost and large files more generally Message-ID: <20070407081339.ANU03132@expms1.cites.uiuc.edu> While you (plural) are cranking on the next release, it's probably not the best time to ask but... - would it be possible to add the terracost functionality to r.cost (http://www.bowdoin.edu/~ltoma/research.html). My impression is that for a C programmer it would be fairly easy. - file size limitations issues. I'm bumping up against a 2 gb limit in r.out.arc. We're using grass6.3, compiled with large file support and we can't export files that would be larger than 2 gb. My postdoc (who knows java but not C) and I looked at the source code for r.out.arc and couldn't see any obvious reason why there would be a size limit. Thanks, Jerry Gerald Nelson Professor, Dept. of Agricultural and Consumer Economics University of Illinois, Urbana-Champaign office: 217-333-6465 cell: 217-390-7888 315 Mumford Hall 1301 W. Gregory Urbana, IL 61801 From neteler at itc.it Sat Apr 7 15:14:01 2007 From: neteler at itc.it (Markus Neteler) Date: Sat Apr 7 15:14:03 2007 Subject: [GRASS-dev] discussion: replacing ps.map In-Reply-To: <17943.38784.175095.175966@cerise.gclements.plus.com> References: <460A273A.1060109@club.worldonline.be> <20070328092330.GA928@polynum.com> <17930.59855.699533.647215@cerise.gclements.plus.com> <17932.40292.139762.620114@cerise.gclements.plus.com> <17942.11920.264665.707513@cerise.gclements.plus.com> <17943.28963.418899.895317@cerise.gclements.plus.com> <17943.33510.244266.240530@cerise.gclements.plus.com> <20070407124950.GA22553@bartok.itc.it> <17943.38784.175095.175966@cerise.gclements.plus.com> Message-ID: <20070407131401.GC22553@bartok.itc.it> On Sat, Apr 07, 2007 at 02:07:12PM +0100, Glynn Clements wrote: > > Markus Neteler wrote: > > > > > [Actually, I may as well add a -l switch to d.font and replace > > > > d.font.freetype with a script which calls d.font. I've only just > > > > noticed that d.font is already reading the freetypecap file to get the > > > > option list for the font= option.] > > > > > > Done. > > > > > > Both d.text.freetype and d.font.freetype are now essentially just > > > aliases for d.text.new and d.font respectively. > > > > Great, thanks - this is reducing the confusion. > > > > Question: Is there still a reason to keep d.text since d.text.new seems > > to provide the same (and more) parameters? > > AFAICT, no. d.text.new appears to accept all of the options/flags > which d.text accepts, so d.text should be able to be replaced in the > same way as d.text.freetype. Additionally the Makefile from d.text.new should be changed to generate d.text as name. Markus From neteler at itc.it Sat Apr 7 15:23:11 2007 From: neteler at itc.it (Markus Neteler) Date: Sat Apr 7 15:23:13 2007 Subject: [GRASS-dev] terracost and large files more generally In-Reply-To: <20070407081339.ANU03132@expms1.cites.uiuc.edu> References: <20070407081339.ANU03132@expms1.cites.uiuc.edu> Message-ID: <20070407132311.GD22553@bartok.itc.it> On Sat, Apr 07, 2007 at 08:13:39AM -0500, Gerald Nelson wrote: > While you (plural) are cranking on the next release, it's probably not the best time to ask but... > > - would it be possible to add the terracost functionality to r.cost (http://www.bowdoin.edu/~ltoma/research.html). My impression is that for a C programmer it would be fairly easy. > > - file size limitations issues. I'm bumping up against a 2 gb limit in r.out.arc. We're using grass6.3, compiled with large file support and we can't export files that would be larger than 2 gb. My postdoc (who knows java but not C) and I looked at the source code for r.out.arc and couldn't see any obvious reason why there would be a size limit. > It would be good to use this as motivation to better document the needed steps as already drafted here: http://grass.gdf-hannover.de/wiki/Large_File_Support Markus From glynn at gclements.plus.com Sat Apr 7 15:24:04 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Apr 7 15:24:09 2007 Subject: [GRASS-dev] discussion: replacing ps.map In-Reply-To: <17943.35077.104825.421335@cerise.gclements.plus.com> References: <17929.35602.196088.815592@cerise.gclements.plus.com> <20070327224018.3aec7e67@localhost.localdomain> <460A273A.1060109@club.worldonline.be> <20070328092330.GA928@polynum.com> <17930.59855.699533.647215@cerise.gclements.plus.com> <17932.40292.139762.620114@cerise.gclements.plus.com> <17942.11920.264665.707513@cerise.gclements.plus.com> <17942.20743.15986.354201@cerise.gclements.plus.com> <461665E4.4050102@gmx.de> <17942.29885.624221.963542@cerise.gclements.plus.com> <4616D8FA.5030808@gmx.de> <17943.16007.570967.710046@cerise.gclements.plus.com> <461771DE.9000409@gmx.de> <17943.35077.104825.421335@cerise.gclements.plus.com> Message-ID: <17943.39796.523007.907723@cerise.gclements.plus.com> Glynn Clements wrote: > > > I would suggest adding a plot_polyline() function which uses either > > > the render= setting or a separate option (e.g. lrender=). That allows > > > people to compare the new implementation against the old one without > > > having to keep an old version of d.vect around. > > > > > > > Done. The patch is attached. > > I intend to apply this, subject to a few changes: I have committed the changes. I have also added a D_polyline_cull() function, which discards lines which are entirely outside of the clip region, but uses D_polyline() for contiguous sections which are inside the region. If the drivers were changed to support a clip rectangle, this would be all that is required (you still want culling to avoid sending an entire map when most of it will be discarded by clipping). [Actually, the drivers do support a clip rectangle, but it's only used for text.] I haven't changed the clipping code to use polylines. It's actually quite non-trivial, as it needs to construct new polylines containing the endpoints which are generated by clipping. OTOH, culling doesn't create new points, so it can just pass portions of the coordinate arrays to the existing polyline functions. I'm wondering whether it's worth the effort given that it's likely to be discarded relatively soon. Clipping during rasterisation is likely to be more efficient than geometric clipping. BTW, this issue isn't limited to the PS driver (although it's likely to be more noticeable there). XDRIVER also uses line joins with thick polylines. Also, this episode has highlighted another issue for the future: the move and cont functions should be augmented with an "end" function, to allow polylines to be constructed incrementally. There are cases where having to collate the coordinates into an array is an (unnecessary) inconvenience. Without an end function, cont operations have to be rendered immediately, which rules out handling a sequence of move/cont operations as a single stroked path. There should also be a way to generate closed loops (i.e. PostScript's "closepath" operator). Simply making the last point the same as the first point doesn't work in PostScript; you still get a pair of caps rather than a join. The idiom of bracketing primitives with begin/end (used by e.g. OpenGL) is probably the best approach. If you don't need a begin or end for a particular primitive, you can make it a no-op, but it's a good idea to make the application provide it just in case. -- Glynn Clements From glynn at gclements.plus.com Sat Apr 7 15:27:56 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Apr 7 15:27:58 2007 Subject: [GRASS-dev] [grass-code P][364] Tiny patch for building In-Reply-To: <20070407125355.GB22553@bartok.itc.it> References: <20070407110908.B10131973F9B@pyrosoma.intevation.org> <17943.33758.180260.596782@cerise.gclements.plus.com> <20070407125355.GB22553@bartok.itc.it> Message-ID: <17943.40028.330396.946195@cerise.gclements.plus.com> Markus Neteler wrote: > > > Initial Comment: > > > While building for debian, programming manual is generated in a second phase. > > > In the following case the 3 files are already present and read-only, so build fails. > > > > > > > > > > > > diff -urNad grass-6.2.2~20070406~/scripts/r.in.wms/Makefile grass-6.2.2~20070406/scripts/r.in.wms/Makefile > > > --- grass-6.2.2~20070406~/scripts/r.in.wms/Makefile 2007-04-07 12:52:36.000000000 +0200 > > > +++ grass-6.2.2~20070406/scripts/r.in.wms/Makefile 2007-04-07 12:54:38.000000000 +0200 > > > @@ -6,4 +6,4 @@ > > > > > > default: script > > > $(MKDIR) $(GISBASE)/etc/r.in.wms/ > > > - cp r.in.gdalwarp wms.request wms.download $(GISBASE)/etc/r.in.wms/ > > > + cp -f r.in.gdalwarp wms.request wms.download $(GISBASE)/etc/r.in.wms/ > > > > This should use $(INSTALL) instead of "cp", e.g. > > > > for file in r.in.gdalwarp wms.request wms.download ; do $(INSTALL) $$file ; done > > Submitted as > > for file in r.in.gdalwarp wms.request wms.download ; do $(INSTALL) -m 755 $$file $(GISBASE)/etc/r.in.wms/ ; done FWIW, you don't need the "-m 755"; that's the default. Use $(INSTALL_DATA) for files which shouldn't be made executable. -- Glynn Clements From tutey at o2.pl Sat Apr 7 16:57:28 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Sat Apr 7 16:57:34 2007 Subject: [GRASS-dev] enable forwarding all GRASS GForge traffic to grass-dev ML? In-Reply-To: <4612120A.8040009@itc.it> References: <4611761A.70609@o2.pl> <20070403125345.14b0ede6.hamish_nospam@yahoo.com> <4612120A.8040009@itc.it> Message-ID: <4617B158.20405@o2.pl> Markus Neteler wrote: > Hamish wrote on 04/03/2007 02:53 AM: >> Also how to enable reply-to-bug from grass-dev? > The current > cc: noreply@wald.intevation.org > is rather useless. I digged deeper, as something was telling me that the reply via email used to be available in GForge. And indeed it was, only it was not working; there's a bug report on it: http://wald.intevation.org/tracker/index.php?func=detail&aid=85&group_id=1&atid=162 Maciek From glynn at gclements.plus.com Sat Apr 7 16:57:58 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Apr 7 16:58:00 2007 Subject: [GRASS-dev] terracost and large files more generally In-Reply-To: <20070407081339.ANU03132@expms1.cites.uiuc.edu> References: <20070407081339.ANU03132@expms1.cites.uiuc.edu> Message-ID: <17943.45430.574853.795059@cerise.gclements.plus.com> Gerald Nelson wrote: > - file size limitations issues. I'm bumping up against a 2 gb limit in > r.out.arc. We're using grass6.3, compiled with large file support and > we can't export files that would be larger than 2 gb. My postdoc (who > knows java but not C) and I looked at the source code for r.out.arc > and couldn't see any obvious reason why there would be a size limit. The --enable-largefile configure option only enables LFS on code which specifically chooses to use it. As r.out.arc only performs sequential output, it's safe to enable LFS, so I've modified the Makefile to enable it. -- Glynn Clements From glynn at gclements.plus.com Sat Apr 7 17:02:29 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Apr 7 17:02:31 2007 Subject: [GRASS-dev] discussion: replacing ps.map In-Reply-To: <20070407131401.GC22553@bartok.itc.it> References: <460A273A.1060109@club.worldonline.be> <20070328092330.GA928@polynum.com> <17930.59855.699533.647215@cerise.gclements.plus.com> <17932.40292.139762.620114@cerise.gclements.plus.com> <17942.11920.264665.707513@cerise.gclements.plus.com> <17943.28963.418899.895317@cerise.gclements.plus.com> <17943.33510.244266.240530@cerise.gclements.plus.com> <20070407124950.GA22553@bartok.itc.it> <17943.38784.175095.175966@cerise.gclements.plus.com> <20070407131401.GC22553@bartok.itc.it> Message-ID: <17943.45701.384662.992463@cerise.gclements.plus.com> Markus Neteler wrote: > > > > > [Actually, I may as well add a -l switch to d.font and replace > > > > > d.font.freetype with a script which calls d.font. I've only just > > > > > noticed that d.font is already reading the freetypecap file to get the > > > > > option list for the font= option.] > > > > > > > > Done. > > > > > > > > Both d.text.freetype and d.font.freetype are now essentially just > > > > aliases for d.text.new and d.font respectively. > > > > > > Great, thanks - this is reducing the confusion. > > > > > > Question: Is there still a reason to keep d.text since d.text.new seems > > > to provide the same (and more) parameters? > > > > AFAICT, no. d.text.new appears to accept all of the options/flags > > which d.text accepts, so d.text should be able to be replaced in the > > same way as d.text.freetype. > > Additionally the Makefile from d.text.new should be changed to > generate d.text as name. Done. -- Glynn Clements From neteler at itc.it Sat Apr 7 18:59:56 2007 From: neteler at itc.it (Markus Neteler) Date: Sat Apr 7 18:59:58 2007 Subject: [GRASS-dev] v.db.renamecol written Message-ID: <20070407165956.GF22553@bartok.itc.it> Since renaming is a relative pain in DBF and SQLite, I have written a new script v.db.renamecol. To use it be sure to update db.describe, too, from CVS. Usage example Spearfish: g.copy vect=roads,myroads v.info -c myroads INTEGER|cat CHARACTER|label v.db.renamecol myroads col=label,roadtype v.info -c myroads INTEGER|cat CHARACTER|roadtype Tested with PostgreSQL, too. Cheers Markus PS: I didn't test with MySQL - please let me know if it should fail there. From grass-doci at wald.intevation.org Sat Apr 7 19:28:56 2007 From: grass-doci at wald.intevation.org (grass-doci@wald.intevation.org) Date: Sat Apr 7 19:28:59 2007 Subject: [GRASS-dev] [grass-doc I][365] Missing target in rfc Message-ID: <20070407172856.106DF1973F9B@pyrosoma.intevation.org> doc I item #365, was opened at 2007-04-07 19:28 Status: Open Priority: 3 Submitted By: Francesco Lovergine (frankie) Assigned to: Nobody (None) Summary: Missing target in rfc Issue status: None Doc section: all GRASS version: 6.2 Doc timestamp (YYMMDD): Initial Comment: make htmldocs fails in the rfc dir due to missing target: [...] Generating docs for compound _dglHeap... Generating docs for compound _dglHeapData... Generating docs for compound _dglHeapNode... Generating docs for compound _dglSpanClipInput... Generating docs for compound _dglSpanClipOutput... Generating docs for compound _dglSPArc... Generating docs for compound _dglSPClipInput... Generating docs for compound _dglSPClipOutput... Generating docs for compound _dglSPReport... Generating docs for compound _dglTreeEdge... Generating docs for compound _dglTreeEdgePri32... Generating docs for compound _dglTreeNode... Generating docs for compound _dglTreeNode2... Generating docs for compound _dglTreeNodePri32... Generating docs for compound _dglTreePredist... Generating docs for compound _dglTreeTouchI32... Generating docs for compound avl_node... Generating docs for compound avl_table... Generating docs for compound avl_traverser... Generating docs for compound ClipperContext_s... Generating docs for compound dglEdgePrioritizer_s... Generating docs for compound dglEdgesetTraverser_s... Generating docs for compound dglEdgeTraverser_s... Generating docs for compound dglIOContext_s... Generating docs for compound dglNodePrioritizer_s... Generating docs for compound dglNodeTraverser_s... Generating docs for compound dglSPCache_s... Generating docs for compound GnoOption... Generating docs for compound libavl_allocator... Generating docs for compound tavl_node... Generating docs for compound tavl_table... Generating docs for compound tavl_traverser... Generating graphical class hierarchy... Generating namespace index... Generating namespace member index... Generating graph info page... Generating directory documentation... Generating dependency graph for directory examples/ Generating file index... Generating directory index... Generating example index... Generating file member index... Generating page index... HTML reference in directory ./html/index.html make[2]: Leaving directory `/users/frankie/debian/debian-gis/grass/grass-6.2.2~20070406/lib/vector/dglib' (cd rfc/ ; /usr/bin/make cleandocs ; /usr/bin/make htmldocs) make[2]: Entering directory `/users/frankie/debian/debian-gis/grass/grass-6.2.2~20070406/rfc' rm -fr latex/ html/ make[2]: Leaving directory `/users/frankie/debian/debian-gis/grass/grass-6.2.2~20070406/rfc' make[2]: Entering directory `/users/frankie/debian/debian-gis/grass/grass-6.2.2~20070406/rfc' make[2]: *** No rule to make target `htmldocs'. Stop. make[2]: Leaving directory `/users/frankie/debian/debian-gis/grass/grass-6.2.2~20070406/rfc' make[1]: *** [htmldocs] Error 2 make[1]: Leaving directory `/users/frankie/debian/debian-gis/grass/grass-6.2.2~20070406' ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=207&aid=365&group_id=21 From woklist at kyngchaos.com Sat Apr 7 21:15:02 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Sat Apr 7 21:15:16 2007 Subject: [GRASS-dev] OSX - new bundle option in bindist Message-ID: <815E10BC-0239-4302-9F82-E8FCD6330EC8@kyngchaos.com> Another refinement of the OSX app build: For the bindist, it's now possible to specify additional files to bundle in the application package. This makes it easier to create an installer without worrying about oddball binaries that also must be installed. Suggested binaries to bundle include: - libpq (the postgres library, so a full postgres install isn't required, though that would still be needed for local postgres DB use) - gpsbabel - netpbm tools (the ones needed by some script commands) - ffmpeg libraries - other libraries and programs not readily available as binaries (no point in bundling my frameworks ^_^ ) I did it as an included .make file, which is customized as required (I tried to make it as simple as I could). See the macosx/ReadMe.rtf for details. ----- William Kyngesburye http://www.kyngchaos.com/ First Pogril: Why is life like sticking your head in a bucket filled with hyena offal? Second Pogril: I don't know. Why IS life like sticking your head in a bucket filled with hyena offal? First Pogril: I don't know either. Wretched, isn't it? -HitchHiker's Guide to the Galaxy From tutey at o2.pl Sun Apr 8 10:43:01 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Sun Apr 8 10:43:04 2007 Subject: [GRASS-dev] d.vect render= and corrupted vector display Message-ID: <4618AB15.3090002@o2.pl> Hi I have tried different render methods with a vector box which fits the region perfectly. For each render method the vector box is displayed wrong on the X mointor. Details: in spearfish: $ g.region rast=elevation.10m -a $ v.in.region output=frame type=line $ d.mon x0 #1 $ d.vect frame rander=g (right egde of the vector box invisible) #2 $ d.erase; d.vect frame render=r (right egde of the vector box invisible) #3 $ d.erase; d.vect frame render=d (right egde of the vector box invisible) #4 $ d.erase; d.vect frame render=c (nothing is visible) #5 $ d.erase; d.vect frame render=c (nothing is visible) Then I repeated tests with width=2 and greater. For cases 1-3 the right edge became visible, but the right and left edges were thinner than top and bottom. For case 4, no matter what width nothing is visible. For case 5, width > 1 makes the right edge visible, but the other 3 are never displayed. Maciek From tutey at o2.pl Sun Apr 8 11:50:54 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Sun Apr 8 11:50:57 2007 Subject: [GRASS-dev] d.vect render= and corrupted vector display In-Reply-To: <4618AB15.3090002@o2.pl> References: <4618AB15.3090002@o2.pl> Message-ID: <4618BAFE.2020501@o2.pl> Maciej Sieczka wrote: > #5 > $ d.erase; d.vect frame render=c Typo. Should read: render=l. > (nothing is visible) Maciek From glynn at gclements.plus.com Sun Apr 8 15:57:23 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Apr 8 15:57:25 2007 Subject: [GRASS-dev] d.vect render= and corrupted vector display In-Reply-To: <4618AB15.3090002@o2.pl> References: <4618AB15.3090002@o2.pl> Message-ID: <17944.62659.369399.495267@cerise.gclements.plus.com> Maciej Sieczka wrote: > I have tried different render methods with a vector box which fits the > region perfectly. For each render method the vector box is displayed > wrong on the X mointor. Details: > > in spearfish: > > $ g.region rast=elevation.10m -a > $ v.in.region output=frame type=line > $ d.mon x0 > > #1 > $ d.vect frame rander=g > (right egde of the vector box invisible) > > #2 > $ d.erase; d.vect frame render=r > (right egde of the vector box invisible) > > #3 > $ d.erase; d.vect frame render=d > (right egde of the vector box invisible) > > #4 > $ d.erase; d.vect frame render=c > (nothing is visible) > > #5 > $ d.erase; d.vect frame render=c > (nothing is visible) > > Then I repeated tests with width=2 and greater. > > For cases 1-3 the right edge became visible, but the right and left > edges were thinner than top and bottom. > > For case 4, no matter what width nothing is visible. > > For case 5, width > 1 makes the right edge visible, but the other 3 are > never displayed. I've changed the clipping/culling code to handle this particular case (i.e. use <= 0 rather than < 0), so #4 and #5 now match the other three. Beyond that, the main issue is that the code which sets up the coordinate mapping (D_setup/D_do_conversions) maps the current region to the current frame *exactly*, without any margin. This is arguably the right thing, even if the net result isn't always ideal (and the result of v.in.region is the worst possible case). This doesn't allow for thick lines, where the path itself (i.e. the centre-line) might lie just outside the region but the "stroke" can still be visible. It also doesn't allow for the fact that the tiniest rounding error might push the path outside. Note that the clipping/culling code doesn't make any allowance for the line width. It can't; it doesn't know the line width (R_line_width() does directly to the driver; the display library doesn't get to see it). I should probably add an option to set a "margin", i.e. the difference between the clip window used for the actual rendering and the clip window used for geometric clipping and culling. There's also the issue that the actual line may vary by +/- half a pixel from the "correct" position. That's an inevitable fact of rasterisation; the driver can't fill half of a pixel. If the path lies exactly along an edge of the "screen" (window/image), the line will end up either just on-screen or just off-screen. FWIW, if you try this with the PS driver and width=1 (which translates to one point, not one device pixel), and render the PostScript at a high resolution, you'll note that it really does draw half of each of the two vertical lines (adding "[10] 0 setdash 1 setlinecap" makes it more clear). -- Glynn Clements From tutey at o2.pl Sun Apr 8 17:29:45 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Sun Apr 8 17:29:49 2007 Subject: [GRASS-dev] d.vect render= and corrupted vector display In-Reply-To: <17944.62659.369399.495267@cerise.gclements.plus.com> References: <4618AB15.3090002@o2.pl> <17944.62659.369399.495267@cerise.gclements.plus.com> Message-ID: <46190A69.8030802@o2.pl> Glynn Thank you for looking into this. Please read below. Glynn Clements wrote: > I've changed the clipping/culling code to handle this particular case > (i.e. use <= 0 rather than < 0), so #4 and #5 now match the other > three. > Beyond that, the main issue is that the code which sets up the > coordinate mapping (D_setup/D_do_conversions) maps the current region > to the current frame *exactly*, without any margin. This is arguably > the right thing, even if the net result isn't always ideal (and the > result of v.in.region is the worst possible case). Don't you think it is confussing for the user? If I do v.in.region, I'm right to expect that the whole vector will be displayed when my working region matches the v.in.region's output extent. And if this doesn't happen (as it is currently), I start wondering whether there could be a bug in v.in.region, or g.region, or d.vect an so on. Waste of time, less trust in GRASS, bogus bug reports etc. If it is possible to fix that without too much effort, I would be for it. > This doesn't allow for thick lines, where the path itself (i.e. the > centre-line) might lie just outside the region but the "stroke" can > still be visible. It also doesn't allow for the fact that the tiniest > rounding error might push the path outside. > > Note that the clipping/culling code doesn't make any allowance for the > line width. It can't; it doesn't know the line width (R_line_width() > does directly to the driver; the display library doesn't get to see > it). Propably I did not understand something, but as I can see render=c/l work well together with width= in d.vect. Did you mean something else? Maciek P.S. If this is usefull, Hamish made some guess about a possible nature of the problem about a year ago; please read on http://intevation.de/rt/webrt?serial_num=3613, message dated: Thu, Sep 8 2005 02:48:20. From glynn at gclements.plus.com Sun Apr 8 18:56:14 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Apr 8 18:56:16 2007 Subject: [GRASS-dev] d.vect render= and corrupted vector display In-Reply-To: <46190A69.8030802@o2.pl> References: <4618AB15.3090002@o2.pl> <17944.62659.369399.495267@cerise.gclements.plus.com> <46190A69.8030802@o2.pl> Message-ID: <17945.7854.435733.691855@cerise.gclements.plus.com> Maciej Sieczka wrote: > > I've changed the clipping/culling code to handle this particular case > > (i.e. use <= 0 rather than < 0), so #4 and #5 now match the other > > three. > > > Beyond that, the main issue is that the code which sets up the > > coordinate mapping (D_setup/D_do_conversions) maps the current region > > to the current frame *exactly*, without any margin. This is arguably > > the right thing, even if the net result isn't always ideal (and the > > result of v.in.region is the worst possible case). > > Don't you think it is confussing for the user? If I do v.in.region, I'm > right to expect that the whole vector will be displayed when my working > region matches the v.in.region's output extent. Hmm; not really. v.in.region generates a vector map corresponding to the region's boundary. d.vect displays the portion of a vector map which lies inside the region. Is a region's boundary *inside* the region? If you treat the boundary as an area, then the area which d.vect will fill is exactly the region, i.e. inside the boundary == inside the region. But is the boundary itself inside the region? I'm aware that this may be counter-intuitive, but that isn't the same thing as being wrong. The problem is that I don't see how to change this without creating more significant problems. > And if this doesn't > happen (as it is currently), I start wondering whether there could be a > bug in v.in.region, or g.region, or d.vect an so on. Waste of time, > less trust in GRASS, bogus bug reports etc. > > If it is possible to fix that without too much effort, I would be for it. How do you propose "fixing" this case without breaking more sensible cases. Bear in mind that this is (quite literally) a "boundary case". > > This doesn't allow for thick lines, where the path itself (i.e. the > > centre-line) might lie just outside the region but the "stroke" can > > still be visible. It also doesn't allow for the fact that the tiniest > > rounding error might push the path outside. > > > > Note that the clipping/culling code doesn't make any allowance for the > > line width. It can't; it doesn't know the line width (R_line_width() > > does directly to the driver; the display library doesn't get to see > > it). > > Propably I did not understand something, but as I can see render=c/l > work well together with width= in d.vect. Did you mean something else? They only work because: a) I tweaked the clip/cull tests slightly (changed <0 to <=0), and b) the coordinates of the region's boundary are integers, so converting from cartographic coordinates to display coordinates doesn't suffer from rounding error. Had the right-hand edge been given a display X coordinate of 640.000001, render=c/l would have discarded the edge, as it lies entirely outside the region. The fact that part of the "stroke" (the filled area centred upon the actual line) would still be visible isn't taken into account when clipping/culling, as the display library doesn't know about the line width. That's why I say that there needs to be a D_line_width() or D_margin() or similar, so that the clipping/culling code won't discard edges which lie only just outside the region. -- Glynn Clements From hmitaso at unity.ncsu.edu Sun Apr 8 20:15:44 2007 From: hmitaso at unity.ncsu.edu (Helena Mitasova) Date: Sun Apr 8 20:15:38 2007 Subject: [GRASS-dev] Fwd: 2GB point file support References: <20070408172201.GA541@bartok.itc.it> Message-ID: I have been going through some unresolved issues that I am trying to keep track of and I would like to ask whether the below is still true? Has anybody worked vector data sets that are larger than 2GB? thank you, Helena >> >> Begin forwarded message: >> >>> From: Andrew Danner >>> Date: June 30, 2006 6:16:41 PM EDT >>> To: Helena Mitasova >>> Subject: Re: Panama data >>> >>> [...] >>> The bigger >>> problem is that the vector library only supports 32-bit file >>> offsets, so >>> you can't have point sets larger than 2GB. Fixing this requires much >>> more work I think and may even break backwards compatibility, so it >>> might be more of a grass7 change. I may have some more time to >>> look at >>> code issues in grass in the fall instead of focusing solely on >>> research >>> issues. >>> >>> I think if we want a scalable v.surf.rst, we have to stick with >>> grass54 >>> (which is what I still run my larger tests on), which is a shame, >>> because I like many of the grass6 features and the code layout is >>> much >>> more logical. Alternatively, I can modify my code to get the >>> point data >>> directly from the ascii file like r.in.xyz does and skip the grass >>> vector point import altogether. Ultimately, grass should support >>> large >>> vector files, but that is easier said than done. >>> >> > > ------------------ > ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler > ITC -> since 1 March 2007 Fondazione Bruno Kessler > ------------------ From tutey at o2.pl Sun Apr 8 20:32:03 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Sun Apr 8 20:32:06 2007 Subject: [GRASS-dev] d.vect render= and corrupted vector display In-Reply-To: <17945.7854.435733.691855@cerise.gclements.plus.com> References: <4618AB15.3090002@o2.pl> <17944.62659.369399.495267@cerise.gclements.plus.com> <46190A69.8030802@o2.pl> <17945.7854.435733.691855@cerise.gclements.plus.com> Message-ID: <46193523.4040508@o2.pl> Glynn Clements wrote: > Maciej Sieczka wrote: > >>> I've changed the clipping/culling code to handle this particular case >>> (i.e. use <= 0 rather than < 0), so #4 and #5 now match the other >>> three. >>> Beyond that, the main issue is that the code which sets up the >>> coordinate mapping (D_setup/D_do_conversions) maps the current region >>> to the current frame *exactly*, without any margin. This is arguably >>> the right thing, even if the net result isn't always ideal (and the >>> result of v.in.region is the worst possible case). >> Don't you think it is confussing for the user? If I do v.in.region, I'm >> right to expect that the whole vector will be displayed when my working >> region matches the v.in.region's output extent. > Hmm; not really. v.in.region generates a vector map corresponding to > the region's boundary. d.vect displays the portion of a vector map > which lies inside the region. > > Is a region's boundary *inside* the region? 1. This is not a boundary, but a line (v.in.region output=frame type=line). 2. Even if it was a boundary - either the *whole* boundary should be displayed, or not. Currently, 75% of the boundary is displayed, while the other 25% is not. This looks strange to the user. Too bad if cannot be "fixed", though I'm 100% OK with whatever you decide about it and thank you for taking your time to check it out and explain it. > If you treat the boundary as an area, then the area which d.vect will > fill is exactly the region, i.e. inside the boundary == inside the > region. But is the boundary itself inside the region? > > I'm aware that this may be counter-intuitive, but that isn't the same > thing as being wrong. The problem is that I don't see how to change > this without creating more significant problems. >> And if this doesn't >> happen (as it is currently), I start wondering whether there could be a >> bug in v.in.region, or g.region, or d.vect an so on. Waste of time, >> less trust in GRASS, bogus bug reports etc. >> >> If it is possible to fix that without too much effort, I would be for it. > How do you propose "fixing" this case I can't know that. I thought you might, so I asked. > without breaking more sensible cases. What could be broken? > Bear in mind that this is > (quite literally) a "boundary case". I don't agree. This issue might bias user's understanding of GRASS' region, which is not trivial: g.region vect=frame; d.vect frame In a result, 25% of lines is missing on display, while region and display were ordered to encompass the whole vector "frame". As the 3/4 of lines is displayed while 1/4 is not, it just looks "not good" to the user, thus might incline him to think there is a defect somewhere underneath. Please note that if you decide this cannot be fixed/too intrusive to do so/to much work compared to profit, please be sure I'm perfectly OK with your decision. Yet, the issue would remain. Maciek From glynn at gclements.plus.com Sun Apr 8 22:18:22 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Apr 8 22:18:28 2007 Subject: [GRASS-dev] d.vect render= and corrupted vector display In-Reply-To: <46193523.4040508@o2.pl> References: <4618AB15.3090002@o2.pl> <17944.62659.369399.495267@cerise.gclements.plus.com> <46190A69.8030802@o2.pl> <17945.7854.435733.691855@cerise.gclements.plus.com> <46193523.4040508@o2.pl> Message-ID: <17945.19982.119626.732589@cerise.gclements.plus.com> Maciej Sieczka wrote: > >>> I've changed the clipping/culling code to handle this particular case > >>> (i.e. use <= 0 rather than < 0), so #4 and #5 now match the other > >>> three. > >>> Beyond that, the main issue is that the code which sets up the > >>> coordinate mapping (D_setup/D_do_conversions) maps the current region > >>> to the current frame *exactly*, without any margin. This is arguably > >>> the right thing, even if the net result isn't always ideal (and the > >>> result of v.in.region is the worst possible case). > >> Don't you think it is confussing for the user? If I do v.in.region, I'm > >> right to expect that the whole vector will be displayed when my working > >> region matches the v.in.region's output extent. > > > Hmm; not really. v.in.region generates a vector map corresponding to > > the region's boundary. d.vect displays the portion of a vector map > > which lies inside the region. > > > > Is a region's boundary *inside* the region? > > 1. This is not a boundary, but a line (v.in.region output=frame type=line). Note that I mean "boundary" in the general sense, not specifically GV_BOUNDARY. > 2. Even if it was a boundary - either the *whole* boundary should be > displayed, or not. Currently, 75% of the boundary is displayed, while > the other 25% is not. This looks strange to the user. Typically, two of the region edges will be coincident with the corresponding edges of the display frame, while the other two won't (unless the region's aspect ratio exactly matches that of the display frame). For a vertical or horizontal line segment which is concident with an edge of the display frame, it's essentially a 50/50 chance as to whether that edge will lie inside or outside the frame; even the slightest rounding error can decide it. Note that it is not guaranteed that (x/y)*y == x when using floating point. If you go out of your way to create lines which lie exactly on a boundary, the results are bound to be unpredictable. Unfortunately, that's exactly what v.in.region does. Ultimately, the only solution is to stick to even line widths (i.e. width=2, width=4 etc), or use the PS driver. Then you're guaranteed to get exactly half of a line on each side (if you don't, that *is* a bug). > > How do you propose "fixing" this case > > I can't know that. I thought you might, so I asked. > > > without breaking more sensible cases. > > What could be broken? Well, that depends upon what you change. AFAICT, changing anything which is likely to affect the result of v.in.region type=line + d.vect amounts to introducing an error. One solution is to expand the region used by D_do_conversions() (either pass in an expanded region or have D_do_conversions() expand it) so that data which lies either within the current region or exactly on its bounds always lies comfortably within the expanded region. But expanded by how much? A metre, a pixel, 1%, ...? It would have to be consistent if you want to overlay maps. Also, that would cause problems for any external code which attempts to reproduce the conversion; ISTR that gis.m does this to convert mouse coordinates to geographic coordinates. > > Bear in mind that this is > > (quite literally) a "boundary case". > > I don't agree. This issue might bias user's understanding of GRASS' > region, which is not trivial: That doesn't have any effect upon whether this is a boundary case. > g.region vect=frame; d.vect frame > > In a result, 25% of lines is missing on display, while region and > display were ordered to encompass the whole vector "frame". As the 3/4 > of lines is displayed while 1/4 is not, it just looks "not good" to the > user, thus might incline him to think there is a defect somewhere > underneath. > > Please note that if you decide this cannot be fixed/too intrusive to do > so/to much work compared to profit, please be sure I'm perfectly OK > with your decision. Yet, the issue would remain. If it was critical, it could be trivially fixed by prohibiting odd line widths in the X and PNG drivers. Unfortunately, a line width of 2 may be much slower than a line width of 1 for the X driver, as it uses a completely different (and more complex) algorithm. But this is just a single (albeit rather striking) example of an inevitable problem with raster graphics: aliasing. Even if you fix this specific case by means of some fudge, there are an unlimited number of similar cases. -- Glynn Clements From woklist at kyngchaos.com Mon Apr 9 01:41:03 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Mon Apr 9 01:41:17 2007 Subject: [GRASS-dev] return of the OSX xterm question Message-ID: <067285F7-8D2C-4DF3-8D92-C13EE4BB8171@kyngchaos.com> Messing around today, and I recalled the discussion about how to get grass-xterm-wrapper to use an OSX Terminal. I think I figured out something that could work. Combining Lorenzo's AppleScript sample and Glynn's way to strip the command out of the parameters and a little experimentation, I have a relatively simple script to do this. Though simple - it's all handled in grass-xterm-wrapper, so there is no need to rewrite scripts - it's a bit of a messy AppleScript hack. The main problem I couldn't fix is that the AppleScript command to run a shell script in the Terminal chokes on large command strings (1 byte over 1K), and a large string is needed to pass the env vars to the Terminal. So I pass them in byte-sized (hee hee) pieces, and there is the potential that the user can interrupt this by switching to another Terminal window. But it's fast enough that it shouldn't be a serious problem. To test this, replace lib/init/grass-xterm-wrapper with this one and rebuild GRASS, or replace the installed grass/etc/grass-xterm- wrapper. Before running GRASS, set GRASS_XTERM=Terminal.app in your ~/.bash_profile. -------------- next part -------------- A non-text attachment was scrubbed... Name: grass-xterm-wrapper Type: application/octet-stream Size: 2761 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070408/e864db4e/grass-xterm-wrapper.obj -------------- next part -------------- I tested it in the Tcl GUI startup mapset screen, choosing New Location by Projection Values. One thing I'm wondering - is there a way to run a command in a shell script without displaying the command in the shell? Something like the @ prefix used in makefiles? Since I have to recreate the env vars in the new Terminal window, a lot of stuff is spewed to the user before the requested command is actually run. ----- William Kyngesburye http://www.kyngchaos.com/ "History is an illusion caused by the passage of time, and time is an illusion caused by the passage of history." - Hitchhiker's Guide to the Galaxy From glynn at gclements.plus.com Mon Apr 9 02:00:12 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Apr 9 02:00:15 2007 Subject: [GRASS-dev] return of the OSX xterm question In-Reply-To: <067285F7-8D2C-4DF3-8D92-C13EE4BB8171@kyngchaos.com> References: <067285F7-8D2C-4DF3-8D92-C13EE4BB8171@kyngchaos.com> Message-ID: <17945.33292.321787.446725@cerise.gclements.plus.com> William Kyngesburye wrote: > One thing I'm wondering - is there a way to run a command in a shell > script without displaying the command in the shell? Something like > the @ prefix used in makefiles? Since I have to recreate the env > vars in the new Terminal window, a lot of stuff is spewed to the user > before the requested command is actually run. This isn't a shell issue; it's an artifact of remote-controlling an existing terminal through AppleScript. Can you not just run the command in a separate terminal instance, in the same way that xterms are used? -- Glynn Clements From woklist at kyngchaos.com Mon Apr 9 02:14:55 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Mon Apr 9 02:15:07 2007 Subject: [GRASS-dev] return of the OSX xterm question In-Reply-To: <17945.33292.321787.446725@cerise.gclements.plus.com> References: <067285F7-8D2C-4DF3-8D92-C13EE4BB8171@kyngchaos.com> <17945.33292.321787.446725@cerise.gclements.plus.com> Message-ID: On Apr 8, 2007, at 7:00 PM, Glynn Clements wrote: > William Kyngesburye wrote: > >> One thing I'm wondering - is there a way to run a command in a shell >> script without displaying the command in the shell? Something like >> the @ prefix used in makefiles? Since I have to recreate the env >> vars in the new Terminal window, a lot of stuff is spewed to the user >> before the requested command is actually run. > > This isn't a shell issue; it's an artifact of remote-controlling an > existing terminal through AppleScript. > Hmm. My OSX app startup does this too. I thought I've seen it purely from running a shell script in a Terminal, but I could be mistaken. Oh well, just have to put up with a little clutter... > Can you not just run the command in a separate terminal instance, in > the same way that xterms are used? > Not quite. Problems (rehash from previous discussion): - doesn't inherit env - returns immediately, without waiting for command to finish - leaves Terminal as active application, so one must manually switch back to whatever called it (ie X11/Tcltk) ----- William Kyngesburye http://www.kyngchaos.com/ [Trillian] What are you supposed to do WITH a maniacally depressed robot? [Marvin] You think you have problems? What are you supposed to do if you ARE a maniacally depressed robot? No, don't try and answer, I'm 50,000 times more intelligent than you and even I don't know the answer... - HitchHiker's Guide to the Galaxy From michael.barton at asu.edu Mon Apr 9 08:26:24 2007 From: michael.barton at asu.edu (Michael Barton) Date: Mon Apr 9 08:26:37 2007 Subject: [GRASS-dev] Re: return of the OSX xterm question In-Reply-To: <067285F7-8D2C-4DF3-8D92-C13EE4BB8171@kyngchaos.com> Message-ID: I'll give this a try tomorrow. I don't know the answer to the question about running a command without command output. But I'd like to know for the wxPython GUI. Cheers Michael On 4/8/07 4:41 PM, "William Kyngesburye" wrote: > Messing around today, and I recalled the discussion about how to get > grass-xterm-wrapper to use an OSX Terminal. I think I figured out > something that could work. Combining Lorenzo's AppleScript sample > and Glynn's way to strip the command out of the parameters and a > little experimentation, I have a relatively simple script to do this. > > Though simple - it's all handled in grass-xterm-wrapper, so there is > no need to rewrite scripts - it's a bit of a messy AppleScript hack. > > The main problem I couldn't fix is that the AppleScript command to > run a shell script in the Terminal chokes on large command strings (1 > byte over 1K), and a large string is needed to pass the env vars to > the Terminal. So I pass them in byte-sized (hee hee) pieces, and > there is the potential that the user can interrupt this by switching > to another Terminal window. > > But it's fast enough that it shouldn't be a serious problem. > > To test this, replace lib/init/grass-xterm-wrapper with this one and > rebuild GRASS, or replace the installed grass/etc/grass-xterm- > wrapper. Before running GRASS, set GRASS_XTERM=Terminal.app in your > ~/.bash_profile. > > > I tested it in the Tcl GUI startup mapset screen, choosing New > Location by Projection Values. > > > One thing I'm wondering - is there a way to run a command in a shell > script without displaying the command in the shell? Something like > the @ prefix used in makefiles? Since I have to recreate the env > vars in the new Terminal window, a lot of stuff is spewed to the user > before the requested command is actually run. > > ----- > William Kyngesburye > http://www.kyngchaos.com/ > > "History is an illusion caused by the passage of time, and time is an > illusion caused by the passage of history." > > - Hitchhiker's Guide to the Galaxy > > __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From grass-codei at wald.intevation.org Mon Apr 9 09:08:45 2007 From: grass-codei at wald.intevation.org (grass-codei@wald.intevation.org) Date: Mon Apr 9 09:08:48 2007 Subject: [GRASS-dev] [grass-code I][366] branch 6.2 should build grass62 Message-ID: <20070409070845.E49D91973F9B@pyrosoma.intevation.org> code I item #366, was opened at 2007-04-09 09:08 Status: Open Priority: 3 Submitted By: Francesco Lovergine (frankie) Assigned to: Nobody (None) Summary: branch 6.2 should build grass62 Issue type: other bug Issue status: None GRASS version: 6.2 GRASS component: build Operating system: all Operating system version: GRASS CVS checkout date, if applies (YYMMDD): Initial Comment: It still builds grass63 instead. IMHO after branching it should build the grass62 binary, which is much more coherent and prevents possible build failures for packagers. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=366&group_id=21 From glynn at gclements.plus.com Mon Apr 9 10:48:15 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Apr 9 10:48:18 2007 Subject: [GRASS-dev] Re: [GRASS-user] v.what.rast (large file) In-Reply-To: <9A7DBAC8-7458-4FAE-876D-A9735AE76E4E@yahoo.it> References: <9A7DBAC8-7458-4FAE-876D-A9735AE76E4E@yahoo.it> Message-ID: <17945.64975.520050.289809@cerise.gclements.plus.com> Massimo Di Stefano wrote: > i've a large point vector file (ascii 160 mb) > can i divide my area in many subregion > and then patch the results ? The categories are modified in-place, so you can just run the command on each subregion; there's no need to "patch" anything. AFAICT, the problem is in the code which deletes duplicate categories: i = 1; while ( i < point_cnt ) { if ( cache[i].cat == cache[i-1].cat ) { cache[i-1].count++; for ( j = i; j < point_cnt - 1; j++ ) { cache[j].row = cache[j+1].row; cache[j].col = cache[j+1].col; cache[j].cat = cache[j+1].cat; cache[j].count = cache[j+1].count; } point_cnt--; continue; } i++; } This is O(n^2), but thiscould be done in O(n). The problem is that it's shifting the remainder of the array down by one place at each step, when it could move each entry to its final destination in one go. E.g. (untested): i = j = 1; while ( i < point_cnt ) { while ( i < point_cnt && cache[i].cat == cache[j-1].cat ) { cache[j-1].count++; i++; } cache[j].row = cache[i].row; cache[j].col = cache[i].col; cache[j].cat = cache[i].cat; cache[j].count = cache[i].count; i++; j++; } point_cnt = j; -- Glynn Clements From glynn at gclements.plus.com Mon Apr 9 10:56:31 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Apr 9 10:56:33 2007 Subject: [GRASS-dev] return of the OSX xterm question In-Reply-To: References: <067285F7-8D2C-4DF3-8D92-C13EE4BB8171@kyngchaos.com> <17945.33292.321787.446725@cerise.gclements.plus.com> Message-ID: <17945.65471.418796.321712@cerise.gclements.plus.com> William Kyngesburye wrote: > >> One thing I'm wondering - is there a way to run a command in a shell > >> script without displaying the command in the shell? Something like > >> the @ prefix used in makefiles? Since I have to recreate the env > >> vars in the new Terminal window, a lot of stuff is spewed to the user > >> before the requested command is actually run. > > > > This isn't a shell issue; it's an artifact of remote-controlling an > > existing terminal through AppleScript. > > > Hmm. My OSX app startup does this too. I thought I've seen it > purely from running a shell script in a Terminal, but I could be > mistaken. Oh well, just have to put up with a little clutter... bash only echoes commands if run with the -x flag. > > Can you not just run the command in a separate terminal instance, in > > the same way that xterms are used? > > > Not quite. Problems (rehash from previous discussion): > > - doesn't inherit env So far as this part is concerned, I suggest writing out the environment as a shell script, then sending e.g. "source /path/to/env.sh" to the terminal, rather than sending individual settings. > - returns immediately, without waiting for command to finish > > - leaves Terminal as active application, so one must manually switch > back to whatever called it (ie X11/Tcltk) Can you create a new terminal, send it the command, wait for the command to complete, then kill the terminal? Sending environment settings to an existing terminal might cause problems for what you were doing in that terminal. Also, isn't there anything like xterm which uses the native GUI? Or is there something about the nature of the GUI which makes that impossible? -- Glynn Clements From tutey at o2.pl Mon Apr 9 13:11:05 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Mon Apr 9 13:11:08 2007 Subject: [GRASS-dev] d.vect render= and corrupted vector display In-Reply-To: <17945.19982.119626.732589@cerise.gclements.plus.com> References: <4618AB15.3090002@o2.pl> <17944.62659.369399.495267@cerise.gclements.plus.com> <46190A69.8030802@o2.pl> <17945.7854.435733.691855@cerise.gclements.plus.com> <46193523.4040508@o2.pl> <17945.19982.119626.732589@cerise.gclements.plus.com> Message-ID: <461A1F49.8030405@o2.pl> Glynn Clements wrote: > Maciej Sieczka wrote: > >>>>> I've changed the clipping/culling code to handle this particular case >>>>> (i.e. use <= 0 rather than < 0), so #4 and #5 now match the other >>>>> three. >>>>> Beyond that, the main issue is that the code which sets up the >>>>> coordinate mapping (D_setup/D_do_conversions) maps the current region >>>>> to the current frame *exactly*, without any margin. This is arguably >>>>> the right thing, even if the net result isn't always ideal (and the >>>>> result of v.in.region is the worst possible case). >>>> Don't you think it is confussing for the user? If I do v.in.region, I'm >>>> right to expect that the whole vector will be displayed when my working >>>> region matches the v.in.region's output extent. >>> Hmm; not really. v.in.region generates a vector map corresponding to >>> the region's boundary. d.vect displays the portion of a vector map >>> which lies inside the region. >>> >>> Is a region's boundary *inside* the region? >> 1. This is not a boundary, but a line (v.in.region output=frame type=line). > > Note that I mean "boundary" in the general sense, not specifically > GV_BOUNDARY. > >> 2. Even if it was a boundary - either the *whole* boundary should be >> displayed, or not. Currently, 75% of the boundary is displayed, while >> the other 25% is not. This looks strange to the user. > > Typically, two of the region edges will be coincident with the > corresponding edges of the display frame, while the other two won't Do you mean that either both horizontal or both vertical lines should be not visible on display? I don't confirm. Alway a single line is missing - either the bottom, or the right side edge, depending on the with X monitor windows's aspect ratio. (Talking of d.vet width=1 here.) To reproduce: 1. v.in.region output=frame type=line 2. d.vect frame 3. play with X monitor windows's aspect ratio > (unless the region's aspect ratio exactly matches that of the display > frame). If you mean that in such case all edges should be displayed, I don't confirm. To reproduce: 1. g.region n=4926750 s=4914430 w=594880 e=607200 res=10 -ag (results is a square region) 2. d.mon x0; d.resize width=320 height=320 (square X display) 3. v.in.region square type=line; d.vect square (only left and top edge are displayed) > For a vertical or horizontal line segment which is concident with an > edge of the display frame, it's essentially a 50/50 chance as to > whether that edge will lie inside or outside the frame; even the > slightest rounding error can decide it. Note that it is not guaranteed > that (x/y)*y == x when using floating point. > > If you go out of your way to create lines which lie exactly on a > boundary, the results are bound to be unpredictable. Unfortunately, > that's exactly what v.in.region does. > > Ultimately, the only solution is to stick to even line widths (i.e. > width=2, width=4 etc), or use the PS driver. Then you're guaranteed to > get exactly half of a line on each side (if you don't, that *is* a > bug). Hmm. With line width=1 I get the effect as described above. With width 2 or 4 I get the effect that either both horizontal or both vertical edges (depending on the with X monitor windows's aspect ratio) are twice that thick as the other pair of lines. If it is not clear what I mean, please look at the attached screenshot of d.vect frame width=2. Do you mean this is a bug? >>> Bear in mind that this is >>> (quite literally) a "boundary case". >> I don't agree. This issue might bias user's understanding of GRASS' >> region, which is not trivial: > That doesn't have any effect upon whether this is a boundary case. By "boundary case", do you mean to assume that v.in.region+d.vect is unlikely to be used? Just curios. Maciek -------------- next part -------------- A non-text attachment was scrubbed... Name: horizontal_edges_thinner.png Type: image/png Size: 1862 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070409/1dddaa9f/horizontal_edges_thinner-0001.png -------------- next part -------------- A non-text attachment was scrubbed... Name: vertical_edges_thinner.png Type: image/png Size: 933 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070409/1dddaa9f/vertical_edges_thinner-0001.png From Bernhard.Hoefle at uibk.ac.at Mon Apr 9 13:37:27 2007 From: Bernhard.Hoefle at uibk.ac.at (Bernhard Reimar Hoefle) Date: Mon Apr 9 13:37:30 2007 Subject: [GRASS-dev] v.to.db manual compactness Message-ID: <1176118647.461a2577888d7@web-mail2.uibk.ac.at> Hi! In the equation for compactness the parentheses are missing. http://grass.itc.it/grass63/manuals/html63_user/v.to.db.html Can somebody update it? It should be (checked in source): compactness = perimeter / (2 * sqrt(PI * area) ) It's a very small but important detail! Bernhard From tutey at o2.pl Mon Apr 9 14:15:59 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Mon Apr 9 14:16:03 2007 Subject: [GRASS-dev] v.to.db manual compactness In-Reply-To: <1176118647.461a2577888d7@web-mail2.uibk.ac.at> References: <1176118647.461a2577888d7@web-mail2.uibk.ac.at> Message-ID: <461A2E7F.4090804@o2.pl> Bernhard Reimar Hoefle wrote: > Hi! > In the equation for compactness the parentheses are missing. > > http://grass.itc.it/grass63/manuals/html63_user/v.to.db.html > > Can somebody update it? > > It should be (checked in source): > > compactness = perimeter / (2 * sqrt(PI * area) ) Thanks for the information. Please use the bugtracker to report issues: http://grass.itc.it/bugtracking/index.php Maciek From grass-doci at wald.intevation.org Mon Apr 9 14:24:59 2007 From: grass-doci at wald.intevation.org (grass-doci@wald.intevation.org) Date: Mon Apr 9 14:25:03 2007 Subject: [GRASS-dev] [grass-doc I][367] v.to.db manual compactness Message-ID: <20070409122459.C564F1973F9B@pyrosoma.intevation.org> doc I item #367, was opened at 2007-04-09 12:24 Status: Open Priority: 3 Submitted By: Bernhard H?fle (bhoefle) Assigned to: Nobody (None) Summary: v.to.db manual compactness Issue status: None Doc section: vector GRASS version: CVS HEAD Doc timestamp (YYMMDD): Initial Comment: Hi! In the equation for compactness the parentheses are missing. http://grass.itc.it/grass63/manuals/html63_user/v.to.db.html Can somebody update it? It should be (checked in source): compactness = perimeter / (2 * sqrt(PI * area) ) ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=207&aid=367&group_id=21 From glynn at gclements.plus.com Mon Apr 9 14:39:27 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Apr 9 14:39:47 2007 Subject: [GRASS-dev] d.vect render= and corrupted vector display In-Reply-To: <461A1F49.8030405@o2.pl> References: <4618AB15.3090002@o2.pl> <17944.62659.369399.495267@cerise.gclements.plus.com> <46190A69.8030802@o2.pl> <17945.7854.435733.691855@cerise.gclements.plus.com> <46193523.4040508@o2.pl> <17945.19982.119626.732589@cerise.gclements.plus.com> <461A1F49.8030405@o2.pl> Message-ID: <17946.13311.501965.898973@cerise.gclements.plus.com> Maciej Sieczka wrote: > > Typically, two of the region edges will be coincident with the > > corresponding edges of the display frame, while the other two won't > > Do you mean that either both horizontal or both vertical lines should > be not visible on display? No. I mean that one pair (both horizontal or both vertical) will normally be visible, while the other two should each have a 50/50 chance of being visible. In the latter case, various factors may combine to affect the actual ratio. E.g. the fact that the transformation is rooted at the north-west corner will typically mean that the top/left edges always result in an exact zero, producing the same result every time. As with anything related to floating-point, the architecture and any compilation options may affect the outcome. > > For a vertical or horizontal line segment which is concident with an > > edge of the display frame, it's essentially a 50/50 chance as to > > whether that edge will lie inside or outside the frame; even the > > slightest rounding error can decide it. Note that it is not guaranteed > > that (x/y)*y == x when using floating point. > > > > If you go out of your way to create lines which lie exactly on a > > boundary, the results are bound to be unpredictable. Unfortunately, > > that's exactly what v.in.region does. > > > > Ultimately, the only solution is to stick to even line widths (i.e. > > width=2, width=4 etc), or use the PS driver. Then you're guaranteed to > > get exactly half of a line on each side (if you don't, that *is* a > > bug). > > Hmm. With line width=1 I get the effect as described above. With width > 2 or 4 I get the effect that either both horizontal or both vertical > edges (depending on the with X monitor windows's aspect ratio) are > twice that thick as the other pair of lines. This is correct behaviour. One pair of region edges will always exactly touch the corresponding edges of the frame, while the other pair will usually have a margin. For an edge which exactly touches the frame, any line which follows that edge will get clipped down the middle. If the aspect ratio of the region exactly matches that of the frame, all four edges will coincide, and all four lines should be half-drawn. > If it is not clear what I > mean, please look at the attached screenshot of d.vect frame width=2. > Do you mean this is a bug? No, I mean that anything else would be a bug. > >>> Bear in mind that this is > >>> (quite literally) a "boundary case". > > >> I don't agree. This issue might bias user's understanding of GRASS' > >> region, which is not trivial: > > > That doesn't have any effect upon whether this is a boundary case. > > By "boundary case", do you mean to assume that v.in.region+d.vect is > unlikely to be used? Just curios. No, I mean that it's a case where a "point" is neither inside nor outside but on the boundary. The term doesn't refer solely to geometry. In any context where some continuous (non-discrete) space is partitioned into distinct categories, you get values which fall on the boundary between categories. E.g. if you partition the real numbers into positive and negative, which is zero? -- Glynn Clements From woklist at kyngchaos.com Mon Apr 9 16:13:25 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Mon Apr 9 16:13:39 2007 Subject: [GRASS-dev] return of the OSX xterm question In-Reply-To: <17945.65471.418796.321712@cerise.gclements.plus.com> References: <067285F7-8D2C-4DF3-8D92-C13EE4BB8171@kyngchaos.com> <17945.33292.321787.446725@cerise.gclements.plus.com> <17945.65471.418796.321712@cerise.gclements.plus.com> Message-ID: <95656C5F-51A6-4A47-A8D2-65941C4332FE@kyngchaos.com> On Apr 9, 2007, at 3:56 AM, Glynn Clements wrote: >>> Can you not just run the command in a separate terminal instance, in >>> the same way that xterms are used? >>> >> Not quite. Problems (rehash from previous discussion): >> >> - doesn't inherit env > > So far as this part is concerned, I suggest writing out the > environment as a shell script, then sending e.g. > "source /path/to/env.sh" to the terminal, rather than sending > individual settings. > Interaction with Terminal.app from AppleScript is limited to sending commands inline. If I sent the temp script file first from the shell, then switched to AppleScript control, there is the problem that I might connect to the wrong Terminal window due to the Terminal's limited AppleScript capabilities. >> - returns immediately, without waiting for command to finish >> >> - leaves Terminal as active application, so one must manually switch >> back to whatever called it (ie X11/Tcltk) > > Can you create a new terminal, send it the command, wait for the > command to complete, then kill the terminal? > > Sending environment settings to an existing terminal might cause > problems for what you were doing in that terminal. > The AppleScript part does this. AppleScript is needed to do the waiting. It also waits for the env commands, though just with a single delay (I may need to loop that for slow Macs). > Also, isn't there anything like xterm which uses the native GUI? Or is > there something about the nature of the GUI which makes that > impossible? > I saw an alternative recently, and it claims xterm compatibility. It's in beta right now. One small problem is requiring/suggesting yet another extra on a user's system. But mainly, I can't understand how the xterm compatibility part would work: to be able to handle the xterm flags, it has to be able to run from the CLI, but when run from the CLI an application executable opens a completely new instance of the whole application, not a new window (exactly the same problem as the browser issue I'm working on). The open method which is necessary operates on files, and doesn't have a way to pass arguments with that. ----- William Kyngesburye http://www.kyngchaos.com/ "This is a question about the past, is it? ... How can I tell that the past isn't a fiction designed to account for the discrepancy between my immediate physical sensations and my state of mind?" - The Ruler of the Universe From woklist at kyngchaos.com Mon Apr 9 16:19:26 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Mon Apr 9 16:19:38 2007 Subject: [GRASS-dev] Re: return of the OSX xterm question In-Reply-To: References: Message-ID: <5916C825-08C8-47BB-9DBD-BDDA7F268A58@kyngchaos.com> On Apr 9, 2007, at 1:26 AM, Michael Barton wrote: > I'll give this a try tomorrow. I don't know the answer to the > question about > running a command without command output. But I'd like to know for the > wxPython GUI. > Do you mean echoing of the command itself to the Terminal or output from the command? I'm talking about echoing the command. Glynn suggested that it's an AppleScript side effect, and that makes sense - AppleScript is effectively pasting the command into the Terminal window. ----- William Kyngesburye http://www.kyngchaos.com/ Theory of the Universe There is a theory which states that if ever anyone discovers exactly what the universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarrely inexplicable. There is another theory which states that this has already happened. -Hitchhiker's Guide to the Galaxy 2nd season intro From glynn at gclements.plus.com Mon Apr 9 17:18:41 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Apr 9 17:18:43 2007 Subject: [GRASS-dev] return of the OSX xterm question In-Reply-To: <95656C5F-51A6-4A47-A8D2-65941C4332FE@kyngchaos.com> References: <067285F7-8D2C-4DF3-8D92-C13EE4BB8171@kyngchaos.com> <17945.33292.321787.446725@cerise.gclements.plus.com> <17945.65471.418796.321712@cerise.gclements.plus.com> <95656C5F-51A6-4A47-A8D2-65941C4332FE@kyngchaos.com> Message-ID: <17946.22865.94012.39668@cerise.gclements.plus.com> William Kyngesburye wrote: > > Also, isn't there anything like xterm which uses the native GUI? Or is > > there something about the nature of the GUI which makes that > > impossible? > > I saw an alternative recently, and it claims xterm compatibility. > It's in beta right now. One small problem is requiring/suggesting > yet another extra on a user's system. > > But mainly, I can't understand how the xterm compatibility part would > work: to be able to handle the xterm flags, it has to be able to run > from the CLI, but when run from the CLI an application executable > opens a completely new instance of the whole application, not a new > window (exactly the same problem as the browser issue I'm working on). And what's the problem with that? I can see why this might be a problem for a browser; I don't see why it's a problem for a terminal. -- Glynn Clements From tutey at o2.pl Mon Apr 9 17:30:46 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Mon Apr 9 17:30:52 2007 Subject: [GRASS-dev] d.vect render= and corrupted vector display In-Reply-To: <17946.13311.501965.898973@cerise.gclements.plus.com> References: <4618AB15.3090002@o2.pl> <17944.62659.369399.495267@cerise.gclements.plus.com> <46190A69.8030802@o2.pl> <17945.7854.435733.691855@cerise.gclements.plus.com> <46193523.4040508@o2.pl> <17945.19982.119626.732589@cerise.gclements.plus.com> <461A1F49.8030405@o2.pl> <17946.13311.501965.898973@cerise.gclements.plus.com> Message-ID: <461A5C26.6030408@o2.pl> Glynn Clements wrote: > Maciej Sieczka wrote: >> By "boundary case", do you mean to assume that v.in.region+d.vect is >> unlikely to be used? Just curios. > No, I mean that it's a case where a "point" is neither inside nor > outside but on the boundary. > > The term doesn't refer solely to geometry. In any context where some > continuous (non-discrete) space is partitioned into distinct > categories, you get values which fall on the boundary between > categories. E.g. if you partition the real numbers into positive and > negative, which is zero? As to display, I guess I get it know. However, I'm not sure what to think about this issue in regard to computational GRASS region. Let's take a following eaxample; in spearfish: $ g.region rast=landuse -a $ v.in.region lu_border type=line $ v.category lu_border out=lu_border_cat option=add $ g.region vect=lu_border_cat $ v.to.rast input=lu_border_cat output=lu_border_cat use=cat The outcome is a raster which includes only the top and left lines, while region was ordered to cover the whole "lu_border_cat" vector. >From user's point of view, half of the input vector was ignored by v.to.rast, in error. Is this not fixable too? Maciek From woklist at kyngchaos.com Mon Apr 9 19:09:32 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Mon Apr 9 19:09:48 2007 Subject: [GRASS-dev] return of the OSX xterm question In-Reply-To: <17946.22865.94012.39668@cerise.gclements.plus.com> References: <067285F7-8D2C-4DF3-8D92-C13EE4BB8171@kyngchaos.com> <17945.33292.321787.446725@cerise.gclements.plus.com> <17945.65471.418796.321712@cerise.gclements.plus.com> <95656C5F-51A6-4A47-A8D2-65941C4332FE@kyngchaos.com> <17946.22865.94012.39668@cerise.gclements.plus.com> Message-ID: <8B39095B-A69E-4832-86BC-36376FBA8C4B@kyngchaos.com> On Apr 9, 2007, at 10:18 AM, Glynn Clements wrote: >> But mainly, I can't understand how the xterm compatibility part would >> work: to be able to handle the xterm flags, it has to be able to run >> from the CLI, but when run from the CLI an application executable >> opens a completely new instance of the whole application, not a new >> window (exactly the same problem as the browser issue I'm working >> on). > > And what's the problem with that? > > I can see why this might be a problem for a browser; I don't see why > it's a problem for a terminal. > It's a general OSX problem/quirk when running any .app application from the CLI. If the application is already running, you don't get a new window in the application (or whatever the default action is, depending on what is passed to it). New instances of whole applications is not the way to run OSX apps. Instead, you must tell the system to open a file with a particular application (the 'open' CLI command) so the system can take care of deciding whether the application is already running. ----- William Kyngesburye http://www.kyngchaos.com/ "History is an illusion caused by the passage of time, and time is an illusion caused by the passage of history." - Hitchhiker's Guide to the Galaxy From glynn at gclements.plus.com Mon Apr 9 19:46:29 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Apr 9 19:46:32 2007 Subject: [GRASS-dev] d.vect render= and corrupted vector display In-Reply-To: <461A5C26.6030408@o2.pl> References: <4618AB15.3090002@o2.pl> <17944.62659.369399.495267@cerise.gclements.plus.com> <46190A69.8030802@o2.pl> <17945.7854.435733.691855@cerise.gclements.plus.com> <46193523.4040508@o2.pl> <17945.19982.119626.732589@cerise.gclements.plus.com> <461A1F49.8030405@o2.pl> <17946.13311.501965.898973@cerise.gclements.plus.com> <461A5C26.6030408@o2.pl> Message-ID: <17946.31733.916667.550826@cerise.gclements.plus.com> Maciej Sieczka wrote: > >> By "boundary case", do you mean to assume that v.in.region+d.vect is > >> unlikely to be used? Just curios. > > > No, I mean that it's a case where a "point" is neither inside nor > > outside but on the boundary. > > > > The term doesn't refer solely to geometry. In any context where some > > continuous (non-discrete) space is partitioned into distinct > > categories, you get values which fall on the boundary between > > categories. E.g. if you partition the real numbers into positive and > > negative, which is zero? > > As to display, I guess I get it know. However, I'm not sure what to > think about this issue in regard to computational GRASS region. > > Let's take a following eaxample; in spearfish: > > $ g.region rast=landuse -a > $ v.in.region lu_border type=line > $ v.category lu_border out=lu_border_cat option=add > $ g.region vect=lu_border_cat > $ v.to.rast input=lu_border_cat output=lu_border_cat use=cat > > The outcome is a raster which includes only the top and left lines, > while region was ordered to cover the whole "lu_border_cat" vector. > From user's point of view, half of the input vector was ignored by > v.to.rast, in error. Is this not fixable too? No. Exactly the same issues apply here. -- Glynn Clements From glynn at gclements.plus.com Mon Apr 9 19:53:18 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Apr 9 19:53:22 2007 Subject: [GRASS-dev] return of the OSX xterm question In-Reply-To: <8B39095B-A69E-4832-86BC-36376FBA8C4B@kyngchaos.com> References: <067285F7-8D2C-4DF3-8D92-C13EE4BB8171@kyngchaos.com> <17945.33292.321787.446725@cerise.gclements.plus.com> <17945.65471.418796.321712@cerise.gclements.plus.com> <95656C5F-51A6-4A47-A8D2-65941C4332FE@kyngchaos.com> <17946.22865.94012.39668@cerise.gclements.plus.com> <8B39095B-A69E-4832-86BC-36376FBA8C4B@kyngchaos.com> Message-ID: <17946.32142.513048.993941@cerise.gclements.plus.com> William Kyngesburye wrote: > >> But mainly, I can't understand how the xterm compatibility part would > >> work: to be able to handle the xterm flags, it has to be able to run > >> from the CLI, but when run from the CLI an application executable > >> opens a completely new instance of the whole application, not a new > >> window (exactly the same problem as the browser issue I'm working > >> on). > > > > And what's the problem with that? > > > > I can see why this might be a problem for a browser; I don't see why > > it's a problem for a terminal. > > It's a general OSX problem/quirk when running any .app application > from the CLI. If the application is already running, you don't get a > new window in the application (or whatever the default action is, > depending on what is passed to it). New instances of whole > applications is not the way to run OSX apps. > > Instead, you must tell the system to open a file with a particular > application (the 'open' CLI command) so the system can take care of > deciding whether the application is already running. That doesn't address my point. What is the problem with having each terminal window belong to a separate process? Or, from a different perspective, what is the advantage to having a single process manage multiple terminal windows? I can see some advantages for a browser, but not for a terminal. -- Glynn Clements From woklist at kyngchaos.com Mon Apr 9 20:58:38 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Mon Apr 9 20:58:53 2007 Subject: [GRASS-dev] return of the OSX xterm question In-Reply-To: <17946.32142.513048.993941@cerise.gclements.plus.com> References: <067285F7-8D2C-4DF3-8D92-C13EE4BB8171@kyngchaos.com> <17945.33292.321787.446725@cerise.gclements.plus.com> <17945.65471.418796.321712@cerise.gclements.plus.com> <95656C5F-51A6-4A47-A8D2-65941C4332FE@kyngchaos.com> <17946.22865.94012.39668@cerise.gclements.plus.com> <8B39095B-A69E-4832-86BC-36376FBA8C4B@kyngchaos.com> <17946.32142.513048.993941@cerise.gclements.plus.com> Message-ID: <9254F61B-1A9C-42C0-BADE-17E7D1D826F9@kyngchaos.com> On Apr 9, 2007, at 12:53 PM, Glynn Clements wrote: >> It's a general OSX problem/quirk when running any .app application >> from the CLI. If the application is already running, you don't get a >> new window in the application (or whatever the default action is, >> depending on what is passed to it). New instances of whole >> applications is not the way to run OSX apps. >> >> Instead, you must tell the system to open a file with a particular >> application (the 'open' CLI command) so the system can take care of >> deciding whether the application is already running. > > That doesn't address my point. > > What is the problem with having each terminal window belong to a > separate process? Or, from a different perspective, what is the > advantage to having a single process manage multiple terminal windows? > > I can see some advantages for a browser, but not for a terminal. > Hmm. Sorry to beat this so much... The basic OSX answer is that a single process (for an application) is the way OSX works. Though commands that are run in a Terminal window spawn their own processes. One practical answer is that each application process (but not spawned CLI processes) shows up in the OSX Dock. All have only the name of the application, ie "Terminal". ----- William Kyngesburye http://www.kyngchaos.com/ "We are at war with them. Neither in hatred nor revenge and with no particular pleasure I shall kill every ___ I can until the war is over. That is my duty." "Don't you even hate 'em?" "What good would it do if I did? If all the many millions of people of the allied nations devoted an entire year exclusively to hating the ____ it wouldn't kill one ___ nor shorten the war one day." "And it might give 'em all stomach ulcers." - Tarzan, on war From gnelson at uiuc.edu Tue Apr 10 00:16:47 2007 From: gnelson at uiuc.edu (Jerry Nelson) Date: Tue Apr 10 00:17:04 2007 Subject: [GRASS-dev] terracost and large files more generally In-Reply-To: <17943.45430.574853.795059@cerise.gclements.plus.com> References: <20070407081339.ANU03132@expms1.cites.uiuc.edu> <17943.45430.574853.795059@cerise.gclements.plus.com> Message-ID: <009901c77af4$c401a700$3e40ae80@ace.uiuc.edu> Thanks for this! I downloaded and recompiled (after a make clean) and it seems to have worked fine. I also needed this for r.in.arc. I put the code modifications you made into that make file and it also seems to have worked fine. I was wondering whether you (plural, ie someone on the development team) could drop those three lines of code into all the related routines. I would think they are r.out.arc r.in.arc r.out.ascii r.in.ascii others? Thanks, Jerry -----Original Message----- From: Glynn Clements [mailto:glynn@gclements.plus.com] Sent: Saturday, April 07, 2007 9:58 AM To: Gerald Nelson Cc: grass-dev@grass.itc.it Subject: Re: [GRASS-dev] terracost and large files more generally Gerald Nelson wrote: > - file size limitations issues. I'm bumping up against a 2 gb limit in > r.out.arc. We're using grass6.3, compiled with large file support and > we can't export files that would be larger than 2 gb. My postdoc (who > knows java but not C) and I looked at the source code for r.out.arc > and couldn't see any obvious reason why there would be a size limit. The --enable-largefile configure option only enables LFS on code which specifically chooses to use it. As r.out.arc only performs sequential output, it's safe to enable LFS, so I've modified the Makefile to enable it. -- Glynn Clements From glynn at gclements.plus.com Tue Apr 10 01:01:38 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Apr 10 01:01:40 2007 Subject: [GRASS-dev] terracost and large files more generally In-Reply-To: <009901c77af4$c401a700$3e40ae80@ace.uiuc.edu> References: <20070407081339.ANU03132@expms1.cites.uiuc.edu> <17943.45430.574853.795059@cerise.gclements.plus.com> <009901c77af4$c401a700$3e40ae80@ace.uiuc.edu> Message-ID: <17946.50642.570923.142743@cerise.gclements.plus.com> Jerry Nelson wrote: > Thanks for this! I downloaded and recompiled (after a make clean) and it > seems to have worked fine. I also needed this for r.in.arc. I put the code > modifications you made into that make file and it also seems to have worked > fine. I was wondering whether you (plural, ie someone on the development > team) could drop those three lines of code into all the related routines. I > would think they are > > r.out.arc > r.in.arc > r.out.ascii > r.in.ascii Those all seem to be okay. The r.out.* programs don't use file positioning at all, r.in.arc uses fseek() with a zero offset, and r.in.ascii always uses reasonably small offsets (either relative seeks of one or two rows of data or absolute seeks near the beginning of the file). I've committed the changes to CVS. -- Glynn Clements From mlennert at club.worldonline.be Tue Apr 10 11:08:28 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Tue Apr 10 11:05:23 2007 Subject: FW: [GRASS-dev] wingrass binaries available [was: Re: [winGRASS] Updating CVS] In-Reply-To: References: Message-ID: <461B540C.5090003@club.worldonline.be> On 03/04/07 20:49, Michael Barton wrote: > Moritz, > > This site has been unavailable since I got your message last night. Perhaps > because of undue popularity?? ;-) No, the problem was that I had left on vacation, but we had a power cut at the office, so my machine was left shut off. Now it is available again. I would really appreciate someone testing these and tell me whether I did things correctly and they work... Two things I probably need to add: - We do need a shell for some commands, so I think that at this stage msys is a requirement. (Paul ?) - I can provide the database drivers (postgres, sqlite) if someone tells me how to compile them separately. Do I have to rerun configure and then make in the individual directories ? Moritz From paul-grass at stjohnspoint.co.uk Tue Apr 10 11:33:51 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Tue Apr 10 11:34:01 2007 Subject: FW: [GRASS-dev] wingrass binaries available [was: Re: [winGRASS] Updating CVS] In-Reply-To: <461B540C.5090003@club.worldonline.be> References: <461B540C.5090003@club.worldonline.be> Message-ID: Hello Moritz On Tue, 10 Apr 2007, Moritz Lennert wrote: > On 03/04/07 20:49, Michael Barton wrote: >> Moritz, >> >> This site has been unavailable since I got your message last night. Perhaps >> because of undue popularity?? > > ;-) > > No, the problem was that I had left on vacation, but we had a power cut at > the office, so my machine was left shut off. > > Now it is available again. > > I would really appreciate someone testing these and tell me whether I did > things correctly and they work... Sorry still have not had time yet... > Two things I probably need to add: > > - We do need a shell for some commands, so I think that at this stage msys is > a requirement. (Paul ?) Yes, although there is a *lot* you can do without using shell scripts, and a shell is not needed for any of the GRASS start-up or module-running infrastructure any more, only for modules that actually are shell scripts. Also we need to investigate the possibility of using non-Msys shells (e.g. the one that comes with Windows services for Unix???) and the fact that Msys still needs the path set to find its utilities and things like that. A way to go on this one. P.S. attached are a couple of patches to the current CVS to fix compilation of libraster and r.mapcalc on Windows. I don't have convenient CVS access right now to apply them... Paul -------------- next part -------------- Index: lib/raster/com_io.c =================================================================== RCS file: /home/grass/grassrepository/grass6/lib/raster/com_io.c,v retrieving revision 2.15 diff -u -r2.15 com_io.c --- lib/raster/com_io.c 7 Apr 2007 10:15:02 -0000 2.15 +++ lib/raster/com_io.c 10 Apr 2007 09:28:15 -0000 @@ -144,7 +144,7 @@ #ifndef HAVE_SOCKET return &loc_trans; -#endif +#else if (!p) return &rem_trans; @@ -164,6 +164,7 @@ G_warning("Unrecognised GRASS_RENDER_IMMEDIATE setting: %s", p); return &rem_trans; +#endif } static void init_transport(void) Index: raster/r.mapcalc/evaluate.c =================================================================== RCS file: /home/grass/grassrepository/grass6/raster/r.mapcalc/evaluate.c,v retrieving revision 2.4 diff -u -r2.4 evaluate.c --- raster/r.mapcalc/evaluate.c 3 Apr 2007 02:48:33 -0000 2.4 +++ raster/r.mapcalc/evaluate.c 10 Apr 2007 09:28:15 -0000 @@ -231,7 +231,7 @@ #if defined(HAVE_DRAND48) srand48(seed_value); #else - srand((unsigned int) seed_value) + srand((unsigned int) seed_value); #endif } From neteler at itc.it Tue Apr 10 12:17:05 2007 From: neteler at itc.it (Markus Neteler) Date: Tue Apr 10 12:17:06 2007 Subject: [GRASS-dev] Scripts now write command history Message-ID: <20070410101703.GC2178@bartok.itc.it> Hi, I have added support to write command history to all relevant scripts in scripts/. with v.info -h map or r.info -h map you can now retrieve the map history even if it was generated by an official GRASS script. Please watch out for bugs introduced (but I think that this change is pretty non-invasive). Markus From glynn at gclements.plus.com Tue Apr 10 12:29:40 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Apr 10 12:29:48 2007 Subject: [GRASS-user] Re: FW: [GRASS-dev] wingrass binaries available [was: Re: [winGRASS] Updating CVS] In-Reply-To: <461B540C.5090003@club.worldonline.be> References: <461B540C.5090003@club.worldonline.be> Message-ID: <17947.26388.825414.958667@cerise.gclements.plus.com> Moritz Lennert wrote: > - I can provide the database drivers (postgres, sqlite) if someone tells > me how to compile them separately. Do I have to rerun configure and then > make in the individual directories ? Yes. For future builds, you can enable whichever database options are supported on the build system. There is no longer any reason to disable the database options when building GRASS (at one time, using --with-postgres resulted in an NVIZ binary which wouldn't run without it, but that's no longer the case). However, if you're using a shared GDAL library, you might want to manually edit the GDALLIBS definition in Platform.make to remove its dependencies, as those will be propagated to any executables which use it. [If you aren't using a shared GDAL library, or if you're including the GDAL library in the GRASS package, you'll need to give some consideration as to which formats are supported.] -- Glynn Clements From glynn at gclements.plus.com Tue Apr 10 13:15:13 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Apr 10 13:15:19 2007 Subject: FW: [GRASS-dev] wingrass binaries available [was: Re: [winGRASS] Updating CVS] In-Reply-To: References: <461B540C.5090003@club.worldonline.be> Message-ID: <17947.29121.55092.347271@cerise.gclements.plus.com> Paul Kelly wrote: > P.S. attached are a couple of patches to the current CVS to fix > compilation of libraster and r.mapcalc on Windows. I don't have convenient > CVS access right now to apply them... Committed. -- Glynn Clements From michael.barton at asu.edu Tue Apr 10 21:40:18 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Apr 10 21:40:24 2007 Subject: [GRASS-dev] update on wxPython GUI for GRASS Message-ID: I just wanted to update everyone on the list. The development of the wxPython next generation GUI for GRASS has been moving at a very fast pace. It now has much of the functionality of the current TclTk GUI, though it is not yet as robust and will certainly be more buggy. All GRASS command and normal scripts are available?either through the menus (though these are still not complete) or the GIS Manager command line. The GIS Manager layer tree work well, has groups, transparency, drag and drop, and layers for all major GRASS GIS data types. There is the potential for multiple map displays, controlled by a single GIS Manager panel, as we have now. But it?s a bit nicer and more modern looking. The map displays have basic zooming, panning, querying, and saving to PNG. Map decorations (scales, legends, and text) are more easily placed and edited than in the current TclTk GUI. The autogenerated dialogs for each GRASS command have a very nice layout and appearance. There is a good beginning on an integrated attribute table editor. There is also a good beginning on a location creation wizard. We just need a non-interactive version of g.setproj ;-) or the ability to send g.setproj data (extents, resolution, and grass dataum and transformation names) to g.proj. Major missing pieces are: special GUI versions of interactive x11 modules (i.e., georectification and profiling) and NVIZ. Direct printing does not work yet. If you are interested in testing, the GUI files can be found at Python 2.4 and above and wxPython 2.8 and above are required. Enjoy Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070410/d97b4b52/attachment-0001.html From michael.barton at asu.edu Wed Apr 11 01:15:58 2007 From: michael.barton at asu.edu (Michael Barton) Date: Wed Apr 11 01:16:04 2007 Subject: [GRASS-dev] problem with r.colors on Mac Message-ID: I just have been having problems with r.colors on the Mac. This is from cvs source code I downloaded and compiled today. r.colors will crash the GUI when I run it with either grey.eq or grey.log as the color map. It seems to calculate the equalization stretch OK with grey.eq, though, in spite of crashing. r.colors gives me a blank (i.e. white) image if I use grey.log. I list the color table below. As you can see, it?s just white. color table from grey.log % 43844 43964 nv:255 43844:254 43963:254 43964:255 43964:255 Any thoughts? Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070410/d8be8ca6/attachment.html From michael.barton at asu.edu Wed Apr 11 02:09:15 2007 From: michael.barton at asu.edu (Michael Barton) Date: Wed Apr 11 02:09:30 2007 Subject: [GRASS-dev] request to change init.sh Message-ID: I?d like to know if anyone has any objections to me or Jachym editing init.sh so that it will work with the new wxPython GUI? This should not have any effect on normal operation. It will only launch the wxPython GUI if you manually change your .grassrc6 to GRASS_GUI: wx (and of course if you have the wxPython Gui and wxPython installed). If anyone would like to look at it beforehand, it is in the wxgrass distribution in the grass svn repository that I mentioned in my last post. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070410/2476f939/attachment.html From woklist at kyngchaos.com Wed Apr 11 02:46:31 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Wed Apr 11 02:46:48 2007 Subject: [GRASS-dev] request to change init.sh In-Reply-To: References: Message-ID: <069702D7-0F03-4B35-8C01-9E24467E562F@kyngchaos.com> That would be nice to make it easier to try the new GUI. Just make sure to start with a recent version of init.sh. Hamish and I made a few changes in the past couple weeks, and I see your GUI copy is older. On Apr 10, 2007, at 7:09 PM, Michael Barton wrote: > I?d like to know if anyone has any objections to me or Jachym > editing init.sh so that it will work with the new wxPython GUI? > This should not have any effect on normal operation. It will only > launch the wxPython GUI if you manually change your .grassrc6 to > GRASS_GUI: wx (and of course if you have the wxPython Gui and > wxPython installed). If anyone would like to look at it beforehand, > it is in the wxgrass distribution in the grass svn repository that > I mentioned in my last post. > > Michael ----- William Kyngesburye http://www.kyngchaos.com/ "I ache, therefore I am. Or in my case - I am, therefore I ache." - Marvin From glynn at gclements.plus.com Wed Apr 11 04:04:03 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Apr 11 04:04:24 2007 Subject: [GRASS-dev] problem with r.colors on Mac In-Reply-To: References: Message-ID: <17948.16915.391634.256480@cerise.gclements.plus.com> Michael Barton wrote: > I just have been having problems with r.colors on the Mac. This is from cvs > source code I downloaded and compiled today. > > r.colors will crash the GUI when I run it with either grey.eq or grey.log as > the color map. It seems to calculate the equalization stretch OK with > grey.eq, though, in spite of crashing. My guess is the gronsole code. Running r.colors from the command line with GRASS_MESSAGE_FORMAT=gui doesn't show anything unusual. As I've mentioned before, the use of "read" with non-blocking I/O is likely to be problematic if the program generates output quickly. If there's a problem here, r.colors is a good candidate to trigger it as it will generate percentage output relatively fast. > r.colors gives me a blank (i.e. white) image if I use grey.log. I list the > color table below. As you can see, it?s just white. > > color table from grey.log > > % 43844 43964 > nv:255 > 43844:254 43963:254 > 43964:255 43964:255 This is expected behaviour; grey.log maps a value of x to 255*log(x)/log(max); the minimum value is ignored. IOW, it *doesn't* map the minimum value to black, it maps 1 to black (log(1) == 0). I don't know whether this is a good idea, but it is how grey.log has always behaved. -- Glynn Clements From michael.barton at asu.edu Wed Apr 11 06:13:54 2007 From: michael.barton at asu.edu (Michael Barton) Date: Wed Apr 11 06:14:15 2007 Subject: [GRASS-dev] problem with r.colors on Mac In-Reply-To: <17948.16915.391634.256480@cerise.gclements.plus.com> Message-ID: On 4/10/07 7:04 PM, "Glynn Clements" wrote: > > Michael Barton wrote: > >> I just have been having problems with r.colors on the Mac. This is from cvs >> source code I downloaded and compiled today. >> >> r.colors will crash the GUI when I run it with either grey.eq or grey.log as >> the color map. It seems to calculate the equalization stretch OK with >> grey.eq, though, in spite of crashing. > > My guess is the gronsole code. Running r.colors from the command line > with GRASS_MESSAGE_FORMAT=gui doesn't show anything unusual. > > As I've mentioned before, the use of "read" with non-blocking I/O is > likely to be problematic if the program generates output quickly. If > there's a problem here, r.colors is a good candidate to trigger it as > it will generate percentage output relatively fast. This hasn't happened before for me with r.colors. Other things that run faster haven't given me problems before, though this has happened with v.to.rast. Your explanation may well be the correct one. But I wonder why it is a problem now and not previously (i.e., a month ago). If read is a problem, what is an alternative? I don't understand the gronsole code very well (didn't write it), but I might be able to fix a specific issue like this. > >> r.colors gives me a blank (i.e. white) image if I use grey.log. I list the >> color table below. As you can see, it?s just white. >> >> color table from grey.log >> >> % 43844 43964 >> nv:255 >> 43844:254 43963:254 >> 43964:255 43964:255 > > This is expected behaviour; grey.log maps a value of x to > 255*log(x)/log(max); the minimum value is ignored. IOW, it *doesn't* > map the minimum value to black, it maps 1 to black (log(1) == 0). > > I don't know whether this is a good idea, but it is how grey.log has > always behaved. I had thought that grey.log was a histogram stretch like grey.eq. In the docs, it is called "histogram logarithmic transformed grey scale". In that sense, it seems like it should set the minimum value to black rather than 1. Thanks for the explanation. Would it be difficult to change this to stretch the image histogram rather than values of 1 to n? Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Wed Apr 11 06:17:15 2007 From: michael.barton at asu.edu (Michael Barton) Date: Wed Apr 11 06:17:43 2007 Subject: [GRASS-dev] request to change init.sh In-Reply-To: <069702D7-0F03-4B35-8C01-9E24467E562F@kyngchaos.com> Message-ID: I figured the best thing would be to just alter the newest one if everyone agrees. The one thing that may be missing is some kind of error check to see if Python is installed--like for TclTk. Michael On 4/10/07 5:46 PM, "William Kyngesburye" wrote: > That would be nice to make it easier to try the new GUI. > > Just make sure to start with a recent version of init.sh. Hamish and > I made a few changes in the past couple weeks, and I see your GUI > copy is older. > > On Apr 10, 2007, at 7:09 PM, Michael Barton wrote: > >> I?d like to know if anyone has any objections to me or Jachym >> editing init.sh so that it will work with the new wxPython GUI? >> This should not have any effect on normal operation. It will only >> launch the wxPython GUI if you manually change your .grassrc6 to >> GRASS_GUI: wx (and of course if you have the wxPython Gui and >> wxPython installed). If anyone would like to look at it beforehand, >> it is in the wxgrass distribution in the grass svn repository that >> I mentioned in my last post. >> >> Michael > > ----- > William Kyngesburye > http://www.kyngchaos.com/ > > "I ache, therefore I am. Or in my case - I am, therefore I ache." > > - Marvin > > __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From cavallini at faunalia.it Wed Apr 11 07:48:10 2007 From: cavallini at faunalia.it (Paolo Cavallini) Date: Wed Apr 11 07:48:25 2007 Subject: [GRASS-dev] update on wxPython GUI for GRASS In-Reply-To: References: Message-ID: <461C769A.7070902@faunalia.it> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Great news, thanks. Two issues: - - I would add r.li to the list of missing pieces - - would it be possible to move all of grass to svn, so compiling with the new gui will be easier? How long will this (presumably) take? All the best. pc Michael Barton ha scritto: > I just wanted to update everyone on the list. The development of the > wxPython next generation GUI for GRASS has been moving at a very fast > pace. It now has much of the functionality of the current TclTk GUI, > though it is not yet as robust and will certainly be more buggy. ... > Major missing pieces are: special GUI versions of interactive x11 > modules (i.e., georectification and profiling) and NVIZ. Direct printing > does not work yet. > > If you are interested in testing, the GUI files can be found at > > > > Python 2.4 and above and wxPython 2.8 and above are required. > > Enjoy > Michael - -- Paolo Cavallini http://www.faunalia.it/pc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGHHaa/NedwLUzIr4RAoxvAJ9A6rSSr5v7NtWu4GmH2ZWjWLEbjwCfa12j 4j11zSUG78xq/HzAr1OUvWM= =eJGK -----END PGP SIGNATURE----- From michael.barton at asu.edu Wed Apr 11 09:37:41 2007 From: michael.barton at asu.edu (Michael Barton) Date: Wed Apr 11 09:41:08 2007 Subject: [GRASS-dev] update on wxPython GUI for GRASS In-Reply-To: <461C769A.7070902@faunalia.it> Message-ID: Yes. The r.li TclTk dialog needs to be recreated in wxPython. It looks like it will be fairly easy to do, but I haven't looked at the code in much detail. Need to ask Markus about the move to the svn. Michael On 4/10/07 10:48 PM, "Paolo Cavallini" wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Great news, thanks. > Two issues: > - - I would add r.li to the list of missing pieces > - - would it be possible to move all of grass to svn, so compiling with > the new gui will be easier? How long will this (presumably) take? > All the best. > pc > > Michael Barton ha scritto: >> I just wanted to update everyone on the list. The development of the >> wxPython next generation GUI for GRASS has been moving at a very fast >> pace. It now has much of the functionality of the current TclTk GUI, >> though it is not yet as robust and will certainly be more buggy. > ... >> Major missing pieces are: special GUI versions of interactive x11 >> modules (i.e., georectification and profiling) and NVIZ. Direct printing >> does not work yet. >> >> If you are interested in testing, the GUI files can be found at >> >> > addons_> >> >> Python 2.4 and above and wxPython 2.8 and above are required. >> >> Enjoy >> Michael > - -- > Paolo Cavallini > http://www.faunalia.it/pc > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFGHHaa/NedwLUzIr4RAoxvAJ9A6rSSr5v7NtWu4GmH2ZWjWLEbjwCfa12j > 4j11zSUG78xq/HzAr1OUvWM= > =eJGK > -----END PGP SIGNATURE----- __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From glynn at gclements.plus.com Wed Apr 11 12:42:57 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Apr 11 12:43:03 2007 Subject: [GRASS-dev] problem with r.colors on Mac In-Reply-To: References: <17948.16915.391634.256480@cerise.gclements.plus.com> Message-ID: <17948.48049.681105.666051@cerise.gclements.plus.com> Michael Barton wrote: > >> I just have been having problems with r.colors on the Mac. This is from cvs > >> source code I downloaded and compiled today. > >> > >> r.colors will crash the GUI when I run it with either grey.eq or grey.log as > >> the color map. It seems to calculate the equalization stretch OK with > >> grey.eq, though, in spite of crashing. > > > > My guess is the gronsole code. Running r.colors from the command line > > with GRASS_MESSAGE_FORMAT=gui doesn't show anything unusual. > > > > As I've mentioned before, the use of "read" with non-blocking I/O is > > likely to be problematic if the program generates output quickly. If > > there's a problem here, r.colors is a good candidate to trigger it as > > it will generate percentage output relatively fast. > > This hasn't happened before for me with r.colors. Other things that run > faster haven't given me problems before, though this has happened with > v.to.rast. Your explanation may well be the correct one. But I wonder why it > is a problem now and not previously (i.e., a month ago). > > If read is a problem, what is an alternative? gets. Gronsole::output_to_gronsole is written on the assumption that it will get complete lines. Gronsole::readout tries to do this, but fails to allow for the fact that "read" may return arbitrary chunks of data (i.e. partial lines). If the stream is in non-blocking mode, gets will return an empty string if a complete line isn't available. The fblocked function can be used to distinguish this from the case where the process wrote a blank line. Also, after this case occurs, another readable event won't be generated for the stream until a complete line is available. > I don't understand the > gronsole code very well (didn't write it), but I might be able to fix a > specific issue like this. Gronsole::readout is the relevant function. > >> r.colors gives me a blank (i.e. white) image if I use grey.log. I list the > >> color table below. As you can see, it?s just white. > >> > >> color table from grey.log > >> > >> % 43844 43964 > >> nv:255 > >> 43844:254 43963:254 > >> 43964:255 43964:255 > > > > This is expected behaviour; grey.log maps a value of x to > > 255*log(x)/log(max); the minimum value is ignored. IOW, it *doesn't* > > map the minimum value to black, it maps 1 to black (log(1) == 0). > > > > I don't know whether this is a good idea, but it is how grey.log has > > always behaved. > > I had thought that grey.log was a histogram stretch like grey.eq. In the > docs, it is called "histogram logarithmic transformed grey scale". In that > sense, it seems like it should set the minimum value to black rather than 1. > Thanks for the explanation. Would it be difficult to change this to stretch > the image histogram rather than values of 1 to n? It wouldn't be hard to change it to map log(min) to black. I'm not so sure about the histogram equalisation part. The main issue is whether someone might be relying upon the existing behaviour. Beyond that, it would be nice to be able to apply histogram equalisation and/or logarithmic scaling to any colour table, rather than just grey. The existence of grey.log and grey.eq is the main reason that r.colors still has separate color= and rules= options, as those two cannot be implemented using rules files. -- Glynn Clements From neteler at itc.it Wed Apr 11 13:43:49 2007 From: neteler at itc.it (Markus Neteler) Date: Wed Apr 11 13:43:51 2007 Subject: [GRASS-dev] problem with r.colors on Mac In-Reply-To: <17948.48049.681105.666051@cerise.gclements.plus.com> References: <17948.16915.391634.256480@cerise.gclements.plus.com> <17948.48049.681105.666051@cerise.gclements.plus.com> Message-ID: <20070411114349.GB13640@bartok.itc.it> On Wed, Apr 11, 2007 at 11:42:57AM +0100, Glynn Clements wrote: > Michael Barton wrote: > > >> r.colors gives me a blank (i.e. white) image if I use grey.log. I list the > > >> color table below. As you can see, it?s just white. > > >> > > >> color table from grey.log > > >> > > >> % 43844 43964 > > >> nv:255 > > >> 43844:254 43963:254 > > >> 43964:255 43964:255 > > > > > > This is expected behaviour; grey.log maps a value of x to > > > 255*log(x)/log(max); the minimum value is ignored. IOW, it *doesn't* > > > map the minimum value to black, it maps 1 to black (log(1) == 0). > > > > > > I don't know whether this is a good idea, but it is how grey.log has > > > always behaved. > > > > I had thought that grey.log was a histogram stretch like grey.eq. In the > > docs, it is called "histogram logarithmic transformed grey scale". In that > > sense, it seems like it should set the minimum value to black rather than 1. > > Thanks for the explanation. Would it be difficult to change this to stretch > > the image histogram rather than values of 1 to n? > > It wouldn't be hard to change it to map log(min) to black. I'm not so > sure about the histogram equalisation part. > > The main issue is whether someone might be relying upon the existing > behaviour. Maybe not too much since it is "only" a color table. > Beyond that, it would be nice to be able to apply histogram > equalisation and/or logarithmic scaling to any colour table, rather > than just grey. Absolutely. A long standing wish... > The existence of grey.log and grey.eq is the main reason that r.colors > still has separate color= and rules= options, as those two cannot be > implemented using rules files. A simplification would be appreciated, but moreover support for FP map histogram equalisation etc. Markus From landa.martin at gmail.com Wed Apr 11 15:07:21 2007 From: landa.martin at gmail.com (Martin Landa) Date: Wed Apr 11 15:07:25 2007 Subject: [GRASS-dev] message standardization on wiki Message-ID: Hi all, updating Czech translation of GRASS I am suggesting some of standard messages. There are lot of library functions which are very often used (e.g. G_find_cell2() or G_find_vector2()), but messages are *very* different, see http://grass.gdf-hannover.de/wiki/Development_Specs#Messages_Discussion Please feel free to extend the list of "standard messages", correct existing (cannot -> could not?, ...), etc. then I will be happy to change messages in GRASS code according this proposal. http://grass.gdf-hannover.de/wiki/Development_Specs#Standard_messages_sandbox also http://grass.gdf-hannover.de/wiki/Development_Specs#How_should_Errors.2FWarnings.2FMessages_be_formatted Not important, but really pain for GRASS translators... Martin -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From tutey at o2.pl Wed Apr 11 15:43:52 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Wed Apr 11 15:43:58 2007 Subject: [GRASS-dev] request to change init.sh In-Reply-To: References: Message-ID: <461CE618.8030601@o2.pl> Michael Barton wrote: > I^(1)d like to know if anyone has any objections to me or Jachym editing > init.sh so that it will work with the new wxPython GUI? As for 6.3 CVS, I think it's good idea. Maciek From gnelson at uiuc.edu Wed Apr 11 15:44:54 2007 From: gnelson at uiuc.edu (Gerald Nelson) Date: Wed Apr 11 15:44:58 2007 Subject: [GRASS-dev] message standardization on wiki Message-ID: <20070411084454.ANZ61728@expms1.cites.uiuc.edu> Can I suggest the following rules 1. First letter should be capitalized 2. Use present tense (cannot instead of could not) 3. No contractions (cannot instead of can't) 4. Good sentence construction ("Cannot find input map <%s>" instead of "It could not be find input map <%s>") 5. Be consistent with periods. Either end all phrases with a period or none. Regards, Jerry ---- Original message ---- >Date: Wed, 11 Apr 2007 15:07:21 +0200 >From: "Martin Landa" >Subject: [GRASS-dev] message standardization on wiki >To: grass-dev , translations@grass.itc.it > >Hi all, > >updating Czech translation of GRASS I am suggesting some of standard >messages. There are lot of library functions which are very often used >(e.g. G_find_cell2() or G_find_vector2()), but messages are *very* >different, see > >http://grass.gdf-hannover.de/wiki/Development_Specs#Messages_Discussion > >Please feel free to extend the list of "standard messages", correct >existing (cannot -> could not?, ...), etc. then I will be happy to >change messages in GRASS code according this proposal. > >http://grass.gdf-hannover.de/wiki/Development_Specs#Standard_messages_sandbox > >also > >http://grass.gdf-hannover.de/wiki/Development_Specs#How_should_Errors.2FWarnings.2FMessages_be_formatted > >Not important, but really pain for GRASS translators... > >Martin > >-- >Martin Landa * http://gama.fsv.cvut.cz/~landa * > >_______________________________________________ >grass-dev mailing list >grass-dev@grass.itc.it >http://grass.itc.it/mailman/listinfo/grass-dev Gerald Nelson Professor, Dept. of Agricultural and Consumer Economics University of Illinois, Urbana-Champaign office: 217-333-6465 cell: 217-390-7888 315 Mumford Hall 1301 W. Gregory Urbana, IL 61801 From gnelson at uiuc.edu Wed Apr 11 15:49:07 2007 From: gnelson at uiuc.edu (Gerald Nelson) Date: Wed Apr 11 15:49:11 2007 Subject: [GRASS-dev] message standardization on wiki Message-ID: <20070411084907.ANZ62381@expms1.cites.uiuc.edu> More controversially, it would be good if the error message was a. as descriptive as possible (Instead of just "Cannot read raster row [%d]" say "Cannot read raster row [%d]. End of file reached") b. followed by suggestions on how to fix the problem (End of file fixed. The file has x rows and y columns but you were trying to read row x+1.) Jerry ---- Original message ---- >Date: Wed, 11 Apr 2007 15:07:21 +0200 >From: "Martin Landa" >Subject: [GRASS-dev] message standardization on wiki >To: grass-dev , translations@grass.itc.it > >Hi all, > >updating Czech translation of GRASS I am suggesting some of standard >messages. There are lot of library functions which are very often used >(e.g. G_find_cell2() or G_find_vector2()), but messages are *very* >different, see > >http://grass.gdf-hannover.de/wiki/Development_Specs#Messages_Discussion > >Please feel free to extend the list of "standard messages", correct >existing (cannot -> could not?, ...), etc. then I will be happy to >change messages in GRASS code according this proposal. > >http://grass.gdf-hannover.de/wiki/Development_Specs#Standard_messages_sandbox > >also > >http://grass.gdf-hannover.de/wiki/Development_Specs#How_should_Errors.2FWarnings.2FMessages_be_formatted > >Not important, but really pain for GRASS translators... > >Martin > >-- >Martin Landa * http://gama.fsv.cvut.cz/~landa * > >_______________________________________________ >grass-dev mailing list >grass-dev@grass.itc.it >http://grass.itc.it/mailman/listinfo/grass-dev Gerald Nelson Professor, Dept. of Agricultural and Consumer Economics University of Illinois, Urbana-Champaign office: 217-333-6465 cell: 217-390-7888 315 Mumford Hall 1301 W. Gregory Urbana, IL 61801 From landa.martin at gmail.com Wed Apr 11 15:59:40 2007 From: landa.martin at gmail.com (Martin Landa) Date: Wed Apr 11 15:59:43 2007 Subject: [GRASS-dev] message standardization on wiki In-Reply-To: <20070411085654.ANZ63525@expms1.cites.uiuc.edu> References: <20070411085654.ANZ63525@expms1.cites.uiuc.edu> Message-ID: Hi, I have already updated the wiki page http://grass.gdf-hannover.de/wiki/Development_Specs#Standard_messages_sandbox Please feel free to add other suggestions... Thanks! Martin 2007/4/11, Gerald Nelson : > Does that mean I should do the editing or you already have? Jerry > > ---- Original message ---- > >Date: Wed, 11 Apr 2007 15:53:58 +0200 > >From: "Martin Landa" > >Subject: Re: [GRASS-dev] message standardization on wiki > >To: "Gerald Nelson" > > > >Hi, > > > >2007/4/11, Gerald Nelson : > >> Can I suggest the following rules > >> 1. First letter should be capitalized > >> 2. Use present tense (cannot instead of could not) > >> 3. No contractions (cannot instead of can't) > >> 4. Good sentence construction ("Cannot find input map <%s>" instead of "It could not be find input map <%s>") > >> 5. Be consistent with periods. Either end all phrases with a period or none. > > > >wiki page updated ... > > > >Martin > > > >> Regards, > >> > >> Jerry > >> > >> ---- Original message ---- > >> >Date: Wed, 11 Apr 2007 15:07:21 +0200 > >> >From: "Martin Landa" > >> >Subject: [GRASS-dev] message standardization on wiki > >> >To: grass-dev , translations@grass.itc.it > >> > > >> >Hi all, > >> > > >> >updating Czech translation of GRASS I am suggesting some of standard > >> >messages. There are lot of library functions which are very often used > >> >(e.g. G_find_cell2() or G_find_vector2()), but messages are *very* > >> >different, see > >> > > >> >http://grass.gdf-hannover.de/wiki/Development_Specs#Messages_Discussion > >> > > >> >Please feel free to extend the list of "standard messages", correct > >> >existing (cannot -> could not?, ...), etc. then I will be happy to > >> >change messages in GRASS code according this proposal. > >> > > >> >http://grass.gdf-hannover.de/wiki/Development_Specs#Standard_messages_sandbox > >> > > >> >also > >> > > >> >http://grass.gdf-hannover.de/wiki/Development_Specs#How_should_Errors.2FWarnings.2FMessages_be_formatted > >> > > >> >Not important, but really pain for GRASS translators... > >> > > >> >Martin > >> > > >> >-- > >> >Martin Landa * http://gama.fsv.cvut.cz/~landa * > >> > > >> >_______________________________________________ > >> >grass-dev mailing list > >> >grass-dev@grass.itc.it > >> >http://grass.itc.it/mailman/listinfo/grass-dev > >> Gerald Nelson > >> Professor, Dept. of Agricultural and Consumer Economics > >> University of Illinois, Urbana-Champaign > >> office: 217-333-6465 > >> cell: 217-390-7888 > >> 315 Mumford Hall > >> 1301 W. Gregory > >> Urbana, IL 61801 > >> > > > > > >-- > >Martin Landa * http://gama.fsv.cvut.cz/~landa * > Gerald Nelson > Professor, Dept. of Agricultural and Consumer Economics > University of Illinois, Urbana-Champaign > office: 217-333-6465 > cell: 217-390-7888 > 315 Mumford Hall > 1301 W. Gregory > Urbana, IL 61801 > -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From mlennert at club.worldonline.be Wed Apr 11 17:25:24 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Wed Apr 11 17:22:18 2007 Subject: [GRASS-dev] Re: [GRASS-user] Views in pgSQL In-Reply-To: <461CCB20.2020704@amu.edu.pl> References: <20070411100756.GJ7680@bartok.itc.it> <461CBFF0.7090602@amu.edu.pl> <461CC4B2.40203@club.worldonline.be> <461CCB20.2020704@amu.edu.pl> Message-ID: <461CFDE4.1070704@club.worldonline.be> On 11/04/07 13:48, Jaros?aw Jasiewicz wrote: > Moritz Lennert napisa?(a): >> On 11/04/07 13:01, Jaros?aw Jasiewicz wrote: >>> Hi >>> >>> Is still possible to use pgSQL views to connect vectors? >>> >>> Connecting views was possible for or five month ago (in spite of >>> error messages during creating views). >>> >>> I have some vector joinred to view They still working. But now, when >>> I tried to connect new vector with view I recived simple error >>> message that there is no table I plan to join >> >> What is the exact error message you are receiving. >> >> >>> >>> If that possibilites was removed (after my post, unfortunatly) please >>> let me know >> >> I am not aware of any related changes... Sorry, I spoke to fast. I think I now found the culprit: revision 1.40 date: 2006/11/28 08:42:02; author: markus; state: Exp; lines: +1 -1 if table doesn't exist: fatal error Before it was only a warning, not a fatal error, and so the connection was established and worked. This undoes what Radim did two years earlier: revision 1.24 date: 2004/11/25 13:15:47; author: radim; state: Exp; lines: +2 -2 error -> warning if table does not exist Markus, what was the reason that you changed this ? Either we have to revert this again, or we have to find a way to check for views as well as tables, which means either implementing db_view_exists() (with all the individual implementations, or just modify the list_tables functions of the individual drivers to include views. In the PostgreSQL driver, the statement used is ( ): "select * from pg_tables where tablename !~ 'pg_*' order by tablename" For views this would have to be something like: SELECT viewname FROM pg_views WHERE schemaname NOT IN ('pg_catalog','information_schema') AND viewname !~ '^pg_'; So the results of these two calls would have to be combined before db__driver_list_tables() returns the results. I don't know if there are any good reasons not to just include views into the list of tables... In the meantime, you can just modify v.db.connect at line 231 from G_fatal_error(_("Table <%s> does not exist in database <%s>"),dbtable->answer, dbdatabase->answer); to G_warning(_("Table <%s> does not exist in database <%s>"),dbtable->answer, dbdatabase->answer); > > BTW: > Pg Views are very important for me when I connect-reconnect vector files > to different atribute table. I use (used!) views insted of original > table to avoid occasional removing original data and to speed up > transfer limiting data in views only to these needed for > (sorry, I think everybody knows it) I completely agree with you. Being able to connect maps to views is fundamental in my eyes. Moritz From neteler at itc.it Wed Apr 11 17:37:15 2007 From: neteler at itc.it (Markus Neteler) Date: Wed Apr 11 17:37:17 2007 Subject: [GRASS-dev] Re: [GRASS-user] Views in pgSQL In-Reply-To: <461CFDE4.1070704@club.worldonline.be> References: <20070411100756.GJ7680@bartok.itc.it> <461CBFF0.7090602@amu.edu.pl> <461CC4B2.40203@club.worldonline.be> <461CCB20.2020704@amu.edu.pl> <461CFDE4.1070704@club.worldonline.be> Message-ID: <20070411153714.GB20701@bartok.itc.it> On Wed, Apr 11, 2007 at 05:25:24PM +0200, Moritz Lennert wrote: > On 11/04/07 13:48, Jaros??aw Jasiewicz wrote: > >Moritz Lennert napisa??(a): > >>On 11/04/07 13:01, Jaros??aw Jasiewicz wrote: > >>>Hi > >>> > >>>Is still possible to use pgSQL views to connect vectors? > >>> > >>>Connecting views was possible for or five month ago (in spite of > >>>error messages during creating views). > >>> > >>>I have some vector joinred to view They still working. But now, when > >>>I tried to connect new vector with view I recived simple error > >>>message that there is no table I plan to join > >> > >>What is the exact error message you are receiving. > >> > >> > >>> > >>>If that possibilites was removed (after my post, unfortunatly) please > >>>let me know > >> > >>I am not aware of any related changes... > > > Sorry, I spoke to fast. I think I now found the culprit: > > revision 1.40 > date: 2006/11/28 08:42:02; author: markus; state: Exp; lines: +1 -1 > if table doesn't exist: fatal error Which file is that? Ah, below I see that you mean v.db.connect/main.c. > Before it was only a warning, not a fatal error, and so the connection > was established and worked. > > This undoes what Radim did two years earlier: > > revision 1.24 > date: 2004/11/25 13:15:47; author: radim; state: Exp; lines: +2 -2 > error -> warning if table does not exist > > Markus, what was the reason that you changed this ? I don't really remember but I think that it broke scripts which use v.db.connect. At least: if the source code doesn't contain a comment to keep special tricks it's likely that they get lost. > Either we have to revert this again, or we have to find a way to check > for views as well as tables, which means either implementing > db_view_exists() (with all the individual implementations, or just > modify the list_tables functions of the individual drivers to include > views. In the PostgreSQL driver, the statement used is ( ): > > "select * from pg_tables where tablename !~ 'pg_*' order by tablename" > > For views this would have to be something like: > > SELECT viewname FROM pg_views WHERE schemaname NOT IN > ('pg_catalog','information_schema') AND viewname !~ '^pg_'; > > So the results of these two calls would have to be combined before > db__driver_list_tables() returns the results. > > I don't know if there are any good reasons not to just include views > into the list of tables... I have no suggestion here how to solve the problem. But yes, views should be visible somehow. > In the meantime, you can just modify v.db.connect at line 231 from > > G_fatal_error(_("Table <%s> does not exist in database > <%s>"),dbtable->answer, dbdatabase->answer); > > to > > G_warning(_("Table <%s> does not exist in database > <%s>"),dbtable->answer, dbdatabase->answer); > > > > > >BTW: > >Pg Views are very important for me when I connect-reconnect vector files > >to different atribute table. I use (used!) views insted of original > >table to avoid occasional removing original data and to speed up > >transfer limiting data in views only to these needed for > >(sorry, I think everybody knows it) > > I completely agree with you. Being able to connect maps to views is > fundamental in my eyes. Yes. But we need a reasonable implementation. Anyone with suggestions how to implement it? Markus From mlennert at club.worldonline.be Wed Apr 11 18:15:20 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Wed Apr 11 18:12:13 2007 Subject: [GRASS-dev] Re: [GRASS-user] Views in pgSQL In-Reply-To: <20070411153714.GB20701@bartok.itc.it> References: <20070411100756.GJ7680@bartok.itc.it> <461CBFF0.7090602@amu.edu.pl> <461CC4B2.40203@club.worldonline.be> <461CCB20.2020704@amu.edu.pl> <461CFDE4.1070704@club.worldonline.be> <20070411153714.GB20701@bartok.itc.it> Message-ID: <461D0998.1060903@club.worldonline.be> On 11/04/07 17:37, Markus Neteler wrote: > On Wed, Apr 11, 2007 at 05:25:24PM +0200, Moritz Lennert wrote: >> On 11/04/07 13:48, Jaros??aw Jasiewicz wrote: >>> Moritz Lennert napisa??(a): >>>> On 11/04/07 13:01, Jaros??aw Jasiewicz wrote: >>>>> Hi >>>>> >>>>> Is still possible to use pgSQL views to connect vectors? >>>>> >>>>> Connecting views was possible for or five month ago (in spite of >>>>> error messages during creating views). >>>>> >>>>> I have some vector joinred to view They still working. But now, when >>>>> I tried to connect new vector with view I recived simple error >>>>> message that there is no table I plan to join >>>> What is the exact error message you are receiving. >>>> >>>> >>>>> If that possibilites was removed (after my post, unfortunatly) please >>>>> let me know >>>> I am not aware of any related changes... >> >> Sorry, I spoke to fast. I think I now found the culprit: >> >> revision 1.40 >> date: 2006/11/28 08:42:02; author: markus; state: Exp; lines: +1 -1 >> if table doesn't exist: fatal error > > Which file is that? > Ah, below I see that you mean v.db.connect/main.c. Yes, sorry. >>> BTW: >>> Pg Views are very important for me when I connect-reconnect vector files >>> to different atribute table. I use (used!) views insted of original >>> table to avoid occasional removing original data and to speed up >>> transfer limiting data in views only to these needed for >>> (sorry, I think everybody knows it) >> I completely agree with you. Being able to connect maps to views is >> fundamental in my eyes. > > Yes. But we need a reasonable implementation. > Anyone with suggestions how to implement it? For me the choice is either 1) to consider views as tables (and thus change the way the individual drivers list tables) or 2) to treat them as separate and change v.db.connect so that it checks for both. 1) seems much easier to implement, 2) seems cleaner in case we need to list tables only, not views, in other contexts than v.db.connect. Moritz From glynn at gclements.plus.com Wed Apr 11 18:24:17 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Apr 11 18:24:19 2007 Subject: [GRASS-dev] problem with r.colors on Mac In-Reply-To: <20070411114349.GB13640@bartok.itc.it> References: <17948.16915.391634.256480@cerise.gclements.plus.com> <17948.48049.681105.666051@cerise.gclements.plus.com> <20070411114349.GB13640@bartok.itc.it> Message-ID: <17949.2993.124827.851219@cerise.gclements.plus.com> Markus Neteler wrote: > > It wouldn't be hard to change it to map log(min) to black. I'm not so > > sure about the histogram equalisation part. > > > > The main issue is whether someone might be relying upon the existing > > behaviour. > > Maybe not too much since it is "only" a color table. I've fixed this. > > Beyond that, it would be nice to be able to apply histogram > > equalisation and/or logarithmic scaling to any colour table, rather > > than just grey. > > Absolutely. A long standing wish... I've added two new functions to libgis: int G_histogram_eq_colors(struct Colors *, struct Colors *, struct Cell_stats *); int G_log_colors(struct Colors *, struct Colors *, int); Eac function creates a new colour table from an existing colour table. In both cases, the new table covers the same range as the old table, but the mapping across the range is either equalised or logarithmically scaled. The next step is to add corresponding options to r.colors. Beyond that, I'd like to propose eliminating most of the individual G_make_*_colors() functions in favour of a general purpose function which takes the name of a rules file as an argument. -- Glynn Clements From glynn at gclements.plus.com Wed Apr 11 19:37:48 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Apr 11 19:37:52 2007 Subject: [GRASS-dev] problem with r.colors on Mac In-Reply-To: <17949.2993.124827.851219@cerise.gclements.plus.com> References: <17948.16915.391634.256480@cerise.gclements.plus.com> <17948.48049.681105.666051@cerise.gclements.plus.com> <20070411114349.GB13640@bartok.itc.it> <17949.2993.124827.851219@cerise.gclements.plus.com> Message-ID: <17949.7404.663290.806077@cerise.gclements.plus.com> Glynn Clements wrote: > > > Beyond that, it would be nice to be able to apply histogram > > > equalisation and/or logarithmic scaling to any colour table, rather > > > than just grey. > > > > Absolutely. A long standing wish... > > I've added two new functions to libgis: > > int G_histogram_eq_colors(struct Colors *, struct Colors *, struct Cell_stats *); > int G_log_colors(struct Colors *, struct Colors *, int); > > Eac function creates a new colour table from an existing colour table. > In both cases, the new table covers the same range as the old table, > but the mapping across the range is either equalised or > logarithmically scaled. > > The next step is to add corresponding options to r.colors. Done; r.colors now has -e (hist. eq.) and -g (log. scale) options. -- Glynn Clements From neteler at itc.it Wed Apr 11 20:12:09 2007 From: neteler at itc.it (Markus Neteler) Date: Wed Apr 11 20:12:10 2007 Subject: [GRASS-dev] problem with r.colors on Mac In-Reply-To: <17949.7404.663290.806077@cerise.gclements.plus.com> References: <17948.16915.391634.256480@cerise.gclements.plus.com> <17948.48049.681105.666051@cerise.gclements.plus.com> <20070411114349.GB13640@bartok.itc.it> <17949.2993.124827.851219@cerise.gclements.plus.com> <17949.7404.663290.806077@cerise.gclements.plus.com> Message-ID: <20070411181209.GG20701@bartok.itc.it> On Wed, Apr 11, 2007 at 06:37:48PM +0100, Glynn Clements wrote: > > Glynn Clements wrote: > > > > > Beyond that, it would be nice to be able to apply histogram > > > > equalisation and/or logarithmic scaling to any colour table, rather > > > > than just grey. > > > > > > Absolutely. A long standing wish... > > > > I've added two new functions to libgis: > > > > int G_histogram_eq_colors(struct Colors *, struct Colors *, struct Cell_stats *); > > int G_log_colors(struct Colors *, struct Colors *, int); > > > > Eac function creates a new colour table from an existing colour table. > > In both cases, the new table covers the same range as the old table, > > but the mapping across the range is either equalised or > > logarithmically scaled. > > > > The next step is to add corresponding options to r.colors. > > Done; r.colors now has -e (hist. eq.) and -g (log. scale) options. Wow - thanks a bunch! Markus From hmitaso at unity.ncsu.edu Wed Apr 11 20:16:52 2007 From: hmitaso at unity.ncsu.edu (Helena Mitasova) Date: Wed Apr 11 20:16:46 2007 Subject: [GRASS-dev] problem with r.colors on Mac In-Reply-To: <20070411181209.GG20701@bartok.itc.it> References: <17948.16915.391634.256480@cerise.gclements.plus.com> <17948.48049.681105.666051@cerise.gclements.plus.com> <20070411114349.GB13640@bartok.itc.it> <17949.2993.124827.851219@cerise.gclements.plus.com> <17949.7404.663290.806077@cerise.gclements.plus.com> <20070411181209.GG20701@bartok.itc.it> Message-ID: On Apr 11, 2007, at 2:12 PM, Markus Neteler wrote: > On Wed, Apr 11, 2007 at 06:37:48PM +0100, Glynn Clements wrote: >> >> Glynn Clements wrote: >> >>>>> Beyond that, it would be nice to be able to apply histogram >>>>> equalisation and/or logarithmic scaling to any colour table, >>>>> rather >>>>> than just grey. >>>> >>>> Absolutely. A long standing wish... >>> >>> I've added two new functions to libgis: >>> >>> int G_histogram_eq_colors(struct Colors *, struct Colors *, >>> struct Cell_stats *); >>> int G_log_colors(struct Colors *, struct Colors *, int); >>> >>> Eac function creates a new colour table from an existing colour >>> table. >>> In both cases, the new table covers the same range as the old table, >>> but the mapping across the range is either equalised or >>> logarithmically scaled. >>> >>> The next step is to add corresponding options to r.colors. >> >> Done; r.colors now has -e (hist. eq.) and -g (log. scale) options. > > Wow - thanks a bunch! > > Markus Glynn, big thanks from me too, I need it all the time, Helena > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From tutey at o2.pl Wed Apr 11 22:35:55 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Wed Apr 11 22:36:01 2007 Subject: [GRASS-dev] problem with r.colors on Mac In-Reply-To: <17949.7404.663290.806077@cerise.gclements.plus.com> References: <17948.16915.391634.256480@cerise.gclements.plus.com> <17948.48049.681105.666051@cerise.gclements.plus.com> <20070411114349.GB13640@bartok.itc.it> <17949.2993.124827.851219@cerise.gclements.plus.com> <17949.7404.663290.806077@cerise.gclements.plus.com> Message-ID: <461D46AB.7050800@o2.pl> Glynn Clements wrote: > Done; r.colors now has -e (hist. eq.) and -g (log. scale) options. Glynn, Wow! Now GRASS is able to equalize any color table, superb. Thank you. Messing around with the new feature I found there is a difference between -e/-g color=grey and the old color=grey.eq/grey.log; in spearfish: $ r.colors landcover.30m col=grey.eq $ r.mapcalc 'tryit_old_eq=#landcover.30m' $ r.colors -e landcover.30m col=grey $ r.mapcalc 'tryit_new_eq=#landcover.30m' There is a difference between the 2 colortables it seems: $ r.mapcalc 'dif_eq=tryit_new_eq-tryit_old_eq' $ r.info -r dif_eq min=-1 max=0 In case of logarithmic scaling there is a difference too: $ r.colors landcover.30m col=grey.log $ r.mapcalc 'tryit_old_log=#landcover.30m' $ r.colors -g landcover.30m col=grey $ r.mapcalc 'tryit_new_log=#landcover.30m' $ r.mapcalc 'dif_log=tryit_new_log-tryit_old_log' $ r.info -r dif_log min=0 max=10 Is that as expected? Maciek From michael.barton at asu.edu Wed Apr 11 22:58:07 2007 From: michael.barton at asu.edu (Michael Barton) Date: Wed Apr 11 22:58:23 2007 Subject: [GRASS-dev] problem with r.colors on Mac In-Reply-To: <20070411114349.GB13640@bartok.itc.it> Message-ID: On 4/11/07 4:43 AM, "Markus Neteler" wrote: > On Wed, Apr 11, 2007 at 11:42:57AM +0100, Glynn Clements wrote: >> Michael Barton wrote: >>> >>> I had thought that grey.log was a histogram stretch like grey.eq. In the >>> docs, it is called "histogram logarithmic transformed grey scale". In that >>> sense, it seems like it should set the minimum value to black rather than 1. >>> Thanks for the explanation. Would it be difficult to change this to stretch >>> the image histogram rather than values of 1 to n? >> >> It wouldn't be hard to change it to map log(min) to black. I'm not so >> sure about the histogram equalisation part. >> >> The main issue is whether someone might be relying upon the existing >> behaviour. > > Maybe not too much since it is "only" a color table. > >> Beyond that, it would be nice to be able to apply histogram >> equalisation and/or logarithmic scaling to any colour table, rather >> than just grey. > > Absolutely. A long standing wish... > >> The existence of grey.log and grey.eq is the main reason that r.colors >> still has separate color= and rules= options, as those two cannot be >> implemented using rules files. > > A simplification would be appreciated, but moreover support for FP map > histogram equalisation etc. > I agree with Markus. For r.colors behavior, I suggest ultimately: map= [name of raster to set color table] colors= [name of predefined color tables] (merge current rules and colors) stretch= [grey.eq,color.eq, grey.log, color.log, other?] (put grey.eq and grey.log here) rast= [import color table of this raster] rules= [import user defined color table] (add a gui "prompt" for browse button) For backward compatibility in the 6.x series, we'd have to leave grey.eq and grey.log as valid settings for the colors argument. I suppose we'd have to leave in the current list of predefined rules files as valid for the rules argument. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From gnelson at uiuc.edu Wed Apr 11 23:50:35 2007 From: gnelson at uiuc.edu (Jerry Nelson) Date: Wed Apr 11 23:51:02 2007 Subject: [GRASS-dev] ascii export and import, large file problem Message-ID: <008f01c77c83$7234a040$3e40ae80@ace.uiuc.edu> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: diffMapSmall.jpg Type: image/jpeg Size: 35502 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070411/d1d2f2e5/diffMapSmall-0001.jpg From glynn at gclements.plus.com Thu Apr 12 00:23:08 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Apr 12 00:23:13 2007 Subject: [GRASS-dev] problem with r.colors on Mac In-Reply-To: <461D46AB.7050800@o2.pl> References: <17948.16915.391634.256480@cerise.gclements.plus.com> <17948.48049.681105.666051@cerise.gclements.plus.com> <20070411114349.GB13640@bartok.itc.it> <17949.2993.124827.851219@cerise.gclements.plus.com> <17949.7404.663290.806077@cerise.gclements.plus.com> <461D46AB.7050800@o2.pl> Message-ID: <17949.24524.49152.315919@cerise.gclements.plus.com> Maciej Sieczka wrote: > Messing around with the new feature I found there is a difference > between -e/-g color=grey and the old color=grey.eq/grey.log; in spearfish: > > $ r.colors landcover.30m col=grey.eq > $ r.mapcalc 'tryit_old_eq=#landcover.30m' > > $ r.colors -e landcover.30m col=grey > $ r.mapcalc 'tryit_new_eq=#landcover.30m' > > There is a difference between the 2 colortables it seems: > > $ r.mapcalc 'dif_eq=tryit_new_eq-tryit_old_eq' > $ r.info -r dif_eq > min=-1 > max=0 grey.eq scales the fraction by 256 to get a grey level, while -e uses it to interpolate the original colour table. If the original colour table is a 0-255 grey scale, -e is effectively scaling the fraction by 255. This comes down to how color_look.c (G_get_d_raster_color() etc) interpolates colour rules. E.g. if you have a single grey-scale rule with 0% = 0/0/0 and 100% = 255/255/255, 99.9999% gets you 254/254/254. I don't think there's anything that I can do about this for -e. grey.eq creates its own grey scale, but -e has to work with any colour table, so it's reliant upon the existing colour lookup functions. > In case of logarithmic scaling there is a difference too: > > $ r.colors landcover.30m col=grey.log > $ r.mapcalc 'tryit_old_log=#landcover.30m' > > $ r.colors -g landcover.30m col=grey > $ r.mapcalc 'tryit_new_log=#landcover.30m' > > $ r.mapcalc 'dif_log=tryit_new_log-tryit_old_log' > $ r.info -r dif_log > min=0 > max=10 > > Is that as expected? The algorithm used by grey.log is quite different to that used by -g. The former takes a "struct Cell_stats", and generates a "step" (a rule with the same grey level for the start and end points) for each category which occurs. The latter simply divides the range into 100[*] logarithmically equal steps. This eliminates the need to compute statistics, so there are no issues with FP data or performance issues with large maps. [*] I can easily change the number of steps, or make it an option. BTW: -e and -g aren't mutually exclusive. -- Glynn Clements From rez at touchofmadness.com Thu Apr 12 08:49:36 2007 From: rez at touchofmadness.com (Brad Douglas) Date: Thu Apr 12 08:49:46 2007 Subject: [GRASS-dev] message standardization on wiki In-Reply-To: <20070411084454.ANZ61728@expms1.cites.uiuc.edu> References: <20070411084454.ANZ61728@expms1.cites.uiuc.edu> Message-ID: <1176360576.3347.29.camel@dev64.localdomain> On Wed, 2007-04-11 at 08:44 -0500, Gerald Nelson wrote: > Can I suggest the following rules > 1. First letter should be capitalized > 2. Use present tense (cannot instead of could not) > 3. No contractions (cannot instead of can't) > 4. Good sentence construction ("Cannot find input map <%s>" instead of "It could not be find input map <%s>") > 5. Be consistent with periods. Either end all phrases with a period or none. I would prefer not using "Cannot...". It's bad grammar. I would much prefer "Unable to..." or something to that effect. -- Brad Douglas KB8UYR/6 Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From wegmann at biozentrum.uni-wuerzburg.de Thu Apr 12 10:12:23 2007 From: wegmann at biozentrum.uni-wuerzburg.de (Martin Wegmann) Date: Thu Apr 12 10:11:54 2007 Subject: [GRASS-dev] Re: errors in: messages - fixed Message-ID: <200704121012.27431.wegmann@biozentrum.uni-wuerzburg.de> > > > > I get various "errors in:" messages after an update. So far I did not > > > > find similar threats on the mailing lists. > > > > > > > > After a cvs update, make distclean - configure - make, a long list of > > > > "errors in:" is prompted (see below). > > > > > > > > I deleted my old cvs folder and removed the grass files in /usr/local > > > > and did a fresh cvs but still the same error appears. > > > > > > > > It is a temporal problem or did I forget something? > > > > > > > > Using debian testing. > > > > > > > > TIA Martin > > > > > > > > Errors in: > > > > ...//grass/grass6/lib/proj > > > > > > --snip-- > > > > > > > (In case of errors please change into the directory with error and > > > > run 'make') > > > > > > please do that, starting with lib/proj > > > > baliola@wpf063:~/software/grass/grass6$ cd lib/proj/ > > baliola@wpf063:~/software/grass/grass6/lib/proj$ make > > gcc -shared -o > /home/baliola/software/grass/grass6/dist.i686-pc-linux-gnu/lib/libgrass_gpr >oj.6.3.cvs.so > -L/home/baliola/software/grass/grass6/dist.i686-pc-linux-gnu/lib > -Wl,--export-dynamic > -Wl,-rpath-link,/home/baliola/software/grass/grass6/dist.i686-pc-linux-gnu/ >lib > > > OBJ.i686-pc-linux-gnu/get_proj.o OBJ.i686-pc-linux-gnu/do_proj.o > > OBJ.i686-pc-linux-gnu/convert.o OBJ.i686-pc-linux-gnu/datum.o > > OBJ.i686-pc-linux-gnu/ellipse.o -lgrass_gis -lgrass_datetime -lz -lproj > -L/usr/local/lib -lgdal -lodbc -lodbcinst -ljasper -lmfhdf -ldf -lgif > -ljpeg -ltiff -lpng -lnetcdf -lcfitsio -L/usr/local/grass-6.3.cvs//lib > -lgrass_vect -lgrass_dig2 -lgrass_dgl -lgrass_rtree -lgrass_linkm > -lgrass_dbmiclient -lgrass_dbmibase -lgrass_I -lgrass_gproj -lgrass_vask > -lgrass_gmath -lgrass_gis -lgrass_datetime -lpq -L/usr/lib -lpq -lz -lm > -lrt -ldl > > > && \ > > (cd > > /home/baliola/software/grass/grass6/dist.i686-pc-linux-gnu/lib; ln -f -s > > libgrass_gproj.6.3.cvs.so > /home/baliola/software/grass/grass6/dist.i686-pc-linux-gnu/lib/libgrass_gpr >oj.so) > > > /usr/bin/ld: cannot find -lgrass_vect > > As libgrass_gproj library doesn't use libgrass_vect, this is almost > certainly a GDAL issue (i.e. your GDAL library was built with GRASS > support, but you've removed the GRASS installation on which it > depends). If that is the case, you will first need to re-install GDAL; > if you're building it from source, you'll need to build without GRASS > support. I removed my whole gdal installation (deb and source) and compiled the source without GRASS support and pointed GRASS to this GDAL path. Now it works fine again. Thanks! Martin From bernhard at intevation.de Thu Apr 12 10:31:19 2007 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu Apr 12 10:31:37 2007 Subject: [GRASS-dev] enable forwarding all GRASS GForge =?iso-8859-2?q?traffic=09to=09grass-dev?= ML? In-Reply-To: <46127E22.4090306@o2.pl> References: <4611761A.70609@o2.pl> <4612120A.8040009@itc.it> <46127E22.4090306@o2.pl> Message-ID: <200704121031.25041.bernhard@intevation.de> Hi Maciej, Hi All, sorry for being a bit slow on this thread to respond. We will fix wald to make it useful. Our motivation is strong as we use it ourselfs. The idea to use the gforge software is that we want to share to effort to create a great development platform with other Free Software developers, while keeping and interface that many users know and thus keep the entry barrier low. Since we have decided to use www.gforge.org, we had to learn that this also makes things slower sometimes as we have Debian and gforge.org that we would want to support. Also the Gforge group did now go into the proprietary market. The community around gforge is quite big, so it will still be among the best software packages to have for this, but we need to do more to make it really fly. Now back to the concrete problems: In general, if you want to help with this, try to help fixing it in the public in Debian and Gforge (both upstream for us). Link your efforts to the entries on wald, this way, everybody can help and we can push this for the good of GRASS, wald, Debian, gforge and the whole Free Software community. I will list the entries in the https://wald.intevation.org/tracker/?group_id=1&atid=162 On Tuesday 03 April 2007 18:17, Maciej Sieczka wrote: > Markus Neteler wrote: > > Hamish wrote on 04/03/2007 02:53 AM: > >> ... > >> it would be nice if the cc'd emails only contained new bug comments. > >> * skip messages from minor tracker edits. > >> eg "priority changed to ..." > > It is not possible currently. This one is missing the wald site-admin tracker? (As a seperate issue.) > >> * don't include full bug history in each email, only the newest > >> comment. > > Not possible currently either. Each email from GForge trackers will > include the full thread. I didn't design it. That's how it is. https://wald.intevation.org/tracker/index.php?func=detail&aid=360 > > I also dislike that all stuff is included (you never find the relevant > > piece, also due to the "fancy" ordering style within the report. > > That's a GForge bad feature which I can't fix. Maybe our GForge host, > the Intevation, can. If they can't, maybe it is an issue in GForge in > general and we should ask GForge devs to fix that. Before doing that, > I'd love to hear from Intevation. Like I said, I have reported the > problem few weeks ago [1] and there was not answer yet. We can fix things, but of course it is better if upstream would fix it. So I suggest that we do a ranking of the issues, submit them all to upstream and start fixing the ones that are most urgent from our side as well. > >> otherwise too much noise. at minimum a "cc" field in the bug tracker > >> would let us manually enter grass-dev, as the old system did. > > > > Sounds like a good idea. > > That's what I asked for in [1]. > > >> Maybe add grass-dev as an interested party in the bug report? > > That's what I asked about in this thread. So, should I? Mind that each > email from GForge trackers will include the whole thread (all > messages), with the original message on top, the most recent next, and > all older messages after that, in chronological order (newer first, > older next). This is a matter of workflow. I would prefer to only have new issues reported to the main list and then people can add themselfs to monitor that item if they are interested. If you want a general email monitoring, we could create another list which get the full information. Actually all wald project admins can do so. Then people could subscribe to that list and filter out whatever information they want to see. This would be an alternative to the monitoring system. > >> Also how to enable reply-to-bug from grass-dev? > > I don't think it is possible currently. And I'm not sure it is needed. > Other widely used tracking systems (Bugzilla, Trac) require one to use > an online interface too and users got used to it. What is missing in > GForge, is an option to CC an arbitrary email, eg. a mailing list, when > a consultation is needed. > > [1]http://wald.intevation.org/tracker/index.php?func=detail&aid=300&group_i >d=1&atid=162 Best, Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070412/2bc20ee0/attachment.bin From glynn at gclements.plus.com Thu Apr 12 15:41:26 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Apr 12 15:41:32 2007 Subject: [GRASS translations] Re: [GRASS-dev] message standardization on wiki In-Reply-To: <1176360576.3347.29.camel@dev64.localdomain> References: <20070411084454.ANZ61728@expms1.cites.uiuc.edu> <1176360576.3347.29.camel@dev64.localdomain> Message-ID: <17950.14086.354374.742566@cerise.gclements.plus.com> Brad Douglas wrote: > > 1. First letter should be capitalized > > 2. Use present tense (cannot instead of could not) > > 3. No contractions (cannot instead of can't) > > 4. Good sentence construction ("Cannot find input map <%s>" instead of "It could not be find input map <%s>") > > 5. Be consistent with periods. Either end all phrases with a period or none. > > I would prefer not using "Cannot...". It's bad grammar. I would much > prefer "Unable to..." or something to that effect. While I can see your point, that construction is quite common in error messages, e.g.: $ ls -l foo ls: cannot access foo: No such file or directory Neither "cannot ..." nor "unable to ..." form complete sentences. If you're concerned about grammar, you can provide an explicit subject ("The program cannot ..."), or use the third person (e.g. "The file cannot be found"). Personally, I don't have a problem with just omitting the subject. -- Glynn Clements From glynn at gclements.plus.com Thu Apr 12 16:42:48 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Apr 12 16:42:50 2007 Subject: [GRASS-dev] ascii export and import, large file problem In-Reply-To: <008f01c77c83$7234a040$3e40ae80@ace.uiuc.edu> References: <008f01c77c83$7234a040$3e40ae80@ace.uiuc.edu> Message-ID: <17950.17768.300890.594225@cerise.gclements.plus.com> Jerry Nelson wrote: > I'm using grass6.3 updated today so the large file support for the ascii > commands is included. I export a file using r.out.arc and then read it back > in using r.in.arc. The attached jpg shows the original raster on the right. > The screen on the left is the original raster minus the exported and > imported version. The bottom two thirds or so of the left raster is zero, as > it should be, but the top 1/3 has a bunch of small values (range is - to > +2.9). My first guess is that the export->import process is changing the vertical extent of the map slightly, so the calculation in the upper portion of the map is using cells which are off by one row. What does r.info say about the bounds of the two maps? -- Glynn Clements From mlennert at club.worldonline.be Thu Apr 12 16:59:42 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Thu Apr 12 16:56:34 2007 Subject: [GRASS-dev] Re: [GRASS-user] Views in pgSQL In-Reply-To: <461D0998.1060903@club.worldonline.be> References: <20070411100756.GJ7680@bartok.itc.it> <461CBFF0.7090602@amu.edu.pl> <461CC4B2.40203@club.worldonline.be> <461CCB20.2020704@amu.edu.pl> <461CFDE4.1070704@club.worldonline.be> <20070411153714.GB20701@bartok.itc.it> <461D0998.1060903@club.worldonline.be> Message-ID: <461E495E.4070407@club.worldonline.be> On 11/04/07 18:15, Moritz Lennert wrote: > On 11/04/07 17:37, Markus Neteler wrote: >> On Wed, Apr 11, 2007 at 05:25:24PM +0200, Moritz Lennert wrote: >>> On 11/04/07 13:48, Jaros??aw Jasiewicz wrote: >>>> BTW: >>>> Pg Views are very important for me when I connect-reconnect vector >>>> files to different atribute table. I use (used!) views insted of >>>> original table to avoid occasional removing original data and to >>>> speed up transfer limiting data in views only to these needed for >>>> (sorry, I think everybody knows it) >>> I completely agree with you. Being able to connect maps to views is >>> fundamental in my eyes. >> >> Yes. But we need a reasonable implementation. >> Anyone with suggestions how to implement it? > > For me the choice is either > > 1) to consider views as tables (and thus change the way the individual > drivers list tables) or > > 2) to treat them as separate and change v.db.connect so that it checks > for both. > > 1) seems much easier to implement, 2) seems cleaner in case we need to > list tables only, not views, in other contexts than v.db.connect. > As I don't see any reason why 1) should be a problem in the context of GRASS, I've had done a quick implementation of this for the pg driver (diff attached). For me it seems to work. Anyone opposed to committing this ? For sqlite and mysql, I will have to do some more reading to learn how to get the relevant info (i.e. list of user-relevant views). If someone has some knowledge about this, I would be grateful. Moritz -------------- next part -------------- A non-text attachment was scrubbed... Name: listtab.diff Type: text/x-patch Size: 3551 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070412/cb72a179/listtab-0001.bin From mlennert at club.worldonline.be Thu Apr 12 17:16:21 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Thu Apr 12 17:13:13 2007 Subject: [GRASS-dev] Re: [GRASS-user] Views in pgSQL In-Reply-To: <461E495E.4070407@club.worldonline.be> References: <20070411100756.GJ7680@bartok.itc.it> <461CBFF0.7090602@amu.edu.pl> <461CC4B2.40203@club.worldonline.be> <461CCB20.2020704@amu.edu.pl> <461CFDE4.1070704@club.worldonline.be> <20070411153714.GB20701@bartok.itc.it> <461D0998.1060903@club.worldonline.be> <461E495E.4070407@club.worldonline.be> Message-ID: <461E4D45.3010308@club.worldonline.be> On 12/04/07 16:59, Moritz Lennert wrote: > On 11/04/07 18:15, Moritz Lennert wrote: >> On 11/04/07 17:37, Markus Neteler wrote: >>> On Wed, Apr 11, 2007 at 05:25:24PM +0200, Moritz Lennert wrote: >>>> On 11/04/07 13:48, Jaros??aw Jasiewicz wrote: > >>>>> BTW: >>>>> Pg Views are very important for me when I connect-reconnect vector >>>>> files to different atribute table. I use (used!) views insted of >>>>> original table to avoid occasional removing original data and to >>>>> speed up transfer limiting data in views only to these needed for >>>>> (sorry, I think everybody knows it) >>>> I completely agree with you. Being able to connect maps to views is >>>> fundamental in my eyes. >>> >>> Yes. But we need a reasonable implementation. >>> Anyone with suggestions how to implement it? >> >> For me the choice is either >> >> 1) to consider views as tables (and thus change the way the individual >> drivers list tables) or >> >> 2) to treat them as separate and change v.db.connect so that it checks >> for both. >> >> 1) seems much easier to implement, 2) seems cleaner in case we need to >> list tables only, not views, in other contexts than v.db.connect. >> > > As I don't see any reason why 1) should be a problem in the context of > GRASS, I've had done a quick implementation of this for the pg driver > (diff attached). For me it seems to work. > > Anyone opposed to committing this ? > > For sqlite and mysql, I will have to do some more reading to learn how > to get the relevant info (i.e. list of user-relevant views). If someone > has some knowledge about this, I would be grateful. Actually sqlite was very easy: Index: listtab.c =================================================================== RCS file: /grassrepository/grass6/db/drivers/sqlite/listtab.c,v retrieving revision 1.3 diff -u -r1.3 listtab.c --- listtab.c 9 Feb 2006 03:08:49 -0000 1.3 +++ listtab.c 12 Apr 2007 15:10:36 -0000 @@ -29,7 +29,7 @@ init_error(); ret = sqlite3_prepare ( sqlite, - "select name from sqlite_master where type = 'table'", + "select name from sqlite_master where type = 'table' or type = 'view'", -1, &statement, &rest ); if ( ret != SQLITE_OK ) { In mysql, views are only supported since version 5. The GRASS mysql driver uses the function mysql_list_tables() to get the table names. I don't see an equivalent of that for views. Will search a bit more. Moritz From carlos.grohmann at gmail.com Thu Apr 12 18:35:54 2007 From: carlos.grohmann at gmail.com (=?ISO-8859-1?Q?Carlos_"Gu=E2no"_Grohmann?=) Date: Thu Apr 12 18:35:57 2007 Subject: [GRASS-dev] impressions on wx GUI Message-ID: I just installed the prototype of wx GUI. It's looking good! nice work! - some impressions: I guess the display is working nice, it's fast. although most people coming from other GIS wants a display where you don't have to ask it to draw the maps. If you de-select one map, it would automatically draw the underlying layer (like QGIS). Multiple selection of layers in GIS Manager. If you want to delete several layers, it is a pain to do it one by one. Also some right-click would be nice. it could open a menu with options like delete, info, colors... IMO a slider for transparency is easier to play with. maybe we could have both the slider and the numerical value, maybe in one of the right-click options. Enable the overlay option for rasters as a default. Maybe make the font size in the dialogs smaller? I get the feeling that it is too big, with too much space between the components. If I am in the "output" tab of GI manager, and add a new raster/vector, I should be sent back to the "layers" tab. that's it for now. Carlos -- +-----------------------------------------------------------+ Carlos Henrique Grohmann - Guano Geologist M.Sc - Doctorate Student at IGc-USP - Brazil Linux User #89721 - carlos dot grohmann at gmail dot com +-----------------------------------------------------------+ _________________ "Good morning, doctors. I have taken the liberty of removing Windows 95 from my hard drive." --The winning entry in a "What were HAL's first words" contest judged by 2001: A SPACE ODYSSEY creator Arthur C. Clarke From glynn at gclements.plus.com Thu Apr 12 21:10:22 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Apr 12 21:10:29 2007 Subject: [GRASS-dev] impressions on wx GUI In-Reply-To: References: Message-ID: <17950.33822.424614.84221@cerise.gclements.plus.com> "Carlos \"Gu?no\" Grohmann" wrote: > I guess the display is working nice, it's fast. although most people > coming from other GIS wants a display where you don't have to ask it > to draw the maps. If you de-select one map, it would automatically > draw the underlying layer (like QGIS). This is probably an artifact of using an external program (g.pnmcomp) to composite layers. AFAICT, this shouldn't be necessary with wxPython, at least when translucency isn't being used. It should be possible to convert the alpha channel to a mask and use native wx functions to composite layers. Unfortunately, wxWidgets doesn't appear to directly support translucency. It might be worth looking into using e.g. PIL for this. -- Glynn Clements From rez at touchofmadness.com Thu Apr 12 22:01:52 2007 From: rez at touchofmadness.com (Brad Douglas) Date: Thu Apr 12 22:01:57 2007 Subject: X-IMail-SPAM-Connection Re: [GRASS translations] Re: [GRASS-dev] message standardization on wiki In-Reply-To: <17950.14086.354374.742566@cerise.gclements.plus.com> References: <20070411084454.ANZ61728@expms1.cites.uiuc.edu> <1176360576.3347.29.camel@dev64.localdomain> <17950.14086.354374.742566@cerise.gclements.plus.com> Message-ID: <1176408112.3347.40.camel@dev64.localdomain> On Thu, 2007-04-12 at 14:41 +0100, Glynn Clements wrote: > Brad Douglas wrote: > > > > 1. First letter should be capitalized > > > 2. Use present tense (cannot instead of could not) > > > 3. No contractions (cannot instead of can't) > > > 4. Good sentence construction ("Cannot find input map <%s>" instead of "It could not be find input map <%s>") > > > 5. Be consistent with periods. Either end all phrases with a period or none. > > > > I would prefer not using "Cannot...". It's bad grammar. I would much > > prefer "Unable to..." or something to that effect. > > While I can see your point, that construction is quite common in error > messages, e.g.: > > $ ls -l foo > ls: cannot access foo: No such file or directory > > Neither "cannot ..." nor "unable to ..." form complete sentences. > > If you're concerned about grammar, you can provide an explicit subject > ("The program cannot ..."), or use the third person (e.g. "The file > cannot be found"). > > Personally, I don't have a problem with just omitting the subject. Point taken. I was really referring to the usage of "Cannot". Some dictionaries do not recognize it as 'real word', yet others (that are generally more progressive with slang and contractions) say that it should replace "can not" in modern English. It's a non-problem. In modules I've [re]written, I've used "Unable to", but I can go back and change them for consistency. -- Brad Douglas KB8UYR/6 Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From glynn at gclements.plus.com Thu Apr 12 23:53:20 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Apr 12 23:53:23 2007 Subject: [GRASS-dev] problem with r.colors on Mac In-Reply-To: <17949.2993.124827.851219@cerise.gclements.plus.com> References: <17948.16915.391634.256480@cerise.gclements.plus.com> <17948.48049.681105.666051@cerise.gclements.plus.com> <20070411114349.GB13640@bartok.itc.it> <17949.2993.124827.851219@cerise.gclements.plus.com> Message-ID: <17950.43600.506857.847594@cerise.gclements.plus.com> Glynn Clements wrote: > Beyond that, I'd like to propose eliminating most of the individual > G_make_*_colors() functions in favour of a general purpose function > which takes the name of a rules file as an argument. I've done this, and would appreciate it if the changes could receive some testing. The core of r.colors' color=rules and rules= options is now in lib/gis/color_rules.c. Apart from the lower-level functions used by r.colors, this provides two new functions: int G_make_colors(struct Colors *colors, const char *name, CELL min, CELL max); int G_make_fp_colors(struct Colors *colors, const char *name, DCELL min, DCELL max); These effectively supersede most of the G_make_*_[fp_]colors() functions, i.e.: G_make_aspect_colors G_make_byg_colors G_make_byr_colors G_make_grey_scale_colors G_make_gyr_colors G_make_rainbow_colors G_make_ramp_colors G_make_ryg_colors G_make_wave_colors plus the _fp_ versions. A call such as: G_make_rainbow_colors(&colors, min, max); can be replaced with: G_make_colors(&colors, "rainbow", min, max); The following functions don't have direct equivalents: G_make_histogram_eq_colors G_make_histogram_log_colors G_make_random_colors The first two can be replaced with a combination of G_make_colors(&colors, "grey", ...) and either G_histogram_eq_colors() or G_log_colors(), e.g.: G_make_colors(&colors, "grey", min, max); G_histogram_eq_colors(&colors_tmp, &colors, &statf); colors = colors_tmp; or: G_make_colors(&colors, "grey", min, max); G_log_colors(&colors_tmp, &colors, 100); colors = colors_tmp; [I will modify G_{histogram_eq,log}_colors to allow the colour table to be updated in-place, to avoid the need for a temporary variable.] G_make_random_colors() cannot be implemented by means of colour rules, and so will remain. The corresponding changes to r.colors are: 1. "r.colors color=rules" is implemented using the lower level functions G_read_color_rules(), G_parse_color_rule() etc, with r.colors itself handling terminal interaction. 2. "r.colors rules=" just calls G_make_fp_colors() with the specified rule name. Also, the rules files have been moved to the lib/gis/color directory. The next step is to replace the various G_make_*_[fp_]colors() functions with wrappers around G_make_[fp_]colors(). Unless that shows up any problems, I'll replace the use of G_make_*_[fp_]colors() with direct calls to G_make_[fp_]colors(), and merge the rules= and color= options in r.colors. -- Glynn Clements From gnelson at uiuc.edu Fri Apr 13 00:16:36 2007 From: gnelson at uiuc.edu (Jerry Nelson) Date: Fri Apr 13 00:16:53 2007 Subject: [GRASS-dev] ascii export and import, large file problem In-Reply-To: <17950.17768.300890.594225@cerise.gclements.plus.com> References: <008f01c77c83$7234a040$3e40ae80@ace.uiuc.edu> <17950.17768.300890.594225@cerise.gclements.plus.com> Message-ID: <00e101c77d50$3c903d50$3e40ae80@ace.uiuc.edu> The regions were in fact different before and after the export/import. We used the default decimal setting. We're trying 16 decimals to see if that makes a difference. Jerry -----Original Message----- From: Glynn Clements [mailto:glynn@gclements.plus.com] Sent: Thursday, April 12, 2007 9:43 AM To: Jerry Nelson Cc: 'grass-dev' Subject: Re: [GRASS-dev] ascii export and import, large file problem Jerry Nelson wrote: > I'm using grass6.3 updated today so the large file support for the ascii > commands is included. I export a file using r.out.arc and then read it back > in using r.in.arc. The attached jpg shows the original raster on the right. > The screen on the left is the original raster minus the exported and > imported version. The bottom two thirds or so of the left raster is zero, as > it should be, but the top 1/3 has a bunch of small values (range is - to > +2.9). My first guess is that the export->import process is changing the vertical extent of the map slightly, so the calculation in the upper portion of the map is using cells which are off by one row. What does r.info say about the bounds of the two maps? -- Glynn Clements From gnelson at uiuc.edu Fri Apr 13 00:22:36 2007 From: gnelson at uiuc.edu (Jerry Nelson) Date: Fri Apr 13 00:22:54 2007 Subject: [GRASS-dev] ascii export and import, large file problem In-Reply-To: <17950.17768.300890.594225@cerise.gclements.plus.com> References: <008f01c77c83$7234a040$3e40ae80@ace.uiuc.edu> <17950.17768.300890.594225@cerise.gclements.plus.com> Message-ID: <00e201c77d51$1310f590$3e40ae80@ace.uiuc.edu> To provide more info, The 'after' info | Rows: 21048 | Columns: 17067 | Total Cells: 359226216 | Projection: UTM (zone 37) | N: 1989570.65127245 S: -516147.35893555 Res: 119.047796 | E: 1868393.2390198 W: -163395.4953122 Res: 119.047796 | Range of data: min = 0.000000 max = 557.001038 The 'before' info | Rows: 21048 | Columns: 17067 | Total Cells: 359226216 | Projection: UTM (zone 37) | N: 1989664.48241023 S: -516147.35893555 Res: 119.05225396 | E: 1868393.2316229 W: -163395.4953122 Res: 119.04779557 | Range of data: min = 0.000000 max = 557.001038 -----Original Message----- From: Glynn Clements [mailto:glynn@gclements.plus.com] Sent: Thursday, April 12, 2007 9:43 AM To: Jerry Nelson Cc: 'grass-dev' Subject: Re: [GRASS-dev] ascii export and import, large file problem Jerry Nelson wrote: > I'm using grass6.3 updated today so the large file support for the ascii > commands is included. I export a file using r.out.arc and then read it back > in using r.in.arc. The attached jpg shows the original raster on the right. > The screen on the left is the original raster minus the exported and > imported version. The bottom two thirds or so of the left raster is zero, as > it should be, but the top 1/3 has a bunch of small values (range is - to > +2.9). My first guess is that the export->import process is changing the vertical extent of the map slightly, so the calculation in the upper portion of the map is using cells which are off by one row. What does r.info say about the bounds of the two maps? -- Glynn Clements From michael.barton at asu.edu Fri Apr 13 00:30:03 2007 From: michael.barton at asu.edu (Michael Barton) Date: Fri Apr 13 00:30:08 2007 Subject: [GRASS-dev] any way to know color assigned to a cell? Message-ID: If have a map with values from 0-255 I create a set of color rules such that 0% = green 100% = red GRASS will create a color table that will assign a nice gradient of colors from 0:255:0 to 255:0:0 to the values from 0-255. Is there any way when querying a single cell of that map to know what color has been assigned to it? Similarly, is there any way to know what color has been assigned to any value in the 0-255 range? Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070412/56f38dae/attachment.html From glynn at gclements.plus.com Fri Apr 13 00:58:16 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Apr 13 00:58:18 2007 Subject: [GRASS-dev] ascii export and import, large file problem In-Reply-To: <00e201c77d51$1310f590$3e40ae80@ace.uiuc.edu> References: <008f01c77c83$7234a040$3e40ae80@ace.uiuc.edu> <17950.17768.300890.594225@cerise.gclements.plus.com> <00e201c77d51$1310f590$3e40ae80@ace.uiuc.edu> Message-ID: <17950.47496.587551.524069@cerise.gclements.plus.com> Jerry Nelson wrote: > > > I'm using grass6.3 updated today so the large file support for the ascii > > > commands is included. I export a file using r.out.arc and then read it back > > > in using r.in.arc. The attached jpg shows the original raster on the right. > > > The screen on the left is the original raster minus the exported and > > > imported version. The bottom two thirds or so of the left raster is zero, as > > > it should be, but the top 1/3 has a bunch of small values (range is - to > > > +2.9). > > > > My first guess is that the export->import process is changing the > > vertical extent of the map slightly, so the calculation in the upper > > portion of the map is using cells which are off by one row. > > > > What does r.info say about the bounds of the two maps? > > To provide more info, > > The 'after' info > Rows: 21048 > Res: 119.047796 > The 'before' info > Rows: 21048 > Res: 119.05225396 119.05225396 - 119.047796 = 0.00445796 0.00445796 * 21048 = 93.8311421 So, the imported map has shrunk by almost a whole cell. That would certainly explain the results. Ah, I see where the problem lies: > The 'before' info > Res: 119.05225396 > Res: 119.04779557 Your cells aren't square, but the ArcGrid format doesn't appear to allow for non-square cells (single "cellsize" value rather than separate x/y values). r.out.arc uses the horizontal resolution for the cellsize value; if the vertical resolution is different, you lose. This specific issue can't be fixed. However, if the original data had square cells, something is going wrong on the initial import. We might want to add a check for this to r.out.arc. We can't actually do anything beyond warn you that exporting will lose information, although that's better than nothing. -- Glynn Clements From glynn at gclements.plus.com Fri Apr 13 01:08:29 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Apr 13 01:08:33 2007 Subject: [GRASS-dev] any way to know color assigned to a cell? In-Reply-To: References: Message-ID: <17950.48109.88914.169521@cerise.gclements.plus.com> Michael Barton wrote: > If have a map with values from 0-255 I create a set of color rules such that > > 0% = green > 100% = red > > GRASS will create a color table that will assign a nice gradient of colors > from 0:255:0 to 255:0:0 to the values from 0-255. > > Is there any way when querying a single cell of that map to know what color > has been assigned to it? Set a 1x1 region around the cell, then r.out.ppm | pnmnoraw | sed. Or r.mapcalc 'out = (r#map * 256 + g#map) * 256 + b#map', query the composite map and decode the category number. > Similarly, is there any way to know what color has > been assigned to any value in the 0-255 range? Set a 1x1 region, r.mapcalc "tmp = $value", r.out.ppm ... Seriously; this is how d.rast.edit.tcl does it. Yeah; we could probably do with a "r.what.colors" module. -- Glynn Clements From michael.barton at asu.edu Fri Apr 13 01:35:04 2007 From: michael.barton at asu.edu (Michael Barton) Date: Fri Apr 13 01:35:17 2007 Subject: [GRASS-dev] any way to know color assigned to a cell? In-Reply-To: <17950.48109.88914.169521@cerise.gclements.plus.com> Message-ID: I was contemplating a wxPython histograming module, like the TclTk profiling module, and liked the option in d.histogram of being able to use the color table for the histogram colors. But this seems like a pretty intensive batch of calculations to do it. Michael On 4/12/07 4:08 PM, "Glynn Clements" wrote: > > Michael Barton wrote: > >> If have a map with values from 0-255 I create a set of color rules such that >> >> 0% = green >> 100% = red >> >> GRASS will create a color table that will assign a nice gradient of colors >> from 0:255:0 to 255:0:0 to the values from 0-255. >> >> Is there any way when querying a single cell of that map to know what color >> has been assigned to it? > > Set a 1x1 region around the cell, then r.out.ppm | pnmnoraw | sed. > > Or r.mapcalc 'out = (r#map * 256 + g#map) * 256 + b#map', query the > composite map and decode the category number. > >> Similarly, is there any way to know what color has >> been assigned to any value in the 0-255 range? > > Set a 1x1 region, r.mapcalc "tmp = $value", r.out.ppm ... > > Seriously; this is how d.rast.edit.tcl does it. > > Yeah; we could probably do with a "r.what.colors" module. __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From gnelson at uiuc.edu Fri Apr 13 02:10:18 2007 From: gnelson at uiuc.edu (Gerald Nelson) Date: Fri Apr 13 02:10:24 2007 Subject: [GRASS-dev] ascii export and import, large file problem Message-ID: <20070412191018.AOC27897@expms1.cites.uiuc.edu> This is related to my earlier question (to which noone responded) about why the slope calculation can't take lat-long data and just figure out the slope from the z values. The srtm elevation data comes in lat-long values in cells that are square. In order to get slope, which we need for a cost map, we project to a utm value in the center of the region we need (UTM37N). Grass does this projection and generates rectangular pixels. Then we do the slope calculation and other things to generate a cost surface. We need the ascii output to read the cost data into our custom neural net program (because we don't have any C programmers, just a java programmer). So its possible that what we observed when we did the export/import process is a function of the square/rectangular pixel issue interacting with the arc export/import that assumes pixels are square. My ideal would be to not have to take the data out of lat-long, but I have to do that to use the slope calculations. Hope this all makes some sense. Regards, Jerry ---- Original message ---- >Date: Thu, 12 Apr 2007 23:58:16 +0100 >From: Glynn Clements >Subject: RE: [GRASS-dev] ascii export and import, large file problem >To: "Jerry Nelson" >Cc: "'grass-dev'" > > >Jerry Nelson wrote: > >> > > I'm using grass6.3 updated today so the large file support for the ascii >> > > commands is included. I export a file using r.out.arc and then read it back >> > > in using r.in.arc. The attached jpg shows the original raster on the right. >> > > The screen on the left is the original raster minus the exported and >> > > imported version. The bottom two thirds or so of the left raster is zero, as >> > > it should be, but the top 1/3 has a bunch of small values (range is - to >> > > +2.9). >> > >> > My first guess is that the export->import process is changing the >> > vertical extent of the map slightly, so the calculation in the upper >> > portion of the map is using cells which are off by one row. >> > >> > What does r.info say about the bounds of the two maps? >> >> To provide more info, >> >> The 'after' info > >> Rows: 21048 > >> Res: 119.047796 > >> The 'before' info > >> Rows: 21048 > >> Res: 119.05225396 > >119.05225396 - 119.047796 = 0.00445796 >0.00445796 * 21048 = 93.8311421 > >So, the imported map has shrunk by almost a whole cell. That would >certainly explain the results. > >Ah, I see where the problem lies: > >> The 'before' info > >> Res: 119.05225396 >> Res: 119.04779557 > >Your cells aren't square, but the ArcGrid format doesn't appear to >allow for non-square cells (single "cellsize" value rather than >separate x/y values). r.out.arc uses the horizontal resolution for the >cellsize value; if the vertical resolution is different, you lose. > >This specific issue can't be fixed. However, if the original data had >square cells, something is going wrong on the initial import. > >We might want to add a check for this to r.out.arc. We can't actually >do anything beyond warn you that exporting will lose information, >although that's better than nothing. > >-- >Glynn Clements Gerald Nelson Professor, Dept. of Agricultural and Consumer Economics University of Illinois, Urbana-Champaign office: 217-333-6465 cell: 217-390-7888 315 Mumford Hall 1301 W. Gregory Urbana, IL 61801 From michael.barton at asu.edu Fri Apr 13 02:20:53 2007 From: michael.barton at asu.edu (Michael Barton) Date: Fri Apr 13 02:20:57 2007 Subject: [GRASS-dev] impressions on wx GUI In-Reply-To: Message-ID: On 4/12/07 9:35 AM, "Carlos "Gu?no" Grohmann" wrote: > I just installed the prototype of wx GUI. It's looking good! nice work! > > - some impressions: > > I guess the display is working nice, it's fast. although most people > coming from other GIS wants a display where you don't have to ask it > to draw the maps. If you de-select one map, it would automatically > draw the underlying layer (like QGIS). This is doable. However, there was discussion on this point for the current TclTk gui (where it is also doable). The majority of the responders preferred to be able to add and manage layers without waiting for a redraw for each change. They preferred to control redraw. > > Multiple selection of layers in GIS Manager. If you want to delete > several layers, it is a pain to do it one by one. Duly noted. Multiple drag and drop is more difficult however. > > Also some right-click would be nice. it could open a menu with options > like delete, info, colors... Definitely agree. We've discussed adding these when basic features are working well. For example, a contextual menu for a display might list various zoom options, redraw, etc. > > IMO a slider for transparency is easier to play with. maybe we could > have both the slider and the numerical value, maybe in one of the > right-click options. I tried the sliders and they looked bad (at least on my Mac) and took up an inordinate amount of space. A bonus of the spin controls is that you can type values into them too. > > Enable the overlay option for rasters as a default. This requires a custom options dialog because it actually calls d.his. I think this is a very handy feature. But right now, we're using the autogenerated dialogs for each command to save time getting the GUI up and running--and these are actually quite nice. We've talked some about custom properties dialogs in the future. > > Maybe make the font size in the dialogs smaller? I get the feeling > that it is too big, with too much space between the components. This is using your default system font. One problem with specifying fonts in detail is that they may look funny or even not work on different systems. Currently, I think the font is 11 point, which is a pretty good compromise on most systems. Which part looks especially large to you? > > If I am in the "output" tab of GI manager, and add a new > raster/vector, I should be sent back to the "layers" tab. Good idea Thanks for testing Michael > > that's it for now. > > Carlos > __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Fri Apr 13 02:25:35 2007 From: michael.barton at asu.edu (Michael Barton) Date: Fri Apr 13 02:25:40 2007 Subject: Updated r.colors - was: [GRASS-dev] problem with r.colors on Mac In-Reply-To: <17950.43600.506857.847594@cerise.gclements.plus.com> Message-ID: Thanks Glynn. This is real nice. Two suggestions. 1) for the rules entry, can it be a browse prompt initially set to the directory where these rules files are stored rather than a list? That way, users could also select their own rules files stored anywhere on their system. 2) it might be good in the long run to change the equalization and log flags to an "enhance=" argument. That way other enhancement algorithms (e.g., gaussian) could be added without making a lot of flags. This is a real nice improvement already though. Michael On 4/12/07 2:53 PM, "Glynn Clements" wrote: > > Glynn Clements wrote: > >> Beyond that, I'd like to propose eliminating most of the individual >> G_make_*_colors() functions in favour of a general purpose function >> which takes the name of a rules file as an argument. > > I've done this, and would appreciate it if the changes could receive > some testing. > > The core of r.colors' color=rules and rules= options is now in > lib/gis/color_rules.c. Apart from the lower-level functions used by > r.colors, this provides two new functions: > > int G_make_colors(struct Colors *colors, const char *name, CELL min, CELL > max); > int G_make_fp_colors(struct Colors *colors, const char *name, DCELL min, DCELL > max); > > These effectively supersede most of the G_make_*_[fp_]colors() > functions, i.e.: > > G_make_aspect_colors > G_make_byg_colors > G_make_byr_colors > G_make_grey_scale_colors > G_make_gyr_colors > G_make_rainbow_colors > G_make_ramp_colors > G_make_ryg_colors > G_make_wave_colors > > plus the _fp_ versions. > > A call such as: > > G_make_rainbow_colors(&colors, min, max); > > can be replaced with: > > G_make_colors(&colors, "rainbow", min, max); > > The following functions don't have direct equivalents: > > G_make_histogram_eq_colors > G_make_histogram_log_colors > G_make_random_colors > > The first two can be replaced with a combination of > G_make_colors(&colors, "grey", ...) and either G_histogram_eq_colors() > or G_log_colors(), e.g.: > > G_make_colors(&colors, "grey", min, max); > G_histogram_eq_colors(&colors_tmp, &colors, &statf); > colors = colors_tmp; > or: > G_make_colors(&colors, "grey", min, max); > G_log_colors(&colors_tmp, &colors, 100); > colors = colors_tmp; > > [I will modify G_{histogram_eq,log}_colors to allow the colour table > to be updated in-place, to avoid the need for a temporary variable.] > > G_make_random_colors() cannot be implemented by means of colour rules, > and so will remain. > > The corresponding changes to r.colors are: > > 1. "r.colors color=rules" is implemented using the lower level functions > G_read_color_rules(), G_parse_color_rule() etc, with r.colors itself > handling terminal interaction. > > 2. "r.colors rules=" just calls G_make_fp_colors() with the specified > rule name. > > Also, the rules files have been moved to the lib/gis/color directory. > > The next step is to replace the various G_make_*_[fp_]colors() > functions with wrappers around G_make_[fp_]colors(). Unless that shows > up any problems, I'll replace the use of G_make_*_[fp_]colors() with > direct calls to G_make_[fp_]colors(), and merge the rules= and color= > options in r.colors. __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Fri Apr 13 02:43:22 2007 From: michael.barton at asu.edu (Michael Barton) Date: Fri Apr 13 02:43:31 2007 Subject: [GRASS-dev] problem with r.colors on Mac In-Reply-To: <17950.43600.506857.847594@cerise.gclements.plus.com> Message-ID: Here is a screenshot of Cesium Magnetometry of a Spanish Neolithic site (early farming ca. 4200 BC). I used Glynn's new histogram equalized gyr color table for the magnetometry values and show them in NVIZ. Michael On 4/12/07 2:53 PM, "Glynn Clements" wrote: > > Glynn Clements wrote: > >> Beyond that, I'd like to propose eliminating most of the individual >> G_make_*_colors() functions in favour of a general purpose function >> which takes the name of a rules file as an argument. > > I've done this, and would appreciate it if the changes could receive > some testing. > > The core of r.colors' color=rules and rules= options is now in > lib/gis/color_rules.c. Apart from the lower-level functions used by > r.colors, this provides two new functions: > > int G_make_colors(struct Colors *colors, const char *name, CELL min, CELL > max); > int G_make_fp_colors(struct Colors *colors, const char *name, DCELL min, DCELL > max); > > These effectively supersede most of the G_make_*_[fp_]colors() > functions, i.e.: > > G_make_aspect_colors > G_make_byg_colors > G_make_byr_colors > G_make_grey_scale_colors > G_make_gyr_colors > G_make_rainbow_colors > G_make_ramp_colors > G_make_ryg_colors > G_make_wave_colors > > plus the _fp_ versions. > > A call such as: > > G_make_rainbow_colors(&colors, min, max); > > can be replaced with: > > G_make_colors(&colors, "rainbow", min, max); > > The following functions don't have direct equivalents: > > G_make_histogram_eq_colors > G_make_histogram_log_colors > G_make_random_colors > > The first two can be replaced with a combination of > G_make_colors(&colors, "grey", ...) and either G_histogram_eq_colors() > or G_log_colors(), e.g.: > > G_make_colors(&colors, "grey", min, max); > G_histogram_eq_colors(&colors_tmp, &colors, &statf); > colors = colors_tmp; > or: > G_make_colors(&colors, "grey", min, max); > G_log_colors(&colors_tmp, &colors, 100); > colors = colors_tmp; > > [I will modify G_{histogram_eq,log}_colors to allow the colour table > to be updated in-place, to avoid the need for a temporary variable.] > > G_make_random_colors() cannot be implemented by means of colour rules, > and so will remain. > > The corresponding changes to r.colors are: > > 1. "r.colors color=rules" is implemented using the lower level functions > G_read_color_rules(), G_parse_color_rule() etc, with r.colors itself > handling terminal interaction. > > 2. "r.colors rules=" just calls G_make_fp_colors() with the specified > rule name. > > Also, the rules files have been moved to the lib/gis/color directory. > > The next step is to replace the various G_make_*_[fp_]colors() > functions with wrappers around G_make_[fp_]colors(). Unless that shows > up any problems, I'll replace the use of G_make_*_[fp_]colors() with > direct calls to G_make_[fp_]colors(), and merge the rules= and color= > options in r.colors. __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From hmitaso at unity.ncsu.edu Fri Apr 13 03:02:37 2007 From: hmitaso at unity.ncsu.edu (Helena Mitasova) Date: Fri Apr 13 03:02:42 2007 Subject: [GRASS-dev] ascii export and import, large file problem In-Reply-To: <20070412191018.AOC27897@expms1.cites.uiuc.edu> References: <20070412191018.AOC27897@expms1.cites.uiuc.edu> Message-ID: <3AF5ED2C-7D5B-45F1-99C5-83CC91774120@unity.ncsu.edu> Jerry, r.slope.aspect should work with lat-long, it calls G_distance that says This routine computes the distance, in meters, from * x1,y1 to x2,y2. If the projection is * latitude-longitude, this distance is measured along the geodesic. Two * routines perform geodesic distance calculations. It should also support the wrap-around. Maybe this should be added to the man page. Helena Helena Mitasova Dept. of Marine, Earth and Atm. Sciences 1125 Jordan Hall, NCSU Box 8208, Raleigh NC 27695 http://skagit.meas.ncsu.edu/~helena/ On Apr 12, 2007, at 8:10 PM, Gerald Nelson wrote: > This is related to my earlier question (to which noone responded) > about why the slope calculation can't take lat-long data and just > figure out the slope from the z values. > > The srtm elevation data comes in lat-long values in cells that are > square. In order to get slope, which we need for a cost map, we > project to a utm value in the center of the region we need > (UTM37N). Grass does this projection and generates rectangular > pixels. Then we do the slope calculation and other things to > generate a cost surface. > > We need the ascii output to read the cost data into our custom > neural net program (because we don't have any C programmers, just a > java programmer). > > So its possible that what we observed when we did the export/import > process is a function of the square/rectangular pixel issue > interacting with the arc export/import that assumes pixels are square. > > My ideal would be to not have to take the data out of lat-long, but > I have to do that to use the slope calculations. > > Hope this all makes some sense. > > Regards, Jerry > > ---- Original message ---- >> Date: Thu, 12 Apr 2007 23:58:16 +0100 >> From: Glynn Clements >> Subject: RE: [GRASS-dev] ascii export and import, large file problem >> To: "Jerry Nelson" >> Cc: "'grass-dev'" >> >> >> Jerry Nelson wrote: >> >>>>> I'm using grass6.3 updated today so the large file support for >>>>> the ascii >>>>> commands is included. I export a file using r.out.arc and then >>>>> read it back >>>>> in using r.in.arc. The attached jpg shows the original raster >>>>> on the right. >>>>> The screen on the left is the original raster minus the >>>>> exported and >>>>> imported version. The bottom two thirds or so of the left >>>>> raster is zero, as >>>>> it should be, but the top 1/3 has a bunch of small values >>>>> (range is - to >>>>> +2.9). >>>> >>>> My first guess is that the export->import process is changing the >>>> vertical extent of the map slightly, so the calculation in the >>>> upper >>>> portion of the map is using cells which are off by one row. >>>> >>>> What does r.info say about the bounds of the two maps? >>> >>> To provide more info, >>> >>> The 'after' info >> >>> Rows: 21048 >> >>> Res: 119.047796 >> >>> The 'before' info >> >>> Rows: 21048 >> >>> Res: 119.05225396 >> >> 119.05225396 - 119.047796 = 0.00445796 >> 0.00445796 * 21048 = 93.8311421 >> >> So, the imported map has shrunk by almost a whole cell. That would >> certainly explain the results. >> >> Ah, I see where the problem lies: >> >>> The 'before' info >> >>> Res: 119.05225396 >>> Res: 119.04779557 >> >> Your cells aren't square, but the ArcGrid format doesn't appear to >> allow for non-square cells (single "cellsize" value rather than >> separate x/y values). r.out.arc uses the horizontal resolution for >> the >> cellsize value; if the vertical resolution is different, you lose. >> >> This specific issue can't be fixed. However, if the original data had >> square cells, something is going wrong on the initial import. >> >> We might want to add a check for this to r.out.arc. We can't actually >> do anything beyond warn you that exporting will lose information, >> although that's better than nothing. >> >> -- >> Glynn Clements > Gerald Nelson > Professor, Dept. of Agricultural and Consumer Economics > University of Illinois, Urbana-Champaign > office: 217-333-6465 > cell: 217-390-7888 > 315 Mumford Hall > 1301 W. Gregory > Urbana, IL 61801 > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From glynn at gclements.plus.com Fri Apr 13 05:26:21 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Apr 13 05:26:27 2007 Subject: [GRASS-dev] ascii export and import, large file problem In-Reply-To: <20070412191018.AOC27897@expms1.cites.uiuc.edu> References: <20070412191018.AOC27897@expms1.cites.uiuc.edu> Message-ID: <17950.63581.739945.558699@cerise.gclements.plus.com> Gerald Nelson wrote: > This is related to my earlier question (to which noone responded) > about why the slope calculation can't take lat-long data and just > figure out the slope from the z values. > > The srtm elevation data comes in lat-long values in cells that are > square. In order to get slope, which we need for a cost map, we > project to a utm value in the center of the region we need (UTM37N). > Grass does this projection and generates rectangular pixels. I'm not sure what you're using to perform the projection, but r.proj uses the region settings which the user specifies. If you set a region with rectangular pixels, you get rectangular pixels. Admittedly, there isn't any automatic mechanism to adjust the region bounds to get square pixels; you have to calculate the bounds yourself. If you don't do this explicitly, you're likely to end up with rectangular pixels. [If you use "g.region res=...", GRASS will divide the region extents by the resolution to get the number of rows and columns. These values will then be rounded to the nearest integer, and the actual n-s and e-w resolutions computed by dividing the extents by these integers.] -- Glynn Clements From mlennert at club.worldonline.be Fri Apr 13 13:51:45 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Fri Apr 13 13:48:38 2007 Subject: [GRASS-dev] Re: [GRASS-user] Views in pgSQL In-Reply-To: <461F6066.8050009@amu.edu.pl> References: <20070411100756.GJ7680@bartok.itc.it> <461CBFF0.7090602@amu.edu.pl> <461CC4B2.40203@club.worldonline.be> <461CCB20.2020704@amu.edu.pl> <461CFDE4.1070704@club.worldonline.be> <20070411153714.GB20701@bartok.itc.it> <461D0998.1060903@club.worldonline.be> <461D0E78.2010002@amu.edu.pl> <461F2425.1010008@itc.it> <461F2F6F.6030304@amu.edu.pl> <461F38DD.6080902@club.worldonline.be> <461F6066.8050009@amu.edu.pl> Message-ID: <461F6ED1.9040108@club.worldonline.be> On 13/04/07 12:50, Jaros?aw Jasiewicz wrote: > Thanks a lot for your effort. I just updated my grass source base on > your diff file (only for pg) now I canged files you send me. All seems > to be OK now > As I understand it will be included in cvs soon? If no one objects (to listing views together with tables), I can commit, yes > BTW > I'm not experienced in grass (I work with that system for year now) but > I has worked as an database administaor (on MSSQL Server) for several > years and with arcInfo too. Grass, due to open architecture has much > more posibilites on database managment than most closed systems. You might be interested in a little proof of concept reimplementation I did of d.vect.chart (attached - also see http://grass.itc.it/pipermail/grass5/2006-October/026504.html). This allows you to enter any sql query to chose the data you want to display, thus giving you the freedom to skip view creation and query many different tables at once directly. This obviusly implies a much greater responsibility of the user to make sure the query returns what is needed. I think it would be interesting to think about whether such approach is something to take further in GRASS. Moritz -------------- next part -------------- A non-text attachment was scrubbed... Name: d.vect.chart.sql.tgz Type: application/x-compressed-tar Size: 6489 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070413/c3626830/d.vect.chart.sql.bin From gnelson at uiuc.edu Fri Apr 13 14:18:55 2007 From: gnelson at uiuc.edu (Gerald Nelson) Date: Fri Apr 13 14:19:02 2007 Subject: [GRASS-dev] ascii export and import, large file problem Message-ID: <20070413071855.AOC96207@expms1.cites.uiuc.edu> As an economist, I'm learning that a little GIS information can be a dangerous thing ;-) I was under the impression that you automatically ended up with rectangular pixels if you projected square lat long pixels to say utm. Although I also noticed that arcgis doesn't do that. Is there any way GRASS could be modified to force pixel dimensions to be the same in the output raster as in the input raster, at least as an option? Thanks, Jerry PS yes, we did use r.proj ---- Original message ---- >Date: Fri, 13 Apr 2007 04:26:21 +0100 >From: Glynn Clements >Subject: RE: [GRASS-dev] ascii export and import, large file problem >To: Gerald Nelson >Cc: "'grass-dev'" > > >Gerald Nelson wrote: > >> This is related to my earlier question (to which noone responded) >> about why the slope calculation can't take lat-long data and just >> figure out the slope from the z values. >> >> The srtm elevation data comes in lat-long values in cells that are >> square. In order to get slope, which we need for a cost map, we >> project to a utm value in the center of the region we need (UTM37N). >> Grass does this projection and generates rectangular pixels. > >I'm not sure what you're using to perform the projection, but r.proj >uses the region settings which the user specifies. If you set a region >with rectangular pixels, you get rectangular pixels. > >Admittedly, there isn't any automatic mechanism to adjust the region >bounds to get square pixels; you have to calculate the bounds >yourself. If you don't do this explicitly, you're likely to end up >with rectangular pixels. > >[If you use "g.region res=...", GRASS will divide the region extents >by the resolution to get the number of rows and columns. These values >will then be rounded to the nearest integer, and the actual n-s and >e-w resolutions computed by dividing the extents by these integers.] > >-- >Glynn Clements Gerald Nelson Professor, Dept. of Agricultural and Consumer Economics University of Illinois, Urbana-Champaign office: 217-333-6465 cell: 217-390-7888 315 Mumford Hall 1301 W. Gregory Urbana, IL 61801 From gnelson at uiuc.edu Fri Apr 13 14:39:31 2007 From: gnelson at uiuc.edu (Gerald Nelson) Date: Fri Apr 13 14:39:35 2007 Subject: [GRASS-dev] ascii export and import, large file problem Message-ID: <20070413073931.AOC98228@expms1.cites.uiuc.edu> Helena, I think the issue when I tried this before is that grass doesn't know that x and y are in degrees while z is in meters. It either assumes they are the same or uses the zfactor option to multiply the z value by something to get it into the same units as x and y. But if I could tell grass that the z units were meters explicitly, couldn't grass do the conversion automatically? Especially since the conversion changes as you move north. Jerry ---- Original message ---- >Date: Thu, 12 Apr 2007 21:02:37 -0400 >From: Helena Mitasova >Subject: Re: [GRASS-dev] ascii export and import, large file problem >To: Gerald Nelson >Cc: grass-dev list > >Jerry, > >r.slope.aspect should work with lat-long, it calls G_distance that says > >This routine computes the distance, in meters, from >* x1,y1 to x2,y2. If the projection is >* latitude-longitude, this distance is measured along the geodesic. Two >* routines perform geodesic distance calculations. > >It should also support the wrap-around. > >Maybe this should be added to the man page. > >Helena > >Helena Mitasova >Dept. of Marine, Earth and Atm. Sciences >1125 Jordan Hall, NCSU Box 8208, >Raleigh NC 27695 >http://skagit.meas.ncsu.edu/~helena/ > > > >On Apr 12, 2007, at 8:10 PM, Gerald Nelson wrote: > >> This is related to my earlier question (to which noone responded) >> about why the slope calculation can't take lat-long data and just >> figure out the slope from the z values. >> >> The srtm elevation data comes in lat-long values in cells that are >> square. In order to get slope, which we need for a cost map, we >> project to a utm value in the center of the region we need >> (UTM37N). Grass does this projection and generates rectangular >> pixels. Then we do the slope calculation and other things to >> generate a cost surface. >> >> We need the ascii output to read the cost data into our custom >> neural net program (because we don't have any C programmers, just a >> java programmer). >> >> So its possible that what we observed when we did the export/import >> process is a function of the square/rectangular pixel issue >> interacting with the arc export/import that assumes pixels are square. >> >> My ideal would be to not have to take the data out of lat-long, but >> I have to do that to use the slope calculations. >> >> Hope this all makes some sense. >> >> Regards, Jerry >> >> ---- Original message ---- >>> Date: Thu, 12 Apr 2007 23:58:16 +0100 >>> From: Glynn Clements >>> Subject: RE: [GRASS-dev] ascii export and import, large file problem >>> To: "Jerry Nelson" >>> Cc: "'grass-dev'" >>> >>> >>> Jerry Nelson wrote: >>> >>>>>> I'm using grass6.3 updated today so the large file support for >>>>>> the ascii >>>>>> commands is included. I export a file using r.out.arc and then >>>>>> read it back >>>>>> in using r.in.arc. The attached jpg shows the original raster >>>>>> on the right. >>>>>> The screen on the left is the original raster minus the >>>>>> exported and >>>>>> imported version. The bottom two thirds or so of the left >>>>>> raster is zero, as >>>>>> it should be, but the top 1/3 has a bunch of small values >>>>>> (range is - to >>>>>> +2.9). >>>>> >>>>> My first guess is that the export->import process is changing the >>>>> vertical extent of the map slightly, so the calculation in the >>>>> upper >>>>> portion of the map is using cells which are off by one row. >>>>> >>>>> What does r.info say about the bounds of the two maps? >>>> >>>> To provide more info, >>>> >>>> The 'after' info >>> >>>> Rows: 21048 >>> >>>> Res: 119.047796 >>> >>>> The 'before' info >>> >>>> Rows: 21048 >>> >>>> Res: 119.05225396 >>> >>> 119.05225396 - 119.047796 = 0.00445796 >>> 0.00445796 * 21048 = 93.8311421 >>> >>> So, the imported map has shrunk by almost a whole cell. That would >>> certainly explain the results. >>> >>> Ah, I see where the problem lies: >>> >>>> The 'before' info >>> >>>> Res: 119.05225396 >>>> Res: 119.04779557 >>> >>> Your cells aren't square, but the ArcGrid format doesn't appear to >>> allow for non-square cells (single "cellsize" value rather than >>> separate x/y values). r.out.arc uses the horizontal resolution for >>> the >>> cellsize value; if the vertical resolution is different, you lose. >>> >>> This specific issue can't be fixed. However, if the original data had >>> square cells, something is going wrong on the initial import. >>> >>> We might want to add a check for this to r.out.arc. We can't actually >>> do anything beyond warn you that exporting will lose information, >>> although that's better than nothing. >>> >>> -- >>> Glynn Clements >> Gerald Nelson >> Professor, Dept. of Agricultural and Consumer Economics >> University of Illinois, Urbana-Champaign >> office: 217-333-6465 >> cell: 217-390-7888 >> 315 Mumford Hall >> 1301 W. Gregory >> Urbana, IL 61801 >> >> _______________________________________________ >> grass-dev mailing list >> grass-dev@grass.itc.it >> http://grass.itc.it/mailman/listinfo/grass-dev > Gerald Nelson Professor, Dept. of Agricultural and Consumer Economics University of Illinois, Urbana-Champaign office: 217-333-6465 cell: 217-390-7888 315 Mumford Hall 1301 W. Gregory Urbana, IL 61801 From hmitaso at unity.ncsu.edu Fri Apr 13 15:13:26 2007 From: hmitaso at unity.ncsu.edu (Helena Mitasova) Date: Fri Apr 13 15:13:31 2007 Subject: [GRASS-dev] ascii export and import, large file problem In-Reply-To: <20070413073931.AOC98228@expms1.cites.uiuc.edu> References: <20070413073931.AOC98228@expms1.cites.uiuc.edu> Message-ID: On Apr 13, 2007, at 8:39 AM, Gerald Nelson wrote: > Helena, I think the issue when I tried this before is that grass > doesn't know that x and y are in degrees while z is in meters. It > either assumes they are the same or uses the zfactor option to > multiply the z value by something to get it into the same units as > x and y. that issue relates to feet - r.slope.aspect converts x,y, or rather the horizontal distance derived from x,y to meters (so if it is lat/long, feet, or anything else defined in PROJ_UNIT it converts it to meters) si if you elevations are in anything else than meters - you have to be careful and convert also your elevation to meters because GRASS has no way of knowing you elevation units. So if your elevation is in meters, you should be fine. Let me know if not. I always project the lat/ long data because I work in smaller areas and it is easier to work with x,y than long.lat so I have never tried computation of slope in long/lat, but by looking at the code it should work. > > But if I could tell grass that the z units were meters explicitly, > couldn't grass do the conversion automatically? as I explained above - GRASS assumes it is in meters. > Especially since the conversion changes as you move north. yes, it uses geodesic to covert - that is what I was trying to say in my email below: "If the projection is latitude-longitude, this distance is measured along the geodesic." I hope this helps - it is kind of messy, Helena > > Jerry > > ---- Original message ---- >> Date: Thu, 12 Apr 2007 21:02:37 -0400 >> From: Helena Mitasova >> Subject: Re: [GRASS-dev] ascii export and import, large file problem >> To: Gerald Nelson >> Cc: grass-dev list >> >> Jerry, >> >> r.slope.aspect should work with lat-long, it calls G_distance that >> says >> >> This routine computes the distance, in meters, from >> * x1,y1 to x2,y2. Two >> * routines perform geodesic distance calculations. >> >> It should also support the wrap-around. >> >> Maybe this should be added to the man page. >> >> Helena >> >> Helena Mitasova >> Dept. of Marine, Earth and Atm. Sciences >> 1125 Jordan Hall, NCSU Box 8208, >> Raleigh NC 27695 >> http://skagit.meas.ncsu.edu/~helena/ >> >> >> >> On Apr 12, 2007, at 8:10 PM, Gerald Nelson wrote: >> >>> This is related to my earlier question (to which noone responded) >>> about why the slope calculation can't take lat-long data and just >>> figure out the slope from the z values. >>> >>> The srtm elevation data comes in lat-long values in cells that are >>> square. In order to get slope, which we need for a cost map, we >>> project to a utm value in the center of the region we need >>> (UTM37N). Grass does this projection and generates rectangular >>> pixels. Then we do the slope calculation and other things to >>> generate a cost surface. >>> >>> We need the ascii output to read the cost data into our custom >>> neural net program (because we don't have any C programmers, just a >>> java programmer). >>> >>> So its possible that what we observed when we did the export/import >>> process is a function of the square/rectangular pixel issue >>> interacting with the arc export/import that assumes pixels are >>> square. >>> >>> My ideal would be to not have to take the data out of lat-long, but >>> I have to do that to use the slope calculations. >>> >>> Hope this all makes some sense. >>> >>> Regards, Jerry >>> >>> ---- Original message ---- >>>> Date: Thu, 12 Apr 2007 23:58:16 +0100 >>>> From: Glynn Clements >>>> Subject: RE: [GRASS-dev] ascii export and import, large file >>>> problem >>>> To: "Jerry Nelson" >>>> Cc: "'grass-dev'" >>>> >>>> >>>> Jerry Nelson wrote: >>>> >>>>>>> I'm using grass6.3 updated today so the large file support for >>>>>>> the ascii >>>>>>> commands is included. I export a file using r.out.arc and then >>>>>>> read it back >>>>>>> in using r.in.arc. The attached jpg shows the original raster >>>>>>> on the right. >>>>>>> The screen on the left is the original raster minus the >>>>>>> exported and >>>>>>> imported version. The bottom two thirds or so of the left >>>>>>> raster is zero, as >>>>>>> it should be, but the top 1/3 has a bunch of small values >>>>>>> (range is - to >>>>>>> +2.9). >>>>>> >>>>>> My first guess is that the export->import process is changing the >>>>>> vertical extent of the map slightly, so the calculation in the >>>>>> upper >>>>>> portion of the map is using cells which are off by one row. >>>>>> >>>>>> What does r.info say about the bounds of the two maps? >>>>> >>>>> To provide more info, >>>>> >>>>> The 'after' info >>>> >>>>> Rows: 21048 >>>> >>>>> Res: 119.047796 >>>> >>>>> The 'before' info >>>> >>>>> Rows: 21048 >>>> >>>>> Res: 119.05225396 >>>> >>>> 119.05225396 - 119.047796 = 0.00445796 >>>> 0.00445796 * 21048 = 93.8311421 >>>> >>>> So, the imported map has shrunk by almost a whole cell. That would >>>> certainly explain the results. >>>> >>>> Ah, I see where the problem lies: >>>> >>>>> The 'before' info >>>> >>>>> Res: 119.05225396 >>>>> Res: 119.04779557 >>>> >>>> Your cells aren't square, but the ArcGrid format doesn't appear to >>>> allow for non-square cells (single "cellsize" value rather than >>>> separate x/y values). r.out.arc uses the horizontal resolution for >>>> the >>>> cellsize value; if the vertical resolution is different, you lose. >>>> >>>> This specific issue can't be fixed. However, if the original >>>> data had >>>> square cells, something is going wrong on the initial import. >>>> >>>> We might want to add a check for this to r.out.arc. We can't >>>> actually >>>> do anything beyond warn you that exporting will lose information, >>>> although that's better than nothing. >>>> >>>> -- >>>> Glynn Clements >>> Gerald Nelson >>> Professor, Dept. of Agricultural and Consumer Economics >>> University of Illinois, Urbana-Champaign >>> office: 217-333-6465 >>> cell: 217-390-7888 >>> 315 Mumford Hall >>> 1301 W. Gregory >>> Urbana, IL 61801 >>> >>> _______________________________________________ >>> grass-dev mailing list >>> grass-dev@grass.itc.it >>> http://grass.itc.it/mailman/listinfo/grass-dev >> > Gerald Nelson > Professor, Dept. of Agricultural and Consumer Economics > University of Illinois, Urbana-Champaign > office: 217-333-6465 > cell: 217-390-7888 > 315 Mumford Hall > 1301 W. Gregory > Urbana, IL 61801 From gnelson at uiuc.edu Fri Apr 13 15:28:35 2007 From: gnelson at uiuc.edu (Gerald Nelson) Date: Fri Apr 13 15:28:38 2007 Subject: [GRASS-dev] ascii export and import, large file problem Message-ID: <20070413082835.AOD04120@expms1.cites.uiuc.edu> Helena, I think grass assumes x,y, and z are all in the same units when it does the slope calculation. At least when I run r.slope.aspect on my lat long file I get junk out but when I project it to utm and then run r.slope.aspect I get numbers that look reasonable. Jerry ---- Original message ---- >Date: Fri, 13 Apr 2007 09:13:26 -0400 >From: Helena Mitasova >Subject: Re: [GRASS-dev] ascii export and import, large file problem >To: Gerald Nelson >Cc: grass-dev list > > >On Apr 13, 2007, at 8:39 AM, Gerald Nelson wrote: > >> Helena, I think the issue when I tried this before is that grass >> doesn't know that x and y are in degrees while z is in meters. It >> either assumes they are the same or uses the zfactor option to >> multiply the z value by something to get it into the same units as >> x and y. > >that issue relates to feet - r.slope.aspect converts x,y, or rather >the horizontal distance derived from x,y >to meters (so if it is lat/long, feet, or anything else defined in >PROJ_UNIT it converts it to meters) >si if you elevations are in anything else than meters - you have to >be careful and convert also your elevation to meters >because GRASS has no way of knowing you elevation units. So if your >elevation is in meters, >you should be fine. Let me know if not. I always project the lat/ >long data because I work in smaller >areas and it is easier to work with x,y than long.lat so I have never >tried computation of slope >in long/lat, but by looking at the code it should work. >> >> But if I could tell grass that the z units were meters explicitly, >> couldn't grass do the conversion automatically? > >as I explained above - GRASS assumes it is in meters. > >> Especially since the conversion changes as you move north. > >yes, it uses geodesic to covert - that is what I was trying to say in >my email below: > >"If the projection is latitude-longitude, this distance is measured >along the geodesic." > >I hope this helps - it is kind of messy, > >Helena >> >> Jerry >> >> ---- Original message ---- >>> Date: Thu, 12 Apr 2007 21:02:37 -0400 >>> From: Helena Mitasova >>> Subject: Re: [GRASS-dev] ascii export and import, large file problem >>> To: Gerald Nelson >>> Cc: grass-dev list >>> >>> Jerry, >>> >>> r.slope.aspect should work with lat-long, it calls G_distance that >>> says >>> >>> This routine computes the distance, in meters, from >>> * x1,y1 to x2,y2. Two >>> * routines perform geodesic distance calculations. >>> >>> It should also support the wrap-around. >>> >>> Maybe this should be added to the man page. >>> >>> Helena >>> >>> Helena Mitasova >>> Dept. of Marine, Earth and Atm. Sciences >>> 1125 Jordan Hall, NCSU Box 8208, >>> Raleigh NC 27695 >>> http://skagit.meas.ncsu.edu/~helena/ >>> >>> >>> >>> On Apr 12, 2007, at 8:10 PM, Gerald Nelson wrote: >>> >>>> This is related to my earlier question (to which noone responded) >>>> about why the slope calculation can't take lat-long data and just >>>> figure out the slope from the z values. >>>> >>>> The srtm elevation data comes in lat-long values in cells that are >>>> square. In order to get slope, which we need for a cost map, we >>>> project to a utm value in the center of the region we need >>>> (UTM37N). Grass does this projection and generates rectangular >>>> pixels. Then we do the slope calculation and other things to >>>> generate a cost surface. >>>> >>>> We need the ascii output to read the cost data into our custom >>>> neural net program (because we don't have any C programmers, just a >>>> java programmer). >>>> >>>> So its possible that what we observed when we did the export/import >>>> process is a function of the square/rectangular pixel issue >>>> interacting with the arc export/import that assumes pixels are >>>> square. >>>> >>>> My ideal would be to not have to take the data out of lat-long, but >>>> I have to do that to use the slope calculations. >>>> >>>> Hope this all makes some sense. >>>> >>>> Regards, Jerry >>>> >>>> ---- Original message ---- >>>>> Date: Thu, 12 Apr 2007 23:58:16 +0100 >>>>> From: Glynn Clements >>>>> Subject: RE: [GRASS-dev] ascii export and import, large file >>>>> problem >>>>> To: "Jerry Nelson" >>>>> Cc: "'grass-dev'" >>>>> >>>>> >>>>> Jerry Nelson wrote: >>>>> >>>>>>>> I'm using grass6.3 updated today so the large file support for >>>>>>>> the ascii >>>>>>>> commands is included. I export a file using r.out.arc and then >>>>>>>> read it back >>>>>>>> in using r.in.arc. The attached jpg shows the original raster >>>>>>>> on the right. >>>>>>>> The screen on the left is the original raster minus the >>>>>>>> exported and >>>>>>>> imported version. The bottom two thirds or so of the left >>>>>>>> raster is zero, as >>>>>>>> it should be, but the top 1/3 has a bunch of small values >>>>>>>> (range is - to >>>>>>>> +2.9). >>>>>>> >>>>>>> My first guess is that the export->import process is changing the >>>>>>> vertical extent of the map slightly, so the calculation in the >>>>>>> upper >>>>>>> portion of the map is using cells which are off by one row. >>>>>>> >>>>>>> What does r.info say about the bounds of the two maps? >>>>>> >>>>>> To provide more info, >>>>>> >>>>>> The 'after' info >>>>> >>>>>> Rows: 21048 >>>>> >>>>>> Res: 119.047796 >>>>> >>>>>> The 'before' info >>>>> >>>>>> Rows: 21048 >>>>> >>>>>> Res: 119.05225396 >>>>> >>>>> 119.05225396 - 119.047796 = 0.00445796 >>>>> 0.00445796 * 21048 = 93.8311421 >>>>> >>>>> So, the imported map has shrunk by almost a whole cell. That would >>>>> certainly explain the results. >>>>> >>>>> Ah, I see where the problem lies: >>>>> >>>>>> The 'before' info >>>>> >>>>>> Res: 119.05225396 >>>>>> Res: 119.04779557 >>>>> >>>>> Your cells aren't square, but the ArcGrid format doesn't appear to >>>>> allow for non-square cells (single "cellsize" value rather than >>>>> separate x/y values). r.out.arc uses the horizontal resolution for >>>>> the >>>>> cellsize value; if the vertical resolution is different, you lose. >>>>> >>>>> This specific issue can't be fixed. However, if the original >>>>> data had >>>>> square cells, something is going wrong on the initial import. >>>>> >>>>> We might want to add a check for this to r.out.arc. We can't >>>>> actually >>>>> do anything beyond warn you that exporting will lose information, >>>>> although that's better than nothing. >>>>> >>>>> -- >>>>> Glynn Clements >>>> Gerald Nelson >>>> Professor, Dept. of Agricultural and Consumer Economics >>>> University of Illinois, Urbana-Champaign >>>> office: 217-333-6465 >>>> cell: 217-390-7888 >>>> 315 Mumford Hall >>>> 1301 W. Gregory >>>> Urbana, IL 61801 >>>> >>>> _______________________________________________ >>>> grass-dev mailing list >>>> grass-dev@grass.itc.it >>>> http://grass.itc.it/mailman/listinfo/grass-dev >>> >> Gerald Nelson >> Professor, Dept. of Agricultural and Consumer Economics >> University of Illinois, Urbana-Champaign >> office: 217-333-6465 >> cell: 217-390-7888 >> 315 Mumford Hall >> 1301 W. Gregory >> Urbana, IL 61801 > Gerald Nelson Professor, Dept. of Agricultural and Consumer Economics University of Illinois, Urbana-Champaign office: 217-333-6465 cell: 217-390-7888 315 Mumford Hall 1301 W. Gregory Urbana, IL 61801 From glynn at gclements.plus.com Fri Apr 13 16:32:24 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Apr 13 16:32:27 2007 Subject: [GRASS-dev] ascii export and import, large file problem In-Reply-To: <20070413071855.AOC96207@expms1.cites.uiuc.edu> References: <20070413071855.AOC96207@expms1.cites.uiuc.edu> Message-ID: <17951.38008.961352.184738@cerise.gclements.plus.com> Gerald Nelson wrote: > > I'm not sure what you're using to perform the projection, but r.proj > > uses the region settings which the user specifies. If you set a region > > with rectangular pixels, you get rectangular pixels. > > > > Admittedly, there isn't any automatic mechanism to adjust the region > > bounds to get square pixels; you have to calculate the bounds > > yourself. If you don't do this explicitly, you're likely to end up > > with rectangular pixels. > > > > [If you use "g.region res=...", GRASS will divide the region extents > > by the resolution to get the number of rows and columns. These values > > will then be rounded to the nearest integer, and the actual n-s and > > e-w resolutions computed by dividing the extents by these integers.] > > As an economist, I'm learning that a little GIS information can be a > dangerous thing ;-) > > I was under the impression that you automatically ended up with > rectangular pixels if you projected square lat long pixels to say utm. > Although I also noticed that arcgis doesn't do that. If you apply most cartographic projections to straight lines, you end up with curves. IOW, not only are projected squares not square, they aren't even rectangles, or even quadrilaterals. Obviously, that isn't a particularly good fit for raster data. So, what r.proj (and most other raster projection tools) do is to inverse-project the centres of the destination cells into the original coordinate system, and sample the source data at the projected points. The end result is that the projected raster has the exact grid which the user specifies via g.region. > Is there any way GRASS could be modified to force pixel dimensions to > be the same in the output raster as in the input raster, at least as > an option? No. "same size" isn't meaningful when one set of data is in degrees and the other is in metres (or occasionally US survey feet). What *would* be possible would be to add an option to g.region to adjust the extents rather than the resolution. This would make it straightforward to get square cells without having to manually calculate appropriate bounds. Uh; hang on; this is what "g.region -a" does (although it has a side-effect of shifting the grid slightly). If you use e.g. "g.region -a res=119.05", you should get cells which are exactly 119.05x119.05m. -- Glynn Clements From glynn at gclements.plus.com Fri Apr 13 16:51:47 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Apr 13 16:51:49 2007 Subject: [GRASS-dev] ascii export and import, large file problem In-Reply-To: <20070413082835.AOD04120@expms1.cites.uiuc.edu> References: <20070413082835.AOD04120@expms1.cites.uiuc.edu> Message-ID: <17951.39171.353385.223868@cerise.gclements.plus.com> Gerald Nelson wrote: > Helena, I think grass assumes x,y, and z are all in the same units > when it does the slope calculation. At least when I run r.slope.aspect > on my lat long file I get junk out but when I project it to utm and > then run r.slope.aspect I get numbers that look reasonable. I get reasonable slope values out of r.slope.aspect for a lat/lon location. As Helena says, it uses geodesic distance for lat/lon locations (if you haven't specified an ellipsoid, it defaults to WGS84). -- Glynn Clements From landa.martin at gmail.com Fri Apr 13 17:12:58 2007 From: landa.martin at gmail.com (Martin Landa) Date: Fri Apr 13 17:13:02 2007 Subject: [GRASS-dev] v.edit tool=flip Message-ID: Hi, I added new tool to v.edit module - 'flip' which flips direction of all selected vector lines. This tool is inspired by v.flip script (thanks Maciek). Testing appreciated. Regards, Martin -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From gnelson at uiuc.edu Fri Apr 13 18:43:09 2007 From: gnelson at uiuc.edu (Jerry Nelson) Date: Fri Apr 13 18:43:34 2007 Subject: [GRASS-dev] ascii export and import, large file problem In-Reply-To: <17950.47496.587551.524069@cerise.gclements.plus.com> References: <008f01c77c83$7234a040$3e40ae80@ace.uiuc.edu><17950.17768.300890.594225@cerise.gclements.plus.com><00e201c77d51$1310f590$3e40ae80@ace.uiuc.edu> <17950.47496.587551.524069@cerise.gclements.plus.com> Message-ID: <010001c77dea$d6748c10$3e40ae80@ace.uiuc.edu> An update on ascii export and import. When we set decimals to 16 in the export and import commands, the difference worked as expected; that is, there is no difference between the original and the exported/imported/ new version. Is this something that needs to be put in the documentation? Jerry -----Original Message----- From: Glynn Clements [mailto:glynn@gclements.plus.com] Sent: Thursday, April 12, 2007 5:58 PM To: Jerry Nelson Cc: 'grass-dev' Subject: RE: [GRASS-dev] ascii export and import, large file problem Jerry Nelson wrote: > > > I'm using grass6.3 updated today so the large file support for the ascii > > > commands is included. I export a file using r.out.arc and then read it back > > > in using r.in.arc. The attached jpg shows the original raster on the right. > > > The screen on the left is the original raster minus the exported and > > > imported version. The bottom two thirds or so of the left raster is zero, as > > > it should be, but the top 1/3 has a bunch of small values (range is - to > > > +2.9). > > > > My first guess is that the export->import process is changing the > > vertical extent of the map slightly, so the calculation in the upper > > portion of the map is using cells which are off by one row. > > > > What does r.info say about the bounds of the two maps? > > To provide more info, > > The 'after' info > Rows: 21048 > Res: 119.047796 > The 'before' info > Rows: 21048 > Res: 119.05225396 119.05225396 - 119.047796 = 0.00445796 0.00445796 * 21048 = 93.8311421 So, the imported map has shrunk by almost a whole cell. That would certainly explain the results. Ah, I see where the problem lies: > The 'before' info > Res: 119.05225396 > Res: 119.04779557 Your cells aren't square, but the ArcGrid format doesn't appear to allow for non-square cells (single "cellsize" value rather than separate x/y values). r.out.arc uses the horizontal resolution for the cellsize value; if the vertical resolution is different, you lose. This specific issue can't be fixed. However, if the original data had square cells, something is going wrong on the initial import. We might want to add a check for this to r.out.arc. We can't actually do anything beyond warn you that exporting will lose information, although that's better than nothing. -- Glynn Clements From glynn at gclements.plus.com Fri Apr 13 20:02:16 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Apr 13 20:02:19 2007 Subject: [GRASS-dev] ascii export and import, large file problem In-Reply-To: <010001c77dea$d6748c10$3e40ae80@ace.uiuc.edu> References: <008f01c77c83$7234a040$3e40ae80@ace.uiuc.edu> <17950.17768.300890.594225@cerise.gclements.plus.com> <00e201c77d51$1310f590$3e40ae80@ace.uiuc.edu> <17950.47496.587551.524069@cerise.gclements.plus.com> <010001c77dea$d6748c10$3e40ae80@ace.uiuc.edu> Message-ID: <17951.50600.641236.397297@cerise.gclements.plus.com> Jerry Nelson wrote: > An update on ascii export and import. When we set decimals to 16 in the > export and import commands, the difference worked as expected; that is, > there is no difference between the original and the exported/imported/ new > version. Is this something that needs to be put in the documentation? Jerry You're omitting something important: the details of the projection step. r.proj projects into an existing region; it doesn't create it itself. Something created that region, and that's where everything went wrong. Beyond that, if you export an ArcGrid file from a region with non-square pixels, then re-import that file, the result will be wrong however many decimal places you use. -- Glynn Clements From glynn at gclements.plus.com Fri Apr 13 20:10:07 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Apr 13 20:10:15 2007 Subject: Updated r.colors - was: [GRASS-dev] problem with r.colors on Mac In-Reply-To: References: <17950.43600.506857.847594@cerise.gclements.plus.com> Message-ID: <17951.51071.57866.338751@cerise.gclements.plus.com> Michael Barton wrote: > 1) for the rules entry, can it be a browse prompt initially set to the > directory where these rules files are stored rather than a list? That way, > users could also select their own rules files stored anywhere on their > system. As I've mentioned before, that isn't the purpose of the rules= option. Once I've merged the rules= and color= options, I can re-use the rules= option to read rules from a file (but I don't think that you can specify a default directory for a file option). Beyond that, it may be worth replacing colour=rules with a flag. Or even a completely separate r.colors.rules module (I think I've already expressed my opinions on having an interactive mode in a module which is otherwise non-interactive). For now, I'm going to wait to see if any issues arise from the most recent round of changes. > 2) it might be good in the long run to change the equalization and log flags > to an "enhance=" argument. That way other enhancement algorithms (e.g., > gaussian) could be added without making a lot of flags. I'll look into it either when I eventually deal with the rules=/color= issue (probably 7.x) or when another "modifier" actually gets added. -- Glynn Clements From glynn at gclements.plus.com Fri Apr 13 20:11:48 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Apr 13 20:11:50 2007 Subject: [GRASS-dev] problem with r.colors on Mac In-Reply-To: <17950.43600.506857.847594@cerise.gclements.plus.com> References: <17948.16915.391634.256480@cerise.gclements.plus.com> <17948.48049.681105.666051@cerise.gclements.plus.com> <20070411114349.GB13640@bartok.itc.it> <17949.2993.124827.851219@cerise.gclements.plus.com> <17950.43600.506857.847594@cerise.gclements.plus.com> Message-ID: <17951.51172.95270.377963@cerise.gclements.plus.com> Glynn Clements wrote: > The next step is to replace the various G_make_*_[fp_]colors() > functions with wrappers around G_make_[fp_]colors(). Done. I'm going to leave it alone for now, to see if any issues arise. -- Glynn Clements From frankie at debian.org Fri Apr 13 21:10:17 2007 From: frankie at debian.org (Francesco Paolo Lovergine) Date: Fri Apr 13 21:10:10 2007 Subject: [GRASS-dev] terracost and large files more generally In-Reply-To: <20070407132311.GD22553@bartok.itc.it> References: <20070407081339.ANU03132@expms1.cites.uiuc.edu> <20070407132311.GD22553@bartok.itc.it> Message-ID: <20070413191016.GA3508@ba.issia.cnr.it> On Sat, Apr 07, 2007 at 03:23:11PM +0200, Markus Neteler wrote: > On Sat, Apr 07, 2007 at 08:13:39AM -0500, Gerald Nelson wrote: > > While you (plural) are cranking on the next release, it's probably not the best time to ask but... > > > > - would it be possible to add the terracost functionality to r.cost (http://www.bowdoin.edu/~ltoma/research.html). My impression is that for a C programmer it would be fairly easy. > > > > - file size limitations issues. I'm bumping up against a 2 gb limit in r.out.arc. We're using grass6.3, compiled with large file support and we can't export files that would be larger than 2 gb. My postdoc (who knows java but not C) and I looked at the source code for r.out.arc and couldn't see any obvious reason why there would be a size limit. > > > > It would be good to use this as motivation to better document > the needed steps as already drafted here: > http://grass.gdf-hannover.de/wiki/Large_File_Support > I would also add to that page that some exporting/inporting formats have their own intrinsic limitations, see for instance: http://www.gdal.org/formats_list.html -- Francesco P. Lovergine From michael.barton at asu.edu Sat Apr 14 03:17:07 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sat Apr 14 03:17:26 2007 Subject: Updated r.colors - was: [GRASS-dev] problem with r.colors on Mac In-Reply-To: <17951.51071.57866.338751@cerise.gclements.plus.com> Message-ID: Hi Glynn, I guess I wasn't very clear on this. On 4/13/07 11:10 AM, "Glynn Clements" wrote: > Once I've merged the rules= and color= options, I can re-use the > rules= option to read rules from a file (but I don't think that you > can specify a default directory for a file option). > > Beyond that, it may be worth replacing colour=rules with a flag. Or > even a completely separate r.colors.rules module (I think I've already > expressed my opinions on having an interactive mode in a module which > is otherwise non-interactive). Heavens NO! No interactive mode. I just meant that currently the rules option only allows you to specify the names of color table files located in $GISBASE/etc/colors. My suggestion is to allow you to specify color table files located anywhere. For example ...as we have now r.colors map=elevation rules=byr ...as I suggest, the following would be permitted r.colors map=elevation rules=/Users/cmbarton/colors/byr When I was talking about a prompt, I meant the gui-prompt in the interface-description xml file. Currently, it calls a list of values that are the names of text files in the $GISBASE/etc/colors directory. As I suggest, this would be replaced by a file browsing prompt (#prompt file,file,file for scripts). Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Sat Apr 14 03:35:47 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sat Apr 14 03:36:04 2007 Subject: [GRASS-dev] impressions on wx GUI In-Reply-To: Message-ID: Done On 4/12/07 5:20 PM, "Michael Barton" wrote: >> >> If I am in the "output" tab of GI manager, and add a new >> raster/vector, I should be sent back to the "layers" tab. > __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From glynn at gclements.plus.com Sat Apr 14 06:15:09 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Apr 14 06:15:13 2007 Subject: Updated r.colors - was: [GRASS-dev] problem with r.colors on Mac In-Reply-To: <17951.51071.57866.338751@cerise.gclements.plus.com> References: <17950.43600.506857.847594@cerise.gclements.plus.com> <17951.51071.57866.338751@cerise.gclements.plus.com> Message-ID: <17952.21837.367173.345059@cerise.gclements.plus.com> Glynn Clements wrote: > Once I've merged the rules= and color= options, I can re-use the > rules= option to read rules from a file (but I don't think that you > can specify a default directory for a file option). I've done that. The colors= option now uses the rules files (except for the grey.eq, grey.log, random and rules choices). The rules= option is now a file option. > Beyond that, it may be worth replacing colour=rules with a flag. Or > even a completely separate r.colors.rules module (I think I've already > expressed my opinions on having an interactive mode in a module which > is otherwise non-interactive). For now, I've added a flag (-i), and retained color=rules. -- Glynn Clements From michael.barton at asu.edu Sat Apr 14 07:13:38 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sat Apr 14 07:14:01 2007 Subject: Updated r.colors - was: [GRASS-dev] problem with r.colors on Mac In-Reply-To: <17952.21837.367173.345059@cerise.gclements.plus.com> Message-ID: Many thanks. This can open up r.colors to user submitted color tables. I'm looking forward to trying this out. Michael On 4/13/07 9:15 PM, "Glynn Clements" wrote: > > Glynn Clements wrote: > >> Once I've merged the rules= and color= options, I can re-use the >> rules= option to read rules from a file (but I don't think that you >> can specify a default directory for a file option). > > I've done that. The colors= option now uses the rules files (except > for the grey.eq, grey.log, random and rules choices). The rules= > option is now a file option. > >> Beyond that, it may be worth replacing colour=rules with a flag. Or >> even a completely separate r.colors.rules module (I think I've already >> expressed my opinions on having an interactive mode in a module which >> is otherwise non-interactive). > > For now, I've added a flag (-i), and retained color=rules. __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Sat Apr 14 09:26:21 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sat Apr 14 09:26:39 2007 Subject: [GRASS-dev] impressions on wx GUI In-Reply-To: Message-ID: Done for layer delete AND for querying multiple raster/vector maps simultaneously Michael On 4/12/07 5:20 PM, "Michael Barton" wrote: >> >> Multiple selection of layers in GIS Manager. If you want to delete >> several layers, it is a pain to do it one by one. > > Duly noted. Multiple drag and drop is more difficult however. __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From neteler at itc.it Sat Apr 14 14:27:46 2007 From: neteler at itc.it (Markus Neteler) Date: Sat Apr 14 14:27:48 2007 Subject: [GRASS-dev] terracost and large files more generally In-Reply-To: <20070413191016.GA3508@ba.issia.cnr.it> References: <20070407081339.ANU03132@expms1.cites.uiuc.edu> <20070407132311.GD22553@bartok.itc.it> <20070413191016.GA3508@ba.issia.cnr.it> Message-ID: <20070414122746.GF13794@bartok.itc.it> On Fri, Apr 13, 2007 at 09:10:17PM +0200, Francesco Paolo Lovergine wrote: > On Sat, Apr 07, 2007 at 03:23:11PM +0200, Markus Neteler wrote: > > On Sat, Apr 07, 2007 at 08:13:39AM -0500, Gerald Nelson wrote: ... > > It would be good to use this as motivation to better document > > the needed steps as already drafted here: > > http://grass.gdf-hannover.de/wiki/Large_File_Support > > > > I would also add to that page that some exporting/inporting formats have their > own intrinsic limitations, see for instance: > > http://www.gdal.org/formats_list.html Done. Markus From neteler at itc.it Sat Apr 14 14:30:17 2007 From: neteler at itc.it (Markus Neteler) Date: Sat Apr 14 14:30:18 2007 Subject: [GRASS-dev] Proposal: release 6.2.2 In-Reply-To: <20070406150028.GF25552@bartok.itc.it> References: <20070406150028.GF25552@bartok.itc.it> Message-ID: <20070414123016.GG13794@bartok.itc.it> On Fri, Apr 06, 2007 at 05:00:29PM +0200, Markus Neteler wrote: > Hi, > > I think that we have accumulated enough bugfixes to get > out 6.2.2 by next week. Since it is a bugfix release > only, I don't feel that we need a long testing phase. > > I suggest to get out a release candidate by next > week which can then be compiled and tested and > hopefully published asap. > You may wonder what happened: I had tagged everything, packages and the a bug in gis.m/georectifier was found. Additionally, I discovered that v.lidar* is largely behind. So I stopped the release. State: - Michael will hopefully take a look at the gis.m problem - Roberto is reviewing a set of patches which I prepared for v.lidar*/v.surf.bspline Then RC1 will be done and so forth. Markus From michael.barton at asu.edu Sat Apr 14 18:22:43 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sat Apr 14 18:23:03 2007 Subject: Updated r.colors - was: [GRASS-dev] problem with r.colors on Mac In-Reply-To: <17952.21837.367173.345059@cerise.gclements.plus.com> Message-ID: Glynn, I just did an update this morning and don't see any difference in r.color behavior. r.colors map=elevation_delete rules=/Users/cmbarton/colors/bcyr ...produced an error. Do I need to do a make clean or something? Michael On 4/13/07 9:15 PM, "Glynn Clements" wrote: > > Glynn Clements wrote: > >> Once I've merged the rules= and color= options, I can re-use the >> rules= option to read rules from a file (but I don't think that you >> can specify a default directory for a file option). > > I've done that. The colors= option now uses the rules files (except > for the grey.eq, grey.log, random and rules choices). The rules= > option is now a file option. > >> Beyond that, it may be worth replacing colour=rules with a flag. Or >> even a completely separate r.colors.rules module (I think I've already >> expressed my opinions on having an interactive mode in a module which >> is otherwise non-interactive). > > For now, I've added a flag (-i), and retained color=rules. __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From glynn at gclements.plus.com Sat Apr 14 18:31:13 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Apr 14 18:31:28 2007 Subject: Updated r.colors - was: [GRASS-dev] problem with r.colors on Mac In-Reply-To: References: <17952.21837.367173.345059@cerise.gclements.plus.com> Message-ID: <17953.465.191849.153590@cerise.gclements.plus.com> Michael Barton wrote: > I just did an update this morning and don't see any difference in r.color > behavior. > > r.colors map=elevation_delete rules=/Users/cmbarton/colors/bcyr > > ...produced an error. What error? > Do I need to do a make clean or something? For safety, you should always do "make distclean" when updating from CVS. OTOH, I can't think of any files which need to be re-compiled which haven't themselves changed. That doesn't mean that there aren't any, though. At a minimum, you should try: make -C lib headers make -C lib/gis clean default make -C raster/r.colors clean default -- Glynn Clements From michael.barton at asu.edu Sat Apr 14 18:46:31 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sat Apr 14 18:46:50 2007 Subject: Updated r.colors - was: [GRASS-dev] problem with r.colors on Mac In-Reply-To: <17953.465.191849.153590@cerise.gclements.plus.com> Message-ID: On 4/14/07 9:31 AM, "Glynn Clements" wrote: > > Michael Barton wrote: > >> I just did an update this morning and don't see any difference in r.color >> behavior. >> >> r.colors map=elevation_delete rules=/Users/cmbarton/colors/bcyr >> >> ...produced an error. > > What error? GRASS 6.3.cvs (spearfish60_test):~ > r.colors map=elevation_delete rules=/Users/cmbarton/colors/bcyr ERROR: value out of range for parameter Legal range: aspect,aspectcolr,bcyr,byg,byr,curvature,differences,elevation,etopo2,evi,gr ey,gyr,ndvi,population,rainbow,ramp,ryb,ryg,slope,srtm,terrain,wave > >> Do I need to do a make clean or something? > > For safety, you should always do "make distclean" when updating from > CVS. I'll do this and it will probably fix it. Off to do some errands, but will report back later. Michael > > OTOH, I can't think of any files which need to be re-compiled which > haven't themselves changed. That doesn't mean that there aren't any, > though. > > At a minimum, you should try: > > make -C lib headers > make -C lib/gis clean default > make -C raster/r.colors clean default __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From carlos.grohmann at gmail.com Sat Apr 14 18:58:10 2007 From: carlos.grohmann at gmail.com (=?ISO-8859-1?Q?Carlos_"Gu=E2no"_Grohmann?=) Date: Sat Apr 14 18:58:14 2007 Subject: [GRASS-dev] impressions on wx GUI In-Reply-To: References: Message-ID: Just tested it. Multiple selection of map layers is working fine. I had some problems with the transparency. The first time I set a transparency value, I did not worked. Then I set the overlay flag on, and it worked. then I changed the transparency value and it didn't worked again. when I unset the overlay, it worked... Carlos On 4/14/07, Michael Barton wrote: > Done for layer delete AND for querying multiple raster/vector maps > simultaneously > > Michael > > > On 4/12/07 5:20 PM, "Michael Barton" wrote: > > >> > >> Multiple selection of layers in GIS Manager. If you want to delete > >> several layers, it is a pain to do it one by one. > > > > Duly noted. Multiple drag and drop is more difficult however. > > __________________________________________ > Michael Barton, Professor of Anthropology > School of Human Evolution & Social Change > Center for Social Dynamics & Complexity > Arizona State University > > phone: 480-965-6213 > fax: 480-965-7671 > www: http://www.public.asu.edu/~cmbarton > > > -- +-----------------------------------------------------------+ Carlos Henrique Grohmann - Guano Geologist M.Sc - Doctorate Student at IGc-USP - Brazil Linux User #89721 - carlos dot grohmann at gmail dot com +-----------------------------------------------------------+ _________________ "Good morning, doctors. I have taken the liberty of removing Windows 95 from my hard drive." --The winning entry in a "What were HAL's first words" contest judged by 2001: A SPACE ODYSSEY creator Arthur C. Clarke From glynn at gclements.plus.com Sat Apr 14 23:24:43 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Apr 14 23:24:48 2007 Subject: Updated r.colors - was: [GRASS-dev] problem with r.colors on Mac In-Reply-To: References: <17953.465.191849.153590@cerise.gclements.plus.com> Message-ID: <17953.18075.831990.692294@cerise.gclements.plus.com> Michael Barton wrote: > >> I just did an update this morning and don't see any difference in r.color > >> behavior. > >> > >> r.colors map=elevation_delete rules=/Users/cmbarton/colors/bcyr > >> > >> ...produced an error. > > > > What error? > > GRASS 6.3.cvs (spearfish60_test):~ > r.colors map=elevation_delete rules=/Users/cmbarton/colors/bcyr > > ERROR: value out of range for parameter > > Legal range: > aspect,aspectcolr,bcyr,byg,byr,curvature,differences,elevation,etopo2,evi,gr > ey,gyr,ndvi,population,rainbow,ramp,ryb,ryg,slope,srtm,terrain,wave You're still using the old version. In the updated version, rules= doesn't have an ->options list: opt.rules = G_define_option(); opt.rules->key = "rules"; opt.rules->type = TYPE_STRING; opt.rules->required = NO; opt.rules->description = _("Path to rules file"); opt.rules->gisprompt = "old_file,file,input"; -- Glynn Clements From glynn at gclements.plus.com Sun Apr 15 01:28:36 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Apr 15 01:28:38 2007 Subject: [GRASS-dev] Use of "const", qualified map names Message-ID: <17953.25508.380841.746547@cerise.gclements.plus.com> Glynn Clements wrote: > Which reminds me of another outstanding clean-up task: library > functions should use "const" where appropriate. > > As it stands, functions which take a non-const pointer but which don't > actually modify the value are so common that a lot of application code > tends to just assume that the missing "const" is an oversight and that > the value won't actually be modified. > > Then it gets bitten by when the function really does modify the value > (G_find_cell() is a common culprit, as it strips off any @mapset > suffix from the map name). > > We need to get into the habit of using "const" wherever possible, so > that the lack of it indicates that the string (or other value) really > will be modified (rather than simply indicating that someone forgot > the "const"). > > This needs to happen from the bottom up, as once a function declares a > parameter as "const", it can't pass it to a function which requires a > non-const parameter (using a type cast can hide a real problem, in the > case where the function really does modify the argument). Over the last two days I have gone through libgis and added "const" qualifiers wherever they were appropriate (as well as a few other minor clean-ups). However, this required a subtle API change. Previously, just about every libgis function which accepted parameters of the form (char *name, char *mapset, ...) would end up normalising the name (removing any "@mapset" part). In most cases, this was likely to be accidental: an artifact of using G_find_file() etc. Apart from meaning that you couldn't pass a "const char *" for the name, it could cause problems if you weren't expecting it (certainly, I've been bitten by it at least once). Following my changes, the only functions which should strip the @mapset part from a map name are the G_find_{file,cell,vector} functions (which return the mapset where the file was found). Anything else should leave the name intact (but will still honour any @mapset part). There is a remote possibility that some module somewhere was actually relying upon the existing behaviour (rather than using G_find_*() to explicitly normalise the name). As this would be almost impossible to track down methodically, all that I can suggest is to be on the lookout for modules misbehaving when given qualified map names. On a related note, I've modified the Tk map browser (lib/gtcltk/select.tcl) to always include the @mapset part in map names. Previously, it omitted it if the mapset was the current mapset, which will fail if you have other mapsets ahead of the current mapset in the search path. [Note: you can't make this check at the point that the map was selected, as the mapset path might be modified afterwards. Then, redisplay would suddenly show the wrong map.] -- Glynn Clements From woklist at kyngchaos.com Sun Apr 15 20:57:15 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Sun Apr 15 20:57:27 2007 Subject: [GRASS-dev] return of the OSX xterm question In-Reply-To: <17945.65471.418796.321712@cerise.gclements.plus.com> References: <067285F7-8D2C-4DF3-8D92-C13EE4BB8171@kyngchaos.com> <17945.33292.321787.446725@cerise.gclements.plus.com> <17945.65471.418796.321712@cerise.gclements.plus.com> Message-ID: I worked out how to dump the env into a script to be sourced in the Terminal window, as suggested by Glynn. This removes the lengthy output before the command is actually run (though the source command is still there). And it makes the AppleScript a little simpler. As before, replace the installed grass /etc/grass-xterm-wrapper with this one (or replace the source /lib/init/grass-xterm-wrapper and rebuild). Also, update CVS for the latest OSX app startup (and rebuild) - I removed the hardwired xterm path. -------------- next part -------------- Skipped content of type multipart/appledouble-------------- next part -------------- If this works well, I'll commit it to CVS. ----- William Kyngesburye http://www.kyngchaos.com/ "History is an illusion caused by the passage of time, and time is an illusion caused by the passage of history." - Hitchhiker's Guide to the Galaxy From michael.barton at asu.edu Sun Apr 15 21:25:08 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sun Apr 15 21:25:16 2007 Subject: [GRASS-dev] icon testing Message-ID: Someone (sorry, but I forgot who) suggested the silk icon set at famfamfam.com would be worth looking at for wxgrass. I took a look at these, and also wrote their creator about the possibility of working with us to design GIS-specific icons (haven?t heard back yet). Many are nice, though all are small (16x16). I tried using these in the wxgrass toolbars to see how they looked. I had to modify a couple (and would need to modify more to really use these). So that others could take a look, I uploaded the results to the svn. There is an icon directory with the icons I used, and silk versions of wxgui.py and toolbars.py. You?ll need to add the icons directory and contents to /wx, and rename wxgui_silk.py to wxgui.py and toolbars_silk.py to toolbars.py. My impression is that the stock silk set are OK, but not a significant improvement over what we?ve got. Also, they are kind of small (at least for my eyes) and we?d still need some additional custom icons beyond the large set provided in the silk set. But it does offer a different look and might inspire an artistic reader of this list to design some new ones for us. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070415/f5e6b740/attachment.html From emanuele.conti at gmail.com Sun Apr 15 22:54:26 2007 From: emanuele.conti at gmail.com (Emanuele Conti) Date: Sun Apr 15 22:54:29 2007 Subject: [GRASS-dev] better mysql support Message-ID: <22ea73180704151354s6b347639o412cea1b8db3f3fe@mail.gmail.com> Hi everybody, I'm a university student and I'm doing a thesis on the integration of grass with mysql. I found that grass has a good support for postgis and I'd like to duplicate all the main features available for this db for mysql, which has geometry extensions (opengis compliant) and performs significantly better than postgres. I downloaded grass 6.3 cvs source code yet and I started to have a look to the code, but I've some questions: - from the grass 6 features page I understood that with postGis it's no more necessary to pass through gdal ogr translation: is this true? Is there a direct db manipulation? - what part of the code implements the direct "Export/Import to *PostGIS"*(functions as v.to.db and so on) and which directories and files should I look at? - what documentation could help me and where could I find it (I googled for technical docs oriented to grass/db integration, but I did't found much material); - is this a project that could become part of grass in any way? How could I receive support and/or feedback when necessary? I hope to read of you soon. Thanks... -- Emanuele Conti Senior Student at University ROMA TRE Department of Informatics and Automation ROME, Italy (matr. 251318) Mob: +39 328 2681070 Home: +39 06 39741124 e-mail: emanuele.conti@yahoo.com y!: emanuele_c msn: emanuele_c@yahoo.com -------------- parte successiva -------------- Un allegato HTML ? stato rimosso... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070415/cf526ed0/attachment.html From glynn at gclements.plus.com Mon Apr 16 02:17:39 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Apr 16 02:17:42 2007 Subject: [GRASS-dev] better mysql support In-Reply-To: <22ea73180704151354s6b347639o412cea1b8db3f3fe@mail.gmail.com> References: <22ea73180704151354s6b347639o412cea1b8db3f3fe@mail.gmail.com> Message-ID: <17954.49315.555321.507920@cerise.gclements.plus.com> Emanuele Conti wrote: > I'm a university student and I'm doing a thesis on the integration of grass > with mysql. I found that grass has a good support for postgis GRASS doesn't specifically support PostGIS. The generic database interface (DBMI) has a driver for PostgreSQL. Also, v.{in,out}.ogr support whichever drivers GDAL/OGR was built with. > and I'd like > to duplicate all the main features available for this db for mysql, which > has geometry extensions (opengis compliant) and performs significantly > better than postgres. I downloaded grass 6.3 cvs source code yet and I > started to have a look to the code, but I've some questions: > - from the grass 6 features page I understood that with postGis it's no more > necessary to pass through gdal ogr translation: is this true? Is there a > direct db manipulation? > - what part of the code implements the direct "Export/Import to > *PostGIS"*(functions as > v.to.db and so on) and which directories and files should I look at? v.to.db uses the DBMI; the PostgreSQL driver is in db/drivers/postgres, while the MySQL driver is in db/drivers/mysql. -- Glynn Clements From glynn at gclements.plus.com Mon Apr 16 02:38:48 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Apr 16 02:38:51 2007 Subject: [GRASS-dev] Use of "const", qualified map names In-Reply-To: <17953.25508.380841.746547@cerise.gclements.plus.com> References: <17953.25508.380841.746547@cerise.gclements.plus.com> Message-ID: <17954.50584.346214.594841@cerise.gclements.plus.com> Glynn Clements wrote: > Over the last two days I have gone through libgis and added "const" > qualifiers wherever they were appropriate (as well as a few other > minor clean-ups). > > However, this required a subtle API change. > > Previously, just about every libgis function which accepted parameters > of the form (char *name, char *mapset, ...) would end up normalising > the name (removing any "@mapset" part). In most cases, this was likely > to be accidental: an artifact of using G_find_file() etc. > > Apart from meaning that you couldn't pass a "const char *" for the > name, it could cause problems if you weren't expecting it (certainly, > I've been bitten by it at least once). > > Following my changes, the only functions which should strip the > @mapset part from a map name are the G_find_{file,cell,vector} > functions (which return the mapset where the file was found). Anything > else should leave the name intact (but will still honour any @mapset > part). > > There is a remote possibility that some module somewhere was actually > relying upon the existing behaviour (rather than using G_find_*() to > explicitly normalise the name). As this would be almost impossible to > track down methodically, all that I can suggest is to be on the > lookout for modules misbehaving when given qualified map names. Soeren found one major instance: G__check_fp_type(), used by G__open_cell_old() (and thus everything which uses it). This caused a significant number of modules to fail when reading FP maps. I've fixed that particular case in CVS, but there are others. Mostly, they relate to code which accesses the cell_misc directory. [Aside: whoever came up with the cell_misc structure needs major therapy. Getting rid of it needs to be the #1 priority for 7.x.] The reason is that all of the G_open_* functions which take element/name (and sometimes mapset) have to be "abused" in order to work with cell_misc, by passing cell_misc/ for the "element" parameter and for the "name" parameter. Because the name isn't actually being passed as the name, but is embedded in the element parameter, the code which strips the @mapset part never gets applied. When using G_open_* correctly (i.e. passing the name as the "name" parameter), this isn't an issue, as the name will be normalised (split it into an unqualified name and a separate mapset) automatically. This doesn't affect all modules: only those which fail to normalise the map name are affected. This has only become an issue with the recent change because, previously, almost any libgis function which accepted a map/mapset pair would end up normalising the name as a side-effect. Essentially, modules which use G_find_cell2() instead of G_find_cell() are affected. AFAICT, modules appear to be almost evenly divided between the use of G_find_cell() and G_find_cell2(). Now, a question: Should I leave these modules alone, in order to identify other functions which don't like being passed qualified map names, or should I just fix the modules? The former is better in the long run[1], but means that, in the short term, we will probably keep bumping into cases where qualified map names fail. [1] Ultimately, I hope to remove all knowledge of mapsets from the modules. Modules should just be able to pass opt->answer directly to libgis functions without having to deal with G_find_cell(), mapset parameters and the like. -- Glynn Clements From michael.barton at asu.edu Mon Apr 16 03:26:04 2007 From: michael.barton at asu.edu (Michael Barton) Date: Mon Apr 16 03:26:12 2007 Subject: [GRASS-dev] impressions on wx GUI In-Reply-To: Message-ID: The overlay flag has nothing to do with transparency. What may be happening is that the rendering algorithm is not catching the transparency change until you change some other option for the layer. I don't get that behavior, so I kind of guessing, however. Michael On 4/14/07 9:58 AM, "Carlos "Gu?no" Grohmann" wrote: > Just tested it. Multiple selection of map layers is working fine. > > I had some problems with the transparency. The first time I set a > transparency value, I did not worked. Then I set the overlay flag on, > and it worked. then I changed the transparency value and it didn't > worked again. when I unset the overlay, it worked... > > Carlos > > > > > On 4/14/07, Michael Barton wrote: >> Done for layer delete AND for querying multiple raster/vector maps >> simultaneously >> >> Michael >> >> >> On 4/12/07 5:20 PM, "Michael Barton" wrote: >> >>>> >>>> Multiple selection of layers in GIS Manager. If you want to delete >>>> several layers, it is a pain to do it one by one. >>> >>> Duly noted. Multiple drag and drop is more difficult however. >> >> __________________________________________ >> Michael Barton, Professor of Anthropology >> School of Human Evolution & Social Change >> Center for Social Dynamics & Complexity >> Arizona State University >> >> phone: 480-965-6213 >> fax: 480-965-7671 >> www: http://www.public.asu.edu/~cmbarton >> >> >> > __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From paul-grass at stjohnspoint.co.uk Mon Apr 16 04:56:18 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Mon Apr 16 04:56:21 2007 Subject: [GRASS-dev] better mysql support In-Reply-To: <22ea73180704151354s6b347639o412cea1b8db3f3fe@mail.gmail.com> References: <22ea73180704151354s6b347639o412cea1b8db3f3fe@mail.gmail.com> Message-ID: On Sun, 15 Apr 2007, Emanuele Conti wrote: > Hi everybody, > I'm a university student and I'm doing a thesis on the integration of grass > with mysql. I found that grass has a good support for postgis and I'd like > to duplicate all the main features available for this db for mysql, which > has geometry extensions (opengis compliant) and performs significantly > better than postgres. I downloaded grass 6.3 cvs source code yet and I As I understand it the OpenGIS vector format is a lot less featureful than the GRASS format (i.e. it doesn't store the topological relationships between vector features, which is important for a lot of vector analyses) and thus it is debateable whether it is useful to store GRASS data in that format. It would mean topology would have to be re-built from the external data any time an analysis is to be done in GRASS. My understanding is the OpenGIS format is more of a quick-access format useful for displaying data, but if it is to be edited, topological format is better for ensuring the integrity of the data (no overlapping boundaries and that kind of thing). As far as I can remember GRASS used to directly support storage of vector geometry in PostGIS in 5.7/6.0 pre-releases, but that was removed before the release of 6.0.0 final because there were problems with it. The PostGIS support was integrated by a group of final year project students I think - there may also have been a paper written about it. It would probably be a good idea to investigate this (e.g. download an old version of GRASS and try it out etc.) and investigate what the problems were and why it was dropped, and see if you can do better with your MySQL spatial support. Off the top of my head though, I think the shortcomings of the OpenGIS vector format for spatial analysis were a major factor. But you would need to read old mailing list posts from Radim Blazek for more insight. Paul > started to have a look to the code, but I've some questions: > - from the grass 6 features page I understood that with postGis it's no more > necessary to pass through gdal ogr translation: is this true? Is there a > direct db manipulation? > - what part of the code implements the direct "Export/Import to > *PostGIS"*(functions as > v.to.db and so on) and which directories and files should I look at? > - what documentation could help me and where could I find it (I googled for > technical docs oriented to grass/db integration, but I did't found much > material); > - is this a project that could become part of grass in any way? How could I > receive support and/or feedback when necessary? > > I hope to read of you soon. Thanks... > > -- > Emanuele Conti > Senior Student at University ROMA TRE > Department of Informatics and Automation > ROME, Italy (matr. 251318) > Mob: +39 328 2681070 > Home: +39 06 39741124 > e-mail: emanuele.conti@yahoo.com > y!: emanuele_c > msn: emanuele_c@yahoo.com > From nicholas.g.lawrence at mainroads.qld.gov.au Mon Apr 16 06:07:49 2007 From: nicholas.g.lawrence at mainroads.qld.gov.au (nicholas.g.lawrence@mainroads.qld.gov.au) Date: Mon Apr 16 06:08:05 2007 Subject: [GRASS-dev] better mysql support In-Reply-To: Message-ID: grass-dev-bounces@grass.itc.it wrote on 16/04/2007 12:56:18 PM: > On Sun, 15 Apr 2007, Emanuele Conti wrote: > > Hi everybody, > > I'm a university student and I'm doing a thesis on the integration of grass > > with mysql. I found that grass has a good support for postgis and I'd like > > to duplicate all the main features available for this db for mysql, which > > has geometry extensions (opengis compliant) and performs significantly > > better than postgres. I downloaded grass 6.3 cvs source code yet and I > Paul > As I understand it the OpenGIS vector format is a lot less featureful than > the GRASS format (i.e. it doesn't store the topological relationships > between vector features, which is important for a lot of vector analyses) > and thus it is debateable whether it is useful to store GRASS data in that > format. Nick Isn't OpenGIS planning to introduce proper topology at a later date? My understanding was that the 'first pass' was simple, non-topological vectors because they are simpler. ************************************************************ Opinions contained in this e-mail do not necessarily reflect the opinions of the Queensland Department of Main Roads, Queensland Transport or Maritime Safety Queensland, or endorsed organisations utilising the same infrastructure. If you have received this electronic mail message in error, please immediately notify the sender and delete the message from your computer. ************************************************************ From cavallini at faunalia.it Mon Apr 16 07:50:21 2007 From: cavallini at faunalia.it (Paolo Cavallini) Date: Mon Apr 16 07:50:23 2007 Subject: [GRASS-dev] better mysql support In-Reply-To: <22ea73180704151354s6b347639o412cea1b8db3f3fe@mail.gmail.com> References: <22ea73180704151354s6b347639o412cea1b8db3f3fe@mail.gmail.com> Message-ID: <46230E9D.5080903@faunalia.it> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 do you have data supporting this statement? from my experience this is not true. pc Emanuele Conti ha scritto: > mysql, which has geometry extensions (opengis compliant) and performs > significantly better than postgres. - -- Paolo Cavallini http://www.faunalia.it/pc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGIw6d/NedwLUzIr4RApthAJ4iQKCYNGpB6ZXGx83Yk7WYEl4liQCgndMh woLBvzbDwk660HYOXyN8WL0= =GHaa -----END PGP SIGNATURE----- From emanuele.conti at gmail.com Mon Apr 16 10:02:43 2007 From: emanuele.conti at gmail.com (Emanuele Conti) Date: Mon Apr 16 10:02:48 2007 Subject: Fwd: [GRASS-dev] better mysql support In-Reply-To: <22ea73180704160101gfa20308oe8b1c80b5cf831b9@mail.gmail.com> References: <22ea73180704151354s6b347639o412cea1b8db3f3fe@mail.gmail.com> <46230E9D.5080903@faunalia.it> <22ea73180704160101gfa20308oe8b1c80b5cf831b9@mail.gmail.com> Message-ID: <22ea73180704160102rbdd45d9y48d52c461545aea2@mail.gmail.com> ---------- Forwarded message ---------- From: Emanuele Conti Date: 16-apr-2007 10.01 Subject: Re: [GRASS-dev] better mysql support To: Paolo Cavallini Something can be read from google and so on, but personally I did benchmarks based on performances and mysql server prerforms significantly better in most of circumstances; I did experiments using also ram-fs to store data for both of them, but the all-in-memory engine of mysql is the fastest and better optimized of the possibilities (always in terms of performances), followed by myisam engine with or without ram-fs; at last comes postgres... 2007/4/16, Paolo Cavallini : > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > do you have data supporting this statement? > from my experience this is not true. > pc > > Emanuele Conti ha scritto: > > > mysql, which has geometry extensions (opengis compliant) and performs > > significantly better than postgres. > - -- > Paolo Cavallini > http://www.faunalia.it/pc > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFGIw6d/NedwLUzIr4RApthAJ4iQKCYNGpB6ZXGx83Yk7WYEl4liQCgndMh > woLBvzbDwk660HYOXyN8WL0= > =GHaa > -----END PGP SIGNATURE----- > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > -- Emanuele Conti Senior Student at University ROMA TRE Department of Informatics and Automation ROME, Italy (matr. 251318) Mob: +39 328 2681070 Home: +39 06 39741124 e-mail: emanuele.conti@yahoo.com y!: emanuele_c msn: emanuele_c@yahoo.com -- Emanuele Conti Senior Student at University ROMA TRE Department of Informatics and Automation ROME, Italy (matr. 251318) Mob: +39 328 2681070 Home: +39 06 39741124 e-mail: emanuele.conti@yahoo.com y!: emanuele_c msn: emanuele_c@yahoo.com -------------- parte successiva -------------- Un allegato HTML ? stato rimosso... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070416/bd3d71d2/attachment.html From emanuele.conti at gmail.com Mon Apr 16 10:35:12 2007 From: emanuele.conti at gmail.com (Emanuele Conti) Date: Mon Apr 16 10:35:17 2007 Subject: Fwd: [GRASS-dev] better mysql support In-Reply-To: <22ea73180704160134t7da8b299q88bdad71aa6b1a33@mail.gmail.com> References: <22ea73180704151354s6b347639o412cea1b8db3f3fe@mail.gmail.com> <17954.49315.555321.507920@cerise.gclements.plus.com> <22ea73180704160134t7da8b299q88bdad71aa6b1a33@mail.gmail.com> Message-ID: <22ea73180704160135s26254a11qeda789afbd0decb1@mail.gmail.com> ---------- Forwarded message ---------- From: Emanuele Conti Date: 16-apr-2007 10.34 Subject: Re: [GRASS-dev] better mysql support To: Glynn Clements So, please, can anyone explain the meaning of the first to point in this feaure list of grass6, where there is a direct and explicit mention to postgis? 2007/4/16, Glynn Clements : > > > Emanuele Conti wrote: > > > I'm a university student and I'm doing a thesis on the integration of > grass > > with mysql. I found that grass has a good support for postgis > > GRASS doesn't specifically support PostGIS. The generic database > interface (DBMI) has a driver for PostgreSQL. Also, v.{in,out}.ogr > support whichever drivers GDAL/OGR was built with. > > > and I'd like > > to duplicate all the main features available for this db for mysql, > which > > has geometry extensions (opengis compliant) and performs significantly > > better than postgres. I downloaded grass 6.3 cvs source code yet and I > > started to have a look to the code, but I've some questions: > > - from the grass 6 features page I understood that with postGis it's no > more > > necessary to pass through gdal ogr translation: is this true? Is there a > > direct db manipulation? > > - what part of the code implements the direct "Export/Import to > > *PostGIS"*(functions as > > v.to.db and so on) and which directories and files should I look at? > > v.to.db uses the DBMI; the PostgreSQL driver is in > db/drivers/postgres, while the MySQL driver is in db/drivers/mysql. > > -- > Glynn Clements > -- Emanuele Conti Senior Student at University ROMA TRE Department of Informatics and Automation ROME, Italy (matr. 251318) Mob: +39 328 2681070 Home: +39 06 39741124 e-mail: emanuele.conti@yahoo.com y!: emanuele_c msn: emanuele_c@yahoo.com -- Emanuele Conti Senior Student at University ROMA TRE Department of Informatics and Automation ROME, Italy (matr. 251318) Mob: +39 328 2681070 Home: +39 06 39741124 e-mail: emanuele.conti@yahoo.com y!: emanuele_c msn: emanuele_c@yahoo.com -------------- parte successiva -------------- Un allegato HTML ? stato rimosso... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070416/60b1e06e/attachment-0001.html From emanuele.conti at gmail.com Mon Apr 16 10:37:14 2007 From: emanuele.conti at gmail.com (Emanuele Conti) Date: Mon Apr 16 10:37:18 2007 Subject: [GRASS-dev] better mysql support In-Reply-To: References: <22ea73180704151354s6b347639o412cea1b8db3f3fe@mail.gmail.com> Message-ID: <22ea73180704160137u6371a582m350f3a73393b5281@mail.gmail.com> So, can anyone explain the meaning of the first two points in this feaure list of grass6, where there is a direct and explicit mention to postgis? 2007/4/16, Paul Kelly : > > On Sun, 15 Apr 2007, Emanuele Conti wrote: > > > Hi everybody, > > I'm a university student and I'm doing a thesis on the integration of > grass > > with mysql. I found that grass has a good support for postgis and I'd > like > > to duplicate all the main features available for this db for mysql, > which > > has geometry extensions (opengis compliant) and performs significantly > > better than postgres. I downloaded grass 6.3 cvs source code yet and I > > As I understand it the OpenGIS vector format is a lot less featureful than > the GRASS format (i.e. it doesn't store the topological relationships > between vector features, which is important for a lot of vector analyses) > and thus it is debateable whether it is useful to store GRASS data in that > format. It would mean topology would have to be re-built from the external > data any time an analysis is to be done in GRASS. My understanding is the > OpenGIS format is more of a quick-access format useful for displaying > data, but if it is to be edited, topological format is better for ensuring > the integrity of the data (no overlapping boundaries and that kind of > thing). > > As far as I can remember GRASS used to directly support storage of vector > geometry in PostGIS in 5.7/6.0 pre-releases, but that was removed before > the release of 6.0.0 final because there were problems with it. The > PostGIS support was integrated by a group of final year project students I > think - there may also have been a paper written about it. It would > probably be a good idea to investigate this (e.g. download an old version > of GRASS and try it out etc.) and investigate what the problems were and > why it was dropped, and see if you can do better with your MySQL spatial > support. > > Off the top of my head though, I think the shortcomings of the OpenGIS > vector format for spatial analysis were a major factor. But you would need > to read old mailing list posts from Radim Blazek for more insight. > > Paul > > > started to have a look to the code, but I've some questions: > > - from the grass 6 features page I understood that with postGis it's no > more > > necessary to pass through gdal ogr translation: is this true? Is there a > > direct db manipulation? > > - what part of the code implements the direct "Export/Import to > > *PostGIS"*(functions as > > v.to.db and so on) and which directories and files should I look at? > > - what documentation could help me and where could I find it (I googled > for > > technical docs oriented to grass/db integration, but I did't found much > > material); > > - is this a project that could become part of grass in any way? How > could I > > receive support and/or feedback when necessary? > > > > I hope to read of you soon. Thanks... > > > > -- > > Emanuele Conti > > Senior Student at University ROMA TRE > > Department of Informatics and Automation > > ROME, Italy (matr. 251318) > > Mob: +39 328 2681070 > > Home: +39 06 39741124 > > e-mail: emanuele.conti@yahoo.com > > y!: emanuele_c > > msn: emanuele_c@yahoo.com > > > -- Emanuele Conti Senior Student at University ROMA TRE Department of Informatics and Automation ROME, Italy (matr. 251318) Mob: +39 328 2681070 Home: +39 06 39741124 e-mail: emanuele.conti@yahoo.com y!: emanuele_c msn: emanuele_c@yahoo.com -------------- parte successiva -------------- Un allegato HTML ? stato rimosso... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070416/f841c1f8/attachment.html From grass-codei at wald.intevation.org Mon Apr 16 10:47:06 2007 From: grass-codei at wald.intevation.org (grass-codei@wald.intevation.org) Date: Mon Apr 16 10:47:09 2007 Subject: [GRASS-dev] [grass-code I][370] Missing proto.h header file in v.edit Message-ID: <20070416084706.BEDD718565C4@pyrosoma.intevation.org> code I item #370, was opened at 2007-04-16 10:47 Status: Open Priority: 4 Submitted By: S?ren Gebbert (huhabla) Assigned to: Martin Landa (martinl) Summary: Missing proto.h header file in v.edit Issue type: module bug Issue status: None GRASS version: CVS HEAD GRASS component: vector Operating system: all Operating system version: Debian Linux testing (etch) GRASS CVS checkout date, if applies (YYMMDD): 070416 Initial Comment: Compilation of v.edit is broken. The header file "proto.h" is missing. Soeren ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=370&group_id=21 From paul-grass at stjohnspoint.co.uk Mon Apr 16 11:14:50 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Mon Apr 16 11:14:52 2007 Subject: [GRASS-dev] better mysql support In-Reply-To: <22ea73180704160137u6371a582m350f3a73393b5281@mail.gmail.com> References: <22ea73180704151354s6b347639o412cea1b8db3f3fe@mail.gmail.com> <22ea73180704160137u6371a582m350f3a73393b5281@mail.gmail.com> Message-ID: On Mon, 16 Apr 2007, Emanuele Conti wrote: > So, can anyone explain the meaning of the first two points in this feaure > list of grass6, where there > is a direct and explicit mention to postgis? I'm not sure. The first point explicitly says the interface to PostGIS is through OGR. PostGIS export/import does indeed have a bullet point to itself - but note it does say export/import - meaning that the geometry is still converted to/from GRASS native format. I'm not sure why its there. Note that the page is for 6.0, which is quite old now. It may be a confusion over the direct PostGIS support which has been recently removed then, or it may simply refer to importing/exporting from/to PostGIS via OGR. This message may be interesting to you about the limitations of the old (GRASS 5.7) PostGIS support: http://grass.itc.it/pipermail/grass5/2003-October/012808.html In particular, it implies that the reason it was slow was because of the way GRASS queried PostGIS, not PostGIS itself. So if you query MySQL spatial in the same way, you would not get any speed improvement because the bottleneck was the interface between GRASS and PostGIS. Or, looking at it another way, if you get it to work fast with MySQL then it would probably also work fast with PostGIS. As is probably obvious here, I only understand most of the issues involved at a superficial level but am trying to point out where you should read around to get more information. Paul From cavallini at faunalia.it Mon Apr 16 13:07:11 2007 From: cavallini at faunalia.it (Paolo Cavallini) Date: Mon Apr 16 13:07:14 2007 Subject: [GRASS-dev] better mysql support In-Reply-To: <22ea73180704160101gfa20308oe8b1c80b5cf831b9@mail.gmail.com> References: <22ea73180704151354s6b347639o412cea1b8db3f3fe@mail.gmail.com> <46230E9D.5080903@faunalia.it> <22ea73180704160101gfa20308oe8b1c80b5cf831b9@mail.gmail.com> Message-ID: <462358DF.6030708@faunalia.it> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This should be related to mysql being non-ACID, something we often cannot afford in GIS. Performance != speed, especially in geographic contexts. PostGIS is far more powerful than the MySQL spatial. All the best. pc Emanuele Conti ha scritto: > Something can be read from google and so on, but personally I did > benchmarks based on performances and mysql server prerforms > significantly better in most of circumstances; I did experiments using > also ram-fs to store data for both of them, but the all-in-memory engine > of mysql is the fastest and better optimized of the possibilities > (always in terms of performances), followed by myisam engine with or > without ram-fs; at last comes postgres... > > 2007/4/16, Paolo Cavallini >: > > do you have data supporting this statement? > from my experience this is not true. > pc > > Emanuele Conti ha scritto: > >> mysql, which has geometry extensions (opengis compliant) and performs >> significantly better than postgres. - -- Paolo Cavallini http://www.faunalia.it/pc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGI1jf/NedwLUzIr4RAoanAJ9ntwL5nHqK0TnLfKodnJ/HEPKYEQCdEyPI Ved//u4ii0YaJEmca9I+fDM= =u+0w -----END PGP SIGNATURE----- From stephan.holl at intevation.de Mon Apr 16 14:42:36 2007 From: stephan.holl at intevation.de (Stephan Holl) Date: Mon Apr 16 14:42:39 2007 Subject: [GRASS-dev] commercial GRASS development Message-ID: <20070416144236.530f41ac@thoe.hq.intevation.de> Hello *, some time ago I asked Markus about commercial GRASS development in the past. He gave some information about this so I summed it up and put it on a wiki-page[1]. Assuming the given list is not complete I like to invite everybody who developed something for GRASS in a commercial way to add it to the wiki. Hopefuly we can make this list extend. Best regards Stephan [1] http://grass.gdf-hannover.de/wiki/Development#Commercial_development_for_GRASS -- Stephan Holl , http://intevation.de/~stephan Tel: +49 (0)541-33 50 8 32 | Intevation GmbH | AG Osnabr?ck - HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From landa.martin at gmail.com Mon Apr 16 15:31:33 2007 From: landa.martin at gmail.com (Martin Landa) Date: Mon Apr 16 15:31:35 2007 Subject: [GRASS-dev] Re: [GRASS-CVS] glynn: grass6 proto.h,1.1,NONE In-Reply-To: <20070416132806.77A401005B7@lists.intevation.de> References: <20070416132806.77A401005B7@lists.intevation.de> Message-ID: Opps, sorry for the mess!! Shame on me;-) Martin 2007/4/16, grass@intevation.de : > Author: glynn > > Update of /grassrepository/grass6 > In directory doto:/tmp/cvs-serv6537 > > Removed Files: > proto.h > Log Message: > Remove misplaced header > > > --- proto.h DELETED --- > > > _______________________________________________ > grass-commit mailing list > grass-commit@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-commit > -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From glynn at gclements.plus.com Mon Apr 16 16:16:10 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Apr 16 16:16:15 2007 Subject: Fwd: [GRASS-dev] better mysql support In-Reply-To: <22ea73180704160135s26254a11qeda789afbd0decb1@mail.gmail.com> References: <22ea73180704151354s6b347639o412cea1b8db3f3fe@mail.gmail.com> <17954.49315.555321.507920@cerise.gclements.plus.com> <22ea73180704160134t7da8b299q88bdad71aa6b1a33@mail.gmail.com> <22ea73180704160135s26254a11qeda789afbd0decb1@mail.gmail.com> Message-ID: <17955.34090.886785.87729@cerise.gclements.plus.com> Emanuele Conti wrote: > So, please, can anyone explain the meaning of the first to point in this > feaure list of grass6, > where there is a direct and explicit mention to postgis? That refers to the use of OGR, via v.external or v.{in,out}.ogr http://grass.itc.it/grass60/manuals/html60_user/v.external.html http://grass.itc.it/grass60/manuals/html60_user/v.in.ogr.html http://grass.itc.it/grass60/manuals/html60_user/v.out.ogr.html -- Glynn Clements From glynn at gclements.plus.com Mon Apr 16 19:03:12 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Apr 16 19:03:21 2007 Subject: [GRASS-dev] Unused files Message-ID: <17955.44112.860626.760287@cerise.gclements.plus.com> There are currently 78 source files whose functions don't appear to be used by anything. Some of these may be used by components which aren't being compiled on my system, and some have been added with the intention of future use. OTOH, some of them may simply be obsolete. Please provide comments as to whether specific files should or shouldn't be removed. The complete list is: lib/cdhc/enormp.c | enormp lib/cdhc/shapiro2.c | shapiro_francia lib/cdhc/shapiroe.c | shapiro_wilk_exp lib/cdhc/cvmw2e.c | cramer_von_mises_exp lib/cdhc/kse.c | kolmogorov_smirnov_exp lib/cdhc/kuiprsve.c | kuipers_v_exp lib/cdhc/watsonue.c | watson_u2_exp lib/cdhc/andrsnde.c | anderson_darling_exp lib/cdhc/chisqe.c | chi_square_exp lib/datetime/same.c | datetime_is_same lib/datetime/local.c | datetime_get_local_time lib/datetime/local.c | datetime_get_local_timezone lib/db/sqlp/print.c | sqpPrintStmt lib/db/dbmi_base/dirent.c | db_alloc_dirent_array lib/db/dbmi_base/dirent.c | db_dirent lib/db/dbmi_base/dirent.c | db_free_dirent_array lib/db/dbmi_base/legal_dbname.c | db_legal_tablename lib/db/dbmi_base/strip.c | db_strip lib/db/dbmi_base/whoami.c | db_whoami lib/db/dbmi_base/xdrfloat.c | db__recv_float lib/db/dbmi_base/xdrfloat.c | db__recv_float_array lib/db/dbmi_base/xdrfloat.c | db__send_float lib/db/dbmi_base/xdrfloat.c | db__send_float_array lib/db/dbmi_client/c_add_col.c | db_add_column lib/db/dbmi_client/c_bindupdate.c | db_bind_update lib/db/dbmi_client/c_createdb.c | db_create_database lib/db/dbmi_client/c_delete.c | db_delete lib/db/dbmi_client/c_deletedb.c | db_delete_database lib/db/dbmi_client/c_drop_col.c | db_drop_column lib/db/dbmi_client/c_drop_index.c | db_drop_index lib/db/dbmi_client/c_drop_tab.c | db_drop_table lib/db/dbmi_client/c_finddb.c | db_find_database lib/db/dbmi_client/c_insert.c | db_insert lib/db/dbmi_client/c_list_idx.c | db_list_indexes lib/db/dbmi_client/c_listdb.c | db_list_databases lib/db/dbmi_client/c_openinsert.c | db_open_insert_cursor lib/db/dbmi_client/c_openupdate.c | db_open_update_cursor lib/db/dbmi_client/c_update.c | db_update lib/db/dbmi_client/c_version.c | db_gversion lib/db/dbmi_client/printtab.c | db_print_column_definition lib/db/dbmi_client/printtab.c | db_print_table_definition lib/db/dbmi_driver/d_mkdir.c | db_driver_mkdir lib/display/clip.c | D_clip lib/display/scan_dbl.c | D_scan_double lib/display/scan_float.c | D_scan_float lib/display/scan_int.c | D_scan_int lib/external/shapelib/shpopen.c | SHPClose lib/external/shapelib/shpopen.c | SHPComputeExtents lib/external/shapelib/shpopen.c | SHPCreate lib/external/shapelib/shpopen.c | SHPCreateObject lib/external/shapelib/shpopen.c | SHPCreateSimpleObject lib/external/shapelib/shpopen.c | SHPDestroyObject lib/external/shapelib/shpopen.c | SHPGetInfo lib/external/shapelib/shpopen.c | SHPOpen lib/external/shapelib/shpopen.c | SHPPartTypeName lib/external/shapelib/shpopen.c | SHPReadObject lib/external/shapelib/shpopen.c | SHPRewindObject lib/external/shapelib/shpopen.c | SHPTypeName lib/external/shapelib/shpopen.c | SHPWriteHeader lib/external/shapelib/shpopen.c | SHPWriteObject lib/g3d/changeprecision.c | G3d_changePrecision lib/g3d/changetype.c | G3d_changeType lib/g3d/filecompare.c | G3d_compareFiles lib/g3d/g3ddoubleio.c | G3d_readDoubles lib/g3d/g3ddoubleio.c | G3d_writeDoubles lib/g3d/g3dvolume.c | G3d_getAllignedVolume lib/g3d/g3dvolume.c | G3d_getVolume lib/g3d/g3dvolume.c | G3d_getVolumeA lib/g3d/g3dvolume.c | G3d_makeAllignedVolumeFile lib/g3d/retile.c | G3d_retile lib/g3d/writeascii.c | G3d_writeAscii lib/gis/clicker.c | G_clicker lib/gis/dig_title.c | G_get_dig_title lib/gis/gishelp.c | G_gishelp lib/gis/histo_eq.c | G_histogram_eq lib/gis/is.c | G_is_gisbase lib/gis/is.c | G_is_location lib/gis/is.c | G_is_mapset lib/gis/line_dist.c | G_distance2_point_to_line lib/gis/line_dist.c | G_set_distance_to_line_tolerance lib/gis/pole_in_poly.c | G_pole_in_polygon lib/gis/radii.c | G_meridional_radius_of_curvature lib/gis/radii.c | G_radius_of_conformal_tangent_sphere lib/gis/radii.c | G_transverse_radius_of_curvature lib/gis/user_config.c | G_rc_path lib/gis/version.c | G_version lib/gmath/la.c | G__matrix_add lib/gmath/la.c | G_matrix_LU_solve lib/gmath/la.c | G_matrix_add lib/gmath/la.c | G_matrix_copy lib/gmath/la.c | G_matrix_eigen_sort lib/gmath/la.c | G_matrix_free lib/gmath/la.c | G_matrix_get_element lib/gmath/la.c | G_matrix_init lib/gmath/la.c | G_matrix_inverse lib/gmath/la.c | G_matrix_print lib/gmath/la.c | G_matrix_product lib/gmath/la.c | G_matrix_read lib/gmath/la.c | G_matrix_scale lib/gmath/la.c | G_matrix_set lib/gmath/la.c | G_matrix_set_element lib/gmath/la.c | G_matrix_stdin lib/gmath/la.c | G_matrix_subtract lib/gmath/la.c | G_matrix_transpose lib/gmath/la.c | G_matrix_zero lib/gmath/la.c | G_matvect_extract_vector lib/gmath/la.c | G_matvect_get_column lib/gmath/la.c | G_matvect_get_row lib/gmath/la.c | G_matvect_retrieve_matrix lib/gmath/la.c | G_vector_copy lib/gmath/la.c | G_vector_free lib/gmath/la.c | G_vector_init lib/gmath/la.c | G_vector_norm1 lib/gmath/la.c | G_vector_norm_euclid lib/gmath/la.c | G_vector_norm_maxval lib/gmath/la.c | G_vector_set lib/gmath/la.c | G_vector_sub lib/gmath/svd.c | G_svbksb lib/gmath/svd.c | G_svdcmp lib/gmath/svd.c | G_svelim lib/imagery/add_cov.c | I_add_covariances lib/imagery/advance.c | I_tape_advance lib/imagery/ask.c | I_ask lib/imagery/ask_subgrp.c | I_ask_subgroup_new lib/imagery/ask_subgrp.c | I_ask_subgroup_old lib/imagery/band_io.c | I_close_band lib/imagery/band_io.c | I_open_band_new lib/imagery/colors.c | I_free_group_colors lib/imagery/colors.c | I_read_group_blu_colors lib/imagery/colors.c | I_read_group_colors lib/imagery/colors.c | I_read_group_grn_colors lib/imagery/colors.c | I_read_group_red_colors lib/imagery/colors.c | I_write_group_blu_colors lib/imagery/colors.c | I_write_group_colors lib/imagery/colors.c | I_write_group_grn_colors lib/imagery/colors.c | I_write_group_red_colors lib/imagery/image.c | I_close_image lib/imagery/image.c | I_get_image_row lib/imagery/image.c | I_image_colors lib/imagery/image.c | I_open_image lib/imagery/image.c | I_translate_image_data lib/imagery/open.c | I_open_group_file_new lib/imagery/open.c | I_open_group_file_old lib/imagery/percent.c | I_percent lib/imagery/proj.c | I_must_be_imagery_projection lib/imagery/sig2cats.c | I_signature_to_cats lib/rowio/forget.c | rowio_forget lib/rst/interp_float/distance.c | IL_dist_square lib/vector/Vlib/dbcolumns.c | Vect_get_column_names lib/vector/Vlib/dbcolumns.c | Vect_get_column_names_types lib/vector/Vlib/dbcolumns.c | Vect_get_column_types lib/vector/Vlib/graph.c | Vect_graph_add_edge lib/vector/Vlib/graph.c | Vect_graph_build lib/vector/Vlib/graph.c | Vect_graph_init lib/vector/Vlib/graph.c | Vect_graph_set_node_costs lib/vector/Vlib/graph.c | Vect_graph_shortest_path lib/vector/Vlib/overlap.c | V__map_overlap lib/vector/Vlib/overlay.c | Vect_overlay lib/vector/Vlib/overlay.c | Vect_overlay_and lib/vector/Vlib/overlay.c | Vect_overlay_str_to_operator lib/vector/dglib/avl.c | avl_allocator_default lib/vector/dglib/avl.c | avl_assert_delete lib/vector/dglib/avl.c | avl_assert_insert lib/vector/dglib/avl.c | avl_copy lib/vector/dglib/avl.c | avl_create lib/vector/dglib/avl.c | avl_delete lib/vector/dglib/avl.c | avl_destroy lib/vector/dglib/avl.c | avl_find lib/vector/dglib/avl.c | avl_free lib/vector/dglib/avl.c | avl_insert lib/vector/dglib/avl.c | avl_malloc lib/vector/dglib/avl.c | avl_probe lib/vector/dglib/avl.c | avl_replace lib/vector/dglib/avl.c | avl_t_copy lib/vector/dglib/avl.c | avl_t_cur lib/vector/dglib/avl.c | avl_t_find lib/vector/dglib/avl.c | avl_t_first lib/vector/dglib/avl.c | avl_t_init lib/vector/dglib/avl.c | avl_t_insert lib/vector/dglib/avl.c | avl_t_last lib/vector/dglib/avl.c | avl_t_next lib/vector/dglib/avl.c | avl_t_prev lib/vector/dglib/avl.c | avl_t_replace lib/gpde/N_solute_transport.c | N_alloc_solute_transport_data2d lib/gpde/N_solute_transport.c | N_alloc_solute_transport_data3d lib/gpde/N_solute_transport.c | N_callback_solute_transport_2d lib/gpde/N_solute_transport.c | N_callback_solute_transport_3d lib/gpde/N_solute_transport.c | N_free_solute_transport_data2d lib/gpde/N_solute_transport.c | N_free_solute_transport_data3d -- Glynn Clements From soerengebbert at gmx.de Mon Apr 16 19:25:04 2007 From: soerengebbert at gmx.de (=?ISO-8859-1?Q?S=F6ren_Gebbert?=) Date: Mon Apr 16 19:26:05 2007 Subject: [GRASS-dev] Unused files In-Reply-To: <17955.44112.860626.760287@cerise.gclements.plus.com> References: <17955.44112.860626.760287@cerise.gclements.plus.com> Message-ID: <4623B170.6000309@gmx.de> Hi, Glynn Clements schrieb: > There are currently 78 source files whose functions don't appear to be > used by anything. > > Some of these may be used by components which aren't being compiled on > my system, and some have been added with the intention of future use. > OTOH, some of them may simply be obsolete. > > Please provide comments as to whether specific files should or > shouldn't be removed. > > The complete list is: > > lib/g3d/changeprecision.c | G3d_changePrecision > lib/g3d/changetype.c | G3d_changeType > lib/g3d/filecompare.c | G3d_compareFiles > lib/g3d/g3ddoubleio.c | G3d_readDoubles > lib/g3d/g3ddoubleio.c | G3d_writeDoubles > lib/g3d/g3dvolume.c | G3d_getAllignedVolume > lib/g3d/g3dvolume.c | G3d_getVolume > lib/g3d/g3dvolume.c | G3d_getVolumeA > lib/g3d/g3dvolume.c | G3d_makeAllignedVolumeFile > lib/g3d/retile.c | G3d_retile > lib/g3d/writeascii.c | G3d_writeAscii Those g3d files are still important. Only a small part of the features from the g3d library are currently used by the raster3d modules. > lib/gpde/N_solute_transport.c | N_alloc_solute_transport_data2d > lib/gpde/N_solute_transport.c | N_alloc_solute_transport_data3d > lib/gpde/N_solute_transport.c | N_callback_solute_transport_2d > lib/gpde/N_solute_transport.c | N_callback_solute_transport_3d > lib/gpde/N_solute_transport.c | N_free_solute_transport_data2d > lib/gpde/N_solute_transport.c | N_free_solute_transport_data3d > Everything which is located in the gpde library directory is under active development. These functions will be used in modules which need to model solute transport in porous media. A module which is doing this will be available in some months. (this is a small impression of what this module will do: http://video.google.de/videoplay?docid=7289891157754718168&q=grass+gis) Besides of this, these functions are used in the gpde test module (lib/gpde/test) which is not build by default. Best regards Soeren From dca.gis at gmail.com Mon Apr 16 21:12:02 2007 From: dca.gis at gmail.com (Daniel Calvelo) Date: Mon Apr 16 21:12:07 2007 Subject: [GRASS-dev] Unused files In-Reply-To: <17955.44112.860626.760287@cerise.gclements.plus.com> References: <17955.44112.860626.760287@cerise.gclements.plus.com> Message-ID: <1a486f560704161212t747f68fdoa0b1ae7559ca42a@mail.gmail.com> On 4/16/07, Glynn Clements wrote: > > There are currently 78 source files whose functions don't appear to be > used by anything. > > Some of these may be used by components which aren't being compiled on > my system, and some have been added with the intention of future use. > OTOH, some of them may simply be obsolete. > > Please provide comments as to whether specific files should or > shouldn't be removed. [...] > lib/db/sqlp/print.c | sqpPrintStmt This is used in sqlp/test and should be useful in debugging; I'd keep it. > lib/db/dbmi_client/c_add_col.c | db_add_column > lib/db/dbmi_client/c_bindupdate.c | db_bind_update > lib/db/dbmi_client/c_createdb.c | db_create_database > lib/db/dbmi_client/c_delete.c | db_delete > lib/db/dbmi_client/c_deletedb.c | db_delete_database > lib/db/dbmi_client/c_drop_col.c | db_drop_column > lib/db/dbmi_client/c_drop_index.c | db_drop_index > lib/db/dbmi_client/c_drop_tab.c | db_drop_table > lib/db/dbmi_client/c_finddb.c | db_find_database > lib/db/dbmi_client/c_insert.c | db_insert > lib/db/dbmi_client/c_list_idx.c | db_list_indexes > lib/db/dbmi_client/c_listdb.c | db_list_databases > lib/db/dbmi_client/c_openinsert.c | db_open_insert_cursor > lib/db/dbmi_client/c_openupdate.c | db_open_update_cursor > lib/db/dbmi_client/c_update.c | db_update > lib/db/dbmi_client/c_version.c | db_gversion > lib/db/dbmi_client/printtab.c | db_print_column_definition > lib/db/dbmi_client/printtab.c | db_print_table_definition > lib/db/dbmi_driver/d_mkdir.c | db_driver_mkdir Aren't these template functions and files to develop new drivers? > lib/external/shapelib/shpopen.c | SHPClose > lib/external/shapelib/shpopen.c | SHPComputeExtents > lib/external/shapelib/shpopen.c | SHPCreate > lib/external/shapelib/shpopen.c | SHPCreateObject > lib/external/shapelib/shpopen.c | SHPCreateSimpleObject > lib/external/shapelib/shpopen.c | SHPDestroyObject > lib/external/shapelib/shpopen.c | SHPGetInfo > lib/external/shapelib/shpopen.c | SHPOpen > lib/external/shapelib/shpopen.c | SHPPartTypeName > lib/external/shapelib/shpopen.c | SHPReadObject > lib/external/shapelib/shpopen.c | SHPRewindObject > lib/external/shapelib/shpopen.c | SHPTypeName > lib/external/shapelib/shpopen.c | SHPWriteHeader > lib/external/shapelib/shpopen.c | SHPWriteObject Since we are relying on OGR for shapefile access, I suppose shapelib is kept as a fallback. No point in keeping it, IMO. Can't comment on the rest. Daniel. -- -- Daniel Calvelo Aros From jachym.cepicky at gmail.com Mon Apr 16 21:41:00 2007 From: jachym.cepicky at gmail.com (Jachym Cepicky) Date: Mon Apr 16 21:41:07 2007 Subject: [GRASS-dev] icon testing In-Reply-To: References: Message-ID: <1176752460.8628.9.camel@mellon> Hi, I think, they are really nice. Jachym Michael Barton p??e v Ne 15. 04. 2007 v 12:25 -0700: > Someone (sorry, but I forgot who) suggested the silk icon set at > famfamfam.com would be worth looking at for wxgrass. > > I took a look at these, and also wrote their creator about the > possibility of working with us to design GIS-specific icons (haven?t > heard back yet). > > Many are nice, though all are small (16x16). I tried using these in > the wxgrass toolbars to see how they looked. I had to modify a couple > (and would need to modify more to really use these). So that others > could take a look, I uploaded the results to the svn. There is an icon > directory with the icons I used, and silk versions of wxgui.py and > toolbars.py. You?ll need to add the icons directory and contents > to /wx, and rename wxgui_silk.py to wxgui.py and toolbars_silk.py to > toolbars.py. > > My impression is that the stock silk set are OK, but not a significant > improvement over what we?ve got. Also, they are kind of small (at > least for my eyes) and we?d still need some additional custom icons > beyond the large set provided in the silk set. But it does offer a > different look and might inspire an artistic reader of this list to > design some new ones for us. > > Michael > __________________________________________ > Michael Barton, Professor of Anthropology > School of Human Evolution & Social Change > Center for Social Dynamics & Complexity > Arizona State University > > phone: 480-965-6213 > fax: 480-965-7671 > www: http://www.public.asu.edu/~cmbarton > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev -- Jachym Cepicky e-mail: jachym.cepicky@gmail.com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub From glynn at gclements.plus.com Mon Apr 16 22:14:34 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Apr 16 22:14:40 2007 Subject: [GRASS-dev] Unused files In-Reply-To: <1a486f560704161212t747f68fdoa0b1ae7559ca42a@mail.gmail.com> References: <17955.44112.860626.760287@cerise.gclements.plus.com> <1a486f560704161212t747f68fdoa0b1ae7559ca42a@mail.gmail.com> Message-ID: <17955.55594.85261.133619@cerise.gclements.plus.com> Daniel Calvelo wrote: > > lib/db/dbmi_client/c_add_col.c | db_add_column > > lib/db/dbmi_client/c_bindupdate.c | db_bind_update > > lib/db/dbmi_client/c_createdb.c | db_create_database > > lib/db/dbmi_client/c_delete.c | db_delete > > lib/db/dbmi_client/c_deletedb.c | db_delete_database > > lib/db/dbmi_client/c_drop_col.c | db_drop_column > > lib/db/dbmi_client/c_drop_index.c | db_drop_index > > lib/db/dbmi_client/c_drop_tab.c | db_drop_table > > lib/db/dbmi_client/c_finddb.c | db_find_database > > lib/db/dbmi_client/c_insert.c | db_insert > > lib/db/dbmi_client/c_list_idx.c | db_list_indexes > > lib/db/dbmi_client/c_listdb.c | db_list_databases > > lib/db/dbmi_client/c_openinsert.c | db_open_insert_cursor > > lib/db/dbmi_client/c_openupdate.c | db_open_update_cursor > > lib/db/dbmi_client/c_update.c | db_update > > lib/db/dbmi_client/c_version.c | db_gversion > > lib/db/dbmi_client/printtab.c | db_print_column_definition > > lib/db/dbmi_client/printtab.c | db_print_table_definition > > lib/db/dbmi_driver/d_mkdir.c | db_driver_mkdir > > Aren't these template functions and files to develop new drivers? No; they are the actual client-side DBMI interface. I was surprised to find so many of them unused. -- Glynn Clements From dylan.beaudette at gmail.com Mon Apr 16 22:20:33 2007 From: dylan.beaudette at gmail.com (Dylan Beaudette) Date: Mon Apr 16 22:19:45 2007 Subject: [GRASS-dev] icon testing In-Reply-To: <1176752460.8628.9.camel@mellon> References: <1176752460.8628.9.camel@mellon> Message-ID: <200704161320.33265.dylan.beaudette@gmail.com> Michael Barton p??e v Ne 15. 04. 2007 v 12:25 -0700: > Someone (sorry, but I forgot who) suggested the silk icon set at > famfamfam.com would be worth looking at for wxgrass. > those look quite nice!!! Dylan -- Dylan Beaudette Soils and Biogeochemistry Graduate Group University of California at Davis 530.754.7341 From neteler at itc.it Mon Apr 16 23:19:53 2007 From: neteler at itc.it (Markus Neteler) Date: Mon Apr 16 23:20:02 2007 Subject: [GRASS-dev] Unused files In-Reply-To: <17955.44112.860626.760287@cerise.gclements.plus.com> References: <17955.44112.860626.760287@cerise.gclements.plus.com> Message-ID: <20070416211952.GB9087@bartok.itc.it> On Mon, Apr 16, 2007 at 06:03:12PM +0100, Glynn Clements wrote: > > There are currently 78 source files whose functions don't appear to be > used by anything. > > Some of these may be used by components which aren't being compiled on > my system, and some have been added with the intention of future use. > OTOH, some of them may simply be obsolete. > > Please provide comments as to whether specific files should or > shouldn't be removed. > > The complete list is: > > lib/cdhc/enormp.c | enormp > lib/cdhc/shapiro2.c | shapiro_francia > lib/cdhc/shapiroe.c | shapiro_wilk_exp > lib/cdhc/cvmw2e.c | cramer_von_mises_exp > lib/cdhc/kse.c | kolmogorov_smirnov_exp > lib/cdhc/kuiprsve.c | kuipers_v_exp > lib/cdhc/watsonue.c | watson_u2_exp > lib/cdhc/andrsnde.c | anderson_darling_exp > lib/cdhc/chisqe.c | chi_square_exp Probably these cdhc/ should go into gmath/ in any case for future developments? [ ... dbmi ...] I feel that DBMI was left in the middle of its development, in particular Radim was digging through and making it functional (the needed parts). I have no idea which parts can be savely abandoned. > lib/gmath/la.c | G__matrix_add The la stuff us the LAPACK wrapper and needed for i.spec.unix (Spectral Unmixing) on which Brad is working to make it ready for GRASS 6 (it's one of my MSc modules). Please keep. > lib/gmath/svd.c | G_svbksb > lib/gmath/svd.c | G_svdcmp > lib/gmath/svd.c | G_svelim Single Value Decomposition was originally in lib/gis/, I had moved it there and originally used it for Spectral Unmixing (matrix inversion). In the end I had to use a different approach. But probably SVD is useful for someone in future. > lib/imagery/add_cov.c | I_add_covariances > lib/imagery/advance.c | I_tape_advance > lib/imagery/ask.c | I_ask > lib/imagery/ask_subgrp.c | I_ask_subgroup_new > lib/imagery/ask_subgrp.c | I_ask_subgroup_old > lib/imagery/band_io.c | I_close_band > lib/imagery/band_io.c | I_open_band_new > lib/imagery/colors.c | I_free_group_colors > lib/imagery/colors.c | I_read_group_blu_colors > lib/imagery/colors.c | I_read_group_colors > lib/imagery/colors.c | I_read_group_grn_colors > lib/imagery/colors.c | I_read_group_red_colors > lib/imagery/colors.c | I_write_group_blu_colors > lib/imagery/colors.c | I_write_group_colors > lib/imagery/colors.c | I_write_group_grn_colors > lib/imagery/colors.c | I_write_group_red_colors > lib/imagery/image.c | I_close_image > lib/imagery/image.c | I_get_image_row > lib/imagery/image.c | I_image_colors > lib/imagery/image.c | I_open_image > lib/imagery/image.c | I_translate_image_data > lib/imagery/open.c | I_open_group_file_new > lib/imagery/open.c | I_open_group_file_old > lib/imagery/percent.c | I_percent > lib/imagery/proj.c | I_must_be_imagery_projection > lib/imagery/sig2cats.c | I_signature_to_cats These imagery functions, if really unused, are probably delete candidates. > lib/vector/Vlib/dbcolumns.c | Vect_get_column_names > lib/vector/Vlib/dbcolumns.c | Vect_get_column_names_types > lib/vector/Vlib/dbcolumns.c | Vect_get_column_types > lib/vector/Vlib/graph.c | Vect_graph_add_edge > lib/vector/Vlib/graph.c | Vect_graph_build > lib/vector/Vlib/graph.c | Vect_graph_init > lib/vector/Vlib/graph.c | Vect_graph_set_node_costs > lib/vector/Vlib/graph.c | Vect_graph_shortest_path > lib/vector/Vlib/overlap.c | V__map_overlap > lib/vector/Vlib/overlay.c | Vect_overlay > lib/vector/Vlib/overlay.c | Vect_overlay_and > lib/vector/Vlib/overlay.c | Vect_overlay_str_to_operator I am suprised to see these Vect functions unused. Really sure? > lib/vector/dglib/avl.c | avl_allocator_default avl: libavl - library for manipulation of binary trees I think we have also lib/btree/ is that's the same purpose? No idea about the other functions. Markus From wolf+grass at bergenheim.net Tue Apr 17 00:12:30 2007 From: wolf+grass at bergenheim.net (Wolf Bergenheim) Date: Tue Apr 17 00:13:07 2007 Subject: [GRASS-dev] improved d.labels rendering In-Reply-To: <20070406192244.5a4ee513.hamish_nospam@yahoo.com> References: <20070406192244.5a4ee513.hamish_nospam@yahoo.com> Message-ID: <4623F4CE.2030903@bergenheim.net> On 06.04.2007 10:22, Hamish wrote: > Hi, > > Text rotation now works properly in d.labels for any justification > setting. Also placement is improved for all center and lower justified > text. Even multi-line labels are working correctly. > > Only lightly tested so far. I haven't tested multi-line labels, but rotation seems to work nicely. There is however a bug. If there is a space between the ':' and the label text, the space becomes part of the label and thus the label is shifted to the right by one space. I have worked around this in v.label.sa by not adding a space between the ':' and the label text. I have also attached a patch which will add support for a label position "none none", which simply means to place the label at the exact point given (no shifting in any direction). So please test this together with the newest version of v.label.sa in the cvs. I have not enabled compilation on it automatically (yet), so you have to run make in vector/v.label.sa before running make install. In other words I'm looking for feedback on the performance of this module, v.label.sa. Not the code (it is still a bit of a mess), but the results. I'm especially interested if you find some odd behavior. It should behave quite nicely... but you never know. I keep finding bugs... > For TrueType fonts you need to set the path to the font name in the > v.label step. (run-time override won't work anymore) Yeah. This is a very nice addition. It works really well. Just what I needed for my v.label.sa :) --Wolf -- <:3 )---- Wolf Bergenheim ----( 8:> -------------- next part -------------- A non-text attachment was scrubbed... Name: display~d.paint.labels~do_labels.c.diff Type: text/x-patch Size: 2954 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070417/a1a86de1/displayd.paint.labelsdo_labels.c-0001.bin From glynn at gclements.plus.com Tue Apr 17 00:21:02 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Apr 17 00:21:04 2007 Subject: [GRASS-dev] Unused files In-Reply-To: <20070416211952.GB9087@bartok.itc.it> References: <17955.44112.860626.760287@cerise.gclements.plus.com> <20070416211952.GB9087@bartok.itc.it> Message-ID: <17955.63182.103807.825355@cerise.gclements.plus.com> Markus Neteler wrote: > These imagery functions, if really unused, are probably > delete candidates. Apart from that, it would be nice to start 7.x with "rm -rf imagery/", and telling people to clean stuff up before they put it back in. If I'm making the same change to every file which uses a particular function, I know I've reached the imagery directory when I start seeing almost exactly the same file over and over again. E.g.: imagery/i.ortho.photo/photo.2image/analyze.c imagery/i.ortho.photo/photo.2target/analyze.c imagery/i.points/analyze.c imagery/i.vpoints/analyze.c or: imagery/i.ortho.photo/photo.2image/ask_mag.c imagery/i.ortho.photo/photo.2target/ask_mag.c imagery/i.points/ask_mag.c imagery/i.vpoints/ask_mag.c or: imagery/i.ortho.photo/photo.2image/call.c imagery/i.ortho.photo/photo.2target/call.c imagery/i.points/call.c imagery/i.vpoints/call.c or: [well, you get the idea.] > > lib/vector/Vlib/dbcolumns.c | Vect_get_column_names > > lib/vector/Vlib/dbcolumns.c | Vect_get_column_names_types > > lib/vector/Vlib/dbcolumns.c | Vect_get_column_types > > lib/vector/Vlib/graph.c | Vect_graph_add_edge > > lib/vector/Vlib/graph.c | Vect_graph_build > > lib/vector/Vlib/graph.c | Vect_graph_init > > lib/vector/Vlib/graph.c | Vect_graph_set_node_costs > > lib/vector/Vlib/graph.c | Vect_graph_shortest_path > > lib/vector/Vlib/overlap.c | V__map_overlap > > lib/vector/Vlib/overlay.c | Vect_overlay > > lib/vector/Vlib/overlay.c | Vect_overlay_and > > lib/vector/Vlib/overlay.c | Vect_overlay_str_to_operator > > I am suprised to see these Vect functions unused. Really sure? I'm quite sure. > > lib/vector/dglib/avl.c | avl_allocator_default > > avl: libavl - library for manipulation of binary trees > I think we have also lib/btree/ is that's the same purpose? Yes; both provide essentially the same functionality. AVL trees are balanced, so they have better worst-case performance. Unbalanced trees are O(log(n)) for random data but degenerate to O(n) for sorted data (you essentially end up with a linked list). Balanced trees are always O(log(n)), although with a higher constant factor for insertions due to the cost of rebalancing. -- Glynn Clements From tlaronde at polynum.com Tue Apr 17 00:58:53 2007 From: tlaronde at polynum.com (tlaronde@polynum.com) Date: Tue Apr 17 00:55:31 2007 Subject: [GRASS-dev] Unused files In-Reply-To: <17955.63182.103807.825355@cerise.gclements.plus.com> References: <17955.44112.860626.760287@cerise.gclements.plus.com> <20070416211952.GB9087@bartok.itc.it> <17955.63182.103807.825355@cerise.gclements.plus.com> Message-ID: <20070416225852.GA168@polynum.com> On Mon, Apr 16, 2007 at 11:21:02PM +0100, Glynn Clements wrote: > > Markus Neteler wrote: > > > These imagery functions, if really unused, are probably > > delete candidates. > > Apart from that, it would be nice to start 7.x with "rm -rf imagery/", > and telling people to clean stuff up before they put it back in. > > If I'm making the same change to every file which uses a particular > function, I know I've reached the imagery directory when I start > seeing almost exactly the same file over and over again. E.g.: > > imagery/i.ortho.photo/photo.2image/analyze.c > imagery/i.ortho.photo/photo.2target/analyze.c > imagery/i.points/analyze.c > imagery/i.vpoints/analyze.c > or: > imagery/i.ortho.photo/photo.2image/ask_mag.c > imagery/i.ortho.photo/photo.2target/ask_mag.c > imagery/i.points/ask_mag.c > imagery/i.vpoints/ask_mag.c > or: > imagery/i.ortho.photo/photo.2image/call.c > imagery/i.ortho.photo/photo.2target/call.c > imagery/i.points/call.c > imagery/i.vpoints/call.c > or: > [well, you get the idea.] FWIW, it is indeed a nightmare. I have already---in KerGIS---extracted the duplicates in a dedicated library, but trying to fix the only 3 imargery modules that are left (for the complete resurrection of the CERL GRASS), I have, one more time, to rework everything because they are slighty different, with some modifications in the choice of colors etc. Not to mention that the C programming skills are the lowest I have ever seen (with even comments saying that "this function returns something so that the program doesn't exit". I have the finger on the trigger and a _huge_ temptation, but in this case I will nuke the externally produced additions of imagery, and keep the CERL original programs (Shapiro). I'm at the moment simplifying v.digit(1) to put the curses interface apart (to allow to throw, supplementary to it, an Athena and a Motif) and I will come back to this... thing after that to see if I feel courageaous enough. Just to say that Glynn may seem rough, but I have the exact same feeling and I think it is the correct solution (but keeping original modules from CERL---at least that's what I will do in KerGIS; these are not difficult to clean and fix and they are so much better written)! Cleaning the CERL code, and understanding how it worked (and reorganizing etc.) has, finally, taken me less time (or at least less headache and no discouragement). And everytime I see the name of the responsible for this in a module, life expectancy of the module drops dramatically... Well, seing that I have "lost" almost one year without being able to finish this, I do think I will nuke the imagery additions. Cheers, -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C From michael.barton at asu.edu Tue Apr 17 06:31:39 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Apr 17 06:31:48 2007 Subject: [GRASS-dev] problem with r.colors on Mac In-Reply-To: <17948.48049.681105.666051@cerise.gclements.plus.com> Message-ID: On 4/11/07 3:42 AM, "Glynn Clements" wrote: >> If read is a problem, what is an alternative? > > gets. > > Gronsole::output_to_gronsole is written on the assumption that it will > get complete lines. Gronsole::readout tries to do this, but fails to > allow for the fact that "read" may return arbitrary chunks of data > (i.e. partial lines). > > If the stream is in non-blocking mode, gets will return an empty > string if a complete line isn't available. The fblocked function can > be used to distinguish this from the case where the process wrote a > blank line. Also, after this case occurs, another readable event won't > be generated for the stream until a complete line is available. > >> I don't understand the >> gronsole code very well (didn't write it), but I might be able to fix a >> specific issue like this. > > Gronsole::readout is the relevant function. Glynn, Now that I have cvs access again and could update, I tried to fix this. I changed Gronsole::readout as indicated below. Gronsole seems to work OK with the change, but the TckTk GUI still crashes when I run r.colors ?e. It also seems to crash more often with other commands too. I?m guessing its the same cause. The change below does not seem to fix it, but I want to know if this is what you had in mind. ##### ORIGINAL CODE ##### proc Gronsole::readout {path ci mark fh} { set str [read $fh] if {[string length $str] != 0} { Gronsole::add_data_tag $path $ci out } set lines [split $str "\n"] foreach line [lrange $lines 0 [expr [llength $lines] - 2]] { Gronsole::output_to_gronsole $path $mark $ci [list cmd$ci cmd$ci-out] "$line\n" } set last [lindex $lines end] if {$last != {}} { Gronsole::output_to_gronsole $path $mark $ci [list cmd$ci cmd$ci-out] $last } $path.text see $mark } ##### REVISED CODE ##### proc Gronsole::readout {path ci mark fh} { # I left this first part in because it seems to simply make an output locale if there is something in $fh set str [read $fh] if {[string length $str] != 0} { Gronsole::add_data_tag $path $ci out } # here I changed all the above code to use gets and read line by line rather than create line by line output with split while {[gets $fh line] >= 0} { Gronsole::output_to_gronsole $path $mark $ci [list cmd$ci cmd$ci-out] "$line\n" } $path.text see $mark } Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070416/e389272f/attachment.html From hamish_nospam at yahoo.com Tue Apr 17 06:34:24 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Apr 17 06:35:07 2007 Subject: [GRASS-dev] improved d.labels rendering In-Reply-To: <4623F4CE.2030903@bergenheim.net> References: <20070406192244.5a4ee513.hamish_nospam@yahoo.com> <4623F4CE.2030903@bergenheim.net> Message-ID: <20070417163424.30014bdc.hamish_nospam@yahoo.com> > Hamish wrote: > > Text rotation now works properly in d.labels for any justification > > setting. Also placement is improved for all center and lower > > justified text. Even multi-line labels are working correctly. > > > > Only lightly tested so far. Wolf wrote: > I haven't tested multi-line labels, but rotation seems to work nicely. > There is however a bug. If there is a space between the ':' and the > label text, the space becomes part of the label and thus the label is > shifted to the right by one space. I have worked around this in > v.label.sa by not adding a space between the ':' and the label text. this is a bug in the rendering stage, not at the labels file creation stage (there is nothing wrong with the labels file). Fixed last week in d.labels/do_labels.c revs 1.20,1.21 with the improved rotation code. ps.map was already working correctly. > I have also attached a patch which will add support for a label > position "none none", which simply means to place the label at the > exact point given (no shifting in any direction). how does that differ from center,center (the default)? or is it "raw", which is {R_move_abs(x,y); R_text(string);} in that case how does none,none differ from the lower,left case? (why is this useful?) I just added some debug code in d.labels to write the rotated text bounding boxes out to a vector ascii file. (zoom dependent, even with size=mapunits, as the rendered font size is not smooth but jumps by quantum amounts) Hamish (mostly off-line for the next few days) From wolf+grass at bergenheim.net Tue Apr 17 07:47:18 2007 From: wolf+grass at bergenheim.net (Wolf Bergenheim) Date: Tue Apr 17 07:47:57 2007 Subject: [GRASS-dev] improved d.labels rendering In-Reply-To: <20070417163424.30014bdc.hamish_nospam@yahoo.com> References: <20070406192244.5a4ee513.hamish_nospam@yahoo.com> <4623F4CE.2030903@bergenheim.net> <20070417163424.30014bdc.hamish_nospam@yahoo.com> Message-ID: <46245F66.1020808@bergenheim.net> On 17.04.2007 07:34, Hamish wrote: > Wolf wrote: >> I haven't tested multi-line labels, but rotation seems to work nicely. >> There is however a bug. If there is a space between the ':' and the >> label text, the space becomes part of the label and thus the label is >> shifted to the right by one space. I have worked around this in >> v.label.sa by not adding a space between the ':' and the label text. > > this is a bug in the rendering stage, not at the labels file creation > stage (there is nothing wrong with the labels file). Fixed last week in > d.labels/do_labels.c revs 1.20,1.21 with the improved rotation code. Yes, exactly as I said. However it isn't fixed (see attached screen shots; with_space.png and without_space.png) > > ps.map was already working correctly. > I haven't tested. >> I have also attached a patch which will add support for a label >> position "none none", which simply means to place the label at the >> exact point given (no shifting in any direction). > > how does that differ from center,center (the default)? or is it "raw", > which is {R_move_abs(x,y); R_text(string);} in that case how does > none,none differ from the lower,left case? > (why is this useful?) I want the lower left corner of the text should go exactly on the point given in the labels file. center,center puts the center of the text, and lower,left put the lower left, but with some magic adjustment. So I guess it is sort of "raw". In v.label.sa I calculate the exact position of a label and it may not be shifted, or else the algorithm doesn't hold. If someone could just verify that the attached patch works, I can commit it. (I have made it against the most recent CVS version) --Wolf -- <:3 )---- Wolf Bergenheim ----( 8:> -------------- next part -------------- A non-text attachment was scrubbed... Name: with_space.png Type: image/png Size: 18726 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070417/9a8c80a6/with_space-0001.png -------------- next part -------------- A non-text attachment was scrubbed... Name: without_space.png Type: image/png Size: 13257 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070417/9a8c80a6/without_space-0001.png -------------- next part -------------- A non-text attachment was scrubbed... Name: display~d.paint.labels~do_labels.c.diff Type: text/x-patch Size: 2525 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070417/9a8c80a6/displayd.paint.labelsdo_labels.c-0001.bin From hamish_nospam at yahoo.com Tue Apr 17 08:52:28 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Apr 17 08:53:10 2007 Subject: [GRASS-dev] improved d.labels rendering In-Reply-To: <46245F66.1020808@bergenheim.net> References: <20070406192244.5a4ee513.hamish_nospam@yahoo.com> <4623F4CE.2030903@bergenheim.net> <20070417163424.30014bdc.hamish_nospam@yahoo.com> <46245F66.1020808@bergenheim.net> Message-ID: <20070417185228.71b32513.hamish_nospam@yahoo.com> > > Wolf wrote: > >> I haven't tested multi-line labels, but rotation seems to work > >> nicely. There is however a bug. If there is a space between the ':' > >> and the label text, the space becomes part of the label and thus > >> the label is shifted to the right by one space. I have worked > >> around this in v.label.sa by not adding a space between the ':' and > >> the label text. Hamish: > > this is a bug in the rendering stage, not at the labels file > > creation stage (there is nothing wrong with the labels file). Fixed > > last week in d.labels/do_labels.c revs 1.20,1.21 with the improved > > rotation code. > > Yes, exactly as I said. However it isn't fixed (see attached screen > shots; with_space.png and without_space.png) sorry, I don't understand. Are Yichang and Kinmen supposed to be lined up in those? Or are you saying that all text (regardless of multi-line) are shifted +1 char to the right? Can you create a labels file from spearfish's bugsites and edit the labels file so one of the entries is like- text: line of text1\nline of text 22\nline of text 333 then post the exact v.label command line + label entry to recreate the bug? or, what does your text: entry look like for each of those screenshots? text:Yichang\nKinmen vs text: Yichang\nKinmen ? Perhaps only seen with TTF? W: > >> I have also attached a patch which will add support for a label > >> position "none none", which simply means to place the label at the > >> exact point given (no shifting in any direction). H: > > how does that differ from center,center (the default)? or is it > > "raw", which is {R_move_abs(x,y); R_text(string);} in that case how > > does none,none differ from the lower,left case? > > (why is this useful?) W: > I want the lower left corner of the text should go exactly on the > point given in the labels file. as given by the lower-left corner of the bounding box around the text, or the lower-left corner of the first letter [or letter block] of text? ps.map seems to justify the text directly on the edge of the bounding box. d.labels currently pads a bit of space between the point and the label, this extra space is by design. I think that the 1 space padding before the start of the border box is nicer. Regardless, ps.map and d.labels should try and do the same thing, be it padding or no padding. With "none" are you trying to remove the padding from d.labels? > center,center puts the center of the > text, and lower,left put the lower left, but with some magic > adjustment. So I guess it is sort of "raw". In v.label.sa I calculate > the exact position of a label and it may not be shifted, or else the > algorithm doesn't hold. (so it works? great!) I think I will have to try .sa well to understand the problem properly. Any spearfish maps which are a good example? W: > If someone could just verify that the attached patch works, I can > commit it. (I have made it against the most recent CVS version) I would like to understand the problem better before committing anything to CVS. (ie be comfortable that we are not adding new features to work around some shortcoming when we should be instead fixing that shortcoming in the first place) Unfortunately today I am short on time and capacity to help. :-/ Hamish From jan-oliver.wagner at intevation.de Tue Apr 17 09:20:50 2007 From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner) Date: Tue Apr 17 09:20:54 2007 Subject: [GRASS-dev] commercial GRASS development In-Reply-To: <20070416144236.530f41ac@thoe.hq.intevation.de> References: <20070416144236.530f41ac@thoe.hq.intevation.de> Message-ID: <200704170920.51339.jan-oliver.wagner@intevation.de> On Monday 16 April 2007 14:42, Stephan Holl wrote: > some time ago I asked Markus about commercial GRASS development in the > past. He gave some information about this so I summed it up and put it > on a wiki-page[1]. > > Assuming the given list is not complete I like to invite everybody who > developed something for GRASS in a commercial way to add it to the wiki. > > Hopefuly we can make this list extend. IMHO it should better be made clear who contracted, who was contracted and what was the outcome (perhaps a table with three columns). The first column may be empty if the name may not be given to the public. This way it xould be more easily identified which companies really worked under contract for GRASS. This is to be seen separate from regular contributions which of course needs to be honoured but are done under different conditions. Best Jan -- Dr. Jan-Oliver Wagner Intevation GmbH, Osnabr?ck Amtsgericht Osnabr?ck, HR B 18998 http://www.intevation.de/ Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From mmaldacker at gmail.com Tue Apr 17 10:18:31 2007 From: mmaldacker at gmail.com (maximilian maldacker) Date: Tue Apr 17 10:18:34 2007 Subject: [GRASS-dev] Google Summer Of Code Project Message-ID: Hello everyone, my name is Maximilian Maldacker and I'm currently a student in Imperial College London studying Mathematics and Computer Science. My project on "Shortest path in free (vector) space avoiding obstacles module in GRASS" was select by Google Summer of Code and I'm looking forward to it :-). I actually start on the 28th of May but I thought I'd introduce my self before and get involved with the community. I have a few question concerning the development of the module. I see modules are organized in several folders and I thought I can create a new folder in the display folder named d.path_obstacles or something similar. Is it sufficient to create a new folder with a Makefile inside and a few *.c files to make a new module and will it be recognized by the command line? The plan for now is to develop a module similar to the d.path one except it will start with a vector space containing obstacles ( i.e. polygons ) and it will construct a visibility graph out of it and compute the shortest path between two given points. Should the visibility graph construction algorithm be added to the Directed Graph Library? What is the best way to test my code? Should I keep a fresh copy of GRASS on my computer, modify/create files, compile everything and test it using the spearfish example? Or is there another way? Thank you for your help and I'm looking forward to help develop GRASS. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070417/97b566ce/attachment.html From wolf+grass at bergenheim.net Tue Apr 17 14:40:33 2007 From: wolf+grass at bergenheim.net (Wolf Bergenheim) Date: Tue Apr 17 14:41:09 2007 Subject: [GRASS-dev] Google Summer Of Code Project In-Reply-To: References: Message-ID: <4624C041.40007@bergenheim.net> As most of you probably know I'm going to work as mentor for Maximilian during the summer, but most (if not all) of the technical discussion is going to take place here on this list, and we'd greatly appreciate any comments and feedback you have. On 17.04.2007 11:18, maximilian maldacker wrote: > I have a few question concerning the development of the module. I see > modules are organized in several folders and I thought I can create a > new folder in the display folder named d.path_obstacles or something > similar. I'd recommend using a period, like d.path.obstacles Do we have any module naming conventions? > Is it sufficient to create a new folder with a Makefile inside > and a few *.c files to make a new module and will it be recognized by > the command line? You can copy the makefile from another module, like d.path, and modify it to suit your needs, or copy the example Makefile, and modify that. The makefiles are set up so that they compile all C files into a module. > The plan for now is to develop a module similar to the d.path one except > it will start with a vector space containing obstacles ( i.e. polygons ) > and it will construct a visibility graph out of it and compute the > shortest path between two given points. Should the visibility graph > construction algorithm be added to the Directed Graph Library? I don't really see it being used anywhere else, so I'd just start by putting it in a file of it's own, and developing it separately from the module, so it can be integrated into the Directed Graph Library later, if we choose to do that. Anybody else have views on this? > What is the best way to test my code? Should I keep a fresh copy of > GRASS on my computer, modify/create files, compile everything and test > it using the spearfish example? Or is there another way? I only have the CVS version checked out. I know others have multiple versions installed for testing, but I'd say it should be enough for you to have only the CVS copy checked out. Spearfish data could be used, or then you can make your own, or perhaps someone has a suitable data set, like showing buildings in an area? > > Thank you for your help and I'm looking forward to help develop GRASS. > Welcome, welcome. I think it will be an interesting summer (of code ;)) --Wolf -- <:3 )---- Wolf Bergenheim ----( 8:> From wolf+grass at bergenheim.net Tue Apr 17 15:10:17 2007 From: wolf+grass at bergenheim.net (Wolf Bergenheim) Date: Tue Apr 17 15:10:53 2007 Subject: [GRASS-dev] improved d.labels rendering In-Reply-To: <20070417185228.71b32513.hamish_nospam@yahoo.com> References: <20070406192244.5a4ee513.hamish_nospam@yahoo.com> <4623F4CE.2030903@bergenheim.net> <20070417163424.30014bdc.hamish_nospam@yahoo.com> <46245F66.1020808@bergenheim.net> <20070417185228.71b32513.hamish_nospam@yahoo.com> Message-ID: <4624C739.8080208@bergenheim.net> On 17.04.2007 09:52, Hamish wrote: >>> Wolf wrote: >>>> I haven't tested multi-line labels, but rotation seems to work >>>> nicely. There is however a bug. If there is a space between the ':' >>>> and the label text, the space becomes part of the label and thus >>>> the label is shifted to the right by one space. I have worked >>>> around this in v.label.sa by not adding a space between the ':' and >>>> the label text. > Hamish: >>> this is a bug in the rendering stage, not at the labels file >>> creation stage (there is nothing wrong with the labels file). Fixed >>> last week in d.labels/do_labels.c revs 1.20,1.21 with the improved >>> rotation code. >> Yes, exactly as I said. However it isn't fixed (see attached screen >> shots; with_space.png and without_space.png) > > sorry, I don't understand. Are Yichang and Kinmen supposed to be lined > up in those? Or are you saying that all text (regardless of multi-line) > are shifted +1 char to the right? Exactly. Shifted +1 char to the right (by the width of a space character) > > Can you create a labels file from spearfish's bugsites and edit the > labels file so one of the entries is like- > text: line of text1\nline of text 22\nline of text 333 > > then post the exact v.label command line + label entry to recreate the > bug? I use v.label.sa to generate the label files, and I'm quite sure there is no bug in that (as it is basically a copy of what d.label does). > > or, > what does your text: entry look like for each of those screenshots? > text:Yichang\nKinmen > vs > text: Yichang\nKinmen > ? Sorry, it was perhaps a bad example. Yichang and Kinmen are 2 labels, and if you look at the two images you see that the first (with space) is shifted to the right by one " " character. The with_space version has label text like text: Yichang And the without_space has text:Yichang I have added another screen shot showing the label point and the label text with and without space, and the effect of my patch to add none none support. Here is the labels file for these: ------------------------------------------------------------------- east: 662726.716593 north: 4036029.863873 xoffset: -0.000000 yoffset: -0.000000 ref: lower left font: /usr/share/fonts/truetype/ttf-bitstream-vera/Vera.ttf color: green size: 150.000000 width: 1 hcolor: none hwidth: 0 background: none border: none opaque: yes rotate: 0.000000 text: LL Space east: 662726.716593 north: 4036029.863873 xoffset: -0.000000 yoffset: -0.000000 ref: lower left font: /usr/share/fonts/truetype/ttf-bitstream-vera/Vera.ttf color: blue size: 150.000000 width: 1 hcolor: none hwidth: 0 background: none border: none opaque: yes rotate: 0.000000 text:LL No Space east: 662726.716593 north: 4036029.863873 xoffset: -0.000000 yoffset: -0.000000 ref: none none font: /usr/share/fonts/truetype/ttf-bitstream-vera/Vera.ttf color: red size: 150.000000 width: 1 hcolor: none hwidth: 0 background: none border: none opaque: yes rotate: 0.000000 text: N Space east: 662726.716593 north: 4036029.863873 xoffset: -0.000000 yoffset: -0.000000 ref: none none font: /usr/share/fonts/truetype/ttf-bitstream-vera/Vera.ttf color: black size: 150.000000 width: 1 hcolor: none hwidth: 0 background: none border: none opaque: yes rotate: 0.000000 text:N No Space ------------------------------------------------------------------- The point is located at the north, east coordinates given in the label file. I can live with the minimal shift which is probably due to cell size or something. Note that all four labels have the same coordinates. --Wolf -- <:3 )---- Wolf Bergenheim ----( 8:> -------------- next part -------------- A non-text attachment was scrubbed... Name: d.labels_problem.png Type: image/png Size: 24279 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070417/9c64acbc/d.labels_problem-0001.png From benjamin.ducke at ufg.uni-kiel.de Tue Apr 17 15:46:18 2007 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Tue Apr 17 15:31:05 2007 Subject: [GRASS-dev] Google Summer Of Code Project In-Reply-To: <4624C041.40007@bergenheim.net> References: <4624C041.40007@bergenheim.net> Message-ID: <4624CFAA.3030800@ufg.uni-kiel.de> Wolf Bergenheim wrote: > As most of you probably know I'm going to work as mentor for Maximilian > during the summer, but most (if not all) of the technical discussion is > going to take place here on this list, and we'd greatly appreciate any > comments and feedback you have. > > On 17.04.2007 11:18, maximilian maldacker wrote: >> I have a few question concerning the development of the module. I see >> modules are organized in several folders and I thought I can create a >> new folder in the display folder named d.path_obstacles or something >> similar. > > I'd recommend using a period, like > d.path.obstacles This implies that it's going to be a module that makes use of the original GRASS display architecture in the style of d.path. May I suggest at least creating a non-interactive, display-independent version that simply outputs the path to a new vector map? Sth. like v.path.obstacles. This way we'll be able to make the contribution more portable, e.g. for use with QGIS and GRASS under Windows. > > Do we have any module naming conventions? > >> Is it sufficient to create a new folder with a Makefile inside >> and a few *.c files to make a new module and will it be recognized by >> the command line? > > You can copy the makefile from another module, like d.path, and modify > it to suit your needs, or copy the example Makefile, and modify that. > The makefiles are set up so that they compile all C files into a module. > >> The plan for now is to develop a module similar to the d.path one except >> it will start with a vector space containing obstacles ( i.e. polygons ) >> and it will construct a visibility graph out of it and compute the >> shortest path between two given points. Should the visibility graph >> construction algorithm be added to the Directed Graph Library? > > I don't really see it being used anywhere else, so I'd just start by > putting it in a file of it's own, and developing it separately from the > module, so it can be integrated into the Directed Graph Library later, > if we choose to do that. Anybody else have views on this? > >> What is the best way to test my code? Should I keep a fresh copy of >> GRASS on my computer, modify/create files, compile everything and test >> it using the spearfish example? Or is there another way? > > I only have the CVS version checked out. I know others have multiple > versions installed for testing, but I'd say it should be enough for you > to have only the CVS copy checked out. Spearfish data could be used, or > then you can make your own, or perhaps someone has a suitable data set, > like showing buildings in an area? > >> Thank you for your help and I'm looking forward to help develop GRASS. >> > > Welcome, welcome. I think it will be an interesting summer (of code ;)) > > --Wolf > -- Benjamin Ducke, M.A. Arch?oinformatik (Archaeoinformation Science) Institut f?r Ur- und Fr?hgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universit?t zu Kiel Johanna-Mestorf-Stra?e 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg From mlennert at club.worldonline.be Tue Apr 17 16:14:24 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Tue Apr 17 16:11:12 2007 Subject: [GRASS-dev] Unused files In-Reply-To: <17955.55594.85261.133619@cerise.gclements.plus.com> References: <17955.44112.860626.760287@cerise.gclements.plus.com> <1a486f560704161212t747f68fdoa0b1ae7559ca42a@mail.gmail.com> <17955.55594.85261.133619@cerise.gclements.plus.com> Message-ID: <4624D640.2030304@club.worldonline.be> On 16/04/07 22:14, Glynn Clements wrote: > Daniel Calvelo wrote: > >>> lib/db/dbmi_client/c_add_col.c | db_add_column >>> lib/db/dbmi_client/c_bindupdate.c | db_bind_update >>> lib/db/dbmi_client/c_createdb.c | db_create_database >>> lib/db/dbmi_client/c_delete.c | db_delete >>> lib/db/dbmi_client/c_deletedb.c | db_delete_database >>> lib/db/dbmi_client/c_drop_col.c | db_drop_column >>> lib/db/dbmi_client/c_drop_index.c | db_drop_index >>> lib/db/dbmi_client/c_drop_tab.c | db_drop_table >>> lib/db/dbmi_client/c_finddb.c | db_find_database >>> lib/db/dbmi_client/c_insert.c | db_insert >>> lib/db/dbmi_client/c_list_idx.c | db_list_indexes >>> lib/db/dbmi_client/c_listdb.c | db_list_databases >>> lib/db/dbmi_client/c_openinsert.c | db_open_insert_cursor >>> lib/db/dbmi_client/c_openupdate.c | db_open_update_cursor >>> lib/db/dbmi_client/c_update.c | db_update >>> lib/db/dbmi_client/c_version.c | db_gversion >>> lib/db/dbmi_client/printtab.c | db_print_column_definition >>> lib/db/dbmi_client/printtab.c | db_print_table_definition >>> lib/db/dbmi_driver/d_mkdir.c | db_driver_mkdir >> Aren't these template functions and files to develop new drivers? > > No; they are the actual client-side DBMI interface. > > I was surprised to find so many of them unused. On 16/04/07 23:19, Markus Neteler wrote: > [ ... dbmi ...] > I feel that DBMI was left in the middle of its development, > in particular Radim was digging through and making it > functional (the needed parts). I have no idea which parts > can be savely abandoned. If they have useful code in them and could be potentially used, why not keep them and hope than someone picks things up ? Unless we decide either - that implementing these functionalities as scripts as we are doing now is better or at least just as good (e.g. the v.db.* scripts), or - that database management should be done via relevant db client programs (independent of GRASS) or db.execute. Moritz From wolf+grass at bergenheim.net Tue Apr 17 16:12:16 2007 From: wolf+grass at bergenheim.net (Wolf Bergenheim) Date: Tue Apr 17 16:12:50 2007 Subject: [GRASS-dev] Google Summer Of Code Project In-Reply-To: <4624CFAA.3030800@ufg.uni-kiel.de> References: <4624C041.40007@bergenheim.net> <4624CFAA.3030800@ufg.uni-kiel.de> Message-ID: <4624D5C0.20803@bergenheim.net> On 17.04.2007 16:46, Benjamin Ducke wrote: > > This implies that it's going to be a module that makes use of the > original GRASS display architecture in the style of d.path. > May I suggest at least creating a non-interactive, display-independent > version that simply outputs the path to a new vector map? > Sth. like v.path.obstacles. > This way we'll be able to make the contribution more portable, e.g. > for use with QGIS and GRASS under Windows. > Right. I agree with you Benjamin. it should be a non-interactive module, and output should be a vector map showing the shortest path. I also think that maybe it could optionally take multiple start/end points just like r.path does. --Wolf -- <:3 )---- Wolf Bergenheim ----( 8:> From mlennert at club.worldonline.be Tue Apr 17 16:28:56 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Tue Apr 17 16:25:45 2007 Subject: [GRASS-dev] Google Summer Of Code Project In-Reply-To: <4624D5C0.20803@bergenheim.net> References: <4624C041.40007@bergenheim.net> <4624CFAA.3030800@ufg.uni-kiel.de> <4624D5C0.20803@bergenheim.net> Message-ID: <4624D9A8.8020409@club.worldonline.be> On 17/04/07 16:12, Wolf Bergenheim wrote: > On 17.04.2007 16:46, Benjamin Ducke wrote: >> This implies that it's going to be a module that makes use of the >> original GRASS display architecture in the style of d.path. >> May I suggest at least creating a non-interactive, display-independent >> version that simply outputs the path to a new vector map? >> Sth. like v.path.obstacles. >> This way we'll be able to make the contribution more portable, e.g. >> for use with QGIS and GRASS under Windows. >> > > Right. I agree with you Benjamin. it should be a non-interactive module, > and output should be a vector map showing the shortest path. I also > think that maybe it could optionally take multiple start/end points just > like r.path does. Or like v.net.path, although I would plead for including startpoint=/endpoint= parameters, not only piping. Moritz From michael.barton at asu.edu Tue Apr 17 16:32:43 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Apr 17 16:32:47 2007 Subject: [GRASS-dev] overwrite and quite flags Message-ID: Maybe I missed something, but it seems that very recently, there has been a fundamental change to the behavior of the overwrite and quite flags. You used to be able to write EITHER --o OR ?overwrite and --q OR ?quiet. Now --o and --q are not accepted and you must write --quiet or --overwrite. Is this intentional? It is breaking scripts, including the GUI. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From glynn at gclements.plus.com Tue Apr 17 17:35:02 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Apr 17 17:35:10 2007 Subject: [GRASS-dev] problem with r.colors on Mac In-Reply-To: References: <17948.48049.681105.666051@cerise.gclements.plus.com> Message-ID: <17956.59686.982239.3065@cerise.gclements.plus.com> Michael Barton wrote: > >> If read is a problem, what is an alternative? > > > > gets. > > > > Gronsole::output_to_gronsole is written on the assumption that it will > > get complete lines. Gronsole::readout tries to do this, but fails to > > allow for the fact that "read" may return arbitrary chunks of data > > (i.e. partial lines). > > > > If the stream is in non-blocking mode, gets will return an empty > > string if a complete line isn't available. The fblocked function can > > be used to distinguish this from the case where the process wrote a > > blank line. Also, after this case occurs, another readable event won't > > be generated for the stream until a complete line is available. > > > >> I don't understand the > >> gronsole code very well (didn't write it), but I might be able to fix a > >> specific issue like this. > > > > Gronsole::readout is the relevant function. > > Glynn, > > Now that I have cvs access again and could update, I tried to fix this. I > changed Gronsole::readout as indicated below. Gronsole seems to work OK with > the change, but the TckTk GUI still crashes when I run r.colors ?e. It also > seems to crash more often with other commands too. I?m guessing its the same > cause. The change below does not seem to fix it, but I want to know if this > is what you had in mind. > > ##### ORIGINAL CODE ##### > proc Gronsole::readout {path ci mark fh} { > set str [read $fh] > if {[string length $str] != 0} { > Gronsole::add_data_tag $path $ci out > } > set lines [split $str "\n"] > foreach line [lrange $lines 0 [expr [llength $lines] - 2]] { > Gronsole::output_to_gronsole $path $mark $ci [list cmd$ci > cmd$ci-out] "$line\n" > } > set last [lindex $lines end] > if {$last != {}} { > Gronsole::output_to_gronsole $path $mark $ci [list cmd$ci > cmd$ci-out] $last > } > $path.text see $mark > } > > ##### REVISED CODE ##### > proc Gronsole::readout {path ci mark fh} { > > # I left this first part in because it seems to simply make an output locale > if there is something in $fh > > set str [read $fh] This is "stealing" the data from the subsequent gets calls. In the original version, the data returned by "read" was being split into lines and fed to the gronsole. In the new version, it's simply being discarded. > if {[string length $str] != 0} { > Gronsole::add_data_tag $path $ci out > } > > # here I changed all the above code to use gets and read line by line rather > than create line by line output with split > > while {[gets $fh line] >= 0} { This test will never be true; the preceding "read" will have consumed all available data, leaving none for the "gets". -- Glynn Clements From glynn at gclements.plus.com Tue Apr 17 18:00:06 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Apr 17 18:00:14 2007 Subject: [GRASS-dev] Unused files In-Reply-To: <4624D640.2030304@club.worldonline.be> References: <17955.44112.860626.760287@cerise.gclements.plus.com> <1a486f560704161212t747f68fdoa0b1ae7559ca42a@mail.gmail.com> <17955.55594.85261.133619@cerise.gclements.plus.com> <4624D640.2030304@club.worldonline.be> Message-ID: <17956.61190.971717.481406@cerise.gclements.plus.com> Moritz Lennert wrote: > >>> lib/db/dbmi_client/c_add_col.c | db_add_column > >>> lib/db/dbmi_client/c_bindupdate.c | db_bind_update > >>> lib/db/dbmi_client/c_createdb.c | db_create_database > >>> lib/db/dbmi_client/c_delete.c | db_delete > >>> lib/db/dbmi_client/c_deletedb.c | db_delete_database > >>> lib/db/dbmi_client/c_drop_col.c | db_drop_column > >>> lib/db/dbmi_client/c_drop_index.c | db_drop_index > >>> lib/db/dbmi_client/c_drop_tab.c | db_drop_table > >>> lib/db/dbmi_client/c_finddb.c | db_find_database > >>> lib/db/dbmi_client/c_insert.c | db_insert > >>> lib/db/dbmi_client/c_list_idx.c | db_list_indexes > >>> lib/db/dbmi_client/c_listdb.c | db_list_databases > >>> lib/db/dbmi_client/c_openinsert.c | db_open_insert_cursor > >>> lib/db/dbmi_client/c_openupdate.c | db_open_update_cursor > >>> lib/db/dbmi_client/c_update.c | db_update > >>> lib/db/dbmi_client/c_version.c | db_gversion > >>> lib/db/dbmi_client/printtab.c | db_print_column_definition > >>> lib/db/dbmi_client/printtab.c | db_print_table_definition > >>> lib/db/dbmi_driver/d_mkdir.c | db_driver_mkdir > >> Aren't these template functions and files to develop new drivers? > > > > No; they are the actual client-side DBMI interface. > > > > I was surprised to find so many of them unused. > > On 16/04/07 23:19, Markus Neteler wrote: > > [ ... dbmi ...] > > I feel that DBMI was left in the middle of its development, > > in particular Radim was digging through and making it > > functional (the needed parts). I have no idea which parts > > can be savely abandoned. > > If they have useful code in them and could be potentially > used, why not keep them and hope than someone picks things up ? Unless > we decide either > > - that implementing these functionalities as scripts as we are doing now > is better or at least just as good (e.g. the v.db.* scripts), or > > - that database management should be done via relevant db client > programs (independent of GRASS) or db.execute. FWIW, I wasn't looking to remove the DBMI functions; I just posted the unabridged list of unused library functions. BTW, I suspect that some of the unused dbmi_client functions are due to this in db/base/Makefile: #not used: db.createdb db.dropdb db.databases db.droptable PROGRAMS = db.columns db.copy db.describe db.drivers db.execute db.select db.tables db.connect Also, some of the dbmi_base functions might only be used by the MySQL or SQLite drivers, which I haven't compiled. However, I did remove the unused display and imagery functions. The display functions would never have been used, and the imagery code is in dire need of cleaning up. Removing unused code from lib/imagery required 3 or 4 iterations; every time I removed the unused functions, a new batch of functions would become unused. As to what's left, roughly half of the imagery library is the I_cluster_* functions, which are only used by i.cluster. I'm wondering whether they should be moved to their own library, or even into i.cluster. -- Glynn Clements From glynn at gclements.plus.com Tue Apr 17 18:43:01 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Apr 17 18:43:10 2007 Subject: [GRASS-dev] overwrite and quite flags In-Reply-To: References: Message-ID: <17956.63765.849549.424280@cerise.gclements.plus.com> Michael Barton wrote: > Maybe I missed something, but it seems that very recently, there has been a > fundamental change to the behavior of the overwrite and quite flags. You > used to be able to write EITHER --o OR ‹overwrite and --q OR ‹quiet. Now --o > and --q are not accepted and you must write --quiet or --overwrite. I cannot reproduce this; both --o and --q work fine for me. -- Glynn Clements From michael.barton at asu.edu Tue Apr 17 18:50:56 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Apr 17 18:51:03 2007 Subject: [GRASS-dev] problem with r.colors on Mac In-Reply-To: <17956.59686.982239.3065@cerise.gclements.plus.com> Message-ID: On 4/17/07 8:35 AM, "Glynn Clements" wrote: >> if {[string length $str] != 0} { >> Gronsole::add_data_tag $path $ci out >> } So do I just get rid of this if clause? >> >> # here I changed all the above code to use gets and read line by line rather >> than create line by line output with split >> >> while {[gets $fh line] >= 0} { > > This test will never be true; the preceding "read" will have consumed > all available data, leaving none for the "gets". __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From dca.gis at gmail.com Tue Apr 17 19:38:01 2007 From: dca.gis at gmail.com (Daniel Calvelo) Date: Tue Apr 17 19:38:08 2007 Subject: [GRASS-dev] Google Summer Of Code Project In-Reply-To: References: Message-ID: <1a486f560704171038i5946486cw80939a1804e939d8@mail.gmail.com> Hi Maximilian, welcome aboard! On 4/17/07, maximilian maldacker wrote: [...] > Should the visibility graph construction algorithm > be added to the Directed Graph Library? Eventually, but it should be coded as an independent library anyway, agnostic of both GRASS internal data representation details and any output code. Then you would go layer by layer to GRASS interfaces of it, and then user interface (e.g. the module's parameters and options) and then, eventually, some display features if need be. > What is the best way to test my code? Should I keep a fresh copy of GRASS on > my computer, modify/create files, compile everything and test it using the > spearfish example? Or is there another way? That is roughly what everybody does who is not touching/refactoring internals. Please also consider using Soeren Gebbert's test suite (http://www-pool.math.tu-berlin.de/~soeren/grass/GRASS_TestSuite/ ; other links? wiki?), possibly from the start to help you fix representations, border cases, scalability and so on. > Thank you for your help and I'm looking forward to help develop GRASS. We look forward to seeing you around for longer than the summer. Daniel. -- -- Daniel Calvelo Aros From hmitaso at unity.ncsu.edu Tue Apr 17 19:43:11 2007 From: hmitaso at unity.ncsu.edu (Helena Mitasova) Date: Tue Apr 17 19:43:27 2007 Subject: [GRASS-dev] Google Summer Of Code Project In-Reply-To: References: Message-ID: <1388DEBF-A109-463B-9A64-12E1B593A08D@unity.ncsu.edu> We will try to get out a new, more modern data set that is planned as a replacement for spearfish, it has been already tested with almost every raster module and most vector modules, we just need to cleanup the names and add metadata. The data set has at least building footprints so you can generate simple buildings using v.extrude, but I am working on getting some real buildings data too. Let me discuss with Markus the best way to provide the data set for early testers/developers. Helena Helena Mitasova Dept. of Marine, Earth and Atm. Sciences 1125 Jordan Hall, NCSU Box 8208, Raleigh NC 27695 http://skagit.meas.ncsu.edu/~helena/ On Apr 17, 2007, at 4:18 AM, maximilian maldacker wrote: > Hello everyone, my name is Maximilian Maldacker and I'm currently a > student in Imperial College London studying Mathematics and > Computer Science. My project on "Shortest path in free (vector) > space avoiding obstacles module in GRASS" was select by Google > Summer of Code and I'm looking forward to it :-). I actually start > on the 28th of May but I thought I'd introduce my self before and > get involved with the community. > > I have a few question concerning the development of the module. I > see modules are organized in several folders and I thought I can > create a new folder in the display folder named d.path_obstacles or > something similar. Is it sufficient to create a new folder with a > Makefile inside and a few *.c files to make a new module and will > it be recognized by the command line? > The plan for now is to develop a module similar to the d.path one > except it will start with a vector space containing obstacles > ( i.e. polygons ) and it will construct a visibility graph out of > it and compute the shortest path between two given points. Should > the visibility graph construction algorithm be added to the > Directed Graph Library? > What is the best way to test my code? Should I keep a fresh copy of > GRASS on my computer, modify/create files, compile everything and > test it using the spearfish example? Or is there another way? > > Thank you for your help and I'm looking forward to help develop GRASS. > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From woklist at kyngchaos.com Tue Apr 17 20:48:33 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Tue Apr 17 20:48:41 2007 Subject: [GRASS-dev] Re: Error compiling dependencies on OSX In-Reply-To: <1C1A06BB-8C2D-4907-9510-E0A8DCBB9179@uv.es> References: <067285F7-8D2C-4DF3-8D92-C13EE4BB8171@kyngchaos.com> <17945.33292.321787.446725@cerise.gclements.plus.com> <17945.65471.418796.321712@cerise.gclements.plus.com> <1C1A06BB-8C2D-4907-9510-E0A8DCBB9179@uv.es> Message-ID: <3BE50D56-D959-470C-AEF4-53C5194829AA@kyngchaos.com> Ah, I've been meaning to look into this more. netpbm has its own copy of the Jasper source which is built by default, and it's clashing with the UnixImageIO Jasper. I need to figure out how to disable the Jasper build in netpbm. On Apr 17, 2007, at 1:36 PM, Agustin Diez Castillo wrote: > NetPBM gives the following error: > > jas_image.c:166: error: conflicting types for 'jas_image_create' > /Library/Frameworks/UnixImageIO.framework/unix/include/jasper/ > jas_image.h:302: error: previous declaration of 'jas_image_create' > was here > jas_image.c: In function 'jas_image_create': > jas_image.c:177: error: 'struct ' has no member named > 'colorspace_' > jas_image.c:166: error: conflicting types for 'jas_image_create' > /Library/Frameworks/UnixImageIO.framework/unix/include/jasper/ > jas_image.h:302: error: previous declaration of 'jas_image_create' > was here > jas_image.c: In function 'jas_image_create': > jas_image.c:177: error: 'struct ' has no member named > 'colorspace_' > jas_image.c: In function 'jas_image_create0': > jas_image.c:235: error: 'struct ' has no member named > 'colorspace_' > jas_image.c:235: error: 'JAS_IMAGE_CS_UNKNOWN' undeclared (first > use in this function) > jas_image.c:235: error: (Each undeclared identifier is reported > only once > jas_image.c:235: error: for each function it appears in.) > jas_image.c:240: error: 'struct ' has no member named > 'iccp_' > jas_image.c:241: error: 'struct ' has no member named > 'iccplen_' > jas_image.c: In function 'jas_image_create0': > jas_image.c:235: error: 'struct ' has no member named > 'colorspace_' > jas_image.c:235: error: 'JAS_IMAGE_CS_UNKNOWN' undeclared (first > use in this function) > jas_image.c:235: error: (Each undeclared identifier is reported > only once > jas_image.c:235: error: for each function it appears in.) > jas_image.c:240: error: 'struct ' has no member named > 'iccp_' > jas_image.c:241: error: 'struct ' has no member named > 'iccplen_' > jas_image.c: At top level: > jas_image.c:414: error: conflicting types for 'jas_image_readcmpt' > /Library/Frameworks/UnixImageIO.framework/unix/include/jasper/ > jas_image.h:418: error: previous declaration of > 'jas_image_readcmpt' was here > jas_image.c: At top level: > jas_image.c:414: error: conflicting types for 'jas_image_readcmpt' > /Library/Frameworks/UnixImageIO.framework/unix/include/jasper/ > jas_image.h:418: error: previous declaration of > 'jas_image_readcmpt' was here > jas_image.c:498: error: conflicting types for 'jas_image_writecmpt' > /Library/Frameworks/UnixImageIO.framework/unix/include/jasper/ > jas_image.h:423: error: previous declaration of > 'jas_image_writecmpt' was here > jas_image.c:498: error: conflicting types for 'jas_image_writecmpt' > /Library/Frameworks/UnixImageIO.framework/unix/include/jasper/ > jas_image.h:423: error: previous declaration of > 'jas_image_writecmpt' was here > jas_image.c:577: error: conflicting types for 'jas_image_addfmt' > /Library/Frameworks/UnixImageIO.framework/unix/include/jasper/ > jas_image.h:462: error: previous declaration of 'jas_image_addfmt' > was here > jas_image.c:577: error: conflicting types for 'jas_image_addfmt' > /Library/Frameworks/UnixImageIO.framework/unix/include/jasper/ > jas_image.h:462: error: previous declaration of 'jas_image_addfmt' > was here > jas_image.c:682: error: conflicting types for 'jas_image_delcmpt' > /Library/Frameworks/UnixImageIO.framework/unix/include/jasper/ > jas_image.h:426: error: previous declaration of 'jas_image_delcmpt' > was here > jas_image.c:698: error: conflicting types for 'jas_image_addcmpt' > /Library/Frameworks/UnixImageIO.framework/unix/include/jasper/ > jas_image.h:430: error: previous declaration of 'jas_image_addcmpt' > was here > jas_image.c:682: error: conflicting types for 'jas_image_delcmpt' > /Library/Frameworks/UnixImageIO.framework/unix/include/jasper/ > jas_image.h:426: error: previous declaration of 'jas_image_delcmpt' > was here > jas_image.c:698: error: conflicting types for 'jas_image_addcmpt' > /Library/Frameworks/UnixImageIO.framework/unix/include/jasper/ > jas_image.h:430: error: previous declaration of 'jas_image_addcmpt' > was here > lipo: can't figure out the architecture type of: /var/tmp// > ccvlNENX.out > make[5]: *** [jas_image.o] Error 1 > make[4]: *** [base/all] Error 2 > make[3]: *** [libjasper/libjasper.a] Error 2 > make[2]: *** [jpeg2000/all] Error 2 > make[1]: *** [other/all] Error 2 > make: *** [converter/all] Error 2 > > __________________________________________________________ > Dr. Agust?n Diez Castillo > Departament de Prehist?ria i Arqueologia > Fundaci? General Universitat de Val?ncia Phone: +34 963 98 38 93 > Avda. Blasco Iba?ez, 28 Fax: +34 963 98 38 87 > Val?ncia 46010 > http://www.uv.es/sidgeipa > Member of the European Network of Excellence EPOCH > http://www.epoch.eu/ > __________________________________________________________ > > > > > On Apr 15, 2007, at 8:57 PM, William Kyngesburye wrote: > >> I worked out how to dump the env into a script to be sourced in >> the Terminal window, as suggested by Glynn. This removes the >> lengthy output before the command is actually run (though the >> source command is still there). And it makes the AppleScript a >> little simpler. >> >> As before, replace the installed grass /etc/grass-xterm-wrapper >> with this one (or replace the source /lib/init/grass-xterm-wrapper >> and rebuild). Also, update CVS for the latest OSX app startup >> (and rebuild) - I removed the hardwired xterm path. >> >> >> >> If this works well, I'll commit it to CVS. >> >> ----- >> William Kyngesburye >> http://www.kyngchaos.com/ >> >> "History is an illusion caused by the passage of time, and time is >> an illusion caused by the passage of history." >> >> - Hitchhiker's Guide to the Galaxy >> >> >> _______________________________________________ >> grass-dev mailing list >> grass-dev@grass.itc.it >> http://grass.itc.it/mailman/listinfo/grass-dev > ----- William Kyngesburye http://www.kyngchaos.com/ All generalizations are dangerous, even this one. From epatton at nrcan.gc.ca Tue Apr 17 21:06:01 2007 From: epatton at nrcan.gc.ca (Patton, Eric) Date: Tue Apr 17 21:06:59 2007 Subject: [GRASS-dev] overwrite and quite flags References: <17956.63765.849549.424280@cerise.gclements.plus.com> Message-ID: Same here; no problems with --o and --q using today's cvs update with make distclean. ~ Eric. -----Original Message----- From: grass-dev-bounces@grass.itc.it on behalf of Glynn Clements Sent: Tue 4/17/2007 1:43 PM To: Michael Barton Cc: grass-dev Subject: Re: [GRASS-dev] overwrite and quite flags Michael Barton wrote: > Maybe I missed something, but it seems that very recently, there has been a > fundamental change to the behavior of the overwrite and quite flags. You > used to be able to write EITHER --o OR and --q are not accepted and you must write --quiet or --overwrite. I cannot reproduce this; both --o and --q work fine for me. -- Glynn Clements _______________________________________________ grass-dev mailing list grass-dev@grass.itc.it http://grass.itc.it/mailman/listinfo/grass-dev From grass-codep at wald.intevation.org Tue Apr 17 21:08:27 2007 From: grass-codep at wald.intevation.org (grass-codep@wald.intevation.org) Date: Tue Apr 17 21:08:31 2007 Subject: [GRASS-dev] [grass-code P][371] a fix for NVIZ site's dependency - almost complete Message-ID: <20070417190827.EEBAC1953AAB@pyrosoma.intevation.org> code P item #371, was opened at 2007-04-17 21:08 Status: Open Priority: 3 Submitted By: Maciej Sieczka (msieczka) Assigned to: Nobody (None) Summary: a fix for NVIZ site's dependency - almost complete Patch status: None Patch type: fix GRASS component: NVIZ GRASS version: CVS HEAD GRASS CVS checkout date, if applies (YYMMDD): 070417 Initial Comment: In a followup of http://www.nabble.com/Re%3A-GRASS-6.2.1RC1-published-p7837804.html Bob has sent me a new version of Gp3.c file, which gets rid of the sites dependency in NVIZ. Hovever, Bob had one doubt: > One of the parts I am not sure about is on line 138 and 139. I am not > sure what this is intended to represent in the geopoint. Any insights > would be appreciated. In spite of this, it works: fetched the 6.3 cvs, overwrited the Gp3.c, built on Ubuntu Dapper using GCC 4.0.3 tcl/tk 8.4.12 on a 32bit Pentium M and all is OK! No line artifacts, strange icons colors or random icon types. Adding/removing 2d/3d points at runtime and at NVIZ startup via 'points' option, displaying 3d points flat - all works OK. Remaining issue is that the 'X' icon is still always rendered kindoff hovering over the surface in 2d mode, not on the surface (though other icons are fine in 2d mode). It is rendered on the correct elevation for 3d points though. Since there's been no response from Bob on this subject for few weeks know, I decided it would be better to post this patch to the tracker so we don't loose an almost working fix. Hopefully somebody would like to look into lines 138, 139 and the 'X' icon issue. Maciek ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=205&aid=371&group_id=21 From glynn at gclements.plus.com Tue Apr 17 21:09:19 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Apr 17 21:09:47 2007 Subject: [GRASS-dev] problem with r.colors on Mac In-Reply-To: References: <17956.59686.982239.3065@cerise.gclements.plus.com> Message-ID: <17957.7007.426486.880487@cerise.gclements.plus.com> Michael Barton wrote: > >> # here I changed all the above code to use gets and read line by line rather > >> than create line by line output with split > >> > >> while {[gets $fh line] >= 0} { > > > > This test will never be true; the preceding "read" will have consumed > > all available data, leaving none for the "gets". > > On 4/17/07 8:35 AM, "Glynn Clements" wrote: > > >> if {[string length $str] != 0} { > >> Gronsole::add_data_tag $path $ci out > >> } > > So do I just get rid of this if clause? No, get rid of the "read" call. E.g. (untested): proc Gronsole::readout {path ci mark fh} { set lines {} while {[gets $fh line] >= 0} { lappend lines $line } if {[length $lines] != 0} { Gronsole::add_data_tag $path $ci out } foreach line [lrange $lines 0 [expr [llength $lines] - 2]] { Gronsole::output_to_gronsole $path $mark $ci [list cmd$ci cmd$ci-out] "$line\n" } set last [lindex $lines end] if {$last != {}} { Gronsole::output_to_gronsole $path $mark $ci [list cmd$ci cmd$ci-out] $last } $path.text see $mark } Although, I'm not entirely sure why it's necessary to omit the newline from the last entry; maybe that was due to the use of "read". Try: proc Gronsole::readout {path ci mark fh} { set lines {} while {[gets $fh line] >= 0} { lappend lines $line } if {[length $lines] != 0} { Gronsole::add_data_tag $path $ci out } foreach line $lines { Gronsole::output_to_gronsole $path $mark $ci [list cmd$ci cmd$ci-out] "$line\n" } $path.text see $mark } -- Glynn Clements From woklist at kyngchaos.com Wed Apr 18 02:55:32 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Wed Apr 18 02:55:45 2007 Subject: [GRASS-dev] off_t problem Message-ID: <5077F501-62C1-41C3-ADB5-20D0D58A3864@kyngchaos.com> One small problem with the recent off_t changes: r.support/modhead/ ask_format.c and factors.h need to include either sys/types.h or unistd.h, like is done in row_addr.c. ----- William Kyngesburye http://www.kyngchaos.com/ All generalizations are dangerous, even this one. From glynn at gclements.plus.com Wed Apr 18 03:00:54 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Apr 18 03:00:58 2007 Subject: [GRASS-dev] off_t problem In-Reply-To: <5077F501-62C1-41C3-ADB5-20D0D58A3864@kyngchaos.com> References: <5077F501-62C1-41C3-ADB5-20D0D58A3864@kyngchaos.com> Message-ID: <17957.28102.882985.171162@cerise.gclements.plus.com> William Kyngesburye wrote: > One small problem with the recent off_t changes: r.support/modhead/ > ask_format.c and factors.h need to include either sys/types.h or > unistd.h, like is done in row_addr.c. I had figured that adding it to local_proto.h would suffice; except that most of the files didn't include local_proto.h. Fixed in CVS. -- Glynn Clements From michael.barton at asu.edu Wed Apr 18 05:11:48 2007 From: michael.barton at asu.edu (Michael Barton) Date: Wed Apr 18 05:12:35 2007 Subject: [GRASS-dev] problem with r.colors on Mac In-Reply-To: <17957.7007.426486.880487@cerise.gclements.plus.com> Message-ID: Glynn, I tried the code below. I still get crashing with both versions if I run r.colors -e. If I run r.colors without -e, it runs fine. I tracked $lines after the following clause... while {[gets $fh line] >= 0} { lappend lines $line } ... and got the results below. RESULTS GRASS 6.3.cvs (spearfish60_test):~ > lines={} {GRASS_INFO_MESSAGE(5017,1): Reading elevation_delete ...} GRASS_INFO_END(5017,1) {} {GRASS_INFO_PERCENT: 0} {GRASS_INFO_PERCENT: 3} lines={GRASS_INFO_PERCENT: 6} {GRASS_INFO_PERCENT: 9} lines={GRASS_INFO_PERCENT: 12} {GRASS_INFO_PERCENT: 15} {GRASS_INFO_PERCENT: 18} {GRASS_INFO_PERCENT: 21} {GRASS_INFO_PERCENT: 24} {GRASS_INFO_PERCENT: 27} {GRASS_INFO_PERCENT: 30} {GRASS_INFO_PERCENT: 33} {GRASS_INFO_PERCENT: 36} {GRASS_INFO_PERCENT: 39} {GRASS_INFO_PERCENT: 42} {GRASS_INFO_PERCENT: 45} {GRASS_INFO_PERCENT: 48} {GRASS_INFO_PERCENT: 51} {GRASS_INFO_PERCENT: 54} {GRASS_INFO_PERCENT: 57} {GRASS_INFO_PERCENT: 60} {GRASS_INFO_PERCENT: 63} lines={GRASS_INFO_PERCENT: 66} lines={GRASS_INFO_PERCENT: 69} lines={GRASS_INFO_PERCENT: 72} lines={GRASS_INFO_PERCENT: 75} lines={GRASS_INFO_PERCENT: 78} lines={GRASS_INFO_PERCENT: 81} lines={GRASS_INFO_PERCENT: 84} {GRASS_INFO_PERCENT: 87} lines={GRASS_INFO_PERCENT: 90} lines={GRASS_INFO_PERCENT: 93} lines={GRASS_INFO_PERCENT: 96} lines={GRASS_INFO_PERCENT: 99} lines={GRASS_INFO_PERCENT: 100} lines={} {GRASS_INFO_MESSAGE(5017,2): Color table for [elevation_delete] set to elevation} GRASS_INFO_END(5017,2) Nothing seems wrong here. If I run r.colors without -e, I simply get the last line returned. Maybe the problem is in the progress bar routine itself. Michael On 4/17/07 12:09 PM, "Glynn Clements" wrote: > > No, get rid of the "read" call. E.g. (untested): > > proc Gronsole::readout {path ci mark fh} { > > set lines {} > > while {[gets $fh line] >= 0} { > lappend lines $line > } > > if {[length $lines] != 0} { > Gronsole::add_data_tag $path $ci out > } > > foreach line [lrange $lines 0 [expr [llength $lines] - 2]] { > Gronsole::output_to_gronsole $path $mark $ci [list cmd$ci cmd$ci-out] > "$line\n" > } > set last [lindex $lines end] > if {$last != {}} { > Gronsole::output_to_gronsole $path $mark $ci [list cmd$ci cmd$ci-out] $last > } > $path.text see $mark > } > > Although, I'm not entirely sure why it's necessary to omit the newline > from the last entry; maybe that was due to the use of "read". Try: > > proc Gronsole::readout {path ci mark fh} { > > set lines {} > > while {[gets $fh line] >= 0} { > lappend lines $line > } > > if {[length $lines] != 0} { > Gronsole::add_data_tag $path $ci out > } > > foreach line $lines { > Gronsole::output_to_gronsole $path $mark $ci [list cmd$ci cmd$ci-out] > "$line\n" > } > > $path.text see $mark > } __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Wed Apr 18 05:18:48 2007 From: michael.barton at asu.edu (Michael Barton) Date: Wed Apr 18 05:19:02 2007 Subject: [GRASS-dev] problem with r.colors on Mac In-Reply-To: <17957.7007.426486.880487@cerise.gclements.plus.com> Message-ID: It's the progress bar. If I comment out the following lines in Gronsole::output_to_gronsole, it stops crashing. It's something about one of the two lines that execute after progress reaches 100%. # } elseif { [regexp -- {^GRASS_INFO_PERCENT: (.+)$} $str match val rest] } { # Gronsole::progress $path $ci $val # if { $val >= 100 } { # Gronsole::progress $path $ci -1 # $outtext insert $mark "\n" $tags # } Michael On 4/17/07 12:09 PM, "Glynn Clements" wrote: > > Michael Barton wrote: > >>>> # here I changed all the above code to use gets and read line by line >>>> rather >>>> than create line by line output with split >>>> >>>> while {[gets $fh line] >= 0} { >>> >>> This test will never be true; the preceding "read" will have consumed >>> all available data, leaving none for the "gets". >> >> On 4/17/07 8:35 AM, "Glynn Clements" wrote: >> >>>> if {[string length $str] != 0} { >>>> Gronsole::add_data_tag $path $ci out >>>> } >> >> So do I just get rid of this if clause? > > No, get rid of the "read" call. E.g. (untested): > > proc Gronsole::readout {path ci mark fh} { > > set lines {} > > while {[gets $fh line] >= 0} { > lappend lines $line > } > > if {[length $lines] != 0} { > Gronsole::add_data_tag $path $ci out > } > > foreach line [lrange $lines 0 [expr [llength $lines] - 2]] { > Gronsole::output_to_gronsole $path $mark $ci [list cmd$ci cmd$ci-out] > "$line\n" > } > set last [lindex $lines end] > if {$last != {}} { > Gronsole::output_to_gronsole $path $mark $ci [list cmd$ci cmd$ci-out] $last > } > $path.text see $mark > } > > Although, I'm not entirely sure why it's necessary to omit the newline > from the last entry; maybe that was due to the use of "read". Try: > > proc Gronsole::readout {path ci mark fh} { > > set lines {} > > while {[gets $fh line] >= 0} { > lappend lines $line > } > > if {[length $lines] != 0} { > Gronsole::add_data_tag $path $ci out > } > > foreach line $lines { > Gronsole::output_to_gronsole $path $mark $ci [list cmd$ci cmd$ci-out] > "$line\n" > } > > $path.text see $mark > } __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From glynn at gclements.plus.com Wed Apr 18 06:15:58 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Apr 18 06:16:15 2007 Subject: [GRASS-dev] problem with r.colors on Mac In-Reply-To: References: <17957.7007.426486.880487@cerise.gclements.plus.com> Message-ID: <17957.39806.436477.452976@cerise.gclements.plus.com> Michael Barton wrote: > I tried the code below. I still get crashing with both versions if I run > r.colors -e. If I run r.colors without -e, it runs fine. I tracked $lines > after the following clause... > > while {[gets $fh line] >= 0} { > lappend lines $line > } > > ... and got the results below. > > RESULTS > > GRASS 6.3.cvs (spearfish60_test):~ > lines={} {GRASS_INFO_MESSAGE(5017,1): > Reading elevation_delete ...} GRASS_INFO_END(5017,1) {} {GRASS_INFO_PERCENT: > 0} {GRASS_INFO_PERCENT: 3} > lines={GRASS_INFO_PERCENT: 6} {GRASS_INFO_PERCENT: 9} > lines={GRASS_INFO_PERCENT: 12} {GRASS_INFO_PERCENT: 15} {GRASS_INFO_PERCENT: > 18} {GRASS_INFO_PERCENT: 21} {GRASS_INFO_PERCENT: 24} {GRASS_INFO_PERCENT: > 27} {GRASS_INFO_PERCENT: 30} {GRASS_INFO_PERCENT: 33} {GRASS_INFO_PERCENT: > 36} {GRASS_INFO_PERCENT: 39} {GRASS_INFO_PERCENT: 42} {GRASS_INFO_PERCENT: > 45} {GRASS_INFO_PERCENT: 48} {GRASS_INFO_PERCENT: 51} {GRASS_INFO_PERCENT: > 54} {GRASS_INFO_PERCENT: 57} {GRASS_INFO_PERCENT: 60} {GRASS_INFO_PERCENT: > 63} > lines={GRASS_INFO_PERCENT: 66} > lines={GRASS_INFO_PERCENT: 69} > lines={GRASS_INFO_PERCENT: 72} > lines={GRASS_INFO_PERCENT: 75} > lines={GRASS_INFO_PERCENT: 78} > lines={GRASS_INFO_PERCENT: 81} > lines={GRASS_INFO_PERCENT: 84} {GRASS_INFO_PERCENT: 87} > lines={GRASS_INFO_PERCENT: 90} > lines={GRASS_INFO_PERCENT: 93} > lines={GRASS_INFO_PERCENT: 96} > lines={GRASS_INFO_PERCENT: 99} > lines={GRASS_INFO_PERCENT: 100} > lines={} {GRASS_INFO_MESSAGE(5017,2): Color table for [elevation_delete] set > to elevation} GRASS_INFO_END(5017,2) > > Nothing seems wrong here. If I run r.colors without -e, I simply get the > last line returned. Maybe the problem is in the progress bar routine itself. Does it make any difference if you change the ">= 0" to "> 0"? Other than that, the assumption that the problem is with the progress bar code seems reasonable. -- Glynn Clements From glynn at gclements.plus.com Wed Apr 18 06:39:20 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Apr 18 06:39:41 2007 Subject: [GRASS-dev] problem with r.colors on Mac In-Reply-To: References: <17957.7007.426486.880487@cerise.gclements.plus.com> Message-ID: <17957.41208.6823.355152@cerise.gclements.plus.com> Michael Barton wrote: > It's the progress bar. > > If I comment out the following lines in Gronsole::output_to_gronsole, it > stops crashing. It's something about one of the two lines that execute after > progress reaches 100%. > > > # } elseif { [regexp -- {^GRASS_INFO_PERCENT: (.+)$} $str match val > rest] } { > # Gronsole::progress $path $ci $val > # if { $val >= 100 } { > # Gronsole::progress $path $ci -1 > # $outtext insert $mark "\n" $tags > # } My first would guess would be the progress bar widget itself. It may be best to simply trace the code, e.g.: proc tracer {cmd op} { puts stderr $cmd } trace add execution Gronsole::progress enter tracer Redirect stderr to a file; it will generate a lot of output. FWIW, I found that the first time that I ran "r.colors --ui ...", the UI crashed, but I couldn't reproduce it after that, which suggests that it's timing related, i.e. it happens if the module produces output too fast. I note that wish takes quite a while to start the first time, but is much quicker thereafter (when the files are in RAM). Does it help if you remove the "update" call from the end of ProgressBar::_modify? -- Glynn Clements From hamish_nospam at yahoo.com Wed Apr 18 07:08:35 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Apr 18 07:08:52 2007 Subject: [GRASS-dev] problem with r.colors on Mac In-Reply-To: <17957.39806.436477.452976@cerise.gclements.plus.com> References: <17957.7007.426486.880487@cerise.gclements.plus.com> <17957.39806.436477.452976@cerise.gclements.plus.com> Message-ID: <20070418170835.3cbce61f.hamish_nospam@yahoo.com> > Michael Barton wrote: > > I tried the code below. I still get crashing with both versions if I > > run r.colors -e. If I run r.colors without -e, it runs fine. I > > tracked $lines after the following clause... .. > > Nothing seems wrong here. If I run r.colors without -e, I simply get > > the last line returned. Maybe the problem is in the progress bar > > routine itself. Glynn: .. > Other than that, the assumption that the problem is with the progress > bar code seems reasonable. I take it that everything works smoothly from the command line? (it's not exit(1)ing with a left over "only works will integer maps" error?) ... BTW these close-without-catch still need to be fixed: http://grass.itc.it/pipermail/grass-dev/2007-April/030157.html something to try: in eq.c and log.c (or wherever that code now lives since Glynn's updates) change the "2"s in G_percent(row, nrows, 2); to 3 or larger. That gives how often to update (here every 2%). For a fast processes it just slows you down to draw a new %-done every 1%. It's not a real fix, but it might help diagnose the problem. Hamish From neteler at itc.it Wed Apr 18 09:24:00 2007 From: neteler at itc.it (Markus Neteler) Date: Wed Apr 18 09:31:28 2007 Subject: [GRASS-dev] Unused files In-Reply-To: <17955.63182.103807.825355@cerise.gclements.plus.com> References: <17955.44112.860626.760287@cerise.gclements.plus.com> <20070416211952.GB9087@bartok.itc.it> <17955.63182.103807.825355@cerise.gclements.plus.com> Message-ID: <4625C790.6000809@itc.it> Glynn Clements wrote on 04/17/2007 12:21 AM: > Markus Neteler wrote: > > >> These imagery functions, if really unused, are probably >> delete candidates. >> > > Apart from that, it would be nice to start 7.x with "rm -rf imagery/", > and telling people to clean stuff up before they put it back in. > > If I'm making the same change to every file which uses a particular > function, I know I've reached the imagery directory when I start > seeing almost exactly the same file over and over again. E.g.: > > imagery/i.ortho.photo/photo.2image/analyze.c > imagery/i.ortho.photo/photo.2target/analyze.c > imagery/i.points/analyze.c > imagery/i.vpoints/analyze.c > or: > imagery/i.ortho.photo/photo.2image/ask_mag.c > imagery/i.ortho.photo/photo.2target/ask_mag.c > imagery/i.points/ask_mag.c > imagery/i.vpoints/ask_mag.c > or: > imagery/i.ortho.photo/photo.2image/call.c > imagery/i.ortho.photo/photo.2target/call.c > imagery/i.points/call.c > imagery/i.vpoints/call.c > or: > [well, you get the idea.] > Yes, the problem is well known - see the GRASS Quality Assessment site, in particular the clone detection part therein: http://web.soccerlab.polymtl.ca/grass-evolution/grass-browsers/clone-browser.html Maybe Brad has comments on his plans to polish the imagery part. >>> lib/vector/Vlib/dbcolumns.c | Vect_get_column_names >>> lib/vector/Vlib/dbcolumns.c | Vect_get_column_names_types >>> lib/vector/Vlib/dbcolumns.c | Vect_get_column_types >>> lib/vector/Vlib/graph.c | Vect_graph_add_edge >>> lib/vector/Vlib/graph.c | Vect_graph_build >>> lib/vector/Vlib/graph.c | Vect_graph_init >>> lib/vector/Vlib/graph.c | Vect_graph_set_node_costs >>> lib/vector/Vlib/graph.c | Vect_graph_shortest_path >>> lib/vector/Vlib/overlap.c | V__map_overlap >>> lib/vector/Vlib/overlay.c | Vect_overlay >>> lib/vector/Vlib/overlay.c | Vect_overlay_and >>> lib/vector/Vlib/overlay.c | Vect_overlay_str_to_operator >>> >> I am suprised to see these Vect functions unused. Really sure? >> > > I'm quite sure. > > >>> lib/vector/dglib/avl.c | avl_allocator_default >>> >> avl: libavl - library for manipulation of binary trees >> I think we have also lib/btree/ is that's the same purpose? >> > > Yes; both provide essentially the same functionality. > > AVL trees are balanced, so they have better worst-case performance. > > Unbalanced trees are O(log(n)) for random data but degenerate to O(n) > for sorted data (you essentially end up with a linked list). Balanced > trees are always O(log(n)), although with a higher constant factor for > insertions due to the cost of rebalancing. > Could this be a reason to drop lib/btree/ and to replace it by a wrapper to lib/vector/dglib/ (wild guess)? Markus ------------------ ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler ITC -> since 1 March 2007 Fondazione Bruno Kessler ------------------ From neteler.osgeo at gmail.com Wed Apr 18 10:19:08 2007 From: neteler.osgeo at gmail.com (Markus Neteler) Date: Wed Apr 18 10:19:12 2007 Subject: [GRASS-dev] Re: SoC 2007 In-Reply-To: <4620C629.8060103@bergenheim.net> References: <4620C629.8060103@bergenheim.net> Message-ID: <86782b610704180119x27463899o16619a30d3182eb1@mail.gmail.com> (cc grass-dev, hope you don't mind) On 4/14/07, Wolf Bergenheim wrote: > Hi! > > Just writing to you to let you know that I have heard back from > Maximilian Maldacker (who will write the shortest path through free > vector space module). > > He will introduce himself on the developer list soonish. Hi, I have seen that he posted to the grass-dev list - very good. > On a side note; Markus (Frank, you may answer too ;)), what do you think > would be better: to have the SoC students commit through our regular CVS > (or svn if we have switched by 28.5) or as a GRASS extension? Concerning the main repository: We definitely won't switch to SVN quickly since it seems to be a slooooow process (sigh). Probably a GRASS SVN Addon would be best for now. We can easily migrate it into the main trunk then. All changes necessary in the libs can go directly into CVS of course so that the Addon stuff is compilable all the time. > In other > words do you think this should be an extension module or a core module? > I think it will be easier for the students to commit to the core, and > that way I think they will feel more like part of the GRASS team. Thoughts? For a module, the best breeding site might be the Addons SVN (however, with your vector/v.label.sa/ we do differently). Time to work out some rules for this. So I cc'ed to the dev list for further discussion. Markus > --Wolf > > -- > > <:3 )---- Wolf Bergenheim ----( 8:> From hamish_nospam at yahoo.com Wed Apr 18 10:30:38 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Apr 18 10:30:46 2007 Subject: [GRASS-dev] ascii export and import, large file problem In-Reply-To: <20070413073931.AOC98228@expms1.cites.uiuc.edu> References: <20070413073931.AOC98228@expms1.cites.uiuc.edu> Message-ID: <20070418203038.2c18b59b.hamish_nospam@yahoo.com> Gerald Nelson wrote: > Helena, I think the issue when I tried this before is that grass > doesn't know that x and y are in degrees while z is in meters. It > either assumes they are the same or uses the zfactor option to > multiply the z value by something to get it into the same units as x > and y. > > But if I could tell grass that the z units were meters explicitly, > couldn't grass do the conversion automatically? Especially since the > conversion changes as you move north. http://article.gmane.org/gmane.comp.gis.grass.devel/19353/ http://article.gmane.org/gmane.comp.gis.grass.devel/19523/ --relevant quotes-- [1...] For a real y-axis label I think we need to add a new (optional) "units" element to the raster format (e.g. in cell_misc/). [2...] > The user should be able to add a title for the legend. For vlegends that's doable. For raster legends I hope to add G_set_raster_units() and G_get_raster_units() to write/read a simple string containing raster data units (set from "r.support units=") which will be stored in $MAPSET/cell_misc/$RASTERMAP/units. Raster legends and things like lat/lon NVIZ and r.shaded.relief could use the tag if it existed. --endquote-- apparently cell_misc/ is evil, so that moves it to $MAPSET/units/$RASTERMAP until GRASS7 when it moves to $MAPSET/raster/$RASTERMAP/units I don't like to add another element dir to $MAPSET, but... Hamish From grass-codep at wald.intevation.org Wed Apr 18 11:38:38 2007 From: grass-codep at wald.intevation.org (grass-codep@wald.intevation.org) Date: Wed Apr 18 11:38:43 2007 Subject: [GRASS-dev] [grass-code P][372] scritps for converting raster maps into GRASS 7 format, and back Message-ID: <20070418093838.B3A5F1953AAB@pyrosoma.intevation.org> code P item #372, was opened at 2007-04-18 21:38 Status: Open Priority: 1 Submitted By: Hamish Bowman (hamish) Assigned to: Nobody (None) Summary: scritps for converting raster maps into GRASS 7 format, and back Patch status: postponed Patch type: new GRASS component: raster GRASS version: None GRASS CVS checkout date, if applies (YYMMDD): Initial Comment: r.convert and r.convert.all: Converts a GRASS 4-6 raster map to a GRASS 7 raster map by moving files around in the $MAPSET. Mostly untested, probably misses some bits. I did not use g.message as I think it should be fully backwards-compatible with GRASS 5.0.0 and newer. Tries to be really really cautious. Hamish ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=205&aid=372&group_id=21 From paul-grass at stjohnspoint.co.uk Wed Apr 18 12:55:07 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Wed Apr 18 12:55:13 2007 Subject: [GRASS-dev] [grass-code P][372] scritps for converting raster maps into GRASS 7 format, and back In-Reply-To: <20070418093838.B3A5F1953AAB@pyrosoma.intevation.org> References: <20070418093838.B3A5F1953AAB@pyrosoma.intevation.org> Message-ID: Hello Hamish Could it be written in C so it is more cross-platform? There is a new function G_copy_file() in CVS that can copy files on disk. There is also the C rename() function. The script could still be available to work with older versions of GRASS. Although I still don't think I like the idea of changing the internal raster format as I expect it will break lots of 3rd-party software that reads GRASS raster files directly, and could make GRASS look bad for changing things. E.g. thinking of the detailed discussion of the raster format a year or two ago for JavaGrass which reads it directly I think. Also even GDAL must be passed the path to the cellhd directory to read a GRASS raster I think? Also might it not be worth taking the opportunity to modernise the raster format further than just re-arranging the files, and perhaps providing some kind of LGPL library for developers of 3rd-party software to use to read GRASS rasters (actually that already exists I think - isn't it what GDAL uses? http://freegis.org/cgi-bin/viewcvs.cgi/libgrass/ but don't think its used much.) Sorry, just a few thoughts I've had for a while; wanted to get them out on the list. Paul On Wed, 18 Apr 2007 grass-codep@wald.intevation.org wrote: > code P item #372, was opened at 2007-04-18 21:38 > Status: Open > Priority: 1 > Submitted By: Hamish Bowman (hamish) > Assigned to: Nobody (None) > Summary: scritps for converting raster maps into GRASS 7 format, and back > Patch status: postponed > Patch type: new > GRASS component: raster > GRASS version: None > GRASS CVS checkout date, if applies (YYMMDD): > > > Initial Comment: > r.convert and r.convert.all: > > Converts a GRASS 4-6 raster map to a GRASS 7 raster map by moving files around in the $MAPSET. > > Mostly untested, probably misses some bits. > > I did not use g.message as I think it should be fully backwards-compatible with GRASS 5.0.0 and newer. > > Tries to be really really cautious. > > > Hamish > > > ---------------------------------------------------------------------- > > You can respond by visiting: > http://wald.intevation.org/tracker/?func=detail&atid=205&aid=372&group_id=21 > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > From cavallini at faunalia.it Wed Apr 18 14:33:11 2007 From: cavallini at faunalia.it (Paolo Cavallini) Date: Wed Apr 18 14:33:15 2007 Subject: [GRASS-dev] [grass-code P][372] scritps for converting raster maps into GRASS 7 format, and back In-Reply-To: References: <20070418093838.B3A5F1953AAB@pyrosoma.intevation.org> Message-ID: <46261007.2040506@faunalia.it> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I agree (for what is worth): changing format is reasonable only to substantially improve things, not for minor cosmetics. Ideally, switching to a more standard format (eg geoTIFF, or anything read through gdal) would be good. Has the grass7 format already been agreed upon? All the best. pc Paul Kelly ha scritto: > Hello Hamish > Could it be written in C so it is more cross-platform? There is a new > function G_copy_file() in CVS that can copy files on disk. There is also > the C rename() function. > > The script could still be available to work with older versions of GRASS. > > Although I still don't think I like the idea of changing the internal > raster format as I expect it will break lots of 3rd-party software that > reads GRASS raster files directly, and could make GRASS look bad for > changing things. E.g. thinking of the detailed discussion of the raster > format a year or two ago for JavaGrass which reads it directly I think. > Also even GDAL must be passed the path to the cellhd directory to read a > GRASS raster I think? Also might it not be worth taking the opportunity > to modernise the raster format further than just re-arranging the files, > and perhaps providing some kind of LGPL library for developers of > 3rd-party software to use to read GRASS rasters (actually that already > exists I think - isn't it what GDAL uses? > http://freegis.org/cgi-bin/viewcvs.cgi/libgrass/ but don't think its > used much.) > > Sorry, just a few thoughts I've had for a while; wanted to get them out > on the list. > > Paul - -- Paolo Cavallini http://www.faunalia.it/pc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGJhAH/NedwLUzIr4RAtKLAKCBEuMKSIjLmI4tNYd0IzA99b2+FwCfbVDC IsDhQSA3ZBdYkQ+dbTieFuo= =3VJR -----END PGP SIGNATURE----- From woklist at kyngchaos.com Wed Apr 18 15:43:53 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Wed Apr 18 15:44:02 2007 Subject: [GRASS-dev] off_t problem In-Reply-To: <0735EFDF-2D7A-4438-A192-B8B54283ABB2@uv.es> References: <5077F501-62C1-41C3-ADB5-20D0D58A3864@kyngchaos.com> <0735EFDF-2D7A-4438-A192-B8B54283ABB2@uv.es> Message-ID: <041A96C9-BD54-411F-B7B2-4D989BB84C3B@kyngchaos.com> Yeah, that's the one. Glynn fixed it already in CVS. On Apr 18, 2007, at 3:50 AM, Agustin Diez Castillo wrote: > I guess this is related > Errors in: > /Users/Shared/grasssource/grass6/raster/r.support/modhead > -- > Finished compilation: Wed Apr 18 09:24:18 CEST 2007 > (In case of errors please change into the directory with error and > run 'make') > make: *** [default] Error 1 > regadiuet:/Users/Shared/grasssource/grass6 adiez$ cd raster/ > r.support/modhead > regadiuet:/Users/Shared/grasssource/grass6/raster/r.support/modhead > adiez$ make > Makefile:15: warning: overriding commands for target `htmletc1' > ../../../include/Make/Html.make:117: warning: ignoring old commands > for target `htmletc1' > gcc -I/Users/Shared/grasssource/grass6/dist.i686-apple-darwin8.9.1/ > include -arch ppc -arch i386 -DPACKAGE=\""grassmods"\" -I/ > Users/Shared/grasssource/grass6/dist.i686-apple-darwin8.9.1/include \ > -o OBJ.i686-apple-darwin8.9.1/ask_format.o -c ask_format.c > ask_format.c:14: error: parse error before 'off_t' ----- William Kyngesburye http://www.kyngchaos.com/ Theory of the Universe There is a theory which states that if ever anyone discovers exactly what the universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarrely inexplicable. There is another theory which states that this has already happened. -Hitchhiker's Guide to the Galaxy 2nd season intro From hamish_nospam at yahoo.com Wed Apr 18 15:51:16 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Apr 18 15:51:35 2007 Subject: [GRASS-dev] any way to know color assigned to a cell? In-Reply-To: References: <17950.48109.88914.169521@cerise.gclements.plus.com> Message-ID: <20070419015116.761a4e3e.hamish_nospam@yahoo.com> Michael: > >> If have a map with values from 0-255 I create a set of color rules > >> such that > >> 0% = green > >> 100% = red > >> > >> GRASS will create a color table that will assign a nice gradient of > >> colors from 0:255:0 to 255:0:0 to the values from 0-255. > >> > >> Is there any way when querying a single cell of that map to know > >> what color has been assigned to it? Glynn: > > Set a 1x1 region around the cell, then r.out.ppm | pnmnoraw | sed. > > > > Or r.mapcalc 'out = (r#map * 256 + g#map) * 256 + b#map', query the > > composite map and decode the category number. > > > >> Similarly, is there any way to know what color has > >> been assigned to any value in the 0-255 range? > > > > Set a 1x1 region, r.mapcalc "tmp = $value", r.out.ppm ... > > > > Seriously; this is how d.rast.edit.tcl does it. > > > > Yeah; we could probably do with a "r.what.colors" module. Michael: > I was contemplating a wxPython histograming module, like the TclTk > profiling module, and liked the option in d.histogram of being able to > use the color table for the histogram colors. But this seems like a > pretty intensive batch of calculations to do it. you could try "r.profile -c" with a profile which starts and stops at the cell center (length=0). Also it should be very simple to add a flag just like "r.profile -c" to r.what, if that helps. But probably the most direct solution is a SWIG-Python interface to the libgis color-lookup fns themselves. Hamish From woklist at kyngchaos.com Wed Apr 18 15:57:50 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Wed Apr 18 15:57:59 2007 Subject: [GRASS-dev] etc file finder, take 2 Message-ID: <85349885-5408-480A-B8AD-63DE67DE2997@kyngchaos.com> (ooh, my brain hurts after this - not made for C) Here's what I came up with. It uses an env var, GRASS_ADDON_ETC, much like the PATH and GRASS_ADDON_PATH vars - a colon-delimited list of paths to look in. And finally checks the GRASS application etc/. It returns the full path to the found file or folder, or null if not found. -------------- next part -------------- Skipped content of type multipart/appledouble-------------- next part -------------- And a companion g.findetc for use in scripts: -------------- next part -------------- A non-text attachment was scrubbed... Name: main.c Type: application/octet-stream Size: 1242 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070418/d03e15d5/main.obj -------------- next part -------------- Comments welcome. As before, I'm not much of a C programmer, so there is probably something wrong - maybe memory cleanup needed or very inefficient. At least it tested OK. ----- William Kyngesburye http://www.kyngchaos.com/ "This is a question about the past, is it? ... How can I tell that the past isn't a fiction designed to account for the discrepancy between my immediate physical sensations and my state of mind?" - The Ruler of the Universe From bcovill at tekmap.ns.ca Wed Apr 18 16:05:02 2007 From: bcovill at tekmap.ns.ca (Bob Covill) Date: Wed Apr 18 16:05:31 2007 Subject: [GRASS-dev] any way to know color assigned to a cell? In-Reply-To: <20070419015116.761a4e3e.hamish_nospam@yahoo.com> References: <17950.48109.88914.169521@cerise.gclements.plus.com> <20070419015116.761a4e3e.hamish_nospam@yahoo.com> Message-ID: <1176905102.12206.2.camel@linuxmain.localhost> On Thu, 2007-04-19 at 01:51 +1200, Hamish wrote: > Michael: > > >> If have a map with values from 0-255 I create a set of color rules > > >> such that > > >> 0% = green > > >> 100% = red > > >> > > >> GRASS will create a color table that will assign a nice gradient of > > >> colors from 0:255:0 to 255:0:0 to the values from 0-255. > > >> > > >> Is there any way when querying a single cell of that map to know > > >> what color has been assigned to it? > Glynn: > > > Set a 1x1 region around the cell, then r.out.ppm | pnmnoraw | sed. > > > > > > Or r.mapcalc 'out = (r#map * 256 + g#map) * 256 + b#map', query the > > > composite map and decode the category number. > > > > > >> Similarly, is there any way to know what color has > > >> been assigned to any value in the 0-255 range? > > > > > > Set a 1x1 region, r.mapcalc "tmp = $value", r.out.ppm ... > > > > > > Seriously; this is how d.rast.edit.tcl does it. > > > > > > Yeah; we could probably do with a "r.what.colors" module. > Michael: > > I was contemplating a wxPython histograming module, like the TclTk > > profiling module, and liked the option in d.histogram of being able to > > use the color table for the histogram colors. But this seems like a > > pretty intensive batch of calculations to do it. > > > you could try "r.profile -c" with a profile which starts and stops at > the cell center (length=0). Also it should be very simple to add a flag > just like "r.profile -c" to r.what, if that helps. I have a version of r.what that I modified to optionally output RGB color. If interested I could commit to CVS? -- Bob > > But probably the most direct solution is a SWIG-Python interface to the > libgis color-lookup fns themselves. > > > Hamish > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From tutey at o2.pl Wed Apr 18 16:40:35 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Wed Apr 18 16:40:39 2007 Subject: [GRASS-dev] any way to know color assigned to a cell? In-Reply-To: <1176905102.12206.2.camel@linuxmain.localhost> References: <17950.48109.88914.169521@cerise.gclements.plus.com> <20070419015116.761a4e3e.hamish_nospam@yahoo.com> <1176905102.12206.2.camel@linuxmain.localhost> Message-ID: <46262DE3.9090401@o2.pl> Bob Covill wrote: > I have a version of r.what that I modified to optionally output RGB > color. If interested I could commit to CVS? Sounds great to me. Maciek From glynn at gclements.plus.com Wed Apr 18 17:33:36 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Apr 18 17:33:39 2007 Subject: [GRASS-dev] Unused files In-Reply-To: <4625C790.6000809@itc.it> References: <17955.44112.860626.760287@cerise.gclements.plus.com> <20070416211952.GB9087@bartok.itc.it> <17955.63182.103807.825355@cerise.gclements.plus.com> <4625C790.6000809@itc.it> Message-ID: <17958.14928.641284.827333@cerise.gclements.plus.com> Markus Neteler wrote: > >>> lib/vector/dglib/avl.c | avl_allocator_default > >>> > >> avl: libavl - library for manipulation of binary trees > >> I think we have also lib/btree/ is that's the same purpose? > >> > > > > Yes; both provide essentially the same functionality. > > > > AVL trees are balanced, so they have better worst-case performance. > > > > Unbalanced trees are O(log(n)) for random data but degenerate to O(n) > > for sorted data (you essentially end up with a linked list). Balanced > > trees are always O(log(n)), although with a higher constant factor for > > insertions due to the cost of rebalancing. > > > Could this be a reason to drop > lib/btree/ > and to replace it by a wrapper to > lib/vector/dglib/ The interface is quite different. lib/btree has separate key/value, while avl.c has a monolithic "item", with the user-supplied compare function being used to determine matches. IMHO, it would be better to modify lib/btree to use AVL trees (or B-trees etc) if performance is considered an issue. -- Glynn Clements From glynn at gclements.plus.com Wed Apr 18 17:42:04 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Apr 18 17:42:07 2007 Subject: [GRASS-dev] ascii export and import, large file problem In-Reply-To: <20070418203038.2c18b59b.hamish_nospam@yahoo.com> References: <20070413073931.AOC98228@expms1.cites.uiuc.edu> <20070418203038.2c18b59b.hamish_nospam@yahoo.com> Message-ID: <17958.15436.169659.460094@cerise.gclements.plus.com> Hamish wrote: > > Helena, I think the issue when I tried this before is that grass > > doesn't know that x and y are in degrees while z is in meters. It > > either assumes they are the same or uses the zfactor option to > > multiply the z value by something to get it into the same units as x > > and y. > > > > But if I could tell grass that the z units were meters explicitly, > > couldn't grass do the conversion automatically? Especially since the > > conversion changes as you move north. > > > http://article.gmane.org/gmane.comp.gis.grass.devel/19353/ > http://article.gmane.org/gmane.comp.gis.grass.devel/19523/ > > --relevant quotes-- > [1...] > For a real y-axis label I think we need to add a new (optional) "units" > element to the raster format (e.g. in cell_misc/). > [2...] > > The user should be able to add a title for the legend. > > For vlegends that's doable. For raster legends I hope to add > G_set_raster_units() and G_get_raster_units() to write/read a simple > string containing raster data units (set from "r.support units=") which > will be stored in $MAPSET/cell_misc/$RASTERMAP/units. Raster legends and > things like lat/lon NVIZ and r.shaded.relief could use the tag if it > existed. > --endquote-- > > apparently cell_misc/ is evil, so that moves it to > $MAPSET/units/$RASTERMAP until GRASS7 when it moves to > $MAPSET/raster/$RASTERMAP/units > > I don't like to add another element dir to $MAPSET, but... Given that cell_misc exists and can't easily be removed right now, you may as well use it for now. Just use the _misc functions which I recently added, i.e. char *G__file_name_misc(char *, const char *, const char *, const char *, const char *); char *G_find_file_misc(const char *, const char *, char *, const char *); char *G_find_file2_misc(const char *, const char *, const char *, const char *); int G__make_mapset_element_misc (const char *, const char *); int G_open_new_misc(const char *, const char *, const char *); int G_open_old_misc(const char *, const char *, const char *, const char *); int G_open_update_misc(const char *, const char *, const char *); FILE *G_fopen_new_misc(const char *, const char *, const char *); FILE *G_fopen_old_misc(const char *, const char *, const char *, const char *); FILE *G_fopen_append_misc(const char *, const char *, const char *); FILE *G_fopen_modify_misc(const char *, const char *, const char *); int G_remove_misc (const char *, const char *, const char *); rather than using sprintf(element, "cell_misc/%s", name) hacks. As for what to do in 7.x: having one directory per map with a file for each element is neater, but that limits the number of maps in a mapset to the filesystem's hard link count limit (32000 for ext2/ext3). We've had at least one person complain about this. -- Glynn Clements From glynn at gclements.plus.com Wed Apr 18 17:59:07 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Apr 18 17:59:09 2007 Subject: [GRASS-dev] [grass-code P][372] scritps for converting raster maps into GRASS 7 format, and back In-Reply-To: References: <20070418093838.B3A5F1953AAB@pyrosoma.intevation.org> Message-ID: <17958.16459.235853.11925@cerise.gclements.plus.com> Paul Kelly wrote: > Although I still don't think I like the idea of changing the internal > raster format as I expect it will break lots of 3rd-party software that > reads GRASS raster files directly, and could make GRASS look bad for > changing things. FWIW, I don't feel that the future of GRASS should be constrained by whether or not third parties are willing to maintain compatibility. > E.g. thinking of the detailed discussion of the raster > format a year or two ago for JavaGrass which reads it directly I think. > Also even GDAL must be passed the path to the cellhd directory to read a > GRASS raster I think? Also might it not be worth taking the opportunity to > modernise the raster format further than just re-arranging the files, and > perhaps providing some kind of LGPL library for developers of 3rd-party > software to use to read GRASS rasters (actually that already exists I > think - isn't it what GDAL uses? > http://freegis.org/cgi-bin/viewcvs.cgi/libgrass/ but don't think its used > much.) Actually, I've been thinking about hiving off the base raster format to a separate library, along with generalising the low-level I/O to allow for an "r.external" command, i.e. allow GRASS raster I/O to directly read external files through GDAL. The higher level stuff (rescaling, format conversion, reclassing, MASK etc) would remain in GRASS. The main issue is that some modules perform random access (i.e. don't read the rows in top-to-bottom order), and not all raster formats can support this efficiently (uncompressed formats such as BMP or raw-PPM can, but anything which uses compression needs an index). A related problem is that modules don't have to explicitly request non-linear access at open time, so there's no simple way to identify which modules would be affected. -- Glynn Clements From glynn at gclements.plus.com Wed Apr 18 18:16:09 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Apr 18 18:16:11 2007 Subject: [GRASS-dev] etc file finder, take 2 In-Reply-To: <85349885-5408-480A-B8AD-63DE67DE2997@kyngchaos.com> References: <85349885-5408-480A-B8AD-63DE67DE2997@kyngchaos.com> Message-ID: <17958.17481.129183.667933@cerise.gclements.plus.com> William Kyngesburye wrote: > Here's what I came up with. It uses an env var, GRASS_ADDON_ETC, > much like the PATH and GRASS_ADDON_PATH vars - a colon-delimited list > of paths to look in. And finally checks the GRASS application etc/. > > It returns the full path to the found file or folder, or null if not > found. The mechanism seems reasonable, although I have quite a few comments on the implementation. The main one is that I'd suggest using G_tokenize() to do most of the work for you. Also, make the argument "const char *" (you don't need to modify it) and use GPATH_MAX as the size of the path buffer (I've been replacing various random constants with that value as I find them; also for GNAME_MAX and GMAPSET_MAX).. E.g. (untested): static char *G__find_etc(const char *name) { const char *pathlist = getenv("GRASS_ADDON_ETC"); char path[GPATH_MAX]; if (pathlist) { char **dirs = G_tokenize(pathlist, ":"); char *result = NULL; int i; for (i = 0; dirs[i]; i++) { sprintf(path, "%s/%s", dirs[i], name); if (access(path, 0) == 0) { result = G_store(path); break; } } G_free_tokens(dirs); if (result) return result; } sprintf(path, "%s/etc/%s", G_gisbase(), name); if (access(path, 0) == 0) return G_store(path); return NULL; } Also: > #include Not needed; add it to gisdefs.h. > And a companion g.findetc for use in scripts: > exit(fpath==NULL); exit(fpath ? EXIT_SUCCESS : EXIT_FAILURE); -- Glynn Clements From glynn at gclements.plus.com Wed Apr 18 18:19:46 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Apr 18 18:19:49 2007 Subject: [GRASS-dev] any way to know color assigned to a cell? In-Reply-To: <1176905102.12206.2.camel@linuxmain.localhost> References: <17950.48109.88914.169521@cerise.gclements.plus.com> <20070419015116.761a4e3e.hamish_nospam@yahoo.com> <1176905102.12206.2.camel@linuxmain.localhost> Message-ID: <17958.17698.218980.703526@cerise.gclements.plus.com> Bob Covill wrote: > > > > Yeah; we could probably do with a "r.what.colors" module. > > Michael: > > > I was contemplating a wxPython histograming module, like the TclTk > > > profiling module, and liked the option in d.histogram of being able to > > > use the color table for the histogram colors. But this seems like a > > > pretty intensive batch of calculations to do it. > > > > > > you could try "r.profile -c" with a profile which starts and stops at > > the cell center (length=0). Also it should be very simple to add a flag > > just like "r.profile -c" to r.what, if that helps. > > I have a version of r.what that I modified to optionally output RGB > color. If interested I could commit to CVS? It may be useful to have that feature in r.what, although there would still be some use for a module which looks up the colour for a user-supplied value (e.g. d.rast.edit.tcl needs to be able to determine the colour for new values which don't yet exist in the map). -- Glynn Clements From michael.barton at asu.edu Wed Apr 18 18:30:04 2007 From: michael.barton at asu.edu (Michael Barton) Date: Wed Apr 18 18:30:12 2007 Subject: [GRASS-dev] any way to know color assigned to a cell? In-Reply-To: <1176905102.12206.2.camel@linuxmain.localhost> Message-ID: This is fine, but I'm afraid that it won't help planned implementation. This is partly because I didn't phrase my question correctly. What I really need to know is what color is assigned to a cat value. The idea is to do histogramming in wxPython. It might be nice to have the histogram show the map colors like d.histogram can. To do that, I need to know the color assigned to a cat. However, to get colors by querying every cell in a map with r.what would take a very long time. Michael On 4/18/07 7:05 AM, "Bob Covill" wrote: > On Thu, 2007-04-19 at 01:51 +1200, Hamish wrote: >> Michael: >>>>> If have a map with values from 0-255 I create a set of color rules >>>>> such that >>>>> 0% = green >>>>> 100% = red >>>>> >>>>> GRASS will create a color table that will assign a nice gradient of >>>>> colors from 0:255:0 to 255:0:0 to the values from 0-255. >>>>> >>>>> Is there any way when querying a single cell of that map to know >>>>> what color has been assigned to it? >> Glynn: >>>> Set a 1x1 region around the cell, then r.out.ppm | pnmnoraw | sed. >>>> >>>> Or r.mapcalc 'out = (r#map * 256 + g#map) * 256 + b#map', query the >>>> composite map and decode the category number. >>>> >>>>> Similarly, is there any way to know what color has >>>>> been assigned to any value in the 0-255 range? >>>> >>>> Set a 1x1 region, r.mapcalc "tmp = $value", r.out.ppm ... >>>> >>>> Seriously; this is how d.rast.edit.tcl does it. >>>> >>>> Yeah; we could probably do with a "r.what.colors" module. >> Michael: >>> I was contemplating a wxPython histograming module, like the TclTk >>> profiling module, and liked the option in d.histogram of being able to >>> use the color table for the histogram colors. But this seems like a >>> pretty intensive batch of calculations to do it. >> >> >> you could try "r.profile -c" with a profile which starts and stops at >> the cell center (length=0). Also it should be very simple to add a flag >> just like "r.profile -c" to r.what, if that helps. > > I have a version of r.what that I modified to optionally output RGB > color. If interested I could commit to CVS? > > -- > Bob > > >> >> But probably the most direct solution is a SWIG-Python interface to the >> libgis color-lookup fns themselves. >> >> >> Hamish >> >> _______________________________________________ >> grass-dev mailing list >> grass-dev@grass.itc.it >> http://grass.itc.it/mailman/listinfo/grass-dev > > __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From soerengebbert at gmx.de Wed Apr 18 18:49:11 2007 From: soerengebbert at gmx.de (Soeren Gebbert) Date: Wed Apr 18 18:40:12 2007 Subject: [GRASS-dev] [grass-code P][372] scritps for converting raster =?iso-8859-1?q?maps=09into_GRASS_7?= format, and back In-Reply-To: <17958.16459.235853.11925@cerise.gclements.plus.com> References: <20070418093838.B3A5F1953AAB@pyrosoma.intevation.org> <17958.16459.235853.11925@cerise.gclements.plus.com> Message-ID: <200704181849.12545.soerengebbert@gmx.de> Hi, Am Mittwoch, 18. April 2007 17:59 schrieb Glynn Clements: > Paul Kelly wrote: > > Although I still don't think I like the idea of changing the internal > > raster format as I expect it will break lots of 3rd-party software that > > reads GRASS raster files directly, and could make GRASS look bad for > > changing things. > > FWIW, I don't feel that the future of GRASS should be constrained by > whether or not third parties are willing to maintain compatibility. > > > E.g. thinking of the detailed discussion of the raster > > format a year or two ago for JavaGrass which reads it directly I think. > > Also even GDAL must be passed the path to the cellhd directory to read a > > GRASS raster I think? Also might it not be worth taking the opportunity > > to modernise the raster format further than just re-arranging the files, > > and perhaps providing some kind of LGPL library for developers of > > 3rd-party software to use to read GRASS rasters (actually that already > > exists I think - isn't it what GDAL uses? > > http://freegis.org/cgi-bin/viewcvs.cgi/libgrass/ but don't think its used > > much.) > > Actually, I've been thinking about hiving off the base raster format > to a separate library, along with generalising the low-level I/O to > allow for an "r.external" command, i.e. allow GRASS raster I/O to > directly read external files through GDAL. > > The higher level stuff (rescaling, format conversion, reclassing, MASK > etc) would remain in GRASS. That is an interesting approach. But we already have a very sophisticated library in grass, which can be used for raster data management. Im talking about the g3d library. IMHO this lib can be extended to support raster maps. The g3d lib supports state of the art data access. I recently readed a terralib document about handling raster data and noticed that the g3d library features are quite progressive. It supports: * variable tile sizes * direct uncached tile access * cached random value access ** while random acces, the tiles which are accessed last are kept in the cache memory ** support of different data type sizes * the directory structure is of type g3d/map_name/files We should consider to extent this lib for internal usage. There is no problem to add an abstraction layer to support external raster map implementations, like the callback design in the display driver code. Some kind of OO design would be great: example: typedef struct G2d_data { Data_source *map; /*g3d or what ever*/ Metadata stuff .... ; /*value access member functions*/ CELL (*get_c_value)(struct G2d_data*, int, int); FCELL (*get_f_value)(struct G2d_data*, int, int); ... void (*put_c_value)(struct G2d_data*, int, int, CELL); void (*put_f_value)(struct G2d_data*, int, int, FCELL); ... /*tile access meber functions*/ CELL *(*get_c_row)(struct G2d_data*, int, int); CELL *(*get_c_tile)(struct G2d_data*, int, int); ... int (*put_tile)(struct G2d_data *, int, int); ... } G2d_data; The callback member functions are static functions like this: G_put_c_value(G2d_data* map, int col, int row, CELL value); and so on ... And set while opening a raster data source. A simple data acces should look like this: { G2d_data *data_source; CELL value; data_source = G_open_raster_data_source(name, type, ...); value = data_source->get_c_value(data_source, 3, 4); data_source->put_c_value(data_source, 3, 4, value); } I will upadte the gpde library with this kind of member function data access. I hope we consider to extent the g3d lib and additionally add new metadata handling and temporal data management. Best regards Soeren > > The main issue is that some modules perform random access (i.e. don't > read the rows in top-to-bottom order), and not all raster formats can > support this efficiently (uncompressed formats such as BMP or raw-PPM > can, but anything which uses compression needs an index). > > A related problem is that modules don't have to explicitly request > non-linear access at open time, so there's no simple way to identify > which modules would be affected. From woklist at kyngchaos.com Wed Apr 18 18:46:42 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Wed Apr 18 18:46:50 2007 Subject: [GRASS-dev] etc file finder, take 2 In-Reply-To: <17958.17481.129183.667933@cerise.gclements.plus.com> References: <85349885-5408-480A-B8AD-63DE67DE2997@kyngchaos.com> <17958.17481.129183.667933@cerise.gclements.plus.com> Message-ID: <9C4C5A80-4FD5-4005-BDDC-F89A14E5AF3B@kyngchaos.com> Thanks... On Apr 18, 2007, at 11:16 AM, Glynn Clements wrote: > The main one is that I'd suggest using G_tokenize() to do most of the > work for you. (more C details that escape me...) My little (basic) C book says a program shouldn't alter an env var returned by getenv, and G_tokenize() says it changes the token to null to terminate token strings (which is what I originally did myself before I read that bit about getenv). Is that what that char ** or const char * takes care of somehow, do either make a copy of the env var? Or is it part of the tokenize initialization? > Also, make the argument "const char *" (you don't need > to modify it) and use GPATH_MAX as the size of the path buffer (I've > been replacing various random constants with that value as I find > them; also for GNAME_MAX and GMAPSET_MAX).. > Ah, I used an older find_file as a starting point. I see you updated this yesterday. > E.g. (untested): > > static char *G__find_etc(const char *name) > { > const char *pathlist = getenv("GRASS_ADDON_ETC"); > char path[GPATH_MAX]; > ... > } > I'll give this a closer look and try it this evening. > Also: > >> #include > > Not needed; add it to gisdefs.h. > Oops, leftover from the earlier configured-paths version. Not needed now. But, I do have the prototype for G_find_etc() in gisdefs.h. >> And a companion g.findetc for use in scripts: > >> exit(fpath==NULL); > > exit(fpath ? EXIT_SUCCESS : EXIT_FAILURE); > got it. ----- William Kyngesburye http://www.kyngchaos.com/ [Trillian] What are you supposed to do WITH a maniacally depressed robot? [Marvin] You think you have problems? What are you supposed to do if you ARE a maniacally depressed robot? No, don't try and answer, I'm 50,000 times more intelligent than you and even I don't know the answer... - HitchHiker's Guide to the Galaxy From glynn at gclements.plus.com Wed Apr 18 19:52:39 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Apr 18 19:52:47 2007 Subject: [GRASS-dev] etc file finder, take 2 In-Reply-To: <9C4C5A80-4FD5-4005-BDDC-F89A14E5AF3B@kyngchaos.com> References: <85349885-5408-480A-B8AD-63DE67DE2997@kyngchaos.com> <17958.17481.129183.667933@cerise.gclements.plus.com> <9C4C5A80-4FD5-4005-BDDC-F89A14E5AF3B@kyngchaos.com> Message-ID: <17958.23271.458566.779734@cerise.gclements.plus.com> William Kyngesburye wrote: > > The main one is that I'd suggest using G_tokenize() to do most of the > > work for you. > > (more C details that escape me...) > > My little (basic) C book says a program shouldn't alter an env var > returned by getenv, and G_tokenize() says it changes the token to > null to terminate token strings (which is what I originally did > myself before I read that bit about getenv). Is that what that char > ** or const char * takes care of somehow, do either make a copy of > the env var? Or is it part of the tokenize initialization? G_tokenize() makes a copy of the string. -- Glynn Clements From glynn at gclements.plus.com Wed Apr 18 20:04:10 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Apr 18 20:04:14 2007 Subject: [GRASS-dev] [grass-code P][372] scritps for converting raster =?iso-8859-1?q?maps=09into_GRASS_7?= format, and back In-Reply-To: <200704181849.12545.soerengebbert@gmx.de> References: <20070418093838.B3A5F1953AAB@pyrosoma.intevation.org> <17958.16459.235853.11925@cerise.gclements.plus.com> <200704181849.12545.soerengebbert@gmx.de> Message-ID: <17958.23962.167459.406092@cerise.gclements.plus.com> Soeren Gebbert wrote: > > Actually, I've been thinking about hiving off the base raster format > > to a separate library, along with generalising the low-level I/O to > > allow for an "r.external" command, i.e. allow GRASS raster I/O to > > directly read external files through GDAL. > > > > The higher level stuff (rescaling, format conversion, reclassing, MASK > > etc) would remain in GRASS. > > That is an interesting approach. But we already have a very sophisticated > library in grass, which can be used for raster data management. > Im talking about the g3d library. IMHO this lib can be extended to support > raster maps. THe key point is that we need to preserve the G_get_raster_row() etc interface. Also, when downscaling, you ideally want to completely skip any rows which aren't actually requested, rather than doing most of the work then discarding unused data at the end. The idea behind r.external is that it would require relatively modest changes to the lowest levels of the raster I/O code (i.e. the parts that read/write raw data to/from the cell/fcell files). The rest of the I/O stack (and, most importantly, the API) would remain unaffected. BTW, one of the main priorities for the the G3D library should be to enable LFS. I didn't touch it in my recent round of LFS changes because the issues were too pervasive (e.g. the various offsets in the G3D_Map structure). -- Glynn Clements From bcovill at tekmap.ns.ca Wed Apr 18 21:02:49 2007 From: bcovill at tekmap.ns.ca (Bob Covill) Date: Wed Apr 18 21:03:19 2007 Subject: [GRASS-dev] any way to know color assigned to a cell? In-Reply-To: <17958.17698.218980.703526@cerise.gclements.plus.com> References: <17950.48109.88914.169521@cerise.gclements.plus.com> <20070419015116.761a4e3e.hamish_nospam@yahoo.com> <1176905102.12206.2.camel@linuxmain.localhost> <17958.17698.218980.703526@cerise.gclements.plus.com> Message-ID: <1176922969.6624.2.camel@linuxmain.localhost> On Wed, 2007-04-18 at 17:19 +0100, Glynn Clements wrote: > Bob Covill wrote: > > > > > > Yeah; we could probably do with a "r.what.colors" module. > > > Michael: > > > > I was contemplating a wxPython histograming module, like the TclTk > > > > profiling module, and liked the option in d.histogram of being able to > > > > use the color table for the histogram colors. But this seems like a > > > > pretty intensive batch of calculations to do it. > > > > > > > > > you could try "r.profile -c" with a profile which starts and stops at > > > the cell center (length=0). Also it should be very simple to add a flag > > > just like "r.profile -c" to r.what, if that helps. > > > > I have a version of r.what that I modified to optionally output RGB > > color. If interested I could commit to CVS? > I have committed the change to r.what. It now has a "-r" flag (-c was taken) that will output the RGB for the selected point. Please test. > It may be useful to have that feature in r.what, although there would > still be some use for a module which looks up the colour for a > user-supplied value (e.g. d.rast.edit.tcl needs to be able to > determine the colour for new values which don't yet exist in the map). > From bcovill at tekmap.ns.ca Wed Apr 18 21:22:06 2007 From: bcovill at tekmap.ns.ca (Bob Covill) Date: Wed Apr 18 21:22:33 2007 Subject: [GRASS-dev] any way to know color assigned to a cell? In-Reply-To: References: Message-ID: <1176924127.6624.13.camel@linuxmain.localhost> Michael, If you are looking to duplicate d.histogram why not use r.stats? This will output raster values with the percent or area which could be used for plotting a histogram. If this did work it could be modified to output the associated raster color along with the other values. Maybe I am missing the point? On a related issues I have used a modified version of r.stats for a while now to create equalized color bars for raster maps. You simply calculate the distribution over a set number of color breaks, drop a custom colortable over the breaks and apply with r.colors rules=. Hope this helps. -- Bob On Wed, 2007-04-18 at 09:30 -0700, Michael Barton wrote: > This is fine, but I'm afraid that it won't help planned implementation. This > is partly because I didn't phrase my question correctly. What I really need > to know is what color is assigned to a cat value. The idea is to do > histogramming in wxPython. It might be nice to have the histogram show the > map colors like d.histogram can. To do that, I need to know the color > assigned to a cat. However, to get colors by querying every cell in a map > with r.what would take a very long time. > > Michael > > > On 4/18/07 7:05 AM, "Bob Covill" wrote: > > > On Thu, 2007-04-19 at 01:51 +1200, Hamish wrote: > >> Michael: > >>>>> If have a map with values from 0-255 I create a set of color rules > >>>>> such that > >>>>> 0% = green > >>>>> 100% = red > >>>>> > >>>>> GRASS will create a color table that will assign a nice gradient of > >>>>> colors from 0:255:0 to 255:0:0 to the values from 0-255. > >>>>> > >>>>> Is there any way when querying a single cell of that map to know > >>>>> what color has been assigned to it? > >> Glynn: > >>>> Set a 1x1 region around the cell, then r.out.ppm | pnmnoraw | sed. > >>>> > >>>> Or r.mapcalc 'out = (r#map * 256 + g#map) * 256 + b#map', query the > >>>> composite map and decode the category number. > >>>> > >>>>> Similarly, is there any way to know what color has > >>>>> been assigned to any value in the 0-255 range? > >>>> > >>>> Set a 1x1 region, r.mapcalc "tmp = $value", r.out.ppm ... > >>>> > >>>> Seriously; this is how d.rast.edit.tcl does it. > >>>> > >>>> Yeah; we could probably do with a "r.what.colors" module. > >> Michael: > >>> I was contemplating a wxPython histograming module, like the TclTk > >>> profiling module, and liked the option in d.histogram of being able to > >>> use the color table for the histogram colors. But this seems like a > >>> pretty intensive batch of calculations to do it. > >> > >> > >> you could try "r.profile -c" with a profile which starts and stops at > >> the cell center (length=0). Also it should be very simple to add a flag > >> just like "r.profile -c" to r.what, if that helps. > > > > I have a version of r.what that I modified to optionally output RGB > > color. If interested I could commit to CVS? > > > > -- > > Bob > > > > > >> > >> But probably the most direct solution is a SWIG-Python interface to the > >> libgis color-lookup fns themselves. > >> > >> > >> Hamish > >> > >> _______________________________________________ > >> grass-dev mailing list > >> grass-dev@grass.itc.it > >> http://grass.itc.it/mailman/listinfo/grass-dev > > > > > > __________________________________________ > Michael Barton, Professor of Anthropology > School of Human Evolution & Social Change > Center for Social Dynamics & Complexity > Arizona State University > > phone: 480-965-6213 > fax: 480-965-7671 > www: http://www.public.asu.edu/~cmbarton > > From soerengebbert at gmx.de Wed Apr 18 21:45:02 2007 From: soerengebbert at gmx.de (Soeren Gebbert) Date: Wed Apr 18 21:36:04 2007 Subject: [GRASS-dev] [grass-code P][372] scritps for converting raster =?iso-8859-1?q?maps=09into_GRASS_7?= format, and back In-Reply-To: <17958.23962.167459.406092@cerise.gclements.plus.com> References: <20070418093838.B3A5F1953AAB@pyrosoma.intevation.org> <200704181849.12545.soerengebbert@gmx.de> <17958.23962.167459.406092@cerise.gclements.plus.com> Message-ID: <200704182145.02816.soerengebbert@gmx.de> Am Mittwoch, 18. April 2007 20:04 schrieb Glynn Clements: > Soeren Gebbert wrote: > > > Actually, I've been thinking about hiving off the base raster format > > > to a separate library, along with generalising the low-level I/O to > > > allow for an "r.external" command, i.e. allow GRASS raster I/O to > > > directly read external files through GDAL. > > > > > > The higher level stuff (rescaling, format conversion, reclassing, MASK > > > etc) would remain in GRASS. > > > > That is an interesting approach. But we already have a very sophisticated > > library in grass, which can be used for raster data management. > > Im talking about the g3d library. IMHO this lib can be extended to > > support raster maps. > > THe key point is that we need to preserve the G_get_raster_row() etc > interface. If we set the tile size to the size of one raster row, the tile functions of the g3d library will show the behaviour of G_get_raster_row() without skipping any kind of data. There is no need to skip existing API, we just need to wrap the g3d lib calls: First set the tile size when open a new map: void *G_open_raster_new (const char *name, RASTER_MAP_TYPE type) { struct Cell_head region2d; G3d_Region region3d; ... G3d_getWindow (®ion3d); G_get_set_window(®ion2d); G3d_regionFromToCellHead(®ion2d, ®ion3d); region3d.depths = 1; region3d.top = 1; region3d.bottom = 0; region3d.tb_res = 1; return G3d_openCellNewParam(name, RASTER_MAP_TYPE, G3D_NO_CACHE, ®ion3d, type, doLzw, doRle, precision, rows, 1, 1); } Now we can access the tiles: int G_put_raster_row (void *map, void *rast, RASTER_MAP_TYPE data_type) { return G3d_writeTile(map, row, rast, RASTER_MAP_TYPE ); } int G_get_raster_row (void* map, void *rast, int row, RASTER_MAP_TYPE data_type) { return G3d_readTile(map, row, rast, RASTER_MAP_TYPE ); } The API will change a bit because of the first argument of G_get_raster_row(). > > Also, when downscaling, you ideally want to completely skip any rows > which aren't actually requested, rather than doing most of the work > then discarding unused data at the end. > > The idea behind r.external is that it would require relatively modest > changes to the lowest levels of the raster I/O code (i.e. the parts > that read/write raw data to/from the cell/fcell files). The rest of > the I/O stack (and, most importantly, the API) would remain > unaffected. > > BTW, one of the main priorities for the the G3D library should be to > enable LFS. I didn't touch it in my recent round of LFS changes > because the issues were too pervasive (e.g. the various offsets in the > G3D_Map structure). That's too bad, i have no clue how to enable LFS support. :( Best regards Soeren From michael.barton at asu.edu Wed Apr 18 23:10:34 2007 From: michael.barton at asu.edu (Michael Barton) Date: Wed Apr 18 23:10:40 2007 Subject: [GRASS-dev] any way to know color assigned to a cell? In-Reply-To: <1176924127.6624.13.camel@linuxmain.localhost> Message-ID: Bob, This is exactly what I need. Michael On 4/18/07 12:22 PM, "Bob Covill" wrote: > Michael, > > If you are looking to duplicate d.histogram why not use r.stats? This > will output raster values with the percent or area which could be used > for plotting a histogram. If this did work it could be modified to > output the associated raster color along with the other values. Maybe I > am missing the point? > > On a related issues I have used a modified version of r.stats for a > while now to create equalized color bars for raster maps. You simply > calculate the distribution over a set number of color breaks, drop a > custom colortable over the breaks and apply with r.colors rules=. > > Hope this helps. > > -- > Bob > > On Wed, 2007-04-18 at 09:30 -0700, Michael Barton wrote: >> This is fine, but I'm afraid that it won't help planned implementation. This >> is partly because I didn't phrase my question correctly. What I really need >> to know is what color is assigned to a cat value. The idea is to do >> histogramming in wxPython. It might be nice to have the histogram show the >> map colors like d.histogram can. To do that, I need to know the color >> assigned to a cat. However, to get colors by querying every cell in a map >> with r.what would take a very long time. >> >> Michael >> >> >> On 4/18/07 7:05 AM, "Bob Covill" wrote: >> >>> On Thu, 2007-04-19 at 01:51 +1200, Hamish wrote: >>>> Michael: >>>>>>> If have a map with values from 0-255 I create a set of color rules >>>>>>> such that >>>>>>> 0% = green >>>>>>> 100% = red >>>>>>> >>>>>>> GRASS will create a color table that will assign a nice gradient of >>>>>>> colors from 0:255:0 to 255:0:0 to the values from 0-255. >>>>>>> >>>>>>> Is there any way when querying a single cell of that map to know >>>>>>> what color has been assigned to it? >>>> Glynn: >>>>>> Set a 1x1 region around the cell, then r.out.ppm | pnmnoraw | sed. >>>>>> >>>>>> Or r.mapcalc 'out = (r#map * 256 + g#map) * 256 + b#map', query the >>>>>> composite map and decode the category number. >>>>>> >>>>>>> Similarly, is there any way to know what color has >>>>>>> been assigned to any value in the 0-255 range? >>>>>> >>>>>> Set a 1x1 region, r.mapcalc "tmp = $value", r.out.ppm ... >>>>>> >>>>>> Seriously; this is how d.rast.edit.tcl does it. >>>>>> >>>>>> Yeah; we could probably do with a "r.what.colors" module. >>>> Michael: >>>>> I was contemplating a wxPython histograming module, like the TclTk >>>>> profiling module, and liked the option in d.histogram of being able to >>>>> use the color table for the histogram colors. But this seems like a >>>>> pretty intensive batch of calculations to do it. >>>> >>>> >>>> you could try "r.profile -c" with a profile which starts and stops at >>>> the cell center (length=0). Also it should be very simple to add a flag >>>> just like "r.profile -c" to r.what, if that helps. >>> >>> I have a version of r.what that I modified to optionally output RGB >>> color. If interested I could commit to CVS? >>> >>> -- >>> Bob >>> >>> >>>> >>>> But probably the most direct solution is a SWIG-Python interface to the >>>> libgis color-lookup fns themselves. >>>> >>>> >>>> Hamish >>>> >>>> _______________________________________________ >>>> grass-dev mailing list >>>> grass-dev@grass.itc.it >>>> http://grass.itc.it/mailman/listinfo/grass-dev >>> >>> >> >> __________________________________________ >> Michael Barton, Professor of Anthropology >> School of Human Evolution & Social Change >> Center for Social Dynamics & Complexity >> Arizona State University >> >> phone: 480-965-6213 >> fax: 480-965-7671 >> www: http://www.public.asu.edu/~cmbarton >> >> > __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From glynn at gclements.plus.com Thu Apr 19 02:23:01 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Apr 19 02:23:05 2007 Subject: [GRASS-dev] any way to know color assigned to a cell? In-Reply-To: <17958.17698.218980.703526@cerise.gclements.plus.com> References: <17950.48109.88914.169521@cerise.gclements.plus.com> <20070419015116.761a4e3e.hamish_nospam@yahoo.com> <1176905102.12206.2.camel@linuxmain.localhost> <17958.17698.218980.703526@cerise.gclements.plus.com> Message-ID: <17958.46693.315258.759312@cerise.gclements.plus.com> Glynn Clements wrote: > > I have a version of r.what that I modified to optionally output RGB > > color. If interested I could commit to CVS? > > It may be useful to have that feature in r.what, although there would > still be some use for a module which looks up the colour for a > user-supplied value (e.g. d.rast.edit.tcl needs to be able to > determine the colour for new values which don't yet exist in the map). I have added such a module, name r.what.color. Values can be passed either on the command line or on stdin, and the corresponding colours are written on stdout. -- Glynn Clements From woklist at kyngchaos.com Thu Apr 19 03:59:06 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Thu Apr 19 03:59:18 2007 Subject: [GRASS-dev] etc file finder, take 2 In-Reply-To: <17958.17481.129183.667933@cerise.gclements.plus.com> References: <85349885-5408-480A-B8AD-63DE67DE2997@kyngchaos.com> <17958.17481.129183.667933@cerise.gclements.plus.com> Message-ID: That all works nicely. thanks. For the const char * arg in G__find_etc() - should I also do that for the public version of this, G_find_etc()? On Apr 18, 2007, at 11:16 AM, Glynn Clements wrote: > work for you. Also, make the argument "const char *" (you don't need > to modify it) and use GPATH_MAX as the size of the path buffer (I've > been replacing various random constants with that value as I find > them; also for GNAME_MAX and GMAPSET_MAX).. > > E.g. (untested): > > static char *G__find_etc(const char *name) > { ----- William Kyngesburye http://www.kyngchaos.com/ "Mon Dieu! but they are all alike. Cheating, murdering, lying, fighting, and all for things that the beasts of the jungle would not deign to possess - money to purchase the effeminate pleasures of weaklings. And yet withal bound down by silly customs that make them slaves to their unhappy lot while firm in the belief that they be the lords of creation enjoying the only real pleasures of existence.... - the wisdom of Tarzan From glynn at gclements.plus.com Thu Apr 19 05:36:59 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Apr 19 05:37:07 2007 Subject: [GRASS-dev] etc file finder, take 2 In-Reply-To: References: <85349885-5408-480A-B8AD-63DE67DE2997@kyngchaos.com> <17958.17481.129183.667933@cerise.gclements.plus.com> Message-ID: <17958.58331.796932.128608@cerise.gclements.plus.com> William Kyngesburye wrote: > That all works nicely. thanks. > > For the const char * arg in G__find_etc() - should I also do that for > the public version of this, G_find_etc()? Yes. When passing a pointer as an argument, if the function doesn't modify the data, the "const" qualifier should be used. I've recently gone through libgis and added "const" wherever it is applicable, so if a libgis function *doesn't* use "const" for a pointer argument, then it modifies (or may modify) the value. Eventually, I'll get around to doing the same for other libraries. Note that certain structure types almost never have the "const" qualifier, even for "read" operations, e.g. the Categories, Colors, and Quant structures. This is because they contain fields which are initialised "on demand". E.g. a call to G_get_color() etc will eventually call G__organize_colors(), which initialises the lookup tables if they haven't already been initialised. -- Glynn Clements From hamish_nospam at yahoo.com Thu Apr 19 06:43:06 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Apr 19 06:43:18 2007 Subject: [GRASS-dev] any way to know color assigned to a cell? In-Reply-To: <1176924127.6624.13.camel@linuxmain.localhost> References: <1176924127.6624.13.camel@linuxmain.localhost> Message-ID: <20070419164306.4293b6fe.hamish_nospam@yahoo.com> Bob Covill wrote: > > If you are looking to duplicate d.histogram why not use r.stats? This > will output raster values with the percent or area which could be used > for plotting a histogram. If this did work it could be modified to > output the associated raster color along with the other values. Maybe > I am missing the point? In fact d.histogram calls system("r.stats -Cr{c|a}...."); to get the data it needs for its histogram. > On a related issues I have used a modified version of r.stats for a > while now to create equalized color bars for raster maps. You simply > calculate the distribution over a set number of color breaks, drop a > custom colortable over the breaks and apply with r.colors rules=. I've done this many times too, albeit by hand. Hamish From woklist at kyngchaos.com Thu Apr 19 06:44:02 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Thu Apr 19 06:44:08 2007 Subject: [GRASS-dev] new G_find_etc() and g.findetc Message-ID: <387A91D7-E046-4176-9587-88E81678628F@kyngchaos.com> Thanks to Glynn's expert help, I added a G_find_etc() function to libgis, and a companion g.findetc command. These are used to locate support files for C and script modules that may be in a directory not inside the GRASS installation ($GISBASE/ etc). They are intended for use by addon modules and scripts that are installed externally to the GRASS installation ($GISBASE). The search paths are specified in the env var GRASS_ADDON_ETC. If not found in those paths (or none are specified), it tries $GISBASE/etc. To use, instead of hardwiring the etc path to $GISBASE: sprintf(path, "%s/etc/somefile", G_gisbase()); search for it with: path = G_find_etc("somefile"); and make sure to test for null = it wasn't found. For scripts, use something like: fpath=`g.findetc file=somefile` Works to find both files and folders, and subfolders. The Mac OS X app startup has been updated to add the default global and user addon etc folders to GRASS_ADDON_ETC. This is a followup to my message from March: http://grass.itc.it/pipermail/grass-dev/2007-March/029975.html ----- William Kyngesburye http://www.kyngchaos.com/ [Trillian] What are you supposed to do WITH a maniacally depressed robot? [Marvin] You think you have problems? What are you supposed to do if you ARE a maniacally depressed robot? No, don't try and answer, I'm 50,000 times more intelligent than you and even I don't know the answer... - HitchHiker's Guide to the Galaxy From hamish_nospam at yahoo.com Thu Apr 19 06:54:15 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Apr 19 06:54:24 2007 Subject: [GRASS-dev] etc file finder, take 2 In-Reply-To: <17958.17481.129183.667933@cerise.gclements.plus.com> References: <85349885-5408-480A-B8AD-63DE67DE2997@kyngchaos.com> <17958.17481.129183.667933@cerise.gclements.plus.com> Message-ID: <20070419165415.69444cb1.hamish_nospam@yahoo.com> Glynn Clements wrote: > use GPATH_MAX as the size of the path buffer (I've > been replacing various random constants with that value as I find > them; also for GNAME_MAX and GMAPSET_MAX).. more of a comment than a question- "char input_map[GNAME_MAX];" is often used to hold input=map@mapset name, when the array often should be able to hold "GNAME_MAX + @ + GMAPSET_MAX + \0" = 514 chars. GNAME_MAX is long enough (256, gis.h) that map@mapset should rarely exceed that, but it's something to look out for. Perhaps gis.h should also have G_FULLYQUALIFIED_MAX ? Hamish From hamish_nospam at yahoo.com Thu Apr 19 07:19:35 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Apr 19 07:19:39 2007 Subject: [GRASS-dev] new G_find_etc() and g.findetc In-Reply-To: <387A91D7-E046-4176-9587-88E81678628F@kyngchaos.com> References: <387A91D7-E046-4176-9587-88E81678628F@kyngchaos.com> Message-ID: <20070419171935.50b296a0.hamish_nospam@yahoo.com> William Kyngesburye wrote: > Thanks to Glynn's expert help, I added a G_find_etc() function to > libgis, and a companion g.findetc command. was there ever any resolution to the question of if etc/ should be renamed to something more appropriate, and more generally how to go about cleaning up the mix of stuff in there? (separate platform specific binary exe from static data files). Or are we happy with it as-is? Something to consider before locking in the module name. Hamish From hamish_nospam at yahoo.com Thu Apr 19 08:02:29 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Apr 19 08:03:26 2007 Subject: [GRASS-dev] [grass-code P][372] scritps for converting raster maps into GRASS 7 format, and back In-Reply-To: References: <20070418093838.B3A5F1953AAB@pyrosoma.intevation.org> Message-ID: <20070419180229.7e982695.hamish_nospam@yahoo.com> Paul Kelly wrote: > Could it be written in C so it is more cross-platform? There is a new > function G_copy_file() in CVS that can copy files on disk. There is > also the C rename() function. I am sure it could, I'm just a lot more comfortable moving files around in the shell. (mostly just ignorance of how to do it safely in C) Perhaps Python would be a better compromise? (assuming it will be required dependency for the GUI+1 anyway) > Although I still don't think I like the idea of changing the internal > raster format as I expect it will break lots of 3rd-party software > that reads GRASS raster files directly, and could make GRASS look bad > for changing things. E.g. thinking of the detailed discussion of the > raster format a year or two ago for JavaGrass which reads it directly > I think. Also even GDAL must be passed the path to the cellhd > directory to read a GRASS raster I think? Also might it not be worth > taking the opportunity to modernise the raster format further than > just re-arranging the files, and perhaps providing some kind of LGPL > library for developers of 3rd-party software to use to read GRASS > rasters (actually that already exists I think - isn't it what GDAL > uses? http://freegis.org/cgi-bin/viewcvs.cgi/libgrass/ but don't think > its used much.) Of course we should try to minimize the change. My beef with the current format is that it is hard to archive and copy maps easily, and is generally not cosmetically pleasing. As it is only dir structure changing it wouldn't so bad an update for the 3rd party authors to deal with. Sure we can and should help package a LGPL or MIT/X licensed reference implementation data reader for 3rd parties. Probably aim for GDAL/OGR first/only. I don't know enough about the nuts and bolts of the formats to know if this could be done cleanly without having to use any GPL code. Presumably the raster format could be done from CERL code (what about FP and NULL, is that pre-GPL grass?) but the vector format is surely GPL encumbered. Maybe Radim could be convinced to relicense any needed parts written by him as LGPL? If we contribute something new to GDAL I guess it should be MIT/X. But that is more of an issue for a whole new binary format, not just an internal rearrangement? see also gdal-1.4.1/frmts/grass/ [I should revisit r.(un)pack to be more like this r.convert script + .tar.gz instead of using r.*.mat. Shrug, I don't use that much- instead I just make a new mapset, g.copy map@other,map then tar.gz the new mapset] > Sorry, just a few thoughts I've had for a while; wanted to get them > out on the list. Don't apologize -- I wrote the script to help get the ball rolling and garner discussion. But if it is to happen, the format change should happen as the first task of the GRASS 7 branch, IMO. Paolo: > Has the grass7 format already been agreed upon? No. Just ideas. see: http://grass.gdf-hannover.de/wiki/Replacement_raster_format Hamish From grass-codei at wald.intevation.org Thu Apr 19 08:15:59 2007 From: grass-codei at wald.intevation.org (grass-codei@wald.intevation.org) Date: Thu Apr 19 08:16:02 2007 Subject: [GRASS-dev] [grass-code I][373] NVIZ: max res ppm fails if pwd is empty Message-ID: <20070419061559.0C7BF18565B7@pyrosoma.intevation.org> code I item #373, was opened at 2007-04-19 18:15 Status: Open Priority: 2 Submitted By: Hamish Bowman (hamish) Assigned to: Nobody (None) Summary: NVIZ: max res ppm fails if pwd is empty Issue type: module bug Issue status: None GRASS version: 6.2.1 GRASS component: NVIZ Operating system: Linux Operating system version: debian sarge GRASS CVS checkout date, if applies (YYMMDD): 070402 Initial Comment: Hi, In NVIZ if you try and do File->Save Image As->Max res PPM when nviz was started in an new & empty dir you get this tcl error: no files matched glob pattern "*" no files matched glob pattern "*" while executing "glob -directory $cur_dir *" (procedure "refresh_file_browser" line 10) invoked from within "refresh_file_browser $w" (procedure "create_file_browser" line 91) invoked from within "create_file_browser .file_browser 1" invoked from within ".top.menu.file.m.img invoke active" ("uplevel" body line 1) invoked from within "uplevel #0 [list $w invoke active]" (procedure "tkMenuInvoke" line 47) invoked from within "tkMenuInvoke .top.menu.file.m.img 1 " (command bound to event) then it takes you to the file picker window. Hamish ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=373&group_id=21 From neteler at itc.it Thu Apr 19 09:53:21 2007 From: neteler at itc.it (Markus Neteler) Date: Thu Apr 19 09:57:53 2007 Subject: [GRASS-dev] any way to know color assigned to a cell? In-Reply-To: <1176922969.6624.2.camel@linuxmain.localhost> References: <17950.48109.88914.169521@cerise.gclements.plus.com> <20070419015116.761a4e3e.hamish_nospam@yahoo.com> <1176905102.12206.2.camel@linuxmain.localhost> <17958.17698.218980.703526@cerise.gclements.plus.com> <1176922969.6624.2.camel@linuxmain.localhost> Message-ID: <46271FF1.1070209@itc.it> Bob Covill wrote on 04/18/2007 09:02 PM: > On Wed, 2007-04-18 at 17:19 +0100, Glynn Clements wrote: > >> Bob Covill wrote: >> >> >>>>>> Yeah; we could probably do with a "r.what.colors" module. >>>>>> >>>> Michael: >>>> >>>>> I was contemplating a wxPython histograming module, like the TclTk >>>>> profiling module, and liked the option in d.histogram of being able to >>>>> use the color table for the histogram colors. But this seems like a >>>>> pretty intensive batch of calculations to do it. >>>>> >>>> you could try "r.profile -c" with a profile which starts and stops at >>>> the cell center (length=0). Also it should be very simple to add a flag >>>> just like "r.profile -c" to r.what, if that helps. >>>> >>> I have a version of r.what that I modified to optionally output RGB >>> color. If interested I could commit to CVS? >>> > I have committed the change to r.what. It now has a "-r" flag (-c was > taken) that will output the RGB for the selected point. > I didn't follow this in detail, but with this new -r flag, what is r.what.color providing? Is there a need to keep it? Markus (who always has an eye on too similar modules) ------------------ ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler ITC -> since 1 March 2007 Fondazione Bruno Kessler ------------------ From Agustin.Diez at uv.es Thu Apr 19 15:24:59 2007 From: Agustin.Diez at uv.es (Agustin Diez Castillo) Date: Thu Apr 19 15:25:48 2007 Subject: [GRASS-dev] nviz crashes on MacOSX Message-ID: <31007F5B-80E4-435B-BBDB-599CE13B0C48@uv.es> After compiling and installing latest cvs following William's readme, I got this error when trying nviz (itt works fine when using his binaries): Date/Time: 2007-04-19 13:10:33.116 +0200 OS Version: 10.4.9 (Build 8P2137) Report Version: 4 Command: nviz Path: /Applications/GRASS-6.3.app/Contents/Resources/etc/nviz2.2/nviz Parent: wish8.4 [15392] Version: ??? (???) PID: 15397 Thread: 0 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x6e614320 Thread 0 Crashed: 0 libX11.6.dylib 0x005dacd2 XQueryExtension + 51 1 libGL.1.dylib 0x005655f3 glXQueryExtension + 62 2 nviz 0x00016aa8 Togl_CreateWindow + 79 3 com.tcltk.tklibrary 0x9ad55131 Tk_MakeWindowExist + 120 4 nviz 0x00016992 Togl_Cmd + 1194 5 com.tcltk.tcllibrary 0x9ac5416f TclInvokeStringCommand + 121 6 com.tcltk.tcllibrary 0x9ac568e1 TclEvalObjvInternal + 733 7 com.tcltk.tcllibrary 0x9ac7965a TclExecuteByteCode + 3101 8 com.tcltk.tcllibrary 0x9ac7e442 TclCompEvalObj + 279 9 com.tcltk.tcllibrary 0x9aca5261 TclObjInterpProc + 524 10 com.tcltk.tcllibrary 0x9ac568e1 TclEvalObjvInternal + 733 11 com.tcltk.tcllibrary 0x9ac56be8 Tcl_EvalEx + 488 12 com.tcltk.tcllibrary 0x9ac94930 Tcl_FSEvalFile + 400 13 com.tcltk.tcllibrary 0x9ac94a14 Tcl_EvalFile + 47 14 com.tcltk.tklibrary 0x9ad2b291 Tk_MainEx + 835 15 nviz 0x0001517a main + 126 16 nviz 0x000023aa _start + 216 17 nviz 0x000022d1 start + 41 Thread 1: 0 libSystem.B.dylib 0x9001a0ec select + 12 1 libSystem.B.dylib 0x90024147 _pthread_body + 84 Thread 0 crashed with X86 Thread State (32-bit): eax: 0x6e614328 ebx: 0x005655c3 ecx: 0x00016a59 edx: 0x6e614320 edi: 0xbfffcce4 esi: 0x01cd5008 ebp: 0xbfffcbd8 esp: 0xbfffcba0 ss: 0x0000001f efl: 0x00010283 eip: 0x005dacd2 cs: 0x00000017 ds: 0x0000001f es: 0x0000001f fs: 0x00000000 gs: 0x00000037 Binary Images Description: 0x1000 - 0x26fff nviz /Applications/GRASS-6.3.app/Contents/ Resources/etc/nviz2.2/nviz 0x34000 - 0x35fff libgrass_bitmap.dylib /Applications/ GRASS-6.3.app/Contents/Resources/lib/libgrass_bitmap.dylib 0x39000 - 0x39fff libgrass_linkm.dylib /Applications/ GRASS-6.3.app/Contents/Resources/lib/libgrass_linkm.dylib 0x3d000 - 0x3efff libgrass_form.dylib /Applications/ GRASS-6.3.app/Contents/Resources/lib/libgrass_form.dylib 0x70000 - 0xc9fff libgrass_ogsf.dylib /Applications/ GRASS-6.3.app/Contents/Resources/lib/libgrass_ogsf.dylib 0xe0000 - 0xe5fff libgrass_datetime.dylib /Applications/ GRASS-6.3.app/Contents/Resources/lib/libgrass_datetime.dylib 0xea000 - 0xedfff libgrass_sites.dylib /Applications/ GRASS-6.3.app/Contents/Resources/lib/libgrass_sites.dylib 0xf2000 - 0xf6fff libgrass_dbmiclient.dylib /Applications/ GRASS-6.3.app/Contents/Resources/lib/libgrass_dbmiclient.dylib 0xfd000 - 0xfdfff com.kyngchaos.UnixImageIO 1.0.12 (UnixImageIO 1.0.13) /Library/Frameworks/UnixImageIO.framework/ Versions/A/UnixImageIO 0x205000 - 0x21efff libgrass_g3d.dylib /Applications/ GRASS-6.3.app/Contents/Resources/lib/libgrass_g3d.dylib 0x228000 - 0x26bfff libgrass_gis.dylib /Applications/ GRASS-6.3.app/Contents/Resources/lib/libgrass_gis.dylib 0x281000 - 0x289fff libgrass_dbmibase.dylib /Applications/ GRASS-6.3.app/Contents/Resources/lib/libgrass_dbmibase.dylib 0x292000 - 0x2bffff libgrass_vect.dylib /Applications/ GRASS-6.3.app/Contents/Resources/lib/libgrass_vect.dylib 0x2cb000 - 0x2dffff libgrass_dgl.dylib /Applications/ GRASS-6.3.app/Contents/Resources/lib/libgrass_dgl.dylib 0x2e6000 - 0x2f6fff libgrass_dig2.dylib /Applications/ GRASS-6.3.app/Contents/Resources/lib/libgrass_dig2.dylib 0x2fd000 - 0x301fff libgrass_rtree.dylib /Applications/ GRASS-6.3.app/Contents/Resources/lib/libgrass_rtree.dylib 0x305000 - 0x309fff libSM.6.dylib /usr/X11R6/lib/libSM.6.dylib 0x30e000 - 0x31dfff libICE.6.dylib /usr/X11R6/lib/libICE.6.dylib 0x325000 - 0x333fff libXmu.6.dylib /usr/X11R6/lib/libXmu.6.dylib 0x33b000 - 0x343fff libXext.6.dylib /usr/X11R6/lib/libXext.6.dylib 0x34a000 - 0x34afff net.refractions.geos 3.0.0 (GEOS 3.0.0-rc4) / Library/Frameworks/GEOS.framework/Versions/3.0/GEOS 0x34d000 - 0x353fff libgeosc.dylib /Library/Frameworks/ GEOS.framework/Versions/3.0/Libraries/libgeosc.dylib 0x35f000 - 0x363fff libgif.dylib /Library/Frameworks/ UnixImageIO.framework/Versions/A/Libraries/libgif.dylib 0x4b0000 - 0x50bfff libGLU.1.dylib /usr/X11R6/lib/libGLU.1.dylib 0x536000 - 0x590fff libGL.1.dylib /usr/X11R6/lib/libGL.1.dylib 0x5c4000 - 0x681fff libX11.6.dylib /usr/X11R6/lib/libX11.6.dylib 0x6a9000 - 0x6d5fff org.maptools.proj 4.5.0 (PROJ 4.5.0-4) / Library/Frameworks/PROJ.framework/Versions/4.5/PROJ 0x6e1000 - 0x72bfff org.sqlite.sqlite3 3.3.14 (SQLite3 3.3.14-1) /Library/Frameworks/SQLite3.framework/Versions/3.3/SQLite3 0x738000 - 0x751fff libjpeg.dylib /Library/Frameworks/ UnixImageIO.framework/Versions/A/Libraries/libjpeg.dylib 0x757000 - 0x78bfff libjasper.dylib /Library/Frameworks/ UnixImageIO.framework/Versions/A/Libraries/libjasper.dylib 0x79e000 - 0x7b8fff libpng.dylib /Library/Frameworks/ UnixImageIO.framework/Versions/A/Libraries/libpng.dylib 0x1008000 - 0x12f7fff org.gdal.gdal 1.4.1 (GDAL 1.4.1-1) /Library/ Frameworks/GDAL.framework/Versions/1.4/GDAL 0x14b8000 - 0x16d1fff Xerces /Library/Frameworks/Xerces.framework/ Versions/A/Xerces 0x1919000 - 0x19d1fff libgeos.dylib /Library/Frameworks/ GEOS.framework/Versions/3.0/Libraries/libgeos.dylib 0x1b0a000 - 0x1bb0fff libXpm.dylib /Library/Frameworks/ UnixImageIO.framework/Versions/A/Libraries/libXpm.dylib 0x1bcc000 - 0x1c18fff libtiff.dylib /Library/Frameworks/ UnixImageIO.framework/Versions/A/Libraries/libtiff.dylib 0x1c23000 - 0x1c5cfff libXt.6.dylib /usr/X11R6/lib/libXt.6.dylib 0x8fe00000 - 0x8fe4afff dyld 46.12 /usr/lib/dyld 0x90000000 - 0x90172fff libSystem.B.dylib /usr/lib/libSystem.B.dylib 0x901c2000 - 0x901c4fff libmathCommon.A.dylib /usr/lib/system/ libmathCommon.A.dylib 0x901c6000 - 0x90203fff com.apple.CoreText 1.1.2 (???) /System/ Library/Frameworks/ApplicationServices.framework/Versions/A/ Frameworks/CoreText.framework/Versions/A/CoreText 0x9022a000 - 0x90300fff ATS /System/Library/Frameworks/ ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/ Versions/A/ATS 0x90320000 - 0x90775fff com.apple.CoreGraphics 1.258.61 (???) /System/ Library/Frameworks/ApplicationServices.framework/Versions/A/ Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics 0x9080c000 - 0x908d4fff com.apple.CoreFoundation 6.4.7 (368.28) / System/Library/Frameworks/CoreFoundation.framework/Versions/A/ CoreFoundation 0x90912000 - 0x90912fff com.apple.CoreServices 10.4 (???) /System/ Library/Frameworks/CoreServices.framework/Versions/A/CoreServices 0x90914000 - 0x90a07fff libicucore.A.dylib /usr/lib/libicucore.A.dylib 0x90a57000 - 0x90ad6fff libobjc.A.dylib /usr/lib/libobjc.A.dylib 0x90aff000 - 0x90b63fff libstdc++.6.dylib /usr/lib/libstdc++.6.dylib 0x90bd2000 - 0x90bd9fff libgcc_s.1.dylib /usr/lib/libgcc_s.1.dylib 0x90bde000 - 0x90c51fff com.apple.framework.IOKit 1.4.6 (???) /System/ Library/Frameworks/IOKit.framework/Versions/A/IOKit 0x90c66000 - 0x90c78fff libauto.dylib /usr/lib/libauto.dylib 0x90c7e000 - 0x90f24fff com.apple.CoreServices.CarbonCore 682.18 / System/Library/Frameworks/CoreServices.framework/Versions/A/ Frameworks/CarbonCore.framework/Versions/A/CarbonCore 0x90f67000 - 0x90fcffff com.apple.CoreServices.OSServices 4.1 /System/ Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/ OSServices.framework/Versions/A/OSServices 0x91008000 - 0x91046fff com.apple.CFNetwork 129.20 /System/Library/ Frameworks/CoreServices.framework/Versions/A/Frameworks/ CFNetwork.framework/Versions/A/CFNetwork 0x91059000 - 0x91069fff com.apple.WebServices 1.1.3 (1.1.0) /System/ Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/ WebServicesCore.framework/Versions/A/WebServicesCore 0x91074000 - 0x910f3fff com.apple.SearchKit 1.0.5 /System/Library/ Frameworks/CoreServices.framework/Versions/A/Frameworks/ SearchKit.framework/Versions/A/SearchKit 0x9112d000 - 0x9114bfff com.apple.Metadata 10.4.4 (121.36) /System/ Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/ Metadata.framework/Versions/A/Metadata 0x91157000 - 0x91165fff libz.1.dylib /usr/lib/libz.1.dylib 0x91168000 - 0x91307fff com.apple.security 4.5.2 (29774) /System/ Library/Frameworks/Security.framework/Versions/A/Security 0x91405000 - 0x9140dfff com.apple.DiskArbitration 2.1.1 /System/ Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration 0x91414000 - 0x9143afff com.apple.SystemConfiguration 1.8.6 /System/ Library/Frameworks/SystemConfiguration.framework/Versions/A/ SystemConfiguration 0x9144c000 - 0x91453fff libbsm.dylib /usr/lib/libbsm.dylib 0x91457000 - 0x914cdfff com.apple.audio.CoreAudio 3.0.4 /System/ Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio 0x9151e000 - 0x9151efff com.apple.ApplicationServices 10.4 (???) / System/Library/Frameworks/ApplicationServices.framework/Versions/A/ ApplicationServices 0x91520000 - 0x9154cfff com.apple.AE 314 (313) /System/Library/ Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ AE.framework/Versions/A/AE 0x9155f000 - 0x91633fff com.apple.ColorSync 4.4.9 /System/Library/ Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ ColorSync.framework/Versions/A/ColorSync 0x9166e000 - 0x916e1fff com.apple.print.framework.PrintCore 4.6 (177.13) /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore 0x9170f000 - 0x917b8fff com.apple.QD 3.10.24 (???) /System/Library/ Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ QD.framework/Versions/A/QD 0x917de000 - 0x91829fff com.apple.HIServices 1.5.2 (???) /System/ Library/Frameworks/ApplicationServices.framework/Versions/A/ Frameworks/HIServices.framework/Versions/A/HIServices 0x91848000 - 0x9185efff com.apple.LangAnalysis 1.6.3 /System/Library/ Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ LangAnalysis.framework/Versions/A/LangAnalysis 0x9186a000 - 0x91885fff com.apple.FindByContent 1.5 /System/Library/ Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ FindByContent.framework/Versions/A/FindByContent 0x91890000 - 0x918cdfff com.apple.LaunchServices 182 /System/Library/ Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ LaunchServices.framework/Versions/A/LaunchServices 0x918e1000 - 0x918edfff com.apple.speech.synthesis.framework 3.5 / System/Library/Frameworks/ApplicationServices.framework/Versions/A/ Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis 0x918f4000 - 0x91933fff com.apple.ImageIO.framework 1.5.4 /System/ Library/Frameworks/ApplicationServices.framework/Versions/A/ Frameworks/ImageIO.framework/Versions/A/ImageIO 0x91946000 - 0x919f8fff libcrypto.0.9.7.dylib /usr/lib/libcrypto. 0.9.7.dylib 0x91a3e000 - 0x91a54fff libcups.2.dylib /usr/lib/libcups.2.dylib 0x91a59000 - 0x91a77fff libJPEG.dylib /System/Library/Frameworks/ ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/ Versions/A/Resources/libJPEG.dylib 0x91a7c000 - 0x91adbfff libJP2.dylib /System/Library/Frameworks/ ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/ Versions/A/Resources/libJP2.dylib 0x91aed000 - 0x91af1fff libGIF.dylib /System/Library/Frameworks/ ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/ Versions/A/Resources/libGIF.dylib 0x91af3000 - 0x91b77fff libRaw.dylib /System/Library/Frameworks/ ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/ Versions/A/Resources/libRaw.dylib 0x91b7b000 - 0x91bb8fff libTIFF.dylib /System/Library/Frameworks/ ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/ Versions/A/Resources/libTIFF.dylib 0x91bbe000 - 0x91bd8fff libPng.dylib /System/Library/Frameworks/ ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/ Versions/A/Resources/libPng.dylib 0x91bdd000 - 0x91bdffff libRadiance.dylib /System/Library/Frameworks/ ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/ Versions/A/Resources/libRadiance.dylib 0x91be1000 - 0x91cbffff libxml2.2.dylib /usr/lib/libxml2.2.dylib 0x91cdc000 - 0x91cdcfff com.apple.Accelerate 1.3.1 (Accelerate 1.3.1) /System/Library/Frameworks/Accelerate.framework/Versions/A/ Accelerate 0x91cde000 - 0x91d6cfff com.apple.vImage 2.5 /System/Library/ Frameworks/Accelerate.framework/Versions/A/Frameworks/ vImage.framework/Versions/A/vImage 0x91d73000 - 0x91d73fff com.apple.Accelerate.vecLib 3.3.1 (vecLib 3.3.1) /System/Library/Frameworks/Accelerate.framework/Versions/A/ Frameworks/vecLib.framework/Versions/A/vecLib 0x91d75000 - 0x91dcefff libvMisc.dylib /System/Library/Frameworks/ Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/ A/libvMisc.dylib 0x91dd7000 - 0x91dfbfff libvDSP.dylib /System/Library/Frameworks/ Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/ A/libvDSP.dylib 0x91e03000 - 0x9220cfff libBLAS.dylib /System/Library/Frameworks/ Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/ A/libBLAS.dylib 0x92246000 - 0x925fafff libLAPACK.dylib /System/Library/Frameworks/ Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/ A/libLAPACK.dylib 0x92627000 - 0x92714fff libiconv.2.dylib /usr/lib/libiconv.2.dylib 0x92716000 - 0x92793fff com.apple.DesktopServices 1.3.6 /System/ Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/ DesktopServicesPriv 0x927d4000 - 0x92a04fff com.apple.Foundation 6.4.8 (567.29) /System/ Library/Frameworks/Foundation.framework/Versions/C/Foundation 0x92b1e000 - 0x92b35fff libGL.dylib /System/Library/Frameworks/ OpenGL.framework/Versions/A/Libraries/libGL.dylib 0x92b40000 - 0x92b98fff libGLU.dylib /System/Library/Frameworks/ OpenGL.framework/Versions/A/Libraries/libGLU.dylib 0x92bac000 - 0x92bacfff com.apple.Carbon 10.4 (???) /System/Library/ Frameworks/Carbon.framework/Versions/A/Carbon 0x92bae000 - 0x92bbefff com.apple.ImageCapture 3.0.4 /System/Library/ Frameworks/Carbon.framework/Versions/A/Frameworks/ ImageCapture.framework/Versions/A/ImageCapture 0x92bcd000 - 0x92bd5fff com.apple.speech.recognition.framework 3.6 / System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ SpeechRecognition.framework/Versions/A/SpeechRecognition 0x92bdb000 - 0x92be1fff com.apple.securityhi 2.0.1 (24742) /System/ Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ SecurityHI.framework/Versions/A/SecurityHI 0x92be7000 - 0x92c78fff com.apple.ink.framework 101.2.1 (71) /System/ Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ Ink.framework/Versions/A/Ink 0x92c8c000 - 0x92c90fff com.apple.help 1.0.3 (32.1) /System/Library/ Frameworks/Carbon.framework/Versions/A/Frameworks/Help.framework/ Versions/A/Help 0x92c93000 - 0x92cb1fff com.apple.openscripting 1.2.5 (???) /System/ Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ OpenScripting.framework/Versions/A/OpenScripting 0x92cc3000 - 0x92cc9fff com.apple.print.framework.Print 5.2 (192.4) / System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ Print.framework/Versions/A/Print 0x92ccf000 - 0x92d32fff com.apple.htmlrendering 66.1 (1.1.3) /System/ Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ HTMLRendering.framework/Versions/A/HTMLRendering 0x92d59000 - 0x92d9afff com.apple.NavigationServices 3.4.4 (3.4.3) / System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ NavigationServices.framework/Versions/A/NavigationServices 0x92dc1000 - 0x92dcffff com.apple.audio.SoundManager 3.9.1 /System/ Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ CarbonSound.framework/Versions/A/CarbonSound 0x92dd6000 - 0x92ddbfff com.apple.CommonPanels 1.2.3 (73) /System/ Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ CommonPanels.framework/Versions/A/CommonPanels 0x92de0000 - 0x930d5fff com.apple.HIToolbox 1.4.9 (???) /System/ Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ HIToolbox.framework/Versions/A/HIToolbox 0x931db000 - 0x931e6fff com.apple.opengl 1.4.16 /System/Library/ Frameworks/OpenGL.framework/Versions/A/OpenGL 0x94293000 - 0x942a2fff libCGATS.A.dylib /System/Library/Frameworks/ ApplicationServices.framework/Versions/A/Frameworks/ CoreGraphics.framework/Versions/A/Resources/libCGATS.A.dylib 0x942a9000 - 0x942b4fff libCSync.A.dylib /System/Library/Frameworks/ ApplicationServices.framework/Versions/A/Frameworks/ CoreGraphics.framework/Versions/A/Resources/libCSync.A.dylib 0x94300000 - 0x9431afff libRIP.A.dylib /System/Library/Frameworks/ ApplicationServices.framework/Versions/A/Frameworks/ CoreGraphics.framework/Versions/A/Resources/libRIP.A.dylib 0x9496d000 - 0x94992fff libssl.0.9.7.dylib /usr/lib/libssl.0.9.7.dylib 0x97849000 - 0x97887fff libiodbc.2.dylib /usr/lib/libiodbc.2.dylib 0x97894000 - 0x9789dfff libiodbcinst.2.dylib /usr/lib/libiodbcinst. 2.dylib 0x9a785000 - 0x9a790fff libXplugin.1.dylib /usr/lib/libXplugin.1.dylib 0x9ac47000 - 0x9acc5fff com.tcltk.tcllibrary 8.4.7 a /System/Library/ Frameworks/Tcl.framework/Versions/8.4/Tcl 0x9acdf000 - 0x9ad8efff com.tcltk.tklibrary 8.4.7 a /System/Library/ Frameworks/Tk.framework/Versions/8.4/Tk Model: iMac5,1, BootROM IM51.0090.B03, 2 processors, Intel Core 2 Duo, 2 GHz, 2 GB Graphics: ATI Radeon X1600, ATY,RadeonX1600, PCIe, 128 MB Memory Module: BANK 0/DIMM0, 1 GB, DDR2 SDRAM, 667 MHz Memory Module: BANK 1/DIMM1, 1 GB, DDR2 SDRAM, 667 MHz AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x87), Broadcom BCM43xx 1.0 (4.80.79.1) Bluetooth: Version 1.7.14f14, 2 service, 1 devices, 1 incoming serial ports Network Service: Built-in Ethernet, Ethernet, en0 Network Service: Parallels Host-Guest, Ethernet, en2 Network Service: Parallels NAT, Ethernet, en3 Serial ATA Device: ST3160812AS Q, 149.05 GB Parallel ATA Device: MATSHITADVD-R UJ-85J USB Device: Built-in iSight, Micron, Up to 480 Mb/sec, 500 mA USB Device: USB HUB, Up to 12 Mb/sec, 500 mA USB Device: Bluetooth HCI, Up to 12 Mb/sec, 500 mA USB Device: IR Receiver, Apple Computer, Inc., Up to 12 Mb/sec, 500 mA USB Device: Hub in Apple Pro Keyboard, Mitsumi Electric, Up to 12 Mb/ sec, 500 mA USB Device: USB-PS/2 Optical Mouse, Logitech, Up to 1.5 Mb/sec, 100 mA USB Device: HASP 2.17, AKS, Up to 1.5 Mb/sec, 100 mA USB Device: Apple Pro Keyboard, Mitsumi Electric, Up to 12 Mb/sec, 250 mA FireWire Device: LaCie Hard Drive FireWire+, LaCie Group SA, Up to 400 Mb/sec FireWire Device: LaCie d2 Extreme LUN 0, LaCie Group SA, Up to 400 Mb/ sec grass-dev@grass.itc.it From JGillette at rfmd.com Thu Apr 19 16:11:08 2007 From: JGillette at rfmd.com (John Gillette) Date: Thu Apr 19 16:11:11 2007 Subject: [GRASS-dev] __BEGIN_DECLS Message-ID: In lib/vector/dglib/graph.h there is __BEGIN_DECLS (near top) and __END_DECLS (at bottom). Are these needed? What do they do? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070419/dfd6995f/attachment.html From peter.loewe at gmx.de Thu Apr 19 16:14:37 2007 From: peter.loewe at gmx.de (peter.loewe@gmx.de) Date: Thu Apr 19 16:14:39 2007 Subject: [GRASS-dev] any way to know color assigned to a cell? In-Reply-To: <46271FF1.1070209@itc.it> References: <17950.48109.88914.169521@cerise.gclements.plus.com> <20070419015116.761a4e3e.hamish_nospam@yahoo.com> <1176905102.12206.2.camel@linuxmain.localhost> <17958.17698.218980.703526@cerise.gclements.plus.com> <1176922969.6624.2.camel@linuxmain.localhost> <46271FF1.1070209@itc.it> Message-ID: <20070419141437.181390@gmx.net> Including a "RGB"-flag into r.stats would still be a good thing. Right now, creating a vector polygon layer with a GRASSRGB-column out of a raster map + colortable needs some manual input or custom shell scripting to set up tthe RGBCOLOR values. Having a RGB-functionality in r.stats would make this (and other tasks) easier. Peter >Bob Covill wrote on 04/18/2007 09:02 PM: >> On Wed, 2007-04-18 at 17:19 +0100, Glynn Clements wrote: >> >>> Bob Covill wrote: >>> >>> >>>>>>> Yeah; we could probably do with a "r.what.colors" module. >>>>>>> >>>>> Michael: >>>>> >>>>>> I was contemplating a wxPython histograming module, like the TclTk >>>>>> profiling module, and liked the option in d.histogram of being able >to >>>>>> use the color table for the histogram colors. But this seems like a >>>>>> pretty intensive batch of calculations to do it. >>>>>> >>>>> you could try "r.profile -c" with a profile which starts and stops at >>>>> the cell center (length=0). Also it should be very simple to add a >flag >>>>> just like "r.profile -c" to r.what, if that helps. >>>>> >>>> I have a version of r.what that I modified to optionally output RGB >>>> color. If interested I could commit to CVS? >>>> >> I have committed the change to r.what. It now has a "-r" flag (-c was >> taken) that will output the RGB for the selected point. >> > >I didn't follow this in detail, but with this new -r flag, what is >r.what.color providing? >Is there a need to keep it? > >Markus (who always has an eye on too similar modules) -- Dr. Peter L?we Diplom-Geograph "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail From michael.barton at asu.edu Thu Apr 19 16:45:02 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Apr 19 16:45:10 2007 Subject: [GRASS-dev] [grass-code P][372] scritps for converting raster maps into GRASS 7 format, and back In-Reply-To: <20070419180229.7e982695.hamish_nospam@yahoo.com> Message-ID: On 4/18/07 11:02 PM, "Hamish" wrote: > > Perhaps Python would be a better compromise? (assuming it will be > required dependency for the GUI+1 anyway) > Unless there is a strong movement in another direction, this will be the case. The GUI development is moving along so well that we can drop TclTk completely if we can get a wxPython equivalent for NVIZ. This is a lot of work, of course, but wxPython development has moved at surprising speed once we really started working on it. There is built in support for an OGL canvas within wxPython once pyOpenGL is installed. If Python becomes a required dependency, it opens up a lot of potential for very sophisticated scripting. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From woklist at kyngchaos.com Thu Apr 19 17:15:10 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Thu Apr 19 17:15:17 2007 Subject: [GRASS-dev] nviz crashes on MacOSX In-Reply-To: <31007F5B-80E4-435B-BBDB-599CE13B0C48@uv.es> References: <31007F5B-80E4-435B-BBDB-599CE13B0C48@uv.es> Message-ID: <0508BA5C-4501-4667-AC6D-7B0034CFF639@kyngchaos.com> Looks like for some reason it's using the system TclTk instead of the one bundled in the GRASS app package. Make sure your X11 build of TclTk got bundled in the app package. It's possible the automatic detection of the TclTk prefix isn't working for the bundling stage, like we discussed offlist, and you would have to set TCLTKPREFIX before building GRASS. If you used the universal tcltk build instructions in the readme, then that would be / usr/local/tcltk. On Apr 19, 2007, at 8:24 AM, Agustin Diez Castillo wrote: > After compiling and installing latest cvs following William's > readme, I got this error when trying nviz (itt works fine when > using his binaries): > Date/Time: 2007-04-19 13:10:33.116 +0200 > OS Version: 10.4.9 (Build 8P2137) > Report Version: 4 > > Command: nviz > Path: /Applications/GRASS-6.3.app/Contents/Resources/etc/nviz2.2/ > nviz > Parent: wish8.4 [15392] > > Version: ??? (???) > > PID: 15397 > Thread: 0 > > Exception: EXC_BAD_ACCESS (0x0001) > Codes: KERN_INVALID_ADDRESS (0x0001) at 0x6e614320 > > Thread 0 Crashed: > 0 libX11.6.dylib 0x005dacd2 XQueryExtension + 51 ... > 0x9ac47000 - 0x9acc5fff com.tcltk.tcllibrary 8.4.7 a /System/ > Library/Frameworks/Tcl.framework/Versions/8.4/Tcl > 0x9acdf000 - 0x9ad8efff com.tcltk.tklibrary 8.4.7 a /System/Library/ > Frameworks/Tk.framework/Versions/8.4/Tk > ----- William Kyngesburye http://www.kyngchaos.com/ "Oh, look, I seem to have fallen down a deep, dark hole. Now what does that remind me of? Ah, yes - life." - Marvin From epatton at nrcan.gc.ca Thu Apr 19 17:28:38 2007 From: epatton at nrcan.gc.ca (Patton, Eric) Date: Thu Apr 19 17:28:42 2007 Subject: [GRASS-dev] Errors applying color rules and -g flags in r.colors Message-ID: I'm having trouble getting the new r.color -g flag to do anything. Or, more correctly, maybe it's working properly, but I just can't tell if it's doing anything or not. Running r.colors -g produces a blank display in gis.m on an ordinary raster dataset: ~ >g.region rast=IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT ~ > ~ >r.colors -g map=IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT color=rainbow Color table for [IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT] set to rainbow ~ > Am I using the flag correctly, or does it also require the use of the 'rules' parameter? r.colors -ge on the input raster also fails to produce anything on the gis.m map window. r.colors -e works nicely on its own. I'm also getting errors applying several of the new-ish predefined color tables. I've ran a script to apply each color table in turn to the same input raster. Output pasted below (warning, it's long): for COLOR in `r.colors -l` ; do echo -e "\n\nApplying color rule $COLOR to input raster...\n" r.colors map=IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT color=$COLOR done Applying color rule aspect to input raster... Color table for [IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT] set to aspect Applying color rule aspectcolr to input raster... ERROR: bad rule (percentage not in range 0-100): 180 cyan Applying color rule bcyr to input raster... Color table for [IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT] set to bcyr Applying color rule byg to input raster... Color table for [IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT] set to byg Applying color rule byr to input raster... Color table for [IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT] set to byr Applying color rule curvature to input raster... ERROR: bad rule (percentage not in range 0-100): -0.01 blue Applying color rule differences to input raster... Color table for [IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT] set to differences Applying color rule elevation to input raster... Color table for [IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT] set to elevation Applying color rule etopo2 to input raster... ERROR: bad rule (percentage not in range 0-100): -11000 0 0 0 Applying color rule evi to input raster... ERROR: bad rule (percentage not in range 0-100): -1.0000 white Applying color rule grey to input raster... Color table for [IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT] set to grey Applying color rule gyr to input raster... Color table for [IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT] set to gyr Applying color rule ndvi to input raster... ERROR: bad rule (percentage not in range 0-100): -1.0000 white Applying color rule population to input raster... ERROR: bad rule (percentage not in range 0-100): 1000 255 218 164 Applying color rule rainbow to input raster... Color table for [IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT] set to rainbow Applying color rule ramp to input raster... Color table for [IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT] set to ramp Applying color rule ryb to input raster... Color table for [IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT] set to ryb Applying color rule ryg to input raster... Color table for [IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT] set to ryg Applying color rule slope to input raster... Color table for [IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT] set to slope Applying color rule srtm to input raster... ERROR: bad rule (percentage not in range 0-100): -500 0 0 10 Applying color rule terrain to input raster... ERROR: bad rule (percentage not in range 0-100): -11000 0 0 0 Applying color rule wave to input raster... Color table for [IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT] set to wave So in sum, there are problems applying the aspectcolr, curvature, etopo2, evi, ndvi, population, srtm, and terrain color tables. It seems that r.colors will only accept a percentage color range and not a standard Grass color name or RGB value. ~ Eric. From woklist at kyngchaos.com Thu Apr 19 17:33:48 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Thu Apr 19 17:33:53 2007 Subject: [GRASS-dev] new G_find_etc() and g.findetc In-Reply-To: <20070419171935.50b296a0.hamish_nospam@yahoo.com> References: <387A91D7-E046-4176-9587-88E81678628F@kyngchaos.com> <20070419171935.50b296a0.hamish_nospam@yahoo.com> Message-ID: <66F740B5-F727-4FD5-8A73-18F4022F5657@kyngchaos.com> On Apr 19, 2007, at 12:19 AM, Hamish wrote: > William Kyngesburye wrote: >> Thanks to Glynn's expert help, I added a G_find_etc() function to >> libgis, and a companion g.findetc command. > > > was there ever any resolution to the question of if etc/ should be > renamed to something more appropriate, and more generally how to go > about cleaning up the mix of stuff in there? (separate platform > specific > binary exe from static data files). Or are we happy with it as-is? > > Something to consider before locking in the module name. > ...something I forgot to bring up... Yeah, it's a bit of a klunky name. Even if etc/ stays as-is, I'm open to suggestions of a better name for it. - find_file seems more appropriate, but that's taken to find mapset data files. - find_data makes some sense (unix software often refers to shared resources such as etc/ and share/ as data), but it could easily be confused with finding mapset data files. - find_resource? or find_rsrc? these are program resource data files we're looking for. ----- William Kyngesburye http://www.kyngchaos.com/ "Time is an illusion - lunchtime doubly so." - Ford Prefect From glynn at gclements.plus.com Thu Apr 19 17:35:08 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Apr 19 17:35:11 2007 Subject: [GRASS-dev] etc file finder, take 2 In-Reply-To: <20070419165415.69444cb1.hamish_nospam@yahoo.com> References: <85349885-5408-480A-B8AD-63DE67DE2997@kyngchaos.com> <17958.17481.129183.667933@cerise.gclements.plus.com> <20070419165415.69444cb1.hamish_nospam@yahoo.com> Message-ID: <17959.35884.147393.832979@cerise.gclements.plus.com> Hamish wrote: > > use GPATH_MAX as the size of the path buffer (I've > > been replacing various random constants with that value as I find > > them; also for GNAME_MAX and GMAPSET_MAX).. > > more of a comment than a question- > > "char input_map[GNAME_MAX];" is often used to hold input=map@mapset > name, when the array often should be able to hold "GNAME_MAX + @ + > GMAPSET_MAX + \0" = 514 chars. > > GNAME_MAX is long enough (256, gis.h) that map@mapset should rarely > exceed that, but it's something to look out for. > > Perhaps gis.h should also have G_FULLYQUALIFIED_MAX ? Who said that GNAME_MAX referred to the length of an *unqualified* name? It's just an arbitrary value used for array dimensions; nothing actually checks map names against that value. -- Glynn Clements From glynn at gclements.plus.com Thu Apr 19 17:38:16 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Apr 19 17:38:19 2007 Subject: [GRASS-dev] [grass-code I][373] NVIZ: max res ppm fails if pwd is empty In-Reply-To: <20070419061559.0C7BF18565B7@pyrosoma.intevation.org> References: <20070419061559.0C7BF18565B7@pyrosoma.intevation.org> Message-ID: <17959.36072.891869.879688@cerise.gclements.plus.com> grass-codei@wald.intevation.org wrote: > code I item #373, was opened at 2007-04-19 18:15 > Status: Open > Priority: 2 > Submitted By: Hamish Bowman (hamish) > Assigned to: Nobody (None) > Summary: NVIZ: max res ppm fails if pwd is empty > Issue type: module bug > Issue status: None > GRASS version: 6.2.1 > GRASS component: NVIZ > Operating system: Linux > Operating system version: debian sarge > GRASS CVS checkout date, if applies (YYMMDD): 070402 > > > Initial Comment: > Hi, > > In NVIZ if you try and do File->Save Image As->Max res PPM when nviz was started in an new & empty dir you get this tcl error: > > no files matched glob pattern "*" > no files matched glob pattern "*" > while executing > "glob -directory $cur_dir *" Add the -nocomplain switch to the glob command (refresh_file_browser, in visualization/nviz/scripts/fileBrowser.tcl). -- Glynn Clements From JGillette at rfmd.com Thu Apr 19 17:40:07 2007 From: JGillette at rfmd.com (John Gillette) Date: Thu Apr 19 17:40:10 2007 Subject: [GRASS-dev] __BEGIN_DECLS In-Reply-To: Message-ID: In cdefs.h, they are defined like so: /* C++ needs to know that types and declarations are C, not C++. */ #ifdef __cplusplus # define __BEGIN_DECLS extern "C" { # define __END_DECLS } #else # define __BEGIN_DECLS # define __END_DECLS #endif So standard C++ name de-mangling. Not needed, won't hurt. So I broke 2 rules: I posted in HTML (oops, Windows default) I wasted bandwidth on a question I really COULD find on the web. I'm sorry. John ________________________________ Subject: [GRASS-dev] __BEGIN_DECLS In lib/vector/dglib/graph.h there is __BEGIN_DECLS (near top) and __END_DECLS (at bottom). Are these needed? What do they do? John From glynn at gclements.plus.com Thu Apr 19 17:46:21 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Apr 19 17:46:24 2007 Subject: [GRASS-dev] nviz crashes on MacOSX In-Reply-To: <31007F5B-80E4-435B-BBDB-599CE13B0C48@uv.es> References: <31007F5B-80E4-435B-BBDB-599CE13B0C48@uv.es> Message-ID: <17959.36557.122042.632050@cerise.gclements.plus.com> Agustin Diez Castillo wrote: > After compiling and installing latest cvs following William's readme, > I got this error when trying nviz (itt works fine when using his > binaries): > Date/Time: 2007-04-19 13:10:33.116 +0200 > OS Version: 10.4.9 (Build 8P2137) > Report Version: 4 > > Command: nviz > Path: /Applications/GRASS-6.3.app/Contents/Resources/etc/nviz2.2/nviz > Parent: wish8.4 [15392] > > Version: ??? (???) > > PID: 15397 > Thread: 0 > > Exception: EXC_BAD_ACCESS (0x0001) > Codes: KERN_INVALID_ADDRESS (0x0001) at 0x6e614320 > > Thread 0 Crashed: > 0 libX11.6.dylib 0x005dacd2 XQueryExtension + 51 > 1 libGL.1.dylib 0x005655f3 glXQueryExtension + 62 > 2 nviz 0x00016aa8 Togl_CreateWindow + 79 Note that you are using X11 OpenGL (I think that William's binaries use native Mac OpenGL). You need to also be using X11 Tcl/Tk (not native Mac Tcl/Tk) for this to work. If you want to use the native Tcl/Tk, you need --with-opengl=mac (any of aqua, mac, osx, macosx, or agl will work). -- Glynn Clements From glynn at gclements.plus.com Thu Apr 19 17:50:55 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Apr 19 17:50:57 2007 Subject: [GRASS-dev] __BEGIN_DECLS In-Reply-To: References: Message-ID: <17959.36831.90681.29330@cerise.gclements.plus.com> John Gillette wrote: > In lib/vector/dglib/graph.h there is __BEGIN_DECLS (near top) and > __END_DECLS (at bottom). > > Are these needed? No. > What do they do? They are defined like so in type.h: #ifdef __cplusplus # define __BEGIN_DECLS extern "C" { # define __END_DECLS } #else # define __BEGIN_DECLS /* empty */ # define __END_DECLS /* empty */ #endif Essentially, they allow the header to be used in C++ code. As the rest of GRASS doesn't do this, there doesn't seem much point doing it in a few specific headers. -- Glynn Clements From glynn at gclements.plus.com Thu Apr 19 17:58:01 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Apr 19 17:58:04 2007 Subject: [GRASS-dev] [grass-code P][372] scritps for converting raster maps into GRASS 7 format, and back In-Reply-To: <20070419180229.7e982695.hamish_nospam@yahoo.com> References: <20070418093838.B3A5F1953AAB@pyrosoma.intevation.org> <20070419180229.7e982695.hamish_nospam@yahoo.com> Message-ID: <17959.37257.614633.921425@cerise.gclements.plus.com> Hamish wrote: > Sure we can and should help package a LGPL or MIT/X licensed reference > implementation data reader for 3rd parties. Probably aim for GDAL/OGR > first/only. I don't know enough about the nuts and bolts of the formats > to know if this could be done cleanly without having to use any GPL > code. Presumably the raster format could be done from CERL code (what > about FP and NULL, is that pre-GPL grass?) I think that FP/NULL are post-GPL. There have been several other enhancements more recently, e.g. allowing 64-bit offsets on all platforms, and allowing zlib compression for raster mapset. -- Glynn Clements From glynn at gclements.plus.com Thu Apr 19 18:08:48 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Apr 19 18:08:52 2007 Subject: [GRASS-dev] [grass-code P][372] scritps for converting raster maps into GRASS 7 format, and back In-Reply-To: References: <20070419180229.7e982695.hamish_nospam@yahoo.com> Message-ID: <17959.37904.135550.277212@cerise.gclements.plus.com> Michael Barton wrote: > > Perhaps Python would be a better compromise? (assuming it will be > > required dependency for the GUI+1 anyway) > > Unless there is a strong movement in another direction, this will be the > case. > > The GUI development is moving along so well that we can drop TclTk > completely if we can get a wxPython equivalent for NVIZ. This is a lot of > work, of course, but wxPython development has moved at surprising speed once > we really started working on it. There is built in support for an OGL canvas > within wxPython once pyOpenGL is installed. GLCanvas is part of wxPython itself: http://wxpython.wxcommunity.com/docs/api/wx.glcanvas.GLCanvas-class.html You shouldn't need pyOpenGL unless you're planning on making OpenGL calls from Python. The only parts of NVIZ which make OpenGL calls are Togl and do_zoom.c. NVIZ is just a UI; all of the actual work is done by the OGSF library. -- Glynn Clements From epatton at nrcan.gc.ca Thu Apr 19 18:19:43 2007 From: epatton at nrcan.gc.ca (Patton, Eric) Date: Thu Apr 19 18:20:56 2007 Subject: [GRASS-dev] RE: [GRASS-user] g.mlist newline separator request References: Message-ID: Well, as no one seems to have had an objection or comment, and I can confirm that it does indeed work, would it be possible for someone to commit Martin's patch to CVS? Thanks, ~ Eric. -----Original Message----- From: Martin Landa [mailto:landa.martin@gmail.com] Sent: Fri 4/13/2007 5:06 AM To: Patton, Eric Cc: grassuser@grass.itc.it Subject: Re: [GRASS-user] g.mlist newline separator request Hi, this patch should fix it. But I am not sure whether to commit it to CVS. Patch seems to be "ugly" for me, moreover I am not sure why printf fn was used in the script (?) Martin 2007/4/12, Patton, Eric : > I've noticed that g.mlist doesn't enter a newline after the last entry in a list, which used to be the case about a month ago: > > ~/coderepo >g.mlist pattern=Minas_Basin* > Minas_Basin_Jan16_2007_50m > Minas_Basin_Jan16_2007_50m_med3 > Minas_Basin_Jan16_2007_50m_med3_shade > Minas_Basin_Jan16_2007_50m_med3_shade_comb > Minas_Basin_Jan16_2007_50m_shade > Minas_Basin_Jan16_2007_50m_shade_comb~/coderepo > > > Consequently, any script that tries to get a count from g.mlist by piping to wc will get an incorrect count that will be off by one: > > > g.mlist pattern=Minas_Basin_Jan16_2007_50m | wc -l > 0 (Should be 1) > > g.mlist pattern=Minas_Basin* | wc -l > 5 (Should be 6) > > Would it be possible to get the final newline back? I have scripts that are broken now because a for loop never gets started when a check is done against the number of rasters matched: > > MATCHES=`g.mlist pattern=${PATTERN} | wc -l` > > # Abort if no matches are found. > if [ "$MATCHES" -eq 0 ] ; then > echo "$SCRIPT: No rasters matched the search pattern!" > exit 1 > fi > > > ~ Eric. > > _______________________________________________ > grassuser mailing list > grassuser@grass.itc.it > http://grass.itc.it/mailman/listinfo/grassuser > -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From michael.barton at asu.edu Thu Apr 19 18:25:25 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Apr 19 18:25:31 2007 Subject: [GRASS-dev] [grass-code P][372] scritps for converting raster maps into GRASS 7 format, and back In-Reply-To: <17959.37904.135550.277212@cerise.gclements.plus.com> Message-ID: When I tried the GLCanvas demo, it told me I needed to have pyOpenGL installed. If we don't really need this, it makes things MUCH easier by removing a group of additional dependencies. Michael On 4/19/07 9:08 AM, "Glynn Clements" wrote: > > Michael Barton wrote: > >>> Perhaps Python would be a better compromise? (assuming it will be >>> required dependency for the GUI+1 anyway) >> >> Unless there is a strong movement in another direction, this will be the >> case. >> >> The GUI development is moving along so well that we can drop TclTk >> completely if we can get a wxPython equivalent for NVIZ. This is a lot of >> work, of course, but wxPython development has moved at surprising speed once >> we really started working on it. There is built in support for an OGL canvas >> within wxPython once pyOpenGL is installed. > > GLCanvas is part of wxPython itself: > > http://wxpython.wxcommunity.com/docs/api/wx.glcanvas.GLCanvas-class.html > > You shouldn't need pyOpenGL unless you're planning on making OpenGL > calls from Python. The only parts of NVIZ which make OpenGL calls are > Togl and do_zoom.c. NVIZ is just a UI; all of the actual work is done > by the OGSF library. __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From landa.martin at gmail.com Thu Apr 19 18:27:37 2007 From: landa.martin at gmail.com (Martin Landa) Date: Thu Apr 19 18:27:39 2007 Subject: [GRASS-dev] Re: [GRASS-user] g.mlist newline separator request In-Reply-To: References: Message-ID: Done. 2007/4/19, Patton, Eric : > Well, as no one seems to have had an objection or comment, and I can confirm that it does indeed work, would it be possible for someone to commit Martin's patch to CVS? > > Thanks, > > ~ Eric. > > > -----Original Message----- > From: Martin Landa [mailto:landa.martin@gmail.com] > Sent: Fri 4/13/2007 5:06 AM > To: Patton, Eric > Cc: grassuser@grass.itc.it > Subject: Re: [GRASS-user] g.mlist newline separator request > > Hi, > > this patch should fix it. > > But I am not sure whether to commit it to CVS. Patch seems to be > "ugly" for me, moreover I am not sure why printf fn was used in the > script (?) > > Martin > > 2007/4/12, Patton, Eric : > > I've noticed that g.mlist doesn't enter a newline after the last entry in a list, which used to be the case about a month ago: > > > > ~/coderepo >g.mlist pattern=Minas_Basin* > > Minas_Basin_Jan16_2007_50m > > Minas_Basin_Jan16_2007_50m_med3 > > Minas_Basin_Jan16_2007_50m_med3_shade > > Minas_Basin_Jan16_2007_50m_med3_shade_comb > > Minas_Basin_Jan16_2007_50m_shade > > Minas_Basin_Jan16_2007_50m_shade_comb~/coderepo > > > > > Consequently, any script that tries to get a count from g.mlist by piping to wc will get an incorrect count that will be off by one: > > > > > > g.mlist pattern=Minas_Basin_Jan16_2007_50m | wc -l > > 0 (Should be 1) > > > > g.mlist pattern=Minas_Basin* | wc -l > > 5 (Should be 6) > > > > Would it be possible to get the final newline back? I have scripts that are broken now because a for loop never gets started when a check is done against the number of rasters matched: > > > > MATCHES=`g.mlist pattern=${PATTERN} | wc -l` > > > > # Abort if no matches are found. > > if [ "$MATCHES" -eq 0 ] ; then > > echo "$SCRIPT: No rasters matched the search pattern!" > > exit 1 > > fi > > > > > > ~ Eric. > > > > _______________________________________________ > > grassuser mailing list > > grassuser@grass.itc.it > > http://grass.itc.it/mailman/listinfo/grassuser > > > > > -- > Martin Landa * http://gama.fsv.cvut.cz/~landa * > > -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From glynn at gclements.plus.com Thu Apr 19 19:22:47 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Apr 19 19:22:50 2007 Subject: [GRASS-dev] Re: [GRASS-user] Errors applying color rules and -g flags in r.colors In-Reply-To: References: Message-ID: <17959.42343.666267.12139@cerise.gclements.plus.com> Patton, Eric wrote: > I'm having trouble getting the new r.color -g flag to do anything. Or, > more correctly, maybe it's working properly, but I just can't tell if > it's doing anything or not. > > Running r.colors -g produces a blank display in gis.m on an ordinary raster dataset: > > ~ >g.region rast=IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT > ~ > > ~ >r.colors -g map=IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT color=rainbow > Color table for [IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT] set to rainbow > ~ > Can you provide details of the map, specifically whether it is integer or FP, and the range? > I'm also getting errors applying several of the new-ish predefined > color tables. I've ran a script to apply each color table in turn to > the same input raster. Output pasted below (warning, it's long): > > for COLOR in `r.colors -l` ; do > echo -e "\n\nApplying color rule $COLOR to input raster...\n" > r.colors map=IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT color=$COLOR > done > > > Applying color rule aspect to input raster... > > Color table for [IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT] set to aspect > > > Applying color rule aspectcolr to input raster... > > ERROR: bad rule (percentage not in range 0-100): 180 cyan This is a bug in the new code; I forgot that: if (sscanf(value, "%lf%%", &x) == 1) will be true regardless of whether or not there is a percent sign after the value, so it's treating all values as percentages. I'll commit the following change shortly: Index: lib/gis/color_rules.c =================================================================== RCS file: /grassrepository/grass6/lib/gis/color_rules.c,v retrieving revision 1.3 diff -u -r1.3 color_rules.c --- lib/gis/color_rules.c 14 Apr 2007 03:35:32 -0000 1.3 +++ lib/gis/color_rules.c 19 Apr 2007 17:15:57 -0000 @@ -46,6 +46,7 @@ { char value[16], color[16]; double x; + char c; *norm = *nval = *dflt = 0; @@ -86,7 +87,7 @@ return CR_OK; } - if (sscanf(value, "%lf%%", &x) == 1) + if (sscanf(value, "%lf%c", &x, &c) == 2 && c == '%') { if (x < 0 || x > 100) return CR_ERROR_PERCENT; > So in sum, there are problems applying the aspectcolr, curvature, > etopo2, evi, ndvi, population, srtm, and terrain color tables. It > seems that r.colors will only accept a percentage color range and not > a standard Grass color name or RGB value. Yep. Thanks for finding this. -- Glynn Clements From glynn at gclements.plus.com Thu Apr 19 19:28:45 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Apr 19 19:28:49 2007 Subject: [GRASS-dev] [grass-code P][372] scritps for converting raster maps into GRASS 7 format, and back In-Reply-To: References: <17959.37904.135550.277212@cerise.gclements.plus.com> Message-ID: <17959.42701.186509.758677@cerise.gclements.plus.com> Michael Barton wrote: > When I tried the GLCanvas demo, it told me I needed to have pyOpenGL > installed. If we don't really need this, it makes things MUCH easier by > removing a group of additional dependencies. The demo needs pyOpenGL so that it can draw stuff on the canvas. NVIZ doesn't use OpenGL from Tcl. NVIZ itself (as opposed to the OGSF library) only barely uses it at all: Togl, which is rougly analogous to GLCanvas, and do_zoom.c, which sets up an off-screen "canvas". And most of that is glX/wgl/agl rather than OpenGL proper. -- Glynn Clements From michael.barton at asu.edu Thu Apr 19 19:46:20 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Apr 19 19:46:28 2007 Subject: [GRASS-dev] [grass-code P][372] scritps for converting raster maps into GRASS 7 format, and back In-Reply-To: <17959.42701.186509.758677@cerise.gclements.plus.com> Message-ID: That's great. So we are not stuck with **new** dependencies beyond Python and wxPython. If we trade these for TclTk (as fond as I've become of it), I think we'll come out ahead in the end. Michael On 4/19/07 10:28 AM, "Glynn Clements" wrote: > > Michael Barton wrote: > >> When I tried the GLCanvas demo, it told me I needed to have pyOpenGL >> installed. If we don't really need this, it makes things MUCH easier by >> removing a group of additional dependencies. > > The demo needs pyOpenGL so that it can draw stuff on the canvas. > > NVIZ doesn't use OpenGL from Tcl. NVIZ itself (as opposed to the OGSF > library) only barely uses it at all: Togl, which is rougly analogous > to GLCanvas, and do_zoom.c, which sets up an off-screen "canvas". And > most of that is glX/wgl/agl rather than OpenGL proper. __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From Agustin.Diez at uv.es Thu Apr 19 19:47:38 2007 From: Agustin.Diez at uv.es (Agustin Diez Castillo) Date: Thu Apr 19 19:48:29 2007 Subject: [GRASS-dev] nviz crashes on MacOSX In-Reply-To: <0508BA5C-4501-4667-AC6D-7B0034CFF639@kyngchaos.com> References: <31007F5B-80E4-435B-BBDB-599CE13B0C48@uv.es> <0508BA5C-4501-4667-AC6D-7B0034CFF639@kyngchaos.com> Message-ID: I did compile with TCLTKPREFIX=/usr/local/tcltk. At first it refuses to launch grass, if the terminal was already open nothing happened otherwise I got this: ************************************************************************ ******************* GRASS 6.3.cvs (Projecte):/Applications/GRASS-6.3.app/Contents/ Resources > gis.m & GRASS 6.3.cvs (Projecte):/Applications/GRASS-6.3.app/Contents/ Resources > Xlib: connection to ":0.0" refused by server Xlib: No protocol specified Application initialization failed: couldn't connect to display ":0.0" Xlib: connection to ":0.0" refused by server Xlib: No protocol specified Error in startup script: couldn't connect to display ":0.0" while executing "load /Applications/GRASS-6.3.app/Contents/Resources/lib/tk8.4/../ libtk8.4.dylib Tk" ("package ifneeded" script) invoked from within "package require Tk 8.0" ("package ifneeded" script) invoked from within "package require -exact BWidget 1.2.1" (file "/Applications/GRASS-6.3.app/Contents/Resources/etc/gm/ gm.tcl" line 24) *********************************** After fixing .grassrc GRASS_GUI=tcltk (as expected it changes to text after failure) it starts either the aqua tclktk or the x11 one (arbitrarily as far as I can say); after several tryouts I got what I want grass started from x11 but nviz still crashes, I have tried from both the icon and the terminal. Now everything I try but nviz is working ? On Apr 19, 2007, at 5:15 PM, William Kyngesburye wrote: > Looks like for some reason it's using the system TclTk instead of > the one bundled in the GRASS app package. > > Make sure your X11 build of TclTk got bundled in the app package. > It's possible the automatic detection of the TclTk prefix isn't > working for the bundling stage, like we discussed offlist, and you > would have to set TCLTKPREFIX before building GRASS. If you used > the universal tcltk build instructions in the readme, then that > would be /usr/local/tcltk. > > > On Apr 19, 2007, at 8:24 AM, Agustin Diez Castillo wrote: > >> After compiling and installing latest cvs following William's >> readme, I got this error when trying nviz (itt works fine when >> using his binaries): >> Date/Time: 2007-04-19 13:10:33.116 +0200 >> OS Version: 10.4.9 (Build 8P2137) >> Report Version: 4 >> >> Command: nviz >> Path: /Applications/GRASS-6.3.app/Contents/Resources/etc/ >> nviz2.2/nviz >> Parent: wish8.4 [15392] >> >> Version: ??? (???) >> >> PID: 15397 >> Thread: 0 >> >> Exception: EXC_BAD_ACCESS (0x0001) >> Codes: KERN_INVALID_ADDRESS (0x0001) at 0x6e614320 >> >> Thread 0 Crashed: >> 0 libX11.6.dylib 0x005dacd2 XQueryExtension + 51 > ... >> 0x9ac47000 - 0x9acc5fff com.tcltk.tcllibrary 8.4.7 a /System/ >> Library/Frameworks/Tcl.framework/Versions/8.4/Tcl >> 0x9acdf000 - 0x9ad8efff com.tcltk.tklibrary 8.4.7 a /System/ >> Library/Frameworks/Tk.framework/Versions/8.4/Tk >> > > ----- > William Kyngesburye > http://www.kyngchaos.com/ > > "Oh, look, I seem to have fallen down a deep, dark hole. Now what > does that remind me of? Ah, yes - life." > > - Marvin > > > -------------- next part -------------- Skipped content of type multipart/related From epatton at nrcan.gc.ca Thu Apr 19 19:59:11 2007 From: epatton at nrcan.gc.ca (Patton, Eric) Date: Thu Apr 19 19:59:16 2007 Subject: [GRASS-dev] RE: [GRASS-user] Errors applying color rules and -g flags in r.colors References: <17959.42343.666267.12139@cerise.gclements.plus.com> Message-ID: Thanks for looking at this, Glynn. Comments interspersed below. Patton, Eric wrote: >> I'm having trouble getting the new r.color -g flag to do anything. Or, >> more correctly, maybe it's working properly, but I just can't tell if >> it's doing anything or not. >> >> Running r.colors -g produces a blank display in gis.m on an ordinary raster dataset: >> >> ~ >g.region rast=IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT >> ~ > >> ~ >r.colors -g map=IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT color=rainbow >> Color table for [IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT] set to rainbow >> ~ > Glynn: >Can you provide details of the map, specifically whether it is integer >or FP, and the range? Yes, the raster is floating point; r.info -r gives: r.info -r IsaacsHarbour_HDCS_1m_grd_fill min=-16.806999 max=-1.215008 Glynn: >This is a bug in the new code; I forgot that: > > if (sscanf(value, "%lf%%", &x) == 1) > > >will be true regardless of whether or not there is a percent sign >after the value, so it's treating all values as percentages. I'll >commit the following change shortly Great, thanks! I'll test it an report back. ~ Eric. From woklist at kyngchaos.com Thu Apr 19 20:55:49 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Thu Apr 19 20:55:55 2007 Subject: [GRASS-dev] nviz crashes on MacOSX In-Reply-To: References: <31007F5B-80E4-435B-BBDB-599CE13B0C48@uv.es> <0508BA5C-4501-4667-AC6D-7B0034CFF639@kyngchaos.com> Message-ID: On Apr 19, 2007, at 12:47 PM, Agustin Diez Castillo wrote: > I did compile with TCLTKPREFIX=/usr/local/tcltk. At first it > refuses to launch grass, if the terminal was already open nothing > happened otherwise I got this: How are you starting the GRASS-6.3.app? From the path you are in when you fire up gis.m, it looks like you may have started it from a Terminal? > *********************************** > After fixing .grassrc GRASS_GUI=tcltk (as expected it changes to > text after failure) it starts either the aqua tclktk or the x11 one > (arbitrarily as far as I can say); after several tryouts I got what > I want grass started from x11 but nviz still crashes, I have tried > from both the icon and the terminal. Now everything I try but nviz > is working Does the NVIZ crashlog show the system TclTk still? If so, NVIZ itself may have linked to the wrong TclTk, even though the rest of GRASS uses the X11 TclTk. Try this in a new Terminal window: otool -L /Applications/GRASS-6.3.app/Contents/Resources/etc/nviz2.2/nviz /usr/local/tcltk/lib/libtcl8.4.dylib and /usr/local/tcltk/lib/ libtk8.4.dylib should be listed, not the Tcl or Tk frameworks from the system. ----- William Kyngesburye http://www.kyngchaos.com/ First Pogril: Why is life like sticking your head in a bucket filled with hyena offal? Second Pogril: I don't know. Why IS life like sticking your head in a bucket filled with hyena offal? First Pogril: I don't know either. Wretched, isn't it? -HitchHiker's Guide to the Galaxy From glynn at gclements.plus.com Thu Apr 19 21:03:47 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Apr 19 21:03:49 2007 Subject: [GRASS-dev] RE: [GRASS-user] Errors applying color rules and -g flags in r.colors In-Reply-To: References: <17959.42343.666267.12139@cerise.gclements.plus.com> Message-ID: <17959.48403.268661.435490@cerise.gclements.plus.com> Patton, Eric wrote: > >> I'm having trouble getting the new r.color -g flag to do anything. Or, > >> more correctly, maybe it's working properly, but I just can't tell if > >> it's doing anything or not. > >> > >> Running r.colors -g produces a blank display in gis.m on an ordinary raster dataset: > >> > >> ~ >g.region rast=IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT > >> ~ > > >> ~ >r.colors -g map=IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT color=rainbow > >> Color table for [IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT] set to rainbow > >> ~ > > > Glynn: > >Can you provide details of the map, specifically whether it is integer > >or FP, and the range? > > Yes, the raster is floating point; r.info -r gives: > > r.info -r IsaacsHarbour_HDCS_1m_grd_fill > min=-16.806999 > max=-1.215008 Ah. Logarithmic scaling doesn't work on negative values. It wouldn't be much effort to add a check for the case where both min and max are negative, although I'm not sure whether that should go into the library function (G_log_colors()) or r.colors. Or even whether it's a good idea. In the case where the range includes zero, there's no realistic solution. -- Glynn Clements From epatton at nrcan.gc.ca Thu Apr 19 21:16:35 2007 From: epatton at nrcan.gc.ca (Patton, Eric) Date: Thu Apr 19 21:16:40 2007 Subject: [GRASS-dev] RE: [GRASS-user] Errors applying color rules and -g flags in r.colors References: <17959.42343.666267.12139@cerise.gclements.plus.com> <17959.48403.268661.435490@cerise.gclements.plus.com> Message-ID: Logarithmic scaling isn't critical for my work, so I'll just avoid the -g flag, or rescale my z-values in the case that I do need this feature. I've updated my cvs to include your latest fix to color_rules.c, and while I'm not receiving the error message I did before, there is still some puzzling behavior occurring. The color tables aspectcolr, evi, ndvi, population, and slope still display an all-white raster when invoked with no flags. However, applying the -e flag to each of these color tables creates a full-color, histogram-equalized color table as requested. I'm using the same floating-point raster as I did previously. Is this expected given the types of color tables being used? I'm not familiar with what 'evi' or 'ndvi' mean and for what types of data they are best suited. ~ Eric. -----Original Message----- From: Glynn Clements [mailto:glynn@gclements.plus.com] Sent: Thu 4/19/2007 4:03 PM To: Patton, Eric Cc: grassuser@grass.itc.it; grass-dev@grass.itc.it Subject: RE: [GRASS-user] Errors applying color rules and -g flags in r.colors Patton, Eric wrote: > >> I'm having trouble getting the new r.color -g flag to do anything. Or, > >> more correctly, maybe it's working properly, but I just can't tell if > >> it's doing anything or not. > >> > >> Running r.colors -g produces a blank display in gis.m on an ordinary raster dataset: > >> > >> ~ >g.region rast=IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT > >> ~ > > >> ~ >r.colors -g map=IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT color=rainbow > >> Color table for [IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT] set to rainbow > >> ~ > > > Glynn: > >Can you provide details of the map, specifically whether it is integer > >or FP, and the range? > > Yes, the raster is floating point; r.info -r gives: > > r.info -r IsaacsHarbour_HDCS_1m_grd_fill > min=-16.806999 > max=-1.215008 Ah. Logarithmic scaling doesn't work on negative values. It wouldn't be much effort to add a check for the case where both min and max are negative, although I'm not sure whether that should go into the library function (G_log_colors()) or r.colors. Or even whether it's a good idea. In the case where the range includes zero, there's no realistic solution. -- Glynn Clements From glynn at gclements.plus.com Thu Apr 19 21:19:01 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Apr 19 21:19:03 2007 Subject: [GRASS-dev] nviz crashes on MacOSX In-Reply-To: References: <31007F5B-80E4-435B-BBDB-599CE13B0C48@uv.es> <0508BA5C-4501-4667-AC6D-7B0034CFF639@kyngchaos.com> Message-ID: <17959.49317.49098.795050@cerise.gclements.plus.com> Agustin Diez Castillo wrote: > I did compile with TCLTKPREFIX=/usr/local/tcltk. At first it refuses > to launch grass, if the terminal was already open nothing happened > otherwise I got this: > ************************************************************************ > ******************* > GRASS 6.3.cvs (Projecte):/Applications/GRASS-6.3.app/Contents/ > Resources > gis.m & > GRASS 6.3.cvs (Projecte):/Applications/GRASS-6.3.app/Contents/ > Resources > Xlib: connection to ":0.0" refused by server > Xlib: No protocol specified > > Application initialization failed: couldn't connect to display ":0.0" > Xlib: connection to ":0.0" refused by server > Xlib: No protocol specified This implies that no X server is running. If you want to use the Aqua Tcl/Tk, set the environment variable GRASS_WISH to the full path to the Aqua "wish" (or "wish8.4" etc) executable. > After fixing .grassrc GRASS_GUI=tcltk (as expected it changes to text > after failure) it starts either the aqua tclktk or the x11 one > (arbitrarily as far as I can say); The default setting for GRASS_WISH is just "wish", so gis.m will use whichever "wish" program comes first in $PATH. > after several tryouts I got what I > want grass started from x11 but nviz still crashes, I have tried from > both the icon and the terminal. Now everything I try but nviz is working Whereas gis.m is written entirely in Tcl/Tk, and uses the standard "wish" Tcl/Tk interpreter, NVIZ is a hybrid C + Tcl/Tk application which links against the Tcl/Tk libraries. Consequently, the Tcl/Tk implementation used by NVIZ is determined at compile-time. As NVIZ also uses OpenGL, the Tcl/Tk implementation has to match the OpenGL implementation. If it uses the X11 Tcl/Tk, it must also use X11 OpenGL (GLX); if it uses native (Aqua) Tcl/Tk, it must use native OpenGL (AGL). The default OpenGL implementation is the X11 one; if you want the native version, you must use --with-opengl=mac. The Tcl/Tk implementation is determined by the --with-tcltk-{libs,headers} switches. However, if you use other libraries from a directory which contains the X11 Tcl/Tk libraries (e.g. /usr/local/lib), it's possible that it will end up using the X11 version even if you point --with-tcltk-libs at the Aqua version. Ultimately, there's no way to tell the linker to link specific libraries from specific directories. You specify a list of directories and a list of libraries, and all libraries are located using the same list of directories. If you have multiple versions of a particular library, this can cause problems. Sometimes, the only solution is to create a separate directory, populate it with symlinks to the libraries which you actually wish to use, then specify that directory instead of e.g. /usr/local/lib etc. -- Glynn Clements From glynn at gclements.plus.com Thu Apr 19 21:40:17 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Apr 19 21:40:19 2007 Subject: [GRASS-dev] RE: [GRASS-user] Errors applying color rules and -g flags in r.colors In-Reply-To: References: <17959.42343.666267.12139@cerise.gclements.plus.com> <17959.48403.268661.435490@cerise.gclements.plus.com> Message-ID: <17959.50593.800174.18107@cerise.gclements.plus.com> Patton, Eric wrote: > I've updated my cvs to include your latest fix to color_rules.c, and > while I'm not receiving the error message I did before, there is still > some puzzling behavior occurring. > > The color tables aspectcolr, evi, ndvi, population, and slope still > display an all-white raster when invoked with no flags. However, > applying the -e flag to each of these color tables creates a > full-color, histogram-equalized color table as requested. I'm using > the same floating-point raster as I did previously. Is this expected > given the types of color tables being used? I'm not familiar with what > 'evi' or 'ndvi' mean and for what types of data they are best suited. The aspectcolor, population and slope tables only cover positive values, while the evi and ndvi tables cover the range -1 to 1, so it's expected that those tables won't work with the data in question. OTOH, -e maps the range of the data to the range of the tables; the absolute values used in the tables don't matter. In general, tables which associate colors with percentages (aspect, bcyr, byg, byr, elevation, grey, gyr, rainbow, ramp, ryb, ryg and wave) can be applied to any data, while those which use absolute values (aspectcolr, curvature, etopo2, evi, ndvi, population, slope, srtm, and terrain) only make sense for data with certain ranges. You can get a rough idea of the applicability of a colour table by reading the corresponding rules file ($GISBASE/etc/colors/). E.g. slope is defined as: 0 255 255 255 2 255 255 0 5 0 255 0 10 0 255 255 15 0 0 255 30 255 0 255 50 255 0 0 90 0 0 0 This is designed for the slope map generated by r.slope.aspect, where the value is a slope angle between 0 and 90 degrees. Similarly, the aspectcolr map: 0 white 1 yellow 90 green 180 cyan 270 red 360 yellow is designed for the aspect maps produced by r.slope.aspect, where the value is a heading between 0 and 360 degrees. [The "aspect" map should probably also use 0-360 rather than 0%-100%; I'm not sure why it doesn't.] -- Glynn Clements From woklist at kyngchaos.com Thu Apr 19 22:03:10 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Thu Apr 19 22:03:19 2007 Subject: [GRASS-dev] nviz crashes on MacOSX In-Reply-To: <17959.49317.49098.795050@cerise.gclements.plus.com> References: <31007F5B-80E4-435B-BBDB-599CE13B0C48@uv.es> <0508BA5C-4501-4667-AC6D-7B0034CFF639@kyngchaos.com> <17959.49317.49098.795050@cerise.gclements.plus.com> Message-ID: <49EE8187-5F5A-4624-BB28-6B424B085609@kyngchaos.com> On Apr 19, 2007, at 2:19 PM, Glynn Clements wrote: > > Agustin Diez Castillo wrote: > >> I did compile with TCLTKPREFIX=/usr/local/tcltk. At first it refuses >> to launch grass, if the terminal was already open nothing happened >> otherwise I got this: >> ********************************************************************* >> *** >> ******************* >> GRASS 6.3.cvs (Projecte):/Applications/GRASS-6.3.app/Contents/ >> Resources > gis.m & >> GRASS 6.3.cvs (Projecte):/Applications/GRASS-6.3.app/Contents/ >> Resources > Xlib: connection to ":0.0" refused by server >> Xlib: No protocol specified >> >> Application initialization failed: couldn't connect to display ":0.0" >> Xlib: connection to ":0.0" refused by server >> Xlib: No protocol specified > > This implies that no X server is running. > And supports my suspicion that Agustin started GRASS.app from the Terminal. GRASS.app is meant to be double-clicked to start. The GRASS.app startup adds some convenience items to start X11 and setup some environment var defaults appropriate for OSX. It should be possible to run this startup from the Terminal, but I haven't tested that and there may be problems. ----- William Kyngesburye http://www.kyngchaos.com/ "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 paul-grass at stjohnspoint.co.uk Fri Apr 20 00:48:59 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Fri Apr 20 00:49:16 2007 Subject: [GRASS-dev] ascii export and import, large file problem In-Reply-To: <20070418203038.2c18b59b.hamish_nospam@yahoo.com> References: <20070413073931.AOC98228@expms1.cites.uiuc.edu> <20070418203038.2c18b59b.hamish_nospam@yahoo.com> Message-ID: Hello Hamish Thanks for bringing this up again. ISTR being too busy to reply straight away the last time and then forgetting... On Wed, 18 Apr 2007, Hamish wrote: [...] > --relevant quotes-- > [1...] > For a real y-axis label I think we need to add a new (optional) "units" > element to the raster format (e.g. in cell_misc/). OK this seems like a very good idea. Several times Helena has suggested the idea of adding "vertical datum" support to a location, but I was always quite negative about it in pointing out that there was not even any way of indicating that a particular raster map contained elevation data. But in fact, the obvious answer seems now to be that it should be done on a per-raster map basis rather than a per-location basis. I.e. if the metadata for a raster map indicates that it contains elevation data (i.e. units are a length measure) then there should also be a facility to specify the vertical datum the length measure is relative to. > [2...] >> The user should be able to add a title for the legend. > > For vlegends that's doable. For raster legends I hope to add > G_set_raster_units() and G_get_raster_units() to write/read a simple > string containing raster data units (set from "r.support units=") which > will be stored in $MAPSET/cell_misc/$RASTERMAP/units. Raster legends and > things like lat/lon NVIZ and r.shaded.relief could use the tag if it > existed. > --endquote-- I think it's worth putting enough thought in so that the feature is easily usable for more than just legend titles. Especially how to specify vertical datums. I suppose there are a few very standard ones, like WGS84 ellipsoidal height and that kind of thing. Actually I think the EPSG co-ordinate system database also includes vertical datums. Maybe it has some kind of unique codes that we could re-use. Maybe we should have a vdatum.table file with descriptions. Or maybe we should just put a human-readable name in and leave it for manual interpretation. I'm really not too sure. Paul > > > apparently cell_misc/ is evil, so that moves it to > $MAPSET/units/$RASTERMAP until GRASS7 when it moves to > $MAPSET/raster/$RASTERMAP/units > > I don't like to add another element dir to $MAPSET, but... > > > Hamish > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > From hamish_nospam at yahoo.com Fri Apr 20 08:22:59 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Apr 20 08:23:06 2007 Subject: [GRASS-dev] any way to know color assigned to a cell? In-Reply-To: <46271FF1.1070209@itc.it> References: <17950.48109.88914.169521@cerise.gclements.plus.com> <20070419015116.761a4e3e.hamish_nospam@yahoo.com> <1176905102.12206.2.camel@linuxmain.localhost> <17958.17698.218980.703526@cerise.gclements.plus.com> <1176922969.6624.2.camel@linuxmain.localhost> <46271FF1.1070209@itc.it> Message-ID: <20070420182259.354ca6b4.hamish_nospam@yahoo.com> Markus Neteler wrote: > > I have committed the change to r.what. It now has a "-r" flag (-c > > was taken) that will output the RGB for the selected point. > > I didn't follow this in detail, but with this new -r flag, what is > r.what.color providing? Arbitrary color lookup, not just the value at one specific x,y cell. I believe it is useful for Glynn's new d.rast.edit[.tcl] where the given cell isn't written for r.what to query. Hamish From hamish_nospam at yahoo.com Fri Apr 20 08:41:37 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Apr 20 08:41:46 2007 Subject: [GRASS-dev] [grass-code I][373] NVIZ: max res ppm fails if pwd is empty In-Reply-To: <17959.36072.891869.879688@cerise.gclements.plus.com> References: <20070419061559.0C7BF18565B7@pyrosoma.intevation.org> <17959.36072.891869.879688@cerise.gclements.plus.com> Message-ID: <20070420184137.7b01af69.hamish_nospam@yahoo.com> > > code I item #373, was opened at 2007-04-19 18:15 > > Summary: NVIZ: max res ppm fails if pwd is empty .. > > In NVIZ if you try and do File->Save Image As->Max res PPM when nviz > > was started in an new & empty dir you get this tcl error: > > > > no files matched glob pattern "*" > > no files matched glob pattern "*" > > while executing > > "glob -directory $cur_dir *" Glynn: > Add the -nocomplain switch to the glob command (refresh_file_browser, > in visualization/nviz/scripts/fileBrowser.tcl). thanks, fixed in CVS. Hamish From hamish_nospam at yahoo.com Fri Apr 20 09:09:12 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Apr 20 09:09:21 2007 Subject: [GRASS-dev] etc file finder, take 2 In-Reply-To: <17959.35884.147393.832979@cerise.gclements.plus.com> References: <85349885-5408-480A-B8AD-63DE67DE2997@kyngchaos.com> <17958.17481.129183.667933@cerise.gclements.plus.com> <20070419165415.69444cb1.hamish_nospam@yahoo.com> <17959.35884.147393.832979@cerise.gclements.plus.com> Message-ID: <20070420190912.4e43b095.hamish_nospam@yahoo.com> > Hamish wrote: > > > use GPATH_MAX as the size of the path buffer (I've > > > been replacing various random constants with that value as I find > > > them; also for GNAME_MAX and GMAPSET_MAX).. > > > > more of a comment than a question- > > > > "char input_map[GNAME_MAX];" is often used to hold input=map@mapset > > name, when the array often should be able to hold "GNAME_MAX + @ + > > GMAPSET_MAX + \0" = 514 chars. > > > > GNAME_MAX is long enough (256, gis.h) that map@mapset should rarely > > exceed that, but it's something to look out for. > > > > Perhaps gis.h should also have G_FULLYQUALIFIED_MAX ? Glynn: > Who said that GNAME_MAX referred to the length of an *unqualified* > name? > > It's just an arbitrary value used for array dimensions; nothing > actually checks map names against that value. /* File/directory name lengths */ #define GNAME_MAX 256 #define GMAPSET_MAX 256 #define GPATH_MAX 4096 if GMAPSET_MAX is 256, and GNAME_MAX should be able to hold name@mapset, shouldn't GNAME_MAX be at least GMAPSET_MAX+2? [2= 1 char long mapset name + @] otherwise concat can theoretically overflow. (playing devil's advocate here to make the allocs a little more bad- assumption-proof) Hamish From hamish_nospam at yahoo.com Fri Apr 20 09:28:50 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Apr 20 09:29:00 2007 Subject: [GRASS-dev] ascii export and import, large file problem In-Reply-To: References: <20070413073931.AOC98228@expms1.cites.uiuc.edu> <20070418203038.2c18b59b.hamish_nospam@yahoo.com> Message-ID: <20070420192850.110cfed9.hamish_nospam@yahoo.com> Paul Kelly wrote: > Hello Hamish > Thanks for bringing this up again. ISTR being too busy to reply > straight away the last time and then forgetting... > > On Wed, 18 Apr 2007, Hamish wrote: > [...] > > --relevant quotes-- > > [1...] > > For a real y-axis label I think we need to add a new (optional) > > "units" element to the raster format (e.g. in cell_misc/). > > OK this seems like a very good idea. Several times Helena has > suggested the idea of adding "vertical datum" support to a location, > but I was always quite negative about it in pointing out that there > was not even any way of indicating that a particular raster map > contained elevation data. But in fact, the obvious answer seems now > to be that it should be done on a per-raster map basis rather than a > per-location basis. I.e. if the metadata for a raster map indicates > that it contains elevation data (i.e. units are a length measure) > then there should also be a facility to specify the vertical datum > the length measure is relative to. > > > [2...] > >> The user should be able to add a title for the legend. > > > > For vlegends that's doable. For raster legends I hope to add > > G_set_raster_units() and G_get_raster_units() to write/read a simple > > string containing raster data units (set from "r.support units=") > > which will be stored in $MAPSET/cell_misc/$RASTERMAP/units. Raster > > legends and things like lat/lon NVIZ and r.shaded.relief could use > > the tag if it existed. > > --endquote-- > > I think it's worth putting enough thought in so that the feature is > easily usable for more than just legend titles. Especially how to > specify vertical datums. I suppose there are a few very standard > ones, like WGS84 ellipsoidal height and that kind of thing. Actually > I think the EPSG co-ordinate system database also includes vertical > datums. Maybe it has some kind of unique codes that we could re-use. > Maybe we should have a vdatum.table file with descriptions. Or maybe > we should just put a human-readable name in and leave it for manual > interpretation. > > I'm really not too sure. ok, proposal: add raster map specific cell_misc/units and cell_misc/vertical_datum files. Each would hold a single line string containing the info. You could set the value with e.g. "r.support units=" You could query with e.g. "r.info -u" read/write using new cell_misc libgis fns described by Glynn in an earlier email. both fully optional, and non-existing by default, so fully backwards compatible with old maps. for use by modules, just start with strcmp(tolower(*string), "meters") for hinting. units can be anything, so I prefer to allow freeform metadata there, not just something from a list. I fear that vertical datums may use very local names so while a common table would be helpful we need to allow a custom entries. I'm not too sure about them though. Hamish From grass-codep at wald.intevation.org Fri Apr 20 09:51:07 2007 From: grass-codep at wald.intevation.org (grass-codep@wald.intevation.org) Date: Fri Apr 20 09:51:12 2007 Subject: [GRASS-dev] [grass-code P][374] v.what.vect additional upload options Message-ID: <20070420075107.D5AA71973FB8@pyrosoma.intevation.org> code P item #374, was opened at 2007-04-20 19:51 Status: Open Priority: 3 Submitted By: Hamish Bowman (hamish) Assigned to: Nobody (None) Summary: v.what.vect additional upload options Patch status: postponed Patch type: enhancement GRASS component: vector GRASS version: CVS HEAD GRASS CVS checkout date, if applies (YYMMDD): 070422 Initial Comment: Hi, I patched the v.what.vect script to allow other upload options. my needs changed & I don't actually need it now, so am not really sure if any of the add'l upload options are really needed/meaningful so haven't really tested or applied to CVS. maybe cat can be useful. modified version of version from CVS 20 April 2007 attached. Hamish ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=205&aid=374&group_id=21 From glynn at gclements.plus.com Fri Apr 20 10:27:48 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Apr 20 10:27:51 2007 Subject: [GRASS-dev] etc file finder, take 2 In-Reply-To: <20070420190912.4e43b095.hamish_nospam@yahoo.com> References: <85349885-5408-480A-B8AD-63DE67DE2997@kyngchaos.com> <17958.17481.129183.667933@cerise.gclements.plus.com> <20070419165415.69444cb1.hamish_nospam@yahoo.com> <17959.35884.147393.832979@cerise.gclements.plus.com> <20070420190912.4e43b095.hamish_nospam@yahoo.com> Message-ID: <17960.31108.203169.98910@cerise.gclements.plus.com> Hamish wrote: > > > > use GPATH_MAX as the size of the path buffer (I've > > > > been replacing various random constants with that value as I find > > > > them; also for GNAME_MAX and GMAPSET_MAX).. > > > > > > more of a comment than a question- > > > > > > "char input_map[GNAME_MAX];" is often used to hold input=map@mapset > > > name, when the array often should be able to hold "GNAME_MAX + @ + > > > GMAPSET_MAX + \0" = 514 chars. > > > > > > GNAME_MAX is long enough (256, gis.h) that map@mapset should rarely > > > exceed that, but it's something to look out for. > > > > > > Perhaps gis.h should also have G_FULLYQUALIFIED_MAX ? > > Glynn: > > Who said that GNAME_MAX referred to the length of an *unqualified* > > name? > > > > It's just an arbitrary value used for array dimensions; nothing > > actually checks map names against that value. > > > /* File/directory name lengths */ > #define GNAME_MAX 256 > #define GMAPSET_MAX 256 > > #define GPATH_MAX 4096 > > > if GMAPSET_MAX is 256, and GNAME_MAX should be able to hold name@mapset, > shouldn't GNAME_MAX be at least GMAPSET_MAX+2? > [2= 1 char long mapset name + @] Not necessarily; it just means that if you have really long names[1] for both maps and mapsets, you may not be able to use fully-qualified names. [1] 256 characters > 3 * 80-character lines, which is *really* long[2]. [2] Long enough that I should probably look at changing struct Reclass to use a dynamically-allocated char* rather than a fixed-sized array, given that the G__ structure has one instance per descriptor. > otherwise concat can theoretically overflow. Simply copying the map name into the array can theoretically overflow. Nothing prevents the user from specifying a map name which exceeds GNAME_MAX (likewise for mapsets). > (playing devil's advocate here to make the allocs a little more bad- > assumption-proof) The actual values don't really matter unless something actually checks them. The main advantage of pre-defined constants is that it discourages authors from using excessively small buffers. -- Glynn Clements From hamish_nospam at yahoo.com Fri Apr 20 10:33:51 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Apr 20 10:33:57 2007 Subject: [GRASS-dev] v.distance in lat/lon? Message-ID: <20070420203351.42a4e28b.hamish_nospam@yahoo.com> Hi, anyone know if "v.distance upload=dist" is safe for lat/lon locations? [v.distance/main.c line 470] tseg = Vect_line_distance ( TPoints, FPoints->x[0], FPoints->y[0], 0, 0, &tmp_tx, &tmp_ty, NULL, &tmp_dist, NULL, &tmp_talong); >From looking at lib/vector/Vlib/line.c Vect_line_distance() and lib/vector/diglib/line_dist.c dig_distance2_point_to_line() I take it is assuming euclidian space and the results are measured in (bogus) degrees. (??) maybe if(LL){Vect_line_geodesic_length();} else {V_l_d();} helps? thanks, Hamish From neteler at itc.it Fri Apr 20 10:26:56 2007 From: neteler at itc.it (Markus Neteler) Date: Fri Apr 20 11:01:12 2007 Subject: [GRASS-dev] any way to know color assigned to a cell? In-Reply-To: <20070420182259.354ca6b4.hamish_nospam@yahoo.com> References: <17950.48109.88914.169521@cerise.gclements.plus.com> <20070419015116.761a4e3e.hamish_nospam@yahoo.com> <1176905102.12206.2.camel@linuxmain.localhost> <17958.17698.218980.703526@cerise.gclements.plus.com> <1176922969.6624.2.camel@linuxmain.localhost> <46271FF1.1070209@itc.it> <20070420182259.354ca6b4.hamish_nospam@yahoo.com> Message-ID: <46287950.4020605@itc.it> Hamish wrote on 04/20/2007 08:22 AM: > Markus Neteler wrote: > >>> I have committed the change to r.what. It now has a "-r" flag (-c >>> was taken) that will output the RGB for the selected point. >>> >> I didn't follow this in detail, but with this new -r flag, what is >> r.what.color providing? >> > > Arbitrary color lookup, not just the value at one specific x,y cell. > > I believe it is useful for Glynn's new d.rast.edit[.tcl] where the given > cell isn't written for r.what to query. > Anyone willing to write description.html for r.what.color? thanks, Markus ------------------ ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler ITC -> since 1 March 2007 Fondazione Bruno Kessler ------------------ From paul-grass at stjohnspoint.co.uk Fri Apr 20 12:07:19 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Fri Apr 20 12:07:31 2007 Subject: [GRASS-dev] Re: SoC 2007 In-Reply-To: <86782b610704180119x27463899o16619a30d3182eb1@mail.gmail.com> References: <4620C629.8060103@bergenheim.net> <86782b610704180119x27463899o16619a30d3182eb1@mail.gmail.com> Message-ID: Hello Markus/Wolf On Wed, 18 Apr 2007, Markus Neteler wrote: [...] >> On a side note; Markus (Frank, you may answer too ;)), what do you think >> would be better: to have the SoC students commit through our regular CVS >> (or svn if we have switched by 28.5) or as a GRASS extension? > > Concerning the main repository: > We definitely won't switch to SVN quickly since it seems to be a slooooow > process (sigh). > > Probably a GRASS SVN Addon would be best for now. We can easily > migrate it into the main trunk then. All changes necessary in the libs can > go directly into CVS of course so that the Addon stuff is compilable all > the time. > >> In other >> words do you think this should be an extension module or a core module? >> I think it will be easier for the students to commit to the core, and >> that way I think they will feel more like part of the GRASS team. Thoughts? > > For a module, the best breeding site might be the Addons SVN (however, > with your vector/v.label.sa/ we do differently). > > Time to work out some rules for this. So I cc'ed to the dev list for > further discussion. I guess in this case some place is needed for the students and mentors to work on code together. A place where its totally fine to put little experimental things and break things on purpose and make many changes per day. From that point of view I think a special repository separate from the main GRASS one is required. I feel the main GRASS repository should only be used for code that has a reasonable chance of working, that you are ready to share with other GRASS developers for testing. I don't think every small incremental devlopment you make in your own tests should be committed, in particular because it adds a lot of noise to the CVS commit mailing list and makes it harder to track real changes. I feel we as developers should, *in general* do a little bit of testing on our own and then commit something that we think is reasonably likely to work. Of course there are lots of exceptions to this. However in the case of summer of code students they need somewhere to share work with the mentor and other interested developers without the pressure of having to use the main CVS. Of course important changes could be committed to the main CVS at regular intervals, like Markus said (with regard to necessary changes to libraries etc.) but day to day development should occur somewhere else IMHO. Paul From wolf+grass at bergenheim.net Fri Apr 20 12:39:38 2007 From: wolf+grass at bergenheim.net (Wolf Bergenheim) Date: Fri Apr 20 12:40:18 2007 Subject: [GRASS-dev] Re: SoC 2007 In-Reply-To: References: <4620C629.8060103@bergenheim.net> <86782b610704180119x27463899o16619a30d3182eb1@mail.gmail.com> Message-ID: <4628986A.1050906@bergenheim.net> On 20.04.2007 13:07, Paul Kelly wrote: > Hello Markus/Wolf > > On Wed, 18 Apr 2007, Markus Neteler wrote: > > [...] >>> On a side note; Markus (Frank, you may answer too ;)), what do you think >>> would be better: to have the SoC students commit through our regular CVS >>> (or svn if we have switched by 28.5) or as a GRASS extension? >> >> Concerning the main repository: >> We definitely won't switch to SVN quickly since it seems to be a slooooow >> process (sigh). >> >> Probably a GRASS SVN Addon would be best for now. We can easily >> migrate it into the main trunk then. All changes necessary in the libs >> can >> go directly into CVS of course so that the Addon stuff is compilable all >> the time. >> >>> In other >>> words do you think this should be an extension module or a core module? >>> I think it will be easier for the students to commit to the core, and >>> that way I think they will feel more like part of the GRASS team. >>> Thoughts? >> >> For a module, the best breeding site might be the Addons SVN (however, >> with your vector/v.label.sa/ we do differently). >> >> Time to work out some rules for this. So I cc'ed to the dev list for >> further discussion. > > I guess in this case some place is needed for the students and mentors > to work on code together. A place where its totally fine to put little > experimental things and break things on purpose and make many changes > per day. From that point of view I think a special repository separate > from the main GRASS one is required. > > I feel the main GRASS repository should only be used for code that has a > reasonable chance of working, that you are ready to share with other > GRASS developers for testing. I don't think every small incremental > devlopment you make in your own tests should be committed, in particular > because it adds a lot of noise to the CVS commit mailing list and makes > it harder to track real changes. I feel we as developers should, *in > general* do a little bit of testing on our own and then commit something > that we think is reasonably likely to work. Of course there are lots of > exceptions to this. However in the case of summer of code students they > need somewhere to share work with the mentor and other interested > developers without the pressure of having to use the main CVS. Of course > important changes could be committed to the main CVS at regular > intervals, like Markus said (with regard to necessary changes to > libraries etc.) but day to day development should occur somewhere else > IMHO. Google does provide space in code.google.com, so I guess we could use that, I suppose, but the idea is that the community should also try the students' code, during the summer, not only the mentor. But I can live with having a grass_soc repository on code.google .com ,and then from there I can commit say weekly working versions of the code to the main GRASS CVS repository. Would that be OK with you people? --Wolf -- <:3 )---- Wolf Bergenheim ----( 8:> From paul-grass at stjohnspoint.co.uk Fri Apr 20 12:56:09 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Fri Apr 20 12:56:15 2007 Subject: [GRASS-dev] Re: SoC 2007 In-Reply-To: <4628986A.1050906@bergenheim.net> References: <4620C629.8060103@bergenheim.net> <86782b610704180119x27463899o16619a30d3182eb1@mail.gmail.com> <4628986A.1050906@bergenheim.net> Message-ID: Hello Wolf On Fri, 20 Apr 2007, Wolf Bergenheim wrote: > Google does provide space in code.google.com, so I guess we could use > that, I suppose, but the idea is that the community should also try the > students' code, during the summer, not only the mentor. But I can live > with having a grass_soc repository on code.google .com ,and then from > there I can commit say weekly working versions of the code to the main > GRASS CVS repository. Would that be OK with you people? I don't see any reason why the students can't have CVS access so they can commit directly? When they think the code is ready for testing. But I expect it will be further into the summer before there is something ready to commit and thus a place to collaborate over the initial prototype is necessary. Can other devlopers access the google repository too - I'm thinking of perhaps discussions on the mailing list when we want to point out something specific in the code. Paul From Agustin.Diez at uv.es Fri Apr 20 13:03:50 2007 From: Agustin.Diez at uv.es (Agustin Diez Castillo) Date: Fri Apr 20 13:04:41 2007 Subject: [GRASS-dev] nviz crashes on MacOSX In-Reply-To: <49EE8187-5F5A-4624-BB28-6B424B085609@kyngchaos.com> References: <31007F5B-80E4-435B-BBDB-599CE13B0C48@uv.es> <0508BA5C-4501-4667-AC6D-7B0034CFF639@kyngchaos.com> <17959.49317.49098.795050@cerise.gclements.plus.com> <49EE8187-5F5A-4624-BB28-6B424B085609@kyngchaos.com> Message-ID: <087A27EE-246F-4B37-A0E4-61B8439C8038@uv.es> I did NOT start from the terminal, I doubled click on the application. The Xlib message only showed up once, the tcltk messages several times but they are gone now. However nviz still crashes. http://smigol2.uv.es/nviz_crashing.mov On Apr 19, 2007, at 10:03 PM, William Kyngesburye wrote: > > On Apr 19, 2007, at 2:19 PM, Glynn Clements wrote: > >> >> Agustin Diez Castillo wrote: >> >>> I did compile with TCLTKPREFIX=/usr/local/tcltk. At first it refuses >>> to launch grass, if the terminal was already open nothing happened >>> otherwise I got this: >>> ******************************************************************** >>> **** >>> ******************* >>> GRASS 6.3.cvs (Projecte):/Applications/GRASS-6.3.app/Contents/ >>> Resources > gis.m & >>> GRASS 6.3.cvs (Projecte):/Applications/GRASS-6.3.app/Contents/ >>> Resources > Xlib: connection to ":0.0" refused by server >>> Xlib: No protocol specified >>> >>> Application initialization failed: couldn't connect to display ": >>> 0.0" >>> Xlib: connection to ":0.0" refused by server >>> Xlib: No protocol specified >> >> This implies that no X server is running. >> > And supports my suspicion that Agustin started GRASS.app from the > Terminal. GRASS.app is meant to be double-clicked to start. The > GRASS.app startup adds some convenience items to start X11 and > setup some environment var defaults appropriate for OSX. It should > be possible to run this startup from the Terminal, but I haven't > tested that and there may be problems. > > > ----- > William Kyngesburye > http://www.kyngchaos.com/ > > "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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070420/1f5d6ce3/attachment.html From Agustin.Diez at uv.es Fri Apr 20 13:20:00 2007 From: Agustin.Diez at uv.es (Agustin Diez Castillo) Date: Fri Apr 20 13:20:54 2007 Subject: [GRASS-dev] nviz crashes on MacOSX In-Reply-To: References: <31007F5B-80E4-435B-BBDB-599CE13B0C48@uv.es> <0508BA5C-4501-4667-AC6D-7B0034CFF639@kyngchaos.com> Message-ID: <6D19ED01-9D61-46C0-9CAF-C8F729DFA798@uv.es> On Apr 19, 2007, at 8:55 PM, William Kyngesburye wrote: > On Apr 19, 2007, at 12:47 PM, Agustin Diez Castillo wrote: > >> I did compile with TCLTKPREFIX=/usr/local/tcltk. At first it >> refuses to launch grass, if the terminal was already open nothing >> happened otherwise I got this: > > How are you starting the GRASS-6.3.app? From the path you are in > when you fire up gis.m, it looks like you may have started it from > a Terminal? > Double click > >> *********************************** >> After fixing .grassrc GRASS_GUI=tcltk (as expected it changes to >> text after failure) it starts either the aqua tclktk or the x11 >> one (arbitrarily as far as I can say); after several tryouts I got >> what I want grass started from x11 but nviz still crashes, I have >> tried from both the icon and the terminal. Now everything I try >> but nviz is working > > Does the NVIZ crashlog show the system TclTk still? If so, NVIZ > itself may have linked to the wrong TclTk, even though the rest of > GRASS uses the X11 TclTk. Try this in a new Terminal window: > Yes it does > otool -L /Applications/GRASS-6.3.app/Contents/Resources/etc/nviz2.2/ > nviz > > /usr/local/tcltk/lib/libtcl8.4.dylib and /usr/local/tcltk/lib/ > libtk8.4.dylib should be listed, not the Tcl or Tk frameworks from > the system. > is pointing to Frameworks /System/Library/Frameworks/Tk.framework/Versions/8.4/Tk I will try from the beginning following Glynn suggestions. > ----- > William Kyngesburye > http://www.kyngchaos.com/ > > First Pogril: Why is life like sticking your head in a bucket > filled with hyena offal? > Second Pogril: I don't know. Why IS life like sticking your head > in a bucket filled with hyena offal? > First Pogril: I don't know either. Wretched, isn't it? > > -HitchHiker's Guide to the Galaxy > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070420/44766f61/attachment.html From wolf+grass at bergenheim.net Fri Apr 20 13:29:08 2007 From: wolf+grass at bergenheim.net (Wolf Bergenheim) Date: Fri Apr 20 13:29:44 2007 Subject: [GRASS-dev] Re: SoC 2007 In-Reply-To: References: <4620C629.8060103@bergenheim.net> <86782b610704180119x27463899o16619a30d3182eb1@mail.gmail.com> <4628986A.1050906@bergenheim.net> Message-ID: <4628A404.4090802@bergenheim.net> On 20.04.2007 13:56, Paul Kelly wrote: > Hello Wolf > > On Fri, 20 Apr 2007, Wolf Bergenheim wrote: > >> Google does provide space in code.google.com, so I guess we could use >> that, I suppose, but the idea is that the community should also try the >> students' code, during the summer, not only the mentor. But I can live >> with having a grass_soc repository on code.google .com ,and then from >> there I can commit say weekly working versions of the code to the main >> GRASS CVS repository. Would that be OK with you people? > > I don't see any reason why the students can't have CVS access so they > can commit directly? When they think the code is ready for testing. Neither do I. Perhaps Markus has some points? And I'm sure that the student's can determine when the code is working and when it is not. > But I expect it will be further into the summer before there is something > ready to commit and thus a place to collaborate over the initial > prototype is necessary. That is true... and daily commits is something I think is mandatory for the collaboration in SoC, just to be able to track the student progress. So in that light I think that perhaps the code.google.com repository might be the place. Another option I assume could be the addons svn, but I'm not sure if people will like that either since it has also some email commit log thing... > Can other devlopers access the google repository too - I'm thinking of > perhaps discussions on the mailing list when we want to point out > something specific in the code. > I think that read access can be given to the whole world. So yeah anybody should be able to get any code from there. I also think that they give a web-access just like in sourceforge. --Wolf -- <:3 )---- Wolf Bergenheim ----( 8:> From neteler at itc.it Fri Apr 20 14:14:59 2007 From: neteler at itc.it (Markus Neteler) Date: Fri Apr 20 14:48:19 2007 Subject: [GRASS-dev] Re: SoC 2007 In-Reply-To: <4628A404.4090802@bergenheim.net> References: <4620C629.8060103@bergenheim.net> <86782b610704180119x27463899o16619a30d3182eb1@mail.gmail.com> <4628986A.1050906@bergenheim.net> <4628A404.4090802@bergenheim.net> Message-ID: <4628AEC3.3070802@itc.it> Wolf Bergenheim wrote on 04/20/2007 01:29 PM: > On 20.04.2007 13:56, Paul Kelly wrote: > >> Hello Wolf >> >> On Fri, 20 Apr 2007, Wolf Bergenheim wrote: >> >> >>> Google does provide space in code.google.com, so I guess we could use >>> that, I suppose, but the idea is that the community should also try the >>> students' code, during the summer, not only the mentor. But I can live >>> with having a grass_soc repository on code.google .com ,and then from >>> there I can commit say weekly working versions of the code to the main >>> GRASS CVS repository. Would that be OK with you people? >>> >> I don't see any reason why the students can't have CVS access so they >> can commit directly? When they think the code is ready for testing. >> > > Neither do I. Perhaps Markus has some points? And I'm sure that the > student's can determine when the code is working and when it is not. > So far we have been pretty conservative granting CVS write access since we have no means to restrict the access (unless we move to SVN). We usually see what/how a person contributes, then grant access. There is the GRASS Addons SVN which might be also of interest. In general, we should find a viable solution which makes testing easy. Helena suggested to re-establish a contrib section as it was in GRASS 4.x. Overall, after full SVN migration these things should be pretty easy to handle. >> But I expect it will be further into the summer before there is something >> ready to commit and thus a place to collaborate over the initial >> prototype is necessary. >> > > That is true... and daily commits is something I think is mandatory for > the collaboration in SoC, just to be able to track the student progress. > So in that light I think that perhaps the code.google.com repository > might be the place. Another option I assume could be the addons svn, but > I'm not sure if people will like that either since it has also some > email commit log thing... > What is the problem with the email commit log? It's sent to this list: http://grass.itc.it/mailman/listinfo/grass-commit-addons Who wants can subscribe. >> Can other devlopers access the google repository too - I'm thinking of >> perhaps discussions on the mailing list when we want to point out >> something specific in the code. >> >> > > I think that read access can be given to the whole world. So yeah > anybody should be able to get any code from there. I also think that > they give a web-access just like in sourceforge. > We should take care to not spread the code too much around. Otherwise connections will get lost or at least tedious. Currently we have GRASS-CVS for the "real" code and GRASS-Addons SVN as breeding site. Isn't that enough? The GRASS-Addons SVN is publicly readable, with password-controlled write access, web interface and own commit mailing list. Markus ------------------ ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler ITC -> since 1 March 2007 Fondazione Bruno Kessler ------------------ From woklist at kyngchaos.com Fri Apr 20 15:52:14 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Fri Apr 20 15:52:20 2007 Subject: [GRASS-dev] nviz crashes on MacOSX In-Reply-To: <087A27EE-246F-4B37-A0E4-61B8439C8038@uv.es> References: <31007F5B-80E4-435B-BBDB-599CE13B0C48@uv.es> <0508BA5C-4501-4667-AC6D-7B0034CFF639@kyngchaos.com> <17959.49317.49098.795050@cerise.gclements.plus.com> <49EE8187-5F5A-4624-BB28-6B424B085609@kyngchaos.com> <087A27EE-246F-4B37-A0E4-61B8439C8038@uv.es> Message-ID: On Apr 20, 2007, at 6:03 AM, Agustin Diez Castillo wrote: > I did NOT start from the terminal, I doubled click on the > application. The Xlib message only showed up once, the tcltk > messages several times but they are gone now. However nviz still > crashes. > http://smigol2.uv.es/nviz_crashing.mov > Sorry. But now it's making sense - as Glynn suggested, somehow during the build NVIZ is linking to /usr/libtcl and /usr/libtk. These are the symlinks in the system to the system Tcl and Tk frameworks. As far as Glynn's suggestion of creating these symlinks to /usr/local/tcltk copies, you shouldn't mess with system stuff (/ usr/lib). What is the link command show for nviz when you build grass? it's built as nvwish so search for that in the make output. There should be no -L/usr/lib in there. That's a default dir for GCC and manually adding it somehow can mess up linking priorities, like what is happening here. ----- William Kyngesburye http://www.kyngchaos.com/ "This is a question about the past, is it? ... How can I tell that the past isn't a fiction designed to account for the discrepancy between my immediate physical sensations and my state of mind?" - The Ruler of the Universe From neteler at itc.it Fri Apr 20 16:15:56 2007 From: neteler at itc.it (Markus Neteler) Date: Fri Apr 20 16:16:00 2007 Subject: [GRASS-dev] Re: SoC 2007 In-Reply-To: <4628BBB6.6020806@bergenheim.net> References: <4620C629.8060103@bergenheim.net> <86782b610704180119x27463899o16619a30d3182eb1@mail.gmail.com> <4628986A.1050906@bergenheim.net> <4628A404.4090802@bergenheim.net> <4628AEC3.3070802@itc.it> <4628BBB6.6020806@bergenheim.net> Message-ID: <20070420141556.GF31105@bartok.itc.it> On Fri, Apr 20, 2007 at 04:10:14PM +0300, Wolf Bergenheim wrote: > On 20.04.2007 15:14, Markus Neteler wrote: > > Wolf Bergenheim wrote on 04/20/2007 01:29 PM: > >> On 20.04.2007 13:56, Paul Kelly wrote: > > > >>> But I expect it will be further into the summer before there is something > >>> ready to commit and thus a place to collaborate over the initial > >>> prototype is necessary. > >>> > >> That is true... and daily commits is something I think is mandatory for > >> the collaboration in SoC, just to be able to track the student progress. > >> So in that light I think that perhaps the code.google.com repository > >> might be the place. Another option I assume could be the addons svn, but > >> I'm not sure if people will like that either since it has also some > >> email commit log thing... > >> > > What is the problem with the email commit log? It's sent to this list: > > http://grass.itc.it/mailman/listinfo/grass-commit-addons > > Who wants can subscribe. > > Paul had concerns of too many messages cluttering the list with SoC > commits. Personally I don't think it is a problem. Nor me - a commit is a commit. Any they don't need to make each single character modification a commit :) > >>> Can other devlopers access the google repository too - I'm thinking of > >>> perhaps discussions on the mailing list when we want to point out > >>> something specific in the code. > >>> > >>> > >> I think that read access can be given to the whole world. So yeah > >> anybody should be able to get any code from there. I also think that > >> they give a web-access just like in sourceforge. > >> > > We should take care to not spread the code too much around. Otherwise > > connections will get > > lost or at least tedious. Currently we have GRASS-CVS for the "real" > > code and > > GRASS-Addons SVN as breeding site. Isn't that enough? The GRASS-Addons > > SVN is > > publicly readable, with password-controlled write access, web interface > > and own > > commit mailing list. > > Do people check out this code? Do people test it? Besides documentation/flyer, it currently contains: gipe/ gui/ i.landsat.dehaze/ r.boxcount/ r.boxcount.sh/ r.out.netcdf/ v.curvature/ v.strahler/ gui/ is under heavy development, also gipe/. The others are single modules with varying level of testing. > My worry is that if we > only store code in the addons svn nobody will even bother to look at > it. (except for me). Not sure about this. And also: you need first sort of functional code to make tests as a user. This simply takes time. > But if I commit that code to the GRASS cvs people > will see it and even be tempted to test it, which is what we want. In > the end of SoC the code has to be submitted to Google anyway for review, > and that means at least one commit to the code.google.com repository if > I have understood things correctly. The whole point with the CVS access > was that we would make the SoC students feel welcome into the core GRASS > community, which would increase the chances of them sticking around > after the SoC. But I guess svn access will be good enough in that > puropse too. Peronally, I thought of starting in SVN and then moving it to CVS once there is relevant code. Meanwhile we have maybe done the entire SVN migration and the problem disappears? > So, how do I go about requesting access to the addons svn? Can I also > request access on the behalf of Daniel Bundala and Maximilian Maldacker? Sure. They may just drop me an email. Markus From tutey at o2.pl Fri Apr 20 16:59:59 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Fri Apr 20 17:00:07 2007 Subject: [GRASS-dev] [patch] Use in intr_char.c In-Reply-To: <20070326205405.GQ6734@hoeg.nl> References: <20070326205405.GQ6734@hoeg.nl> Message-ID: <4628D56F.5040304@o2.pl> Ed Thanks for your patch. Please submit it to the patches tracker. Maciek From benjamin.ducke at ufg.uni-kiel.de Fri Apr 20 17:21:12 2007 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Fri Apr 20 17:05:55 2007 Subject: [GRASS-dev] multiple definition of _fmode on Win32 Message-ID: <4628DA68.7080004@ufg.uni-kiel.de> Hi all, I am trying to compile yesterday's CVS sources on Win32 using MSYS and MingW (3.4.2). When the make script should link the gis lib objs (and other libs), I get this: OBJ.i686-pc-mingw32/open_misc.o(.data+0x0): In function `G__open_misc': C:/msys/src/grass6/lib/gis/open_misc.c:45: multiple definition of `_fmode' OBJ.i686-pc-mingw32/open.o(.data+0x0):C:/msys/src/grass6/lib/gis/open.c:98: first defined here collect2: ld returned 1 exit status make[2]: *** [/src/grass6/dist.i686-pc-mingw32/lib/libgrass_gis.6.3.cvs.dll] Error 1 I updated from CVS ca. 18 hours ago and did a "make distclean" and "make clean" before running the configure script. Am I doing sth. wrong here? Best, Benjamin -- Benjamin Ducke, M.A. Arch?oinformatik (Archaeoinformation Science) Institut f?r Ur- und Fr?hgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universit?t zu Kiel Johanna-Mestorf-Stra?e 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg From epatton at nrcan.gc.ca Fri Apr 20 17:53:04 2007 From: epatton at nrcan.gc.ca (Patton, Eric) Date: Fri Apr 20 17:53:11 2007 Subject: [GRASS-dev] RE: [GRASS-user] Errors applying color rules and -g flags in r.colors In-Reply-To: <17959.50593.800174.18107@cerise.gclements.plus.com> References: <17959.42343.666267.12139@cerise.gclements.plus.com><17959.48403.268661.435490@cerise.gclements.plus.com> <17959.50593.800174.18107@cerise.gclements.plus.com> Message-ID: Thanks, that clears up all the outstanding issues. A while back I think I recall someone saying that they had implemented a C structure that would allow a color-picker to be used in Grass programs. Would it be much difficulty adding this color-picker dialog to r.colors to assist in constructing custom color rules files? It seems to me that this module would be the ideal place to have such a feature. -- Eric Patton email: epatton@nrcan.gc.ca > -----Original Message----- > From: Glynn Clements [mailto:glynn@gclements.plus.com] > Sent: Thursday, April 19, 2007 4:40 PM > To: Patton, Eric > Cc: grassuser@grass.itc.it; grass-dev@grass.itc.it > Subject: RE: [GRASS-user] Errors applying color rules and -g > flags in r.colors > > > Patton, Eric wrote: > > > I've updated my cvs to include your latest fix to > color_rules.c, and > > while I'm not receiving the error message I did before, > there is still > > some puzzling behavior occurring. > > > > The color tables aspectcolr, evi, ndvi, population, and slope still > > display an all-white raster when invoked with no flags. However, > > applying the -e flag to each of these color tables creates a > > full-color, histogram-equalized color table as requested. I'm using > > the same floating-point raster as I did previously. Is this > expected > > given the types of color tables being used? I'm not > familiar with what > > 'evi' or 'ndvi' mean and for what types of data they are > best suited. > > The aspectcolor, population and slope tables only cover > positive values, while the evi and ndvi tables cover the > range -1 to 1, so it's expected that those tables won't work > with the data in question. > > OTOH, -e maps the range of the data to the range of the > tables; the absolute values used in the tables don't matter. > > In general, tables which associate colors with percentages > (aspect, bcyr, byg, byr, elevation, grey, gyr, rainbow, ramp, > ryb, ryg and > wave) can be applied to any data, while those which use > absolute values (aspectcolr, curvature, etopo2, evi, ndvi, > population, slope, srtm, and terrain) only make sense for > data with certain ranges. > > You can get a rough idea of the applicability of a colour > table by reading the corresponding rules file > ($GISBASE/etc/colors/). > E.g. slope is defined as: > > 0 255 255 255 > 2 255 255 0 > 5 0 255 0 > 10 0 255 255 > 15 0 0 255 > 30 255 0 255 > 50 255 0 0 > 90 0 0 0 > > This is designed for the slope map generated by > r.slope.aspect, where the value is a slope angle between 0 > and 90 degrees. > > Similarly, the aspectcolr map: > > 0 white > 1 yellow > 90 green > 180 cyan > 270 red > 360 yellow > > is designed for the aspect maps produced by r.slope.aspect, > where the value is a heading between 0 and 360 degrees. > > [The "aspect" map should probably also use 0-360 rather than > 0%-100%; I'm not sure why it doesn't.] > > -- > Glynn Clements > From glynn at gclements.plus.com Fri Apr 20 18:43:42 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Apr 20 18:43:45 2007 Subject: [GRASS-dev] RE: [GRASS-user] Errors applying color rules and -g flags in r.colors In-Reply-To: References: <17959.42343.666267.12139@cerise.gclements.plus.com> <17959.48403.268661.435490@cerise.gclements.plus.com> <17959.50593.800174.18107@cerise.gclements.plus.com> Message-ID: <17960.60862.650275.942334@cerise.gclements.plus.com> Patton, Eric wrote: > A while back I think I recall someone saying that they had implemented a > C structure that would allow a color-picker to be used in Grass > programs. This is part of the Tcl/Tk GUI. Options which are marked as colours can be set using a colour picker from within gis.m or within the dialog generated by --ui. See the options in the Colors tab of d.vect for an example. > Would it be much difficulty adding this color-picker dialog to > r.colors to assist in constructing custom color rules files? It seems to > me that this module would be the ideal place to have such a feature. This would need to be part of a separate application, rather than of r.colors itself. -- Glynn Clements From glynn at gclements.plus.com Fri Apr 20 18:48:00 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Apr 20 18:48:06 2007 Subject: [GRASS-dev] [patch] Use in intr_char.c In-Reply-To: <4628D56F.5040304@o2.pl> References: <20070326205405.GQ6734@hoeg.nl> <4628D56F.5040304@o2.pl> Message-ID: <17960.61120.8132.120257@cerise.gclements.plus.com> Maciej Sieczka wrote: > Thanks for your patch. Please submit it to the patches tracker. This was committed to CVS shortly after the patch was posted. It appears that I forgot to reply to this. -- Glynn Clements From Agustin.Diez at uv.es Fri Apr 20 18:59:22 2007 From: Agustin.Diez at uv.es (Agustin Diez Castillo) Date: Fri Apr 20 19:00:13 2007 Subject: [GRASS-dev] nviz crashes on MacOSX In-Reply-To: References: <31007F5B-80E4-435B-BBDB-599CE13B0C48@uv.es> <0508BA5C-4501-4667-AC6D-7B0034CFF639@kyngchaos.com> <17959.49317.49098.795050@cerise.gclements.plus.com> <49EE8187-5F5A-4624-BB28-6B424B085609@kyngchaos.com> <087A27EE-246F-4B37-A0E4-61B8439C8038@uv.es> Message-ID: <3FA438B1-404E-4368-8FD2-62EFD44A72DD@uv.es> Now it's working, after cvs update, make distclean, make, sudo make install. Same flags, same machine and export SDKROOT=/Developer/SDKs/MacOSX10.4u.sdk; export CFLAGS="-arch ppc -arch i386 -isysroot $SDKROOT"; export CXXFLAGS="-arch ppc -arch i386 -isysroot $SDKROOT"; export LDFLAGS="-arch ppc -arch i386 - isysroot $SDKROOT"; export NAD2BIN=/Library/Frameworks/PROJ.framework/ Programs/nad2bin not tcltkprefix. ********************************************** ./configure --with-freetype --with-freetype-includes="/Library/ Frameworks/FreeType.framework/unix/include/freetype2 /Library/ Frameworks/FreeType.framework/unix/include" --with-freetype-libs=/ Library/Frameworks/FreeType.framework/unix/lib --with-gdal=/Library/ Frameworks/GDAL.framework/Programs/gdal-config --with-proj --with- proj-includes=/Library/Frameworks/PROJ.framework/unix/include --with- proj-libs=/Library/Frameworks/PROJ.framework/unix/lib --with-proj- share=/Library/Frameworks/PROJ.framework/Resources/proj --with-jpeg- includes=/Library/Frameworks/UnixImageIO.framework/unix/include -- with-jpeg-libs=/Library/Frameworks/UnixImageIO.framework/unix/lib -- with-png-includes=/Library/Frameworks/UnixImageIO.framework/unix/ include --with-png-libs=/Library/Frameworks/UnixImageIO.framework/ unix/lib --with-tiff-includes=/Library/Frameworks/ UnixImageIO.framework/unix/include --with-tiff-libs=/Library/ Frameworks/UnixImageIO.framework/unix/lib --with-postgres-includes=/ usr/local/pgsql/include --with-postgres-libs=/usr/local/pgsql/lib -- without-mysql --with-odbc --with-sqlite --with-sqlite-libs=/Library/ Frameworks/SQLite3.framework/unix/lib --with-sqlite-includes=/Library/ Frameworks/SQLite3.framework/unix/include --with-fftw-includes=/ Library/Frameworks/FFTW3.framework/unix/include --with-fftw-libs=/ Library/Frameworks/FFTW3.framework/unix/lib --with-cxx --with-tcltk- includes=/usr/local/tcltk/include --with-tcltk-libs=/usr/local/tcltk/ lib --with-x --with-motif --without-glw --with-opengl=x11 --with- opengl-libs=/usr/X11R6/lib --without-readline --prefix=/Applications --enable-macosx-app > On Apr 20, 2007, at 6:03 AM, Agustin Diez Castillo wrote: > >> I did NOT start from the terminal, I doubled click on the >> application. The Xlib message only showed up once, the tcltk >> messages several times but they are gone now. However nviz still >> crashes. >> http://smigol2.uv.es/nviz_crashing.mov >> > Sorry. But now it's making sense - as Glynn suggested, somehow > during the build NVIZ is linking to /usr/libtcl and /usr/libtk. > These are the symlinks in the system to the system Tcl and Tk > frameworks. As far as Glynn's suggestion of creating these > symlinks to /usr/local/tcltk copies, you shouldn't mess with system > stuff (/usr/lib). > > What is the link command show for nviz when you build grass? it's > built as nvwish so search for that in the make output. > > There should be no -L/usr/lib in there. That's a default dir for > GCC and manually adding it somehow can mess up linking priorities, > like what is happening here. > > > ----- > William Kyngesburye > http://www.kyngchaos.com/ > > "This is a question about the past, is it? ... How can I tell that > the past isn't a fiction designed to account for the discrepancy > between my immediate physical sensations and my state of mind?" > > - The Ruler of the Universe > > > From glynn at gclements.plus.com Fri Apr 20 19:52:58 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Apr 20 19:52:59 2007 Subject: [GRASS-dev] multiple definition of _fmode on Win32 In-Reply-To: <4628DA68.7080004@ufg.uni-kiel.de> References: <4628DA68.7080004@ufg.uni-kiel.de> Message-ID: <17960.65018.271320.735672@cerise.gclements.plus.com> Benjamin Ducke wrote: > I am trying to compile yesterday's CVS sources on Win32 using MSYS and > MingW (3.4.2). > When the make script should link the gis lib objs (and other libs), I > get this: > > OBJ.i686-pc-mingw32/open_misc.o(.data+0x0): In function `G__open_misc': > C:/msys/src/grass6/lib/gis/open_misc.c:45: multiple definition of `_fmode' > OBJ.i686-pc-mingw32/open.o(.data+0x0):C:/msys/src/grass6/lib/gis/open.c:98: > first defined here > collect2: ld returned 1 exit status > make[2]: *** > [/src/grass6/dist.i686-pc-mingw32/lib/libgrass_gis.6.3.cvs.dll] Error 1 > > I updated from CVS ca. 18 hours ago and did a "make distclean" and "make > clean" before running the configure script. I've removed both occurrences of _fmode from libgis (in any case, defining it inside a DLL doesn't work). _fmode should be defined by linking against $(FMODE_OBJ). -- Glynn Clements From tutey at o2.pl Fri Apr 20 20:11:12 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Fri Apr 20 20:11:21 2007 Subject: [GRASS-dev] [patch] Use in intr_char.c In-Reply-To: <17960.61120.8132.120257@cerise.gclements.plus.com> References: <20070326205405.GQ6734@hoeg.nl> <4628D56F.5040304@o2.pl> <17960.61120.8132.120257@cerise.gclements.plus.com> Message-ID: <46290240.7000105@o2.pl> Glynn Clements wrote: > Maciej Sieczka wrote: > >> Thanks for your patch. Please submit it to the patches tracker. > > This was committed to CVS shortly after the patch was posted. It > appears that I forgot to reply to this. My email server tends to re-send a random message from time to time. Ed's message was one such. I replied, missing how old the message was and forgetting that the issue had been solved in patches tracker [1]. Very sorry for the fuss. My fault. Maciek [1]http://wald.intevation.org/tracker/?func=detail&atid=205&aid=347&group_id=21 From glynn at gclements.plus.com Fri Apr 20 20:34:34 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Apr 20 20:34:35 2007 Subject: [GRASS-dev] any way to know color assigned to a cell? In-Reply-To: <46287950.4020605@itc.it> References: <17950.48109.88914.169521@cerise.gclements.plus.com> <20070419015116.761a4e3e.hamish_nospam@yahoo.com> <1176905102.12206.2.camel@linuxmain.localhost> <17958.17698.218980.703526@cerise.gclements.plus.com> <1176922969.6624.2.camel@linuxmain.localhost> <46271FF1.1070209@itc.it> <20070420182259.354ca6b4.hamish_nospam@yahoo.com> <46287950.4020605@itc.it> Message-ID: <17961.1978.70480.547786@cerise.gclements.plus.com> Markus Neteler wrote: > >>> I have committed the change to r.what. It now has a "-r" flag (-c > >>> was taken) that will output the RGB for the selected point. > >>> > >> I didn't follow this in detail, but with this new -r flag, what is > >> r.what.color providing? > >> > > > > Arbitrary color lookup, not just the value at one specific x,y cell. > > > > I believe it is useful for Glynn's new d.rast.edit[.tcl] where the given > > cell isn't written for r.what to query. > > > Anyone willing to write description.html for r.what.color? Done. -- Glynn Clements From woklist at kyngchaos.com Fri Apr 20 21:38:51 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Fri Apr 20 21:38:57 2007 Subject: [GRASS-dev] nviz crashes on MacOSX In-Reply-To: <3FA438B1-404E-4368-8FD2-62EFD44A72DD@uv.es> References: <31007F5B-80E4-435B-BBDB-599CE13B0C48@uv.es> <0508BA5C-4501-4667-AC6D-7B0034CFF639@kyngchaos.com> <17959.49317.49098.795050@cerise.gclements.plus.com> <49EE8187-5F5A-4624-BB28-6B424B085609@kyngchaos.com> <087A27EE-246F-4B37-A0E4-61B8439C8038@uv.es> <3FA438B1-404E-4368-8FD2-62EFD44A72DD@uv.es> Message-ID: Cool. I tend to get focused on the details of a problem, but make distclean is always a good place to start. On Apr 20, 2007, at 11:59 AM, Agustin Diez Castillo wrote: > Now it's working, after cvs update, make distclean, make, sudo make > install. > Same flags, same machine and > export SDKROOT=/Developer/SDKs/MacOSX10.4u.sdk; export CFLAGS="- > arch ppc -arch i386 -isysroot $SDKROOT"; export CXXFLAGS="-arch ppc > -arch i386 -isysroot $SDKROOT"; export LDFLAGS="-arch ppc -arch > i386 -isysroot $SDKROOT"; export NAD2BIN=/Library/Frameworks/ > PROJ.framework/Programs/nad2bin > not tcltkprefix. ----- William Kyngesburye http://www.kyngchaos.com/ "Time is an illusion - lunchtime doubly so." - Ford Prefect From jachym.cepicky at gmail.com Sat Apr 21 00:11:45 2007 From: jachym.cepicky at gmail.com (Jachym Cepicky) Date: Sat Apr 21 00:11:50 2007 Subject: [GRASS-dev] off topic: offline status Message-ID: <1177107105.8617.18.camel@mellon> Hi, I'll be for a month (till mid of June) offline. Looking forward to read you again. Jachym -- Jachym Cepicky e-mail: jachym.cepicky@gmail.com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub From michael.barton at asu.edu Sat Apr 21 05:40:25 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sat Apr 21 05:40:35 2007 Subject: [GRASS-dev] Re: SoC 2007 In-Reply-To: <4628AEC3.3070802@itc.it> Message-ID: Grass Addons seems like a good place for this. There is similar development work going on there currently, ranging from possible new GIS modules to the new GUI. Michael On 4/20/07 5:14 AM, "Markus Neteler" wrote: > Wolf Bergenheim wrote on 04/20/2007 01:29 PM: >> On 20.04.2007 13:56, Paul Kelly wrote: >> >>> Hello Wolf >>> >>> On Fri, 20 Apr 2007, Wolf Bergenheim wrote: >>> >>> >>>> Google does provide space in code.google.com, so I guess we could use >>>> that, I suppose, but the idea is that the community should also try the >>>> students' code, during the summer, not only the mentor. But I can live >>>> with having a grass_soc repository on code.google .com ,and then from >>>> there I can commit say weekly working versions of the code to the main >>>> GRASS CVS repository. Would that be OK with you people? >>>> >>> I don't see any reason why the students can't have CVS access so they >>> can commit directly? When they think the code is ready for testing. >>> >> >> Neither do I. Perhaps Markus has some points? And I'm sure that the >> student's can determine when the code is working and when it is not. >> > > So far we have been pretty conservative granting CVS write access since > we have no > means to restrict the access (unless we move to SVN). We usually see > what/how a person > contributes, then grant access. > There is the GRASS Addons SVN which might be also of interest. > > In general, we should find a viable solution which makes testing easy. > Helena suggested > to re-establish a contrib section as it was in GRASS 4.x. > Overall, after full SVN migration these things should be pretty easy to > handle. > >>> But I expect it will be further into the summer before there is something >>> ready to commit and thus a place to collaborate over the initial >>> prototype is necessary. >>> >> >> That is true... and daily commits is something I think is mandatory for >> the collaboration in SoC, just to be able to track the student progress. >> So in that light I think that perhaps the code.google.com repository >> might be the place. Another option I assume could be the addons svn, but >> I'm not sure if people will like that either since it has also some >> email commit log thing... >> > What is the problem with the email commit log? It's sent to this list: > http://grass.itc.it/mailman/listinfo/grass-commit-addons > Who wants can subscribe. > >>> Can other devlopers access the google repository too - I'm thinking of >>> perhaps discussions on the mailing list when we want to point out >>> something specific in the code. >>> >>> >> >> I think that read access can be given to the whole world. So yeah >> anybody should be able to get any code from there. I also think that >> they give a web-access just like in sourceforge. >> > We should take care to not spread the code too much around. Otherwise > connections will get > lost or at least tedious. Currently we have GRASS-CVS for the "real" > code and > GRASS-Addons SVN as breeding site. Isn't that enough? The GRASS-Addons > SVN is > publicly readable, with password-controlled write access, web interface > and own > commit mailing list. > > Markus > > ------------------ > ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler > ITC -> since 1 March 2007 Fondazione Bruno Kessler > ------------------ > > __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Sat Apr 21 05:43:42 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sat Apr 21 05:43:52 2007 Subject: [GRASS-dev] RE: [GRASS-user] Errors applying color rules and -g flags in r.colors In-Reply-To: Message-ID: An interactive color picker is best implemented in an interactive GUI environment. There are some already active in the current TclTk GUI, and we are adding quite a few more for user convenience in the new wxPython GUI that is now under develoment. Michael On 4/20/07 8:53 AM, "Patton, Eric" wrote: > Thanks, that clears up all the outstanding issues. > > A while back I think I recall someone saying that they had implemented a > C structure that would allow a color-picker to be used in Grass > programs. Would it be much difficulty adding this color-picker dialog to > r.colors to assist in constructing custom color rules files? It seems to > me that this module would be the ideal place to have such a feature. > > -- > Eric Patton > email: epatton@nrcan.gc.ca > > > >> -----Original Message----- >> From: Glynn Clements [mailto:glynn@gclements.plus.com] >> Sent: Thursday, April 19, 2007 4:40 PM >> To: Patton, Eric >> Cc: grassuser@grass.itc.it; grass-dev@grass.itc.it >> Subject: RE: [GRASS-user] Errors applying color rules and -g >> flags in r.colors >> >> >> Patton, Eric wrote: >> >>> I've updated my cvs to include your latest fix to >> color_rules.c, and >>> while I'm not receiving the error message I did before, >> there is still >>> some puzzling behavior occurring. >>> >>> The color tables aspectcolr, evi, ndvi, population, and slope still >>> display an all-white raster when invoked with no flags. However, >>> applying the -e flag to each of these color tables creates a >>> full-color, histogram-equalized color table as requested. I'm using >>> the same floating-point raster as I did previously. Is this >> expected >>> given the types of color tables being used? I'm not >> familiar with what >>> 'evi' or 'ndvi' mean and for what types of data they are >> best suited. >> >> The aspectcolor, population and slope tables only cover >> positive values, while the evi and ndvi tables cover the >> range -1 to 1, so it's expected that those tables won't work >> with the data in question. >> >> OTOH, -e maps the range of the data to the range of the >> tables; the absolute values used in the tables don't matter. >> >> In general, tables which associate colors with percentages >> (aspect, bcyr, byg, byr, elevation, grey, gyr, rainbow, ramp, >> ryb, ryg and >> wave) can be applied to any data, while those which use >> absolute values (aspectcolr, curvature, etopo2, evi, ndvi, >> population, slope, srtm, and terrain) only make sense for >> data with certain ranges. >> >> You can get a rough idea of the applicability of a colour >> table by reading the corresponding rules file >> ($GISBASE/etc/colors/). >> E.g. slope is defined as: >> >> 0 255 255 255 >> 2 255 255 0 >> 5 0 255 0 >> 10 0 255 255 >> 15 0 0 255 >> 30 255 0 255 >> 50 255 0 0 >> 90 0 0 0 >> >> This is designed for the slope map generated by >> r.slope.aspect, where the value is a slope angle between 0 >> and 90 degrees. >> >> Similarly, the aspectcolr map: >> >> 0 white >> 1 yellow >> 90 green >> 180 cyan >> 270 red >> 360 yellow >> >> is designed for the aspect maps produced by r.slope.aspect, >> where the value is a heading between 0 and 360 degrees. >> >> [The "aspect" map should probably also use 0-360 rather than >> 0%-100%; I'm not sure why it doesn't.] >> >> -- >> Glynn Clements >> > > __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From hamish_nospam at yahoo.com Sat Apr 21 14:01:22 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Sat Apr 21 14:01:29 2007 Subject: [GRASS-dev] d.vect.chart legends Message-ID: <20070422000122.3121d068.hamish_nospam@yahoo.com> Hi, I just added a new -l flag to d.vect.chart to output info needed to create legends for charts. Previously you just got different colors with no reference to which columns they represented (using default colors). this can be parsed to make a legend, either using d.graph (like d.vect.thematic does) or by storing the info in a raster map's metadata and using d.legend to make the map--for example: MAP= COLUMNS= #### setup temporary file TMP="`g.tempfile pid=$$`" if [ $? -ne 0 ] || [ -z "$TMP" ] ; then echo "ERROR: unable to create temporary files" 1>&2 exit 1 fi d.vect.chart -l map="$MAP" type=point columns="$COLUMNS" > "$TMP" NCATS=`tail -n1 "$TMP" | cut -f1 -d'|'` # wc -l ? # create small temporary map hold legend info g.region save=previous_zoom g.region n=1 s=0 e=1 w=0 res=1 r.mapcalc "tmp_chart_$$ = $NCATS" g.region previous_zoom #set cat labels eval `g.gisenv` awk -F'|' '{ printf("%d:%s\n", $1, $2) }' "$TMP" >> \ "$GISDBASE/$LOCATION_NAME/$MAPSET/cats/tmp_chart_$$" #set colors r.colors tmp_chart_$$ color=rules --quiet << EOF `awk -F'|' '{ printf("%d %s\n", $1, $3) }' "$TMP"` EOF #draw the legend d.legend -c tmp_chart_$$ range=1,$NCATS at=50,90,5,10 enjoy, Hamish From hamish_nospam at yahoo.com Sat Apr 21 14:14:01 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Sat Apr 21 14:14:06 2007 Subject: [GRASS-dev] [patch] Use in intr_char.c In-Reply-To: <46290240.7000105@o2.pl> References: <20070326205405.GQ6734@hoeg.nl> <4628D56F.5040304@o2.pl> <17960.61120.8132.120257@cerise.gclements.plus.com> <46290240.7000105@o2.pl> Message-ID: <20070422001401.56c7a623.hamish_nospam@yahoo.com> Maciej Sieczka wrote: > My email server tends to re-send a random message from time to time. > Ed's message was one such. I've just received it too. [...] Received: from grass.itc.it (localhost.localdomain [127.0.0.1]) by grass.itc.it (8.13.1/8.13.1) with ESMTP id l3KDiAoO027865; Fri, 20 Apr 2007 15:44:15 +0200 Received: from palm.hoeg.nl (palm.hoeg.nl [83.98.131.212]) by grass.itc.it (8.13.1/8.13.1) with ESMTP id l2QKs5W5013503 for ; Mon, 26 Mar 2007 22:54:05 +0200 [...] the hold-up seems to have been in Italy. apparently Glynn received it earlier: CVS log for grass6/lib/gis/intr_char.c Revision 2.2, Fri Mar 30 09:30:02 2007 UTC (3 weeks, 1 day ago) Changes since 2.1: +9 -1 lines Use termios if available ?? Hamish From hamish_nospam at yahoo.com Sat Apr 21 14:21:28 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Sat Apr 21 14:22:11 2007 Subject: [GRASS-dev] Re: SoC 2007 In-Reply-To: <20070420141556.GF31105@bartok.itc.it> References: <4620C629.8060103@bergenheim.net> <86782b610704180119x27463899o16619a30d3182eb1@mail.gmail.com> <4628986A.1050906@bergenheim.net> <4628A404.4090802@bergenheim.net> <4628AEC3.3070802@itc.it> <4628BBB6.6020806@bergenheim.net> <20070420141556.GF31105@bartok.itc.it> Message-ID: <20070422002128.33e21749.hamish_nospam@yahoo.com> Markus Neteler wrote: > Probably a GRASS SVN Addon would be best for now. We can easily > migrate it into the main trunk then. All changes necessary in the libs > can go directly into CVS of course so that the Addon stuff is > compilable all the time. .. > Peronally, I thought of starting in SVN and then moving it to CVS > once there is relevant code. Meanwhile we have maybe done the > entire SVN migration and the problem disappears? I agree. Hamish From glynn at gclements.plus.com Sat Apr 21 18:28:10 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Apr 21 18:28:12 2007 Subject: [GRASS-dev] [patch] Use in intr_char.c In-Reply-To: <20070422001401.56c7a623.hamish_nospam@yahoo.com> References: <20070326205405.GQ6734@hoeg.nl> <4628D56F.5040304@o2.pl> <17960.61120.8132.120257@cerise.gclements.plus.com> <46290240.7000105@o2.pl> <20070422001401.56c7a623.hamish_nospam@yahoo.com> Message-ID: <17962.15258.463493.824188@cerise.gclements.plus.com> Hamish wrote: > Maciej Sieczka wrote: > > My email server tends to re-send a random message from time to time. > > Ed's message was one such. > > I've just received it too. > > > [...] > Received: from grass.itc.it (localhost.localdomain [127.0.0.1]) by grass.itc.it (8.13.1/8.13.1) with ESMTP id l3KDiAoO027865; Fri, 20 Apr 2007 15:44:15 +0200 > Received: from palm.hoeg.nl (palm.hoeg.nl [83.98.131.212]) by grass.itc.it (8.13.1/8.13.1) with ESMTP id l2QKs5W5013503 for ; Mon, 26 Mar 2007 22:54:05 +0200 > [...] > > the hold-up seems to have been in Italy. Same here: Received: from grass.itc.it (localhost.localdomain [127.0.0.1]) by grass.itc.it (8.13.1/8.13.1) with ESMTP id l3KDiAoO027865; Fri, 20 Apr 2007 15:44:15 +0200 Received: from palm.hoeg.nl (palm.hoeg.nl [83.98.131.212]) by grass.itc.it (8.13.1/8.13.1) with ESMTP id l2QKs5W5013503 for ; Mon, 26 Mar 2007 22:54:05 +0200 > apparently Glynn received it earlier: No, I received (and replied to) a similar message sent by the bug tracker: http://grass.itc.it/pipermail/grass-dev/2007-March/030047.html http://grass.itc.it/pipermail/grass-dev/2007-March/030057.html -- Glynn Clements From michael.barton at asu.edu Sat Apr 21 18:58:35 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sat Apr 21 18:58:45 2007 Subject: [GRASS-dev] [grass-code P][372] scritps for converting raster maps into GRASS 7 format, and back In-Reply-To: <17959.37904.135550.277212@cerise.gclements.plus.com> Message-ID: On 4/19/07 9:08 AM, "Glynn Clements" wrote: > You shouldn't need pyOpenGL unless you're planning on making OpenGL > calls from Python. The only parts of NVIZ which make OpenGL calls are > Togl and do_zoom.c. NVIZ is just a UI; all of the actual work is done > by the OGSF library. So we don't need pyOpenGL to replace Togl? Does the wxPython GLCanvas replace Togl? Somehow we need to make calls from wxPython event handlers to actually display/render a 3D image. I'm totally in the dark as to how this is done. I've worked with the UI part of NVIZ (this is the overwhelmingly greatest part, as you point out), but don't understand how the OGL calls are actually made. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From glynn at gclements.plus.com Sat Apr 21 21:17:58 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Apr 21 21:18:23 2007 Subject: [GRASS-dev] [grass-code P][372] scritps for converting raster maps into GRASS 7 format, and back In-Reply-To: References: <17959.37904.135550.277212@cerise.gclements.plus.com> Message-ID: <17962.25446.61539.876493@cerise.gclements.plus.com> Michael Barton wrote: > > You shouldn't need pyOpenGL unless you're planning on making OpenGL > > calls from Python. The only parts of NVIZ which make OpenGL calls are > > Togl and do_zoom.c. NVIZ is just a UI; all of the actual work is done > > by the OGSF library. > > So we don't need pyOpenGL to replace Togl? No. > Does the wxPython GLCanvas replace Togl? Yes. > Somehow we need to make calls from wxPython event handlers to > actually display/render a 3D image. I'm totally in the dark as to how this > is done. I've worked with the UI part of NVIZ (this is the overwhelmingly > greatest part, as you point out), but don't understand how the OGL calls are > actually made. OpenGL is called by OGSF (GS_*, gsd_* etc), which is called by the various N_*_cmd() functions in the C part of NVIZ. These functions are registered as Tcl commands, and the Tcl commands are called from the various Tcl scripts. In general, any Tcl command which begins with "N" (but not "Nv_"), e.g. Ndraw_all, is implemented in C. Typically a Tcl command "Nfoo" corresponds to the C function Nfoo_cmd(), although there are some exceptions, e.g. Ndraw_all corresponds to Ndraw_all_together_cmd(). Some of the functions are little more than wrappers around individual OGSF functions, which others (e.g. Ndraw_all) are more complex. Most of the bindings are in src/init_commands.c; grep for "Tcl_CreateCommand" in src/*.c for a complete list. -- Glynn Clements From grass-codei at wald.intevation.org Sat Apr 21 22:05:01 2007 From: grass-codei at wald.intevation.org (grass-codei@wald.intevation.org) Date: Sat Apr 21 22:05:06 2007 Subject: [GRASS-dev] [grass-code I][377] d.vect map disp=dir now broken: G_plot_icon() bug? Message-ID: <20070421200501.46D521973FB5@pyrosoma.intevation.org> code I item #377, was opened at 2007-04-21 22:05 Status: Open Priority: 3 Submitted By: Markus Neteler (markusn) Assigned to: Nobody (None) Summary: d.vect map disp=dir now broken: G_plot_icon() bug? Issue type: module bug Issue status: None GRASS version: CVS HEAD GRASS component: None Operating system: all Operating system version: GRASS CVS checkout date, if applies (YYMMDD): Initial Comment: Since a few days the "disp=dir" no longer works. I recall to have seen some G_plot_icon() modifications. Could this be related? The positioning is right but the symbol invisible: #spearfish d.vect roads d.vect roads disp=dir -> directional arrow no more visible This functionality is important for graph related work such as LRS or vector network analysis. Markus ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=377&group_id=21 From glynn at gclements.plus.com Sat Apr 21 22:13:14 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Apr 21 22:13:22 2007 Subject: [GRASS-dev] [grass-code I][377] d.vect map disp=dir now broken: G_plot_icon() bug? In-Reply-To: <20070421200501.46D521973FB5@pyrosoma.intevation.org> References: <20070421200501.46D521973FB5@pyrosoma.intevation.org> Message-ID: <17962.28762.766925.462855@cerise.gclements.plus.com> grass-codei@wald.intevation.org wrote: > code I item #377, was opened at 2007-04-21 22:05 > Status: Open > Priority: 3 > Submitted By: Markus Neteler (markusn) > Assigned to: Nobody (None) > Summary: d.vect map disp=dir now broken: G_plot_icon() bug? > Issue type: module bug > Issue status: None > GRASS version: CVS HEAD > GRASS component: None > Operating system: all > Operating system version: > GRASS CVS checkout date, if applies (YYMMDD): > > > Initial Comment: > Since a few days the "disp=dir" no longer works. > I recall to have seen some G_plot_icon() modifications. Could this > be related? The positioning is right but the symbol invisible: It could be related. I ended up multiplying by the scale twice, so if the scale factor is significantly less than unity, the icons could end up invisible. Try changing lines 29-30 of lib/gis/icon.c to: x[i] = m[0][0] * x[i] + m[0][1] * y[i] + xc; y[i] = m[1][0] * x[i] + m[1][1] * y[i] + yc; I'll commit this when CVS comes back to life. -- Glynn Clements From neteler at itc.it Sat Apr 21 23:03:01 2007 From: neteler at itc.it (Markus Neteler) Date: Sat Apr 21 23:03:03 2007 Subject: [GRASS-dev] [grass-code I][377] d.vect map disp=dir now broken: G_plot_icon() bug? In-Reply-To: <17962.28762.766925.462855@cerise.gclements.plus.com> References: <20070421200501.46D521973FB5@pyrosoma.intevation.org> <17962.28762.766925.462855@cerise.gclements.plus.com> Message-ID: <20070421210300.GA10528@bartok.itc.it> On Sat, Apr 21, 2007 at 09:13:14PM +0100, Glynn Clements wrote: > > grass-codei@wald.intevation.org wrote: > > > code I item #377, was opened at 2007-04-21 22:05 > > Status: Open > > Priority: 3 > > Submitted By: Markus Neteler (markusn) > > Assigned to: Nobody (None) > > Summary: d.vect map disp=dir now broken: G_plot_icon() bug? > > Issue type: module bug > > Issue status: None > > GRASS version: CVS HEAD > > GRASS component: None > > Operating system: all > > Operating system version: > > GRASS CVS checkout date, if applies (YYMMDD): > > > > > > Initial Comment: > > Since a few days the "disp=dir" no longer works. > > I recall to have seen some G_plot_icon() modifications. Could this > > be related? The positioning is right but the symbol invisible: > > It could be related. I ended up multiplying by the scale twice, so if > the scale factor is significantly less than unity, the icons could end > up invisible. > > Try changing lines 29-30 of lib/gis/icon.c to: > > x[i] = m[0][0] * x[i] + m[0][1] * y[i] + xc; > y[i] = m[1][0] * x[i] + m[1][1] * y[i] + yc; > > I'll commit this when CVS comes back to life. I have tried but it doesn't seem to help. Does it work for you now? Markus From neteler at itc.it Sat Apr 21 23:06:37 2007 From: neteler at itc.it (Markus Neteler) Date: Sat Apr 21 23:06:40 2007 Subject: [GRASS-dev] [patch] Use in intr_char.c In-Reply-To: <20070422001401.56c7a623.hamish_nospam@yahoo.com> References: <20070326205405.GQ6734@hoeg.nl> <4628D56F.5040304@o2.pl> <17960.61120.8132.120257@cerise.gclements.plus.com> <46290240.7000105@o2.pl> <20070422001401.56c7a623.hamish_nospam@yahoo.com> Message-ID: <20070421210637.GB10528@bartok.itc.it> On Sun, Apr 22, 2007 at 12:14:01AM +1200, Hamish wrote: > Maciej Sieczka wrote: > > My email server tends to re-send a random message from time to time. > > Ed's message was one such. > > I've just received it too. > > > [...] > Received: from grass.itc.it (localhost.localdomain [127.0.0.1]) by grass.itc.it (8.13.1/8.13.1) with ESMTP id l3KDiAoO027865; Fri, 20 Apr 2007 15:44:15 +0200 > Received: from palm.hoeg.nl (palm.hoeg.nl [83.98.131.212]) by grass.itc.it (8.13.1/8.13.1) with ESMTP id l2QKs5W5013503 for ; Mon, 26 Mar 2007 22:54:05 +0200 > [...] > > the hold-up seems to have been in Italy. Mea culpa (AFAIK): This mail got trapped in Mailman since the sender wasn't subscribed to the list. To not discard the mail, I approved it and wrote to the person to subscribe to follow further conversation. Usually I reject such mails. Probably I should have done so here, too. But there us always the not so low probability that senders just throw it away. Well: sorry for the mess. But I don't manage to check the mailman queues daily. I guess I will tend to always reject now. Markus > apparently Glynn received it earlier: > > CVS log for grass6/lib/gis/intr_char.c > Revision 2.2, Fri Mar 30 09:30:02 2007 UTC (3 weeks, 1 day ago) > Changes since 2.1: +9 -1 lines > Use termios if available > > > ?? > Hamish > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev -- Markus Neteler http://mpa.itc.it/markus/ FBK-irst - Centro per la Ricerca Scientifica e Tecnologica MPBA - Predictive Models for Biol. & Environ. Data Analysis Via Sommarive, 18 - 38050 Povo (Trento), Italy From glynn at gclements.plus.com Sat Apr 21 23:29:25 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Apr 21 23:29:30 2007 Subject: [GRASS-dev] [grass-code I][377] d.vect map disp=dir now broken: G_plot_icon() bug? In-Reply-To: <20070421210300.GA10528@bartok.itc.it> References: <20070421200501.46D521973FB5@pyrosoma.intevation.org> <17962.28762.766925.462855@cerise.gclements.plus.com> <20070421210300.GA10528@bartok.itc.it> Message-ID: <17962.33333.437195.979974@cerise.gclements.plus.com> Markus Neteler wrote: > > > Since a few days the "disp=dir" no longer works. > > > I recall to have seen some G_plot_icon() modifications. Could this > > > be related? The positioning is right but the symbol invisible: > > > > It could be related. I ended up multiplying by the scale twice, so if > > the scale factor is significantly less than unity, the icons could end > > up invisible. > > > > Try changing lines 29-30 of lib/gis/icon.c to: > > > > x[i] = m[0][0] * x[i] + m[0][1] * y[i] + xc; > > y[i] = m[1][0] * x[i] + m[1][1] * y[i] + yc; > > > > I'll commit this when CVS comes back to life. > > I have tried but it doesn't seem to help. > Does it work for you now? That was only half of the problem; this deals with the other half: Index: icon.c =================================================================== RCS file: /grassrepository/grass6/lib/gis/icon.c,v retrieving revision 1.8 diff -u -r1.8 icon.c --- icon.c 21 Apr 2007 20:37:46 -0000 1.8 +++ icon.c 21 Apr 2007 21:24:44 -0000 @@ -28,8 +28,11 @@ for ( i = 0; i < n_points; i++) { - x[i] = m[0][0] * x[i] + m[0][1] * y[i] + xc; - y[i] = m[1][0] * x[i] + m[1][1] * y[i] + yc; + double xi = x[i]; + double yi = y[i]; + + x[i] = m[0][0] * xi + m[0][1] * yi + xc; + y[i] = m[1][0] * xi + m[1][1] * yi + yc; } } I have tested this and it appears to work now. Committed to CVS. -- Glynn Clements From neteler at itc.it Sat Apr 21 23:32:30 2007 From: neteler at itc.it (Markus Neteler) Date: Sat Apr 21 23:32:31 2007 Subject: [GRASS-dev] [grass-code I][377] d.vect map disp=dir now broken: G_plot_icon() bug? In-Reply-To: <17962.33333.437195.979974@cerise.gclements.plus.com> References: <20070421200501.46D521973FB5@pyrosoma.intevation.org> <17962.28762.766925.462855@cerise.gclements.plus.com> <20070421210300.GA10528@bartok.itc.it> <17962.33333.437195.979974@cerise.gclements.plus.com> Message-ID: <20070421213230.GC10528@bartok.itc.it> On Sat, Apr 21, 2007 at 10:29:25PM +0100, Glynn Clements wrote: > > Markus Neteler wrote: > > > > > Since a few days the "disp=dir" no longer works. > > > > I recall to have seen some G_plot_icon() modifications. Could this > > > > be related? The positioning is right but the symbol invisible: > > > > > > It could be related. I ended up multiplying by the scale twice, so if > > > the scale factor is significantly less than unity, the icons could end > > > up invisible. > > > > > > Try changing lines 29-30 of lib/gis/icon.c to: > > > > > > x[i] = m[0][0] * x[i] + m[0][1] * y[i] + xc; > > > y[i] = m[1][0] * x[i] + m[1][1] * y[i] + yc; > > > > > > I'll commit this when CVS comes back to life. > > > > I have tried but it doesn't seem to help. > > Does it work for you now? > > That was only half of the problem; this deals with the other half: > > Index: icon.c > =================================================================== > RCS file: /grassrepository/grass6/lib/gis/icon.c,v > retrieving revision 1.8 > diff -u -r1.8 icon.c > --- icon.c 21 Apr 2007 20:37:46 -0000 1.8 > +++ icon.c 21 Apr 2007 21:24:44 -0000 > @@ -28,8 +28,11 @@ > > for ( i = 0; i < n_points; i++) > { > - x[i] = m[0][0] * x[i] + m[0][1] * y[i] + xc; > - y[i] = m[1][0] * x[i] + m[1][1] * y[i] + yc; > + double xi = x[i]; > + double yi = y[i]; > + > + x[i] = m[0][0] * xi + m[0][1] * yi + xc; > + y[i] = m[1][0] * xi + m[1][1] * yi + yc; > } > } > > I have tested this and it appears to work now. > > Committed to CVS. Very nice. Also works for me. Thanks, Markus From michael.barton at asu.edu Sun Apr 22 08:06:10 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sun Apr 22 08:06:20 2007 Subject: [GRASS-dev] d.vect.chart legends In-Reply-To: <20070422000122.3121d068.hamish_nospam@yahoo.com> Message-ID: Hamish, This is conceptually a nice way for getting legends for a vector map, using the tools we now have. There have been repeated requests for a way to get legends for vector maps. Could this be systematized somehow in a script, or better in the vector code, in some way. For example, a flag that would automatically create a tiny legend raster that could be used with d.legend. This could be built out of: the RGB column for vectors, out of random vector colors, built with a script for d.vect.thematic (until the C version is done), created for d.vect.chart like you did for text output. Michael On 4/21/07 5:01 AM, "Hamish" wrote: > Hi, > > I just added a new -l flag to d.vect.chart to output info needed to > create legends for charts. Previously you just got different colors with > no reference to which columns they represented (using default colors). > > this can be parsed to make a legend, either using d.graph (like > d.vect.thematic does) or by storing the info in a raster map's metadata > and using d.legend to make the map--for example: > > > MAP= > COLUMNS= > > #### setup temporary file > TMP="`g.tempfile pid=$$`" > if [ $? -ne 0 ] || [ -z "$TMP" ] ; then > echo "ERROR: unable to create temporary files" 1>&2 > exit 1 > fi > > d.vect.chart -l map="$MAP" type=point columns="$COLUMNS" > "$TMP" > > NCATS=`tail -n1 "$TMP" | cut -f1 -d'|'` # wc -l ? > > # create small temporary map hold legend info > g.region save=previous_zoom > g.region n=1 s=0 e=1 w=0 res=1 > r.mapcalc "tmp_chart_$$ = $NCATS" > g.region previous_zoom > > #set cat labels > eval `g.gisenv` > awk -F'|' '{ printf("%d:%s\n", $1, $2) }' "$TMP" >> \ > "$GISDBASE/$LOCATION_NAME/$MAPSET/cats/tmp_chart_$$" > > #set colors > r.colors tmp_chart_$$ color=rules --quiet << EOF > `awk -F'|' '{ printf("%d %s\n", $1, $3) }' "$TMP"` > EOF > > #draw the legend > d.legend -c tmp_chart_$$ range=1,$NCATS at=50,90,5,10 > > > > enjoy, > Hamish > > __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Sun Apr 22 08:45:01 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sun Apr 22 08:45:10 2007 Subject: [GRASS-dev] numeric-numpy-scipy for graphs? Message-ID: We need to create a graph/plot for at least 2 functions in the wxgrass GUI?profile plotting and histogramming. I did the TclTk profile module with just standard graphic calls. However, wxPython has a very nice plot control:PyPlot. It has lots of nice options, including ways to save the plot easily. BUT, it requires numeric or numarray ? which have been superceded by numpy or scipy. These are as available the main python package and provide a rich scientific computing library for Python and wxPython. It looks like these are available for all platforms either as binary or source files. However, it would be another dependency. So what do you think? Should I install numpy (or scipy) and try the PyPlot or just create these modules with simple graphics? Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070421/2e28922f/attachment.html From yann.chemin at gmail.com Sun Apr 22 09:03:35 2007 From: yann.chemin at gmail.com (Yann) Date: Sun Apr 22 09:03:46 2007 Subject: [GRASS-dev] numeric-numpy-scipy for graphs? In-Reply-To: References: Message-ID: <200704221403.35590.yann.chemin@gmail.com> Based on your previous experience with TclTk: using pyplot, do you forecast less pain/less time for coding the same and better quality of GUI interface because of mentioned advantages? if yes, +1 to the added dependency. yann On Sunday 22 April 2007 13:45, Michael Barton wrote: > We need to create a graph/plot for at least 2 functions in the wxgrass > GUI?profile plotting and histogramming. I did the TclTk profile module with > just standard graphic calls. However, wxPython has a very nice plot > control:PyPlot. It has lots of nice options, including ways to save the > plot easily. > > BUT, it requires numeric or numarray ? which have been superceded by numpy > or scipy. These are as available the main python package and provide a rich > scientific computing library for Python and wxPython. It looks like these > are available for all platforms either as binary or source files. However, > it would be another dependency. > > So what do you think? Should I install numpy (or scipy) and try the PyPlot > or just create these modules with simple graphics? > > Michael > __________________________________________ > Michael Barton, Professor of Anthropology > School of Human Evolution & Social Change > Center for Social Dynamics & Complexity > Arizona State University > > phone: 480-965-6213 > fax: 480-965-7671 > www: http://www.public.asu.edu/~cmbarton -- Yann Chemin Sainte-Anne d'Auray, France From wollez at gmx.net Sun Apr 22 10:25:27 2007 From: wollez at gmx.net (wolle) Date: Sun Apr 22 10:25:46 2007 Subject: [GRASS-dev] numeric-numpy-scipy for graphs? In-Reply-To: References: Message-ID: Hi, have a look at matplotlib http://matplotlib.sourceforge.net/ . It depends on numeric. Wolfgang Michael Barton wrote: > We need to create a graph/plot for at least 2 functions in the wxgrass > GUI?profile plotting and histogramming. I did the TclTk profile module > with just standard graphic calls. However, wxPython has a very nice plot > control:PyPlot. It has lots of nice options, including ways to save the > plot easily. > > BUT, it requires numeric or numarray ? which have been superceded by > numpy or scipy. These are as available the main python package and > provide a rich scientific computing library for Python and wxPython. It > looks like these are available for all platforms either as binary or > source files. However, it would be another dependency. > > So what do you think? Should I install numpy (or scipy) and try the > PyPlot or just create these modules with simple graphics? > > Michael > __________________________________________ > Michael Barton, Professor of Anthropology > School of Human Evolution & Social Change > Center for Social Dynamics & Complexity > Arizona State University > > phone: 480-965-6213 > fax: 480-965-7671 > www: http://www.public.asu.edu/~cmbarton > > > ------------------------------------------------------------------------ > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From hamish_nospam at yahoo.com Sun Apr 22 11:54:50 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Sun Apr 22 11:55:18 2007 Subject: [GRASS-dev] numeric-numpy-scipy for graphs? In-Reply-To: References: Message-ID: <20070422215450.11bdeba9.hamish_nospam@yahoo.com> Michael Barton wrote: > We need to create a graph/plot for at least 2 functions in the wxgrass > GUI?profile plotting and histogramming. I did the TclTk profile module > with just standard graphic calls. However, wxPython has a very nice > plot control:PyPlot. It has lots of nice options, including ways to > save the plot easily. maybe you are looking for something more advanced, but can it be done with d.graph and/or d.linegraph? I've never actually used d.linegraph, but would be willing to help bring it up to speed if it is useful but for a few small rendering issues. Hamish From mmaldacker at gmail.com Sun Apr 22 12:19:36 2007 From: mmaldacker at gmail.com (maximilian maldacker) Date: Sun Apr 22 12:19:39 2007 Subject: [GRASS-dev] path.obstacles Message-ID: Hello Thank you for your comments on my module proposition and taking your propositions in account I was thinking of develop ping the module the following way I will firstly create a library to create visibility graphs from a vector space containing obstacles ( polygons ). It will be completely independent of GRASS and I will put it in a subfolder of the folder v.path.obstacles. I will then create a second layer which will use GRASS vector library and directed graph library to construct the visibility graph ( using the abstract library ), this will be in several files in the v.path.obstacles. Then I will create a main file for the actual module which will be command based only with input a vector map and several points ( to compute several paths ) and output a vector map. Once this is done, I think I could maybe implement a module d.path.obstacleswith a graphical interface similar to d.path. It will access the 2nd layer headers in the v.path.obstacles folder. Would that be the best way to do? Because otherwise I don't really see where to put it, except to add it in the directed graph library. So in fact I will create module in a structure similar to v.net.path and d.path ( a command line module only, and then a graphical interface ). Would that make everyone happy? Tanks, Maximilian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070422/3fc213e0/attachment.html From grass-codei at wald.intevation.org Sun Apr 22 12:57:17 2007 From: grass-codei at wald.intevation.org (grass-codei@wald.intevation.org) Date: Sun Apr 22 12:57:23 2007 Subject: [GRASS-dev] [grass-code I][378] v.distance: bogus distances for Lat/Lon locations Message-ID: <20070422105717.D25251973FB5@pyrosoma.intevation.org> code I item #378, was opened at 2007-04-22 22:57 Status: Open Priority: 3 Submitted By: Hamish Bowman (hamish) Assigned to: Nobody (None) Summary: v.distance: bogus distances for Lat/Lon locations Issue type: module bug Issue status: None GRASS version: 6.2 GRASS component: vector Operating system: all Operating system version: GRASS CVS checkout date, if applies (YYMMDD): Initial Comment: Hi, v.distance in a lat/lon location gives distances in degrees, which is useless in most cases as lat and lon are not equally scaled and the result is a line at some given angle. [v.distance/main.c line 470] tseg = Vect_line_distance ( TPoints, FPoints->x[0], FPoints->y[0], 0, 0, &tmp_tx, &tmp_ty, NULL, &tmp_dist, NULL, &tmp_talong); >>From looking at lib/vector/Vlib/line.c Vect_line_distance() and lib/vector/diglib/line_dist.c dig_distance2_point_to_line() I take it Vect_line_distance() is assuming euclidian space. perhaps Vect_line_distance() should be using Vect_line_geodesic_length(), or more simply G_geodesic_distance(), when (G_projection() == PROJECTION_LL) ? thanks, Hamish ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=378&group_id=21 From hamish_nospam at yahoo.com Sun Apr 22 13:19:50 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Sun Apr 22 13:20:01 2007 Subject: [GRASS-dev] any way to know color assigned to a cell? In-Reply-To: <17950.48109.88914.169521@cerise.gclements.plus.com> References: <17950.48109.88914.169521@cerise.gclements.plus.com> Message-ID: <20070422231950.6abc0ba8.hamish_nospam@yahoo.com> Glynn Clements wrote: > Yeah; we could probably do with a "r.what.colors" module. Hi, I notice r.what.color outputs colors as follows: fprintf(stdout, "%d: %02x:%02x:%02x\n", ival, red, grn, blu); ie ff:ff:ff the rest of GRASS uniformly uses/expects %d:%d:%d (255:255:255) for that. suggestion: either use 0x%02x%02x%02x (0xaabbcc) if output is primariliy meant for sending to Tcl, or %d:%d:%d (255:255:255) if meant to be useful to GRASS. "ff:ff:ff" seems to be a mix of methods and an anomaly. or is there another reason? what RGB triplet pattern does xwPython prefer? Hamish From hamish_nospam at yahoo.com Sun Apr 22 14:00:07 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Sun Apr 22 14:00:39 2007 Subject: [GRASS-dev] d.vect.chart legends In-Reply-To: References: <20070422000122.3121d068.hamish_nospam@yahoo.com> Message-ID: <20070423000007.65d4f949.hamish_nospam@yahoo.com> Hamish: > > I just added a new -l flag to d.vect.chart to output info needed to > > create legends for charts. Previously you just got different colors > > with no reference to which columns they represented (using default > > colors). > > > > this can be parsed to make a legend, either using d.graph (like > > d.vect.thematic does) or by storing the info in a raster map's > > metadata and using d.legend to make the map Michael Barton wrote: > This is conceptually a nice way for getting legends for a vector map, > using the tools we now have. There have been repeated requests for a > way to get legends for vector maps. Could this be systematized somehow > in a script, or better in the vector code, in some way. > > For example, a flag that would automatically create a tiny legend > raster that could be used with d.legend. This could be built out of: > the RGB column for vectors, out of random vector colors, built with a > script for d.vect.thematic (until the C version is done), created for > d.vect.chart like you did for text output. I consider the mini-raster map method an Add-on hack- you get lots of tmp_chart_$$ raster maps left over in your mapset. Not a satisfactory solution for the main distribution. I guess the best solution is to add categorical vector legends to d.legend. This would reuse the integer CELL map legend code to draw filled boxes[, cat number][, and labels], using cat # and RGBCOLOR column from a DB table. Note in the posted script I use the raw column name as the cat label. In production you'd probably want to edit that to something nicer (eg >10 chars). At least in the d.vect.chart case divining nice labels from the input vector map isn't really an option, so I'm not sure how to do that beyond either a) adding an option to d.vect.chart with ';' sep labels, or b) creating a new DB table from the output of 'd.v.chart -l', then leave it to the user reset the label column themselves if they want. Using (b) would mean d.legend didn't care about vector maps, only DB tables in the form of: "cat|label|color". Which might not be such a bad solution as it is very flexible. An intermediary shell script awk'ing v.db.select should be able to create that from a vector map in thematic cases??? (I've never had the need to do thematic vector mapping in GRASS, so I can't really appreciate the required dataflow) Note the d.vect.chart legend is formed from the columns= and colors= options, not anything to do with the vector map. Another complication is that I didn't functionalize d.legend when I had the chance, and now it is a very large and very fragile piece of code. As it is currently working very well I am a bit loathe to touch it. I fear to functionalize the module will require a lot of (module) global variables, which defeats the purpose IMO (result is still logically messy). Perhaps start over with a clean legend module/tool/lib fn which takes "cat|label|color" as input and farm out all rast+vect categorical legends to that? You'd have to pass on all the rendering info, so it's still problematic and doesn't gain you much abstraction. Hamish From woklist at kyngchaos.com Sun Apr 22 17:16:48 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Sun Apr 22 17:17:00 2007 Subject: [GRASS-dev] Re: [GRASSGUI] numeric-numpy-scipy for graphs? In-Reply-To: References: Message-ID: <5E0905E2-C9BA-4D03-9038-37AD187C7762@kyngchaos.com> I wouldn't mind. As a bit of perspective, the GDAL Python interface uses Numeric for it's old bindings and Numpy for its new bindings, so either will be something many GRASS users will probably have. On Apr 22, 2007, at 1:45 AM, Michael Barton wrote: > We need to create a graph/plot for at least 2 functions in the > wxgrass GUI?profile plotting and histogramming. I did the TclTk > profile module with just standard graphic calls. However, wxPython > has a very nice plot control:PyPlot. It has lots of nice options, > including ways to save the plot easily. > > BUT, it requires numeric or numarray ? which have been superceded > by numpy or scipy. These are as available the main python package > and provide a rich scientific computing library for Python and > wxPython. It looks like these are available for all platforms > either as binary or source files. However, it would be another > dependency. > > So what do you think? Should I install numpy (or scipy) and try the > PyPlot or just create these modules with simple graphics? > ----- William Kyngesburye http://www.kyngchaos.com/ "Oh, look, I seem to have fallen down a deep, dark hole. Now what does that remind me of? Ah, yes - life." - Marvin From michael.barton at asu.edu Sun Apr 22 19:21:36 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sun Apr 22 19:21:50 2007 Subject: [GRASS-dev] numeric-numpy-scipy for graphs? In-Reply-To: <200704221403.35590.yann.chemin@gmail.com> Message-ID: On 4/22/07 12:03 AM, "Yann" wrote: > Based on your previous experience with TclTk: > > using pyplot, do you forecast less pain/less time for coding the same and > better quality of GUI interface because of mentioned advantages? I don't know yet. I haven't installed scipy and so haven't seen what pyplot does. I wanted to make sure that it was worth the effort on my part to test it out before doing so. There have been enough positive replies that I'll go ahead and work on installing scipy (the successor to numeric/numarray->numpy) to try this out. If this becomes a general GRASS dependency, I could see some very positive results in having a sophisticated scientific computation toolkit available for scripting. Michael > > if yes, +1 to the added dependency. > > yann __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Sun Apr 22 19:21:55 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sun Apr 22 19:22:07 2007 Subject: [GRASS-dev] numeric-numpy-scipy for graphs? In-Reply-To: Message-ID: Really impressive! Michael On 4/22/07 1:25 AM, "wolle" wrote: > Hi, > > have a look at matplotlib http://matplotlib.sourceforge.net/ . It > depends on numeric. > > Wolfgang > > Michael Barton wrote: >> We need to create a graph/plot for at least 2 functions in the wxgrass >> GUI?profile plotting and histogramming. I did the TclTk profile module >> with just standard graphic calls. However, wxPython has a very nice plot >> control:PyPlot. It has lots of nice options, including ways to save the >> plot easily. >> >> BUT, it requires numeric or numarray ? which have been superceded by >> numpy or scipy. These are as available the main python package and >> provide a rich scientific computing library for Python and wxPython. It >> looks like these are available for all platforms either as binary or >> source files. However, it would be another dependency. >> >> So what do you think? Should I install numpy (or scipy) and try the >> PyPlot or just create these modules with simple graphics? >> >> Michael >> __________________________________________ >> Michael Barton, Professor of Anthropology >> School of Human Evolution & Social Change >> Center for Social Dynamics & Complexity >> Arizona State University >> >> phone: 480-965-6213 >> fax: 480-965-7671 >> www: http://www.public.asu.edu/~cmbarton >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> grass-dev mailing list >> grass-dev@grass.itc.it >> http://grass.itc.it/mailman/listinfo/grass-dev > > __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Sun Apr 22 19:26:39 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sun Apr 22 19:26:52 2007 Subject: [GRASS-dev] numeric-numpy-scipy for graphs? In-Reply-To: <20070422215450.11bdeba9.hamish_nospam@yahoo.com> Message-ID: Thanks Hamish, In fact, we can do considerably more now with the wxPython (and TclTk) drawing commands to than is available in d.graph or d.linegraph, even with your nice enhancements. In the case of histogramming and profiling, it seems a better display to have them come up in a separate window (like is now the case with the TclTk profiling module) than have them rendered like a map in the main display (like we do now for d.histogram in the current TclTk GUI). Rendering maps is complex and it doesn't seem efficient to have to go through the same complex procedures to draw a histogram or profile that doesn't need to be drawn georeferenced. For this reason, it seems better to do these kinds of analyses with the gui tools, using underlying GRASS modules like r.profile and r.stats. Michael On 4/22/07 2:54 AM, "Hamish" wrote: > Michael Barton wrote: >> We need to create a graph/plot for at least 2 functions in the wxgrass >> GUI?profile plotting and histogramming. I did the TclTk profile module >> with just standard graphic calls. However, wxPython has a very nice >> plot control:PyPlot. It has lots of nice options, including ways to >> save the plot easily. > > maybe you are looking for something more advanced, but can it be done > with d.graph and/or d.linegraph? I've never actually used d.linegraph, > but would be willing to help bring it up to speed if it is useful but > for a few small rendering issues. > > > Hamish > > __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From glynn at gclements.plus.com Sun Apr 22 20:41:11 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Apr 22 20:41:18 2007 Subject: [GRASSGUI] Re: [GRASS-dev] numeric-numpy-scipy for graphs? In-Reply-To: References: <20070422215450.11bdeba9.hamish_nospam@yahoo.com> Message-ID: <17963.44103.516371.612995@cerise.gclements.plus.com> Michael Barton wrote: > In fact, we can do considerably more now with the wxPython (and TclTk) > drawing commands to than is available in d.graph or d.linegraph, even with > your nice enhancements. > > In the case of histogramming and profiling, it seems a better display to > have them come up in a separate window (like is now the case with the TclTk > profiling module) than have them rendered like a map in the main display > (like we do now for d.histogram in the current TclTk GUI). Rendering maps is > complex and it doesn't seem efficient to have to go through the same complex > procedures to draw a histogram or profile that doesn't need to be drawn > georeferenced. > > For this reason, it seems better to do these kinds of analyses with the gui > tools, using underlying GRASS modules like r.profile and r.stats. Even if you decide not to use the existing graphics API, I would still suggest that any functionality which could reasonably be used non-interactively can be. -- Glynn Clements From michael.barton at asu.edu Sun Apr 22 20:44:34 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sun Apr 22 20:44:43 2007 Subject: [GRASSGUI] Re: [GRASS-dev] numeric-numpy-scipy for graphs? In-Reply-To: <17963.44103.516371.612995@cerise.gclements.plus.com> Message-ID: I agree that these functions should be maintained and even enhanced, especially for scripting. Michael On 4/22/07 11:41 AM, "Glynn Clements" wrote: > > Michael Barton wrote: > >> In fact, we can do considerably more now with the wxPython (and TclTk) >> drawing commands to than is available in d.graph or d.linegraph, even with >> your nice enhancements. >> >> In the case of histogramming and profiling, it seems a better display to >> have them come up in a separate window (like is now the case with the TclTk >> profiling module) than have them rendered like a map in the main display >> (like we do now for d.histogram in the current TclTk GUI). Rendering maps is >> complex and it doesn't seem efficient to have to go through the same complex >> procedures to draw a histogram or profile that doesn't need to be drawn >> georeferenced. >> >> For this reason, it seems better to do these kinds of analyses with the gui >> tools, using underlying GRASS modules like r.profile and r.stats. > > Even if you decide not to use the existing graphics API, I would still > suggest that any functionality which could reasonably be used > non-interactively can be. __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From glynn at gclements.plus.com Sun Apr 22 20:59:10 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Apr 22 20:59:13 2007 Subject: [GRASS-dev] any way to know color assigned to a cell? In-Reply-To: <20070422231950.6abc0ba8.hamish_nospam@yahoo.com> References: <17950.48109.88914.169521@cerise.gclements.plus.com> <20070422231950.6abc0ba8.hamish_nospam@yahoo.com> Message-ID: <17963.45182.795488.930033@cerise.gclements.plus.com> Hamish wrote: > > Yeah; we could probably do with a "r.what.colors" module. > > I notice r.what.color outputs colors as follows: > > fprintf(stdout, "%d: %02x:%02x:%02x\n", ival, red, grn, blu); > > ie ff:ff:ff > > the rest of GRASS uniformly uses/expects %d:%d:%d (255:255:255) for that. Ah; I'll add an option for the output format, defaulting to %d:%d:%d. -- Glynn Clements From yann.chemin at gmail.com Sun Apr 22 21:05:30 2007 From: yann.chemin at gmail.com (Yann) Date: Sun Apr 22 21:05:42 2007 Subject: [GRASS-dev] numeric-numpy-scipy for graphs? In-Reply-To: References: Message-ID: <200704230205.30289.yann.chemin@gmail.com> http://matplotlib.sourceforge.net/screenshots/plotmap_large.png Really nice ! On Sunday 22 April 2007 15:25, wolle wrote: > Hi, > > have a look at matplotlib http://matplotlib.sourceforge.net/ . It > depends on numeric. > > Wolfgang > > Michael Barton wrote: > > We need to create a graph/plot for at least 2 functions in the wxgrass > > GUI?profile plotting and histogramming. I did the TclTk profile module > > with just standard graphic calls. However, wxPython has a very nice plot > > control:PyPlot. It has lots of nice options, including ways to save the > > plot easily. > > > > BUT, it requires numeric or numarray ? which have been superceded by > > numpy or scipy. These are as available the main python package and > > provide a rich scientific computing library for Python and wxPython. It > > looks like these are available for all platforms either as binary or > > source files. However, it would be another dependency. > > > > So what do you think? Should I install numpy (or scipy) and try the > > PyPlot or just create these modules with simple graphics? > > > > Michael > > __________________________________________ > > Michael Barton, Professor of Anthropology > > School of Human Evolution & Social Change > > Center for Social Dynamics & Complexity > > Arizona State University > > > > phone: 480-965-6213 > > fax: 480-965-7671 > > www: http://www.public.asu.edu/~cmbarton > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > grass-dev mailing list > > grass-dev@grass.itc.it > > http://grass.itc.it/mailman/listinfo/grass-dev > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev -- Yann Chemin Sainte-Anne d'Auray, France From twiens at interbaun.com Sun Apr 22 22:18:06 2007 From: twiens at interbaun.com (Trevor Wiens) Date: Sun Apr 22 22:11:09 2007 Subject: [GRASSGUI] Re: [GRASS-dev] numeric-numpy-scipy for graphs? In-Reply-To: References: <17963.44103.516371.612995@cerise.gclements.plus.com> Message-ID: <20070422141806.67e36ad2@localhost.localdomain> On Sun, 22 Apr 2007 11:44:34 -0700 Michael Barton wrote: > I agree that these functions should be maintained and even enhanced, > especially for scripting. > As discussed a long time ago on the list, there is no reason why a wrapper function couldn't be created in python to make calls to the GUI from the command line, to allow for scripted control of the GUI using sockets (not Unix specific ones). One socket could be listened to by the GUI and the command line wrapper would simply pass calls to that socket thus allowing CLI access. I had planned to develop this myself, but being up to my ass in alligators (figuratively speaking) I've not had the time. If there is good functionality available through wxGRASS, why maintain another version of a similar function. It could be argued that some users would prefer to avoid the overhead of a GUI, but for them, there are older versions of GRASS. AFAIC duplication is a bad thing. In the similar vein to Python, there should be one obvious way to do things. GRASS is already so big, we don't need more duplication. So I would vote for inclusion of scipy for graphing and planning the obsolescence of the older means. T -- Trevor Wiens twiens@interbaun.com The significant problems that we face cannot be solved at the same level of thinking we were at when we created them. (Albert Einstein) From glynn at gclements.plus.com Sun Apr 22 22:31:49 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Apr 22 22:33:42 2007 Subject: [GRASSGUI] Re: [GRASS-dev] numeric-numpy-scipy for graphs? In-Reply-To: <20070422141806.67e36ad2@localhost.localdomain> References: <17963.44103.516371.612995@cerise.gclements.plus.com> <20070422141806.67e36ad2@localhost.localdomain> Message-ID: <17963.50741.249087.579531@cerise.gclements.plus.com> Trevor Wiens wrote: > > I agree that these functions should be maintained and even enhanced, > > especially for scripting. > > As discussed a long time ago on the list, there is no reason why a > wrapper function couldn't be created in python to make calls to the GUI > from the command line, to allow for scripted control of the GUI using > sockets (not Unix specific ones). One socket could be listened to by > the GUI and the command line wrapper would simply pass calls to that > socket thus allowing CLI access. I had planned to develop this myself, > but being up to my ass in alligators (figuratively speaking) I've not > had the time. Being able to remote-control the GUI is a separate issue. Functionality (including creating graphics) should be available in an environment where you cannot create a window (no X server, no X libs). -- Glynn Clements From sydv at sjgeophysics.com Sun Apr 22 22:36:04 2007 From: sydv at sjgeophysics.com (Syd Visser) Date: Sun Apr 22 22:35:41 2007 Subject: [GRASS-dev] Re: numeric-numpy-scipy for graphs? In-Reply-To: <200704221905.l3MJ5swN017990@grass.itc.it> References: <200704221905.l3MJ5swN017990@grass.itc.it> Message-ID: <462BC734.80302@sjgeophysics.com> We use enthought open source tool suite http://www.enthought.com/ which contains Numpy, SciPi and numerous other packages. our main use is with Matplotlib and Chaco for 2D graphs and MayaVi2 for 3D graphics I think these packages would be well worth having a close look at especially MayaVi2 (Python wrapped VTK) for the 3D graphics. thanks Syd -- ///////////////////////////////////// Syd Visser P.Geo SJ Geophysics Ltd. sydv@sjgeophysics.com www.sjgeophysics.com From soerengebbert at gmx.de Sun Apr 22 22:46:31 2007 From: soerengebbert at gmx.de (=?ISO-8859-1?Q?S=F6ren_Gebbert?=) Date: Sun Apr 22 22:46:38 2007 Subject: [GRASS-dev] Re: numeric-numpy-scipy for graphs? In-Reply-To: <462BC734.80302@sjgeophysics.com> References: <200704221905.l3MJ5swN017990@grass.itc.it> <462BC734.80302@sjgeophysics.com> Message-ID: <462BC9A7.50407@gmx.de> Hi, Syd Visser schrieb: > We use enthought open source tool suite http://www.enthought.com/ which > contains Numpy, SciPi and numerous other packages. > our main use is with Matplotlib and Chaco for 2D graphs and MayaVi2 for > 3D graphics > I think these packages would be well worth having a close look at > especially MayaVi2 (Python wrapped VTK) for the 3D graphics. I would like to prefer a C++ grass data server + grass gui plugin for paraview3 to visualize 3d data. This would a nice and fast solution. Best regards Soeren > > thanks > Syd > From sydv at sjgeophysics.com Sun Apr 22 23:05:17 2007 From: sydv at sjgeophysics.com (Syd Visser) Date: Sun Apr 22 23:04:50 2007 Subject: [GRASS-dev] Re: numeric-numpy-scipy for graphs? In-Reply-To: <462BC9A7.50407@gmx.de> References: <200704221905.l3MJ5swN017990@grass.itc.it> <462BC734.80302@sjgeophysics.com> <462BC9A7.50407@gmx.de> Message-ID: <462BCE0D.1040805@sjgeophysics.com> Soren Paraview3 uses Qt and MayaVi2 uses Wxpython thus we are leaning more towards MayaVi2 although we use Paraview2.6 extensively but strictly as a viewer. We find MayaVi2 is also more open to user development thus easier to extend. Thanks Syd S?ren Gebbert wrote: > Hi, > > Syd Visser schrieb: >> We use enthought open source tool suite http://www.enthought.com/ >> which contains Numpy, SciPi and numerous other packages. >> our main use is with Matplotlib and Chaco for 2D graphs and MayaVi2 >> for 3D graphics >> I think these packages would be well worth having a close look at >> especially MayaVi2 (Python wrapped VTK) for the 3D graphics. > > I would like to prefer a C++ grass data server + grass gui plugin for > paraview3 > to visualize 3d data. This would a nice and fast solution. > > Best regards > Soeren > >> >> thanks >> Syd >> > > -- ///////////////////////////////////// Syd Visser P.Geo SJ Geophysics Ltd. sydv@sjgeophysics.com www.sjgeophysics.com From wollez at gmx.net Sun Apr 22 23:05:46 2007 From: wollez at gmx.net (Wolfgang) Date: Sun Apr 22 23:06:26 2007 Subject: [GRASS-dev] Re: numeric-numpy-scipy for graphs? In-Reply-To: <462BC9A7.50407@gmx.de> References: <200704221905.l3MJ5swN017990@grass.itc.it> <462BC734.80302@sjgeophysics.com> <462BC9A7.50407@gmx.de> Message-ID: S?ren Gebbert wrote: > Hi, > > Syd Visser schrieb: >> We use enthought open source tool suite http://www.enthought.com/ >> which contains Numpy, SciPi and numerous other packages. >> our main use is with Matplotlib and Chaco for 2D graphs and MayaVi2 >> for 3D graphics >> I think these packages would be well worth having a close look at >> especially MayaVi2 (Python wrapped VTK) for the 3D graphics. > > I would like to prefer a C++ grass data server + grass gui plugin for > paraview3 > to visualize 3d data. This would a nice and fast solution. > > Best regards > Soeren > >> >> thanks >> Syd >> I would also vote for a better connection between grass and vtk. There are direct wrappers to vtk from python, so that Mayavi is obsolete? Wolfgang From twiens at interbaun.com Sun Apr 22 23:30:56 2007 From: twiens at interbaun.com (Trevor Wiens) Date: Sun Apr 22 23:23:58 2007 Subject: [GRASSGUI] Re: [GRASS-dev] numeric-numpy-scipy for graphs? In-Reply-To: <17963.50741.249087.579531@cerise.gclements.plus.com> References: <17963.44103.516371.612995@cerise.gclements.plus.com> <20070422141806.67e36ad2@localhost.localdomain> <17963.50741.249087.579531@cerise.gclements.plus.com> Message-ID: <20070422153056.175398fd@localhost.localdomain> On Sun, 22 Apr 2007 21:31:49 +0100 Glynn Clements wrote: > > Trevor Wiens wrote: > > > > I agree that these functions should be maintained and even enhanced, > > > especially for scripting. > > > > As discussed a long time ago on the list, there is no reason why a > > wrapper function couldn't be created in python to make calls to the GUI > > from the command line, to allow for scripted control of the GUI using > > sockets (not Unix specific ones). One socket could be listened to by > > the GUI and the command line wrapper would simply pass calls to that > > socket thus allowing CLI access. I had planned to develop this myself, > > but being up to my ass in alligators (figuratively speaking) I've not > > had the time. > > Being able to remote-control the GUI is a separate issue. > > Functionality (including creating graphics) should be available in an > environment where you cannot create a window (no X server, no X libs). In that case why not allow users to export their data to R and use that or pipe to another graph producing package like ploticus (which I've used extensively and found to be excellent as it includes CMYK eps output options, and much better than any other of the products suggested in this discussion so far IMHO). Neither of these solutions would require as much work as maintaining duplicate modules which produce lower quality results. Yes, it is an additional dependency, but a general management rule states one should manage for the majority and treat special cases individually. I would expect that the majority of users use GRASS in a windowing environment, so we are talking about a very small portion of the user base, no? Another option would be to use a single solution that can be used in all cases. If this were to be the case I would vote for serious consideration being given to ploticus. FYI, Steve Grubb also has a small postscript library which supports CMYK, which we might want to look at using to enhance the ps output options with the d.* modules. I'm not trying to make things complicated, but I'm trying to make sure we don't waste effort recreating things that already exist and good. One of my current projects is producing a book on birds for which I produced almost 600 graphs as CMYK eps files. Matplotlib couldn't do it. GnuPlot sucks IMHO. PyX was as user friendly as a poke in the eye, although the list people were very nice. I was able to do what I needed with ploticus within half a day of looking at it and could continue to customize it as needed. It may appear a bit old fashioned compared to some of the Python plotting products, but it is easily understood, provides fine control when needed, and produces output in a variety of formats. No GUI required. If we wrote wrapper to use it, the output could be displayed in a separate window or written to file. T -- Trevor Wiens twiens@interbaun.com The significant problems that we face cannot be solved at the same level of thinking we were at when we created them. (Albert Einstein) From soerengebbert at gmx.de Mon Apr 23 01:31:33 2007 From: soerengebbert at gmx.de (=?ISO-8859-1?Q?S=F6ren_Gebbert?=) Date: Mon Apr 23 01:31:41 2007 Subject: [GRASS-dev] Replacement of NVIZ In-Reply-To: <462BCE0D.1040805@sjgeophysics.com> References: <200704221905.l3MJ5swN017990@grass.itc.it> <462BC734.80302@sjgeophysics.com> <462BC9A7.50407@gmx.de> <462BCE0D.1040805@sjgeophysics.com> Message-ID: <462BF055.4000500@gmx.de> Syd, Syd Visser schrieb: > Soren > > Paraview3 uses Qt and MayaVi2 uses Wxpython thus we are leaning more > towards MayaVi2 although we use Paraview2.6 extensively but strictly as > a viewer. > We find MayaVi2 is also more open to user development thus easier to > extend. I'm developing with VTK and Qt since several years and have used ParaView1-2 for several years. My experience with MayaVi is little, because the user interface was too horrible. IMHO ParaView3 is the better choice. It has a sophisticated but very intuitive user interface and is developed by well known institutes and kitware. And they are doing a great job. ParaView is designed to visualize huge datasets in parallel. MayaVi2 depends on Traits, TVTK, Envisage and wxPython. A lot of new dependencies (except wxPython). And for now i'm not able to get even the new grass wxPython gui to run on my debian etch system because of the dependencies. ParaView3 depends only on Qt4.2. Qt is available for many, many platforms as well as VTK. (i still don't understand why wxWidgets and python was choosen for the new grass gui and not Qt and python ...) The only thing we need to provide is a data server and gui plugin for ParaView3: http://www.paraview.org/Wiki/Plugin_HowTo And when ParaView3 reaches a stable state and i have some spare time i'm absolutely willingly to implement them! IMHO the data server and the reader/writer to the grass database (grass data should be modified with Paraview3 and stored back into the grass database :) if possible) should be implemented in C++ for performance reasons. I would not use the grass python wrapper to get the data into a visualization system. The grass raster, voxel and vector functions can be accessed from C++ code directly. The data server should provide access to the grass database to read and write raster, volume and vector data. And ParaView3 should be extended with a nice little Qt gui to access the grass data directly from the toolbar (like Qgis). We don't need to touch the ParaView3 sources, we only need to implement plugins. A screenshot of ParaView3 handling grass raster, volume and vector data (exported with the *.out.vtk modules) is available here: http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/ParaView3_Screenshot_grass_data.png Just my two cents ... sorry for my English Best regards Soeren > > Thanks > Syd > > S?ren Gebbert wrote: >> Hi, >> >> Syd Visser schrieb: >>> We use enthought open source tool suite http://www.enthought.com/ >>> which contains Numpy, SciPi and numerous other packages. >>> our main use is with Matplotlib and Chaco for 2D graphs and MayaVi2 >>> for 3D graphics >>> I think these packages would be well worth having a close look at >>> especially MayaVi2 (Python wrapped VTK) for the 3D graphics. >> >> I would like to prefer a C++ grass data server + grass gui plugin for >> paraview3 >> to visualize 3d data. This would a nice and fast solution. >> >> Best regards >> Soeren >> >>> >>> thanks >>> Syd >>> >> >> > From michael.barton at asu.edu Mon Apr 23 05:03:39 2007 From: michael.barton at asu.edu (Michael Barton) Date: Mon Apr 23 05:03:49 2007 Subject: [GRASS-dev] minor issue with compiling Mac version of GRASS 6.3 cvs Message-ID: Something I?ve been meaning to mention for awhile (but haven?t gotten around to it because it is fairly minor) is that every time I compile after a make distclean or make clean, I have ... Errors in: /Users/cmbarton/grass_dev/grass6/lib/proj /Users/cmbarton/grass_dev/grass6/gui/tcltk/d.m If I change to the relevant directories and run make, they compile just fine, and I have no more problem until I do a distclean or clean again. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070422/4f298435/attachment.html From woklist at kyngchaos.com Mon Apr 23 05:24:06 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Mon Apr 23 05:24:18 2007 Subject: [GRASS-dev] Re: minor issue with compiling Mac version of GRASS 6.3 cvs In-Reply-To: References: Message-ID: <194DB35B-48B9-4C8D-AABD-5E5DD4EF27FA@kyngchaos.com> On Apr 22, 2007, at 10:03 PM, Michael Barton wrote: > Something I?ve been meaning to mention for awhile (but haven?t > gotten around to it because it is fairly minor) is that every time > I compile after a make distclean or make clean, I have ... > Scoll up in the make output to find why these failed (I usually Find the string '***' to locate make errors). > Errors in: > /Users/cmbarton/grass_dev/grass6/lib/proj > /Users/cmbarton/grass_dev/grass6/gui/tcltk/d.m > > If I change to the relevant directories and run make, they compile > just fine, and I have no more problem until I do a distclean or > clean again. > ----- William Kyngesburye http://www.kyngchaos.com/ "History is an illusion caused by the passage of time, and time is an illusion caused by the passage of history." - Hitchhiker's Guide to the Galaxy From michael.barton at asu.edu Mon Apr 23 05:40:17 2007 From: michael.barton at asu.edu (Michael Barton) Date: Mon Apr 23 05:40:21 2007 Subject: [GRASS-dev] Re: numeric-numpy-scipy for graphs? In-Reply-To: <462BC734.80302@sjgeophysics.com> Message-ID: Following up on this and the many other interesting posts to this thread... I asked if anyone objected to having numpy or scipy (incluing numpy) as a dependency for the new wxPython GUI. The response has been overwhelmingly in favor, pointing out the many things possible with this kind of package. I just want to use it to make nicer plotting easier (e.g., for profiling and histogramming) in the GUI, but obviously it has other uses. And of course, there are a number of other even more sophisticated plotting/graphing packages that also run under wxPython and scipy. Michael On 4/22/07 1:36 PM, "Syd Visser" wrote: > We use enthought open source tool suite http://www.enthought.com/ which > contains Numpy, SciPi and numerous other packages. > our main use is with Matplotlib and Chaco for 2D graphs and MayaVi2 for > 3D graphics > I think these packages would be well worth having a close look at > especially MayaVi2 (Python wrapped VTK) for the 3D graphics. > > thanks > Syd __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Mon Apr 23 05:48:26 2007 From: michael.barton at asu.edu (Michael Barton) Date: Mon Apr 23 05:48:32 2007 Subject: [GRASS-dev] Replacement of NVIZ In-Reply-To: <462BF055.4000500@gmx.de> Message-ID: It's great that we can export GRASS data to be used in high-end multi-dimensional visualization platforms like Paraview and MayVi2. I've used Paraview a bit. I wouldn't call it easy or intuitive, but it is quite sophisticated and powerful--though not particularly fast in my experience. However, using any of these packages is not a replacement for NVIZ. NVIZ will let a user quickly and seamlessly render 2, 2.5, 3, and 4 dimensional data within a GRASS GIS session. This is a real bonus. And NVIZ does this better than any other rendering engine within a GIS that I've seen. In this sense, NVIZ has a different goal from Paraview and other dedicated multidemensional rendering packages. So I hope that we can get NVIZ ported to wxPython and make it an even more seamless part of the geospatial visualization tools for GRASS. Making tighter connections between GRASS and other, external visualization tools is also a worthy plan--similar to the integration between GRASS and R. But IMHO, we should not abandon NVIZ or something like it. Michael On 4/22/07 4:31 PM, "S?ren Gebbert" wrote: > Syd, > > Syd Visser schrieb: >> Soren >> >> Paraview3 uses Qt and MayaVi2 uses Wxpython thus we are leaning more >> towards MayaVi2 although we use Paraview2.6 extensively but strictly as >> a viewer. >> We find MayaVi2 is also more open to user development thus easier to >> extend. > > I'm developing with VTK and Qt since several years and have used ParaView1-2 > for several years. > My experience with MayaVi is little, because the user interface was too > horrible. > IMHO ParaView3 is the better choice. It has a sophisticated but very > intuitive user interface and is developed by well known institutes and > kitware. > And they are doing a great job. ParaView is designed to visualize huge > datasets in parallel. > > MayaVi2 depends on Traits, TVTK, Envisage and wxPython. A lot of new > dependencies (except wxPython). > And for now i'm not able to get even the new grass wxPython gui to run on my > debian etch system > because of the dependencies. > ParaView3 depends only on Qt4.2. Qt is available for many, many platforms as > well as VTK. > (i still don't understand why wxWidgets and python was choosen for the new > grass gui and not Qt > and python ...) > > The only thing we need to provide is a data server and gui plugin for > ParaView3: > http://www.paraview.org/Wiki/Plugin_HowTo > And when ParaView3 reaches a stable state and i have some spare time i'm > absolutely willingly to implement them! > > IMHO the data server and the reader/writer to the grass database > (grass data should be modified with Paraview3 and stored back into the grass > database :) if possible) > should be implemented in C++ for performance reasons. I would not use the > grass python wrapper > to get the data into a visualization system. The grass raster, voxel and > vector functions can be > accessed from C++ code directly. > > The data server should provide access to the grass database to read and write > raster, volume and vector data. > And ParaView3 should be extended with a nice little Qt gui to access the grass > data directly from the toolbar > (like Qgis). We don't need to touch the ParaView3 sources, we only need to > implement plugins. > > A screenshot of ParaView3 handling grass raster, volume and vector data > (exported with the *.out.vtk modules) > is available here: > http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/ParaView3_ > Screenshot_grass_data.png > > Just my two cents ... > > sorry for my English > Best regards > Soeren > >> >> Thanks >> Syd >> >> S?ren Gebbert wrote: >>> Hi, >>> >>> Syd Visser schrieb: >>>> We use enthought open source tool suite http://www.enthought.com/ >>>> which contains Numpy, SciPi and numerous other packages. >>>> our main use is with Matplotlib and Chaco for 2D graphs and MayaVi2 >>>> for 3D graphics >>>> I think these packages would be well worth having a close look at >>>> especially MayaVi2 (Python wrapped VTK) for the 3D graphics. >>> >>> I would like to prefer a C++ grass data server + grass gui plugin for >>> paraview3 >>> to visualize 3d data. This would a nice and fast solution. >>> >>> Best regards >>> Soeren >>> >>>> >>>> thanks >>>> Syd >>>> >>> >>> >> > > __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From glynn at gclements.plus.com Mon Apr 23 06:19:26 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Apr 23 06:19:36 2007 Subject: [GRASS-dev] numeric-numpy-scipy for graphs? In-Reply-To: References: Message-ID: <17964.13262.446768.863375@cerise.gclements.plus.com> Michael Barton wrote: > We need to create a graph/plot for at least 2 functions in the wxgrass > GUI‹profile plotting and histogramming. I did the TclTk profile module with > just standard graphic calls. However, wxPython has a very nice plot > control:PyPlot. It has lots of nice options, including ways to save the plot > easily. Can you provide a URL; the first thing that comes up for "PyPlot" on Google uses Python/Tk for the interface and gnuplot for the output: http://www.wadsworth.org/spider_doc/spider/docs/spire/guitools/pyplot.html The remainder of the first couple of pages are posts to mailing lists. > BUT, it requires numeric or numarray ‹ which have been superceded by numpy > or scipy. These are as available the main python package and provide a rich > scientific computing library for Python and wxPython. It looks like these > are available for all platforms either as binary or source files. However, > it would be another dependency. AFAICT, both NumPy and SciPy deal are primarily numerical packages; I can't see anything about graphics. -- Glynn Clements From hamish_nospam at yahoo.com Mon Apr 23 07:28:47 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Apr 23 07:28:58 2007 Subject: [GRASS-dev] Replacement of NVIZ In-Reply-To: <462BF055.4000500@gmx.de> References: <200704221905.l3MJ5swN017990@grass.itc.it> <462BC734.80302@sjgeophysics.com> <462BC9A7.50407@gmx.de> <462BCE0D.1040805@sjgeophysics.com> <462BF055.4000500@gmx.de> Message-ID: <20070423172847.37e76ea7.hamish_nospam@yahoo.com> S?ren Gebbert wrote: > And for now i'm not able to get even the new grass wxPython gui to run > on my debian etch system because of the dependencies. FWIW, once wxPython 2.8.x stabilizes into Debian/testing, I hope to backport the minimum requried packages* for GRASS GUI+1 to Etch. These could be hosted either at backports.org, DebianGIS's Alioth repo, or my google webspace. [*] python-wxgtk2.8 python-wxtools wx2.8-i18n ?? Hamish From hamish_nospam at yahoo.com Mon Apr 23 08:15:56 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Apr 23 08:16:04 2007 Subject: [GRASS-dev] numeric-numpy-scipy for graphs? In-Reply-To: References: Message-ID: <20070423181556.715a1b72.hamish_nospam@yahoo.com> > "wolle" wrote: > > have a look at matplotlib http://matplotlib.sourceforge.net/ . It > > depends on numeric. Michael Barton wrote: > Really impressive! oh, and by the way, IMO translucency is the neat way to go for bubble plots, not sorting by size before rendering and drawing the little ones on top (can lead to coin toss overlap results; you lose any order/time info in the data). e.g. study these two: http://matplotlib.sourceforge.net/screenshots/scatter_demo2_large.png and attached graphic (clipped from the NY Times online edition a few days ago) which demonstrates it quite well. Hamish -------------- next part -------------- A non-text attachment was scrubbed... Name: nyt_USpres_fundraising.gif Type: image/gif Size: 13491 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070423/e900ebba/nyt_USpres_fundraising-0001.gif From michael.barton at asu.edu Mon Apr 23 08:48:02 2007 From: michael.barton at asu.edu (Michael Barton) Date: Mon Apr 23 08:48:07 2007 Subject: [GRASS-dev] numeric-numpy-scipy for graphs? In-Reply-To: <20070423181556.715a1b72.hamish_nospam@yahoo.com> Message-ID: I agree about the translucency. Looks nice AND is more informative. Michael On 4/22/07 11:15 PM, "Hamish" wrote: >> "wolle" wrote: >>> have a look at matplotlib http://matplotlib.sourceforge.net/ . It >>> depends on numeric. > > Michael Barton wrote: >> Really impressive! > > > oh, and by the way, IMO translucency is the neat way to go for bubble > plots, not sorting by size before rendering and drawing the little ones > on top (can lead to coin toss overlap results; you lose any order/time > info in the data). > > e.g. study these two: > > http://matplotlib.sourceforge.net/screenshots/scatter_demo2_large.png > > and attached graphic (clipped from the NY Times online edition a few > days ago) which demonstrates it quite well. > > > Hamish __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From mlennert at club.worldonline.be Mon Apr 23 08:59:57 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Mon Apr 23 08:56:40 2007 Subject: [GRASSGUI] Re: [GRASS-dev] numeric-numpy-scipy for graphs? In-Reply-To: <17963.50741.249087.579531@cerise.gclements.plus.com> References: <17963.44103.516371.612995@cerise.gclements.plus.com> <20070422141806.67e36ad2@localhost.localdomain> <17963.50741.249087.579531@cerise.gclements.plus.com> Message-ID: <43811.85.10.68.191.1177311597.squirrel@geog-pc40.ulb.ac.be> On Sun, April 22, 2007 22:31, Glynn Clements wrote: > > Trevor Wiens wrote: > >> > I agree that these functions should be maintained and even enhanced, >> > especially for scripting. >> >> As discussed a long time ago on the list, there is no reason why a >> wrapper function couldn't be created in python to make calls to the GUI >> from the command line, to allow for scripted control of the GUI using >> sockets (not Unix specific ones). One socket could be listened to by >> the GUI and the command line wrapper would simply pass calls to that >> socket thus allowing CLI access. I had planned to develop this myself, >> but being up to my ass in alligators (figuratively speaking) I've not >> had the time. > > Being able to remote-control the GUI is a separate issue. > > Functionality (including creating graphics) should be available in an > environment where you cannot create a window (no X server, no X libs). +1 Moritz From dca.gis at gmail.com Mon Apr 23 08:56:43 2007 From: dca.gis at gmail.com (Daniel Calvelo) Date: Mon Apr 23 08:56:47 2007 Subject: [GRASS-dev] any way to know color assigned to a cell? In-Reply-To: <20070422231950.6abc0ba8.hamish_nospam@yahoo.com> References: <17950.48109.88914.169521@cerise.gclements.plus.com> <20070422231950.6abc0ba8.hamish_nospam@yahoo.com> Message-ID: <1a486f560704222356u28911cdbs80fced279a384e6f@mail.gmail.com> On 4/22/07, Hamish wrote: [...] > what RGB triplet pattern does xwPython prefer? Either (in printf format): "\"#%02x%02x%02x\"" (quotes included: a string may be given as color in the form of a wx color name or a hex triplet) or "(%d,%d,%d)" (an integer triplet, 0-255 values). So red is one of: "RED" "#FF0000" (255,0,0) Daniel. -- Daniel Calvelo Aros From paul-grass at stjohnspoint.co.uk Mon Apr 23 09:51:01 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Mon Apr 23 09:52:05 2007 Subject: [GRASS-dev] Re: numeric-numpy-scipy for graphs? In-Reply-To: References: Message-ID: Hello Michael On Sun, 22 Apr 2007, Michael Barton wrote: > Following up on this and the many other interesting posts to this thread... > > I asked if anyone objected to having numpy or scipy (incluing numpy) as a > dependency for the new wxPython GUI. The response has been overwhelmingly in > favor, pointing out the many things possible with this kind of package. > > I just want to use it to make nicer plotting easier (e.g., for profiling and > histogramming) in the GUI, but obviously it has other uses. And of course, > there are a number of other even more sophisticated plotting/graphing > packages that also run under wxPython and scipy. TBH I was being lazy and waiting for more information on what specifically it could be used for before giving an opinion... the names at least suggest they are primarily for numerical calculations etc. and not drawing graphics? I wonder do the parts of Pyplot you want to use even use anything in NumPy? Obviously numerical calculations and that kind of stuff is best done in C in the GRASS libraries and modules to make it available also for command-line and scripting use. I think that's the main issue here, that having NumPy available doesn't result in the GUI having lots of computational functionality that isn't available in the core of GRASS. but just my opinion Paul From paul-grass at stjohnspoint.co.uk Mon Apr 23 10:15:38 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Mon Apr 23 10:15:43 2007 Subject: [GRASS-dev] numeric-numpy-scipy for graphs? In-Reply-To: References: Message-ID: On Sun, 22 Apr 2007, Michael Barton wrote: > Thanks Hamish, > > In fact, we can do considerably more now with the wxPython (and TclTk) > drawing commands to than is available in d.graph or d.linegraph, even with > your nice enhancements. > > In the case of histogramming and profiling, it seems a better display to > have them come up in a separate window (like is now the case with the TclTk > profiling module) than have them rendered like a map in the main display > (like we do now for d.histogram in the current TclTk GUI). Rendering maps is > complex and it doesn't seem efficient to have to go through the same complex > procedures to draw a histogram or profile that doesn't need to be drawn > georeferenced. Another thought - with the enhancements to the display architecture in progress/idea stage, it might actually be possible to produce better quality graphs for inclusion in reports/papers etc. using the existing display architecture. I'm thinking of the move towards PostScript as a display output format. I imagine with pop-up Windows in the GUI with histograms etc. you would be limited to printing the thing as a raster graphic at the same resolution as the screen? Not so good. Unless those new python modules you're looking at perhaps have an option to save as postscript (I mean proper line-graphics postscript) for printing. And of course if you use GRASS modules to produce the graphs then as Glynn says it is also possible to produce them from scripts, which is rather important. (Rather than having all this functionality tied up in the GUI and having to re-implement it if we change the GUI). > For this reason, it seems better to do these kinds of analyses with the gui > tools, using underlying GRASS modules like r.profile and r.stats. I agree it "seemed" better/tidier/neater to me at first, but if we consider the display architecture is being enhanced beyond it's old clunky state it may not be as logical is it first seemed? Paul From glynn at gclements.plus.com Mon Apr 23 11:08:54 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Apr 23 11:09:03 2007 Subject: [GRASS-dev] Re: numeric-numpy-scipy for graphs? In-Reply-To: References: Message-ID: <17964.30630.226470.371251@cerise.gclements.plus.com> Paul Kelly wrote: > > Following up on this and the many other interesting posts to this thread... > > > > I asked if anyone objected to having numpy or scipy (incluing numpy) as a > > dependency for the new wxPython GUI. The response has been overwhelmingly in > > favor, pointing out the many things possible with this kind of package. > > > > I just want to use it to make nicer plotting easier (e.g., for profiling and > > histogramming) in the GUI, but obviously it has other uses. And of course, > > there are a number of other even more sophisticated plotting/graphing > > packages that also run under wxPython and scipy. > > TBH I was being lazy and waiting for more information on what specifically > it could be used for before giving an opinion... the names at least > suggest they are primarily for numerical calculations etc. and not drawing > graphics? I wonder do the parts of Pyplot you want to use even use anything > in NumPy? Looking at the source code, it's all basic stuff: primitive array operations plus fabs, floor, ceil, log10, power, sqrt, minimum, maximum. The comment at the top of plot.py says: This is a simple light weight plotting module that can be used with Boa or easily integrated into your own wxPython application. The emphasis is on small size and fast plotting for large data sets. It has a reasonable number of features to do line and scatter graphs easily as well as simple bar graphs. Excluding the demo (which is built into the package), it's ~1500 (non-blank) lines of code. AFAICT, an equivalent d.* module would be a decent day's work (assuming that you knew what you wanted at the outset). The only real advantage of PyPlot would be the ability to zoom/pan in real time. [BTW, on the subject of perfomance: I've extended the PNG driver to support writing 32-bpp BMP files. More significantly, if you set GRASS_PNG_MAPPED=TRUE, it will immediately write out the file, then mmap() for use as its framebuffer, so it doesn't have to explicitly write the file after each command.] -- Glynn Clements From glynn at gclements.plus.com Mon Apr 23 11:31:56 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Apr 23 11:32:11 2007 Subject: [GRASS-dev] numeric-numpy-scipy for graphs? In-Reply-To: References: Message-ID: <17964.32012.691862.169314@cerise.gclements.plus.com> Paul Kelly wrote: > > In fact, we can do considerably more now with the wxPython (and TclTk) > > drawing commands to than is available in d.graph or d.linegraph, even with > > your nice enhancements. > > > > In the case of histogramming and profiling, it seems a better display to > > have them come up in a separate window (like is now the case with the TclTk > > profiling module) than have them rendered like a map in the main display > > (like we do now for d.histogram in the current TclTk GUI). Rendering maps is > > complex and it doesn't seem efficient to have to go through the same complex > > procedures to draw a histogram or profile that doesn't need to be drawn > > georeferenced. > > Another thought - with the enhancements to the display architecture in > progress/idea stage Idea, currently. I need to introduce non-trivial API breakage in order to go much further. Mainly, switching to floating-point coordinates and adding begin/end operations to the move/cont and raster primitives. > it might actually be possible to produce better > quality graphs for inclusion in reports/papers etc. using the existing > display architecture. I'm thinking of the move towards PostScript as a > display output format. Certainly, I want (decent) PostScript output to at least be an option. The main question is whether we can abandon other formats, i.e. whether modules can rely upon being able to use the full feature set (e.g. arbitrary clip paths, rotation/scaling of all output, pattern fills etc), or whether they will be limited to a common-denominator subset. > I imagine with pop-up Windows in the GUI with > histograms etc. you would be limited to printing the thing as a raster > graphic at the same resolution as the screen? Not quite. I'm assuming that lines, polygons etc wouldn't be rasterised when using a print DC, but you're still stuck with coordinates on integer boundaries (and a fairly primitive API). This is one of the main distinctions between an "ideal" graphics API (PostScript, OpenGL) and an "adequate for GUI use" API (X11, Windows GDI). [FWIW, the wx API is heavily based upon Windows' GDI, which hasn't really changed much since Windows 1.0.] > Not so good. Unless those > new python modules you're looking at perhaps have an option to save as > postscript (I mean proper line-graphics postscript) for printing. wx has PostScriptDC and PrinterDC, which allow you to use the same code as for drawing on a screen DC. Not all operations will work on such contexts, e.g. you can't use raster ops (XOR-plotting etc) in PostScript. And you're still limited to the standard DC methods, e.g. no rotated images (NT/2K/XP has this, 95/98/ME doesn't, nor does X). > And of > course if you use GRASS modules to produce the graphs then as Glynn says > it is also possible to produce them from scripts, which is rather > important. (Rather than having all this functionality tied up in the GUI > and having to re-implement it if we change the GUI). > > > For this reason, it seems better to do these kinds of analyses with the gui > > tools, using underlying GRASS modules like r.profile and r.stats. > > I agree it "seemed" better/tidier/neater to me at first, but if we > consider the display architecture is being enhanced beyond it's old > clunky state it may not be as logical is it first seemed? +1 ;) -- Glynn Clements From soerengebbert at gmx.de Mon Apr 23 13:06:30 2007 From: soerengebbert at gmx.de (=?ISO-8859-1?Q?S=F6ren_Gebbert?=) Date: Mon Apr 23 13:06:40 2007 Subject: [GRASS-dev] Replacement of NVIZ In-Reply-To: References: Message-ID: <462C9336.1000602@gmx.de> Dear Michael, Michael Barton schrieb: > It's great that we can export GRASS data to be used in high-end > multi-dimensional visualization platforms like Paraview and MayVi2. I've > used Paraview a bit. I wouldn't call it easy or intuitive, but it is quite > sophisticated and powerful--though not particularly fast in my experience. > > However, using any of these packages is not a replacement for NVIZ. NVIZ > will let a user quickly and seamlessly render 2, 2.5, 3, and 4 dimensional > data within a GRASS GIS session. This is a real bonus. And NVIZ does this > better than any other rendering engine within a GIS that I've seen. In this > sense, NVIZ has a different goal from Paraview and other dedicated > multidemensional rendering packages. > > So I hope that we can get NVIZ ported to wxPython and make it an even more > seamless part of the geospatial visualization tools for GRASS. Making Good news. Nice to hear that. I hope you will redesign the gui, so it will be more intuitive. I have had a look at the NVIZ code and was afraid that this construct is not maintainable. Well, this is hopefully related to my very little knowledge of software design and C coding with Tcl/Tk bindings. > tighter connections between GRASS and other, external visualization tools is > also a worthy plan--similar to the integration between GRASS and R. But > IMHO, we should not abandon NVIZ or something like it. I guess you are right. An integrated 2.5d, 3d and 4d visualization tool is important. The good thing is that ParaView is not only a visualization tool, it is a preprocessing and analysis tool with 4d support and powerful threaded image processing. Best regards Soeren > > Michael > > > On 4/22/07 4:31 PM, "S?ren Gebbert" wrote: > >> Syd, >> >> Syd Visser schrieb: >>> Soren >>> >>> Paraview3 uses Qt and MayaVi2 uses Wxpython thus we are leaning more >>> towards MayaVi2 although we use Paraview2.6 extensively but strictly as >>> a viewer. >>> We find MayaVi2 is also more open to user development thus easier to >>> extend. >> I'm developing with VTK and Qt since several years and have used ParaView1-2 >> for several years. >> My experience with MayaVi is little, because the user interface was too >> horrible. >> IMHO ParaView3 is the better choice. It has a sophisticated but very >> intuitive user interface and is developed by well known institutes and >> kitware. >> And they are doing a great job. ParaView is designed to visualize huge >> datasets in parallel. >> >> MayaVi2 depends on Traits, TVTK, Envisage and wxPython. A lot of new >> dependencies (except wxPython). >> And for now i'm not able to get even the new grass wxPython gui to run on my >> debian etch system >> because of the dependencies. >> ParaView3 depends only on Qt4.2. Qt is available for many, many platforms as >> well as VTK. >> (i still don't understand why wxWidgets and python was choosen for the new >> grass gui and not Qt >> and python ...) >> >> The only thing we need to provide is a data server and gui plugin for >> ParaView3: >> http://www.paraview.org/Wiki/Plugin_HowTo >> And when ParaView3 reaches a stable state and i have some spare time i'm >> absolutely willingly to implement them! >> >> IMHO the data server and the reader/writer to the grass database >> (grass data should be modified with Paraview3 and stored back into the grass >> database :) if possible) >> should be implemented in C++ for performance reasons. I would not use the >> grass python wrapper >> to get the data into a visualization system. The grass raster, voxel and >> vector functions can be >> accessed from C++ code directly. >> >> The data server should provide access to the grass database to read and write >> raster, volume and vector data. >> And ParaView3 should be extended with a nice little Qt gui to access the grass >> data directly from the toolbar >> (like Qgis). We don't need to touch the ParaView3 sources, we only need to >> implement plugins. >> >> A screenshot of ParaView3 handling grass raster, volume and vector data >> (exported with the *.out.vtk modules) >> is available here: >> http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/ParaView3_ >> Screenshot_grass_data.png >> >> Just my two cents ... >> >> sorry for my English >> Best regards >> Soeren >> >>> Thanks >>> Syd >>> >>> S?ren Gebbert wrote: >>>> Hi, >>>> >>>> Syd Visser schrieb: >>>>> We use enthought open source tool suite http://www.enthought.com/ >>>>> which contains Numpy, SciPi and numerous other packages. >>>>> our main use is with Matplotlib and Chaco for 2D graphs and MayaVi2 >>>>> for 3D graphics >>>>> I think these packages would be well worth having a close look at >>>>> especially MayaVi2 (Python wrapped VTK) for the 3D graphics. >>>> I would like to prefer a C++ grass data server + grass gui plugin for >>>> paraview3 >>>> to visualize 3d data. This would a nice and fast solution. >>>> >>>> Best regards >>>> Soeren >>>> >>>>> thanks >>>>> Syd >>>>> >>>> >> > > __________________________________________ > Michael Barton, Professor of Anthropology > School of Human Evolution & Social Change > Center for Social Dynamics & Complexity > Arizona State University > > phone: 480-965-6213 > fax: 480-965-7671 > www: http://www.public.asu.edu/~cmbarton > > From soerengebbert at gmx.de Mon Apr 23 13:19:59 2007 From: soerengebbert at gmx.de (=?ISO-8859-1?Q?S=F6ren_Gebbert?=) Date: Mon Apr 23 13:20:06 2007 Subject: [GRASS-dev] Replacement of NVIZ In-Reply-To: <462C9336.1000602@gmx.de> References: <462C9336.1000602@gmx.de> Message-ID: <462C965F.3020507@gmx.de> Sorry! More in the text below. S?ren Gebbert schrieb: > Dear Michael, > > Michael Barton schrieb: >> It's great that we can export GRASS data to be used in high-end >> multi-dimensional visualization platforms like Paraview and MayVi2. I've >> used Paraview a bit. I wouldn't call it easy or intuitive, but it is >> quite >> sophisticated and powerful--though not particularly fast in my >> experience. >> >> However, using any of these packages is not a replacement for NVIZ. NVIZ >> will let a user quickly and seamlessly render 2, 2.5, 3, and 4 >> dimensional >> data within a GRASS GIS session. This is a real bonus. And NVIZ does this >> better than any other rendering engine within a GIS that I've seen. In >> this >> sense, NVIZ has a different goal from Paraview and other dedicated >> multidemensional rendering packages. >> >> So I hope that we can get NVIZ ported to wxPython and make it an even >> more >> seamless part of the geospatial visualization tools for GRASS. Making > > Good news. Nice to hear that. I hope you will redesign the gui, so it > will be more intuitive. > I have had a look at the NVIZ code and was afraid that this construct is > not maintainable. > Well, this is hopefully related to my very little knowledge of software > design and C coding > with Tcl/Tk bindings. > >> tighter connections between GRASS and other, external visualization >> tools is >> also a worthy plan--similar to the integration between GRASS and R. But >> IMHO, we should not abandon NVIZ or something like it. > > I guess you are right. An integrated 2.5d, 3d and 4d visualization tool > is important. > The good thing is that ParaView is not only a visualization tool, it is > a preprocessing and analysis tool with 4d support and powerful threaded > image processing. I mean post-processing. Sorry for confusion. Soeren > > Best regards > Soeren > >> >> Michael >> >> >> On 4/22/07 4:31 PM, "S?ren Gebbert" wrote: >> >>> Syd, >>> >>> Syd Visser schrieb: >>>> Soren >>>> >>>> Paraview3 uses Qt and MayaVi2 uses Wxpython thus we are leaning more >>>> towards MayaVi2 although we use Paraview2.6 extensively but >>>> strictly as >>>> a viewer. >>>> We find MayaVi2 is also more open to user development thus easier to >>>> extend. >>> I'm developing with VTK and Qt since several years and have used >>> ParaView1-2 >>> for several years. >>> My experience with MayaVi is little, because the user interface was too >>> horrible. >>> IMHO ParaView3 is the better choice. It has a sophisticated but very >>> intuitive user interface and is developed by well known institutes and >>> kitware. >>> And they are doing a great job. ParaView is designed to visualize huge >>> datasets in parallel. >>> >>> MayaVi2 depends on Traits, TVTK, Envisage and wxPython. A lot of new >>> dependencies (except wxPython). >>> And for now i'm not able to get even the new grass wxPython gui to >>> run on my >>> debian etch system >>> because of the dependencies. >>> ParaView3 depends only on Qt4.2. Qt is available for many, many >>> platforms as >>> well as VTK. >>> (i still don't understand why wxWidgets and python was choosen for >>> the new >>> grass gui and not Qt >>> and python ...) >>> >>> The only thing we need to provide is a data server and gui plugin for >>> ParaView3: >>> http://www.paraview.org/Wiki/Plugin_HowTo >>> And when ParaView3 reaches a stable state and i have some spare time i'm >>> absolutely willingly to implement them! >>> >>> IMHO the data server and the reader/writer to the grass database >>> (grass data should be modified with Paraview3 and stored back into >>> the grass >>> database :) if possible) >>> should be implemented in C++ for performance reasons. I would not use >>> the >>> grass python wrapper >>> to get the data into a visualization system. The grass raster, voxel and >>> vector functions can be >>> accessed from C++ code directly. >>> >>> The data server should provide access to the grass database to read >>> and write >>> raster, volume and vector data. >>> And ParaView3 should be extended with a nice little Qt gui to access >>> the grass >>> data directly from the toolbar >>> (like Qgis). We don't need to touch the ParaView3 sources, we only >>> need to >>> implement plugins. >>> >>> A screenshot of ParaView3 handling grass raster, volume and vector data >>> (exported with the *.out.vtk modules) >>> is available here: >>> http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/ParaView3_ >>> >>> Screenshot_grass_data.png >>> >>> Just my two cents ... >>> >>> sorry for my English >>> Best regards >>> Soeren >>> >>>> Thanks >>>> Syd >>>> >>>> S?ren Gebbert wrote: >>>>> Hi, >>>>> >>>>> Syd Visser schrieb: >>>>>> We use enthought open source tool suite http://www.enthought.com/ >>>>>> which contains Numpy, SciPi and numerous other packages. >>>>>> our main use is with Matplotlib and Chaco for 2D graphs and MayaVi2 >>>>>> for 3D graphics >>>>>> I think these packages would be well worth having a close look at >>>>>> especially MayaVi2 (Python wrapped VTK) for the 3D graphics. >>>>> I would like to prefer a C++ grass data server + grass gui plugin for >>>>> paraview3 >>>>> to visualize 3d data. This would a nice and fast solution. >>>>> >>>>> Best regards >>>>> Soeren >>>>> >>>>>> thanks >>>>>> Syd >>>>>> >>>>> >>> >> >> __________________________________________ >> Michael Barton, Professor of Anthropology >> School of Human Evolution & Social Change >> Center for Social Dynamics & Complexity >> Arizona State University >> >> phone: 480-965-6213 >> fax: 480-965-7671 >> www: http://www.public.asu.edu/~cmbarton >> >> > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > From benjamin.ducke at ufg.uni-kiel.de Mon Apr 23 15:02:23 2007 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Mon Apr 23 14:47:00 2007 Subject: [GRASS-dev] DBMI trouble compiling on Win32 In-Reply-To: <17960.65018.271320.735672@cerise.gclements.plus.com> References: <4628DA68.7080004@ufg.uni-kiel.de> <17960.65018.271320.735672@cerise.gclements.plus.com> Message-ID: <462CAE5F.9090707@ufg.uni-kiel.de> Thanks, Glynn for the quick reply. This fixed things in part. However, now I have a problem with the DBMI lib: cd /src/grass6/lib/db/dbmi_client make gives me: gcc -I/src/grass6/dist.i686-pc-mingw32/include -I/include -I/local/include -g -O2 -I/include -I/local/include -DPACKAGE=\""grasslibs"\" -I../dbmi_base -DPACKAGE=\""grasslibs"\" -I/src/grass6/dist.i686-pc-mingw32/include \ -o OBJ.i686-pc-mingw32/start.o -c start.c start.c: In function `db_start_driver': start.c:157: error: `have_stdin' undeclared (first use in this function) start.c:157: error: (Each undeclared identifier is reported only once start.c:157: error: for each function it appears in.) start.c:157: error: `have_stdout' undeclared (first use in this function) start.c:162: error: `stdin_fd' undeclared (first use in this function) start.c:168: error: `stdin_orig' undeclared (first use in this function) start.c:185: error: `stdout_fd' undeclared (first use in this function) start.c:191: error: `stdout_orig' undeclared (first use in this function) make[1]: *** [OBJ.i686-pc-mingw32/start.o] Error 1 make[1]: Leaving directory `/src/grass6/lib/db/dbmi_client' Maybe something needs to be fixed in the configure script for Win32? Thanks, Benjamin Glynn Clements wrote: > Benjamin Ducke wrote: > >> I am trying to compile yesterday's CVS sources on Win32 using MSYS and >> MingW (3.4.2). >> When the make script should link the gis lib objs (and other libs), I >> get this: >> >> OBJ.i686-pc-mingw32/open_misc.o(.data+0x0): In function `G__open_misc': >> C:/msys/src/grass6/lib/gis/open_misc.c:45: multiple definition of `_fmode' >> OBJ.i686-pc-mingw32/open.o(.data+0x0):C:/msys/src/grass6/lib/gis/open.c:98: >> first defined here >> collect2: ld returned 1 exit status >> make[2]: *** >> [/src/grass6/dist.i686-pc-mingw32/lib/libgrass_gis.6.3.cvs.dll] Error 1 >> >> I updated from CVS ca. 18 hours ago and did a "make distclean" and "make >> clean" before running the configure script. > > I've removed both occurrences of _fmode from libgis (in any case, > defining it inside a DLL doesn't work). _fmode should be defined by > linking against $(FMODE_OBJ). > -- Benjamin Ducke, M.A. Arch?oinformatik (Archaeoinformation Science) Institut f?r Ur- und Fr?hgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universit?t zu Kiel Johanna-Mestorf-Stra?e 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg From cavallini at faunalia.it Mon Apr 23 15:46:31 2007 From: cavallini at faunalia.it (Paolo Cavallini) Date: Mon Apr 23 15:49:48 2007 Subject: [GRASS-dev] Replacement of NVIZ In-Reply-To: References: Message-ID: <462CB8B7.7080101@faunalia.it> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I agree that integration is good, but I do not think NVIZ is maintainable. I think a good and smooth link to an external 3d viewer (call it Paraview or whatever). Why exactly this could not be a replacement for nviz? We cannot do everything within grass: the dev team is small compare to the code base, and externalizing functions is the only way to make real progress, in my view. All the best. pc Michael Barton ha scritto: > So I hope that we can get NVIZ ported to wxPython and make it an even more > seamless part of the geospatial visualization tools for GRASS. Making > tighter connections between GRASS and other, external visualization tools is > also a worthy plan--similar to the integration between GRASS and R. But > IMHO, we should not abandon NVIZ or something like it. - -- Paolo Cavallini http://www.faunalia.it/pc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGLLi3/NedwLUzIr4RAhLzAKCvv9lA+uX/EDVBS88TZUA3Cbb6OgCffHYf RFa1b0RgKp7BKmusclIn9k4= =tFUj -----END PGP SIGNATURE----- From carlos.grohmann at gmail.com Mon Apr 23 16:07:56 2007 From: carlos.grohmann at gmail.com (=?ISO-8859-1?Q?Carlos_"Gu=E2no"_Grohmann?=) Date: Mon Apr 23 16:08:00 2007 Subject: [GRASS-dev] Replacement of NVIZ In-Reply-To: <462CB8B7.7080101@faunalia.it> References: <462CB8B7.7080101@faunalia.it> Message-ID: Even though I am not a real developer, I just want to say that NVIZ rocks! It could have some other features (like, create a view with a oberserver at XXX YYY ZZZ looking to 275 deg north, or something) but it's easy to use, and produce some really nice outputs. I just submitted a paper comparing ArcGis and GRASS for morphometric analysis (guess who won?) and the 3D image we use was made in NVIZ, because ArcScene doesn't even get close to the beauty of NVIZ 3D image. Having a [lightweighted] n-D visualizer integrated in the system really makes a difference. just my 0.02 Carlos On 4/23/07, Paolo Cavallini wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I agree that integration is good, but I do not think NVIZ is > maintainable. I think a good and smooth link to an external 3d viewer > (call it Paraview or whatever). Why exactly this could not be a > replacement for nviz? > We cannot do everything within grass: the dev team is small compare to > the code base, and externalizing functions is the only way to make real > progress, in my view. > All the best. > pc > > Michael Barton ha scritto: > > So I hope that we can get NVIZ ported to wxPython and make it an even more > > seamless part of the geospatial visualization tools for GRASS. Making > > tighter connections between GRASS and other, external visualization tools is > > also a worthy plan--similar to the integration between GRASS and R. But > > IMHO, we should not abandon NVIZ or something like it. > - -- > Paolo Cavallini > http://www.faunalia.it/pc > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFGLLi3/NedwLUzIr4RAhLzAKCvv9lA+uX/EDVBS88TZUA3Cbb6OgCffHYf > RFa1b0RgKp7BKmusclIn9k4= > =tFUj > -----END PGP SIGNATURE----- > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > -- +-----------------------------------------------------------+ Carlos Henrique Grohmann - Guano Geologist M.Sc - Doctorate Student at IGc-USP - Brazil Linux User #89721 - carlos dot grohmann at gmail dot com +-----------------------------------------------------------+ _________________ "Good morning, doctors. I have taken the liberty of removing Windows 95 from my hard drive." --The winning entry in a "What were HAL's first words" contest judged by 2001: A SPACE ODYSSEY creator Arthur C. Clarke From benjamin.ducke at ufg.uni-kiel.de Mon Apr 23 16:34:33 2007 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Mon Apr 23 16:19:10 2007 Subject: [GRASS-dev] Replacement of NVIZ In-Reply-To: References: <462CB8B7.7080101@faunalia.it> Message-ID: <462CC3F9.9090508@ufg.uni-kiel.de> Could you post article references and figure screenshots? This seems to be good material for some GRASS advocation and/or ArcGIS bashing ... Benjamin Carlos "Gu?no" Grohmann wrote: > Even though I am not a real developer, I just want to say that NVIZ > rocks! It could have some other features (like, create a view with a > oberserver at XXX YYY ZZZ looking to 275 deg north, or something) but > it's easy to use, and produce some really nice outputs. I just > submitted a paper comparing ArcGis and GRASS for morphometric analysis > (guess who won?) and the 3D image we use was made in NVIZ, because > ArcScene doesn't even get close to the beauty of NVIZ 3D image. > > Having a [lightweighted] n-D visualizer integrated in the system > really makes a difference. > > just my 0.02 > > Carlos > > > > On 4/23/07, Paolo Cavallini wrote: > I agree that integration is good, but I do not think NVIZ is > maintainable. I think a good and smooth link to an external 3d viewer > (call it Paraview or whatever). Why exactly this could not be a > replacement for nviz? > We cannot do everything within grass: the dev team is small compare to > the code base, and externalizing functions is the only way to make real > progress, in my view. > All the best. > pc > > Michael Barton ha scritto: >> So I hope that we can get NVIZ ported to wxPython and make it an > even more >> seamless part of the geospatial visualization tools for GRASS. Making >> tighter connections between GRASS and other, external visualization > tools is >> also a worthy plan--similar to the integration between GRASS and R. But >> IMHO, we should not abandon NVIZ or something like it. >> _______________________________________________ grass-dev mailing list grass-dev@grass.itc.it http://grass.itc.it/mailman/listinfo/grass-dev >> -- Benjamin Ducke, M.A. Arch?oinformatik (Archaeoinformation Science) Institut f?r Ur- und Fr?hgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universit?t zu Kiel Johanna-Mestorf-Stra?e 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg From yann.chemin at gmail.com Mon Apr 23 16:26:52 2007 From: yann.chemin at gmail.com (Yann) Date: Mon Apr 23 16:27:05 2007 Subject: [GRASS-dev] Replacement of NVIZ In-Reply-To: References: <462CB8B7.7080101@faunalia.it> Message-ID: <200704232126.52282.yann.chemin@gmail.com> Any website to ddownload this article/screenshots? thanks, Yann On Monday 23 April 2007 21:07, Carlos "Gu?no" Grohmann wrote: > Even though I am not a real developer, I just want to say that NVIZ > rocks! It could have some other features (like, create a view with a > oberserver at XXX YYY ZZZ looking to 275 deg north, or something) but > it's easy to use, and produce some really nice outputs. I just > submitted a paper comparing ArcGis and GRASS for morphometric analysis > (guess who won?) and the 3D image we use was made in NVIZ, because > ArcScene doesn't even get close to the beauty of NVIZ 3D image. > > Having a [lightweighted] n-D visualizer integrated in the system > really makes a difference. > > just my 0.02 > > Carlos > > On 4/23/07, Paolo Cavallini wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > I agree that integration is good, but I do not think NVIZ is > > maintainable. I think a good and smooth link to an external 3d viewer > > (call it Paraview or whatever). Why exactly this could not be a > > replacement for nviz? > > We cannot do everything within grass: the dev team is small compare to > > the code base, and externalizing functions is the only way to make real > > progress, in my view. > > All the best. > > pc > > > > Michael Barton ha scritto: > > > So I hope that we can get NVIZ ported to wxPython and make it an even > > > more seamless part of the geospatial visualization tools for GRASS. > > > Making tighter connections between GRASS and other, external > > > visualization tools is also a worthy plan--similar to the integration > > > between GRASS and R. But IMHO, we should not abandon NVIZ or something > > > like it. > > > > - -- > > Paolo Cavallini > > http://www.faunalia.it/pc > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.6 (GNU/Linux) > > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > > > iD8DBQFGLLi3/NedwLUzIr4RAhLzAKCvv9lA+uX/EDVBS88TZUA3Cbb6OgCffHYf > > RFa1b0RgKp7BKmusclIn9k4= > > =tFUj > > -----END PGP SIGNATURE----- > > > > _______________________________________________ > > grass-dev mailing list > > grass-dev@grass.itc.it > > http://grass.itc.it/mailman/listinfo/grass-dev -- Yann Chemin Sainte-Anne d'Auray, France From carlos.grohmann at gmail.com Mon Apr 23 16:33:50 2007 From: carlos.grohmann at gmail.com (=?ISO-8859-1?Q?Carlos_"Gu=E2no"_Grohmann?=) Date: Mon Apr 23 16:33:54 2007 Subject: [GRASS-dev] Replacement of NVIZ In-Reply-To: <200704232126.52282.yann.chemin@gmail.com> References: <462CB8B7.7080101@faunalia.it> <200704232126.52282.yann.chemin@gmail.com> Message-ID: Sorry, but not yet. The article has just been submitted, it will take some time until I can show anything... Thanks for the interest! On 4/23/07, Yann wrote: > Any website to ddownload this article/screenshots? > > thanks, > Yann > > On Monday 23 April 2007 21:07, Carlos "Gu?no" Grohmann wrote: > > Even though I am not a real developer, I just want to say that NVIZ > > rocks! It could have some other features (like, create a view with a > > oberserver at XXX YYY ZZZ looking to 275 deg north, or something) but > > it's easy to use, and produce some really nice outputs. I just > > submitted a paper comparing ArcGis and GRASS for morphometric analysis > > (guess who won?) and the 3D image we use was made in NVIZ, because > > ArcScene doesn't even get close to the beauty of NVIZ 3D image. > > > > Having a [lightweighted] n-D visualizer integrated in the system > > really makes a difference. > > > > just my 0.02 > > > > Carlos > > > > On 4/23/07, Paolo Cavallini wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > I agree that integration is good, but I do not think NVIZ is > > > maintainable. I think a good and smooth link to an external 3d viewer > > > (call it Paraview or whatever). Why exactly this could not be a > > > replacement for nviz? > > > We cannot do everything within grass: the dev team is small compare to > > > the code base, and externalizing functions is the only way to make real > > > progress, in my view. > > > All the best. > > > pc > > > > > > Michael Barton ha scritto: > > > > So I hope that we can get NVIZ ported to wxPython and make it an even > > > > more seamless part of the geospatial visualization tools for GRASS. > > > > Making tighter connections between GRASS and other, external > > > > visualization tools is also a worthy plan--similar to the integration > > > > between GRASS and R. But IMHO, we should not abandon NVIZ or something > > > > like it. > > > > > > - -- > > > Paolo Cavallini > > > http://www.faunalia.it/pc > > > -----BEGIN PGP SIGNATURE----- > > > Version: GnuPG v1.4.6 (GNU/Linux) > > > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > > > > > iD8DBQFGLLi3/NedwLUzIr4RAhLzAKCvv9lA+uX/EDVBS88TZUA3Cbb6OgCffHYf > > > RFa1b0RgKp7BKmusclIn9k4= > > > =tFUj > > > -----END PGP SIGNATURE----- > > > > > > _______________________________________________ > > > grass-dev mailing list > > > grass-dev@grass.itc.it > > > http://grass.itc.it/mailman/listinfo/grass-dev > > -- > Yann Chemin > Sainte-Anne d'Auray, France > > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > -- +-----------------------------------------------------------+ Carlos Henrique Grohmann - Guano Geologist M.Sc - Doctorate Student at IGc-USP - Brazil Linux User #89721 - carlos dot grohmann at gmail dot com +-----------------------------------------------------------+ _________________ "Good morning, doctors. I have taken the liberty of removing Windows 95 from my hard drive." --The winning entry in a "What were HAL's first words" contest judged by 2001: A SPACE ODYSSEY creator Arthur C. Clarke From mlennert at club.worldonline.be Mon Apr 23 16:45:52 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Mon Apr 23 16:42:35 2007 Subject: [GRASS-dev] DBMI trouble compiling on Win32 In-Reply-To: <462CAE5F.9090707@ufg.uni-kiel.de> References: <4628DA68.7080004@ufg.uni-kiel.de> <17960.65018.271320.735672@cerise.gclements.plus.com> <462CAE5F.9090707@ufg.uni-kiel.de> Message-ID: <462CC6A0.3000003@club.worldonline.be> On 23/04/07 15:02, Benjamin Ducke wrote: > Thanks, Glynn for the quick reply. > This fixed things in part. However, now I have a problem with the DBMI > lib: > > cd /src/grass6/lib/db/dbmi_client > make > > gives me: > > gcc -I/src/grass6/dist.i686-pc-mingw32/include -I/include > -I/local/include -g -O2 -I/include -I/local/include > -DPACKAGE=\""grasslibs"\" -I../dbmi_base -DPACKAGE=\""grasslibs"\" > -I/src/grass6/dist.i686-pc-mingw32/include \ > -o OBJ.i686-pc-mingw32/start.o -c start.c > start.c: In function `db_start_driver': > start.c:157: error: `have_stdin' undeclared (first use in this function) > start.c:157: error: (Each undeclared identifier is reported only once > start.c:157: error: for each function it appears in.) > start.c:157: error: `have_stdout' undeclared (first use in this function) > start.c:162: error: `stdin_fd' undeclared (first use in this function) > start.c:168: error: `stdin_orig' undeclared (first use in this function) > start.c:185: error: `stdout_fd' undeclared (first use in this function) > start.c:191: error: `stdout_orig' undeclared (first use in this function) > make[1]: *** [OBJ.i686-pc-mingw32/start.o] Error 1 > make[1]: Leaving directory `/src/grass6/lib/db/dbmi_client' > > > Maybe something needs to be fixed in the configure script for Win32? This seems to come from Brad's latest change to start.c: @@ -33,9 +38,6 @@ int stat; dbConnection connection; char ebuf[5]; - int stdin_orig, stdout_orig; - int have_stdin, have_stdout; - int stdin_fd, stdout_fd; Brad, any special reason for this, or did you just not see that these are used in the #ifdef __MINGW32__ which starts at line 117 ? Moritz From michael.barton at asu.edu Mon Apr 23 16:55:01 2007 From: michael.barton at asu.edu (Michael Barton) Date: Mon Apr 23 16:55:10 2007 Subject: [GRASS-dev] numeric-numpy-scipy for graphs? In-Reply-To: <17964.32012.691862.169314@cerise.gclements.plus.com> Message-ID: A couple thoughts to add to the good discussion below. Using native GUI graphics can make for much nicer output. Look at the TclTk text layer in the current GUI. I is the only thing that currently outputs in postscript/eps. The best example is the thematic vector legend. OTOH, if a nice GRASS plotting routine could serve the relatively simple GIS needs, I've been rethinking on how I could do it in wxPython without having to go through the kind of complex rendering system. Using a single line GRASS command like d.histogram is a lot easier than having to program graphic primitives with data from r.stat--even if I can use the wxPython plot routine. It simply needs to go to a PNG file and be picked up again by a display window. No need to worry about georeferencing. The one complication is changing window size. The GRASS command would need to be rerun and the graphic rendered. With the new PS driver, we might not be stuck with a rasterized version. The fonts are still ugly (to me at least) and remain difficult to change. But maybe recent changes have improved this. If writing C code for simple native GRASS plotting is as straightforward as Glynn suggests, it might be worth a look. d.histogram already can render to a graphics file that can be displayed in a canvas. An equivalent (non-interactive) d.profile does not exist (perhaps a flag added to r.profile?) I haven't looked at d.graph closely since Hamish upgraded it, but will do so. Michael On 4/23/07 2:31 AM, "Glynn Clements" wrote: > > Paul Kelly wrote: > >>> In fact, we can do considerably more now with the wxPython (and TclTk) >>> drawing commands to than is available in d.graph or d.linegraph, even with >>> your nice enhancements. >>> >>> In the case of histogramming and profiling, it seems a better display to >>> have them come up in a separate window (like is now the case with the TclTk >>> profiling module) than have them rendered like a map in the main display >>> (like we do now for d.histogram in the current TclTk GUI). Rendering maps is >>> complex and it doesn't seem efficient to have to go through the same complex >>> procedures to draw a histogram or profile that doesn't need to be drawn >>> georeferenced. >> >> Another thought - with the enhancements to the display architecture in >> progress/idea stage > > Idea, currently. I need to introduce non-trivial API breakage in order > to go much further. Mainly, switching to floating-point coordinates > and adding begin/end operations to the move/cont and raster > primitives. > >> it might actually be possible to produce better >> quality graphs for inclusion in reports/papers etc. using the existing >> display architecture. I'm thinking of the move towards PostScript as a >> display output format. > > Certainly, I want (decent) PostScript output to at least be an option. > > The main question is whether we can abandon other formats, i.e. > whether modules can rely upon being able to use the full feature set > (e.g. arbitrary clip paths, rotation/scaling of all output, pattern > fills etc), or whether they will be limited to a common-denominator > subset. > >> I imagine with pop-up Windows in the GUI with >> histograms etc. you would be limited to printing the thing as a raster >> graphic at the same resolution as the screen? > > Not quite. I'm assuming that lines, polygons etc wouldn't be > rasterised when using a print DC, but you're still stuck with > coordinates on integer boundaries (and a fairly primitive API). > > This is one of the main distinctions between an "ideal" graphics API > (PostScript, OpenGL) and an "adequate for GUI use" API (X11, Windows > GDI). > > [FWIW, the wx API is heavily based upon Windows' GDI, which hasn't > really changed much since Windows 1.0.] > >> Not so good. Unless those >> new python modules you're looking at perhaps have an option to save as >> postscript (I mean proper line-graphics postscript) for printing. > > wx has PostScriptDC and PrinterDC, which allow you to use the same > code as for drawing on a screen DC. Not all operations will work on > such contexts, e.g. you can't use raster ops (XOR-plotting etc) in > PostScript. And you're still limited to the standard DC methods, e.g. > no rotated images (NT/2K/XP has this, 95/98/ME doesn't, nor does X). > >> And of >> course if you use GRASS modules to produce the graphs then as Glynn says >> it is also possible to produce them from scripts, which is rather >> important. (Rather than having all this functionality tied up in the GUI >> and having to re-implement it if we change the GUI). >> >>> For this reason, it seems better to do these kinds of analyses with the gui >>> tools, using underlying GRASS modules like r.profile and r.stats. >> >> I agree it "seemed" better/tidier/neater to me at first, but if we >> consider the display architecture is being enhanced beyond it's old >> clunky state it may not be as logical is it first seemed? > > +1 ;) __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Mon Apr 23 17:05:01 2007 From: michael.barton at asu.edu (Michael Barton) Date: Mon Apr 23 17:05:09 2007 Subject: [GRASS-dev] FW: [PyOpenGL-Devel] pyopengl on Mac OS X In-Reply-To: <462C8D83.6020804@gmail.com> Message-ID: Looking ahead to a wxPython port/replacement for NVIZ, I inquired about getting pyOpenGL running on multiple platforms--specifically Mac since Linux and Windows are explicitly mentioned in the installation docs. Glynn has indicated that we may not need this, but I've had some interesting replies and some useful links. I'll forward these to the list in case they are helpful. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton ------ Forwarded Message > From: altern > Date: Mon, 23 Apr 2007 12:42:11 +0200 > To: Michael Barton > Subject: Re: [PyOpenGL-Devel] pyopengl on Mac OS X > > just notice that my code might be a bit weird compared to the typical > wxpython style, but i hope it might help you understanding the basics. > You can also check a basic example on the windows wxpython demo that > comes with the wxpython installation, it has a opengl example as well, > but with no menu/widgets. Somebody passed me the code for a project from > engeneering school where i live that was useful as well, i will try to > find the link and send it to you as this might be more clear > > Michael Barton(e)k dio: >> Thanks for the pointers. >> >> Michael >> >> >> On 4/22/07 11:02 PM, "altern" wrote: >> >>> hi michael >>> >>> just quick answer i am busy today. it does work. check >>> www.ixi-softare.net/mirra >>> check the wxwindow class at main.py >>> >>> and maybe this one more useful as it is far simpler >>> https://devel.goto10.org/ enter ixi and then python there are some >>> examples there >>> https://devel.goto10.org/filedetails.php?repname=ixi&path=%2Fpython%2Fwxopen >>> gl >>> test.py&rev=0&sc=0 >>> https://devel.goto10.org/filedetails.php?repname=ixi&path=%2Fpython%2Fwxopen >>> gl >>> test_simple.py&rev=0&sc=0 >>> >>> any questions just ask, sorry for short email, just leaving for work >>> best >>> >>> enrike >>> >>> Michael Barton(e)k dio: >>>> Greetings, >>>> >>>> I represent the GRASS GIS open source development team. We are currently >>>> developing a new GUI for GRASS in wxPython. An important component is >>>> OpenGL access for multi-dimensional rendering of geospatial data. We >>>> currently do this in TclTk via TOGL. >>>> >>>> As the person overseeing the GUI development, I?m trying to see what it >>>> takes to get the wxPython GLCanvas up and running. GRASS is strongly >>>> cross-platform, running on all common Linux flavors, Mac OSX (i.e., BSD >>>> Unix), and Windows. I?ve looked through the installation docs for >>>> pyOpenGL and don?t see any mention of Mac OS X. Can you tell me if >>>> anyone has it up and running on that platform? >>>> >>>> I?m not a subscriber to this list, so could you reply to me directly? If >>>> I get a reply, I can check the archives to see if there are related >>>> threads too. >>>> >>>> Thanks much >>>> Michael Barton >>>> __________________________________________ >>>> Michael Barton, Professor of Anthropology >>>> School of Human Evolution & Social Change >>>> Center for Social Dynamics & Complexity >>>> Arizona State University >>>> >>>> phone: 480-965-6213 >>>> fax: 480-965-7671 >>>> www: http://www.public.asu.edu/~cmbarton >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> ------------------------------------------------------------------------- >>>> This SF.net email is sponsored by DB2 Express >>>> Download DB2 Express C - the FREE version of DB2 express and take >>>> control of your XML. No limits. Just data. Click to get it now. >>>> http://sourceforge.net/powerbar/db2/ >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> PyOpenGL Homepage >>>> http://pyopengl.sourceforge.net >>>> _______________________________________________ >>>> PyOpenGL-Devel mailing list >>>> PyOpenGL-Devel@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/pyopengl-devel >> >> __________________________________________ >> Michael Barton, Professor of Anthropology >> School of Human Evolution & Social Change >> Center for Social Dynamics & Complexity >> Arizona State University >> >> phone: 480-965-6213 >> fax: 480-965-7671 >> www: http://www.public.asu.edu/~cmbarton >> >> >> > ------ End of Forwarded Message From michael.barton at asu.edu Mon Apr 23 17:05:39 2007 From: michael.barton at asu.edu (Michael Barton) Date: Mon Apr 23 17:05:44 2007 Subject: [GRASS-dev] FW: [PyOpenGL-Devel] pyopengl on Mac OS X In-Reply-To: <886A9D0E-9EC3-403B-99E3-CFEC95825B83@sandia.gov> Message-ID: More on this thread __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton ------ Forwarded Message > From: rmuller > Date: Mon, 23 Apr 2007 08:20:39 -0600 > To: Michael Barton > Subject: Re: [PyOpenGL-Devel] pyopengl on Mac OS X > > It should be possible. I routinely use PyOpenGL and the wx GLCanvas > on Mac OS X, and have found it significantly easier to get running on > different platforms than TOGL. If you run into any problems, let me > know, and I can figure out my own installation details. I believe I'm > using Python and wxPython from http://pythonmac.org/packages, and a > manual install of PyOpenGL-2.0.1.07. > > Rick > ------ End of Forwarded Message From michael.barton at asu.edu Mon Apr 23 17:06:38 2007 From: michael.barton at asu.edu (Michael Barton) Date: Mon Apr 23 17:06:43 2007 Subject: [GRASS-dev] FW: [PyOpenGL-Devel] pyopengl on Mac OS X In-Reply-To: Message-ID: Another post to the pyOpenGL thread. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton > ------ Forwarded Message > From: Shane Holloway > Date: Mon, 23 Apr 2007 08:25:04 -0600 > To: Michael Barton > Cc: > Subject: Re: [PyOpenGL-Devel] pyopengl on Mac OS X > > Hey Michael, > > I started from the GLCanvas in the wx demo.? Works pretty well, but some > features like full screen antialiasing are not configurable through the GL > Canvas because the constants and cases are missing for them. > > -Shane ------ End of Forwarded Message -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070423/f541344e/attachment.html From wegmann at biozentrum.uni-wuerzburg.de Mon Apr 23 17:31:26 2007 From: wegmann at biozentrum.uni-wuerzburg.de (Martin Wegmann) Date: Mon Apr 23 17:35:05 2007 Subject: [GRASS-dev] g.copy bug? Message-ID: <200704231731.26396.wegmann@biozentrum.uni-wuerzburg.de> Hello, g.copy from mapsetA -> mapsetB does not work witht the most current cvs version. if I run g.copy rast=old@mapsetX,test1725heute d.rast test1725heute WARNING: can't read range file for [test1725heute in habitat_amount] WARNING: color support for [test1725heute] in mapset [habitat_amount] missing ERROR: Color file for [test1725heute] not available r.support test1725heute WARNING: Can't open header file for [test1725heute in habitat_amount] Edit header for [test1725heute]? (y/n) [y] Edit header for [test1725heute@habitat_amount] WARNING: unable to open raster map [test1725heute in habitat_amount] ERROR: Cannot open raster map [test1725heute]! WARNING: Can't open header file for [test1725heute in habitat_amount] ERROR: Canceling from edit header. r.info test1725heute WARNING: Can't open header file for [test1725heute in habitat_amount] WARNING: category support for [test1725heute] in mapset [habitat_amount] missing WARNING: can't get history information for [test1725heute] in mapset [habitat_amount] WARNING: can't read range file for [test1725heute in habitat_amount] ERROR: could not read range file unfortunately my grass6 / 62 Debian versions are broken hence I cannot test it using these releases. can anybody report this bug as well? Martin BTW is there a way to move raster between mapsets? From michael.barton at asu.edu Mon Apr 23 17:56:40 2007 From: michael.barton at asu.edu (Michael Barton) Date: Mon Apr 23 17:56:45 2007 Subject: [GRASS-dev] using system fonts? Message-ID: Perhaps this is a silly question, but is there any way to use system fonts in GRASS. Currently, we either need to use a stroke font (the default, ugly) or specify a path to a Truetype font. It is quite easy to get system font information (family, name, style, size, color, etc) from a standard system font dialog in wxPython (and in TclTk too). Is there some way to pass that information to GRASS so that it will be the display font. Or could there be a flag/GRASS environmental variable, to make the default system font the default GRASS font? Then the default could be changed as desired. Imagine Helvetica/Lucida Grand/Arial as the default font for legends, bar scales, and the like... Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070423/59896ff7/attachment-0001.html From michael.barton at asu.edu Mon Apr 23 19:15:00 2007 From: michael.barton at asu.edu (Michael Barton) Date: Mon Apr 23 19:15:19 2007 Subject: [GRASS-dev] Replacement of NVIZ In-Reply-To: <462CB8B7.7080101@faunalia.it> Message-ID: Why do you think it is not maintainable? We are maintaining it now and it is far better than equivalent packages in other GIS platforms (if they even exist). There also are likely to be more people with python/wxPython expertise than we now have with TclTk expertise, which bodes well for future maintainability and enhancements. We should be conservative about taking on **new** code responsibilities unless we have the development team to manage them into the future. But with the development team growing, and inclusion into OSGEO, I don't see any reason to jettison existing GRASS functionality--especially a piece that is so good and has been a key part of GRASS for so long. Many other programs exist that do parts of what GRASS does (GDAL, MySQL, ParaView, GIMP, QCAD)--and sometimes do it with much more sophistication. GRASS brings needed functionality together in an integrated way to provide a rich and complete GIS environment. Michael On 4/23/07 6:46 AM, "Paolo Cavallini" wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I agree that integration is good, but I do not think NVIZ is > maintainable. I think a good and smooth link to an external 3d viewer > (call it Paraview or whatever). Why exactly this could not be a > replacement for nviz? > We cannot do everything within grass: the dev team is small compare to > the code base, and externalizing functions is the only way to make real > progress, in my view. > All the best. > pc > > Michael Barton ha scritto: >> So I hope that we can get NVIZ ported to wxPython and make it an even more >> seamless part of the geospatial visualization tools for GRASS. Making >> tighter connections between GRASS and other, external visualization tools is >> also a worthy plan--similar to the integration between GRASS and R. But >> IMHO, we should not abandon NVIZ or something like it. > - -- > Paolo Cavallini > http://www.faunalia.it/pc > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFGLLi3/NedwLUzIr4RAhLzAKCvv9lA+uX/EDVBS88TZUA3Cbb6OgCffHYf > RFa1b0RgKp7BKmusclIn9k4= > =tFUj > -----END PGP SIGNATURE----- > > __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From JGillette at rfmd.com Mon Apr 23 19:52:41 2007 From: JGillette at rfmd.com (John Gillette) Date: Mon Apr 23 19:52:44 2007 Subject: [GRASS-dev] numeric-numpy-scipy for graphs? In-Reply-To: <17964.32012.691862.169314@cerise.gclements.plus.com> Message-ID: What does "DC" stand for? > -----Original Message----- > From: grass-dev-bounces@grass.itc.it > [mailto:grass-dev-bounces@grass.itc.it] On Behalf Of Glynn Clements > Sent: Monday, April 23, 2007 5:32 AM > To: Paul Kelly > Cc: grassgui@grass.itc.it; Michael Barton; Hamish; > grass-dev@grass.itc.it > Subject: Re: [GRASS-dev] numeric-numpy-scipy for graphs? > > > Paul Kelly wrote: > > > > In fact, we can do considerably more now with the wxPython (and > > > TclTk) drawing commands to than is available in d.graph or > > > d.linegraph, even with your nice enhancements. > > > > > > In the case of histogramming and profiling, it seems a better > > > display to have them come up in a separate window (like > is now the > > > case with the TclTk profiling module) than have them > rendered like a > > > map in the main display (like we do now for d.histogram in the > > > current TclTk GUI). Rendering maps is complex and it doesn't seem > > > efficient to have to go through the same complex > procedures to draw > > > a histogram or profile that doesn't need to be drawn > georeferenced. > > > > Another thought - with the enhancements to the display > architecture in > > progress/idea stage > > Idea, currently. I need to introduce non-trivial API breakage > in order to go much further. Mainly, switching to > floating-point coordinates and adding begin/end operations to > the move/cont and raster primitives. > > > it might actually be possible to produce better quality graphs for > > inclusion in reports/papers etc. using the existing display > > architecture. I'm thinking of the move towards PostScript > as a display > > output format. > > Certainly, I want (decent) PostScript output to at least be > an option. > > The main question is whether we can abandon other formats, i.e. > whether modules can rely upon being able to use the full > feature set (e.g. arbitrary clip paths, rotation/scaling of > all output, pattern fills etc), or whether they will be > limited to a common-denominator subset. > > > I imagine with pop-up Windows in the GUI with histograms etc. you > > would be limited to printing the thing as a raster graphic > at the same > > resolution as the screen? > > Not quite. I'm assuming that lines, polygons etc wouldn't be > rasterised when using a print DC, but you're still stuck with > coordinates on integer boundaries (and a fairly primitive API). > > This is one of the main distinctions between an "ideal" > graphics API (PostScript, OpenGL) and an "adequate for GUI > use" API (X11, Windows GDI). > > [FWIW, the wx API is heavily based upon Windows' GDI, which > hasn't really changed much since Windows 1.0.] > > > Not so good. Unless those > > new python modules you're looking at perhaps have an option > to save as > > postscript (I mean proper line-graphics postscript) for printing. > > wx has PostScriptDC and PrinterDC, which allow you to use the > same code as for drawing on a screen DC. Not all operations > will work on such contexts, e.g. you can't use raster ops > (XOR-plotting etc) in PostScript. And you're still limited to > the standard DC methods, e.g. > no rotated images (NT/2K/XP has this, 95/98/ME doesn't, nor does X). > > > And of > > course if you use GRASS modules to produce the graphs then as Glynn > > says it is also possible to produce them from scripts, > which is rather > > important. (Rather than having all this functionality tied > up in the > > GUI and having to re-implement it if we change the GUI). > > > > > For this reason, it seems better to do these kinds of > analyses with > > > the gui tools, using underlying GRASS modules like > r.profile and r.stats. > > > > I agree it "seemed" better/tidier/neater to me at first, but if we > > consider the display architecture is being enhanced beyond it's old > > clunky state it may not be as logical is it first seemed? > > +1 ;) > > -- > Glynn Clements > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > From glynn at gclements.plus.com Mon Apr 23 20:12:46 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Apr 23 20:13:06 2007 Subject: [GRASSGUI] Re: [GRASS-dev] numeric-numpy-scipy for graphs? In-Reply-To: References: <17964.32012.691862.169314@cerise.gclements.plus.com> Message-ID: <17964.63262.692060.161976@cerise.gclements.plus.com> Michael Barton wrote: > A couple thoughts to add to the good discussion below. > > Using native GUI graphics can make for much nicer output. Look at the TclTk > text layer in the current GUI. I is the only thing that currently outputs in > postscript/eps. Are you comparing it to stroke fonts or TrueType fonts? I'm well aware that the stroke fonts are rather ugly; they're maintained because they're guaranteed to work on all drivers and the same set of fonts is always available. If you use TrueType fonts, there's no reason why the quality should be any worse than Tk's own text items, and may be better (d.text[.new] and the PNG driver will generate anti-aliased output). -- Glynn Clements From glynn at gclements.plus.com Mon Apr 23 20:18:13 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Apr 23 20:18:16 2007 Subject: [GRASS-dev] DBMI trouble compiling on Win32 In-Reply-To: <462CC6A0.3000003@club.worldonline.be> References: <4628DA68.7080004@ufg.uni-kiel.de> <17960.65018.271320.735672@cerise.gclements.plus.com> <462CAE5F.9090707@ufg.uni-kiel.de> <462CC6A0.3000003@club.worldonline.be> Message-ID: <17964.63589.195731.772348@cerise.gclements.plus.com> Moritz Lennert wrote: > > This fixed things in part. However, now I have a problem with the DBMI > > lib: > > > > cd /src/grass6/lib/db/dbmi_client > > make > > > > gives me: > > > > gcc -I/src/grass6/dist.i686-pc-mingw32/include -I/include > > -I/local/include -g -O2 -I/include -I/local/include > > -DPACKAGE=\""grasslibs"\" -I../dbmi_base -DPACKAGE=\""grasslibs"\" > > -I/src/grass6/dist.i686-pc-mingw32/include \ > > -o OBJ.i686-pc-mingw32/start.o -c start.c > > start.c: In function `db_start_driver': > > start.c:157: error: `have_stdin' undeclared (first use in this function) > > start.c:157: error: (Each undeclared identifier is reported only once > > start.c:157: error: for each function it appears in.) > > start.c:157: error: `have_stdout' undeclared (first use in this function) > > start.c:162: error: `stdin_fd' undeclared (first use in this function) > > start.c:168: error: `stdin_orig' undeclared (first use in this function) > > start.c:185: error: `stdout_fd' undeclared (first use in this function) > > start.c:191: error: `stdout_orig' undeclared (first use in this function) > > make[1]: *** [OBJ.i686-pc-mingw32/start.o] Error 1 > > make[1]: Leaving directory `/src/grass6/lib/db/dbmi_client' > > > > > > Maybe something needs to be fixed in the configure script for Win32? > > This seems to come from Brad's latest change to start.c: > > > @@ -33,9 +38,6 @@ > int stat; > dbConnection connection; > char ebuf[5]; > - int stdin_orig, stdout_orig; > - int have_stdin, have_stdout; > - int stdin_fd, stdout_fd; > > Brad, any special reason for this, or did you just not see that these > are used in the #ifdef __MINGW32__ which starts at line 117 ? Almost certainly the latter. I've restored the variables, conditionalised upon "#ifdef __MINGW32__" to prevent "unused variable" warnings on other platforms (which is probably the reason that they were removed). -- Glynn Clements From glynn at gclements.plus.com Mon Apr 23 20:27:09 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Apr 23 20:27:13 2007 Subject: [GRASS-dev] g.copy bug? In-Reply-To: <200704231731.26396.wegmann@biozentrum.uni-wuerzburg.de> References: <200704231731.26396.wegmann@biozentrum.uni-wuerzburg.de> Message-ID: <17964.64125.289050.275888@cerise.gclements.plus.com> Martin Wegmann wrote: > Hello, > > g.copy from mapsetA -> mapsetB does not work witht the most current cvs > version. > > if I run g.copy rast=old@mapsetX,test1725heute > > d.rast test1725heute > WARNING: can't read range file for [test1725heute in habitat_amount] > WARNING: color support for [test1725heute] in mapset [habitat_amount] > missing > ERROR: Color file for [test1725heute] not available > > > r.support test1725heute > WARNING: Can't open header file for [test1725heute in habitat_amount] > Edit header for [test1725heute]? (y/n) [y] > Edit header for [test1725heute@habitat_amount] > WARNING: unable to open raster map [test1725heute in habitat_amount] > ERROR: Cannot open raster map [test1725heute]! > WARNING: Can't open header file for [test1725heute in habitat_amount] > ERROR: Canceling from edit header. > > r.info test1725heute > WARNING: Can't open header file for [test1725heute in habitat_amount] > WARNING: category support for [test1725heute] in mapset [habitat_amount] > missing > WARNING: can't get history information for [test1725heute] in mapset > [habitat_amount] > WARNING: can't read range file for [test1725heute in habitat_amount] > ERROR: could not read range file > > unfortunately my grass6 / 62 Debian versions are broken hence I cannot test it > using these releases. > > can anybody report this bug as well? I can't reproduce this with a 2-day-version, which is after the recent changes involving qualified names. I tried: $ g.mapsets mapset=glynn $ g.mapsets -p glynn $ g.copy elevation.dem@PERMANENT,foo Copy raster to current mapset as $ ls /opt/grass-data/spearfish57/glynn/cell_misc/foo/ null range There may be other factors involved; can you create a minimal location which demonstrates the issue? > BTW is there a way to move raster between mapsets? Change to destination, g.copy, change to source, g.remove. There isn't a faster way; you can't modify mapsets other than the current one. -- Glynn Clements From glynn at gclements.plus.com Mon Apr 23 20:44:44 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Apr 23 20:47:05 2007 Subject: [GRASS-dev] using system fonts? In-Reply-To: References: Message-ID: <17964.65180.772776.762079@cerise.gclements.plus.com> Michael Barton wrote: > Perhaps this is a silly question, but is there any way to use system fonts > in GRASS. Currently, we either need to use a stroke font (the default, ugly) > or specify a path to a Truetype font. > > It is quite easy to get system font information (family, name, style, size, > color, etc) from a standard system font dialog in wxPython (and in TclTk > too). Is there some way to pass that information to GRASS so that it will be > the display font. Or could there be a flag/GRASS environmental variable, to > make the default system font the default GRASS font? Then the default could > be changed as desired. Imagine Helvetica/Lucida Grand/Arial as the default > font for legends, bar scales, and the like... Adding support for bitmap fonts would be reasonably straightforward, but getting those fonts without using X might be a different matter (bear in mind that there might not be any font files on the local system. X can get its fonts from a font server). Personally, I would have thought that the Freetype support would be sufficient. If it isn't, I can look into either stealing the PCF-reading code from X, or writing an X-based font-dumping utility. Obviously, I don't want to make the PNG/PS drivers link directly against Xlib. BTW, the term "default system font" isn't clear-cut. Different toolkits may have different ideas as to the default font. Xt uses X resources. Tcl/Tk manually parses certain X resource files (but not in the same that Xt does), so it might use the same font as Xt-based applications or it might not. GTK and Qt have their own mechanisms, and can vary depending upon whether they are being used under Gnome or KDE. -- Glynn Clements From dca.gis at gmail.com Mon Apr 23 20:53:29 2007 From: dca.gis at gmail.com (Daniel Calvelo) Date: Mon Apr 23 20:53:32 2007 Subject: [GRASS-dev] numeric-numpy-scipy for graphs? In-Reply-To: References: <17964.32012.691862.169314@cerise.gclements.plus.com> Message-ID: <1a486f560704231153j5fd5d1ecs878fcf6b95b635e4@mail.gmail.com> On 4/23/07, John Gillette wrote: > What does "DC" stand for? Device Context: it's the object drawing operations are performed on. Picture it as an API layer between client drawing code and some specific device. In GRASS terms, it's like a driver interface. So you instantiate one kind of DC (MemoryDC, PostScriptDC, MetafileDC, PrinterDC, and so on) and then use drawing operations irrespective of the particular back-end. (It's also my initials :) Daniel. -- -- Daniel Calvelo Aros From glynn at gclements.plus.com Mon Apr 23 20:59:45 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Apr 23 21:04:48 2007 Subject: [GRASS-dev] Replacement of NVIZ In-Reply-To: References: <462CB8B7.7080101@faunalia.it> Message-ID: <17965.545.466628.424478@cerise.gclements.plus.com> Michael Barton wrote: > Why do you think it is not maintainable? We are maintaining it now and it is > far better than equivalent packages in other GIS platforms (if they even > exist). There also are likely to be more people with python/wxPython > expertise than we now have with TclTk expertise, which bodes well for future > maintainability and enhancements. How long have we been trying to get "max res PPM" working (or, at least, to fail in ways which don't involve rebooting)? Beyond that, NVIZ is pretty ugly, structurally. > We should be conservative about taking on **new** code responsibilities > unless we have the development team to manage them into the future. But with > the development team growing, and inclusion into OSGEO, I don't see any > reason to jettison existing GRASS functionality--especially a piece that is > so good and has been a key part of GRASS for so long. Many other programs > exist that do parts of what GRASS does (GDAL, MySQL, ParaView, GIMP, > QCAD)--and sometimes do it with much more sophistication. GRASS brings > needed functionality together in an integrated way to provide a rich and > complete GIS environment. I thought that NVIZ *was* going to be jettisoned in favour of a Python version? That process isn't going to retain much of the original code. FWIW, I would be in favour of doing that. Apart from anything else, a replacement ought to be much cleaner. More generally, when creating an application of that level of complexity, structure matters. A lot. It isn't sufficient for the end result to work; people need to be able to modify it without first having to spend days or even weeks studying the code. Regarding "PyNVIZ", my main suggestion would be to keep the amount of C to a bare minimum. Create direct Python bindings for OGSF and write the rest in Python. Trying to understand code which is split between multiple languages is hard, and debugging it is even worse. -- Glynn Clements From neteler at itc.it Mon Apr 23 21:08:47 2007 From: neteler at itc.it (Markus Neteler) Date: Mon Apr 23 21:08:49 2007 Subject: [GRASS-dev] g.copy bug? In-Reply-To: <200704231731.26396.wegmann@biozentrum.uni-wuerzburg.de> References: <200704231731.26396.wegmann@biozentrum.uni-wuerzburg.de> Message-ID: <20070423190846.GA8137@bartok.itc.it> On Mon, Apr 23, 2007 at 05:31:26PM +0200, Martin Wegmann wrote: > Hello, > > g.copy from mapsetA -> mapsetB does not work witht the most current cvs > version. > > if I run g.copy rast=old@mapsetX,test1725heute > > d.rast test1725heute > WARNING: can't read range file for [test1725heute in habitat_amount] > WARNING: color support for [test1725heute] in mapset [habitat_amount] > missing > ERROR: Color file for [test1725heute] not available Martin, most likely a "make distclean" and full recompile will cure the problem. Did you try this? Markus From michael.barton at asu.edu Tue Apr 24 02:55:59 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Apr 24 02:56:07 2007 Subject: [GRASS-dev] Replacement of NVIZ In-Reply-To: <17965.545.466628.424478@cerise.gclements.plus.com> Message-ID: On 4/23/07 11:59 AM, "Glynn Clements" wrote: > > Michael Barton wrote: > >> Why do you think it is not maintainable? We are maintaining it now and it is >> far better than equivalent packages in other GIS platforms (if they even >> exist). There also are likely to be more people with python/wxPython >> expertise than we now have with TclTk expertise, which bodes well for future >> maintainability and enhancements. > > How long have we been trying to get "max res PPM" working (or, at > least, to fail in ways which don't involve rebooting)? Maybe we should give up on this ;-) > > Beyond that, NVIZ is pretty ugly, structurally. Agreed. It still uses quite a bit of very old TclTk syntax, as well as some very clunky ways of doing things (maybe necessitated when it was written). There is a lot of legacy code in GRASS, simply because it's been around so long with so many contributors. > >> We should be conservative about taking on **new** code responsibilities >> unless we have the development team to manage them into the future. But with >> the development team growing, and inclusion into OSGEO, I don't see any >> reason to jettison existing GRASS functionality--especially a piece that is >> so good and has been a key part of GRASS for so long. Many other programs >> exist that do parts of what GRASS does (GDAL, MySQL, ParaView, GIMP, >> QCAD)--and sometimes do it with much more sophistication. GRASS brings >> needed functionality together in an integrated way to provide a rich and >> complete GIS environment. > > I thought that NVIZ *was* going to be jettisoned in favour of a Python > version? That process isn't going to retain much of the original code. Agreed again. There is no point in simply porting the current NVIZ to wxPython. This is a good chance to improve visualization in general. However, I'd hate to lose the ability to visualize multidimensional data within GRASS like we can now--however it is done. Rather than passing off visualization to other apps, I'd hope we can take this opportunity to improve how it works in GRASS. > > FWIW, I would be in favour of doing that. Apart from anything else, a > replacement ought to be much cleaner. > > More generally, when creating an application of that level of > complexity, structure matters. A lot. It isn't sufficient for the end > result to work; people need to be able to modify it without first > having to spend days or even weeks studying the code. Yes. And documentation helps a lot too. > > Regarding "PyNVIZ", my main suggestion would be to keep the amount of > C to a bare minimum. Create direct Python bindings for OGSF and write > the rest in Python. Trying to understand code which is split between > multiple languages is hard, and debugging it is even worse. Only dealing with the GUI end of it, I take your word on this. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Tue Apr 24 03:02:28 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Apr 24 03:02:33 2007 Subject: [GRASS-dev] using system fonts? In-Reply-To: <17964.65180.772776.762079@cerise.gclements.plus.com> Message-ID: I guess, I'm thinking of my Mac-centric world (thought similar for Windows too), where bringing up a font selection dialog lets me access the fonts installed on my system and send their specifications to a display app. I don't have to go searching for them. These are the bitmapped fonts, in general I guess. It would simply be nice to be able to make a consistent font selection interface across GRASS. I don't use Linux enough to know where a font-selection dialog created by wxPython, for example, gets its fonts. Maybe it's more a matter of specifying fonts. Currently, we have to give a TT font file path. Could it accept a bitmapped font description too (font name, style, color, size)? Michael On 4/23/07 11:44 AM, "Glynn Clements" wrote: > > Michael Barton wrote: > >> Perhaps this is a silly question, but is there any way to use system fonts >> in GRASS. Currently, we either need to use a stroke font (the default, ugly) >> or specify a path to a Truetype font. >> >> It is quite easy to get system font information (family, name, style, size, >> color, etc) from a standard system font dialog in wxPython (and in TclTk >> too). Is there some way to pass that information to GRASS so that it will be >> the display font. Or could there be a flag/GRASS environmental variable, to >> make the default system font the default GRASS font? Then the default could >> be changed as desired. Imagine Helvetica/Lucida Grand/Arial as the default >> font for legends, bar scales, and the like... > > Adding support for bitmap fonts would be reasonably straightforward, > but getting those fonts without using X might be a different matter > (bear in mind that there might not be any font files on the local > system. X can get its fonts from a font server). > > Personally, I would have thought that the Freetype support would be > sufficient. If it isn't, I can look into either stealing the > PCF-reading code from X, or writing an X-based font-dumping utility. > Obviously, I don't want to make the PNG/PS drivers link directly > against Xlib. > > BTW, the term "default system font" isn't clear-cut. Different > toolkits may have different ideas as to the default font. Xt uses X > resources. Tcl/Tk manually parses certain X resource files (but not in > the same that Xt does), so it might use the same font as Xt-based > applications or it might not. GTK and Qt have their own mechanisms, > and can vary depending upon whether they are being used under Gnome or > KDE. __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From hamish_nospam at yahoo.com Tue Apr 24 03:14:44 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Apr 24 03:15:35 2007 Subject: [GRASS-dev] Re: numeric-numpy-scipy for graphs? In-Reply-To: References: Message-ID: <20070424131444.0c553d0b.hamish_nospam@yahoo.com> Paul Kelly wrote: > Obviously numerical calculations and that kind of stuff is best done > in C in the GRASS libraries and modules to make it available also for > command-line and scripting use. Let's not forget SWIG Python bindings into libgis to make some/many/all libgis tools available for Python scripters! No new system modules needed for little tasks. (or at least that is my understanding of SWIG; never used it myself...) Hamish From glynn at gclements.plus.com Tue Apr 24 03:37:44 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Apr 24 03:38:10 2007 Subject: [GRASS-dev] using system fonts? In-Reply-To: References: <17964.65180.772776.762079@cerise.gclements.plus.com> Message-ID: <17965.24424.12098.308972@cerise.gclements.plus.com> Michael Barton wrote: > I guess, I'm thinking of my Mac-centric world (thought similar for Windows > too), where bringing up a font selection dialog lets me access the fonts > installed on my system and send their specifications to a display app. I > don't have to go searching for them. These are the bitmapped fonts, in > general I guess. That would surprise me; TrueType fonts seem to be the norm nowadays. Bear in mind that TTF files can contain pre-rendered bitmaps for common sizes; the FreeType library will use these automatically if they are found. > It would simply be nice to be able to make a consistent font selection > interface across GRASS. I don't use Linux enough to know where a > font-selection dialog created by wxPython, for example, gets its fonts. That depends upon the toolkit which wx uses, and the options it was built with (e.g. whether it uses Xft). > Maybe it's more a matter of specifying fonts. Currently, we have to give a > TT font file path. Could it accept a bitmapped font description too (font > name, style, color, size)? In general, no. X applications can tell the X server to use a font by name. The X server knows where to get the fonts from via the FontPath settings in the xorg.conf file (previously XF86Config). Non-X applications won't easily be able to find whatever fonts X is using; they may not even be available from the system on which the client is running (other than by "dumping" them, i.e. drawing text into a pixmap then grabbing the pixmap contents from the server; for TrueType fonts, this will get you pre-rendered bitmaps rather than the outlines). Every application which wants to do something with fonts other than render them via X has the same issues; even X applications which need to get at the actual fonts to e.g. embed them in a PDF file. -- Glynn Clements From woklist at kyngchaos.com Tue Apr 24 03:42:06 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Tue Apr 24 03:42:22 2007 Subject: [GRASS-dev] using system fonts? In-Reply-To: References: Message-ID: <00DFBA40-9881-4964-92CD-C6E88AC3BFCC@kyngchaos.com> I wonder if [wx]Python has a general font handling API that taps into the platform font/type API - for both selecting and drawing fonts. Especially on OSX, probably Windows, available fonts are not just what's "installed". There are 3rd party utilities that 'activate' fonts outside the normal font folders, using the system API. On Apr 23, 2007, at 8:02 PM, Michael Barton wrote: > I guess, I'm thinking of my Mac-centric world (thought similar for > Windows > too), where bringing up a font selection dialog lets me access the > fonts > installed on my system and send their specifications to a display > app. I > don't have to go searching for them. These are the bitmapped fonts, in > general I guess. > > It would simply be nice to be able to make a consistent font selection > interface across GRASS. I don't use Linux enough to know where a > font-selection dialog created by wxPython, for example, gets its > fonts. > > Maybe it's more a matter of specifying fonts. Currently, we have to > give a > TT font file path. Could it accept a bitmapped font description too > (font > name, style, color, size)? > > Michael > ----- William Kyngesburye http://www.kyngchaos.com/ [Trillian] What are you supposed to do WITH a maniacally depressed robot? [Marvin] You think you have problems? What are you supposed to do if you ARE a maniacally depressed robot? No, don't try and answer, I'm 50,000 times more intelligent than you and even I don't know the answer... - HitchHiker's Guide to the Galaxy From glynn at gclements.plus.com Tue Apr 24 04:14:50 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Apr 24 04:15:04 2007 Subject: [GRASS-dev] using system fonts? In-Reply-To: <00DFBA40-9881-4964-92CD-C6E88AC3BFCC@kyngchaos.com> References: <00DFBA40-9881-4964-92CD-C6E88AC3BFCC@kyngchaos.com> Message-ID: <17965.26650.952525.389533@cerise.gclements.plus.com> William Kyngesburye wrote: > I wonder if [wx]Python has a general font handling API that taps into > the platform font/type API - for both selecting and drawing fonts. Yes. But that doesn't help us at all, as it won't actually tell you where to find the .ttf file so that the display drivers can use it. -- Glynn Clements From woklist at kyngchaos.com Tue Apr 24 04:56:09 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Tue Apr 24 04:56:24 2007 Subject: [GRASS-dev] using system fonts? In-Reply-To: <17965.26650.952525.389533@cerise.gclements.plus.com> References: <00DFBA40-9881-4964-92CD-C6E88AC3BFCC@kyngchaos.com> <17965.26650.952525.389533@cerise.gclements.plus.com> Message-ID: Ah, I was thinking of font rendering with Python, not directly in a GRASS display module or driver. Even so, the Python font API (whatever it may be) might have some method of obtaining the font file path? On Apr 23, 2007, at 9:14 PM, Glynn Clements wrote: > > William Kyngesburye wrote: > >> I wonder if [wx]Python has a general font handling API that taps into >> the platform font/type API - for both selecting and drawing fonts. > > Yes. But that doesn't help us at all, as it won't actually tell you > where to find the .ttf file so that the display drivers can use it. > > -- > Glynn Clements ----- William Kyngesburye http://www.kyngchaos.com/ "Time is an illusion - lunchtime doubly so." - Ford Prefect From michael.barton at asu.edu Tue Apr 24 05:39:17 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Apr 24 05:39:24 2007 Subject: [GRASS-dev] using system fonts? In-Reply-To: Message-ID: If there is a way to get the path from the multitude of font information I CAN get, I can't find it. Everything but. What I'd like to get away from is for everyone to have to search for their fonts to use in GRASS. On the Mac, most are in /Library/fonts. However, some are also in the X11RC directory. On different Linux systems they are in other places, and for Windows I have no idea where they live. This means that there is no way to design a generic font picker for GRASS that will simply list available fonts. I CAN get a generic font picker from a GUI package, but at least with wxPython and TclTk, it provides lots of information about font DESCRIPTION, but nothing (that I can find) about font LOCATION and file name. Maybe it's just not possible to specify font description for GRASS display (or more trouble than it's worth for one reason or another). But it would be nice. The other thing that makes this more complicated is that, if I understand it correctly, font settings do not persist past a single display event. This provides greater flexibility in creating displays with different fonts, but it makes it harder to set a default font for all GRASS unless you want to change it. This is all doable and possible to have nice displays in GRASS. It's just complicated to code into a GUI. I'll stop whining now. Michael On 4/23/07 7:56 PM, "William Kyngesburye" wrote: > Ah, I was thinking of font rendering with Python, not directly in a > GRASS display module or driver. Even so, the Python font API > (whatever it may be) might have some method of obtaining the font > file path? > > On Apr 23, 2007, at 9:14 PM, Glynn Clements wrote: > >> >> William Kyngesburye wrote: >> >>> I wonder if [wx]Python has a general font handling API that taps into >>> the platform font/type API - for both selecting and drawing fonts. >> >> Yes. But that doesn't help us at all, as it won't actually tell you >> where to find the .ttf file so that the display drivers can use it. >> >> -- >> Glynn Clements > > ----- > William Kyngesburye > http://www.kyngchaos.com/ > > "Time is an illusion - lunchtime doubly so." > > - Ford Prefect > > __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Tue Apr 24 05:43:06 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Apr 24 05:43:14 2007 Subject: [GRASS-dev] Re: numeric-numpy-scipy for graphs? In-Reply-To: <20070424131444.0c553d0b.hamish_nospam@yahoo.com> Message-ID: On 4/23/07 6:14 PM, "Hamish" wrote: > Paul Kelly wrote: >> Obviously numerical calculations and that kind of stuff is best done >> in C in the GRASS libraries and modules to make it available also for >> command-line and scripting use. > > Let's not forget SWIG Python bindings into libgis to make some/many/all > libgis tools available for Python scripters! No new system modules > needed for little tasks. > > (or at least that is my understanding of SWIG; never used it myself...) Nor I. But it would probably be useful to understand how it works. Michael > > > Hamish __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From hamish_nospam at yahoo.com Tue Apr 24 06:44:43 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Apr 24 06:44:54 2007 Subject: [GRASS-dev] Replacement of NVIZ In-Reply-To: References: <462CB8B7.7080101@faunalia.it> Message-ID: <20070424164443.12085c13.hamish_nospam@yahoo.com> Carlos wrote: > Even though I am not a real developer, I just want to say that NVIZ > rocks! It could have some other features (like, create a view with a > oberserver at XXX YYY ZZZ looking to 275 deg north, or something) not simply, but it is possible. For example d.nviz creates a script to do "create a view with a oberserver at XXX YYY ZZZ ..." in a reproducable way. Studying that code might help you write your own little script to set the shots up as needed. Frankly I'm surprised no one has ever added these controls in to a NVIZ panel yet, it's a common need and I'm guessing it wouldn't be too hard. Glynn: > How long have we been trying to get "max res PPM" working (or, at > least, to fail in ways which don't involve rebooting)? AFAIK, the 6.2 branch defaults to on-screen rendering, and the bug is only noticable in the devel branch where it attempts to do off-screen rendering by default. Don't know if the on-screen rendering is susceptible to overlapping windows corrupting the snapshot or if double- buffering has been implemented to avoid that. Hamish From glynn at gclements.plus.com Tue Apr 24 06:54:18 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Apr 24 06:54:24 2007 Subject: [GRASS-dev] using system fonts? In-Reply-To: References: <00DFBA40-9881-4964-92CD-C6E88AC3BFCC@kyngchaos.com> <17965.26650.952525.389533@cerise.gclements.plus.com> Message-ID: <17965.36218.347285.223026@cerise.gclements.plus.com> William Kyngesburye wrote: > Ah, I was thinking of font rendering with Python, not directly in a > GRASS display module or driver. Even so, the Python font API > (whatever it may be) might have some method of obtaining the font > file path? Nope; that information simply isn't available. The way that fonts work in a GUI is that the GUI (usually) provides some way to obtain a list of names, and (invariably) provides some way to select a font using a name. As for paths: there may not be any paths. The X server can get its fonts from a font server; as for where the font server gets those fonts from, not even the X server knows. And even if it did, that doesn't help if it can't access the filesystem on the box which is running the font server. And even if the X server gets those fonts from files, those files may not be accessible to the X client. I do all of my GRASS development on my Linux box. When I say "on", I mean that's where the shell is running, that's where make, gcc etc run, that's where GRASS programs are run. The Linux box doesn't have a monitor. The Windows box has a monitor, and that's where the X server runs, and that's where all of my windows (XEmacs, xterm, XDRIVER, gis.m etc) show up. The X server is using the fonts on the Windows box (i.e. /usr/X11R6/lib/X11/fonts/* in Cygwin, or C:\cygwin\usr\X11R6\lib\X11\fonts in Windows). Those paths simply aren't accessible to gis.m or other programs running on the Linux box. Now, I do have a reasonable set of fonts available on the Linux box, in /usr/share/fonts/*. But there is absolutely no standard API function (whether in C or Tk or Python or anything else) which is going to reveal this fact to the PNG driver. It *has* to be told. -- Glynn Clements From michael.barton at asu.edu Tue Apr 24 07:12:35 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Apr 24 07:12:45 2007 Subject: [GRASS-dev] setting 'default' font Message-ID: Glynn, I?m thinking about making a convenience default setting dialog for GRASS in the wxPython GUI. It would simply let users select a TT font (Do I need to have an option for a stroke font too?). This font would then be set at render time using the GRASS_FONT environmental variable. Is there any way to set the size for the font (e.g., for legends and scalebars where you can?t select a size)? Or is it just a font name? Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070423/e6d0b365/attachment.html From glynn at gclements.plus.com Tue Apr 24 07:18:44 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Apr 24 07:19:14 2007 Subject: [GRASS-dev] using system fonts? In-Reply-To: References: Message-ID: <17965.37684.49006.600577@cerise.gclements.plus.com> Michael Barton wrote: > If there is a way to get the path from the multitude of font information I > CAN get, I can't find it. Everything but. > > What I'd like to get away from is for everyone to have to search for their > fonts to use in GRASS. On the Mac, most are in /Library/fonts. However, some > are also in the X11RC directory. On different Linux systems they are in > other places, and for Windows I have no idea where they live. > > This means that there is no way to design a generic font picker for GRASS > that will simply list available fonts. I CAN get a generic font picker from > a GUI package, but at least with wxPython and TclTk, it provides lots of > information about font DESCRIPTION, but nothing (that I can find) about font > LOCATION and file name. > > Maybe it's just not possible to specify font description for GRASS display > (or more trouble than it's worth for one reason or another). But it would be > nice. At a minimum, it requires that the renderer knows where the fonts are, and can get at them. > The other thing that makes this more complicated is that, if I understand it > correctly, font settings do not persist past a single display event. This > provides greater flexibility in creating displays with different fonts, but > it makes it harder to set a default font for all GRASS unless you want to > change it. For direct rendering, the font is set from environment variables. That means that they can only be changed by an ancestor of any d.* commands (e.g. the shell, gis.m, gism.py etc), and not by a sibling (the way that d.font works). The font could easily be set from a GRASS variable, but that's basically a bad idea. It doesn't make it any easier for a GUI (setting an environment variable is no harder than running d.font), and causes problems due to statefulness, i.e. the order in which you execute the display commands matters, you can't run multiple display commands concurrently, etc. In general, global state is bad. Its use in GRASS is due to its CLI origins, where having to specify the database, location, mapset, region, monitor, font, etc as explicit parameters for each command would be a nuisance. Mostly, you want those parameters to be the same for successive commands until you say otherwise, so you use global state to eliminate the need to keep typing them. For a GUI, this isn't an issue; the GUI can keep track of the state. Moreover, if you want to change a parameter for an individual command, you don't have to modify global state, run the command, change the state back, and hope that the modification didn't interfere with anything else which was running concurrently. -- Glynn Clements From michael.barton at asu.edu Tue Apr 24 07:23:20 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Apr 24 07:23:30 2007 Subject: [GRASS-dev] another idea for font setting Message-ID: How about a GRASS_FONTPATH variable set in init.sh (or an environmental variable if that?s better). It could work like some of the other such path variables. Check to see if it?s already set (e.g., in .grassrc6 or .profile). If it?s not already set, try some default settings: /Library/Fonts for Darwin systems, a ?normal? linux font place, a ?normal? windows font place. A font setting dialog could get this path from the variable and insert it into a font path browse control. For many people, they would not need to do anything but pick from the list of fonts in that directory. But the control would still allow a user to browse for another locality if their fonts were in a different place. This gives some degree of convenience for the many people who have fonts in a standard location for their platform and provides 2 ways to deal with those who don?t?in a configuration file (for GRASS or shell) or by browsing to the font location. Trying to find a way to make this a bit easier for many, while dealing with the considerable variability across systems. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070423/c3b934a6/attachment.html From michael.barton at asu.edu Tue Apr 24 07:25:53 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Apr 24 07:26:36 2007 Subject: [GRASS-dev] Re: numeric-numpy-scipy for graphs? In-Reply-To: <17964.30630.226470.371251@cerise.gclements.plus.com> Message-ID: Should we go ahead and set this in the rendering section of the TclTk and wxPython code? Do we need to turn it off after each rendering? Michael On 4/23/07 2:08 AM, "Glynn Clements" wrote: > [BTW, on the subject of perfomance: I've extended the PNG driver to > support writing 32-bpp BMP files. More significantly, if you set > GRASS_PNG_MAPPED=TRUE, it will immediately write out the file, then > mmap() for use as its framebuffer, so it doesn't have to explicitly > write the file after each command.] __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From hamish_nospam at yahoo.com Tue Apr 24 07:50:11 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Apr 24 07:50:26 2007 Subject: [GRASS-dev] numeric-numpy-scipy for graphs? In-Reply-To: References: <17964.32012.691862.169314@cerise.gclements.plus.com> Message-ID: <20070424175011.4b5067df.hamish_nospam@yahoo.com> Michael Barton wrote: > The one complication is changing window size. The GRASS command would > need to be rerun and the graphic rendered. With the new PS driver, we > might not be stuck with a rasterized version. just to throw something else out there: What if we had a SVG driver? http://en.wikipedia.org/wiki/Svg very rough idea: If window bounds are the same, maybe it is easier to render raster maps in the PNG driver and vector maps & decorations in the SVG driver before combining with g.pnmcomp? > If writing C code for simple native GRASS plotting is as > straightforward as Glynn suggests, it might be worth a look. If following that path, prototype what you want to do with d.graph first. Translating from that into C is pretty easy. > d.histogram already can render to a graphics file that can be > displayed in a canvas. An equivalent (non-interactive) d.profile does > not exist (perhaps a flag added to r.profile?) I don't fully understand your idea, but if you are getting at what I think you are getting at, I'm a bit doubtful that it should be in r.profile. (better use a wrapper script that calls r.profile) IMO GRASS 5 d.profile and d.histogram are too ugly to live. I welcome GUI replacements for them both. Hamish From hamish_nospam at yahoo.com Tue Apr 24 07:57:34 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Apr 24 07:58:26 2007 Subject: [GRASS-dev] using system fonts? In-Reply-To: <17965.36218.347285.223026@cerise.gclements.plus.com> References: <00DFBA40-9881-4964-92CD-C6E88AC3BFCC@kyngchaos.com> <17965.26650.952525.389533@cerise.gclements.plus.com> <17965.36218.347285.223026@cerise.gclements.plus.com> Message-ID: <20070424175734.090c3670.hamish_nospam@yahoo.com> Glynn Clements wrote: > > Nope; that information simply isn't available. > > The way that fonts work in a GUI is that the GUI (usually) provides > some way to obtain a list of names, and (invariably) provides some way > to select a font using a name. perhaps add a script to the GUI Config menu to search the system for .ttf fonts and dump to a .grass fontcap file? eg for {`uname -s` = "Darwin"} look in wherever Mac dumps fonts, for Windows use a .bat file that looks in C:\Windows\fonts\*.ttf (or wherever), and for Linux /usr/X11R6/lib/X11/fonts/* or other common dumping grounds. if any files are on that list you get an easy picker, if not you can always select the . ??, Hamish From michael.barton at asu.edu Tue Apr 24 08:14:10 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Apr 24 08:14:16 2007 Subject: [GRASS-dev] using system fonts? In-Reply-To: <20070424175734.090c3670.hamish_nospam@yahoo.com> Message-ID: This is what I was thinking of with a GRASS_FONTPATH variable. It could either set these as reasonable defaults or read what is specifically set in a configuration file (e.g., .grassrc6 or .profile). Michael On 4/23/07 10:57 PM, "Hamish" wrote: > Glynn Clements wrote: >> >> Nope; that information simply isn't available. >> >> The way that fonts work in a GUI is that the GUI (usually) provides >> some way to obtain a list of names, and (invariably) provides some way >> to select a font using a name. > > > perhaps add a script to the GUI Config menu to search the system for > .ttf fonts and dump to a .grass fontcap file? > > eg for {`uname -s` = "Darwin"} look in wherever Mac dumps fonts, for > Windows use a .bat file that looks in C:\Windows\fonts\*.ttf (or > wherever), and for Linux /usr/X11R6/lib/X11/fonts/* or other common > dumping grounds. > > if any files are on that list you get an easy picker, if not you can > always select the . > > > ??, > Hamish __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Tue Apr 24 08:17:44 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Apr 24 08:17:51 2007 Subject: [GRASS-dev] using system fonts? In-Reply-To: <17965.37684.49006.600577@cerise.gclements.plus.com> Message-ID: This is what I'm trying to think about and maybe try something. I can certainly create a file browser that would let a user find and select a True Type font. I'm just trying to think of a way that a user doesn't have to try to figure out where the fonts are stored--or at the very least give them a reasonable hint to start with. Maybe everyone using Linux knows the path to the fonts, but I'd wager that most people using Mac's and Windows don't know this. Michael On 4/23/07 10:18 PM, "Glynn Clements" wrote: > For a GUI, this isn't an issue; the GUI can keep track of the state. > Moreover, if you want to change a parameter for an individual command, > you don't have to modify global state, run the command, change the > state back, and hope that the modification didn't interfere with > anything else which was running concurrently. > __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From hamish_nospam at yahoo.com Tue Apr 24 08:20:16 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Apr 24 08:20:22 2007 Subject: [GRASS-dev] numeric-numpy-scipy for graphs? In-Reply-To: References: <20070423181556.715a1b72.hamish_nospam@yahoo.com> Message-ID: <20070424182016.2f0c7a75.hamish_nospam@yahoo.com> > >> "wolle" wrote: > >>> have a look at matplotlib http://matplotlib.sourceforge.net/ > >>> It depends on numeric. > > > > Michael wrote: > >> Really impressive! > > Hamish: > > oh, and by the way, IMO translucency is the neat way to go for > > bubble plots, not sorting by size before rendering and drawing the > > little ones on top (can lead to coin toss overlap results; you lose > > any order/time info in the data). > > > > e.g. study these two: > > > > http://matplotlib.sourceforge.net/screenshots/scatter_demo2_large.png > > > > and attached graphic (clipped from the NY Times online edition a few > > days ago) which demonstrates it quite well. > Michael Barton wrote: > I agree about the translucency. Looks nice AND is more informative. For the record, I don't mean to say that sorting isn't a nice short-term solution, it is. Translucency is just a nicer long-term solution. Hamish From hamish_nospam at yahoo.com Tue Apr 24 08:24:01 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Apr 24 08:24:21 2007 Subject: [GRASS-dev] any way to know color assigned to a cell? In-Reply-To: <1a486f560704222356u28911cdbs80fced279a384e6f@mail.gmail.com> References: <17950.48109.88914.169521@cerise.gclements.plus.com> <20070422231950.6abc0ba8.hamish_nospam@yahoo.com> <1a486f560704222356u28911cdbs80fced279a384e6f@mail.gmail.com> Message-ID: <20070424182401.3672005f.hamish_nospam@yahoo.com> Daniel Calvelo wrote: > On 4/22/07, Hamish wrote: > [...] > > what RGB triplet pattern does xwPython prefer? > > Either (in printf format): "\"#%02x%02x%02x\"" (quotes included: a > string may be given as color in the form of a wx color name or a hex > triplet) or "(%d,%d,%d)" (an integer triplet, 0-255 values). > > So red is one of: > > "RED" > "#FF0000" > (255,0,0) curious, is "wx color name" the same as X11 color names? (honeydew4 etc as given in /usr/lib/X11/rgb.txt) or just basic red,green,blue,.. ? Hamish From tutey at o2.pl Tue Apr 24 08:56:16 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Tue Apr 24 08:56:25 2007 Subject: [GRASS-dev] Re: [GRASS-user] v.digit cannot update table In-Reply-To: <87wt024xiu.fsf@patagonia.sebmags.homelinux.org> References: <87abx15xpd.fsf@patagonia.sebmags.homelinux.org> <87wt024xiu.fsf@patagonia.sebmags.homelinux.org> Message-ID: <462DAA10.30005@o2.pl> Seb wrote: > On Sat, 21 Apr 2007 14:33:50 -0500, > Seb wrote: > >> Hi, In GRASS CVS, I'm encountering problems digitizing into a vector >> with the following: > > >> v.digit -n map=newvect bg="d.vect coastline" > > >> Clicking on the settings button -> table tab -> "create table" tells me >> that a new empty map has been created. I then proceed with the >> "digitize new boundary" button and create a polygon. When >> right-clicking to close the line I'm asked about what encoding to use (I >> leave it as utf-8 which which is my locale) and then "submit", I receive >> the following error: > > The cause of this error was that the table needs to have more than the > 'cat' column. I was simply creating the table without adding an extra > column because I don't need any attributes. The problem has been already reported 8 months ago: http://intevation.de/rt/webrt?serial_num=5127 Maciek From benjamin.ducke at ufg.uni-kiel.de Tue Apr 24 09:13:04 2007 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Tue Apr 24 08:57:40 2007 Subject: [GRASS-dev] DBMI trouble compiling on Win32 In-Reply-To: <17964.63589.195731.772348@cerise.gclements.plus.com> References: <4628DA68.7080004@ufg.uni-kiel.de> <17960.65018.271320.735672@cerise.gclements.plus.com> <462CAE5F.9090707@ufg.uni-kiel.de> <462CC6A0.3000003@club.worldonline.be> <17964.63589.195731.772348@cerise.gclements.plus.com> Message-ID: <462DAE00.2080404@ufg.uni-kiel.de> OK, this seems to have done the trick. Thanks for the quick help. In the future, I will try to find more time to compile and test the CVS version of GRASS more frequently on Win32, so problems like these will surface early. Benjamin Glynn Clements wrote: > Moritz Lennert wrote: > >>> This fixed things in part. However, now I have a problem with the DBMI >>> lib: >>> >>> cd /src/grass6/lib/db/dbmi_client >>> make >>> >>> gives me: >>> >>> gcc -I/src/grass6/dist.i686-pc-mingw32/include -I/include >>> -I/local/include -g -O2 -I/include -I/local/include >>> -DPACKAGE=\""grasslibs"\" -I../dbmi_base -DPACKAGE=\""grasslibs"\" >>> -I/src/grass6/dist.i686-pc-mingw32/include \ >>> -o OBJ.i686-pc-mingw32/start.o -c start.c >>> start.c: In function `db_start_driver': >>> start.c:157: error: `have_stdin' undeclared (first use in this function) >>> start.c:157: error: (Each undeclared identifier is reported only once >>> start.c:157: error: for each function it appears in.) >>> start.c:157: error: `have_stdout' undeclared (first use in this function) >>> start.c:162: error: `stdin_fd' undeclared (first use in this function) >>> start.c:168: error: `stdin_orig' undeclared (first use in this function) >>> start.c:185: error: `stdout_fd' undeclared (first use in this function) >>> start.c:191: error: `stdout_orig' undeclared (first use in this function) >>> make[1]: *** [OBJ.i686-pc-mingw32/start.o] Error 1 >>> make[1]: Leaving directory `/src/grass6/lib/db/dbmi_client' >>> >>> >>> Maybe something needs to be fixed in the configure script for Win32? >> This seems to come from Brad's latest change to start.c: >> >> >> @@ -33,9 +38,6 @@ >> int stat; >> dbConnection connection; >> char ebuf[5]; >> - int stdin_orig, stdout_orig; >> - int have_stdin, have_stdout; >> - int stdin_fd, stdout_fd; >> >> Brad, any special reason for this, or did you just not see that these >> are used in the #ifdef __MINGW32__ which starts at line 117 ? > > Almost certainly the latter. I've restored the variables, > conditionalised upon "#ifdef __MINGW32__" to prevent "unused variable" > warnings on other platforms (which is probably the reason that they > were removed). > -- Benjamin Ducke, M.A. Arch?oinformatik (Archaeoinformation Science) Institut f?r Ur- und Fr?hgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universit?t zu Kiel Johanna-Mestorf-Stra?e 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg From michael.barton at asu.edu Tue Apr 24 09:25:10 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Apr 24 09:25:20 2007 Subject: [GRASS-dev] numeric-numpy-scipy for graphs? In-Reply-To: <20070424175011.4b5067df.hamish_nospam@yahoo.com> Message-ID: On 4/23/07 10:50 PM, "Hamish" wrote: >> d.histogram already can render to a graphics file that can be >> displayed in a canvas. An equivalent (non-interactive) d.profile does >> not exist (perhaps a flag added to r.profile?) > > I don't fully understand your idea, but if you are getting at what I > think you are getting at, I'm a bit doubtful that it should be in > r.profile. (better use a wrapper script that calls r.profile) d.histogram can be run non-interactively. This makes is possible to have it draw to a PNG and popup in a window. d.profile cannot be run interactively. So without some kind of modification (to d.profile or r.profile) the only recourse is to draw the profile in the GUI, like in the TclTk one. > > IMO GRASS 5 d.profile and d.histogram are too ugly to live. I welcome > GUI replacements for them both. No disagreement from me about the need for better versions of both. I don't mind doing this in the GUI. But if we can have nice C versions that can be called from a script or displayed in the GUI, that's OK too. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Tue Apr 24 09:34:22 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Apr 24 09:34:29 2007 Subject: [GRASS-dev] numeric-numpy-scipy for graphs? In-Reply-To: <20070424175011.4b5067df.hamish_nospam@yahoo.com> Message-ID: Actually, as you mentioned earlier, d.linegraph has the beginnings of the tools needed to do both profile and histogram. I haven't tried it in ages, but might take a look at what it looks like. Michael On 4/23/07 10:50 PM, "Hamish" wrote: >> If writing C code for simple native GRASS plotting is as >> straightforward as Glynn suggests, it might be worth a look. > > If following that path, prototype what you want to do with d.graph > first. Translating from that into C is pretty easy. > __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From hamish_nospam at yahoo.com Tue Apr 24 09:56:58 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Apr 24 09:57:09 2007 Subject: [GRASS-dev] d.vect.chart legends In-Reply-To: <20070423000007.65d4f949.hamish_nospam@yahoo.com> References: <20070422000122.3121d068.hamish_nospam@yahoo.com> <20070423000007.65d4f949.hamish_nospam@yahoo.com> Message-ID: <20070424195658.25cc8f77.hamish_nospam@yahoo.com> > Hamish: > > > I just added a new -l flag to d.vect.chart to output info needed > > > to create legends for charts. Previously you just got different > > > colors with no reference to which columns they represented (using > > > default colors). > > > > > > this can be parsed to make a legend, either using d.graph (like > > > d.vect.thematic does) or by storing the info in a raster map's > > > metadata and using d.legend to make the map > > Michael: > > This is conceptually a nice way for getting legends for a vector > > map, using the tools we now have. There have been repeated requests > > for a way to get legends for vector maps. Could this be systematized > > somehow in a script, or better in the vector code, in some way. > > > > For example, a flag that would automatically create a tiny legend > > raster that could be used with d.legend. This could be built out of: > > the RGB column for vectors, out of random vector colors, built with > > a script for d.vect.thematic (until the C version is done), created > > for d.vect.chart like you did for text output. > Hamish: > I consider the mini-raster map method an Add-on hack- you get lots of > tmp_chart_$$ raster maps left over in your mapset. Not a satisfactory > solution for the main distribution. > > I guess the best solution is to add categorical vector legends to > d.legend. This would reuse the integer CELL map legend code to draw > filled boxes[, cat number][, and labels], using cat # and RGBCOLOR > column from a DB table. > > Note in the posted script I use the raw column name as the cat label. > In production you'd probably want to edit that to something nicer (eg > >10 > chars). At least in the d.vect.chart case divining nice labels from > the input vector map isn't really an option, so I'm not sure how to do > that beyond either a) adding an option to d.vect.chart with ';' sep > labels, or b) creating a new DB table from the output of 'd.v.chart > -l', then leave it to the user reset the label column themselves if > they want. > > Using (b) would mean d.legend didn't care about vector maps, only DB > tables in the form of: "cat|label|color". Which might not be such a > bad solution as it is very flexible. An intermediary shell script > awk'ing v.db.select should be able to create that from a vector map in > thematic cases??? (I've never had the need to do thematic vector > mapping in GRASS, so I can't really appreciate the required dataflow) > > Note the d.vect.chart legend is formed from the columns= and colors= > options, not anything to do with the vector map. > > Another complication is that I didn't functionalize d.legend when I > had the chance, and now it is a very large and very fragile piece of > code. As it is currently working very well I am a bit loathe to touch > it. I fear to functionalize the module will require a lot of (module) > global variables, which defeats the purpose IMO (result is still > logically messy). > > Perhaps start over with a clean legend module/tool/lib fn which takes > "cat|label|color" as input and farm out all rast+vect categorical > legends to that? You'd have to pass on all the rendering info, so it's > still problematic and doesn't gain you much abstraction. d.legend idea: if data is fed from stdin (signaled by map=-) create categorical legend using that data. Data format: "cat|label|color" e.g. d.legend -m map="-" < Hi, after recent changes r.le.setup fails to build due to implicit declaration of G_ask_sites_old(), G_fopen_sites_old(), and G_get_site(). More generally sample.c should be using a vector points map there, not an old sites map. sample.c: In function `sample': sample.c:54: warning: unused variable `btn' sample.c: In function `man_unit': sample.c:124: warning: unused variable `dx' sample.c:124: warning: unused variable `dy' sample.c:125: warning: unused variable `l0' sample.c:125: warning: unused variable `t0' sample.c:125: warning: unused variable `randflag' sample.c:126: warning: unused variable `itmp' sample.c:128: warning: unused variable `al' sample.c:128: warning: unused variable `ar' sample.c:128: warning: unused variable `at' sample.c:128: warning: unused variable `ab' sample.c:128: warning: unused variable `au_w' sample.c:128: warning: unused variable `au_l' sample.c:132: warning: unused variable `sites_mapset' sample.c:133: warning: unused variable `wind' sample.c: In function `draw_grid': sample.c:661: warning: unused variable `k' sample.c:661: warning: unused variable `itmp' sample.c:661: warning: unused variable `tmp' sample.c: In function `calc_unit_loc': sample.c:827: warning: suggest parentheses around assignment used as truth value sample.c:916: error: implicit declaration of function `G_ask_sites_old' sample.c:916: warning: assignment makes pointer from integer without a cast sample.c:922: error: implicit declaration of function `G_fopen_sites_old' sample.c:922: warning: assignment makes pointer from integer without a cast sample.c:930: error: implicit declaration of function `G_get_site' sample.c:733: warning: unused variable `region' sample.c:735: warning: unused variable `k' sample.c:736: warning: unused variable `tmp' sample.c: In function `graph_unit': sample.c:1042: warning: unused variable `tmpw' sample.c:1042: warning: unused variable `tmpl' sample.c: In function `draw_circle': sample.c:1473: warning: unused variable `x2' sample.c:1473: warning: unused variable `yr' sample.c: In function `numtrap': sample.c:1519: warning: unused variable `j' make: *** [OBJ.i686-pc-linux-gnu/sample.o] Error 1 thanks, Hamish From hamish_nospam at yahoo.com Tue Apr 24 10:16:21 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Apr 24 10:16:26 2007 Subject: [GRASS-dev] v.digit segfault in 6.3-cvs Message-ID: <20070424201621.43ff4a62.hamish_nospam@yahoo.com> Hi, [latest 6.3 CVS] v.digit is segfaulting for me on startup. It gets far enough that I need to v.build the map to recover it. G63> g.gisenv set="DEBUG=3" G63> v.digit ant_coast_COPY D2/3: node = 1491 nlines = 1 D2/3: node = 1492 nl = 1 D2/3: i = 0 line = 1493 D3/3: Vect_read_line() D3/3: V2_read_line_nat(): line = 1493 D3/3: Vect__Read_line_nat: offset = 571401 D3/3: type = 2, do_cats = 0 dead = 0 D3/3: n_points = 10 D3/3: off = 571566 D2/3: node = 1492 nlines = 1 D3/3: Starting Tk_Main. D3/3: v.digit Tcl_AppInit (...) D3/3: Starting toolbox.tcl D3/3: c_tool_centre() D2/3: var_init D2/3: Variable = 0x805d800 D2/3: cat_max_get() field = 1 Segmentation fault same segfault using spearfish and copy of the roads vector. DEGUG=1: D1/1: dbln: 1 road_COPY cat $GISDBASE/$LOCATION_NAME/$MAPSET/dbf/ dbf D1/1: field = 1 name = (null), table = road_COPY, key = cat, database = $GISDBASE/$LOCATION_NAME/$MAPSET/dbf/, driver = dbf D1/1: Dblinks read D1/1: Vect_Rewind(): name = road_COPY D1/1: dig_spidx_init() D1/1: Map opened Segmentation fault thanks, Hamish From neteler at itc.it Tue Apr 24 10:22:31 2007 From: neteler at itc.it (Markus Neteler) Date: Tue Apr 24 10:22:32 2007 Subject: [GRASS-dev] r.le.setup fails to build In-Reply-To: <20070424200324.10211a72.hamish_nospam@yahoo.com> References: <20070424200324.10211a72.hamish_nospam@yahoo.com> Message-ID: <20070424082230.GD30207@bartok.itc.it> On Tue, Apr 24, 2007 at 08:03:24PM +1200, Hamish wrote: > Hi, > > after recent changes r.le.setup fails to build due to implicit declaration > of G_ask_sites_old(), G_fopen_sites_old(), and G_get_site(). > Fixed in CVS by adding #include Markus From glynn at gclements.plus.com Tue Apr 24 10:21:20 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Apr 24 10:22:54 2007 Subject: [GRASS-dev] setting 'default' font In-Reply-To: References: Message-ID: <17965.48640.910481.262401@cerise.gclements.plus.com> Michael Barton wrote: > I?m thinking about making a convenience default setting dialog for GRASS in > the wxPython GUI. It would simply let users select a TT font (Do I need to > have an option for a stroke font too?). It would be wise to allow stroke fonts to be selected, as they will always be available. The set of available stroke fonts can be obtained by listing $GISBASE/fonts/*.hmp. > This font would then be set at > render time using the GRASS_FONT environmental variable. With FreeType fonts, you also want to set GRASS_FT_ENCODING. If this isn't set, it defaults to ISO-8859-1 (this is hard-coded if built without iconv). Unless Python provides a better way, you may be able to get the locale's encoding[1] using the command "locale charmap". [1] I'm presuming that's what Python uses when passing strings to the child's argv[] or stdin. > Is there any way to set the size for the font (e.g., for legends and > scalebars where you can?t select a size)? Or is it just a font name? No, modules have to set the text size themselves. It is initially zero (and, with a standalone driver, persists between clients), so modules which draw text always set it explicitly (whether from an option, a calculation based upon the amount of text being drawn and the size of the screen, or a hard-coded constant). -- Glynn Clements From wegmann at biozentrum.uni-wuerzburg.de Tue Apr 24 10:24:44 2007 From: wegmann at biozentrum.uni-wuerzburg.de (Martin Wegmann) Date: Tue Apr 24 10:28:30 2007 Subject: [GRASS-dev] g.copy bug? In-Reply-To: <20070423190846.GA8137@bartok.itc.it> References: <200704231731.26396.wegmann@biozentrum.uni-wuerzburg.de> <20070423190846.GA8137@bartok.itc.it> Message-ID: <200704241024.44377.wegmann@biozentrum.uni-wuerzburg.de> On Monday 23 April 2007 21:08, Markus Neteler wrote: > On Mon, Apr 23, 2007 at 05:31:26PM +0200, Martin Wegmann wrote: > > Hello, > > > > g.copy from mapsetA -> mapsetB does not work witht the most current cvs > > version. > > > > if I run g.copy rast=old@mapsetX,test1725heute > > > > d.rast test1725heute > > WARNING: can't read range file for [test1725heute in habitat_amount] > > WARNING: color support for [test1725heute] in mapset [habitat_amount] > > missing > > ERROR: Color file for [test1725heute] not available > > Martin, > > most likely a "make distclean" and full recompile will > cure the problem. Did you try this? my script does: make clean make distclean cvs update -dP grass6 ./configure --with-tcltk-includes=/usr/include/tcl8.4 --with-postgres-includes=/usr/include/postgresql --with-gdal=/usr/local/bin/gdal-config --enable-largefile make make install I am recompiling it again and perhaps I'll redo it by-hand if it does not work afterwards. Martin > Markus > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From wegmann at biozentrum.uni-wuerzburg.de Tue Apr 24 10:36:31 2007 From: wegmann at biozentrum.uni-wuerzburg.de (Martin Wegmann) Date: Tue Apr 24 10:40:18 2007 Subject: [GRASS-dev] g.copy bug? In-Reply-To: <17964.64125.289050.275888@cerise.gclements.plus.com> References: <200704231731.26396.wegmann@biozentrum.uni-wuerzburg.de> <17964.64125.289050.275888@cerise.gclements.plus.com> Message-ID: <200704241036.32190.wegmann@biozentrum.uni-wuerzburg.de> On Monday 23 April 2007 20:27, Glynn Clements wrote: > Martin Wegmann wrote: > > Hello, > > > > g.copy from mapsetA -> mapsetB does not work witht the most current cvs > > version. > > > > if I run g.copy rast=old@mapsetX,test1725heute > > > > d.rast test1725heute > > WARNING: can't read range file for [test1725heute in habitat_amount] > > WARNING: color support for [test1725heute] in mapset [habitat_amount] > > missing > > ERROR: Color file for [test1725heute] not available > > > > > > r.support test1725heute > > WARNING: Can't open header file for [test1725heute in habitat_amount] > > Edit header for [test1725heute]? (y/n) [y] > > Edit header for [test1725heute@habitat_amount] > > WARNING: unable to open raster map [test1725heute in habitat_amount] > > ERROR: Cannot open raster map [test1725heute]! > > WARNING: Can't open header file for [test1725heute in habitat_amount] > > ERROR: Canceling from edit header. > > > > r.info test1725heute > > WARNING: Can't open header file for [test1725heute in habitat_amount] > > WARNING: category support for [test1725heute] in mapset [habitat_amount] > > missing > > WARNING: can't get history information for [test1725heute] in mapset > > [habitat_amount] > > WARNING: can't read range file for [test1725heute in habitat_amount] > > ERROR: could not read range file > > > > unfortunately my grass6 / 62 Debian versions are broken hence I cannot > > test it using these releases. > > > > can anybody report this bug as well? > > I can't reproduce this with a 2-day-version, which is after the recent > changes involving qualified names. I tried: > > $ g.mapsets mapset=glynn > $ g.mapsets -p > glynn > $ g.copy elevation.dem@PERMANENT,foo > Copy raster to current mapset as > $ ls /opt/grass-data/spearfish57/glynn/cell_misc/foo/ > null range > > There may be other factors involved; can you create a minimal location > which demonstrates the issue? I did it with spearfish g.copy rast=aspect@PERMANENT,testcopy same error message with compilation from yesterday. I finished cvs update, make clean, distclean, ./configure, make, make install and now I get: g.copy rast=aspect@PERMANENT,testcopy2 Copy raster to current mapset as Speicherzugriffsfehler (-> Memory access error) GRASS error or Linux problem? (Debian unstable) r.info testcopy2 WARNING: Can't open header file for [testcopy2 in anna] WARNING: category support for [testcopy2] in mapset [anna] missing WARNING: can't get history information for [testcopy2] in mapset [anna] WARNING: can't read range file for [testcopy2 in anna] ERROR: could not read range file BTW I commented \visualization out due to errors in make - but that should not affect it, should it? > > BTW is there a way to move raster between mapsets? > > Change to destination, g.copy, change to source, g.remove. > > There isn't a faster way; you can't modify mapsets other than the > current one. well, stupid question - then I change destination as usual. thanks. Martin From wegmann at biozentrum.uni-wuerzburg.de Tue Apr 24 10:44:01 2007 From: wegmann at biozentrum.uni-wuerzburg.de (Martin Wegmann) Date: Tue Apr 24 10:47:47 2007 Subject: [GRASS-dev] g.remove with @mapset problem Message-ID: <200704241044.01522.wegmann@biozentrum.uni-wuerzburg.de> Hello, I you use the GUI of g.remove and select some raster files it adds the @mapset as well which causes an error when executing this command: copy/paste of GUI command: g.remove rast=dispersalmap_missing_2@march07 Removing raster Illegal filename. Character <@> not allowed. raster: couldn't be removed Illegal filename. Character <@> not allowed. header: couldn't be removed Illegal filename. Character <@> not allowed. category: couldn't be removed Illegal filename. Character <@> not allowed. color: couldn't be removed Illegal filename. Character <@> not allowed. history: couldn't be removed Illegal filename. Character <@> not allowed. misc: couldn't be removed Illegal filename. Character <@> not allowed. fcell: couldn't be removed Illegal filename. Character <@> not allowed. g3dcell: couldn't be removed Illegal filename. Character <@> not allowed. colr2/march07: couldn't be removed nothing removed Martin From glynn at gclements.plus.com Tue Apr 24 10:47:42 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Apr 24 10:48:17 2007 Subject: [GRASS-dev] Re: numeric-numpy-scipy for graphs? In-Reply-To: References: <17964.30630.226470.371251@cerise.gclements.plus.com> Message-ID: <17965.50222.388721.599370@cerise.gclements.plus.com> Michael Barton wrote: > > [BTW, on the subject of perfomance: I've extended the PNG driver to > > support writing 32-bpp BMP files. More significantly, if you set > > GRASS_PNG_MAPPED=TRUE, it will immediately write out the file, then > > mmap() for use as its framebuffer, so it doesn't have to explicitly > > write the file after each command.] > > Should we go ahead and set this in the rendering section of the TclTk and > wxPython code? Not unless you're planning on using the BMP format (which means eliminating g.pnmcomp); it doesn't work with other formats. [Essentially, the image format needs store the actual image data as raw 32-bit pixels, which rules out both PNG and PPM/PGM. 32-bpp BMP is just that: a 54-byte header followed by raw 32-bit pixels. TGA and PAM might also be viable.] On that subject, you really should look into eliminating g.pnmcomp. AFAICT, wxWidgets doesn't feature blending (although it should be able to do compositing with binary mask), but you may be able to use e.g. PIL for that. Performing compositing internally would save on I/O when enabling, disabling and re-ordering existing layers. > Do we need to turn it off after each rendering? No. BTW, I've added a simple BMP viewer in visualization/ximgview (not compiled by default). The idea is that you can use e.g.: export GRASS_RENDER_IMMEDIATE=TRUE export GRASS_PNGFILE=map.bmp export GRASS_TRUECOLOR=TRUE export GRASS_PNG_MAPPED=TRUE export GRASS_PNG_READ=TRUE export GRASS_TRANSPARENT=TRUE ximgview image=map.bmp & to get vaguely XDRIVER-like behaviour using direct rendering. d.* commands map the BMP file as their framebuffer (rather than explicitly reading and writing it), and ximgview continually displays its contents in a window. This is primarily an experiment to see whether it would be sufficient for people who prefer the CLI/XDRIVER model over a GUI, assuming that 7.x abandons stand-alone drivers altogether. -- Glynn Clements From hamish_nospam at yahoo.com Tue Apr 24 11:28:26 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Apr 24 11:28:30 2007 Subject: [GRASS-dev] d.rast.edit: what does aspect do? Message-ID: <20070424212826.45b77a0a.hamish_nospam@yahoo.com> Hi, the new d.rast.edit (.tcl) is very nice, a huge improvement on the old. one question: what does the aspect map do? is it purely informative? Hamish From grass-bugs at intevation.de Tue Apr 24 11:46:57 2007 From: grass-bugs at intevation.de (Hamish Bowman via RT) Date: Tue Apr 24 11:46:59 2007 Subject: [GRASS-dev] [bug #4725] (grass) nviz crashed while volume visualisation Message-ID: <20070424094657.D2E1A1005D2@lists.intevation.de> NVIZ volume problem is not fixed. :( --latest 6.3 CVS-- G63> nviz vol=vox50 #loads ok (see bug report for generating vox50) # view height -> 75.0 Visualize -> Volumes Isosurface [Add] Segmentation fault :-( try again: G63> nviz vol=vox50 #loads ok Visualize -> Volumes Isosurface [Add] New Constant: 3000 # hey it took one! Isosurface [Add] New Constant: # here it doesn't let me enter anything in the text box [Cancel] New Constant: 2000 #now it gives me a cursor in the text box [Ok] invalid command name ".new_const.constant" invalid command name ".new_const.constant" while executing "$w.constant get" (procedure "create_constant_popup" line 27) invoked from within "create_constant_popup .new_const 1" (procedure "aip_show_newconst" line 5) invoked from within "aip_show_newconst threshold" invoked from within ".temporary_new_isosurf.f2.const invoke" ("uplevel" body line 1) invoked from within "uplevel #0 [list $w invoke]" (procedure "tkButtonUp" line 7) invoked from within "tkButtonUp .temporary_new_isosurf.f2.const " (command bound to event) # but it still adds the isosurface ok. # same thing for adding more isosurfaces at 1000,500,... 6.2: the bug remains- NVIZ with vol= given on the command line locks up with "Please wait..." window. Hamish -------------------------------------------- Managed by Request Tracker From mlennert at club.worldonline.be Tue Apr 24 11:55:29 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Tue Apr 24 11:52:11 2007 Subject: [GRASS-dev] numeric-numpy-scipy for graphs? In-Reply-To: <20070424182016.2f0c7a75.hamish_nospam@yahoo.com> References: <20070423181556.715a1b72.hamish_nospam@yahoo.com> <20070424182016.2f0c7a75.hamish_nospam@yahoo.com> Message-ID: <462DD411.1050303@club.worldonline.be> On 24/04/07 08:20, Hamish wrote: >>>> "wolle" wrote: >>>>> have a look at matplotlib http://matplotlib.sourceforge.net/ >>>>> It depends on numeric. >>> Michael wrote: >>>> Really impressive! > Hamish: >>> oh, and by the way, IMO translucency is the neat way to go for >>> bubble plots, not sorting by size before rendering and drawing the >>> little ones on top (can lead to coin toss overlap results; you lose >>> any order/time info in the data). >>> >>> e.g. study these two: >>> >>> http://matplotlib.sourceforge.net/screenshots/scatter_demo2_large.png >>> >>> and attached graphic (clipped from the NY Times online edition a few >>> days ago) which demonstrates it quite well. > Michael Barton wrote: >> I agree about the translucency. Looks nice AND is more informative. > > For the record, I don't mean to say that sorting isn't a nice short-term > solution, it is. Translucency is just a nicer long-term solution. I don't think I agree with this, unless order/time is an important element. For other uses, I still think that ordering is better as you don't lose the color information as you do in your example (see small circle behind large circle at -0.01,-0.01). So, I guess, as always, choice rules ;-) Moritz From hamish_nospam at yahoo.com Tue Apr 24 12:09:20 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Apr 24 12:09:32 2007 Subject: [GRASS-dev] gis.m crashes on zoom-out In-Reply-To: <17941.9472.210910.297736@cerise.gclements.plus.com> References: <20070405183030.438e5df3.hamish_nospam@yahoo.com> <17940.61460.168535.770304@cerise.gclements.plus.com> <20070406021849.3823fe38.hamish_nospam@yahoo.com> <17941.9472.210910.297736@cerise.gclements.plus.com> Message-ID: <20070424220920.4656ddeb.hamish_nospam@yahoo.com> > > > Hamish wrote: > > > > found a bug in gis.m zoom out tool. > > > > > > > > start gis.m, select zoom out, draw a box, and poof! gis.m > > > > crashes. > > > > > > > > happens always in a lat long location when you zoom out past > > > > 90NS 180EW view or a bit harder to trigger in spearfish, but > > > > crashes on the 4th or 5th zoom out when the rows*cols gets to be > > > > something silly like 500e6*500e6. > > > > > > > > presumably g.region exits with an error which isn't handled > > > > well. > > > > Glynn Clements wrote: > > > Yep. > > > > > > If you spawn a child process with "open |...", any errors are > > > reported by way of the corresponding "close" throwing an > > > exception. Tcl's definition of "error" includes anything being > > > written to stderr (so any warnings are treated as errors), as well > > > as a non-zero exit code. > > > > > > Any calls to "close" on a subprocess pipe should be enclosed in a > > > catch statement. > > > Hamish: > > gui/tcltk/gis.m$ grep close * | grep -v catch > > > > > > finds this one in georect.tcl > > proc GRMap::zoom_gregion { args} { > > > > and in histogram.tcl: > > proc GmHist::display { node mod } { > > > > and in rastnums.tcl: > > proc GmRnums::display { node mod } { > > > > and in runandoutput.tcl: > > proc guarantee_xmon {} { > > > > > > ..maybe more? > > > > I don't see the open|g.region in mapcanvas.tcl which triggers this > > bug? > > Glynn: > Line 585, in Mapcanvas::runprograms: > > if {[catch {close $input} error]} { > puts $error > exit 1 > } > > It catches the error, then prints the error message and exits. Not > really much point in catching it. So what would the soltution look like? Would the above catch+puts+exit in the histogram or georect tool only bring down those tools and not all of gis.m as they do now? histogram.tcl and rastnums.tcl probably need a catch on the open as well? tcl is mostly beyond me, so I can't really do much to fix these... Hamish From woklist at kyngchaos.com Tue Apr 24 16:18:59 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Tue Apr 24 16:19:17 2007 Subject: [GRASS-dev] Re: [GRASSGUI] another idea for font setting In-Reply-To: References: Message-ID: <384D9EDF-36EB-4EB8-911D-2E0085FFDCEC@kyngchaos.com> This should be able to handle subfolders. While the system folders are normally flat, when 3rd-party font activation tools are used, it's common to organize extra fonts into subfolders. On the down side of letting the user specify font folders external to the system folders, there can be multiple versions of a font, though only one may be active at a time. It could get confusing choosing a font. On Apr 24, 2007, at 12:23 AM, Michael Barton wrote: > How about a GRASS_FONTPATH variable set in init.sh (or an > environmental variable if that?s better). It could work like some > of the other such path variables. > > Check to see if it?s already set (e.g., in .grassrc6 or .profile). > If it?s not already set, try some default settings: /Library/Fonts > for Darwin systems, a ?normal? linux font place, a ?normal? windows > font place. > > A font setting dialog could get this path from the variable and > insert it into a font path browse control. For many people, they > would not need to do anything but pick from the list of fonts in > that directory. But the control would still allow a user to browse > for another locality if their fonts were in a different place. This > gives some degree of convenience for the many people who have fonts > in a standard location for their platform and provides 2 ways to > deal with those who don?t?in a configuration file (for GRASS or > shell) or by browsing to the font location. > > Trying to find a way to make this a bit easier for many, while > dealing with the considerable variability across systems. > ----- William Kyngesburye http://www.kyngchaos.com/ "I ache, therefore I am. Or in my case - I am, therefore I ache." - Marvin From michael.barton at asu.edu Tue Apr 24 16:30:54 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Apr 24 16:31:00 2007 Subject: [GRASS-dev] d.vect.chart legends In-Reply-To: <20070424195658.25cc8f77.hamish_nospam@yahoo.com> Message-ID: Good idea. I'd recommend an option for this however. d.legend map=- data=[file]/[string] Smooth FP legends would be useful with non-thematic vector maps with many objects and potential values--points representing K values for soils Michael On 4/24/07 12:56 AM, "Hamish" wrote: > d.legend idea: > > if data is fed from stdin (signaled by map=-) create categorical legend > using that data. Data format: "cat|label|color" > > e.g. > > d.legend -m map="-" < 1|Main Street|255:0:0 > 2|Elm Street|0:255:0 > 3|Old Coach Road|0:0:255 > EOF > > > in this way d.legend could work as a system module by the GUI instead of > a user module, but be useful for non-raster tasks. > > question/future: allow smooth FP legends from stdin data for use with > thematic vectors or stick with categorical legends? __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Tue Apr 24 16:39:43 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Apr 24 16:40:08 2007 Subject: [GRASS-dev] Re: numeric-numpy-scipy for graphs? In-Reply-To: <17965.50222.388721.599370@cerise.gclements.plus.com> Message-ID: On 4/24/07 1:47 AM, "Glynn Clements" wrote: > Not unless you're planning on using the BMP format (which means > eliminating g.pnmcomp); it doesn't work with other formats. OK. I missed the BMP part. > > [Essentially, the image format needs store the actual image data as > raw 32-bit pixels, which rules out both PNG and PPM/PGM. 32-bpp BMP is > just that: a 54-byte header followed by raw 32-bit pixels. TGA and PAM > might also be viable.] > > On that subject, you really should look into eliminating g.pnmcomp. > AFAICT, wxWidgets doesn't feature blending (although it should be able > to do compositing with binary mask), but you may be able to use e.g. > PIL for that. Performing compositing internally would save on I/O when > enabling, disabling and re-ordering existing layers. We're already doing internal compositing with the barscale/legend overlays, using PseudoDC's. And I think that it is pretty easy to draw with a transparent background with other DC's. I also see several ways to get translucency in the demo. would mean reworking the rendering engine, but probably worth it in the end. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Tue Apr 24 17:01:04 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Apr 24 17:01:10 2007 Subject: [GRASS-dev] thinking about font variables Message-ID: After sleeping on it, I?d like to propose 2 new kinds of font variables for GRASS. GRASS_FONTPATH would be an environmental variable like GRASS_PROJSHARE. It is a convenience to help users get to their fonts easily without a lot of browsing around. Like GRASS_PROJSHARE, this could be set manually (e.g., in a user?s .profile) or Init.sh will make some reasonable guesses as to a logical path on each platform (e.g., /Library/Fonts on a Mac OS X). It could be used from the command line or in the GUI to get to the font directory for easy font selection?e.g., the default font path shown in the autogenerated dialog for d.text could be initially set to $GRASS_FONTPATH. GRASS_DEFAULTFONT would be a GRASS environmental variable, optionally set in .grassrc6. It would take any value accepted by d.font. The purpose of this variable would be to allow for a default font to be set by the user and persist from session to session. If GRASS_DEFAULTFONT is not set, GRASS would simply default to it current stroke font setting. Explicitly setting d.font or specifying a font in something like d.text would temporarily override GRASS_DEFAULTFONT. I can see how I can use it in the rendering part of the GUI to use this font for every rendering operation. It would be nice, however, if this could be used automatically for any display command that renders fonts (e.g., d.legend). Implementing this in the GUI is fairly trivial. I don?t know what kind of work would be needed to make d.* commands automatically respect GRASS_DEFAULTFONT, however. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070424/28d5569b/attachment.html From michael.barton at asu.edu Tue Apr 24 17:03:15 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Apr 24 17:03:22 2007 Subject: [GRASS-dev] Re: [GRASSGUI] another idea for font setting In-Reply-To: <384D9EDF-36EB-4EB8-911D-2E0085FFDCEC@kyngchaos.com> Message-ID: As I just proposed, the idea of having a font path variable would be a convenience function to get a user in the general vicinity of fonts at least--or in exactly the right place if he/she knows where they want to look. I agree about the potential for confusion. But this would reduce (though I agree not eliminiate) it over the situation we have now. Michael On 4/24/07 7:18 AM, "William Kyngesburye" wrote: > This should be able to handle subfolders. While the system folders > are normally flat, when 3rd-party font activation tools are used, > it's common to organize extra fonts into subfolders. > > On the down side of letting the user specify font folders external to > the system folders, there can be multiple versions of a font, though > only one may be active at a time. It could get confusing choosing a > font. __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From tutey at o2.pl Tue Apr 24 17:45:10 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Tue Apr 24 17:45:20 2007 Subject: [GRASS-dev] clean the source [was: g.copy bug?] In-Reply-To: <200704241024.44377.wegmann@biozentrum.uni-wuerzburg.de> References: <200704231731.26396.wegmann@biozentrum.uni-wuerzburg.de> <20070423190846.GA8137@bartok.itc.it> <200704241024.44377.wegmann@biozentrum.uni-wuerzburg.de> Message-ID: <462E2606.6020006@o2.pl> Martin Wegmann wrote: > my script does: > > make clean > make distclean > cvs update -dP grass6 Being curious - doesn't "make distclean" alone suffice? Does'n it do all that "make clean" does and more? Maciek From dca.gis at gmail.com Tue Apr 24 17:45:24 2007 From: dca.gis at gmail.com (Daniel Calvelo) Date: Tue Apr 24 17:45:27 2007 Subject: [GRASS-dev] any way to know color assigned to a cell? In-Reply-To: <20070424182401.3672005f.hamish_nospam@yahoo.com> References: <17950.48109.88914.169521@cerise.gclements.plus.com> <20070422231950.6abc0ba8.hamish_nospam@yahoo.com> <1a486f560704222356u28911cdbs80fced279a384e6f@mail.gmail.com> <20070424182401.3672005f.hamish_nospam@yahoo.com> Message-ID: <1a486f560704240845x5464f2ccr5cd7b173d4832aca@mail.gmail.com> On 4/24/07, Hamish wrote: > > curious, is "wx color name" the same as X11 color names? (honeydew4 etc > as given in /usr/lib/X11/rgb.txt) or just basic red,green,blue,.. Neither, alas. I have no idea what is the rationale; the standard colors are hard-coded in the C++ source, in src/common/gdicmn.cpp. They are: aquamarine, black, blue, blue violet, brown, cadet blue, coral, cornflower blue, cyan, dark grey, dark green, dark olive green, dark orchid, dark slate blue, dark slate grey, dark turquoise, dim grey, firebrick, forest green, gold, goldenrod, grey, green, green yellow, indian red, khaki, light blue, light grey, light steel blue, lime green, magenta, maroon, medium aquamarine, medium blue, medium forest green, medium goldenrod, medium orchid, medium sea green, medium slate blue, medium spring green, medium turquoise, medium violet red, midnight blue, navy, orange, orange red, orchid, pale green, pink, plum, purple, red, salmon, sea green, sienna, sky blue, slate blue, spring green, steel blue, tan, thistle, turquoise, violet, violet red, wheat, white, yellow, yellow green Daniel. -- -- Daniel Calvelo Aros From grass-codei at wald.intevation.org Tue Apr 24 19:03:35 2007 From: grass-codei at wald.intevation.org (grass-codei@wald.intevation.org) Date: Tue Apr 24 19:03:41 2007 Subject: [GRASS-dev] [grass-code I][379] r.in.wms incorrect flag Message-ID: <20070424170335.4C68E1973FBB@pyrosoma.intevation.org> code I item #379, was opened at 2007-04-24 19:03 Status: Open Priority: 3 Submitted By: Agustin Diez Castillo (dieza) Assigned to: Nobody (None) Summary: r.in.wms incorrect flag Issue type: module bug Issue status: None GRASS version: CVS HEAD GRASS component: None Operating system: MacOS X Operating system version: 10.4.9 GRASS CVS checkout date, if applies (YYMMDD): 070422 Initial Comment: WARNING: xml2 NOT avaliable sed: sed: 1: "s//LAYER:/i ": bad flag in substitute command: 'i' 1: "s/\s*\(\w*\)/~\1~ ...": bad flag in substitute command: 'i' sed: 1: "s/<\/Name>\n//ig ": bad flag in substitute command: 'i'sed: 1: "s/<\/Layer.*>//i ": bad flag in substitute command: 'i' sed: 1: "s/<\/*.*\/*\/*>//i ": bad flag in substitute command: 'i' sed: 1: "s/<\/Title>//i ": bad flag in substitute command: 'i' sed: 1: "s/