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-9