From tim at linfiniti.com Mon Jan 1 04:45:49 2007 From: tim at linfiniti.com (Tim Sutton) Date: Mon Jan 1 04:45:51 2007 Subject: [GRASS-dev] Windows native GRASS build Message-ID: Happy new year all! For those of you following the GRASS on windows efforts with QGIS, I have now got GRASS building with all but about 20 modules under msys/windows. I havent compiled in postgresql support yet.. GRASS attribute viewing and man page viewing are now working under windows qgis for me. There are two small issues remaining that I noticed (and maybe more that others will notice): 1) Every time a layer is added a black console box temporarily appears and then disappears. 2) When clicking on a tool inthe GRASS toolbox, I get a message like: "Warning: cannot find key output" 3) Are any of the unbuilt modules listed below particularly vital to have in the QGIS 0.8 binary installer for windows? I will upload a binary for testing tonight or tomorrow. I compiled with the following options: ./configure --build=i686-pc-mingw32 \ --with-jpeg-libs=/bin \ --with-libs=/local/lib/ \ --with-png-libs=/bin \ --with-fftw-libs=/local/lib \ --with-fftw-includes=/local/include \ --with-includes=/local/include \ --with-includes=/include \ --with-tcltk=no \ --with-postgres=no \ --with-opengl=no And the end of make report looks like this: ---------------------------------------------------------------------- GRASS GIS compilation log ------------------------- Started compilation: Sun Dec 31 20:15:24 CST 2006 -- Errors in: /src/grass6/display/drivers/PNG /src/grass6/imagery/i.class /src/grass6/imagery/i.ortho.photo/photo.2image /src/grass6/imagery/i.ortho.photo/photo.2target /src/grass6/imagery/i.points /src/grass6/imagery/i.vpoints /src/grass6/raster/r.li/r.li.daemon /src/grass6/raster/r.li/r.li.edgedensity /src/grass6/raster/r.li/r.li.patchdensity /src/grass6/raster/r.li/r.li.patchnumber /src/grass6/raster/r.li/r.li.shape /src/grass6/raster/r.li/r.li.simpson /src/grass6/raster/r.li/r.li.shannon /src/grass6/raster/r.li/r.li.meanPatchSize /src/grass6/raster/r.li/r.li.meanPixelAttribute /src/grass6/raster/r.li/r.li.patchAreaDistributionCV /src/grass6/raster/r.li/r.li.patchAreaDistributionSD /src/grass6/raster/r.li/r.li.patchAreaDistributionRANGE /src/grass6/raster/r.li/r.li.contrastWeightedEdgeDensity /src/grass6/raster/r.li/r.li.richness /src/grass6/raster/r.li/r.li.dominance -- Finished compilation: Sun Dec 31 20:47:48 CST 2006 (In case of errors please change into the directory with error and run 'make') make: *** [default] Error 1 -- -- Tim Sutton Visit http://qgis.org for a great Open Source GIS Home Page: http://linfiniti.com Skype: timlinux MSN: tim_bdworld@msn.com Yahoo: tim_bdworld@yahoo.com Jabber: timlinux Irc: timlinux on #qgis at freenode.net From radim.blazek at gmail.com Mon Jan 1 13:47:53 2007 From: radim.blazek at gmail.com (Radim Blazek) Date: Mon Jan 1 13:47:56 2007 Subject: [GRASS-dev] Re: [Qgis-developer] Windows native GRASS build In-Reply-To: References: Message-ID: <340505ef0701010447s39a3912fy439fbb8274fba804@mail.gmail.com> On 1/1/07, Tim Sutton wrote: > Happy new year all! > > For those of you following the GRASS on windows efforts with QGIS, I > have now got GRASS building with all but about 20 modules under > msys/windows. I havent compiled in postgresql support yet.. GRASS > attribute viewing and man page viewing are now working under windows > qgis for me. There are two small issues remaining that I noticed (and > maybe more that others will notice): > > 1) Every time a layer is added a black console box temporarily appears > and then disappears. It is known problem, db driver is exe and when it is started by spawnl() it opens Windows console for a while. I am not Win expert and I dont know how to avoid this. I have asked already in QGIS and GRASS devel lists. > 2) When clicking on a tool inthe GRASS toolbox, I get a message like: > "Warning: cannot find key output" Which module? > 3) Are any of the unbuilt modules listed below particularly vital to > have in the QGIS 0.8 binary installer for windows? > > I will upload a binary for testing tonight or tomorrow. > > I compiled with the following options: > > ./configure --build=i686-pc-mingw32 \ > --with-jpeg-libs=/bin \ > --with-libs=/local/lib/ \ > --with-png-libs=/bin \ > --with-fftw-libs=/local/lib \ > --with-fftw-includes=/local/include \ > --with-includes=/local/include \ > --with-includes=/include \ > --with-tcltk=no \ > --with-postgres=no \ Postgres is important IMO. > --with-opengl=no > > And the end of make report looks like this: > > ---------------------------------------------------------------------- > GRASS GIS compilation log > ------------------------- > Started compilation: Sun Dec 31 20:15:24 CST 2006 > -- > Errors in: > /src/grass6/display/drivers/PNG Not used. > /src/grass6/imagery/i.class > /src/grass6/imagery/i.ortho.photo/photo.2image > /src/grass6/imagery/i.ortho.photo/photo.2target > /src/grass6/imagery/i.points > /src/grass6/imagery/i.vpoints Some i.* modules which depend on GRASS monitor must be impemented in QGIS in future. No solution for now. > /src/grass6/raster/r.li/r.li.daemon > /src/grass6/raster/r.li/r.li.edgedensity > /src/grass6/raster/r.li/r.li.patchdensity > /src/grass6/raster/r.li/r.li.patchnumber > /src/grass6/raster/r.li/r.li.shape > /src/grass6/raster/r.li/r.li.simpson > /src/grass6/raster/r.li/r.li.shannon > /src/grass6/raster/r.li/r.li.meanPatchSize > /src/grass6/raster/r.li/r.li.meanPixelAttribute > /src/grass6/raster/r.li/r.li.patchAreaDistributionCV > /src/grass6/raster/r.li/r.li.patchAreaDistributionSD > /src/grass6/raster/r.li/r.li.patchAreaDistributionRANGE > /src/grass6/raster/r.li/r.li.contrastWeightedEdgeDensity > /src/grass6/raster/r.li/r.li.richness > /src/grass6/raster/r.li/r.li.dominance Not crucial. Radim > Finished compilation: Sun Dec 31 20:47:48 CST 2006 > (In case of errors please change into the directory with error and run 'make') > make: *** [default] Error 1 > > > > -- > -- > Tim Sutton > > Visit http://qgis.org for a great Open Source GIS > Home Page: http://linfiniti.com > Skype: timlinux > MSN: tim_bdworld@msn.com > Yahoo: tim_bdworld@yahoo.com > Jabber: timlinux > Irc: timlinux on #qgis at freenode.net > _______________________________________________ > Qgis-developer mailing list > Qgis-developer@lists.qgis.org > http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer > From tutey at o2.pl Mon Jan 1 18:28:34 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Mon Jan 1 18:28:40 2007 Subject: [GRASS-dev] gdal-grass plugin fails during ./configure with GRASS 6.3 CVS Message-ID: <459944C2.70201@o2.pl> Hi, With current GRASS 6.3 CVS gdal-grass 1.3.1.2 and 1.3.2 fail during configure: $ ./configure --with-grass=/usr/local/grass-6.3.cvs/ [...] checking for gdal-config... /usr/local/bin/gdal-config using /usr/local/lib/gdalplugins as GDAL shared library autoload directory checking for G_asprintf in -lgrass_gis... no configure: error: --with-grass=/usr/local/grass-6.3.cvs/ requested, but libraries not found! Perhaps you need to set LD_LIBRARY_PATH to include /usr/local/grass-6.3.cvs//lib? GRASS is installed /usr/local/grass-6.3.cvs/, the /usr/local/grass-6.3.cvs/lib is present in the /etc/ld.so.conf and I remembered to run ldconfig. Did something change in GRASS between 6.2 and 6.3, or in GDAL, that gdal-grass plugin won't build with GRASS 6.3? Both gdal-grass versions configure fine with GRASS 6.2.2 (CVS 23.12.2006). Using GDAL 1.4 CVS 25.12.2006. Any hints appreciated! Thanks. Maciek From tim at linfiniti.com Mon Jan 1 18:30:17 2007 From: tim at linfiniti.com (Tim Sutton) Date: Mon Jan 1 18:30:19 2007 Subject: [GRASS-dev] Re: [Qgis-developer] Windows native GRASS build In-Reply-To: <340505ef0701010447s39a3912fy439fbb8274fba804@mail.gmail.com> References: <340505ef0701010447s39a3912fy439fbb8274fba804@mail.gmail.com> Message-ID: Hi > > > 1) Every time a layer is added a black console box temporarily appears > > and then disappears. > > It is known problem, db driver is exe and when it is started by spawnl() > it opens Windows console for a while. I am not Win expert and I dont know > how to avoid this. I have asked already in QGIS and GRASS devel lists. Ok - I think its not a big problem for now. > > > 2) When clicking on a tool inthe GRASS toolbox, I get a message like: > > "Warning: cannot find key output" > > Which module? *every module* Any ideas what can be causing that? > > > 3) Are any of the unbuilt modules listed below particularly vital to > > have in the QGIS 0.8 binary installer for windows? > > Postgres is important IMO. > Yes I will work tonight on getting pg support compiled under msys. > > Not crucial. Ok I will ignore them for this release exercise. Regards Tim > > Radim > > > Finished compilation: Sun Dec 31 20:47:48 CST 2006 > > (In case of errors please change into the directory with error and run 'make') > > make: *** [default] Error 1 > > > > > > > > -- > > -- > > Tim Sutton > > > > Visit http://qgis.org for a great Open Source GIS > > Home Page: http://linfiniti.com > > Skype: timlinux > > MSN: tim_bdworld@msn.com > > Yahoo: tim_bdworld@yahoo.com > > Jabber: timlinux > > Irc: timlinux on #qgis at freenode.net > > _______________________________________________ > > Qgis-developer mailing list > > Qgis-developer@lists.qgis.org > > http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer > > > -- -- Tim Sutton Visit http://qgis.org for a great Open Source GIS Home Page: http://linfiniti.com Skype: timlinux MSN: tim_bdworld@msn.com Yahoo: tim_bdworld@yahoo.com Jabber: timlinux Irc: timlinux on #qgis at freenode.net From tutey at o2.pl Mon Jan 1 18:51:49 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Mon Jan 1 18:51:53 2007 Subject: [GRASS-dev] g.region print flags combination In-Reply-To: References: <22A5FE4C-7F65-4E87-A823-0900E5D414CF@unity.ncsu.edu> Message-ID: <45994A35.5070805@o2.pl> Hi Martin! Thanks for cleaning up g.region. Unfortunately, it seems that in the process you have accidently removed a feature - it is now impossible to use "g.region -g" alone anymore - one has to call it in combination with other flags now. Although your approach is good, currently it breaks some GRASS scripts using "g.region -g", eg. d.out.gpsdrive, r.plane, r.shaded.relief, r.tileset and unknown number of user scripts. I suggest to revert this change and leave it for GRASS 7. Regards and thanks. Maciek From paul-grass at stjohnspoint.co.uk Mon Jan 1 18:57:21 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Mon Jan 1 18:57:27 2007 Subject: [GRASS-dev] gdal-grass plugin fails during ./configure with GRASS 6.3 CVS In-Reply-To: <459944C2.70201@o2.pl> References: <459944C2.70201@o2.pl> Message-ID: You probably need to check config.log to see what the actual error is. But as a sidenote, in some circumstances G_asprintf is/was/will be implemented as a macro (replaced by a call to the system asprintf()) and not a function in libgrass_gis.so, so it is not a very good choice as a typical GRASS function to test for in the configure script. Perhaps G_gisinit() would be better, or some function that the GDAL GRASS plugin directly uses. Paul On Mon, 1 Jan 2007, Maciej Sieczka wrote: > Hi, > > With current GRASS 6.3 CVS gdal-grass 1.3.1.2 and 1.3.2 fail during > configure: > > $ ./configure --with-grass=/usr/local/grass-6.3.cvs/ > [...] > checking for gdal-config... /usr/local/bin/gdal-config > using /usr/local/lib/gdalplugins as GDAL shared library autoload directory > checking for G_asprintf in -lgrass_gis... no > configure: error: --with-grass=/usr/local/grass-6.3.cvs/ requested, but > libraries not found! Perhaps you need to set LD_LIBRARY_PATH to > include /usr/local/grass-6.3.cvs//lib? > > GRASS is installed /usr/local/grass-6.3.cvs/, the > /usr/local/grass-6.3.cvs/lib is present in the /etc/ld.so.conf and I > remembered to run ldconfig. > > Did something change in GRASS between 6.2 and 6.3, or in GDAL, that > gdal-grass plugin won't build with GRASS 6.3? Both gdal-grass versions > configure fine with GRASS 6.2.2 (CVS 23.12.2006). > > Using GDAL 1.4 CVS 25.12.2006. > > Any hints appreciated! > > Thanks. > > Maciek > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > From landa.martin at gmail.com Mon Jan 1 19:13:12 2007 From: landa.martin at gmail.com (Martin Landa) Date: Mon Jan 1 19:13:14 2007 Subject: [GRASS-dev] g.region print flags combination In-Reply-To: <45994A35.5070805@o2.pl> References: <22A5FE4C-7F65-4E87-A823-0900E5D414CF@unity.ncsu.edu> <45994A35.5070805@o2.pl> Message-ID: Hi Maciek, sorry, you are right. I will fix it as soon as possible. Regards, Martin 2007/1/1, Maciej Sieczka : > Hi Martin! > > Thanks for cleaning up g.region. Unfortunately, it seems that in the > process you have accidently removed a feature - it is now impossible to > use "g.region -g" alone anymore - one has to call it in combination > with other flags now. > > Although your approach is good, currently it breaks some GRASS scripts > using "g.region -g", eg. d.out.gpsdrive, r.plane, r.shaded.relief, > r.tileset and unknown number of user scripts. I suggest to revert this > change and leave it for GRASS 7. > > Regards and thanks. > > Maciek > > -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From tutey at o2.pl Mon Jan 1 19:33:34 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Mon Jan 1 19:33:39 2007 Subject: [GRASS-dev] gdal-grass plugin fails during ./configure with GRASS 6.3 CVS In-Reply-To: References: <459944C2.70201@o2.pl> Message-ID: <459953FE.4000801@o2.pl> Paul Kelly wrote: > You probably need to check config.log to see what the actual error is. Tried that but no enlightment. I'm attaching it if anybody would like to have a look. Cheers, Maciek -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log.bz2 Type: application/x-bzip Size: 3507 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070101/dd4c26cd/config.log.bin From paul-grass at stjohnspoint.co.uk Mon Jan 1 22:22:34 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Mon Jan 1 22:22:36 2007 Subject: [GRASS-dev] gdal-grass plugin fails during ./configure with GRASS 6.3 CVS In-Reply-To: <459953FE.4000801@o2.pl> References: <459944C2.70201@o2.pl> <459953FE.4000801@o2.pl> Message-ID: Hello Maciek On Mon, 1 Jan 2007, Maciej Sieczka wrote: > Paul Kelly wrote: >> You probably need to check config.log to see what the actual error is. > > Tried that but no enlightment. I'm attaching it if anybody would like > to have a look. Here is the relevant output: configure:2840: found /usr/local/bin/gdal-config configure:2853: result: /usr/local/bin/gdal-config configure:2912: result: using /usr/local/lib/gdalplugins as GDAL shared library autoload directory configure:2939: checking for G_asprintf in -lgrass_gis configure:2969: gcc -o conftest -O2 conftest.c -lgrass_gis -L/usr/local/grass -6.3.cvs/lib -lgrass_I -lgrass_vask -lgrass_gmath -lgrass_gis -lgrass_datetime - lgrass_gproj -lgrass_vect -lgrass_dbmibase -lgrass_dbmiclient -lgrass_dgl -lgras s_dig2 -lgrass_rtree -lgrass_linkm -L/usr/local/lib -lgdal >&5 /usr/local/lib/libgeos_c.so.1: undefined reference to `geos::WKBReader::read(std ::basic_istream >&)' /usr/local/lib/libgeos_c.so.1: undefined reference to `geos::WKBWriter::write(ge os::Geometry const&, std::basic_ostream >&)' /usr/local/lib/libgeos_c.so.1: undefined reference to `geos::Point::getCoordinat esRO() const' /usr/local/lib/libgeos_c.so.1: undefined reference to `geos::WKBWriter::WKBWrite r(int, int)' collect2: ld returned 1 exit status So the problem is something to do with geos. What has changed appears to be something to do with GDAL now depending on GEOS in some way? This e-mail from Glynn may be related: http://grass.itc.it/pipermail/grass-dev/2006-November/027546.html Hope this is some help. GDAL and Geos-related stuff has started coming up a bit in the last month or two so it looks like something is perhaps not right somewhere but I don't know what needs fixed exactly. Paul From stefan.paulick at urbeli.com Tue Jan 2 07:42:02 2007 From: stefan.paulick at urbeli.com (Paulick Consult) Date: Tue Jan 2 07:42:05 2007 Subject: [GRASS-dev] Re: GIS Manager and Map Display 1 faults on Ubuntu 6.06 In-Reply-To: <200612281057.26552.andreas.gros@biozentrum.uni-wuerzburg.de> References: <200612281057.26552.andreas.gros@biozentrum.uni-wuerzburg.de> Message-ID: <200701020642.l026g2BY074532@mail.bytecamp.net> > had the same problem with Ubuntu 6.06. Now that I installed 6.10 this problem > is gone. Haven't figured out what exactly the original problem was, though. Sorry Andreas, switching to 6.10 is no option, because we want to benefit from "LTS" I collected the latest CVS code, and now gis.m flashes the initial graphic and is gone. d.m works fine; distclean didn't change the behaviour. I get no error message, only the note: ... D3/5: region item: n-s resol3: 1 D3/5: region item: t-b resol: 1 D3/5: G_adjust_Cell_head: epsilon_ns: 2.77778e-07, epsilon_ew: 1e-06 D3/5: G_adjust_Cell_head: epsilon_ns: 2.77778e-07, epsilon_ew: 1e-06 GRASS 6.3.cvs (grassuser):/gd > Looks like not all fatal conditions are caught. --> Is there a way to monitor the script execution during startup? Mit freundlichen Gr??en / With kindest regards Stefan Paulick http://www.urbeli.com mailto://stefan.paulick@urbeli.com /*----------------------*/ From cavallini at faunalia.it Tue Jan 2 08:29:49 2007 From: cavallini at faunalia.it (Paolo Cavallini) Date: Tue Jan 2 08:29:53 2007 Subject: [GRASS-dev] Re: [Qgis-developer] Windows native GRASS build In-Reply-To: <340505ef0701010447s39a3912fy439fbb8274fba804@mail.gmail.com> References: <340505ef0701010447s39a3912fy439fbb8274fba804@mail.gmail.com> Message-ID: <459A09ED.7050904@faunalia.it> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Radim Blazek ha scritto: > On 1/1/07, Tim Sutton wrote: >> ./configure --build=i686-pc-mingw32 \ >> --with-jpeg-libs=/bin \ >> --with-libs=/local/lib/ \ >> --with-png-libs=/bin \ >> --with-fftw-libs=/local/lib \ >> --with-fftw-includes=/local/include \ >> --with-includes=/local/include \ >> --with-includes=/include \ >> --with-tcltk=no \ >> --with-postgres=no \ > > Postgres is important IMO. Very important for any serious use of grass. >> /src/grass6/raster/r.li/r.li.daemon >> /src/grass6/raster/r.li/r.li.edgedensity >> /src/grass6/raster/r.li/r.li.patchdensity >> /src/grass6/raster/r.li/r.li.patchnumber >> /src/grass6/raster/r.li/r.li.shape >> /src/grass6/raster/r.li/r.li.simpson >> /src/grass6/raster/r.li/r.li.shannon >> /src/grass6/raster/r.li/r.li.meanPatchSize >> /src/grass6/raster/r.li/r.li.meanPixelAttribute >> /src/grass6/raster/r.li/r.li.patchAreaDistributionCV >> /src/grass6/raster/r.li/r.li.patchAreaDistributionSD >> /src/grass6/raster/r.li/r.li.patchAreaDistributionRANGE >> /src/grass6/raster/r.li/r.li.contrastWeightedEdgeDensity >> /src/grass6/raster/r.li/r.li.richness >> /src/grass6/raster/r.li/r.li.dominance > > Not crucial. Agreed, but we would like to have it. Tim, could you please forward the errors to Serena Pallecchi, Davide Spano and Claudio Porta? Thanks. pc - -- Paolo Cavallini email+jabber: cavallini@faunalia.it www.faunalia.it Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFmgnt/NedwLUzIr4RAsAeAJ9wK/2CTtTv49B0EyJDx5N/CJHxngCcCcyI 5czwr8c64Luk4CvCXbwQOp4= =t+rs -----END PGP SIGNATURE----- From landa.martin at gmail.com Tue Jan 2 12:15:13 2007 From: landa.martin at gmail.com (Martin Landa) Date: Tue Jan 2 12:15:14 2007 Subject: [GRASS-dev] g.region print flags combination In-Reply-To: References: <22A5FE4C-7F65-4E87-A823-0900E5D414CF@unity.ncsu.edu> <45994A35.5070805@o2.pl> Message-ID: Hi, I hope, now it is fixed in CVS. Martin 2007/1/1, Martin Landa : > Hi Maciek, > > sorry, you are right. I will fix it as soon as possible. > > Regards, Martin > > 2007/1/1, Maciej Sieczka : > > Hi Martin! > > > > Thanks for cleaning up g.region. Unfortunately, it seems that in the > > process you have accidently removed a feature - it is now impossible to > > use "g.region -g" alone anymore - one has to call it in combination > > with other flags now. > > > > Although your approach is good, currently it breaks some GRASS scripts > > using "g.region -g", eg. d.out.gpsdrive, r.plane, r.shaded.relief, > > r.tileset and unknown number of user scripts. I suggest to revert this > > change and leave it for GRASS 7. > > > > Regards and thanks. > > > > Maciek > > > > > > > -- > Martin Landa * http://gama.fsv.cvut.cz/~landa * > -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From paul-grass at stjohnspoint.co.uk Tue Jan 2 12:33:39 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Tue Jan 2 12:33:51 2007 Subject: [GRASS-dev] Re: [Qgis-developer] Windows native GRASS build In-Reply-To: <459A09ED.7050904@faunalia.it> References: <340505ef0701010447s39a3912fy439fbb8274fba804@mail.gmail.com> <459A09ED.7050904@faunalia.it> Message-ID: Hello Paolo On Tue, 2 Jan 2007, Paolo Cavallini wrote: [...] >>> /src/grass6/raster/r.li/r.li.daemon >>> /src/grass6/raster/r.li/r.li.edgedensity >>> /src/grass6/raster/r.li/r.li.patchdensity >>> /src/grass6/raster/r.li/r.li.patchnumber >>> /src/grass6/raster/r.li/r.li.shape >>> /src/grass6/raster/r.li/r.li.simpson >>> /src/grass6/raster/r.li/r.li.shannon >>> /src/grass6/raster/r.li/r.li.meanPatchSize >>> /src/grass6/raster/r.li/r.li.meanPixelAttribute >>> /src/grass6/raster/r.li/r.li.patchAreaDistributionCV >>> /src/grass6/raster/r.li/r.li.patchAreaDistributionSD >>> /src/grass6/raster/r.li/r.li.patchAreaDistributionRANGE >>> /src/grass6/raster/r.li/r.li.contrastWeightedEdgeDensity >>> /src/grass6/raster/r.li/r.li.richness >>> /src/grass6/raster/r.li/r.li.dominance >> >> Not crucial. > > Agreed, but we would like to have it. Tim, could you please forward the > errors to Serena Pallecchi, Davide Spano and Claudio Porta? Please see attached. Main problems as far as I can see: - Use of FIFOs? AIUI Windows doesn't have FIFOs so that won't work. - Also I don't think fork() is available on Windows either - Glynn may be able to advise. Paul -------------- next part -------------- ../../include/Make/Html.make:32: warning: overriding commands for target `htmlgen' ../../include/Make/Html.make:32: warning: ignoring old commands for target `htmlgen' ../../include/Make/Html.make:101: warning: overriding commands for target `htmlcmd1' ../../include/Make/Html.make:101: warning: ignoring old commands for target `htmlcmd1' ../../include/Make/Html.make:107: warning: overriding commands for target `htmlscript1' ../../include/Make/Html.make:107: warning: ignoring old commands for target `htmlscript1' ../../include/Make/Html.make:117: warning: overriding commands for target `htmletc1' ../../include/Make/Html.make:117: warning: ignoring old commands for target `htmletc1' ../../include/Make/Html.make:123: warning: overriding commands for target `htmldir1' ../../include/Make/Html.make:123: warning: ignoring old commands for target `htmldir1' ../../include/Make/Html.make:128: warning: overriding commands for target `htmlmulti' ../../include/Make/Html.make:128: warning: ignoring old commands for target `htmlmulti' r.li.daemon make[1]: Entering directory `/c/grass/grass6/raster/r.li/r.li.daemon' gcc -shared -o /c/grass/grass6/dist.i686-pc-mingw32/lib/liblibr_li.6.3.cvs.dll -L/c/grass/grass6/dist.i686-pc-mingw32/lib -Wl,--export-dynamic,--enable-runtime-pseudo-reloc -L/c/grass/forgrass/lib OBJ.i686-pc-mingw32/daemon.o OBJ.i686-pc-mingw32/list.o OBJ.i686-pc-mingw32/ipc.o OBJ.i686-pc-mingw32/worker.o OBJ.i686-pc-mingw32/GenericCell.o OBJ.i686-pc-mingw32/avl.o OBJ.i686-pc-mingw32/avlID.o -lgrass_gis -lgrass_datetime -lxdr -liberty -lws2_32 -lz && \ (cd /c/grass/grass6/dist.i686-pc-mingw32/lib; ln -f -s liblibr_li.6.3.cvs.dll /c/grass/grass6/dist.i686-pc-mingw32/lib/liblibr_li.dll) OBJ.i686-pc-mingw32/daemon.o(.text+0x18c9): In function `calculateIndex': c:/grass/grass6/raster/r.li/r.li.daemon/daemon.c:57: undefined reference to `mkfifo' OBJ.i686-pc-mingw32/daemon.o(.text+0x18e2):c:/grass/grass6/raster/r.li/r.li.daemon/daemon.c:72: undefined reference to `fork' OBJ.i686-pc-mingw32/daemon.o(.text+0x194b):c:/grass/grass6/raster/r.li/r.li.daemon/daemon.c:70: undefined reference to `mkfifo' OBJ.i686-pc-mingw32/daemon.o(.text+0x195f):c:/grass/grass6/raster/r.li/r.li.daemon/daemon.c:72: undefined reference to `fork' OBJ.i686-pc-mingw32/daemon.o(.text+0x1d9c):c:/grass/grass6/raster/r.li/r.li.daemon/daemon.c:219: undefined reference to `wait' OBJ.i686-pc-mingw32/daemon.o(.text+0x1daa):c:/grass/grass6/raster/r.li/r.li.daemon/daemon.c:220: undefined reference to `WIFEXITED' OBJ.i686-pc-mingw32/daemon.o(.text+0x1ec5):c:/grass/grass6/raster/r.li/r.li.daemon/daemon.c:239: undefined reference to `wait' OBJ.i686-pc-mingw32/daemon.o(.text+0x1ed3):c:/grass/grass6/raster/r.li/r.li.daemon/daemon.c:240: undefined reference to `WIFEXITED' collect2: ld returned 1 exit status make[1]: *** [/c/grass/grass6/dist.i686-pc-mingw32/lib/liblibr_li.6.3.cvs.dll] Error 1 make[1]: Leaving directory `/c/grass/grass6/raster/r.li/r.li.daemon' r.li.edgedensity make[1]: Entering directory `/c/grass/grass6/raster/r.li/r.li.edgedensity' gcc -L/c/grass/grass6/dist.i686-pc-mingw32/lib -Wl,--export-dynamic,--enable-runtime-pseudo-reloc -L/c/grass/forgrass/lib -DPACKAGE=\""grassmods"\" -o /c/grass/grass6/dist.i686-pc-mingw32/bin/r.li.edgedensity.exe OBJ.i686-pc-mingw32/edgedensity.o /c/grass/grass6/lib/gis/OBJ.i686-pc-mingw32/fmode.o -lgrass_gis -lgrass_datetime -lxdr -liberty -lws2_32 -lz -llibr_li -lxdr -liberty -lws2_32 -lz c:\mingw\bin\..\lib\gcc\mingw32\3.4.2\..\..\..\..\mingw32\bin\ld.exe: cannot find -llibr_li collect2: ld returned 1 exit status make[1]: *** [/c/grass/grass6/dist.i686-pc-mingw32/bin/r.li.edgedensity.exe] Error 1 make[1]: Leaving directory `/c/grass/grass6/raster/r.li/r.li.edgedensity' r.li.patchdensity make[1]: Entering directory `/c/grass/grass6/raster/r.li/r.li.patchdensity' gcc -L/c/grass/grass6/dist.i686-pc-mingw32/lib -Wl,--export-dynamic,--enable-runtime-pseudo-reloc -L/c/grass/forgrass/lib -DPACKAGE=\""grassmods"\" -o /c/grass/grass6/dist.i686-pc-mingw32/bin/r.li.patchdensity.exe OBJ.i686-pc-mingw32/main.o /c/grass/grass6/lib/gis/OBJ.i686-pc-mingw32/fmode.o -lgrass_gis -lgrass_datetime -lxdr -liberty -lws2_32 -lz -llibr_li -lxdr -liberty -lws2_32 -lz c:\mingw\bin\..\lib\gcc\mingw32\3.4.2\..\..\..\..\mingw32\bin\ld.exe: cannot find -llibr_li collect2: ld returned 1 exit status make[1]: *** [/c/grass/grass6/dist.i686-pc-mingw32/bin/r.li.patchdensity.exe] Error 1 make[1]: Leaving directory `/c/grass/grass6/raster/r.li/r.li.patchdensity' r.li.patchnumber make[1]: Entering directory `/c/grass/grass6/raster/r.li/r.li.patchnumber' gcc -L/c/grass/grass6/dist.i686-pc-mingw32/lib -Wl,--export-dynamic,--enable-runtime-pseudo-reloc -L/c/grass/forgrass/lib -DPACKAGE=\""grassmods"\" -o /c/grass/grass6/dist.i686-pc-mingw32/bin/r.li.patchnumber.exe OBJ.i686-pc-mingw32/main.o /c/grass/grass6/lib/gis/OBJ.i686-pc-mingw32/fmode.o -lgrass_gis -lgrass_datetime -lxdr -liberty -lws2_32 -lz -llibr_li -lxdr -liberty -lws2_32 -lz c:\mingw\bin\..\lib\gcc\mingw32\3.4.2\..\..\..\..\mingw32\bin\ld.exe: cannot find -llibr_li collect2: ld returned 1 exit status make[1]: *** [/c/grass/grass6/dist.i686-pc-mingw32/bin/r.li.patchnumber.exe] Error 1 make[1]: Leaving directory `/c/grass/grass6/raster/r.li/r.li.patchnumber' r.li.setup make[1]: Entering directory `/c/grass/grass6/raster/r.li/r.li.setup' GISRC=c:/grass/grass6/dist.i686-pc-mingw32/demolocation/.grassrc63 GISBASE=c:/grass/grass6/dist.i686-pc-mingw32 PATH="/c/grass/grass6/dist.i686-pc-mingw32/bin:$PATH" PATH="/c/grass/grass6/dist.i686-pc-mingw32/bin:/c/grass/grass6/dist.i686-pc-mingw32/lib:.:/bin:/mingw/bin:/mingw/lib:/c/grass/forgrass/bin:/c/grass/forgrass/lib:/c/tcl/bin:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:/c/Program Files/QuickTime/QTSystem/:/c/grass/forgrass/bin:/c/grass/forgrass/lib:/c/tcl/bin:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:/c/Program Files/QuickTime/QTSystem/:/c/jed09916/bin" LC_ALL=C /c/grass/grass6/dist.i686-pc-mingw32/scripts/r.li.setup --html-description | grep -v '\|' > r.li.setup.tmp.html ; true mkdir -p /c/grass/grass6/dist.i686-pc-mingw32/docs/html mv -f r.li.setup.tmp.html /c/grass/grass6/dist.i686-pc-mingw32/docs/html/r.li.setup.html for file in *.png *.jpg ; do \ head -n 1 $file | grep '^#!' > /dev/null ; \ if [ $? -ne 0 ] ; then \ /bin/install -c -m 644 $file /c/grass/grass6/dist.i686-pc-mingw32/docs/html ; \ fi \ done 2> /dev/null ; true GISRC=c:/grass/grass6/dist.i686-pc-mingw32/demolocation/.grassrc63 GISBASE=c:/grass/grass6/dist.i686-pc-mingw32 PATH=/c/grass/grass6/dist.i686-pc-mingw32/bin:$PATH PATH="/c/grass/grass6/dist.i686-pc-mingw32/lib:.:/bin:/mingw/bin:/mingw/lib:/c/grass/forgrass/bin:/c/grass/forgrass/lib:/c/tcl/bin:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:/c/Program Files/QuickTime/QTSystem/:/c/grass/forgrass/bin:/c/grass/forgrass/lib:/c/tcl/bin:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:/c/Program Files/QuickTime/QTSystem/:/c/jed09916/bin" g.parser -t r.li.setup | sed s/\"/\\\\\"/g | sed 's/.*/_("&")/' > ../../../locale/scriptstrings/r.li.setup_to_translate.c ; true mkdir -p /c/grass/grass6/dist.i686-pc-mingw32/etc/r.li.setup /bin/install -c -m 755 ./area_query /c/grass/grass6/dist.i686-pc-mingw32/etc/r.li.setup/area_query /bin/install -c -m 755 ./masked_area_selection /c/grass/grass6/dist.i686-pc-mingw32/etc/r.li.setup/masked_area_selection /bin/install -c -m 755 ./r.li.setup.main /c/grass/grass6/dist.i686-pc-mingw32/etc/r.li.setup/r.li.setup.main /bin/install -c -m 755 ./r.li.setup.procedures.tcl /c/grass/grass6/dist.i686-pc-mingw32/etc/r.li.setup/r.li.setup.procedures.tcl /bin/install -c -m 755 ./r.li.windows.tcl /c/grass/grass6/dist.i686-pc-mingw32/etc/r.li.setup/r.li.windows.tcl /bin/install -c -m 755 ./sample_area_vector.sh /c/grass/grass6/dist.i686-pc-mingw32/etc/r.li.setup/sample_area_vector.sh /bin/install -c -m 755 ./square_mouse_selection.sh /c/grass/grass6/dist.i686-pc-mingw32/etc/r.li.setup/square_mouse_selection.sh /bin/install -c -m 755 ./square_query /c/grass/grass6/dist.i686-pc-mingw32/etc/r.li.setup/square_query /bin/install -c -m 644 ./circle.txt /c/grass/grass6/dist.i686-pc-mingw32/etc/r.li.setup/circle.txt /bin/install -c -m 644 ./polygon.txt /c/grass/grass6/dist.i686-pc-mingw32/etc/r.li.setup/polygon.txt make[1]: Leaving directory `/c/grass/grass6/raster/r.li/r.li.setup' r.li.shape make[1]: Entering directory `/c/grass/grass6/raster/r.li/r.li.shape' gcc -L/c/grass/grass6/dist.i686-pc-mingw32/lib -Wl,--export-dynamic,--enable-runtime-pseudo-reloc -L/c/grass/forgrass/lib -DPACKAGE=\""grassmods"\" -o /c/grass/grass6/dist.i686-pc-mingw32/bin/r.li.shape.exe OBJ.i686-pc-mingw32/main.o /c/grass/grass6/lib/gis/OBJ.i686-pc-mingw32/fmode.o -lgrass_gis -lgrass_datetime -lxdr -liberty -lws2_32 -lz -llibr_li -lxdr -liberty -lws2_32 -lz c:\mingw\bin\..\lib\gcc\mingw32\3.4.2\..\..\..\..\mingw32\bin\ld.exe: cannot find -llibr_li collect2: ld returned 1 exit status make[1]: *** [/c/grass/grass6/dist.i686-pc-mingw32/bin/r.li.shape.exe] Error 1 make[1]: Leaving directory `/c/grass/grass6/raster/r.li/r.li.shape' r.li.simpson make[1]: Entering directory `/c/grass/grass6/raster/r.li/r.li.simpson' gcc -L/c/grass/grass6/dist.i686-pc-mingw32/lib -Wl,--export-dynamic,--enable-runtime-pseudo-reloc -L/c/grass/forgrass/lib -DPACKAGE=\""grassmods"\" -o /c/grass/grass6/dist.i686-pc-mingw32/bin/r.li.simpson.exe OBJ.i686-pc-mingw32/simpson.o /c/grass/grass6/lib/gis/OBJ.i686-pc-mingw32/fmode.o -lgrass_gis -lgrass_datetime -lxdr -liberty -lws2_32 -lz -llibr_li -lxdr -liberty -lws2_32 -lz c:\mingw\bin\..\lib\gcc\mingw32\3.4.2\..\..\..\..\mingw32\bin\ld.exe: cannot find -llibr_li collect2: ld returned 1 exit status make[1]: *** [/c/grass/grass6/dist.i686-pc-mingw32/bin/r.li.simpson.exe] Error 1 make[1]: Leaving directory `/c/grass/grass6/raster/r.li/r.li.simpson' r.li.shannon make[1]: Entering directory `/c/grass/grass6/raster/r.li/r.li.shannon' gcc -L/c/grass/grass6/dist.i686-pc-mingw32/lib -Wl,--export-dynamic,--enable-runtime-pseudo-reloc -L/c/grass/forgrass/lib -DPACKAGE=\""grassmods"\" -o /c/grass/grass6/dist.i686-pc-mingw32/bin/r.li.shannon.exe OBJ.i686-pc-mingw32/shannon.o /c/grass/grass6/lib/gis/OBJ.i686-pc-mingw32/fmode.o -lgrass_gis -lgrass_datetime -lxdr -liberty -lws2_32 -lz -llibr_li -lxdr -liberty -lws2_32 -lz c:\mingw\bin\..\lib\gcc\mingw32\3.4.2\..\..\..\..\mingw32\bin\ld.exe: cannot find -llibr_li collect2: ld returned 1 exit status make[1]: *** [/c/grass/grass6/dist.i686-pc-mingw32/bin/r.li.shannon.exe] Error 1 make[1]: Leaving directory `/c/grass/grass6/raster/r.li/r.li.shannon' r.li.meanPatchSize make[1]: Entering directory `/c/grass/grass6/raster/r.li/r.li.meanPatchSize' gcc -L/c/grass/grass6/dist.i686-pc-mingw32/lib -Wl,--export-dynamic,--enable-runtime-pseudo-reloc -L/c/grass/forgrass/lib -DPACKAGE=\""grassmods"\" -o /c/grass/grass6/dist.i686-pc-mingw32/bin/r.li.meanPatchSize.exe OBJ.i686-pc-mingw32/meanPatchSize.o /c/grass/grass6/lib/gis/OBJ.i686-pc-mingw32/fmode.o -lgrass_gis -lgrass_datetime -lxdr -liberty -lws2_32 -lz -llibr_li -lxdr -liberty -lws2_32 -lz c:\mingw\bin\..\lib\gcc\mingw32\3.4.2\..\..\..\..\mingw32\bin\ld.exe: cannot find -llibr_li collect2: ld returned 1 exit status make[1]: *** [/c/grass/grass6/dist.i686-pc-mingw32/bin/r.li.meanPatchSize.exe] Error 1 make[1]: Leaving directory `/c/grass/grass6/raster/r.li/r.li.meanPatchSize' r.li.meanPixelAttribute make[1]: Entering directory `/c/grass/grass6/raster/r.li/r.li.meanPixelAttribute' gcc -L/c/grass/grass6/dist.i686-pc-mingw32/lib -Wl,--export-dynamic,--enable-runtime-pseudo-reloc -L/c/grass/forgrass/lib -DPACKAGE=\""grassmods"\" -o /c/grass/grass6/dist.i686-pc-mingw32/bin/r.li.meanPixelAttribute.exe OBJ.i686-pc-mingw32/meanPixelAttribute.o /c/grass/grass6/lib/gis/OBJ.i686-pc-mingw32/fmode.o -lgrass_gis -lgrass_datetime -lxdr -liberty -lws2_32 -lz -llibr_li -lxdr -liberty -lws2_32 -lz c:\mingw\bin\..\lib\gcc\mingw32\3.4.2\..\..\..\..\mingw32\bin\ld.exe: cannot find -llibr_li collect2: ld returned 1 exit status make[1]: *** [/c/grass/grass6/dist.i686-pc-mingw32/bin/r.li.meanPixelAttribute.exe] Error 1 make[1]: Leaving directory `/c/grass/grass6/raster/r.li/r.li.meanPixelAttribute' r.li.patchAreaDistributionCV make[1]: Entering directory `/c/grass/grass6/raster/r.li/r.li.patchAreaDistributionCV' gcc -L/c/grass/grass6/dist.i686-pc-mingw32/lib -Wl,--export-dynamic,--enable-runtime-pseudo-reloc -L/c/grass/forgrass/lib -DPACKAGE=\""grassmods"\" -o /c/grass/grass6/dist.i686-pc-mingw32/bin/r.li.patchAreaDistributionCV.exe OBJ.i686-pc-mingw32/patchAreaDistributionCV.o /c/grass/grass6/lib/gis/OBJ.i686-pc-mingw32/fmode.o -lgrass_gis -lgrass_datetime -lxdr -liberty -lws2_32 -lz -llibr_li -lxdr -liberty -lws2_32 -lz c:\mingw\bin\..\lib\gcc\mingw32\3.4.2\..\..\..\..\mingw32\bin\ld.exe: cannot find -llibr_li collect2: ld returned 1 exit status make[1]: *** [/c/grass/grass6/dist.i686-pc-mingw32/bin/r.li.patchAreaDistributionCV.exe] Error 1 make[1]: Leaving directory `/c/grass/grass6/raster/r.li/r.li.patchAreaDistributionCV' r.li.patchAreaDistributionSD make[1]: Entering directory `/c/grass/grass6/raster/r.li/r.li.patchAreaDistributionSD' gcc -L/c/grass/grass6/dist.i686-pc-mingw32/lib -Wl,--export-dynamic,--enable-runtime-pseudo-reloc -L/c/grass/forgrass/lib -DPACKAGE=\""grassmods"\" -o /c/grass/grass6/dist.i686-pc-mingw32/bin/r.li.patchAreaDistributionSD.exe OBJ.i686-pc-mingw32/patchAreaDistributionSD.o /c/grass/grass6/lib/gis/OBJ.i686-pc-mingw32/fmode.o -lgrass_gis -lgrass_datetime -lxdr -liberty -lws2_32 -lz -llibr_li -lxdr -liberty -lws2_32 -lz c:\mingw\bin\..\lib\gcc\mingw32\3.4.2\..\..\..\..\mingw32\bin\ld.exe: cannot find -llibr_li collect2: ld returned 1 exit status make[1]: *** [/c/grass/grass6/dist.i686-pc-mingw32/bin/r.li.patchAreaDistributionSD.exe] Error 1 make[1]: Leaving directory `/c/grass/grass6/raster/r.li/r.li.patchAreaDistributionSD' r.li.patchAreaDistributionRANGE make[1]: Entering directory `/c/grass/grass6/raster/r.li/r.li.patchAreaDistributionRANGE' gcc -L/c/grass/grass6/dist.i686-pc-mingw32/lib -Wl,--export-dynamic,--enable-runtime-pseudo-reloc -L/c/grass/forgrass/lib -DPACKAGE=\""grassmods"\" -o /c/grass/grass6/dist.i686-pc-mingw32/bin/r.li.patchAreaDistributionRANGE.exe OBJ.i686-pc-mingw32/patchAreaDistributionRANGE.o /c/grass/grass6/lib/gis/OBJ.i686-pc-mingw32/fmode.o -lgrass_gis -lgrass_datetime -lxdr -liberty -lws2_32 -lz -llibr_li -lxdr -liberty -lws2_32 -lz c:\mingw\bin\..\lib\gcc\mingw32\3.4.2\..\..\..\..\mingw32\bin\ld.exe: cannot find -llibr_li collect2: ld returned 1 exit status make[1]: *** [/c/grass/grass6/dist.i686-pc-mingw32/bin/r.li.patchAreaDistributionRANGE.exe] Error 1 make[1]: Leaving directory `/c/grass/grass6/raster/r.li/r.li.patchAreaDistributionRANGE' r.li.contrastWeightedEdgeDensity make[1]: Entering directory `/c/grass/grass6/raster/r.li/r.li.contrastWeightedEdgeDensity' gcc -L/c/grass/grass6/dist.i686-pc-mingw32/lib -Wl,--export-dynamic,--enable-runtime-pseudo-reloc -L/c/grass/forgrass/lib -DPACKAGE=\""grassmods"\" -o /c/grass/grass6/dist.i686-pc-mingw32/bin/r.li.contrastWeightedEdgeDensity.exe OBJ.i686-pc-mingw32/contrastWeightedEdgeDensity.o OBJ.i686-pc-mingw32/utility.o /c/grass/grass6/lib/gis/OBJ.i686-pc-mingw32/fmode.o -lgrass_gis -lgrass_datetime -lxdr -liberty -lws2_32 -lz -llibr_li -lxdr -liberty -lws2_32 -lz c:\mingw\bin\..\lib\gcc\mingw32\3.4.2\..\..\..\..\mingw32\bin\ld.exe: cannot find -llibr_li collect2: ld returned 1 exit status make[1]: *** [/c/grass/grass6/dist.i686-pc-mingw32/bin/r.li.contrastWeightedEdgeDensity.exe] Error 1 make[1]: Leaving directory `/c/grass/grass6/raster/r.li/r.li.contrastWeightedEdgeDensity' r.li.richness make[1]: Entering directory `/c/grass/grass6/raster/r.li/r.li.richness' gcc -L/c/grass/grass6/dist.i686-pc-mingw32/lib -Wl,--export-dynamic,--enable-runtime-pseudo-reloc -L/c/grass/forgrass/lib -DPACKAGE=\""grassmods"\" -o /c/grass/grass6/dist.i686-pc-mingw32/bin/r.li.richness.exe OBJ.i686-pc-mingw32/richness.o /c/grass/grass6/lib/gis/OBJ.i686-pc-mingw32/fmode.o -lgrass_gis -lgrass_datetime -lxdr -liberty -lws2_32 -lz -llibr_li -lxdr -liberty -lws2_32 -lz c:\mingw\bin\..\lib\gcc\mingw32\3.4.2\..\..\..\..\mingw32\bin\ld.exe: cannot find -llibr_li collect2: ld returned 1 exit status make[1]: *** [/c/grass/grass6/dist.i686-pc-mingw32/bin/r.li.richness.exe] Error 1 make[1]: Leaving directory `/c/grass/grass6/raster/r.li/r.li.richness' r.li.dominance make[1]: Entering directory `/c/grass/grass6/raster/r.li/r.li.dominance' gcc -L/c/grass/grass6/dist.i686-pc-mingw32/lib -Wl,--export-dynamic,--enable-runtime-pseudo-reloc -L/c/grass/forgrass/lib -DPACKAGE=\""grassmods"\" -o /c/grass/grass6/dist.i686-pc-mingw32/bin/r.li.dominance.exe OBJ.i686-pc-mingw32/dominance.o /c/grass/grass6/lib/gis/OBJ.i686-pc-mingw32/fmode.o -lgrass_gis -lgrass_datetime -lxdr -liberty -lws2_32 -lz -llibr_li -lxdr -liberty -lws2_32 -lz c:\mingw\bin\..\lib\gcc\mingw32\3.4.2\..\..\..\..\mingw32\bin\ld.exe: cannot find -llibr_li collect2: ld returned 1 exit status make[1]: *** [/c/grass/grass6/dist.i686-pc-mingw32/bin/r.li.dominance.exe] Error 1 make[1]: Leaving directory `/c/grass/grass6/raster/r.li/r.li.dominance' mkdir -p /c/grass/grass6/dist.i686-pc-mingw32/docs/html mv -f r.li.tmp.html /c/grass/grass6/dist.i686-pc-mingw32/docs/html/r.li.html for file in *.png *.jpg ; do \ head -n 1 $file | grep '^#!' > /dev/null ; \ if [ $? -ne 0 ] ; then \ /bin/install -c -m 644 $file /c/grass/grass6/dist.i686-pc-mingw32/docs/html ; \ fi \ done 2> /dev/null ; true From radim.blazek at gmail.com Tue Jan 2 12:57:39 2007 From: radim.blazek at gmail.com (Radim Blazek) Date: Tue Jan 2 12:57:41 2007 Subject: [GRASS-dev] Re: [Qgis-developer] Windows native GRASS build In-Reply-To: References: <340505ef0701010447s39a3912fy439fbb8274fba804@mail.gmail.com> Message-ID: <340505ef0701020357r1636e972vd95be1e18516e602@mail.gmail.com> On 1/1/07, Tim Sutton wrote: > > > 2) When clicking on a tool inthe GRASS toolbox, I get a message like: > > > "Warning: cannot find key output" > > > > Which module? > > *every module* > > Any ideas what can be causing that? I cannot get that message with http://qgis.org/uploadfiles/testbuilds/qgis_setup.exe (02-Jan-2007 06:29 44M). No idea, very strange. It was always working. The message means that parameter 'output' is missing in the XML description of GRASS module written out by a module run with --interface-description option. You could try to run a module (in shell) with that option and check if the 'output' option tag is in XML printed on stdout. Radim From tim at linfiniti.com Tue Jan 2 13:28:18 2007 From: tim at linfiniti.com (Tim Sutton) Date: Tue Jan 2 13:28:20 2007 Subject: [GRASS-dev] Re: [Qgis-developer] Windows native GRASS build In-Reply-To: <340505ef0701020357r1636e972vd95be1e18516e602@mail.gmail.com> References: <340505ef0701010447s39a3912fy439fbb8274fba804@mail.gmail.com> <340505ef0701020357r1636e972vd95be1e18516e602@mail.gmail.com> Message-ID: Hi Yes thats a new build you tested with. I uploaded it I went to sleep at 4am this morning. I was going to write a message when I woke up saying the problem was fixed but looks like you beat me to it ! :-P The version you have downloaded also has GRASS built with postgres support. I was not able to test pg support at home - can someone give it a try? I'm hoping the version I uploaded last night http://qgis.org/uploadfiles/testbuilds/qgis_setup.exe fixes all remaining issues so everyone interested in the Win build please download it and test it out. Please note that the installer offers to download sample data for you but you will need to manually unzip the data in you Quantum GIS/SampleData dir since I couldnt yet get NSIS to automate that. I hope to put this version online on the main qgis 0.8 release page later today so any issues found after that will have to get resolved in a follow up bug fix release. I will also upload the msys environment which contains everything you need to build grass for windows msys later today. Regards Tim On 1/2/07, Radim Blazek wrote: > On 1/1/07, Tim Sutton wrote: > > > > 2) When clicking on a tool inthe GRASS toolbox, I get a message like: > > > > "Warning: cannot find key output" > > > > > > Which module? > > > > *every module* > > > > Any ideas what can be causing that? > > I cannot get that message with > http://qgis.org/uploadfiles/testbuilds/qgis_setup.exe > (02-Jan-2007 06:29 44M). > > No idea, very strange. It was always working. The message means that > parameter 'output' is missing in the XML description of GRASS module > written out by a module run with --interface-description option. > You could try to run a module (in shell) with that option and check if > the 'output' option tag is in XML printed on stdout. > > Radim > -- -- Tim Sutton Visit http://qgis.org for a great Open Source GIS Home Page: http://linfiniti.com Skype: timlinux MSN: tim_bdworld@msn.com Yahoo: tim_bdworld@yahoo.com Jabber: timlinux Irc: timlinux on #qgis at freenode.net From cedricgrass at shockfamily.net Tue Jan 2 17:21:35 2007 From: cedricgrass at shockfamily.net (Cedric Shock) Date: Tue Jan 2 17:23:01 2007 Subject: [GRASS-dev] Re: Behavior of explore mode in GIS Manager In-Reply-To: References: Message-ID: <200701020821.36356.cedricgrass@shockfamily.net> Michael, > Essentially, it is changing so that a constant number of grid cells are > represented in the display window. > Is this the way we want zooming to work in this special mode? If so, we > need to change the mouse over help to make sure this is clear. If not, we > need to change how explore mode works so that it does not change > resolution. I can see advantages and disadvantages of each. This was very deliberate. Explore mode does two things: Makes the region displayed fill the window and Makes the region one cell per pixel on the display device. The solution is more documentation or ... I actually considered two separate toggle buttons when I designed this, one for filling the screen and one for automatic resolution changes. Another interesting behaviour is the one you described, "a constant number of grid cells are represented in the display window", but it is slightly less obvious how to use. --Cedric From tutey at o2.pl Tue Jan 2 17:52:03 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Tue Jan 2 17:52:06 2007 Subject: [GRASS-dev] g.region print flags combination In-Reply-To: References: <22A5FE4C-7F65-4E87-A823-0900E5D414CF@unity.ncsu.edu> <45994A35.5070805@o2.pl> Message-ID: <459A8DB3.6030205@o2.pl> Martin Landa wrote: > Hi, > > I hope, now it is fixed in CVS. Martin, "g.region -g" works OK now, but it prints a WARNING message on the top. It also prints few extra lines, compared to before, namely: projection=1 zone=34 datum=wgs84 ellipsoid=wgs84 Your WARNING message is correct and desired, as well as the extra info is usefull, but those several additional lines might brake some user's scripts. Unless the script parses the "g.region -g" output something like "eval `g.region -g`", it might fail to parse it as intended. And although using eval in scripts is the best option, we shouldn't assume the user doesn't do it some other way. E.g my r.surf.nnbathy parses "g.region -g" with awk instead of eval, because I din't know eval when I was writing the script. I only knew how to do it with awk, and it worked fine (anyway, a fixed version using eval should be online tonight). See also http://www.nabble.com/r.sum---parsable-for-shell-scripts-tf2707790.html#a7549849 I'd like to ask GRASS folks what you think about it - should the "g.region -g" output change during the GRASS 6.3? I guess these changes should wait for 7. Cheers, Maciek From tutey at o2.pl Tue Jan 2 18:39:41 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Tue Jan 2 18:39:48 2007 Subject: [GRASS-dev] Re: [GRASS-user] gis.m window still disappears In-Reply-To: <20070102102751.AHW77003@expms1.cites.uiuc.edu> References: <20070102102751.AHW77003@expms1.cites.uiuc.edu> Message-ID: <459A98DD.8010108@o2.pl> Gerald Nelson wrote: > I have done a cvs update of grass 63 a couple of times over the past > couple of days and still have the problem that the gis.m windows > appear briefly and then disappear. > > The terminal window reports > > WARNING: This feature is superseded and will be removed in future > versions of GRASS. Use the -g flag in combination with other print > flats, e.g. -pg. Looks like related to recent changes in g.region: http://www.nabble.com/Re%3A-g.region-print-flags-combination-p8126822.html Cheers, Maciek From landa.martin at gmail.com Tue Jan 2 18:49:07 2007 From: landa.martin at gmail.com (Martin Landa) Date: Tue Jan 2 18:49:09 2007 Subject: [GRASS-dev] g.region print flags combination In-Reply-To: <459A8DB3.6030205@o2.pl> References: <22A5FE4C-7F65-4E87-A823-0900E5D414CF@unity.ncsu.edu> <45994A35.5070805@o2.pl> <459A8DB3.6030205@o2.pl> Message-ID: Hi, 2007/1/2, Maciej Sieczka : > "g.region -g" works OK now, but it prints a WARNING message on the top. > It also prints few extra lines, compared to before, namely: > > projection=1 > zone=34 > datum=wgs84 > ellipsoid=wgs84 > > Your WARNING message is correct and desired, as well as the extra info > is usefull, but those several additional lines might brake some user's > scripts. So should I disable this warning, right? I think the additional lines would not break any scripts, which parse `g.region -g` output in a reasonable way (eval, awk) (?). Regards, Martin > Unless the script parses the "g.region -g" output something like "eval > `g.region -g`", it might fail to parse it as intended. And although > using eval in scripts is the best option, we shouldn't assume the user > doesn't do it some other way. > > E.g my r.surf.nnbathy parses "g.region -g" with awk instead of eval, > because I din't know eval when I was writing the script. I only knew > how to do it with awk, and it worked fine (anyway, a fixed version > using eval should be online tonight). > > See also > http://www.nabble.com/r.sum---parsable-for-shell-scripts-tf2707790.html#a7549849 > > I'd like to ask GRASS folks what you think about it - should the > "g.region -g" output change during the GRASS 6.3? I guess these changes > should wait for 7. > > Cheers, > Maciek > -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From paul-grass at stjohnspoint.co.uk Tue Jan 2 18:54:10 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Tue Jan 2 18:54:22 2007 Subject: [GRASS-dev] Re: [GRASS-user] gis.m window still disappears In-Reply-To: <459A98DD.8010108@o2.pl> References: <20070102102751.AHW77003@expms1.cites.uiuc.edu> <459A98DD.8010108@o2.pl> Message-ID: On Tue, 2 Jan 2007, Maciej Sieczka wrote: > Gerald Nelson wrote: >> I have done a cvs update of grass 63 a couple of times over the past >> couple of days and still have the problem that the gis.m windows >> appear briefly and then disappear. >> >> The terminal window reports >> >> WARNING: This feature is superseded and will be removed in future >> versions of GRASS. Use the -g flag in combination with other print >> flats, e.g. -pg. > > Looks like related to recent changes in g.region: > http://www.nabble.com/Re%3A-g.region-print-flags-combination-p8126822.html Oh well spotted! I was a bit blind to that. The behaviour of g.region is now inconsistent with the man page; it says: -p Print the current region -g Print the current region (shell script style) Perhaps the -g flag should be kept as it is and a new flag introduced for the new behaviour? g.region does have rather a lot of flags though. Paul From tutey at o2.pl Tue Jan 2 19:41:59 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Tue Jan 2 19:42:03 2007 Subject: [GRASS-dev] g.region print flags combination In-Reply-To: References: <22A5FE4C-7F65-4E87-A823-0900E5D414CF@unity.ncsu.edu> <45994A35.5070805@o2.pl> <459A8DB3.6030205@o2.pl> Message-ID: <459AA777.40504@o2.pl> Martin Landa wrote: > 2007/1/2, Maciej Sieczka : > >> "g.region -g" works OK now, but it prints a WARNING message on the top. >> It also prints few extra lines, compared to before, namely: >> >> projection=1 >> zone=34 >> datum=wgs84 >> ellipsoid=wgs84 >> >> Your WARNING message is correct and desired, as well as the extra info >> is usefull, but those several additional lines might brake some user's >> scripts. > > So should I disable this warning, right? I guess so. But somebody more knowledgable should decide. > I think the additional lines would not break any scripts, which parse > `g.region -g` output in a reasonable way (eval, awk) (?). Those extra lines might brake all scripts that don't use eval, I suppose. Eg. parsing with awk by line number will fail now: # grab the current region settings g.region -g > $TMP.${PROG}.region # extract variables from the grabbed region north=`awk 'BEGIN {FS="="} (NR==1) {print $2}' $TMP.${PROG}.region` south=`awk 'BEGIN {FS="="} (NR==2) {print $2}' $TMP.${PROG}.region` west=`awk 'BEGIN {FS="="} (NR==3) {print $2}' $TMP.${PROG}.region` east=`awk 'BEGIN {FS="="} (NR==4) {print $2}' $TMP.${PROG}.region` nsres=`awk 'BEGIN {FS="="} (NR==5) {print $2}' $TMP.${PROG}.region` ewres=`awk 'BEGIN {FS="="} (NR==6) {print $2}' $TMP.${PROG}.region` rows=`awk 'BEGIN {FS="="} (NR==7) {print $2}' $TMP.${PROG}.region` cols=`awk 'BEGIN {FS="="} (NR==8) {print $2}' $TMP.${PROG}.region` Is that "reasonable" I don't know, but it used to work with g.region -g before your recent changes, and now it fails, because top 4 lines of g.region -g output are different now. I personally don't care too much, I have fixed my script to use eval, but what with other users? I absolutely agree you are doing a Good Thing fixing g.region -g as you do, but I'm affraid it should wait till GRASS 7, for legacy reasons. Maciek From rez at touchofmadness.com Tue Jan 2 19:44:09 2007 From: rez at touchofmadness.com (Brad Douglas) Date: Tue Jan 2 19:44:18 2007 Subject: [GRASS-dev] Re: [Qgis-developer] Windows native GRASS build In-Reply-To: References: <340505ef0701010447s39a3912fy439fbb8274fba804@mail.gmail.com> <459A09ED.7050904@faunalia.it> Message-ID: <1167763449.11348.331.camel@devel> On Tue, 2007-01-02 at 11:33 +0000, Paul Kelly wrote: > Hello Paolo > > On Tue, 2 Jan 2007, Paolo Cavallini wrote: > > [...] > >>> /src/grass6/raster/r.li/r.li.daemon > >>> /src/grass6/raster/r.li/r.li.edgedensity > >>> /src/grass6/raster/r.li/r.li.patchdensity > >>> /src/grass6/raster/r.li/r.li.patchnumber > >>> /src/grass6/raster/r.li/r.li.shape > >>> /src/grass6/raster/r.li/r.li.simpson > >>> /src/grass6/raster/r.li/r.li.shannon > >>> /src/grass6/raster/r.li/r.li.meanPatchSize > >>> /src/grass6/raster/r.li/r.li.meanPixelAttribute > >>> /src/grass6/raster/r.li/r.li.patchAreaDistributionCV > >>> /src/grass6/raster/r.li/r.li.patchAreaDistributionSD > >>> /src/grass6/raster/r.li/r.li.patchAreaDistributionRANGE > >>> /src/grass6/raster/r.li/r.li.contrastWeightedEdgeDensity > >>> /src/grass6/raster/r.li/r.li.richness > >>> /src/grass6/raster/r.li/r.li.dominance > >> > >> Not crucial. > > > > Agreed, but we would like to have it. Tim, could you please forward the > > errors to Serena Pallecchi, Davide Spano and Claudio Porta? > > Please see attached. Main problems as far as I can see: > - Use of FIFOs? AIUI Windows doesn't have FIFOs so that won't work. > - Also I don't think fork() is available on Windows either - Glynn may be > able to advise. Linux: fork() exec() Win32: CreateProcess() Linux: exit() Win32: ExitProcess() Linux: get/putenv() Win32: Get/SetEnvironmentVariable() Linux: waitpid() Win32: GetExitCodeProcess() Linux; getpid() Win32: GetCurrentProcessId() It would be nice to have wrappers for these functions. Thoughts, Glynn? -- Brad Douglas KB8UYR/6 Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From tutey at o2.pl Tue Jan 2 20:30:16 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Tue Jan 2 20:30:21 2007 Subject: [GRASS-dev] new r.surf.nnbathy version In-Reply-To: <20060615152022.585f6042.werchowyna@epf.pl> References: <20060615152022.585f6042.werchowyna@epf.pl> Message-ID: <459AB2C8.8060908@o2.pl> Hi, New r.surf.nnbathy version uploaded to http://kufaya.googlepages.com/grassgisscripts (I'm still hoping to launch a real webpage, one day ;) ). Besides several fixes it now supports all the 3 interpolation methods nnbathy provides: l - linear triangulation nn - natural neighbor; Dave Watson's algorithm for Sibson interpolation ns - non-Sibsonian; Belikov and Semenov's formulas for non-Sibsonian interpolation All methods are using Jonathan Richard Shewchuk's software "triangle", for the underlaying Delaunay triangulation. Please refer to nn library source code for details. Many thanks to Pavel Sakov, nn and nnbathy author, for providing his ecxellent software and for being so helpfull! CHANGELOG: 1.6, 2006.06.15: - first public release 1.9, 2007.01.02: - parse g.region -g with eval, not awk - support all interpolation methods nnbathy provides - create history for output raster with r.support - require nnbathy 1.69 (major bug was fixed) - try to detect if nnbathy failed and exit cleanly - documentation extended - minor cleanups - todo: there is a progress indicator switch (-%) in nnbathy now, but using it slows down the interpolation 3-4 times on my machine, while works OK on nnbathy author's; if sorted out, I'll use -% Maciek From tim at linfiniti.com Tue Jan 2 20:58:18 2007 From: tim at linfiniti.com (Tim Sutton) Date: Tue Jan 2 20:58:21 2007 Subject: [GRASS-dev] Re: [Qgis-developer] Windows native GRASS build In-Reply-To: <1167763449.11348.331.camel@devel> References: <340505ef0701010447s39a3912fy439fbb8274fba804@mail.gmail.com> <459A09ED.7050904@faunalia.it> <1167763449.11348.331.camel@devel> Message-ID: Hi For those interested, I have uploaded the complete msys environemnt that Tisham Dhar and myself set up here: http://qgis.org/uploadfiles/msys/msys.tar.gz Its around 230mb since I have not run make clean in the source dirs and stripped away unneeeded stuff. However it contains a complete build environment for making grass (along with numerous other FOSS GIS stuff) under msys / windows. The GRASS in there is an anonynous checkout from head and a cvs client is included in teh msys so you can cvs update grass from in the msys shell. Regards Tim On 1/2/07, Brad Douglas wrote: > On Tue, 2007-01-02 at 11:33 +0000, Paul Kelly wrote: > > Hello Paolo > > > > On Tue, 2 Jan 2007, Paolo Cavallini wrote: > > > > [...] > > >>> /src/grass6/raster/r.li/r.li.daemon > > >>> /src/grass6/raster/r.li/r.li.edgedensity > > >>> /src/grass6/raster/r.li/r.li.patchdensity > > >>> /src/grass6/raster/r.li/r.li.patchnumber > > >>> /src/grass6/raster/r.li/r.li.shape > > >>> /src/grass6/raster/r.li/r.li.simpson > > >>> /src/grass6/raster/r.li/r.li.shannon > > >>> /src/grass6/raster/r.li/r.li.meanPatchSize > > >>> /src/grass6/raster/r.li/r.li.meanPixelAttribute > > >>> /src/grass6/raster/r.li/r.li.patchAreaDistributionCV > > >>> /src/grass6/raster/r.li/r.li.patchAreaDistributionSD > > >>> /src/grass6/raster/r.li/r.li.patchAreaDistributionRANGE > > >>> /src/grass6/raster/r.li/r.li.contrastWeightedEdgeDensity > > >>> /src/grass6/raster/r.li/r.li.richness > > >>> /src/grass6/raster/r.li/r.li.dominance > > >> > > >> Not crucial. > > > > > > Agreed, but we would like to have it. Tim, could you please forward the > > > errors to Serena Pallecchi, Davide Spano and Claudio Porta? > > > > Please see attached. Main problems as far as I can see: > > - Use of FIFOs? AIUI Windows doesn't have FIFOs so that won't work. > > - Also I don't think fork() is available on Windows either - Glynn may be > > able to advise. > > Linux: fork() exec() > Win32: CreateProcess() > > Linux: exit() > Win32: ExitProcess() > > Linux: get/putenv() > Win32: Get/SetEnvironmentVariable() > > Linux: waitpid() > Win32: GetExitCodeProcess() > > Linux; getpid() > Win32: GetCurrentProcessId() > > It would be nice to have wrappers for these functions. Thoughts, Glynn? > > > -- > Brad Douglas KB8UYR/6 > Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > -- -- Tim Sutton Visit http://qgis.org for a great Open Source GIS Home Page: http://linfiniti.com Skype: timlinux MSN: tim_bdworld@msn.com Yahoo: tim_bdworld@yahoo.com Jabber: timlinux Irc: timlinux on #qgis at freenode.net From dsampson at NRCan.gc.ca Tue Jan 2 22:44:27 2007 From: dsampson at NRCan.gc.ca (Sampson, David) Date: Tue Jan 2 22:44:34 2007 Subject: [GRASS-dev] Public Address Geo Coding: Join the Team Message-ID: <2FAA57395C1F914DB27CAA4C376058F201800443@S0-OTT-X2.nrn.nrcan.gc.ca> Public Address Geo Coding: Join the Team Dave Sampson here, This is a blunt call for programmers and users that would be interested in another geometrics related open source project. PAGC is the Public Address Geo Coder. We are looking to diversify our coder base and also get the word out about this established but quiet project. We are looking for a lead code architect to lead the charge from a CLI to a library with bindings to python etc. We are also looking for all types of skill sets and inputs to contribute. Synopsis: The Postal Address Geo-Coder (or PAGC) is a command line program written in ANSI C that uses an address-ranged street network shapefile and an address list (in a dbf format file) to create a point shapefile that provides the longitude/latitude coordinates of each matched address, and maintains the attribute information in the original address database file. PAGC is Open Source, and is released under the GNU Lesser General Public License. PAGC has been built and tested under GNU-Linux, Microsoft Windows, and Mac OS X. However, since it is written in ANSI C, it should be possible to build and use PAGC under any operating system that provides a command line interface. While PAGC is currently a command line program, we have a major initiative to create a C library based on the code and algorithms used in the command line program. This should allow other open source GIS oriented projects to add postal address geo-coding features to their software. The Web page: http://www.pagcgeo.org/ Sourceforge site: https://sourceforge.net/projects/pagc/ Dev mailing list: https://lists.sourceforge.net/lists/listinfo/pagc-devel User Mailing List: https://lists.sourceforge.net/lists/listinfo/pagc-users If you're looking for a project to get involved with at a critical juncture then this is your bet. Join the list(s) and introduce yourself. You might see some familiar faces. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070102/1d063311/attachment.html From landa.martin at gmail.com Wed Jan 3 08:15:42 2007 From: landa.martin at gmail.com (Martin Landa) Date: Wed Jan 3 08:15:54 2007 Subject: [GRASS-dev] Re: [GRASS-user] gis.m window still disappears In-Reply-To: References: <20070102102751.AHW77003@expms1.cites.uiuc.edu> <459A98DD.8010108@o2.pl> Message-ID: Hi, first of all I am really sorry for that. It was careless of me to change the behaviour in a such radical way. I will update the documentation when g.region -g issue will be closed (very soon I hope). Martin 2007/1/2, Paul Kelly : > > > On Tue, 2 Jan 2007, Maciej Sieczka wrote: > > > Gerald Nelson wrote: > >> I have done a cvs update of grass 63 a couple of times over the past > >> couple of days and still have the problem that the gis.m windows > >> appear briefly and then disappear. > >> > >> The terminal window reports > >> > >> WARNING: This feature is superseded and will be removed in future > >> versions of GRASS. Use the -g flag in combination with other print > >> flats, e.g. -pg. > > > > Looks like related to recent changes in g.region: > > http://www.nabble.com/Re%3A-g.region-print-flags-combination-p8126822.html > > Oh well spotted! I was a bit blind to that. The behaviour of g.region is > now inconsistent with the man page; it says: > > -p Print the current region > -g Print the current region (shell script style) > > Perhaps the -g flag should be kept as it is and a new flag introduced for > the new behaviour? g.region does have rather a lot of flags though. > > Paul > > -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From landa.martin at gmail.com Wed Jan 3 08:41:36 2007 From: landa.martin at gmail.com (Martin Landa) Date: Wed Jan 3 08:41:44 2007 Subject: [GRASS-dev] Re: [GRASS-user] Re: grassuser Digest, Vol 9, Issue 1 In-Reply-To: References: <200701021709.l02H9mm8000900@grass.itc.it> Message-ID: Hi, 2007/1/2, Paul Kelly : > But the other issue is of course - should we be changing the meaning of > the g.region -g flag at all? Why not keep it as it is and add the new > functionality (key=value output in combination with any other flag) to a > totally new flag, to reduce confusion and enhance backwards compatibility? not sure, there are *a lot of flags* in g.region module. Adding a new one which generally have the same impact as the -g flag (i.e. key=value output) -- I don't know. Now `g.region -g` (still there is a warning message) is the same as `g.region -pg`. I think that the -g or --g flag should have the same meaning in all GRASS modules: to print parsable output. I changed the -g flag behaviour mainly because I wanted to allow user to use this flag in connection with other print flags, e.g. `g.region -eg`. Regards, Martin -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From paul-grass at stjohnspoint.co.uk Wed Jan 3 09:53:47 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Wed Jan 3 09:54:13 2007 Subject: [GRASS-dev] Re: [GRASS-user] Re: grassuser Digest, Vol 9, Issue 1 In-Reply-To: References: <200701021709.l02H9mm8000900@grass.itc.it> Message-ID: Hello Martin On Wed, 3 Jan 2007, Martin Landa wrote: > Hi, > > 2007/1/2, Paul Kelly : > >> But the other issue is of course - should we be changing the meaning of >> the g.region -g flag at all? Why not keep it as it is and add the new >> functionality (key=value output in combination with any other flag) to a >> totally new flag, to reduce confusion and enhance backwards compatibility? > > not sure, there are *a lot of flags* in g.region module. Adding a new > one which generally have the same impact as the -g flag (i.e. > key=value output) -- I don't know. > > Now `g.region -g` (still there is a warning message) is the same as > `g.region -pg`. I think that the -g or --g flag should have the same > meaning in all GRASS modules: to print parsable output. I changed the > -g flag behaviour mainly because I wanted to allow user to use this > flag in connection with other print flags, e.g. `g.region -eg`. Yes its definitely not a bad thing to sort out the inconsistencies; you just need to also check how they affect other parts of GRASS. In particuar, gis.m seems to be quite tightly bound to the existing behaviour of g.region and its quirks. If you grep for g.region in the gui/tcltk/gis.m directory you will see quite a few places where it is called with different flags and then the output parsed with a regular expression. The return value of the regexp command isn't checked anywhere, so if the regular expression doesn't match the output from g.region exactly (e.g. because of the new features) then it will fail at some stage. So it would be worthwhile I think to look at the existing uses of g.region and the matching regexps in gis.m and see if they can be rationalised to make best use of the new features of g.region. Worth checking throughout the whole source code actually - there are a lot of things that call g.region and parse its output. Like I said, definitely a good idea to sort out the inconsistencies but need to stay backward-compatible until we fix everything that depended on the old behaviour. Paul From michael.barton at asu.edu Wed Jan 3 15:36:04 2007 From: michael.barton at asu.edu (Michael Barton) Date: Wed Jan 3 15:36:18 2007 Subject: [GRASS-dev] Re: [GRASS-user] Re: grassuser Digest, Vol 9, Issue 1 In-Reply-To: Message-ID: I haven't yet tried this new version of g.region but hope to soon. It sounds like g.region -g is now issuing an interactive terminal message. If this is so, I need to note that we are trying to remove all required user interaction via the terminal. Any command that sends a message and asks the user for Y/N or something like that makes that command very difficult to use in a script or GUI language. At least the --q option should kill all such interaction. We should be able to run the command and have it return whatever it returns (including an error where appropriate) without requiring the user to interact via the terminal. Thanks Michael On 1/3/07 12:41 AM, "Martin Landa" wrote: > Hi, > > 2007/1/2, Paul Kelly : > >> But the other issue is of course - should we be changing the meaning of >> the g.region -g flag at all? Why not keep it as it is and add the new >> functionality (key=value output in combination with any other flag) to a >> totally new flag, to reduce confusion and enhance backwards compatibility? > > not sure, there are *a lot of flags* in g.region module. Adding a new > one which generally have the same impact as the -g flag (i.e. > key=value output) -- I don't know. > > Now `g.region -g` (still there is a warning message) is the same as > `g.region -pg`. I think that the -g or --g flag should have the same > meaning in all GRASS modules: to print parsable output. I changed the > -g flag behaviour mainly because I wanted to allow user to use this > flag in connection with other print flags, e.g. `g.region -eg`. > > Regards, Martin __________________________________________ 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 Jan 3 15:43:44 2007 From: michael.barton at asu.edu (Michael Barton) Date: Wed Jan 3 15:43:52 2007 Subject: [GRASS-dev] Re: [GRASS-user] Re: grassuser Digest, Vol 9, Issue 1 In-Reply-To: Message-ID: I very much agree. In order for the GUI and its display to work properly, we must be able to obtain information about the current region and to change it. The most transparent way to do this is entirely through the use of GRASS commands rather than trying to read WIND or other files. Other information-getting commands that are used in the GUI include r.info, v.info, r.univar, v.univar.sh, and r.statistics. I support trying to cleanup and regularize the output of any such commands that return information about the GRASS environment. But because they are used currently in the GUI (and other scripts), we need to be careful about keeping them backward compatible or synching changes with other systems that depend on them. Michael On 1/3/07 1:53 AM, "Paul Kelly" wrote: > So it would be worthwhile I think to look at the existing uses of g.region > and the matching regexps in gis.m and see if they can be rationalised to > make best use of the new features of g.region. > Worth checking throughout the whole source code actually - there are a lot > of things that call g.region and parse its output. Like I said, definitely > a good idea to sort out the inconsistencies but need to stay > backward-compatible until we fix everything that depended on the old > behaviour. __________________________________________ 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 Jan 3 16:59:01 2007 From: michael.barton at asu.edu (Michael Barton) Date: Wed Jan 3 16:59:09 2007 Subject: [GRASS-dev] Re: [GRASS-user] Re: grassuser Digest, Vol 9, Issue 1 In-Reply-To: Message-ID: I just was able to compile the cvs version from today. It turns out that there are 2 issues. First, g.region -g is functionally replaced by g.region -gp Second, there has been a format change to the output from g.region -p Both of these can be fixed in the GUI and I will try to do so today. I have a couple of suggestions. I'm not sure about putting the warning in g.region -g. But if it was after the output, it would be much less harmful in existing scripts (including the GUI) than if it precedes normal output. Second, I don't know how the format for g.region -p changed exactly. Perhaps it's better than before. And I'm strongly in favor of creating better, more parsable, more consistent, output from commands like g.region. We just need to be careful about breaking things where it is currently used when this is done. It looks like this affects both the main GUI and the georectifier in this case. Michael On 1/3/07 1:53 AM, "Paul Kelly" wrote: > Hello Martin > > On Wed, 3 Jan 2007, Martin Landa wrote: > >> Hi, >> >> 2007/1/2, Paul Kelly : >> >>> But the other issue is of course - should we be changing the meaning of >>> the g.region -g flag at all? Why not keep it as it is and add the new >>> functionality (key=value output in combination with any other flag) to a >>> totally new flag, to reduce confusion and enhance backwards compatibility? >> >> not sure, there are *a lot of flags* in g.region module. Adding a new >> one which generally have the same impact as the -g flag (i.e. >> key=value output) -- I don't know. >> >> Now `g.region -g` (still there is a warning message) is the same as >> `g.region -pg`. I think that the -g or --g flag should have the same >> meaning in all GRASS modules: to print parsable output. I changed the >> -g flag behaviour mainly because I wanted to allow user to use this >> flag in connection with other print flags, e.g. `g.region -eg`. > > Yes its definitely not a bad thing to sort out the inconsistencies; you > just need to also check how they affect other parts of GRASS. In > particuar, gis.m seems to be quite tightly bound to the existing > behaviour of g.region and its quirks. If you grep for g.region in the > gui/tcltk/gis.m directory you will see quite a few places where it is > called with different flags and then the output parsed with a regular > expression. The return value of the regexp command isn't checked anywhere, > so if the regular expression doesn't match the output from g.region > exactly (e.g. because of the new features) then it will fail at some > stage. > > So it would be worthwhile I think to look at the existing uses of g.region > and the matching regexps in gis.m and see if they can be rationalised to > make best use of the new features of g.region. > Worth checking throughout the whole source code actually - there are a lot > of things that call g.region and parse its output. Like I said, definitely > a good idea to sort out the inconsistencies but need to stay > backward-compatible until we fix everything that depended on the old > behaviour. > > Paul > __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From tutey at o2.pl Wed Jan 3 17:11:39 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Wed Jan 3 17:11:44 2007 Subject: [GRASS-dev] Re: [GRASS-user] Re: grassuser Digest, Vol 9, Issue 1 In-Reply-To: References: Message-ID: <459BD5BB.1000100@o2.pl> Michael Barton wrote: > I haven't yet tried this new version of g.region but hope to soon. It sounds > like g.region -g is now issuing an interactive terminal message. No it doesn't. The differences between the old and current g.region -g are: - the WARNING message on the top of the g.region output - 4 extra lines in the g.region -g output: projection= zone= datum= ellipsoid= Maciek From dca.gis at gmail.com Wed Jan 3 17:45:14 2007 From: dca.gis at gmail.com (Daniel Calvelo) Date: Wed Jan 3 17:45:19 2007 Subject: [GRASS-dev] g.list -a In-Reply-To: References: <17806.65476.593110.361071@cerise.gclements.plus.com> <17809.48637.726595.182177@cerise.gclements.plus.com> Message-ID: <1a486f560701030845j37776763m4350ff8d011d9984@mail.gmail.com> How about g.list type=any or g.list type=all? 2c. On 12/28/06, Martin Landa wrote: > Hi, > > I have just one general (maybe a little bit silly;-) question. There > are number of modules which follow this pattern: > > * there is one (determinative) parameter (e.g. type in g.list) > * and the flag for all types (e.g. -a -- List all data types) > > I can see two distinct approaches: > > 1) the determinative parameter is requested > > -> usage: g.list -a type= > > This is more precise for parsing syntax of the module, I think. On the > other hand a little bit confusing for the user. > > 2) the determinative parameter is not requested > > -> usage: g.list -a > > This construction is more clear for the user I hope. But it cause more > problems for programmer -- there is a need to handle meaningless usage > of the module, e.g. g.list -f (verbose listing). > > I am not sure which approach is better. > > Best regards, Martin > > 2006/12/27, Martin Landa : > > Hi, > > > > 2006/12/27, Glynn Clements : > > > > > > Martin Landa wrote: > > > > > > > > > I am trying to implement the wish [1]. I found a strange construction > > > > > > in g.list module. The -f flag (full listing) calls the external > > > > > > program $GISBASE/etc/lister/[cell|vector]. These little programs are > > > > > > called only in g.list -f (I think). > > > > > > > > > > > > I rewrote g.list without calling any external program -- i.e. I moved > > > > > > functions from lister directory to lib/lister.c. If there are no > > > > > > serious objections I will commit it to CVS. > > > > > > > > > > Don't remove the existing functionality; add a new switch for using > > > > > your built-in lister. > > > > > > > > this patch does not remove any functionality (AFAIK). The only change > > > > is: the functionality of lister (programs) is moved to lib/lister.c. I > > > > don't see any reason why to have this functionality (the -f flag) > > > > outside of the g.list (/etc/lister/[cell|vector]). Maybe there is a > > > > particular reason for this construction, please let me know. Thanks! > > > > > > > > The user can install lister programs for other types and/or replace > > > existing ones. > > > > OK, it makes sense to me (only it's hard to imagine an user how > > installs other lister program instead of changing the code;-) > > > > > The point of -f isn't so much to provide specific additional > > > functionality, but to allow the handling to be deferred to an external > > > program. > > > > You are right, I have tried to change the patch in this way, not sure > > if I am working with child process as I should have. In any case > > g.list works:-) > > > > Martin > > > > > -- > > > Glynn Clements > > > > > > > > > -- > > Martin Landa * http://gama.fsv.cvut.cz/~landa * > > > > > > > > > -- > 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 > -- -- Daniel Calvelo Aros From jachym.cepicky at centrum.cz Wed Jan 3 17:50:26 2007 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Wed Jan 3 17:50:31 2007 Subject: [GRASS-dev] ps.map fprintf -> G_ In-Reply-To: References: Message-ID: <20070103165026.GB6831@localdomain> Hi, nice job, thanks for the patch, but when I'm thinking about it, ... this patch makes ps.map set it's verbosity not by the --quiet or --verbose flags, but also according to the input configuration file. imho, the simplest solution should be, remove the VERBOSE keyword from ps.map. It would not harm to anythink. I doubt, some people are parsing output from ps.map in their scripts. If so, G_set_verbose function is the best solution. What do others think? Jachym On Tue, Dec 26, 2006 at 11:16:44AM +0100, Martin Landa wrote: > Hi all, > > trying to change fprintf to G_message/warning/fatal_error in ps.map > module I found one complication. There is a special mapping > instruction --- VERBOSE. I think this instruction should overwrite > GRASS_VERBOSE environment variable(??). There is also need to have a > special function G_set_verbose() which allows to set a given verbosity > level after first calling of G_verbose() fn. Please look at the patch > (especially at verbose.c.diff). Thanks a lot. > > Best regards, 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 -- Jachym Cepicky e-mail: jachym.cepicky@centrum.cz URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub ----------------------------------------- OFFICE: Department of Geoinformation Technologies Zemedelska 3 613 00, Brno Czech Republick e-mail: xcepicky@node.mendelu.cz URL: http://mapserver.mendelu.cz Tel.: +420 545 134 514 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070103/e4662400/attachment.bin From michael.barton at asu.edu Wed Jan 3 17:58:58 2007 From: michael.barton at asu.edu (Michael Barton) Date: Wed Jan 3 17:59:06 2007 Subject: [GRASS-dev] Re: [GRASS-user] Re: grassuser Digest, Vol 9, Issue 1 In-Reply-To: Message-ID: I've fixed the issues that arose from the changes to g.region and committed the updates to the cvs. Thanks again to Bernhard for getting me set up for cvs access from home. Michael On 1/3/07 1:53 AM, "Paul Kelly" wrote: > Hello Martin > > On Wed, 3 Jan 2007, Martin Landa wrote: > >> Hi, >> >> 2007/1/2, Paul Kelly : >> >>> But the other issue is of course - should we be changing the meaning of >>> the g.region -g flag at all? Why not keep it as it is and add the new >>> functionality (key=value output in combination with any other flag) to a >>> totally new flag, to reduce confusion and enhance backwards compatibility? >> >> not sure, there are *a lot of flags* in g.region module. Adding a new >> one which generally have the same impact as the -g flag (i.e. >> key=value output) -- I don't know. >> >> Now `g.region -g` (still there is a warning message) is the same as >> `g.region -pg`. I think that the -g or --g flag should have the same >> meaning in all GRASS modules: to print parsable output. I changed the >> -g flag behaviour mainly because I wanted to allow user to use this >> flag in connection with other print flags, e.g. `g.region -eg`. > > Yes its definitely not a bad thing to sort out the inconsistencies; you > just need to also check how they affect other parts of GRASS. In > particuar, gis.m seems to be quite tightly bound to the existing > behaviour of g.region and its quirks. If you grep for g.region in the > gui/tcltk/gis.m directory you will see quite a few places where it is > called with different flags and then the output parsed with a regular > expression. The return value of the regexp command isn't checked anywhere, > so if the regular expression doesn't match the output from g.region > exactly (e.g. because of the new features) then it will fail at some > stage. > > So it would be worthwhile I think to look at the existing uses of g.region > and the matching regexps in gis.m and see if they can be rationalised to > make best use of the new features of g.region. > Worth checking throughout the whole source code actually - there are a lot > of things that call g.region and parse its output. Like I said, definitely > a good idea to sort out the inconsistencies but need to stay > backward-compatible until we fix everything that depended on the old > behaviour. > > Paul > __________________________________________ 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 centrum.cz Wed Jan 3 18:14:54 2007 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Wed Jan 3 18:15:00 2007 Subject: [GRASS-dev] Re: [GRASS-user] Re: grassuser Digest, Vol 9, Issue 1 In-Reply-To: <459BD5BB.1000100@o2.pl> References: <459BD5BB.1000100@o2.pl> Message-ID: <20070103171453.GC6831@localdomain> Hi, On Wed, Jan 03, 2007 at 05:11:39PM +0100, Maciej Sieczka wrote: > Michael Barton wrote: > > I haven't yet tried this new version of g.region but hope to soon. It sounds > > like g.region -g is now issuing an interactive terminal message. > > No it doesn't. The differences between the old and current g.region -g are: > > - the WARNING message on the top of the g.region output > > - 4 extra lines in the g.region -g output: > projection= > zone= > datum= > ellipsoid= > > Maciek > sorry, if this will sound radical, but adding new lines of this kind to program output is IMHO not *change* but *added funtionality*. It makes g.region more usable than it was. It the output is more informative, than it was. Maybe new lines could be clipped to end of the "old" output, not in front of it. Jachym P.S. The -g flag could IMHO remain also in the future. It is faster to use only one flag (-g) than two flags (-gp). -- Jachym Cepicky e-mail: jachym.cepicky@centrum.cz URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub ----------------------------------------- OFFICE: Department of Geoinformation Technologies Zemedelska 3 613 00, Brno Czech Republick e-mail: xcepicky@node.mendelu.cz URL: http://mapserver.mendelu.cz Tel.: +420 545 134 514 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070103/1c21df0f/attachment.bin From stefan.paulick at urbeli.com Wed Jan 3 18:58:45 2007 From: stefan.paulick at urbeli.com (Paulick Consult) Date: Wed Jan 3 18:58:48 2007 Subject: [GRASS-dev] Re: grassuser Digest, Vol 9, Issue 1 In-Reply-To: References: Message-ID: <200701031758.l03Hwj9S018961@mail.bytecamp.net> Michael Barton schrieb: > I've fixed the issues that arose from the changes to g.region and committed > the updates to the cvs. Yes, it is working again. Thank you very much! At the risk of being a nuisance: d.rast map=k1 -o fails on a known good map as following: PNG: GRASS_TRUECOLOR status: TRUE PNG: collecting to file: /home/grassdata/grassuser/user/.tmp/ucon643/24892.0.ppm, GRASS_WIDTH=642, GRASS_HEIGHT=465 region for current mapset line 7: run "g.region" Mit freundlichen Gr??en / With kindest regards Stefan Paulick http://www.urbeli.com mailto://stefan.paulick@urbeli.com /*----------------------*/ From tutey at o2.pl Wed Jan 3 19:52:30 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Wed Jan 3 19:52:34 2007 Subject: [GRASS-dev] Re: [GRASS-user] Re: grassuser Digest, Vol 9, Issue 1 In-Reply-To: <20070103171453.GC6831@localdomain> References: <459BD5BB.1000100@o2.pl> <20070103171453.GC6831@localdomain> Message-ID: <459BFB6E.2090501@o2.pl> Jachym Cepicky wrote: > On Wed, Jan 03, 2007 at 05:11:39PM +0100, Maciej Sieczka wrote: >> Michael Barton wrote: >>> I haven't yet tried this new veWrsion of g.region but hope to soon. It sounds >>> like g.region -g is now issuing an interactive terminal message. >> No it doesn't. The differences between the old and current g.region -g are: >> >> - the WARNING message on the top of the g.region output >> >> - 4 extra lines in the g.region -g output: >> projection= >> zone= >> datum= >> ellipsoid= > sorry, if this will sound radical, but adding new lines of this kind to program > output is IMHO not *change* but *added funtionality*. Jachym, Actually it is not really an *added* functionality, but a modification to an *already-existing* functionality in GRASS 6. Martin's g.region -g output is different from the g.region -g output before, isn't it? I guess this should not happen *during* GRASS 6. Should be left for GRASS 7. Sure Martin's approach is right! I much appreciate and enjoy his work on sanitising GRASS code. Only that *this particular change* might brake programs depending on g.region output in GRASS 6 so far. That's all I'm concerned with. That's my last word regarding this case. Please do whatever you think is right now. Best, Maciek From michael.barton at asu.edu Wed Jan 3 22:08:53 2007 From: michael.barton at asu.edu (Michael Barton) Date: Wed Jan 3 22:09:00 2007 Subject: [GRASS-dev] Re: Behavior of explore mode in GIS Manager In-Reply-To: <200701020821.36356.cedricgrass@shockfamily.net> Message-ID: Hi Cedric, I figured that you intended it to be this way, but wanted to make sure that others understood it as well. Most of the concern about this was obviated when we decoupled the display region settings from the 'computational' region settings. Cheers Michael On 1/2/07 9:21 AM, "Cedric Shock" wrote: > Michael, > >> Essentially, it is changing so that a constant number of grid cells are >> represented in the display window. > >> Is this the way we want zooming to work in this special mode? If so, we >> need to change the mouse over help to make sure this is clear. If not, we >> need to change how explore mode works so that it does not change >> resolution. I can see advantages and disadvantages of each. > > This was very deliberate. Explore mode does two things: > > Makes the region displayed fill the window and > Makes the region one cell per pixel on the display device. > > The solution is more documentation or ... > > I actually considered two separate toggle buttons when I designed this, one > for filling the screen and one for automatic resolution changes. Another > interesting behaviour is the one you described, "a constant number of grid > cells are represented in the display window", but it is slightly less obvious > how to use. > > --Cedric __________________________________________ 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 Thu Jan 4 06:42:23 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Jan 4 06:42:31 2007 Subject: [GRASS-dev] G.region bug when setting 3d resolution??? Maybe not In-Reply-To: <200701040513.l045DF9T010360@mail.bytecamp.net> Message-ID: Paulick, Below I try to answer at least a few questions. Midway through, I think I figured out what the problem is. There was a long-standing bug in the 3D settings using g.region. Then again, maybe not. Read on... On 1/3/07 10:13 PM, "Paulick Consult" wrote: > Michael, > > I found that both PERMANENT WIND and DEFAULT_WIND was set to: > > proj: 3 > zone: 0 > north: 1N > south: 0 > east: 1E > west: 0 > cols: 1 > rows: 1 > e-w resol: 1 > n-s resol: 1 > top: 1 > bottom: 0 > cols3: 1 > rows3: 1 > depths: 1 > e-w resol3: 1 > n-s resol3: 1 > t-b resol: 1 > > When running d.m, it was able do display the entire map while gis.m showed > only the tiny part. (?) D.m is even more constrained by the 'computational' region. So it may have displayed fine prior to the region change. But if you tried to use d.m to display now, you'd get a 1x1 cell display. You can try this by working from the command line. ##d.mon start=x0 ##d.rast map=[your map] In the new GUI, the display region is uncoupled from the computational region. That is, you can zoom in or out in the display without changing the underlying region for gis computations. Vice versa, you can change the computational region with g.region and have no impact on the display. That said, the display region needs something to start with when you fire it up. So it starts with whatever is in your WIND file. You can change this interactively with the zoom + and - magnifying glass tools, or with the zoom pull down. Try this. Add your map as a layer in the GIS Manager. DON'T PUSH THE DISPLAY BUTTON YET Select 'zoom to selected map' from the zoom pull down in the display window. This should let you view your entire map. >From the same pull down, you can set the WIND file to match your display. Or you can use g.region to set the current region to match the map. > > I do not understand how the WIND files can change to these values. Looks > like a default setting for initialisation. While working on the dataset, I > do not remember that I changed something. > > my start setup was: > > proj: 3 > zone: 0 > north: 90N > south: 90S > east: 180E > west: 180W > cols: 7200 > rows: 3600 > e-w resol: 0:03 > n-s resol: 0:03 > top: 1 > bottom: 0 > cols3: 1 > rows3: 1 > depths: 1 > e-w resol3: 1 > n-s resol3: 1 > t-b resol: 1 This looks OK. > > It seems that more things have been modified inside the data during the > changes in g.region. The recent changes in g.region are primarily concerned with getting output of your current region settings. I don't think that anything (or much) has changed with the part that actually sets region values. > After correcting the WIND files, I still get this error message when drawing > with "Display active layers": > > region for current mapset line 7: This is weird. ****Wait a minute. I think I know what it is. ******* I've hit this too. This is a bug that I thought was fixed. If you mess with the e-w resol3 and n-s resol3 (and maybe the t-b resol), it will completely screw up your region. I *think* you can set the region to match the map and fix it. > > while g.region -p at the command line says: > > projection : 3 (Latitude-Longitude) > zone : 0 > datum : wgs84 > ellipsoid : wgs84 > north : 90N > south : 90S > west : 180W > east : 180E > nsres : 0:03 > ewres : 0:03 > rows : 3600 > cols : 7200 > cells : 25920000 > Right. This is correct, but now your WIND file is "corrupted" because a 3D resolution setting was changed. I don't think that this is a GUI problem, but a long-standing one in g.region. Well, I just tried to get this to fail with Spearfish and I was unable to do so. Maybe I didn't mess with the 3D settings in the right (i.e., wrong) way. Or maybe this is fixed and I don't know what is causing your problem. But just out of curiosity, did you change the 3D resolution or top/bottom settings in any way? > This is very confusing to me, as graphic screens die instantly without > further notice. Is there a way to run gis.m inside a debugger? It is possible if you have a TclTk debugger. > > spearfish data as new installed work. It is some kind of inbreeding when > working only on this data set. I used > http://grass.itc.it/newsletter/GRASS_OSGeo_News_vol4-usermap.pdf example. > > And I do not understand why the data exchange over the modules is not > encapsulated. Would be more than helpful for grass 7 to become free of the > position of values inside a text stream - as we have seen... ;-) Not sure what you mean here. Hope this helps. > > > > Mit freundlichen Gr??en / With kindest regards > > Stefan Paulick > > > http://www.urbeli.com > mailto://stefan.paulick@urbeli.com > /*----------------------*/ > > > > > > Michael Barton schrieb: > >> Paulick, >> >> Questions are not a nuisance. I just can't answer all of them ;-) >> >> I have to ask you one. This looks like you are trying to run from the >> command line. Is this the case? Are the errors being reported to the >> terminal? Or is this summarized from the GUI response? (i.e., it is not a >> TclTk error format). >> >> One thing that you can do to help isolate the issue is try it with the >> Spearfish demo set. If all works with that, there is something problematic >> with your data probably. If it fails with Spearfish too, that suggests a >> problem with some part of the program. >> >> Also, given the error you have below, I'd trying running g.region -up to see >> what you get for extents, resolution, etc. The map may be fine, but your >> region may be problematic. One message below is worrisome. It says that you >> have the east-west resolution set to 0. >> >> Michael >> >> >> On 1/3/07 10:58 AM, "Paulick Consult" wrote: >> >>> Michael Barton schrieb: >>> >>>> I've fixed the issues that arose from the changes to g.region and committed >>>> the updates to the cvs. >>> >>> Yes, it is working again. Thank you very much! >>> >>> At the risk of being a nuisance: d.rast map=k1 -o fails on a known good map >>> as following: >>> >>> PNG: GRASS_TRUECOLOR status: TRUE >>> PNG: collecting to file: >>> /home/grassdata/grassuser/user/.tmp/ucon643/24892.0.ppm, >>> GRASS_WIDTH=642, GRASS_HEIGHT=465 >>> >>> region for current mapset line 7: >>> run "g.region" >>> >>> >>> >>> >>> Mit freundlichen Gr??en / With kindest regards >>> >>> Stefan Paulick >>> >>> >>> http://www.urbeli.com >>> mailto://stefan.paulick@urbeli.com >>> /*----------------------*/ >>> >> >> __________________________________________ >> Michael Barton, Professor of Anthropology >> School of Human Evolution & Social Change >> Center for Social Dynamics & Complexity >> Arizona State University >> >> phone: 480-965-6213 >> fax: 480-965-7671 >> www: http://www.public.asu.edu/~cmbarton >> >> > > __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From landa.martin at gmail.com Thu Jan 4 09:28:55 2007 From: landa.martin at gmail.com (Martin Landa) Date: Thu Jan 4 09:28:58 2007 Subject: [GRASS-dev] g.region print flags combination In-Reply-To: <459AA777.40504@o2.pl> References: <22A5FE4C-7F65-4E87-A823-0900E5D414CF@unity.ncsu.edu> <45994A35.5070805@o2.pl> <459A8DB3.6030205@o2.pl> <459AA777.40504@o2.pl> Message-ID: Hi all, I would like to summarize all complication with the new behaviour of g.region. I would like also to ask you some question, to fix and close this issue finally;-) 1) The -g flag can be used in combination with all print flags, e.g. g.region -cg I think it is without problem. There was idea to add a new flag for shell script style. I hope it is possible to use the -g flag for this work as well. 2) It is possible to mix print flags, e.g. g.region -pc or for parsable output g.region -pcg There should not be any problem. 3) The -p flag was changed. projection: 99 (Krovak) zone: 0 datum: towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56 -> projection : 99 (Krovak) zone : 0 datum : towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56 Not sure what formatting is more appropriate. 4) g.region -g X g.region -pg --- I wanted to make -g flag more universal, e.g. to distinguish g.region -pcl g.region -cl and g.region -pclg instead of g.region -gcl <-- problem g.region -gcl <-- problem The question of the warning in `g.region -g` -- it can be printed at the end of the output or removed. 5) New lines in shell script style output, I think this modification can be done in 6.x branch. These lines can be added to the end of the output for backward compability -- OK? Thanks for feedback! Regards, Martin 2007/1/2, Maciej Sieczka : > Martin Landa wrote: > > > 2007/1/2, Maciej Sieczka : > > > >> "g.region -g" works OK now, but it prints a WARNING message on the top. > >> It also prints few extra lines, compared to before, namely: > >> > >> projection=1 > >> zone=34 > >> datum=wgs84 > >> ellipsoid=wgs84 > >> > >> Your WARNING message is correct and desired, as well as the extra info > >> is usefull, but those several additional lines might brake some user's > >> scripts. > > > > So should I disable this warning, right? > > I guess so. But somebody more knowledgable should decide. > > > I think the additional lines would not break any scripts, which parse > > `g.region -g` output in a reasonable way (eval, awk) (?). > > Those extra lines might brake all scripts that don't use eval, I > suppose. Eg. parsing with awk by line number will fail now: > > # grab the current region settings > g.region -g > $TMP.${PROG}.region > > # extract variables from the grabbed region > north=`awk 'BEGIN {FS="="} (NR==1) {print $2}' $TMP.${PROG}.region` > south=`awk 'BEGIN {FS="="} (NR==2) {print $2}' $TMP.${PROG}.region` > west=`awk 'BEGIN {FS="="} (NR==3) {print $2}' $TMP.${PROG}.region` > east=`awk 'BEGIN {FS="="} (NR==4) {print $2}' $TMP.${PROG}.region` > nsres=`awk 'BEGIN {FS="="} (NR==5) {print $2}' $TMP.${PROG}.region` > ewres=`awk 'BEGIN {FS="="} (NR==6) {print $2}' $TMP.${PROG}.region` > rows=`awk 'BEGIN {FS="="} (NR==7) {print $2}' $TMP.${PROG}.region` > cols=`awk 'BEGIN {FS="="} (NR==8) {print $2}' $TMP.${PROG}.region` > > Is that "reasonable" I don't know, but it used to work with g.region -g > before your recent changes, and now it fails, because top 4 lines of > g.region -g output are different now. > > I personally don't care too much, I have fixed my script to use eval, > but what with other users? > > I absolutely agree you are doing a Good Thing fixing g.region -g as you > do, but I'm affraid it should wait till GRASS 7, for legacy reasons. > > Maciek > -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From landa.martin at gmail.com Thu Jan 4 11:42:35 2007 From: landa.martin at gmail.com (Martin Landa) Date: Thu Jan 4 11:42:38 2007 Subject: [GRASS-dev] ps.map fprintf -> G_ In-Reply-To: <20070103165026.GB6831@localdomain> References: <20070103165026.GB6831@localdomain> Message-ID: Hi Jachym, 2007/1/3, Jachym Cepicky : > Hi, > nice job, thanks for the patch, but when I'm thinking about it, ... > > this patch makes ps.map set it's verbosity not by the --quiet > or --verbose flags, but also according to the input configuration file. Right, this patch allows to set verbosity level by the --q/v flag or by verbose mapping instruction. > imho, the simplest solution should be, remove the VERBOSE keyword from > ps.map. It would not harm to anythink. I doubt, some people are parsing Not sure, it would break backward compatibility. OK, maybe the verbose instruction should be removed later, now just printing appropriate warning about it. There is also question about priority: the --q/v flag should overwrite the mapping instruction or not? > output from ps.map in their scripts. > > If so, G_set_verbose function is the best solution. > > What do others think? ... > Jachym Thanks for the feedback Jachym. > > On Tue, Dec 26, 2006 at 11:16:44AM +0100, Martin Landa wrote: > > Hi all, > > > > trying to change fprintf to G_message/warning/fatal_error in ps.map > > module I found one complication. There is a special mapping > > instruction --- VERBOSE. I think this instruction should overwrite > > GRASS_VERBOSE environment variable(??). There is also need to have a > > special function G_set_verbose() which allows to set a given verbosity > > level after first calling of G_verbose() fn. Please look at the patch > > (especially at verbose.c.diff). Thanks a lot. > > > > Best regards, 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 > > -- > Jachym Cepicky > e-mail: jachym.cepicky@centrum.cz > URL: http://les-ejk.cz > GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub > ----------------------------------------- > OFFICE: > Department of Geoinformation Technologies > Zemedelska 3 > 613 00, Brno > Czech Republick > e-mail: xcepicky@node.mendelu.cz > URL: http://mapserver.mendelu.cz > Tel.: +420 545 134 514 > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.3 (GNU/Linux) > > iD8DBQFFm97SyKt0uAjU4I8RAh4lAKCMce8cDJEO5Yf8Wra2msvgzAAfDwCfRraX > tGACE41v2F2Yv2UKt6AXuEI= > =2I9W > -----END PGP SIGNATURE----- > > > -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From landa.martin at gmail.com Thu Jan 4 11:47:02 2007 From: landa.martin at gmail.com (Martin Landa) Date: Thu Jan 4 11:47:04 2007 Subject: [GRASS-dev] g.list -a In-Reply-To: <1a486f560701030845j37776763m4350ff8d011d9984@mail.gmail.com> References: <17806.65476.593110.361071@cerise.gclements.plus.com> <17809.48637.726595.182177@cerise.gclements.plus.com> <1a486f560701030845j37776763m4350ff8d011d9984@mail.gmail.com> Message-ID: Hi, it is nice idea but there is one problem. The data type list is common for related modules, e.g. g.remove, g.copy, etc. It would affect them also... Martin 2007/1/3, Daniel Calvelo : > How about g.list type=any or g.list type=all? > > 2c. > > On 12/28/06, Martin Landa wrote: > > Hi, > > > > I have just one general (maybe a little bit silly;-) question. There > > are number of modules which follow this pattern: > > > > * there is one (determinative) parameter (e.g. type in g.list) > > * and the flag for all types (e.g. -a -- List all data types) > > > > I can see two distinct approaches: > > > > 1) the determinative parameter is requested > > > > -> usage: g.list -a type= > > > > This is more precise for parsing syntax of the module, I think. On the > > other hand a little bit confusing for the user. > > > > 2) the determinative parameter is not requested > > > > -> usage: g.list -a > > > > This construction is more clear for the user I hope. But it cause more > > problems for programmer -- there is a need to handle meaningless usage > > of the module, e.g. g.list -f (verbose listing). > > > > I am not sure which approach is better. > > > > Best regards, Martin > > > > 2006/12/27, Martin Landa : > > > Hi, > > > > > > 2006/12/27, Glynn Clements : > > > > > > > > Martin Landa wrote: > > > > > > > > > > > I am trying to implement the wish [1]. I found a strange construction > > > > > > > in g.list module. The -f flag (full listing) calls the external > > > > > > > program $GISBASE/etc/lister/[cell|vector]. These little programs are > > > > > > > called only in g.list -f (I think). > > > > > > > > > > > > > > I rewrote g.list without calling any external program -- i.e. I moved > > > > > > > functions from lister directory to lib/lister.c. If there are no > > > > > > > serious objections I will commit it to CVS. > > > > > > > > > > > > Don't remove the existing functionality; add a new switch for using > > > > > > your built-in lister. > > > > > > > > > > this patch does not remove any functionality (AFAIK). The only change > > > > > is: the functionality of lister (programs) is moved to lib/lister.c. I > > > > > don't see any reason why to have this functionality (the -f flag) > > > > > outside of the g.list (/etc/lister/[cell|vector]). Maybe there is a > > > > > particular reason for this construction, please let me know. Thanks! > > > > > > > > > > > The user can install lister programs for other types and/or replace > > > > existing ones. > > > > > > OK, it makes sense to me (only it's hard to imagine an user how > > > installs other lister program instead of changing the code;-) > > > > > > > The point of -f isn't so much to provide specific additional > > > > functionality, but to allow the handling to be deferred to an external > > > > program. > > > > > > You are right, I have tried to change the patch in this way, not sure > > > if I am working with child process as I should have. In any case > > > g.list works:-) > > > > > > Martin > > > > > > > -- > > > > Glynn Clements > > > > > > > > > > > > > -- > > > Martin Landa * http://gama.fsv.cvut.cz/~landa * > > > > > > > > > > > > > > > -- > > 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 > > > > > -- > -- Daniel Calvelo Aros > -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From mlennert at club.worldonline.be Thu Jan 4 14:12:23 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Thu Jan 4 14:11:05 2007 Subject: [GRASS-dev] gis.m crashes on zoom to map existing in more than one mapset Message-ID: <459CFD37.1060408@club.worldonline.be> Hi Michael, I don't know if this is just another manifestation of the changes in g.region, but gis.m crashes when I try to zoom to a map which exists in more than one mapset of the current location. To reproduce in spearfish, in mapset user1: 1) g.copy rast=bugsites@PERMANENT,bugsites (or any other raster or vector map) 2) display bugsites 3) zoom to selected map The command used in mapcanvas.tcl is g.region -ugp rast=bugsites. This gives: GRASS 6.3.cvs (spearfish60):~ > g.region -ugp rast=bugsites WARNING: 'cell/bugsites' was found in more mapsets (also found in user1). projection=1 zone=13 datum=nad27 ellipsoid=clark66 n=4928000 s=4914000 w=590000 e=609000 nsres=100 ewres=100 rows=140 cols=190 cells=26600 So I imagine that the WARNING is what causes the problem. Just as a side note: I have always found it illogical that when I work with the map in mapset user1 (or at least I think I do), the warning tells me that the map _also_ exists in user1, as if it was currently working with the one in PERMANENT. Does this mean, that being in mapset user1, and launching a command on a map that exists both in user1 and in PERMANENT makes the command work with the version in PERMANENT, or is it just a confusing formulation ? I have always worked with the idea that it is the second. Any reason for this formulation or could we change this to "map also exists in PERMANENT (or whatever _other_ mapsets than the one you are currently in)" ? Moritz From florian.kindl at uibk.ac.at Thu Jan 4 15:05:54 2007 From: florian.kindl at uibk.ac.at (Florian Kindl) Date: Thu Jan 4 15:05:56 2007 Subject: [GRASS-dev] patch: foreground color in d.rast Message-ID: <20070104140554.GB13745@uibk.ac.at> Skipped content of type multipart/mixed-------------- 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/20070104/b0e51fde/attachment.bin From paul-grass at stjohnspoint.co.uk Thu Jan 4 15:54:02 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Thu Jan 4 15:54:07 2007 Subject: [GRASS-dev] G.region bug when setting 3d resolution??? Maybe not In-Reply-To: References: Message-ID: On Wed, 3 Jan 2007, Michael Barton wrote: > On 1/3/07 10:13 PM, "Paulick Consult" wrote: > [...] >> And I do not understand why the data exchange over the modules is not >> encapsulated. Would be more than helpful for grass 7 to become free of the >> position of values inside a text stream - as we have seen... ;-) > > Not sure what you mean here. I don't think, that the problem is the way the data exchange is handled, just that gis.m should be a *little* bit more robust in its handling of the output from g.region and other commands used in a similar way to get information about the GRASS environment. My two recommendations would be: 1. Merge the output of stdout and stderr for any commands called like this, by adding "|& $env(GISBASE)/etc/grocat" to the end of the command line. Reason: This will stop Tcl bombing out completely if anything is written to stderr (a warning or message, for example). 2. Make the parsing of the command output more robust by actually checking the return value of the regexp command (or whichever other Tcl command is used to parse the output) before acting on it. Reason: If an unexpected line occurs in the output (e.g. a warning) and it isn't matched by the regexp, then it will be simply skipped over and no action will be taken. I'm willing to help with examples for these if necessary. I think improving the robustness of gis.m like this would make debugging problems with the GRASS set-up a lot easier. Paul From michael.barton at asu.edu Thu Jan 4 16:18:42 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Jan 4 16:18:54 2007 Subject: [GRASS-dev] Re: gis.m crashes on zoom to map existing in more than one mapset In-Reply-To: <459CFD37.1060408@club.worldonline.be> Message-ID: Moritz, Yes, this warning will again break the GUI. This seems like a warning that is not terribly useful. So what if a map with the same name exists in another mapset? May I suggest that the -g flag, which means print in shell *SCRIPT* format, does exactly that--print the output in a format that can easily be parsed by scripts. A warning at the beginning of output for scripting cannot easily be parsed. The warning should be for the format that is to be read by humans. Any warnings or similar messages should be surpressed in scripting output format. Even for humans, I'm not sure that this particular warning is especially useful. What is it "warning" about? The design of independent mapsets, with the option of "name@MAPSET" construction permits maps of the same name to reside in different mapsets of the same location. Michael On 1/4/07 6:12 AM, "Moritz Lennert" wrote: > Hi Michael, > > I don't know if this is just another manifestation of the changes in > g.region, but gis.m crashes when I try to zoom to a map which exists in > more than one mapset of the current location. > > To reproduce in spearfish, in mapset user1: > > 1) g.copy rast=bugsites@PERMANENT,bugsites (or any other raster or > vector map) > > 2) display bugsites > > 3) zoom to selected map > > The command used in mapcanvas.tcl is g.region -ugp rast=bugsites. This > gives: > > GRASS 6.3.cvs (spearfish60):~ > g.region -ugp rast=bugsites > WARNING: 'cell/bugsites' was found in more mapsets (also found in user1). > projection=1 > zone=13 > datum=nad27 > ellipsoid=clark66 > n=4928000 > s=4914000 > w=590000 > e=609000 > nsres=100 > ewres=100 > rows=140 > cols=190 > cells=26600 > > So I imagine that the WARNING is what causes the problem. > > Just as a side note: I have always found it illogical that when I work > with the map in mapset user1 (or at least I think I do), the warning > tells me that the map _also_ exists in user1, as if it was currently > working with the one in PERMANENT. > Does this mean, that being in mapset user1, and launching a command on a > map that exists both in user1 and in PERMANENT makes the command work > with the version in PERMANENT, or is it just a confusing formulation ? > I have always worked with the idea that it is the second. Any reason for > this formulation or could we change this to "map also exists in > PERMANENT (or whatever _other_ mapsets than the one you are currently in)" ? > > Moritz __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From paul-grass at stjohnspoint.co.uk Thu Jan 4 16:44:10 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Thu Jan 4 16:44:16 2007 Subject: [GRASS-dev] Re: gis.m crashes on zoom to map existing in more than one mapset In-Reply-To: References: Message-ID: On Thu, 4 Jan 2007, Michael Barton wrote: > scripts. A warning at the beginning of output for scripting cannot easily be > parsed. The warning should be for the format that is to be read by humans. Just to point out, a warning shouldn't really have to be easily parsed - warnings and related messages always go to stderr while only parseable output should go to stdout. It is only because of a design flaw in Tcl that we have to merge stderr and stdout, thus greatly complicating things - using most any other system for parsing the warnings wouldn't go near stdout and we wouldn't even have to worry about them. I agree that this warning in particular is an anomaly though - it has been discussed on the list before. Paul From michael.barton at asu.edu Thu Jan 4 16:45:16 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Jan 4 16:45:29 2007 Subject: [GRASS-dev] g.region print flags combination In-Reply-To: Message-ID: Martin, I support your goals in making the output from g.region more consistent and more informative. Now that everyone is communicating, I think we can all sync things. We'll have to go through scripts to make sure that they are not broken. Keeping the -g flag working by itself in the old way might make this less of an issue. If I understand this correctly, all g.region output will default to the new -p style, unless modified by the -g flag. If modified by the -g flag, it will be output in 'script' style. Here are some general principles to make 'script' style more parsable by scripts. Hopefully these can serve as guidelines for cleanup of other commands like you did with g.region. 1. All output should be in the form of [key][separator][value] 2. The [key] should be the same for a given command in 'script' format, regardless of what other modifier is used or the environment in which it is used. That is, for 'script' style, [key] should not be "e" in one setting and "east" in another. The same [key] should be formatted the same regardless of the location setting (i.e., UTM vs latlon vs XY) 3. The [separator] should be the same in ALL commands using a 'script' style output. Currently, the "=" is most widely used. It should be used in ALL commands with 'script' style output. 4. The [value] should be in the same format regardless the location environment or any other context. A script may not know a priori whether the user is in a UTM or latlon environment. In fact, it may be trying to get this information from the GRASS command. It would certainly be nice if ALL commands that accepted coordinate input could read both decimal degrees and DD:MM:SS formats. 5. There should be no spaces or other extraneous characters between [key][separator][value], or at the end or beginning of this string. 6. There should be no warnings or other extraneous text printed with 'script' format. The assumption is that script format is not designed for humans to read (although they certainly can, of course). If it fails for some reason, it should get the standard error message. for that command. I would strongly suggest getting rid of the warnings in script format for g.region. 7. The lines of output should be the same regardless of the location environment or any other context factor. R.describe is particularly problematic in this regard, making it useless for scripting. 8. I would love to have -g work the same in all information producing commands. It would making parsing r.info and v.info SO much easier. I hope this can be helpful in the future. Others who work with scripts might want to add to this also. Michael On 1/4/07 1:28 AM, "Martin Landa" wrote: > Hi all, > > I would like to summarize all complication with the new behaviour of > g.region. I would like also to ask you some question, to fix and close > this issue finally;-) > > 1) The -g flag can be used in combination with all print flags, e.g. > > g.region -cg > > I think it is without problem. There was idea to add a new flag for > shell script style. I hope it is possible to use the -g flag for this > work as well. > > 2) It is possible to mix print flags, e.g. > > g.region -pc > > or for parsable output > > g.region -pcg > > There should not be any problem. > > 3) The -p flag was changed. > > projection: 99 (Krovak) > zone: 0 > datum: towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56 > > -> > > projection : 99 (Krovak) > zone : 0 > datum : towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56 > > Not sure what formatting is more appropriate. > > 4) g.region -g X g.region -pg --- I wanted to make -g flag more > universal, e.g. to distinguish > > g.region -pcl > g.region -cl > > and > > g.region -pclg instead of g.region -gcl <-- problem > g.region -gcl <-- problem > > The question of the warning in `g.region -g` -- it can be printed at > the end of the output or removed. > > 5) New lines in shell script style output, I think this modification > can be done in 6.x branch. > > These lines can be added to the end of the output for backward > compability -- OK? > > Thanks for feedback! > > Regards, Martin > > 2007/1/2, Maciej Sieczka : >> Martin Landa wrote: >> >>> 2007/1/2, Maciej Sieczka : >>> >>>> "g.region -g" works OK now, but it prints a WARNING message on the top. >>>> It also prints few extra lines, compared to before, namely: >>>> >>>> projection=1 >>>> zone=34 >>>> datum=wgs84 >>>> ellipsoid=wgs84 >>>> >>>> Your WARNING message is correct and desired, as well as the extra info >>>> is usefull, but those several additional lines might brake some user's >>>> scripts. >>> >>> So should I disable this warning, right? >> >> I guess so. But somebody more knowledgable should decide. >> >>> I think the additional lines would not break any scripts, which parse >>> `g.region -g` output in a reasonable way (eval, awk) (?). >> >> Those extra lines might brake all scripts that don't use eval, I >> suppose. Eg. parsing with awk by line number will fail now: >> >> # grab the current region settings >> g.region -g > $TMP.${PROG}.region >> >> # extract variables from the grabbed region >> north=`awk 'BEGIN {FS="="} (NR==1) {print $2}' $TMP.${PROG}.region` >> south=`awk 'BEGIN {FS="="} (NR==2) {print $2}' $TMP.${PROG}.region` >> west=`awk 'BEGIN {FS="="} (NR==3) {print $2}' $TMP.${PROG}.region` >> east=`awk 'BEGIN {FS="="} (NR==4) {print $2}' $TMP.${PROG}.region` >> nsres=`awk 'BEGIN {FS="="} (NR==5) {print $2}' $TMP.${PROG}.region` >> ewres=`awk 'BEGIN {FS="="} (NR==6) {print $2}' $TMP.${PROG}.region` >> rows=`awk 'BEGIN {FS="="} (NR==7) {print $2}' $TMP.${PROG}.region` >> cols=`awk 'BEGIN {FS="="} (NR==8) {print $2}' $TMP.${PROG}.region` >> >> Is that "reasonable" I don't know, but it used to work with g.region -g >> before your recent changes, and now it fails, because top 4 lines of >> g.region -g output are different now. >> >> I personally don't care too much, I have fixed my script to use eval, >> but what with other users? >> >> I absolutely agree you are doing a Good Thing fixing g.region -g as you >> do, but I'm affraid it should wait till GRASS 7, for legacy reasons. >> >> Maciek >> > __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From mlennert at club.worldonline.be Thu Jan 4 16:47:25 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Thu Jan 4 16:45:43 2007 Subject: [GRASS-dev] Re: gis.m crashes on zoom to map existing in more than one mapset In-Reply-To: References: Message-ID: <459D218D.4050507@club.worldonline.be> On 04/01/07 16:18, Michael Barton wrote: > Moritz, > > Yes, this warning will again break the GUI. This seems like a warning that > is not terribly useful. So what if a map with the same name exists in > another mapset? > > May I suggest that the -g flag, which means print in shell *SCRIPT* format, > does exactly that--print the output in a format that can easily be parsed by > scripts. A warning at the beginning of output for scripting cannot easily be > parsed. The warning should be for the format that is to be read by humans. > Any warnings or similar messages should be surpressed in scripting output > format. I don't necessarily agree that warnings should not be printed in scripts. I would rather argue with Paul that scripts should be made in a way to deal with such issues more robustly. > > Even for humans, I'm not sure that this particular warning is especially > useful. What is it "warning" about? The design of independent mapsets, with > the option of "name@MAPSET" construction permits maps of the same name to > reside in different mapsets of the same location. Personally I have never found it useful, but it might be useful to some as a reminder, in order to make sure that they are really working on the map they want to work on. But then this should probably read something like: "Map exists in several mapsets. Currently working with map@XXX." Moritz > > Michael > > > On 1/4/07 6:12 AM, "Moritz Lennert" wrote: > >> Hi Michael, >> >> I don't know if this is just another manifestation of the changes in >> g.region, but gis.m crashes when I try to zoom to a map which exists in >> more than one mapset of the current location. >> >> To reproduce in spearfish, in mapset user1: >> >> 1) g.copy rast=bugsites@PERMANENT,bugsites (or any other raster or >> vector map) >> >> 2) display bugsites >> >> 3) zoom to selected map >> >> The command used in mapcanvas.tcl is g.region -ugp rast=bugsites. This >> gives: >> >> GRASS 6.3.cvs (spearfish60):~ > g.region -ugp rast=bugsites >> WARNING: 'cell/bugsites' was found in more mapsets (also found in user1). >> projection=1 >> zone=13 >> datum=nad27 >> ellipsoid=clark66 >> n=4928000 >> s=4914000 >> w=590000 >> e=609000 >> nsres=100 >> ewres=100 >> rows=140 >> cols=190 >> cells=26600 >> >> So I imagine that the WARNING is what causes the problem. >> >> Just as a side note: I have always found it illogical that when I work >> with the map in mapset user1 (or at least I think I do), the warning >> tells me that the map _also_ exists in user1, as if it was currently >> working with the one in PERMANENT. >> Does this mean, that being in mapset user1, and launching a command on a >> map that exists both in user1 and in PERMANENT makes the command work >> with the version in PERMANENT, or is it just a confusing formulation ? >> I have always worked with the idea that it is the second. Any reason for >> this formulation or could we change this to "map also exists in >> PERMANENT (or whatever _other_ mapsets than the one you are currently in)" ? From peter.loewe at gmx.de Thu Jan 4 16:48:27 2007 From: peter.loewe at gmx.de (peter.loewe@gmx.de) Date: Thu Jan 4 16:48:29 2007 Subject: [GRASS-dev] Vector weirdness @ native windows version Message-ID: <20070104154827.21340@gmx.net> v.out.ogr produces some interesting effects in the current beta version for native windows: Using Spearfish, v.out.ogr input=roads type=line,boundary dsn=. olayer=roads_out layer=1 format=ESRI_Shapefile gets stuck after a black window ist produced by C:/msys/1.0/local/grass\driver\db\dbf.exe [btw the combination of slashes and backslashes is NOT a typo.] This happens only when v.out.ogr is accessed through its GUI. When called up entirely from the command line, it gets stuck at "13%". Does anybody know of a workaround for this ? Peter -- Dr. Peter L?we Diplom-Geograph Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal f?r Modem und ISDN: http://www.gmx.net/de/go/smartsurfer From michael.barton at asu.edu Thu Jan 4 17:11:30 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Jan 4 17:11:38 2007 Subject: [GRASS-dev] G.region bug when setting 3d resolution??? Maybe not In-Reply-To: Message-ID: Hi Paul, A few thoughts below. On 1/4/07 7:54 AM, "Paul Kelly" wrote: > > I don't think, that the problem is the way the data exchange is handled, > just that gis.m should be a *little* bit more robust in its handling of > the output from g.region and other commands used in a similar way to get > information about the GRASS environment. My two recommendations would be: I agree about finding ways to increase the robusticity of the GUI. The more it is used, the more robust it needs to be. And the more robust it is, the more it will be used. While specific errors can be trapped if they can be reliably anticipated, the general TclTk form for error-trapping is the catch command. It is widely used in the GUI, but could be used in a more sophisticated way to trap and report errors. TclTk actually does a pretty good job of catching and reporting errors, returning real information rather than codes. However, it would better if users could be spared TclTk errors as much as possible. > > 1. Merge the output of stdout and stderr for any commands called like > this, by adding "|& $env(GISBASE)/etc/grocat" to the end of the command > line. > Reason: This will stop Tcl bombing out completely if anything is written > to stderr (a warning or message, for example). I think some other solution would be better for two reasons. First, this construction calls a *nix command from within TclTk. This is problematic for Windows. A pure TclTk construction would be better. Second, in the most recent set of problems with g.region, I'm not sure if this would help all that much anyway. The GUI was reading the text output from g.region -g OK, the problem is that it was the wrong output. It was expecting [key]=[value]. The first [key] included the warning message. This gave a key that was not recognizable by the subsequent routine that tried to process the key to get region values. For this particular routine, a 'catch' command is already in place to trap real errors and move on. In fact, an error will cause the GUI to quit relatively gracefully with the GRASS error printed to the terminal. I implemented this, working with Hamish to solve a recurrent problem that caused the GUI to give somewhat misleading error messages when GRASS was improperly installed (usually a gdal installation problem). This construction probably needs to be used more widely as we identify potential problem spots. Maybe it is useful wherever a GRASS command is run. If you have any suggestions or want to check through the code for places you see as potentially problematic, we can try to beef them up. > > 2. Make the parsing of the command output more robust by actually checking > the return value of the regexp command (or whichever other Tcl command is > used to parse the output) before acting on it. > Reason: If an unexpected line occurs in the output (e.g. a warning) and it > isn't matched by the regexp, then it will be simply skipped over and no > action will be taken. This is a good plan if you know what return value you are expecting. In some places this makes a lot of sense. It is implemented in some places, but could probably be expanded. It would be worthwhile to identify such spots. In this particular case, however, g.region produces a lot of possible return [key][separator][value] lines. The TclTk routine loops through all of them and puts them into a list that it later uses for all sorts of things. I'm not sure if it's efficient to check each line against all possible valid g.region outputs. The loop read the output 'correctly', it just got output that was subsequently unusable. Moreover, the new warning is in a difficult to parse location for reading information. IMHO, it should not be there for 'script' style output. > > I'm willing to help with examples for these if necessary. I think > improving the robustness of gis.m like this would make debugging problems > with the GRASS set-up a lot easier. Thanks. This would be very much appreciated. Now that the GUI code is itself is pretty robust, if we can identify the most likely spots that can result in crashes when there are other problems, and solve these with pure TclTk methods (i.e., cross-platform) it will make for a much better piece of software. Michael > > Paul > > > > __________________________________________ 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 Thu Jan 4 17:23:45 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Jan 4 17:24:15 2007 Subject: [GRASS-dev] Re: gis.m crashes on zoom to map existing in more than one mapset In-Reply-To: <459D218D.4050507@club.worldonline.be> Message-ID: On 1/4/07 8:47 AM, "Moritz Lennert" wrote: Moritz and Paul, The following construction will trap errors in TclTk, but it doesn't help this particular issue. if {![catch {open [concat "|g.region" "-ugp" $args] r} input]} { while {[gets $input line] >= 0} { regexp -nocase {^([a-z]+)=(.*)$} $line trash key value set parts($key) $value } .... If there if no error, "catch" returns 0 and the routine goes on. If there is an error, "catch" returns a value >0 and the error message is stored in the variable "input". Input can be printed to the terminal or to a TclTk dialog if desired. This is trapping errors fine as far as I can tell. Try getting rid of libgdal (which produces an error if you run g.region) and running the GUI. It will exit with a message to the terminal. In this case, the warning in g.region -g seems to be part of the command output rather than a valid error message. I don't know why. Michael > On 04/01/07 16:18, Michael Barton wrote: >> Moritz, >> >> Yes, this warning will again break the GUI. This seems like a warning that >> is not terribly useful. So what if a map with the same name exists in >> another mapset? >> >> May I suggest that the -g flag, which means print in shell *SCRIPT* format, >> does exactly that--print the output in a format that can easily be parsed by >> scripts. A warning at the beginning of output for scripting cannot easily be >> parsed. The warning should be for the format that is to be read by humans. >> Any warnings or similar messages should be surpressed in scripting output >> format. > > I don't necessarily agree that warnings should not be printed in > scripts. I would rather argue with Paul that scripts should be made in a > way to deal with such issues more robustly. > >> >> Even for humans, I'm not sure that this particular warning is especially >> useful. What is it "warning" about? The design of independent mapsets, with >> the option of "name@MAPSET" construction permits maps of the same name to >> reside in different mapsets of the same location. > > Personally I have never found it useful, but it might be useful to some > as a reminder, in order to make sure that they are really working on the > map they want to work on. But then this should probably read something > like: "Map exists in several mapsets. Currently working with map@XXX." > > Moritz > >> __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From paul-grass at stjohnspoint.co.uk Thu Jan 4 17:42:22 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Thu Jan 4 17:42:27 2007 Subject: [GRASS-dev] Re: gis.m crashes on zoom to map existing in more than one mapset In-Reply-To: References: Message-ID: Hello Michael On Thu, 4 Jan 2007, Michael Barton wrote: > On 1/4/07 8:47 AM, "Moritz Lennert" wrote: > > Moritz and Paul, > > The following construction will trap errors in TclTk, but it doesn't help > this particular issue. > > if {![catch {open [concat "|g.region" "-ugp" $args] r} input]} { > while {[gets $input line] >= 0} { > regexp -nocase {^([a-z]+)=(.*)$} $line trash key value > set parts($key) $value > } > .... > > If there if no error, "catch" returns 0 and the routine goes on. > If there is an error, "catch" returns a value >0 and the error message is > stored in the variable "input". Input can be printed to the terminal or to a > TclTk dialog if desired. Try this instead: if {![catch {open [concat "|g.region" "-ugp" $args "|& $env(GISBASE)/etc/grocat"] r} input]} { while {[gets $input line] >= 0} { if { [regexp -nocase {^([a-z]+)=(.*)$} $line trash key value] } { set parts($key) $value } } I am guessing that "catch" catches errors by seeing if anything is written to stderr - if a warning is written to stderr will it incorrectly catch it as an error? I'm not sure, but merging stderr into stdout with the grocat program will stop anything being written to stderr so will stop this. This will work on Windows - in fact I wrote it specifically because the previous way it was done (see my recent changes to lib/gtcltk/gronsole.tcl) was Unix-specific - the grocat trick works on Unix and Windows. Then within the while loop I've used an if to check the return value of regexp - there are only two possible values - 1 if it matches the line and 0 if it doesn't. So it won't match the Warning line, will return 0, and thus stops you trying to assign non-existent values to key and value. Paul From tutey at o2.pl Thu Jan 4 18:54:49 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Thu Jan 4 18:54:52 2007 Subject: [GRASS-dev] g.region print flags combination In-Reply-To: References: <22A5FE4C-7F65-4E87-A823-0900E5D414CF@unity.ncsu.edu> <45994A35.5070805@o2.pl> <459A8DB3.6030205@o2.pl> <459AA777.40504@o2.pl> Message-ID: <459D3F69.3040500@o2.pl> Martin Landa wrote: > Hi all, > > I would like to summarize all complication with the new behaviour of > g.region. I would like also to ask you some question, to fix and close > this issue finally;-) > > 1) The -g flag can be used in combination with all print flags, e.g. > > g.region -cg > > I think it is without problem. There was idea to add a new flag for > shell script style. I hope it is possible to use the -g flag for this > work as well. > > 2) It is possible to mix print flags, e.g. > > g.region -pc > > or for parsable output > > g.region -pcg > > There should not be any problem. > > 3) The -p flag was changed. > > projection: 99 (Krovak) > zone: 0 > datum: towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56 > > -> > > projection : 99 (Krovak) > zone : 0 > datum : towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56 > > Not sure what formatting is more appropriate. > > 4) g.region -g X g.region -pg --- I wanted to make -g flag more > universal, e.g. to distinguish > > g.region -pcl > g.region -cl > > and > > g.region -pclg instead of g.region -gcl <-- problem > g.region -gcl <-- problem > > The question of the warning in `g.region -g` -- it can be printed at > the end of the output or removed. > > 5) New lines in shell script style output, I think this modification > can be done in 6.x branch. > > These lines can be added to the end of the output for backward > compability -- OK? Really cannot it wait for GRASS 7? I'm just kind of uneasy about it. What if somebody eg. counts the number of lines in g.region -g output for his mysterious, unknow to us, purpose, and he gets extra 4 lines? This might sound funny ;), but it won't be funny anymore if it is real. You never know. Better to stick to the safe side I think. Wait, another thought - WHY should g.region print the projection info, either in -p or -pg mode, *anyway*? Isn't ther g.proj -p for that? Doubled functionality per se (if we also consider r.info which prints the projection info too - a trippled fuctionality). So shouldn't this wait for GRASS 7, where printing the projection info will be left for g.proj [1] alone, and removed from g.region and r.info for good? And for now, in GRASS 6, leave it as it was before - not perfect, but 100% backwards compatible at least. Let's leave cleaning it all up together for GRASS 7. Am I thinking any good? Paul? [1] propably the g.proj -j output should be extended to include all the information output by g.proj -p, or a new "-g" flag should be introduced, to be used in conjunction with "-p" for parseable output. Maciek From paul-grass at stjohnspoint.co.uk Thu Jan 4 19:54:12 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Thu Jan 4 19:54:14 2007 Subject: [GRASS-dev] g.region print flags combination In-Reply-To: <459D3F69.3040500@o2.pl> References: <22A5FE4C-7F65-4E87-A823-0900E5D414CF@unity.ncsu.edu> <45994A35.5070805@o2.pl> <459A8DB3.6030205@o2.pl> <459AA777.40504@o2.pl> <459D3F69.3040500@o2.pl> Message-ID: Hello Maciek On Thu, 4 Jan 2007, Maciej Sieczka wrote: > Wait, another thought - WHY should g.region print the projection info, > either in -p or -pg mode, *anyway*? Isn't ther g.proj -p for that? > Doubled functionality per se (if we also consider r.info which prints > the projection info too - a trippled fuctionality). So shouldn't this > wait for GRASS 7, where printing the projection info will be left for > g.proj [1] alone, and removed from g.region and r.info for good? And > for now, in GRASS 6, leave it as it was before - not perfect, but 100% > backwards compatible at least. Let's leave cleaning it all up together > for GRASS 7. Am I thinking any good? Paul? I think: g.region should print only information it gets from the WIND file r.info should print only information it gets from the raster header file g.proj -p should only print information it gets from the PROJ_INFO and PROJ_UNITS files. Yes the WIND and yes the raster header include some projection information - that is an historical thing. We shouldn't try to hide it though, because there are bits of the code that check it and it is still useful in a few circumstances. But I don't think extra stuff like the projection name from PROJ_INFO in brackets, ellps or datum should be there. It is confusing as these are being taken from a different source. The projection name reported should be one of the 5 original ones defined: XY, UTM, State Plane, Latitude-Longitude or Other, corresponding to codes 0,1,2,3 or 99 in the WIND file. r.info should continue to report the projection information that is in the raster header - it causes problems if it is not the same as the location so it is important to report it just in case. But again (I don't know if it does) it should not report anything from the PROJ_INFO file. > [1] > propably the g.proj -j output should be extended to include all the > information output by g.proj -p, or a new "-g" flag should be > introduced, to be used in conjunction with "-p" for parseable output. Hmm, if you think it might be useful. I'm not sure. The function of g.proj -j is to produce a PROJ.4-compatible output. This is slightly different from that you see with g.proj -p with colons replaced by = signs. I'm not sure how useful g.proj -pg would be as AFAIK only proj, unit, units and meters are the only fields *guaranteed* to be present. There are many different ways to specify a PROJ_INFO file, unlike a WIND file where all the parameters have to be there and have to have a value. The two aren't really analogous IMHO. So that's what I think :) Paul From tutey at o2.pl Thu Jan 4 20:21:11 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Thu Jan 4 20:21:16 2007 Subject: [GRASS-dev] g.region print flags combination In-Reply-To: References: <22A5FE4C-7F65-4E87-A823-0900E5D414CF@unity.ncsu.edu> <45994A35.5070805@o2.pl> <459A8DB3.6030205@o2.pl> <459AA777.40504@o2.pl> <459D3F69.3040500@o2.pl> Message-ID: <459D53A7.6020803@o2.pl> Paul Kelly wrote: > Hello Maciek > > On Thu, 4 Jan 2007, Maciej Sieczka wrote: > >> Wait, another thought - WHY should g.region print the projection info, >> either in -p or -pg mode, *anyway*? Isn't ther g.proj -p for that? >> Doubled functionality per se (if we also consider r.info which prints >> the projection info too - a trippled fuctionality). So shouldn't this >> wait for GRASS 7, where printing the projection info will be left for >> g.proj [1] alone, and removed from g.region and r.info for good? And >> for now, in GRASS 6, leave it as it was before - not perfect, but 100% >> backwards compatible at least. Let's leave cleaning it all up together >> for GRASS 7. Am I thinking any good? Paul? > > I think: > g.region should print only information it gets from the WIND file > r.info should print only information it gets from the raster header file > g.proj -p should only print information it gets from the PROJ_INFO and > PROJ_UNITS files. And I think :): - g.region: should print region extent, *only* - r.info: print only the given raster layer info, *exluding* projection ifno - you can't have (normally) a raster inside a given GRASS location, that has a projection different from the location's projection it is in, can you? - g.proj: print all the info relevant to the projection of the current working location > Yes the WIND and yes the raster header include some projection > information - that is an historical thing. We shouldn't try to hide it > though, because there are bits of the code that check it and it is still > useful in a few circumstances. What circumstances, ecxactly (sorry, I really don't know). > But I don't think extra stuff like the > projection name from PROJ_INFO in brackets, ellps or datum should be > there. It is confusing as these are being taken from a different source. > The projection name reported should be one of the 5 original ones > defined: XY, UTM, State Plane, Latitude-Longitude or Other, > corresponding to codes 0,1,2,3 or 99 in the WIND file. Hmm, I think g.proj -p should report the projection name as good as it can, given the available data. 'Other' doesn't mean much (there are dozens of projections other than UTM and State Plane). Maciek > r.info should continue to report the projection information that is in > the raster header - it causes problems if it is not the same as the > location so it is important to report it just in case. How can a raster's projection inside a location be different than the location's projection? > But again (I don't know if it does) it should not report anything from the PROJ_INFO > file. >> [1] >> propably the g.proj -j output should be extended to include all the >> information output by g.proj -p, or a new "-g" flag should be >> introduced, to be used in conjunction with "-p" for parseable output. > > Hmm, if you think it might be useful. I'm not sure. The function of > g.proj -j is to produce a PROJ.4-compatible output. Right. But it doesn't print the units information, which is present in PROJ.4-compatible output of eg. "epsg_tr.py -proj4 ". Shouldn't then g.proj -j include the units info too? > This is slightly > different from that you see with g.proj -p with colons replaced by = > signs. I'm not sure how useful g.proj -pg would be as AFAIK only proj, > unit, units and meters are the only fields *guaranteed* to be present. > > There are many different ways to specify a PROJ_INFO file, unlike a WIND > file where all the parameters have to be there and have to have a value. > The two aren't really analogous IMHO. > > So that's what I think :) Thanks! I hope together we can know a bit more :). Maciek From michael.barton at asu.edu Thu Jan 4 21:35:18 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Jan 4 21:35:28 2007 Subject: [GRASS-dev] Re: gis.m crashes on zoom to map existing in more than one mapset In-Reply-To: Message-ID: Paul On 1/4/07 9:42 AM, "Paul Kelly" wrote: > Hello Michael > > On Thu, 4 Jan 2007, Michael Barton wrote: > >> On 1/4/07 8:47 AM, "Moritz Lennert" wrote: >> >> Moritz and Paul, >> >> The following construction will trap errors in TclTk, but it doesn't help >> this particular issue. >> >> if {![catch {open [concat "|g.region" "-ugp" $args] r} input]} { >> while {[gets $input line] >= 0} { >> regexp -nocase {^([a-z]+)=(.*)$} $line trash key value >> set parts($key) $value >> } >> .... >> >> If there if no error, "catch" returns 0 and the routine goes on. >> If there is an error, "catch" returns a value >0 and the error message is >> stored in the variable "input". Input can be printed to the terminal or to a >> TclTk dialog if desired. > > Try this instead: > if {![catch {open [concat "|g.region" "-ugp" $args "|& > $env(GISBASE)/etc/grocat"] r} input]} { > while {[gets $input line] >= 0} { > if { [regexp -nocase {^([a-z]+)=(.*)$} $line trash key value] } > { > set parts($key) $value > } > } I can confirm that this works. What is grocat?? > > I am guessing that "catch" catches errors by seeing if anything is written > to stderr - if a warning is written to stderr will it incorrectly catch it > as an error? Yes, this is what seems to be happening. The program exits with the warning printed to the terminal. > I'm not sure, but merging stderr into stdout with the grocat > program will stop anything being written to stderr so will stop this. This > will work on Windows - in fact I wrote it specifically because the > previous way it was done (see my recent changes to > lib/gtcltk/gronsole.tcl) was Unix-specific - the grocat trick works on > Unix and Windows. OK. If you've tested this on Windows, then it should be OK. I'm just trying not to do anything that will jeopardize a native Windows build. > > Then within the while loop I've used an if to check the return value of > regexp - there are only two possible values - 1 if it matches the line and > 0 if it doesn't. So it won't match the Warning line, will return 0, and > thus stops you trying to assign non-existent values to key and value. OK. This works fine too. Thanks. After fixing stuff yesterday, I was thinking it might be simpler to switch to set key [string trim [lindex [split $line "="] 0]] I wonder if this could be made to test in a similar way? Thanks for your help. Michael > > Paul > __________________________________________ 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 mlennert at club.worldonline.be Thu Jan 4 22:18:41 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Thu Jan 4 22:16:59 2007 Subject: [GRASS-dev] Re: gis.m crashes on zoom to map existing in more than one mapset In-Reply-To: References: Message-ID: <48814.85.10.64.49.1167945521.squirrel@geog-pc40.ulb.ac.be> On Thu, January 4, 2007 21:35, Michael Barton wrote: > Paul > > > On 1/4/07 9:42 AM, "Paul Kelly" wrote: > >> Hello Michael >> >> On Thu, 4 Jan 2007, Michael Barton wrote: >> >>> On 1/4/07 8:47 AM, "Moritz Lennert" >>> wrote: >>> >>> Moritz and Paul, >>> >>> The following construction will trap errors in TclTk, but it doesn't >>> help >>> this particular issue. >>> >>> if {![catch {open [concat "|g.region" "-ugp" $args] r} input]} { >>> while {[gets $input line] >= 0} { >>> regexp -nocase {^([a-z]+)=(.*)$} $line trash key value >>> set parts($key) $value >>> } >>> .... >>> >>> If there if no error, "catch" returns 0 and the routine goes on. >>> If there is an error, "catch" returns a value >0 and the error message >>> is >>> stored in the variable "input". Input can be printed to the terminal or >>> to a >>> TclTk dialog if desired. >> >> Try this instead: >> if {![catch {open [concat "|g.region" "-ugp" $args "|& >> $env(GISBASE)/etc/grocat"] r} input]} { >> while {[gets $input line] >= 0} { >> if { [regexp -nocase {^([a-z]+)=(.*)$} $line trash key >> value] } >> { >> set parts($key) $value >> } >> } > > I can confirm that this works. What is grocat?? A small program that Paul wrote. Here's the description from the source file: * PURPOSE: Copies stdin to stdout in line-buffered mode until end * of file is received. * Used with Tcl/Tk gronsole system to merge stdout and * stderr streams to be caught by Tcl "open" command. > > OK. If you've tested this on Windows, then it should be OK. I'm just > trying > not to do anything that will jeopardize a native Windows build. I think as the main developer working on the Win port we can trust Paul to have the same worries ;-) Moritz From cedricgrass at shockfamily.net Fri Jan 5 01:41:53 2007 From: cedricgrass at shockfamily.net (Cedric Shock) Date: Fri Jan 5 01:43:15 2007 Subject: [GRASS-dev] TCL/TK GUI development questions answered In-Reply-To: References: Message-ID: <200701041641.54123.cedricgrass@shockfamily.net> Michael, > > Here's a quick one (I think). How do I 'break into' gronsole in order to > send some information there? What I want to do is the following. I've > already set up bindings on the points to store the current xy geographic > coordinates to a variable each time you click on a display with a mouse. > I'd just like to be able to send this information to the gronsole. This is > a wish someone made sometime back and it seems like a good idea. But in my > initial look at the gronsole code, it was unclear to me where I could > insert this information in order for it to be displayed. This one I can handle. Short answer in gis.m (these are implemented at the bottom of runandoutput.tcl): Say we start clicking and want to print a list of points. set handle [monitor_annotation_start $mon "Click Lister Tool" [list gism]] Then later when someone clicks we'd do this to add the location to the list: monitor_annotate $handle "$x $y \n" (pardon me if that isn't really variable substitution in a string and a newline, I've been a while from tcl/tk) If we have a little icon for the tool (status-clicktool.gif), we can add it to the horizontal bar like so. I've also taken the liberty of lifting the title string for translation: set handle [monitor_annotation_start $mon [G_msg "Click Lister Tool"] [list gism clicktool]] ($mon is that annoying monitor variable, it's not used in the current implementation...) This extra abstraction is probably preferred for all of gis.m. The long answer is... There are two gronsole methods, annotate and annotate_text. Annotate makes a new program header, and annotate_text adds fake output. Assuming that $gronsole is a path command of a gronsole then you can do things like this: set handle [$gronsole annotate [G_msg "Click Lister Tool"] [list gism clicktool running] $gronsole set_click_command $handle {} The second command makes clicking on the horizontal bar do nothing (instead of recalling the command so it can be run again, which makes no sense here) Then when you get clicks you can: $gronsole annotate_text $handle "$x $y \n" And then when the tool's use is discontinued you can $gronsole remove_tag $handle running $gronsole add_tag $handle success These behaviours could be easily wrapped up in runandoutput.tcl if they are needed. > > On the other hand, in general, I'm trying to wind down the new features for > the TclTk GUI and make sure it is robust and stable so that it can hang > around for a year or so with only minor maintenance. That should give us > all a chance to start working on the new wxPython GUI in earnest. Because > of looming health issues that may make my contributions sporadic for > awhile, I've sent my current wxPython files to Jachym Cepicky, who can > coordinate these efforts for awhile. I hope you are interested in > contributing. > > The current remaining work on TclTk involves trying to improve the startup. > I've done a lot of fixing to the EPSG startup. I'm waiting on changes to > g.proj to do the same with the georeferenced file part. The code for the > main startup screen is nearly prehistoric, making it difficult to work > with. It needs more improvements, but I'm not sure how much is worth it. > > The other thing is bringing NVIZ up to date. I've done a lot on that front > lately. Most of it is done--at least cosmetically. The code structure is > pretty out of date, but I've fixed the worst of it. Like the entry panels, > NVIZ generally lacks namespace definitions and has far too many globals, > which cause a number of problems. But it would be an enormous task to > rewrite all the procedures to respect local namespaces. I was working with > Hamish Bowman and Bob Covill to improve the north arrow and scale tools. We > are almost there, needing some additional C-coding and debugging to make > the font setting work. Also need to improve the looks of the scale and the > spatial relationships between arrow/"N" and scale/key. The TclTk part is > virtually done, with stubbed variables awaiting Bob. Finally, the advanced > animation panel (formerly misnamed as keyframe animation--both are keyframe > animation) is semi-broken. The code is a mess. I managed to untangle it all > and make it work pretty nice in the simple animation panel, but haven't had > time to fight my way through the other panel. It seemed to me, when I discontinued active development this summer, that the next obvious direction would be a unified layer compositing (2D) and on-mesh display system (3D), for use both as a gui component and as an output method. I had some ideas, and played around a bit with pygame (for OpenGL), but I had neither the time nor the hardware to pursue it. If anyone has an excuse to hire me and a machine with a graphics accelerator I'd be thrilled to develop a new grass gui. > > So if any of these items seem like an enjoyable challenge, dig in. Maybe > let me know what you're up to so that we don't work at cross-purposes. All > the best. Hopping over to the grass list, Cedric From landa.martin at gmail.com Fri Jan 5 09:06:20 2007 From: landa.martin at gmail.com (Martin Landa) Date: Fri Jan 5 09:06:22 2007 Subject: [GRASS-dev] g.region print flags combination In-Reply-To: <459AA777.40504@o2.pl> References: <22A5FE4C-7F65-4E87-A823-0900E5D414CF@unity.ncsu.edu> <45994A35.5070805@o2.pl> <459A8DB3.6030205@o2.pl> <459AA777.40504@o2.pl> Message-ID: Hi, I have modified g.region: 1) the warning (g.region -g) is disabled 2) g.region -g (or g.region -pg) prints the same lines as before In the result there still small minor consistency g.region -g -> g.region -pg g.region -gcl is not the same as g.region -pgcl So -g[3] == -pg[3] only without other print flags. add 2) I am still thinking that these kind of changes (i.e. different number of lines in g.region -g) can be done in 6.x. In G7.x should be cleaned the connection between g.region + g.proj + [r|v].info as Paul suggested. Best regards, Martin 2007/1/2, Maciej Sieczka : > Martin Landa wrote: > > > 2007/1/2, Maciej Sieczka : > > > >> "g.region -g" works OK now, but it prints a WARNING message on the top. > >> It also prints few extra lines, compared to before, namely: > >> > >> projection=1 > >> zone=34 > >> datum=wgs84 > >> ellipsoid=wgs84 > >> > >> Your WARNING message is correct and desired, as well as the extra info > >> is usefull, but those several additional lines might brake some user's > >> scripts. > > > > So should I disable this warning, right? > > I guess so. But somebody more knowledgable should decide. > > > I think the additional lines would not break any scripts, which parse > > `g.region -g` output in a reasonable way (eval, awk) (?). > > Those extra lines might brake all scripts that don't use eval, I > suppose. Eg. parsing with awk by line number will fail now: > > # grab the current region settings > g.region -g > $TMP.${PROG}.region > > # extract variables from the grabbed region > north=`awk 'BEGIN {FS="="} (NR==1) {print $2}' $TMP.${PROG}.region` > south=`awk 'BEGIN {FS="="} (NR==2) {print $2}' $TMP.${PROG}.region` > west=`awk 'BEGIN {FS="="} (NR==3) {print $2}' $TMP.${PROG}.region` > east=`awk 'BEGIN {FS="="} (NR==4) {print $2}' $TMP.${PROG}.region` > nsres=`awk 'BEGIN {FS="="} (NR==5) {print $2}' $TMP.${PROG}.region` > ewres=`awk 'BEGIN {FS="="} (NR==6) {print $2}' $TMP.${PROG}.region` > rows=`awk 'BEGIN {FS="="} (NR==7) {print $2}' $TMP.${PROG}.region` > cols=`awk 'BEGIN {FS="="} (NR==8) {print $2}' $TMP.${PROG}.region` > > Is that "reasonable" I don't know, but it used to work with g.region -g > before your recent changes, and now it fails, because top 4 lines of > g.region -g output are different now. > > I personally don't care too much, I have fixed my script to use eval, > but what with other users? > > I absolutely agree you are doing a Good Thing fixing g.region -g as you > do, but I'm affraid it should wait till GRASS 7, for legacy reasons. > > Maciek > -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From paul-grass at stjohnspoint.co.uk Fri Jan 5 11:57:16 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Fri Jan 5 11:57:19 2007 Subject: [GRASS-dev] g.region print flags combination In-Reply-To: <459D53A7.6020803@o2.pl> References: <22A5FE4C-7F65-4E87-A823-0900E5D414CF@unity.ncsu.edu> <45994A35.5070805@o2.pl> <459A8DB3.6030205@o2.pl> <459AA777.40504@o2.pl> <459D3F69.3040500@o2.pl> <459D53A7.6020803@o2.pl> Message-ID: On Thu, 4 Jan 2007, Maciej Sieczka wrote: > Paul Kelly wrote: >> Yes the WIND and yes the raster header include some projection >> information - that is an historical thing. We shouldn't try to hide it >> though, because there are bits of the code that check it and it is still >> useful in a few circumstances. > > What circumstances, ecxactly (sorry, I really don't know). G_projection() checks in there. E.g. checking for a latitude-longitude projection in a module to see how distance measurements should be handled, results in WIND being checked. Also for XY locations, they won't have a PROJ_INFO file, but the projection entry in the WIND file gives the information that the location is XY (unprojected). There are also places in the code code that check if the location zone and projection (from the WIND file) match that in raster map headers. It would be possible to have the projection and zone info in a raster map not matching the location if it had got corrupted or manually edited, or more likely directly copied from a different location. It is possible for two locations to have effectively the same projection number but different numbers in the cellhd projection value - e.g. both UTM and State Plane projections can equivalently be represented as transverse mercator or lambert conformal conic with appropriate parameters, in which case there should be 99 (other projection) in the cellhd. Not that likely but possible. >> But I don't think extra stuff like the >> projection name from PROJ_INFO in brackets, ellps or datum should be >> there. It is confusing as these are being taken from a different source. >> The projection name reported should be one of the 5 original ones >> defined: XY, UTM, State Plane, Latitude-Longitude or Other, >> corresponding to codes 0,1,2,3 or 99 in the WIND file. > > Hmm, I think g.proj -p should report the projection name as good as it > can, given the available data. 'Other' doesn't mean much (there are > dozens of projections other than UTM and State Plane). Yes - I wasn't saying it shouldn't - my comment above is related to what I thought g.region should report. Well ideally it should report any projection-related information but if it's there in the WIND file, then I think it should. My main point is, that to keep things simple and avoid the possiblity of introducing easily avoidable bugs in the future, the structure of the commands should reflect as much as possible the underlying structure of GRASS. Thus if you are going to change e.g. g.region and r.info not to report the projection info contained in the WIND file and raster header, then you should remove that information from those files, change the cellhd struct not to contain it, and change all the bits of GRASS code that assume that information is there and check for it. IOW a proper clean-up. I don't think it is a good idea to just make cosmetic changes to commands that hide the mess that is in the GRASS structure underneath, like sweeping it under the carpet. IMHO, better to keep it visible it will be easier to see what's going on and diagnose problems when they occur. But TBH I don't feel all that strongly on this issue really! [...] >>> [1] >>> propably the g.proj -j output should be extended to include all the >>> information output by g.proj -p, or a new "-g" flag should be >>> introduced, to be used in conjunction with "-p" for parseable output. >> >> Hmm, if you think it might be useful. I'm not sure. The function of >> g.proj -j is to produce a PROJ.4-compatible output. > > Right. But it doesn't print the units information, which is present in > PROJ.4-compatible output of eg. "epsg_tr.py -proj4 ". Shouldn't > then g.proj -j include the units info too? Maybe it should! Can you point me to some examples? Paul From paul-grass at stjohnspoint.co.uk Fri Jan 5 12:07:19 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Fri Jan 5 12:07:24 2007 Subject: [GRASS-dev] Re: gis.m crashes on zoom to map existing in more than one mapset In-Reply-To: References: Message-ID: Hello Michael On Thu, 4 Jan 2007, Michael Barton wrote: [...] >> Try this instead: >> if {![catch {open [concat "|g.region" "-ugp" $args "|& >> $env(GISBASE)/etc/grocat"] r} input]} { >> while {[gets $input line] >= 0} { >> if { [regexp -nocase {^([a-z]+)=(.*)$} $line trash key value] } >> { >> set parts($key) $value >> } >> } > > I can confirm that this works. What is grocat?? It's a little C program I wrote (with lots of hints from Glynn) that very simply copies its standard input to standard output. Tcl allows you to pipe both stdout and stderr to an external program (using the |& operator) but doesn't allow you to redirect stderr to stdout like you can do on the command-line. So we created this little program to combine stdout and stderr and write them to stdout. It's source is in lib/gtcltk/grocat.c but it doesn't use any GRASS functions or libraries so is in effect standalone. >> I am guessing that "catch" catches errors by seeing if anything is written >> to stderr - if a warning is written to stderr will it incorrectly catch it >> as an error? > > Yes, this is what seems to be happening. The program exits with the warning > printed to the terminal. Right. So catch isn't useful for GRASS commands then as in GRASS, a module writing to stderr is not equivalent to an error condition. Messages and warnings also go to stderr, and we need to use something like grocat to redirect these away from stderr and stop them making Tcl think there is an error. >> I'm not sure, but merging stderr into stdout with the grocat >> program will stop anything being written to stderr so will stop this. This >> will work on Windows - in fact I wrote it specifically because the >> previous way it was done (see my recent changes to >> lib/gtcltk/gronsole.tcl) was Unix-specific - the grocat trick works on >> Unix and Windows. > > OK. If you've tested this on Windows, then it should be OK. I'm just trying > not to do anything that will jeopardize a native Windows build. Yes, totally understand. It does look like a Unix command I know but it's contained within the GRASS source so will be available on any platform (it's very simple basic C, really only uses stdio.h). >> Then within the while loop I've used an if to check the return value of >> regexp - there are only two possible values - 1 if it matches the line and >> 0 if it doesn't. So it won't match the Warning line, will return 0, and >> thus stops you trying to assign non-existent values to key and value. > > OK. This works fine too. Thanks. After fixing stuff yesterday, I was > thinking it might be simpler to switch to > > set key [string trim [lindex [split $line "="] 0]] > > I wonder if this could be made to test in a similar way? I actually think using the regexp command is more powerful. Because the lindex construction above assumes that the output from the command is valid. But e.g. if there is a warning or an extra message, then not every line will be valid. The regexp is powerful because if the line doesn't match what you're expecting, then you're able to skip over it. I can't easily see a way to that with the set key... line above, although it might be possible I suppose with a lot of thinking. > Thanks for your help. No problem. Working around the inadequacies and limitations of Tcl would appear to be an interesting challenge but I'm sure there are more productive things we could be doing! Paul From radim.blazek at gmail.com Fri Jan 5 13:19:39 2007 From: radim.blazek at gmail.com (Radim Blazek) Date: Fri Jan 5 13:19:41 2007 Subject: [GRASS-dev] Re: [Qgis-developer] Windows native GRASS build In-Reply-To: <200701031123.18433.marco.hugentobler@karto.baug.ethz.ch> References: <340505ef0701010447s39a3912fy439fbb8274fba804@mail.gmail.com> <200701031123.18433.marco.hugentobler@karto.baug.ethz.ch> Message-ID: <340505ef0701050419n1e58b71eu7bc4ce2afe66c06e@mail.gmail.com> Thanks Marco! -mwindows helped, attached is patch for Grass.make.in and dbf driver Makefile. Similar change must be done in Makefiles of all drivers. configure must be run because Grass.make.in is source for Grass.make It would be nice if this patch or something similar could be applied to GRASS CVS head and 6.2 release branch. Tim can you patch your GRASS in MSYS and create a new build? We dont have to wait for 0.8.1 IMO because it does not include changes in QGIS, it is just a new binary build. Radim On 1/3/07, Marco Hugentobler wrote: > > Hi Radim and Tim, > > If the db driver is compiled with mingw gcc and you have the possibility to > recompile it yourself, you may use the linker option -mwindows. I don't know > of other possibilities to avoid the console (but I am no win expert too). > > Marco > > Am Montag, 1. Januar 2007 18:30 schrieb Tim Sutton: > > Hi > > > > > > 1) Every time a layer is added a black console box temporarily appears > > > > and then disappears. > > > > > > It is known problem, db driver is exe and when it is started by spawnl() > > > it opens Windows console for a while. I am not Win expert and I dont know > > > how to avoid this. I have asked already in QGIS and GRASS devel lists. > > > > Ok - I think its not a big problem for now. > > > _______________________________________________ > Qgis-developer mailing list > Qgis-developer@lists.qgis.org > http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer > -------------- next part -------------- A non-text attachment was scrubbed... Name: Grass.make.in.patch Type: application/octet-stream Size: 363 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070105/a08ab3a7/Grass.make.in.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.patch Type: application/octet-stream Size: 411 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070105/a08ab3a7/Makefile.obj From glynn at gclements.plus.com Fri Jan 5 13:26:26 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Jan 5 13:26:32 2007 Subject: [GRASS-dev] Re: [Qgis-developer] Windows native GRASS build In-Reply-To: <1167763449.11348.331.camel@devel> References: <340505ef0701010447s39a3912fy439fbb8274fba804@mail.gmail.com> <459A09ED.7050904@faunalia.it> <1167763449.11348.331.camel@devel> Message-ID: <17822.17394.326185.59708@cerise.gclements.plus.com> Brad Douglas wrote: > > >>> /src/grass6/raster/r.li/r.li.daemon > > >>> /src/grass6/raster/r.li/r.li.edgedensity > > >>> /src/grass6/raster/r.li/r.li.patchdensity > > >>> /src/grass6/raster/r.li/r.li.patchnumber > > >>> /src/grass6/raster/r.li/r.li.shape > > >>> /src/grass6/raster/r.li/r.li.simpson > > >>> /src/grass6/raster/r.li/r.li.shannon > > >>> /src/grass6/raster/r.li/r.li.meanPatchSize > > >>> /src/grass6/raster/r.li/r.li.meanPixelAttribute > > >>> /src/grass6/raster/r.li/r.li.patchAreaDistributionCV > > >>> /src/grass6/raster/r.li/r.li.patchAreaDistributionSD > > >>> /src/grass6/raster/r.li/r.li.patchAreaDistributionRANGE > > >>> /src/grass6/raster/r.li/r.li.contrastWeightedEdgeDensity > > >>> /src/grass6/raster/r.li/r.li.richness > > >>> /src/grass6/raster/r.li/r.li.dominance > > >> > > >> Not crucial. > > > > > > Agreed, but we would like to have it. Tim, could you please forward the > > > errors to Serena Pallecchi, Davide Spano and Claudio Porta? > > > > Please see attached. Main problems as far as I can see: > > - Use of FIFOs? AIUI Windows doesn't have FIFOs so that won't work. > > - Also I don't think fork() is available on Windows either - Glynn may be > > able to advise. > > Linux: fork() exec() > Win32: CreateProcess() > > Linux: exit() > Win32: ExitProcess() > > Linux: get/putenv() > Win32: Get/SetEnvironmentVariable() > > Linux: waitpid() > Win32: GetExitCodeProcess() > > Linux; getpid() > Win32: GetCurrentProcessId() > > It would be nice to have wrappers for these functions. Thoughts, Glynn? There are limits to "wrapping" process management. It isn't as if Unix and Windows are the same except for the names given to the functions; the semantics are quite different. Particularly the Unix model of separate fork() and exec(), with the ability to substantially alter the state of the child between the two, versus a single CreateProcess() call with a fixed set of parameters. Having said that, you could wrap the simpler cases. You would need to stick to what's available on Windows; some of the more complex things which can be done on Unix either aren't possible on Windows (e.g. setting descriptors other than stdin/stdout/stderr) or don't have any equivalent there (e.g. signal handling). I already started writing potential replacements for typical usage of system(); see lib/gis/spawn.c. G_spawn() is a direct replacement for the simplest uses of system(), except that it accepts individual arguments rather than a single string and doesn't use "sh -c ...". G_spawn_ex() is intended to handle more advanced usage, e.g. redirection, signal handling, environment variable substitution and binding. -- Glynn Clements From radim.blazek at gmail.com Fri Jan 5 13:32:02 2007 From: radim.blazek at gmail.com (Radim Blazek) Date: Fri Jan 5 13:32:05 2007 Subject: [GRASS-dev] Vector weirdness @ native windows version In-Reply-To: <20070104154827.21340@gmx.net> References: <20070104154827.21340@gmx.net> Message-ID: <340505ef0701050432wde21dcey25ae0749c2b7b524@mail.gmail.com> A large vector with attributes? It could be the problem with pipe on Windows. DB drivers are using pipes and there is a bug in implementation of pipe buffer on Windows. IIRC it can fail on Windows 5.1 (workstation) but it works on 5.2 (server). Try to run the same on Windows XP server. Radim On 1/4/07, peter.loewe@gmx.de wrote: > v.out.ogr produces some interesting effects in the current beta version for native windows: > > Using Spearfish, > v.out.ogr input=roads type=line,boundary dsn=. olayer=roads_out layer=1 format=ESRI_Shapefile > gets stuck after a black window ist produced by C:/msys/1.0/local/grass\driver\db\dbf.exe > [btw the combination of slashes and backslashes is NOT a typo.] > > This happens only when v.out.ogr is accessed through its GUI. > > When called up entirely from the command line, it gets stuck at "13%". > > Does anybody know of a workaround for this ? > > Peter > -- > Dr. Peter L?we > > Diplom-Geograph > > > > > > > > > Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! > Ideal f?r Modem und ISDN: http://www.gmx.net/de/go/smartsurfer > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > From glynn at gclements.plus.com Fri Jan 5 13:33:30 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Jan 5 13:33:33 2007 Subject: [GRASS-dev] patch: foreground color in d.rast In-Reply-To: <20070104140554.GB13745@uibk.ac.at> References: <20070104140554.GB13745@uibk.ac.at> Message-ID: <17822.17818.579786.807824@cerise.gclements.plus.com> Florian Kindl wrote: > Attached you find a quick patch which adds a fg=color option to d.rast. > It draws cells with cat=1 in the specified color. > I created this for personal use as I frequently overlay binary rasters > to have a quick visual comparison. > > We probably don't want to have this patch applied to CVS as it > 1) can be replaced with r.colors > 2) works with binary (1,NULL) CELL raters only > 3) it does not adhere to the "new color logic" (uses G_set_color) > > If the developers are of the opinion that 1) is a non-issue and d.rast > should have the fg=color option added then we have to discuss whether 2) > should be expanded to for example, "color all non-NULL cells of any > given raster type". Once this is decided, one can implement the functionality > using the "new color logic" functions (G_add_color_rule). > > For now, I'll just post the patch as a service for anyone who'd like to > have the limited functionality today. FWIW, I don't support applying this to CVS due to #1. -- Glynn Clements From glynn at gclements.plus.com Fri Jan 5 13:41:34 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Jan 5 13:45:06 2007 Subject: [GRASS-dev] G.region bug when setting 3d resolution??? Maybe not In-Reply-To: References: Message-ID: <17822.18302.742776.284983@cerise.gclements.plus.com> Michael Barton wrote: > > 1. Merge the output of stdout and stderr for any commands called like > > this, by adding "|& $env(GISBASE)/etc/grocat" to the end of the command > > line. > > Reason: This will stop Tcl bombing out completely if anything is written > > to stderr (a warning or message, for example). > > I think some other solution would be better for two reasons. First, this > construction calls a *nix command from within TclTk. This is problematic for > Windows. A pure TclTk construction would be better. Second, in the most > recent set of problems with g.region, I'm not sure if this would help all > that much anyway. The GUI was reading the text output from g.region -g OK, > the problem is that it was the wrong output. It was expecting [key]=[value]. > The first [key] included the warning message. This gave a key that was not > recognizable by the subsequent routine that tried to process the key to get > region values. For this particular routine, a 'catch' command is already in > place to trap real errors and move on. In fact, an error will cause the GUI > to quit relatively gracefully with the GRASS error printed to the terminal. > I implemented this, working with Hamish to solve a recurrent problem that > caused the GUI to give somewhat misleading error messages when GRASS was > improperly installed (usually a gdal installation problem). Part of the problem here is that you're running into the limitations of Tcl/Tk's process management. AFAICT, Python provides more powerful process management, e.g. os.popen3 returns separate pipes for each of stdin, stdout, and stderr, so you don't have to merge or discard stderr. -- Glynn Clements From glynn at gclements.plus.com Fri Jan 5 13:55:02 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Jan 5 13:55:06 2007 Subject: [GRASS-dev] g.region print flags combination In-Reply-To: References: <22A5FE4C-7F65-4E87-A823-0900E5D414CF@unity.ncsu.edu> <45994A35.5070805@o2.pl> <459A8DB3.6030205@o2.pl> Message-ID: <17822.19110.920723.538784@cerise.gclements.plus.com> Martin Landa wrote: > > "g.region -g" works OK now, but it prints a WARNING message on the top. > > It also prints few extra lines, compared to before, namely: > > > > projection=1 > > zone=34 > > datum=wgs84 > > ellipsoid=wgs84 > > > > Your WARNING message is correct and desired, as well as the extra info > > is usefull, but those several additional lines might brake some user's > > scripts. > > So should I disable this warning, right? Maybe. If the intention is that use of -g alone will cease to work at some point, the warning should be kept. If it is kept, gis.m should be modified to handle it; has that been done already? Even if this specific warning is removed, gis.m should always allow for warnings simply for robustness. Personally, I don't see a problem with having -g alone remaining equivalent to -pg permanently, i.e. if -g is used with no other "print" switches, then -p is enabled automatically. > I think the additional lines would not break any scripts, which parse > `g.region -g` output in a reasonable way (eval, awk) (?). Agreed, but that doesn't help scripts which parse the output in an *unreasonable* way ;) Where the g.region documentation specifies the output produced by a switch or combination of switches, it should explicitly state that the output will include specific fields, but that the order is unspecified and that other fields may also be present. IOW, anything which parses the output of g.region should, regardless of which output format is used: 1. identify fields by their "keys" rather than by their relative position (i.e. line number) in the output, and 2. silently ignore any unrecognised fields. IMHO, scripts which don't comply with the above should be considered "already broken"; changes to g.region need not accomodate them. -- Glynn Clements From glynn at gclements.plus.com Fri Jan 5 14:04:40 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Jan 5 14:12:43 2007 Subject: [GRASS-dev] g.region print flags combination In-Reply-To: References: <22A5FE4C-7F65-4E87-A823-0900E5D414CF@unity.ncsu.edu> <45994A35.5070805@o2.pl> <459A8DB3.6030205@o2.pl> <459AA777.40504@o2.pl> Message-ID: <17822.19688.509359.666325@cerise.gclements.plus.com> Martin Landa wrote: > 3) The -p flag was changed. > > projection: 99 (Krovak) > zone: 0 > datum: towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56 > > -> > > projection : 99 (Krovak) > zone : 0 > datum : towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56 > > Not sure what formatting is more appropriate. Personally, I would have added the padding after the colons, i.e.: projection: 99 (Krovak) zone: 0 datum: towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56 The reason being that a regexp such as "^([^:]*): *(.*)$" would still work as before. > 4) g.region -g X g.region -pg Should be equivalent, IMO. > --- I wanted to make -g flag more > universal, e.g. to distinguish > > g.region -pcl > g.region -cl > > and > > g.region -pclg instead of g.region -gcl <-- problem > g.region -gcl <-- problem What's the problem? That -g == -pg but -cg != -pcg? That isn't a problem, IMHO. By making -g a synonym for -pg, you're only affecting the behaviour of a case which would otherwise be meaningless (the printing format doesn't matter if you don't print anything). Several other modules have similar behaviour, and some of it is significantly more irrational than this. -- Glynn Clements From Roger.Bivand at nhh.no Fri Jan 5 14:27:29 2007 From: Roger.Bivand at nhh.no (Roger Bivand) Date: Fri Jan 5 14:27:31 2007 Subject: [GRASS-dev] g.region print flags combination In-Reply-To: <17822.19688.509359.666325@cerise.gclements.plus.com> Message-ID: On Fri, 5 Jan 2007, Glynn Clements wrote: > > Martin Landa wrote: > > > 3) The -p flag was changed. > > > > projection: 99 (Krovak) > > zone: 0 > > datum: towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56 > > > > -> > > > > projection : 99 (Krovak) > > zone : 0 > > datum : towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56 > > > > Not sure what formatting is more appropriate. > > Personally, I would have added the padding after the colons, i.e.: > > projection: 99 (Krovak) > zone: 0 > datum: towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56 > > The reason being that a regexp such as "^([^:]*): *(.*)$" would still > work as before. There are some standards here - the one most often used in R for package management is DCF (Debian Control File): " DCF is a simple format for storing databases in plain text files that can easily be directly read and written by humans. DCF is used in various places to store R system information, like descriptions and contents of packages. The DCF rules as implemented in R are: 1. A database consists of one or more records, each with one or more named fields. Not every record must contain each field, a field may appear only once in a record. 2. Regular lines start with a non-whitespace character. 3. Regular lines are of form 'tag:value', i.e., have a name tag and a value for the field, separated by ':' (only the first ':' counts). The value can be empty (=whitespace only). 4. Lines starting with whitespace are continuation lines (to the preceding field) if at least one character in the line is non-whitespace. 5. Records are separated by one or more empty (=whitespace only) lines. " where most often there is only one record. I have used this for reading in g.region output (in spgrass6), so would be happy to see something that can be parsed used. For that, padding is a pain by and large, and if people need pretty things, then a parsed text file can be fed to a GUI. Roger > > > 4) g.region -g X g.region -pg > > Should be equivalent, IMO. > > > --- I wanted to make -g flag more > > universal, e.g. to distinguish > > > > g.region -pcl > > g.region -cl > > > > and > > > > g.region -pclg instead of g.region -gcl <-- problem > > g.region -gcl <-- problem > > What's the problem? That -g == -pg but -cg != -pcg? > > That isn't a problem, IMHO. By making -g a synonym for -pg, you're > only affecting the behaviour of a case which would otherwise be > meaningless (the printing format doesn't matter if you don't print > anything). Several other modules have similar behaviour, and some of > it is significantly more irrational than this. > > -- Roger Bivand Economic Geography Section, Department of Economics, Norwegian School of Economics and Business Administration, Helleveien 30, N-5045 Bergen, Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43 e-mail: Roger.Bivand@nhh.no From glynn at gclements.plus.com Fri Jan 5 14:23:58 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Jan 5 14:37:25 2007 Subject: [GRASS-dev] g.region print flags combination In-Reply-To: References: Message-ID: <17822.20846.201828.655405@cerise.gclements.plus.com> Michael Barton wrote: > 5. There should be no spaces or other extraneous characters between > [key][separator][value], or at the end or beginning of this string. However, there may be cases where the [value] can contain spaces or other "awkward" characters. We need to decide what, if any, processing should be performed in such cases; if so, it should be done consistently by all relevant modules. If you're targeting the shell's "eval", the easiest solution is to add quotes, e.g.: string='this is a string' or backslash characters, e.g.: string=this\ is\ a\ string but that makes it harder for other languages. In general, the easiest format would be to prohibit newlines and take as the value everything from the character immediately following the separator to the end of the line, so: string= this is a string would have the value " this is a string" (with a leading space). That can't be parsed by "eval", although it can be parsed by just about anything having regexp or pattern operations, e.g.: $ foo="string= this is a string" $ echo "$foo" string= this is a string $ echo "${foo%%=*}" # key string $ echo "${foo#*=}" # value this is a string Note the use of one # but two % to handle the case where the value contains the separator: $ foo="string= this is a = string" $ echo "$foo" string= this is a = string $ echo "${foo%%=*}" # key (correct) string $ echo "${foo%=*}" # key (removes too little) string= this is a $ echo "${foo#*=}" # value (correct) this is a = string $ echo "${foo##*=}" # value (removes too much) string > 6. There should be no warnings or other extraneous text printed with > 'script' format. The assumption is that script format is not designed for > humans to read (although they certainly can, of course). If it fails for > some reason, it should get the standard error message. for that command. I > would strongly suggest getting rid of the warnings in script format for > g.region. Scripts should be parsing stdout, not stderr. Modules can write whatever they wish to stderr; it's gis.m's job to allow for the possibility of warnings. -- Glynn Clements From landa.martin at gmail.com Fri Jan 5 14:37:54 2007 From: landa.martin at gmail.com (Martin Landa) Date: Fri Jan 5 14:37:56 2007 Subject: [GRASS-dev] g.region print flags combination In-Reply-To: <17822.19688.509359.666325@cerise.gclements.plus.com> References: <45994A35.5070805@o2.pl> <459A8DB3.6030205@o2.pl> <459AA777.40504@o2.pl> <17822.19688.509359.666325@cerise.gclements.plus.com> Message-ID: Hi, 2007/1/5, Glynn Clements : > > 3) The -p flag was changed. > > > > projection: 99 (Krovak) > > zone: 0 > > datum: towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56 > > > > -> > > > > projection : 99 (Krovak) > > zone : 0 > > datum : towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56 > > > > Not sure what formatting is more appropriate. > > Personally, I would have added the padding after the colons, i.e.: > > projection: 99 (Krovak) > zone: 0 > datum: towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56 > > The reason being that a regexp such as "^([^:]*): *(.*)$" would still > work as before. OK, changed in CVS. Thanks! Martin -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From glynn at gclements.plus.com Fri Jan 5 14:42:11 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Jan 5 14:43:29 2007 Subject: [GRASS-dev] Re: gis.m crashes on zoom to map existing in more than one mapset In-Reply-To: References: Message-ID: <17822.21939.817759.306537@cerise.gclements.plus.com> Paul Kelly wrote: > I am guessing that "catch" catches errors by seeing if anything is written > to stderr - if a warning is written to stderr will it incorrectly catch it > as an error? "catch" catches exceptions thrown by Tcl. It isn't limited to I/O, e.g.: % set foo [expr 1 / 0] divide by zero % catch {set foo [expr 1 / 0]} res 1 % puts $res divide by zero % catch {set foo [expr 10 / 2]} res 0 % puts $res 5 Tcl's process-creation code throws an exception if anything is written to stderr. For "exec", it's the exec call which throws the exception. For "open |...", the corresponding "close" will throw an exception (the error won't have occurred at the point that open returns, which will typically be soon after the fork(), possibly before the child has even called execve()). I'm not sure, but it's possible that reading from the pipe may also throw an exception. In simple cases, the entire open/read/close loop should be contained within a single catch; in more complex cases, each individual function needs its own catch. >I'm not sure, but merging stderr into stdout with the grocat > program will stop anything being written to stderr so will stop this. This > will work on Windows - in fact I wrote it specifically because the > previous way it was done (see my recent changes to > lib/gtcltk/gronsole.tcl) was Unix-specific - the grocat trick works on > Unix and Windows. In this case, an alternative is to simply redirect stderr elsewhere, e.g. to @stdout (may not work on Windows) or /dev/null (nul on Windows). > Then within the while loop I've used an if to check the return value of > regexp - there are only two possible values - 1 if it matches the line and > 0 if it doesn't. So it won't match the Warning line, will return 0, and > thus stops you trying to assign non-existent values to key and value. In general, any Tcl code which attempts to parse program output needs to silently ignore unexpected output, as stderr often has to be merged with stdout due to Tcl's "writing to stderr == error" behaviour. -- Glynn Clements From glynn at gclements.plus.com Fri Jan 5 14:49:52 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Jan 5 14:51:09 2007 Subject: [GRASS-dev] gis.m crashes on zoom to map existing in more than one mapset In-Reply-To: <459CFD37.1060408@club.worldonline.be> References: <459CFD37.1060408@club.worldonline.be> Message-ID: <17822.22400.497161.234470@cerise.gclements.plus.com> Moritz Lennert wrote: > I don't know if this is just another manifestation of the changes in > g.region, but gis.m crashes when I try to zoom to a map which exists in > more than one mapset of the current location. > > To reproduce in spearfish, in mapset user1: > > 1) g.copy rast=bugsites@PERMANENT,bugsites (or any other raster or > vector map) > > 2) display bugsites > > 3) zoom to selected map > > The command used in mapcanvas.tcl is g.region -ugp rast=bugsites. This > gives: > > GRASS 6.3.cvs (spearfish60):~ > g.region -ugp rast=bugsites > WARNING: 'cell/bugsites' was found in more mapsets (also found in user1). This is a good example of why the solution to the recent g.region/gis.m issues is to make gis.m handle warnings correctly rather than trying to eliminate specific warnings. Even the simplest program can potentially result in warnings (or similar diagnostics) being generated by libgis (or other libraries) in some cases. And for third-party libraries (of which GDAL may use a significant number), there is nothing which can be done about it. Tcl's behaviour of treating anything written to stderr as an error is a nuisance, but one which has to be dealt with so long as we continue to use Tcl. -- Glynn Clements From peter.loewe at gmx.de Fri Jan 5 15:10:06 2007 From: peter.loewe at gmx.de (=?iso-8859-1?Q?=22Peter_L=F6we=22?=) Date: Fri Jan 5 15:10:08 2007 Subject: [GRASS-dev] g.parser how to debug ? In-Reply-To: <200701051232.l05CW94W017797@grass.itc.it> References: <200701051232.l05CW94W017797@grass.itc.it> Message-ID: <20070105141006.280340@gmx.net> hi, when using g.parser to get paramters into bash-scripts (nothing fancy: input map, output map, a string) there's a problem with the GUI-variant: if the script is invoked with all paramters provided on the command line, it works as expected. if its called up without any parameters, the GUI is generated and the parameters are entered (same as provided for the command line). however, it stops short of doing anything, showing the red-disk-white-x - icon on the output panel. how can I figure out what's going on/debug the script if necessary ? Peter -- Dr. Peter L?we Diplom-Geograph Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal f?r Modem und ISDN: http://www.gmx.net/de/go/smartsurfer From tim at linfiniti.com Fri Jan 5 16:25:50 2007 From: tim at linfiniti.com (Tim Sutton) Date: Fri Jan 5 16:25:51 2007 Subject: [GRASS-dev] Re: [Qgis-developer] Windows native GRASS build In-Reply-To: <340505ef0701050419n1e58b71eu7bc4ce2afe66c06e@mail.gmail.com> References: <340505ef0701010447s39a3912fy439fbb8274fba804@mail.gmail.com> <200701031123.18433.marco.hugentobler@karto.baug.ethz.ch> <340505ef0701050419n1e58b71eu7bc4ce2afe66c06e@mail.gmail.com> Message-ID: Hi Radim I can make another build but probably not until monday. If the patches go into grass cvs that will be great cause then I can just update & build. Regards Tim On 1/5/07, Radim Blazek wrote: > Thanks Marco! > -mwindows helped, attached is patch for Grass.make.in > and dbf driver Makefile. Similar change must be done in > Makefiles of all drivers. configure must be run because > Grass.make.in is source for Grass.make > > It would be nice if this patch or something similar could be applied > to GRASS CVS head and 6.2 release branch. > > Tim can you patch your GRASS in MSYS and create a new build? > We dont have to wait for 0.8.1 IMO because it does not include > changes in QGIS, it is just a new binary build. > > Radim > > On 1/3/07, Marco Hugentobler wrote: > > > > Hi Radim and Tim, > > > > If the db driver is compiled with mingw gcc and you have the possibility to > > recompile it yourself, you may use the linker option -mwindows. I don't know > > of other possibilities to avoid the console (but I am no win expert too). > > > > Marco > > > > Am Montag, 1. Januar 2007 18:30 schrieb Tim Sutton: > > > Hi > > > > > > > > 1) Every time a layer is added a black console box temporarily appears > > > > > and then disappears. > > > > > > > > It is known problem, db driver is exe and when it is started by spawnl() > > > > it opens Windows console for a while. I am not Win expert and I dont know > > > > how to avoid this. I have asked already in QGIS and GRASS devel lists. > > > > > > Ok - I think its not a big problem for now. > > > > > _______________________________________________ > > Qgis-developer mailing list > > Qgis-developer@lists.qgis.org > > http://lists.qgis.org/cgi-bin/mailman/listinfo/qgis-developer > > > > > -- -- Tim Sutton Visit http://qgis.org for a great Open Source GIS Home Page: http://linfiniti.com Skype: timlinux MSN: tim_bdworld@msn.com Yahoo: tim_bdworld@yahoo.com Jabber: timlinux Irc: timlinux on #qgis at freenode.net From maris.gis at gmail.com Fri Jan 5 16:37:19 2007 From: maris.gis at gmail.com (Maris Nartiss) Date: Fri Jan 5 16:37:21 2007 Subject: [GRASS-dev] Valid location, mapset and map names Message-ID: <2b3d8c1c0701050737v7e08d498j8e18828613b26b40@mail.gmail.com> Hi, I wanted to know - is safe to use non-latin chars in location, mapset, map names? Are there any other restrictions on those names except file system related restrictions? I recall some conversation about alloved and forbidden characters in vector file names, but quick look at 6.3.cvs reference manual does not reveal this information. Information about valid and invalid chars in location, mapset, map names should be included in reference manual. WBR, Maris. From maris.gis at gmail.com Fri Jan 5 18:27:07 2007 From: maris.gis at gmail.com (Maris Nartiss) Date: Fri Jan 5 18:27:11 2007 Subject: [GRASS-dev] GRASS startup window patches Message-ID: <2b3d8c1c0701050927q34503896nf22c4de307f46485@mail.gmail.com> Hi all, as last night I had loooong chat with some first time GRASS user, who was hit by problems in GRASS startup screen (paritaly fixed in 6.3), thus today I spent some time on fixing small usability problems of startup screen. Please, somebody review them and commit to CVS. And another question - epsg_option.tcl uses "exec g.proj" to call g.proj. Is possible (safe) to use same approach to create new location from georeferenced file? If yes, then it's just copy/paste epsg_option code and a bit to tweak to make georef location creator as same good like epsg one :) Maris. -------------- next part -------------- A non-text attachment was scrubbed... Name: epsg_option.patch Type: text/x-diff Size: 4552 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070105/72ca1241/epsg_option-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: gis_set.patch Type: text/x-diff Size: 17098 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070105/72ca1241/gis_set-0001.bin From tutey at o2.pl Fri Jan 5 21:01:51 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Fri Jan 5 21:02:09 2007 Subject: [GRASS-dev] g.region print flags combination In-Reply-To: References: <22A5FE4C-7F65-4E87-A823-0900E5D414CF@unity.ncsu.edu> <45994A35.5070805@o2.pl> <459A8DB3.6030205@o2.pl> <459AA777.40504@o2.pl> <459D3F69.3040500@o2.pl> <459D53A7.6020803@o2.pl> Message-ID: <459EAEAF.9000507@o2.pl> Paul Kelly wrote: > On Thu, 4 Jan 2007, Maciej Sieczka wrote: >> Right. But it doesn't print the units information, which is present in >> PROJ.4-compatible output of eg. "epsg_tr.py -proj4 ". Shouldn't >> then g.proj -j include the units info too? > Maybe it should! Can you point me to some examples? Eg. $ epsg_tr.py -proj4 2180 # ETRS89 / Poland CS92 <2180> +proj=tmerc +lat_0=0 +lon_0=19 +k=0.999300 +x_0=500000 +y_0=-5300000 +ellps=GRS80 +units=m +no_defs <> ^ | There units here ------------- But, in a location created with "g.proj -c proj4='+init=epsg:2180'", units are missing from "g.proj -j" output: $ g.proj -jf +proj=tmerc +lat_0=0 +lon_0=19 +k=0.999300 +x_0=500000 +y_0=-5300000 +no_defs +a=6378137 +rf=298.257222101 +towgs84=0.000,0.000,0.000 ^ |------------------------------- | Another thing - is no_defs on right place here? I *guess* it should be on the very end, ?. Cheers, Maciek From paul-grass at stjohnspoint.co.uk Fri Jan 5 22:06:44 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Fri Jan 5 22:06:49 2007 Subject: [GRASS-dev] GRASS startup window patches In-Reply-To: <2b3d8c1c0701050927q34503896nf22c4de307f46485@mail.gmail.com> References: <2b3d8c1c0701050927q34503896nf22c4de307f46485@mail.gmail.com> Message-ID: Hello Maris, A few points: It's a bit hard to see what your patch does by looking at it - there seem to be a lot of bogus changes where the line deleted and the line added are the same - could it be an issue with Tab/space conversion settings in your editor perhaps? You don't need to put a changelog as comments in the file - it is saved automatically when commited to CVS! As we saw in the discussions about g.region and gis.m, using the Tcl catch commands on GRASS commands isn't generally a good idea as Tcl falsely assumes a command that writes to stderr is issuing an error. This applies to g.proj too. If partially-specified datum information is passed to g.proj, it WILL try to interactively prompt the user for complete information. This is done by printing to stderr and looking for an input on stdin.(The Tcl catch command will treat this as an error.) There are also circumstances where g.proj will issue a warning (but still proceed to create the location OK), and again this writes to stderr and the catch command will erroneously assume there is an error. I think, until we can work out some way of always passing fully specified datum information to g.proj, that when g.proj is used for location set-up we should run it in a pop-up terminal Window. So if it does choose to prompt the user it (while kludgy and archaic-looking) will actually work. The procedure run_xterm in lib/gtcltk/gronsole.tcl has some Unix/Windows Tcl code for running GRASS commands in a pop-up terminal Window (it would be good to have this in a function for use by all the Tcl bits of GRASS, not just those that use gronsole, but I'm not sure how to do that). But yes as you said below about using g.proj to create a new location using a georeferenced file - that is exactly the same idea as using the EPSG code. In fact better, as the recent update I made to g.proj a few days ago now attempts to set initial region settings for the new location from the extents of the file (using code taken from r.in.gdal and v.in.ogr). I haven't really tested it yet though. Helena made the point that it was important to impress the concept of setting the initial region for a location on the user, and that this was lost a bit with the new "one click" location creation. I was thinking, that it would be a good idea for the start-up GUI, after the location was created, to read the region back in (using g.region probably) and then present this to the user in a GUI screen similar to the curses-based region setting that the old inter version of g.region used to have. If the region had been set from a georeferenced file, it would probably be fine and the user could just press OK, or if the location had been created e.g. from an EPSG code there would just be a default 1pixel-sized region that the user could then set. If a pretty GUI screen was created for this it could also be used for setting the region in gis.m proper - the current straight-down list of north, south, east, west, resolution etc. is inferior IMHO to the old interactive terminal-based g.region. Before Christmas when I changed g.proj to call G_no_gisinit() instead of G_gisinit(): that removed the issue whereby a whole template location with valid mapset had to exist before actually creating a new location with g.proj - now it just needs a GISRC file with the GISDBASE field set to something valid. HOWEVER, the G_tempfile() issue (which does require a valid current location and mapset) hasn't yet been fixed, so can't remove all that stuff out of epsg_option.tcl just yet. But I will try and get the time to propose something to the list soon and we can sort it out. This e-mail has just been a bit of a brain-dump really, sorry about that Paul On Fri, 5 Jan 2007, Maris Nartiss wrote: > Hi all, > > as last night I had loooong chat with some first time GRASS user, who > was hit by problems in GRASS startup screen (paritaly fixed in 6.3), > thus today I spent some time on fixing small usability problems of > startup screen. > > Please, somebody review them and commit to CVS. > > And another question - epsg_option.tcl uses "exec g.proj" to call > g.proj. Is possible (safe) to use same approach to create new location > from georeferenced file? If yes, then it's just copy/paste epsg_option > code and a bit to tweak to make georef location creator as same good > like epsg one :) > > Maris. > From paul-grass at stjohnspoint.co.uk Fri Jan 5 22:39:32 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Fri Jan 5 22:39:33 2007 Subject: [GRASS-dev] g.region print flags combination In-Reply-To: <459EAEAF.9000507@o2.pl> References: <22A5FE4C-7F65-4E87-A823-0900E5D414CF@unity.ncsu.edu> <45994A35.5070805@o2.pl> <459A8DB3.6030205@o2.pl> <459AA777.40504@o2.pl> <459D3F69.3040500@o2.pl> <459D53A7.6020803@o2.pl> <459EAEAF.9000507@o2.pl> Message-ID: Hello Maciek On Fri, 5 Jan 2007, Maciej Sieczka wrote: > Paul Kelly wrote: >> On Thu, 4 Jan 2007, Maciej Sieczka wrote: > >>> Right. But it doesn't print the units information, which is present in >>> PROJ.4-compatible output of eg. "epsg_tr.py -proj4 ". Shouldn't >>> then g.proj -j include the units info too? > >> Maybe it should! Can you point me to some examples? > > Eg. > > $ epsg_tr.py -proj4 2180 > # ETRS89 / Poland CS92 > <2180> +proj=tmerc +lat_0=0 +lon_0=19 +k=0.999300 +x_0=500000 > +y_0=-5300000 +ellps=GRS80 +units=m +no_defs <> > ^ > | > There units here ------------- > > But, in a location created with "g.proj -c proj4='+init=epsg:2180'", > units are missing from "g.proj -j" output: Yes, that was a bug. Well spotted! It had been there for a few years. Fixed in CVS now. The reason it was missing: the use of PROJ in GRASS pre-dates PROJ's support of a unit factor. With "classic" PROJ, the units were always in metres anyway. A reminder of this can still be seen today in that the false easting and northing must always be given in metres, even if the unit of the projection is something different. So anyway GRASS handled the unit factor separately because PROJ didn't support it in the early 1990s. But if the PROJ output is for external use (as in g.proj -j) then we must include the unit factor as an external program might want to make use of it. > $ g.proj -jf > +proj=tmerc +lat_0=0 +lon_0=19 +k=0.999300 +x_0=500000 +y_0=-5300000 > +no_defs +a=6378137 +rf=298.257222101 +towgs84=0.000,0.000,0.000 > ^ > |------------------------------- > | > Another thing - is no_defs on right place here? I *guess* it should be > on the very end, ?. I think it is OK anywhere. All it is doing is telling PROJ not to read any defaults from it's default file should something appear to be missing. The only parameters it should use are those supplied. If you see any documentation that suggests it needs to be at the end then of course, let me know. Paul From michael.barton at asu.edu Fri Jan 5 23:42:40 2007 From: michael.barton at asu.edu (Michael Barton) Date: Fri Jan 5 23:42:50 2007 Subject: [GRASS-dev] GRASS startup window patches In-Reply-To: <2b3d8c1c0701050927q34503896nf22c4de307f46485@mail.gmail.com> Message-ID: Maris, A short while back, I started trying to improve the startup in general and for windows in particular. The work I did on the epsg option was a test to see if this worked better. I've been waiting for some updates to g.proj before going on to make some similar improvements to the georef file location creator. I didn't want to fix it one way, and then have to change to a different routine if g.proj is updated. The issue with g.proj is that in order to create a new location (only one of the things that g.proj does) it needs to have at least one valid location and mapset already set. This makes sense for most of what g.proj does, but not for making a new location. This is of course problematic for first time use where a valid location does not yet exist. The epsg option gets around this by creating a temporary fake location in case one doesn't yet exist, creating the desired location with g.proj, and then deleting the fake location. This is cumbersome and could cause problems if the process is halted mid-way through. However, if an update to g.proj is not forthcoming, perhaps I can just go ahead and fix the georef location creator in the same way as the epsg option. I'll try out your patches first. It looks like the ones to the epsg option serve to internationalize the GUI (good idea). I'm not sure what is happing with the changes to gis_set.tcl. Could you summarize so I know what to look for. Thanks very much for this. Michael On 1/5/07 10:27 AM, "Maris Nartiss" wrote: > Hi all, > > as last night I had loooong chat with some first time GRASS user, who > was hit by problems in GRASS startup screen (paritaly fixed in 6.3), > thus today I spent some time on fixing small usability problems of > startup screen. > > Please, somebody review them and commit to CVS. > > And another question - epsg_option.tcl uses "exec g.proj" to call > g.proj. Is possible (safe) to use same approach to create new location > from georeferenced file? If yes, then it's just copy/paste epsg_option > code and a bit to tweak to make georef location creator as same good > like epsg one :) > > Maris. __________________________________________ 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 dca.gis at gmail.com Fri Jan 5 23:58:23 2007 From: dca.gis at gmail.com (Daniel Calvelo) Date: Fri Jan 5 23:58:24 2007 Subject: [GRASS-dev] gis.m crashes on zoom to map existing in more than one mapset In-Reply-To: <17822.22400.497161.234470@cerise.gclements.plus.com> References: <459CFD37.1060408@club.worldonline.be> <17822.22400.497161.234470@cerise.gclements.plus.com> Message-ID: <1a486f560701051458q4b7e5091h9ddcde06112d9872@mail.gmail.com> On 1/5/07, Glynn Clements wrote: > > Moritz Lennert wrote: > > > The command used in mapcanvas.tcl is g.region -ugp rast=bugsites. This > > gives: > > > > GRASS 6.3.cvs (spearfish60):~ > g.region -ugp rast=bugsites > > WARNING: 'cell/bugsites' was found in more mapsets (also found in user1). > > This is a good example of why the solution to the recent > g.region/gis.m issues is to make gis.m handle warnings correctly > rather than trying to eliminate specific warnings. > > Even the simplest program can potentially result in warnings (or > similar diagnostics) being generated by libgis (or other libraries) in > some cases. And for third-party libraries (of which GDAL may use a > significant number), there is nothing which can be done about it. Would having G_warning() output "#WARNING:" help? The initial '#' would be parseable as a comment, as it is in the shell. And alongside, eval of output in scripts wouldn't be affected. Of course, strict discipline of using G_* messages is compulsory. > Tcl's behaviour of treating anything written to stderr as an error is > a nuisance, but one which has to be dealt with so long as we continue > to use Tcl. IMO, this is THE reason to get serious about wxPython. 2c. Daniel. -- -- Daniel Calvelo Aros From dca.gis at gmail.com Sat Jan 6 00:07:24 2007 From: dca.gis at gmail.com (Daniel Calvelo) Date: Sat Jan 6 00:07:26 2007 Subject: [GRASS-dev] g.list -a In-Reply-To: References: <17806.65476.593110.361071@cerise.gclements.plus.com> <17809.48637.726595.182177@cerise.gclements.plus.com> <1a486f560701030845j37776763m4350ff8d011d9984@mail.gmail.com> Message-ID: <1a486f560701051507r4e666e00r9460246917a4057e@mail.gmail.com> [me] > How about g.list type=any or g.list type=all? [Martin] > it is nice idea but there is one problem. The data type list is common > for related modules, e.g. g.remove, g.copy, etc. It would affect them > also... Don't you think it might be helpful there as well? I agree it is some more work to get the semantics and implementation right in all the actual cases, but I've the feeling it might be of some use... Daniel. From michael.barton at asu.edu Sat Jan 6 00:15:52 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sat Jan 6 00:16:01 2007 Subject: [GRASS-dev] GRASS startup window patches In-Reply-To: <2b3d8c1c0701050927q34503896nf22c4de307f46485@mail.gmail.com> Message-ID: I haven't seen any problem with these patches but will want to know what the gis_set.tcl patches do before committing it. There is still a problem with the epsg code browsing that I ran into before. This is the setting of "PROJSHARE", the location of the epsg file. Supposedly, this is set during compilation. I had thought that it wasn't being set properly on my Mac binaries. But I checked a recent compile and it is being set. At least, this is the only place I can see to set it... --with-proj-includes=/Library/Frameworks/PROJ.framework/Headers --with-proj-libs=/Library/Frameworks/PROJ.framework/unix/lib --with-proj-share=/Library/Frameworks/PROJ.framework/Resources/proj However, the way that the epsg file location is treated in the TclTk code seems strange. This is the way it is now... set epsgOpt::browsedepsg "PROJSHARE/epsg" ...where epsgOpt is a variable whose value will be automatically inserted into the epsg file browse window as a default. I would normally think that some kind of environmental variable PROSHARE, would be written as $PROJSHARE or $env(PROJSHARE) in the TclTk script. But someone told me that it should be written as PROJSHARE (i.e., no string substitution). I can't find the email of whoever it was (Glynn??). Anyway, with this construction, what actually shows up in the epsg file browse widget on my Mac is "PROJSHARE/epsg" and not "/Library/Frameworks/PROJ.framework/Resources/proj" (which is what it should be). Neither $PROJSHARE nor $env(PROJSHARE) exists as variables, however. So does anyone know what is wrong? Does this work properly on Linux systems currently (that is, does it give a proper path to the epsg file)? If so, any idea why it doesn't on the Mac? Michael On 1/5/07 10:27 AM, "Maris Nartiss" wrote: > Hi all, > > as last night I had loooong chat with some first time GRASS user, who > was hit by problems in GRASS startup screen (paritaly fixed in 6.3), > thus today I spent some time on fixing small usability problems of > startup screen. > > Please, somebody review them and commit to CVS. > > And another question - epsg_option.tcl uses "exec g.proj" to call > g.proj. Is possible (safe) to use same approach to create new location > from georeferenced file? If yes, then it's just copy/paste epsg_option > code and a bit to tweak to make georef location creator as same good > like epsg one :) > > Maris. __________________________________________ 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 Jan 6 00:28:55 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sat Jan 6 00:29:09 2007 Subject: [GRASS-dev] gis.m crashes on zoom to map existing in more than one mapset In-Reply-To: <17822.22400.497161.234470@cerise.gclements.plus.com> Message-ID: I just committed Paul's fix that pipes g.region commands through grocat. Maybe check to see if this fixes this crash on warning too. Michael On 1/5/07 6:49 AM, "Glynn Clements" wrote: > > Moritz Lennert wrote: > >> I don't know if this is just another manifestation of the changes in >> g.region, but gis.m crashes when I try to zoom to a map which exists in >> more than one mapset of the current location. >> >> To reproduce in spearfish, in mapset user1: >> >> 1) g.copy rast=bugsites@PERMANENT,bugsites (or any other raster or >> vector map) >> >> 2) display bugsites >> >> 3) zoom to selected map >> >> The command used in mapcanvas.tcl is g.region -ugp rast=bugsites. This >> gives: >> >> GRASS 6.3.cvs (spearfish60):~ > g.region -ugp rast=bugsites >> WARNING: 'cell/bugsites' was found in more mapsets (also found in user1). > > This is a good example of why the solution to the recent > g.region/gis.m issues is to make gis.m handle warnings correctly > rather than trying to eliminate specific warnings. > > Even the simplest program can potentially result in warnings (or > similar diagnostics) being generated by libgis (or other libraries) in > some cases. And for third-party libraries (of which GDAL may use a > significant number), there is nothing which can be done about it. > > Tcl's behaviour of treating anything written to stderr as an error is > a nuisance, but one which has to be dealt with so long as we continue > to use Tcl. __________________________________________ 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 Jan 6 05:53:02 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Jan 6 05:53:10 2007 Subject: [GRASS-dev] g.list -a In-Reply-To: <1a486f560701051507r4e666e00r9460246917a4057e@mail.gmail.com> References: <17806.65476.593110.361071@cerise.gclements.plus.com> <17809.48637.726595.182177@cerise.gclements.plus.com> <1a486f560701030845j37776763m4350ff8d011d9984@mail.gmail.com> <1a486f560701051507r4e666e00r9460246917a4057e@mail.gmail.com> Message-ID: <17823.11054.35596.752944@cerise.gclements.plus.com> Daniel Calvelo wrote: > [me] > > How about g.list type=any or g.list type=all? > > [Martin] > > it is nice idea but there is one problem. The data type list is common > > for related modules, e.g. g.remove, g.copy, etc. It would affect them > > also... > > Don't you think it might be helpful there as well? It's used differently; g.list has a type= option where the valid option values are the types, while g.remove, g.rename and g.copy have a separate option for each type. In terms of implementing "g.list type=all", the obvious first step would be to add element->multiple=YES to the type= option so that you can do e.g. "g.list type=rast,vect". Once that was done, it would be relatively straightforward to allow "type=all". -- Glynn Clements From glynn at gclements.plus.com Sat Jan 6 06:18:24 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Jan 6 06:18:36 2007 Subject: [GRASS-dev] GRASS startup window patches In-Reply-To: References: <2b3d8c1c0701050927q34503896nf22c4de307f46485@mail.gmail.com> Message-ID: <17823.12576.712805.194692@cerise.gclements.plus.com> Paul Kelly wrote: > As we saw in the discussions about g.region and gis.m, using the Tcl catch > commands on GRASS commands isn't generally a good idea On the contrary, most exec (and "open |...") commands *should* use catch so that errors (either real errors or Tcl complaining about stderr) aren't fatal. > as Tcl falsely > assumes a command that writes to stderr is issuing an error. This applies > to g.proj too. If partially-specified datum information is passed to > g.proj, it WILL try to interactively prompt the user for complete > information. This is done by printing to stderr and looking for an input > on stdin.(The Tcl catch command will treat this as an error.) There are > also circumstances where g.proj will issue a warning (but still proceed to > create the location OK), and again this writes to stderr and the catch > command will erroneously assume there is an error. No, it's exec which treats it as an error; the catch command catches the exception which exec throws so that it doesn't terminate the program. > I think, until we can work out some way of always passing fully specified > datum information to g.proj, that when g.proj is used for location set-up > we should run it in a pop-up terminal Window. So if it does choose to > prompt the user it (while kludgy and archaic-looking) will actually work. What is the problem with simply removing the "interactive" parameter from GPJ_{osr,wkt}_to_grass()? -- Glynn Clements From glynn at gclements.plus.com Sat Jan 6 06:22:39 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Jan 6 06:22:49 2007 Subject: [GRASS-dev] gis.m crashes on zoom to map existing in more than one mapset In-Reply-To: <1a486f560701051458q4b7e5091h9ddcde06112d9872@mail.gmail.com> References: <459CFD37.1060408@club.worldonline.be> <17822.22400.497161.234470@cerise.gclements.plus.com> <1a486f560701051458q4b7e5091h9ddcde06112d9872@mail.gmail.com> Message-ID: <17823.12831.474749.548561@cerise.gclements.plus.com> Daniel Calvelo wrote: > > > The command used in mapcanvas.tcl is g.region -ugp rast=bugsites. This > > > gives: > > > > > > GRASS 6.3.cvs (spearfish60):~ > g.region -ugp rast=bugsites > > > WARNING: 'cell/bugsites' was found in more mapsets (also found in user1). > > > > This is a good example of why the solution to the recent > > g.region/gis.m issues is to make gis.m handle warnings correctly > > rather than trying to eliminate specific warnings. > > > > Even the simplest program can potentially result in warnings (or > > similar diagnostics) being generated by libgis (or other libraries) in > > some cases. And for third-party libraries (of which GDAL may use a > > significant number), there is nothing which can be done about it. > > Would having G_warning() output "#WARNING:" help? The initial '#' > would be parseable as a comment, as it is in the shell. And alongside, > eval of output in scripts wouldn't be affected. Of course, strict > discipline of using G_* messages is compulsory. Programs shouldn't attempt to parse stderr. Merging stdout and stderr is purely a workaround for a Tcl misfeature (treating anything written to stderr as an error). In the case where you're actually parsing the output (rather than just dumping it to the "gronsole" widget), it's the wrong workaround. In that case, stderr should be redirected to a file or discarded (redirected to /dev/null or NUL). -- Glynn Clements From glynn at gclements.plus.com Sat Jan 6 06:30:52 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Jan 6 06:33:32 2007 Subject: [GRASS-dev] Re: gis.m crashes on zoom to map existing in more than one mapset In-Reply-To: References: Message-ID: <17823.13324.7282.189913@cerise.gclements.plus.com> Paul Kelly wrote: > Right. So catch isn't useful for GRASS commands then as in GRASS, a module > writing to stderr is not equivalent to an error condition. It's useful insofar as it allows you to ignore the error and continue. > Messages and > warnings also go to stderr, and we need to use something like grocat to > redirect these away from stderr and stop them making Tcl think there is an > error. The problem with the "|& grocat" approach is that you then get stderr output merged with normal module output. This isn't an issue if you're just dumping everything to the gronsole for the user to read, but it is an issue if you plan to parse the output. Even if the parser silently ignores everything which it doesn't understand, there's no guarantee that messages written to stderr won't conform to the parsed syntax and thus be interpreted as "output". I would suggest having a global variable which refers to a "sink" to which stderr can be safely redirected in situations like this. Valid values would be anything which can appear after "2>" in an exec (or "open |...") command, e.g. @stderr (i.e. gis.m's stderr, typically a terminal, although this may not be valid on non-Unix systems), the name of a log file, or /dev/null (or NUL on Windows). -- Glynn Clements From glynn at gclements.plus.com Sat Jan 6 07:51:15 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Jan 6 07:54:29 2007 Subject: [GRASS-dev] Re: gis.m crashes on zoom to map existing in more than one mapset In-Reply-To: <17823.13324.7282.189913@cerise.gclements.plus.com> References: <17823.13324.7282.189913@cerise.gclements.plus.com> Message-ID: <17823.18147.706206.919741@cerise.gclements.plus.com> Glynn Clements wrote: > I would suggest having a global variable which refers to a "sink" to > which stderr can be safely redirected in situations like this. Valid > values would be anything which can appear after "2>" in an exec (or > "open |...") command, e.g. @stderr (i.e. gis.m's stderr, typically a > terminal, although this may not be valid on non-Unix systems), the > name of a log file, or /dev/null (or NUL on Windows). In case it wasn't obvious, the idea is that code which doesn't want stderr mixed with stdout and doesn't want exceptions can just add "2> $sink" to make stderr "go away". We can argue over where to send it later. Apart from the terminal, a log file or /dev/null, there's also the possibility of redirecting it to a FIFO, from where gis.m can read it and send it to the gronsole. However, this approach can potentially stall the child process if gis.m doesn't keep the FIFO drained. In most cases, writing stderr to a temporary file then dumping the contents to the gronsole afterwards would be preferable. -- Glynn Clements From paul-grass at stjohnspoint.co.uk Sat Jan 6 10:22:44 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Sat Jan 6 10:22:50 2007 Subject: [GRASS-dev] gis.m crashes on zoom to map existing in more than one mapset In-Reply-To: <17823.12831.474749.548561@cerise.gclements.plus.com> References: <459CFD37.1060408@club.worldonline.be> <17822.22400.497161.234470@cerise.gclements.plus.com> <1a486f560701051458q4b7e5091h9ddcde06112d9872@mail.gmail.com> <17823.12831.474749.548561@cerise.gclements.plus.com> Message-ID: On Sat, 6 Jan 2007, Glynn Clements wrote: > Merging stdout and stderr is purely a workaround for a Tcl misfeature > (treating anything written to stderr as an error). In the case where > you're actually parsing the output (rather than just dumping it to the > "gronsole" widget), it's the wrong workaround. In that case, stderr > should be redirected to a file or discarded (redirected to /dev/null > or NUL). Of course. That's the simple and more obvious fix for the recent g.region issues. I've updated gui/tcltk/gis.m/mapcanvas.tcl (after Michael's fixes last night) to just discard stderr after all those g.region calls instead of merging it with stdout. So the calls to g.region should be tripley robust now (catch, discarding stderr, and checking the output lines match a regexp). From paul-grass at stjohnspoint.co.uk Sat Jan 6 12:27:35 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Sat Jan 6 12:27:38 2007 Subject: [GRASS-dev] GRASS startup window patches In-Reply-To: <17823.12576.712805.194692@cerise.gclements.plus.com> References: <2b3d8c1c0701050927q34503896nf22c4de307f46485@mail.gmail.com> <17823.12576.712805.194692@cerise.gclements.plus.com> Message-ID: On Sat, 6 Jan 2007, Glynn Clements wrote: >> as Tcl falsely >> assumes a command that writes to stderr is issuing an error. This applies >> to g.proj too. If partially-specified datum information is passed to >> g.proj, it WILL try to interactively prompt the user for complete >> information. This is done by printing to stderr and looking for an input >> on stdin.(The Tcl catch command will treat this as an error.) There are >> also circumstances where g.proj will issue a warning (but still proceed to >> create the location OK), and again this writes to stderr and the catch >> command will erroneously assume there is an error. > > No, it's exec which treats it as an error; the catch command catches > the exception which exec throws so that it doesn't terminate the > program. Yes that's right of course - what I was getting at was gis.m treats it as an error really - it skips over what it was supposed to be doing, so in general it stays running but is an undefined state as some variables haven't been set and you need to re-start it to get back to doing something useful. But not a lot that can be done about this. >> I think, until we can work out some way of always passing fully specified >> datum information to g.proj, that when g.proj is used for location set-up >> we should run it in a pop-up terminal Window. So if it does choose to >> prompt the user it (while kludgy and archaic-looking) will actually work. > > What is the problem with simply removing the "interactive" parameter > from GPJ_{osr,wkt}_to_grass()? Because then, if there is partially-specified datum information, a (likely sub-optimal) default set of datum parameters must be used. I tried to explain this here: http://www.nabble.com/g.proj-and-datum-information-%28and-gis.m%29-t2484411.html#a6928102 and haven't come up with an easier solution since then. All I can say that if, either no datum information at all, or fully specified (i.e. datum name and parameters) are passed to g.proj as part of the input co-ordinate system description, then it won't attempt to interactively prompt. IMHO perhaps we need to look at ways the GUI can verify that the datum information is complete before it attempts to create the location? I really don't know what's best. Paul From glynn at gclements.plus.com Sat Jan 6 15:04:28 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Jan 6 15:04:32 2007 Subject: [GRASS-dev] GRASS startup window patches In-Reply-To: References: <2b3d8c1c0701050927q34503896nf22c4de307f46485@mail.gmail.com> <17823.12576.712805.194692@cerise.gclements.plus.com> Message-ID: <17823.44140.49512.674843@cerise.gclements.plus.com> Paul Kelly wrote: > >> I think, until we can work out some way of always passing fully specified > >> datum information to g.proj, that when g.proj is used for location set-up > >> we should run it in a pop-up terminal Window. So if it does choose to > >> prompt the user it (while kludgy and archaic-looking) will actually work. > > > > What is the problem with simply removing the "interactive" parameter > > from GPJ_{osr,wkt}_to_grass()? > > Because then, if there is partially-specified datum information, a (likely > sub-optimal) default set of datum parameters must be used. I tried to > explain this here: > http://www.nabble.com/g.proj-and-datum-information-%28and-gis.m%29-t2484411.html#a6928102 > and haven't come up with an easier solution since then. All I can say that > if, either no datum information at all, or fully specified (i.e. datum > name and parameters) are passed to g.proj as part of the input co-ordinate > system description, then it won't attempt to interactively prompt. IMHO > perhaps we need to look at ways the GUI can verify that the datum > information is complete before it attempts to create the location? I > really don't know what's best. Regardless of what's best, interactive prompting is worst. I don't have a problem with an approach where anything which isn't explicitly specified gets a default value. IMHO, what really matters is that the user has some way to provide this information; it's not up to us to force them to do so. If using a default isn't considered acceptable, then missing parameters should result in an error, not terminal interaction. As it stands, if you want g.proj to ensure that the defaults aren't used, it should just be a matter of ensuring that the proj4= option contains either towgs84= or nadgrids=, no? However, I would favour replacing the GPJ_ask_datum_params() call in GPJ_osr_to_grass() with G_fatal_error(). In the absence of complete datum information, the choice provided by the "interactive" parameter would then be default-vs-error rather than default-vs-prompt. This would eliminate the need to modify g.proj. Prompting assumes the existence of stdin, and in most cases[1] assuming the existence of stdin is a bug. [1] The main exception being when the user explicitly requests the use of stdin. Libraries should *never* use stdin. Apart from GPJ_osr_to_grass(), the only other use of GPJ_ask_datum_params() is in g.setproj, which is still a complete mess. A fair amount of it could be made non-interactive by changing the functions in get_num.c to obtain the requested parameter from a key=value list rather than prompting for it. Most of the mess is due to all the hard-coded special cases. -- Glynn Clements From paul-grass at stjohnspoint.co.uk Sat Jan 6 15:57:10 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Sat Jan 6 15:57:13 2007 Subject: [GRASS-dev] G_tempfile() proposed changes [relevant to creating a new location] Message-ID: I've had the attached changes (to G_tempfile(), g.tempfile and a couple of other places) sitting around for a while, but Michael's comment about changes to g.proj being forthcoming reminded me to hurry up and put them forward for discussion. The changes amount to: * Re-naming the current G_tempfile() to G_tempfile_in_mapset(). * Change the calls to G_tempfile() in lib/gis/opencell.c to use the new function G_tempfile_in_mapset() * Write a new G_tempfile() that puts a tempfile in the directory pointed to by the TEMP environment variable if it exists (this will be somewhere writeable by the user on Windows) or P_tmpdir otherwise (/tmp on Unix or root of current drive on Windows). * Add a new command-line flag to g.tempfile to allow it to create a tempfile in the current mapset if necessary. * Change r.in.aster (as an example) to use g.tempfile in this way. There would be more examples I'm sure we could find that want to create a large tempfile somewhere there's more than likely to be enough space - the original purpose of G_tempfile, according to comments in the source. Although perhaps that's not all that relevant. Perhaps in the past /tmp might have been likely to be very small? The reason I haven't applied the changes yet is that I'm slightly worried about what the effect might be of the sudden change. In particular, that tempfiles created by the current G_tempfile (i.e. in the current mapset) get cleaned up at the end of the session and after the change they won't. Should we just change it and fix things on a case-by-case basis? (Either change them to create the tempfile in the mapset, or force them to delete it?) A bit of a dilemma. Paul -------------- next part -------------- Index: general/g.tempfile/description.html =================================================================== RCS file: /home/grass/grassrepository/grass6/general/g.tempfile/description.html,v retrieving revision 1.2 diff -u -r1.2 description.html --- general/g.tempfile/description.html 7 Dec 2005 13:31:15 -0000 1.2 +++ general/g.tempfile/description.html 3 Jan 2007 21:36:12 -0000 @@ -1,12 +1,19 @@

DESCRIPTION

+

g.tempfile is designed for shell scripts that need to use large temporary files. GRASS provides a mechanism for temporary files that does not depend on -/tmp. GRASS temporary files are created in the data base with the assumption +the system temporary directory (e.g. /tmp on Unix). When the -m flag is +specified, g.tempfile creates a file in the data base with the assumption that there will be enough space under the data base for large files. GRASS periodically removes temporary files that have been left behind -by programs that failed to remove them before terminating. +by programs that failed to remove them before terminating. +

+

+When the -m flag is not specified, the temporary filename given is located +in the normal system temporary directory. This tends to be more suitable for +smaller files.

@@ -33,16 +40,20 @@

NOTES

+

Each call to g.tempfile creates a different (i.e. unique) name. - -Although GRASS does eventually get around to removing -tempfiles that have been left behind, the programmer should +

+

+Although GRASS does remove tempfiles that have been left behind +at the start and finish of every session, the programmer should make every effort to remove these files. They often get large and take up disk space. If you write /bin/sh scripts, learn to use the /bin/sh trap command. If you write /bin/csh scripts, learn to use the /bin/csh -onintr command. +onintr command. This is especially important if the -m flag +is not used, as the temporary files will not then be deleted by GRASS. +

AUTHOR

Index: general/g.tempfile/main.c =================================================================== RCS file: /home/grass/grassrepository/grass6/general/g.tempfile/main.c,v retrieving revision 2.3 diff -u -r2.3 main.c --- general/g.tempfile/main.c 19 Aug 2006 12:52:20 -0000 2.3 +++ general/g.tempfile/main.c 3 Jan 2007 21:36:12 -0000 @@ -10,6 +10,7 @@ { struct GModule *module; struct Option *pid; + struct Flag *mapset; char *tempfile, *G__tempfile(); int p; @@ -27,6 +28,11 @@ pid->required = YES; pid->description = "Process id to use when naming the tempfile"; + mapset = G_define_flag(); + mapset->key = 'm'; + mapset->description = "Create tempfile in current mapset (will be" + "automatically deleted on exiting GRASS session)"; + G_disable_interactive(); if (G_parser(argc,argv)) exit(1); @@ -35,7 +41,10 @@ G_usage(); exit(1); } - tempfile = G__tempfile(p); + if (mapset->answer) + tempfile = G__tempfile_in_mapset(p); + else + tempfile = G__tempfile(p); umask(0); /* create tempfile so next run of this program will create a unique name */ close(creat(tempfile,0666)); Index: include/gisdefs.h =================================================================== RCS file: /home/grass/grassrepository/grass6/include/gisdefs.h,v retrieving revision 1.76 diff -u -r1.76 gisdefs.h --- include/gisdefs.h 20 Dec 2006 19:10:36 -0000 1.76 +++ include/gisdefs.h 3 Jan 2007 21:36:18 -0000 @@ -1107,7 +1107,9 @@ /* tempfile.c */ char *G_tempfile(void); +char *G_tempfile_in_mapset(void); char *G__tempfile(int); +char *G__tempfile_in_mapset(int); int G__temp_element(char *); /* timestamp.c */ Index: lib/gis/opencell.c =================================================================== RCS file: /home/grass/grassrepository/grass6/lib/gis/opencell.c,v retrieving revision 2.8 diff -u -r2.8 opencell.c --- lib/gis/opencell.c 13 Dec 2006 14:21:36 -0000 2.8 +++ lib/gis/opencell.c 3 Jan 2007 21:36:25 -0000 @@ -627,7 +627,7 @@ G__init_window(); /* open a tempfile name */ - tempname = G_tempfile (); + tempname = G_tempfile_in_mapset (); fd = creat (tempname, 0666); if (fd < 0) { @@ -731,7 +731,7 @@ fcb->cur_row = 0; /* open a null tempfile name */ - tempname = G_tempfile (); + tempname = G_tempfile_in_mapset (); null_fd = creat (tempname, 0666); if (null_fd < 0) { Index: lib/gis/tempfile.c =================================================================== RCS file: /home/grass/grassrepository/grass6/lib/gis/tempfile.c,v retrieving revision 2.4 diff -u -r2.4 tempfile.c --- lib/gis/tempfile.c 18 Dec 2006 08:09:36 -0000 2.4 +++ lib/gis/tempfile.c 3 Jan 2007 21:36:26 -0000 @@ -11,36 +11,62 @@ * \date 1999-2006 */ +#include +#include #include #include #include +#include #include - -/** - * \fn char *G_tempfile (void) +/*! + * \brief returns a temporary file name on the same disk as the current mapset * - * \brief Returns a temporary file name. + * This function returns a pointer to a string containing a unique file name + * that can be used as a temporary file within the module. Successive calls + * to the function will generate new names. + * + * Only the file name is generated. The file itself is not created. To create the + * file, the module must use standard UNIX functions which create and open files, + * e.g., creat() or fopen(). The filename is guaranteed to be on the same disk + * as the current mapset. This means that "draft" output maps can + * be moved (with either link()+remove() or rename()) into their final + * location upon closure. + * + * The programmer should take reasonable care to remove (unlink) the file + * before the module exits. However, GRASS database management will + * eventually remove all temporary files created by G_tempfile_in_mapset() + * that have been left behind by the modules which created them. + * + * \return char: pointer to a character string containing the name. + * the name is copied to allocated memory and may be + * released by the unix free () routine. + */ + +char *G_tempfile_in_mapset(void) +{ + return G__tempfile_in_mapset(getpid()); +} + +/*! + * \brief returns a temporary file name * - * This routine returns a pointer to a string containing a unique - * temporary file name that can be used as a temporary file within the - * module. Successive calls to G_tempfile() will generate new - * names. Only the file name is generated. The file itself is not - * created. To create the file, the module must use standard UNIX - * functions which create and open files, e.g., creat() or - * fopen().
- * - * Successive calls will generate different names the names are of the - * form pid.n where pid is the programs process id number and n is a - * unique identifier.
- * - * Note: It is recommended to unlink() (remove) the - * temp file on exit/error. Only if GRASS is left with 'exit', the GIS - * mapset manangement will clean up the temp directory (ETC/clean_temp). - * - * \return pointer to a character string containing the name. The name - * is copied to allocated memory and may be released by the unix free() - * routine. + * This function returns a pointer to a string containing a unique file name + * that can be used as a temporary file within the module. Successive calls + * to the function will generate new names. + * + * Only the file name is generated. The file itself is not created. To create the + * file, the module must use standard UNIX functions which create and open files, + * e.g., creat() or fopen(). + * + * The programmer should take care to remove (unlink) the file before + * the module exits. If a module requires not to immediately delete a + * temporary file and instead have it automatically deleted at the end of + * the GRASS session, G_tempfile_in_mapset() should be used instead. + * + * \return char: pointer to a character string containing the name. + * the name is copied to allocated memory and may be + * released by the unix free () routine. */ char *G_tempfile(void) @@ -48,10 +74,7 @@ return G__tempfile(getpid()); } - /** - * \fn char *G__tempfile (int pid) - * * \brief Create tempfile from process id. * * See G_tempfile(). @@ -62,6 +85,60 @@ char *G__tempfile (int pid) { + char *env_temp = getenv("TEMP"); + char *prefix, *path = NULL; + char dirsep_char[2]; + static int uniq = 0; + struct stat st; + + if (pid <= 0) + pid = getpid(); + + if (env_temp != NULL) + /* This should be somewhere in user profile directory on Windows, + * thus ensuring write permission */ + prefix = G_store(env_temp); + else + /* Usually /tmp on Unix or root of current drive on Windows */ + prefix = G_store(P_tmpdir); + + /* Often there's no harm in having an extra directory separator character + * in the middle of a path but just being careful here. */ + if (G_is_dirsep( prefix[strlen(prefix)-1] )) { + dirsep_char[0] = '\0'; + } + else { + dirsep_char[0] = GRASS_DIRSEP; + dirsep_char[1] = '\0'; + } + + do { + if (path != NULL) + G_free(path); + path = G_malloc(strlen(prefix) + 40 ); + sprintf(path, "%s%sgrass-%d.%d", prefix, dirsep_char, pid, uniq++); + /* We use '/'-style dirseps within GRASS */ + G_convert_dirseps_from_host( path ); + } while (stat(path, &st) == 0); + + G_free(prefix); + + return path; + +} + + +/** + * \brief Create tempfile in current mapset from process id. + * + * See G_tempfile_in_mapset(). + * + * \param[in] pid + * \return Pointer to string path + */ + +char *G__tempfile_in_mapset (int pid) +{ char path[1024]; char name[GNAME_MAX]; char element[100]; @@ -78,13 +155,14 @@ } while (stat(path, &st) == 0) ; + /* We use '/'-style dirseps within GRASS */ + G_convert_dirseps_from_host (path); + return G_store (path); } /** - * \fn int G__temp_element (char *element) - * * \brief Populates element with a path string. * * \param[in,out] element Index: scripts/r.in.aster/r.in.aster =================================================================== RCS file: /home/grass/grassrepository/grass6/scripts/r.in.aster/r.in.aster,v retrieving revision 1.5 diff -u -r1.5 r.in.aster --- scripts/r.in.aster/r.in.aster 19 Aug 2006 12:52:24 -0000 1.5 +++ scripts/r.in.aster/r.in.aster 3 Jan 2007 21:36:39 -0000 @@ -138,7 +138,7 @@ srcfile=$GIS_OPT_INPUT fi -tempfile=`g.tempfile $$`.tif +tempfile=`g.tempfile -m $$`.tif #run gdalwarp with selected options (must be in $PATH) #to translate aster image to geotiff From paul-grass at stjohnspoint.co.uk Sat Jan 6 16:23:51 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Sat Jan 6 16:23:53 2007 Subject: [GRASS-dev] GRASS startup window patches In-Reply-To: <17823.44140.49512.674843@cerise.gclements.plus.com> References: <2b3d8c1c0701050927q34503896nf22c4de307f46485@mail.gmail.com> <17823.12576.712805.194692@cerise.gclements.plus.com> <17823.44140.49512.674843@cerise.gclements.plus.com> Message-ID: On Sat, 6 Jan 2007, Glynn Clements wrote: > > Paul Kelly wrote: > >>>> I think, until we can work out some way of always passing fully specified >>>> datum information to g.proj, that when g.proj is used for location set-up >>>> we should run it in a pop-up terminal Window. So if it does choose to >>>> prompt the user it (while kludgy and archaic-looking) will actually work. >>> >>> What is the problem with simply removing the "interactive" parameter >>> from GPJ_{osr,wkt}_to_grass()? >> >> Because then, if there is partially-specified datum information, a (likely >> sub-optimal) default set of datum parameters must be used. I tried to >> explain this here: >> http://www.nabble.com/g.proj-and-datum-information-%28and-gis.m%29-t2484411.html#a6928102 >> and haven't come up with an easier solution since then. All I can say that >> if, either no datum information at all, or fully specified (i.e. datum >> name and parameters) are passed to g.proj as part of the input co-ordinate >> system description, then it won't attempt to interactively prompt. IMHO >> perhaps we need to look at ways the GUI can verify that the datum >> information is complete before it attempts to create the location? I >> really don't know what's best. > > Regardless of what's best, interactive prompting is worst. > > I don't have a problem with an approach where anything which isn't > explicitly specified gets a default value. IMHO, what really matters > is that the user has some way to provide this information; it's not up > to us to force them to do so. > > If using a default isn't considered acceptable, then missing > parameters should result in an error, not terminal interaction. > > As it stands, if you want g.proj to ensure that the defaults aren't > used, it should just be a matter of ensuring that the proj4= option > contains either towgs84= or nadgrids=, no? That's right. The g.proj -d output (although I was thinking of removing it) already provides detailed information on the datum-related component of any input co-ordinate system. It might be useful if this was re-organised a bit and then another flag was added that would list the possible choices of datum parameters for a particular input co-ordinate system? Maybe the GUI could then run a couple of pre-processing steps using g.proj with different flags to determine if extra datum information was required, and get the user to select a particular set of parameters. How to merge them in with the user-provided co-ordinate system may not be easy though (it seems if proj4="+init=epsg:1234 +towgs84=1,2,3" is used, the PROJ-string parser in OGR ignores anything else once it has found a +init key). But we could maybe work around that. And then it would be more acceptable to fail with G_fatal_error if the datum information is not set (the "interactive" parameter in GPJ_osr_to_grass() would become a "fatal error" parameter). Maybe offer an extra flag to g.proj that the user could specify on the command-line to do interactive prompting (this would have to be moved out of the library function and into g.proj though). It's one possible option anyway. From michael.barton at asu.edu Sat Jan 6 16:58:37 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sat Jan 6 16:58:48 2007 Subject: [GRASS-dev] GRASS startup window patches In-Reply-To: <17823.44140.49512.674843@cerise.gclements.plus.com> Message-ID: >From the point of view of someone who needs to use this GRASS module in an external scripting environment, I agree with the proposal here. Michael On 1/6/07 7:04 AM, "Glynn Clements" wrote: > > Paul Kelly wrote: > >>>> I think, until we can work out some way of always passing fully specified >>>> datum information to g.proj, that when g.proj is used for location set-up >>>> we should run it in a pop-up terminal Window. So if it does choose to >>>> prompt the user it (while kludgy and archaic-looking) will actually work. >>> >>> What is the problem with simply removing the "interactive" parameter >>> from GPJ_{osr,wkt}_to_grass()? >> >> Because then, if there is partially-specified datum information, a (likely >> sub-optimal) default set of datum parameters must be used. I tried to >> explain this here: >> http://www.nabble.com/g.proj-and-datum-information-%28and-gis.m%29-t2484411.h >> tml#a6928102 >> and haven't come up with an easier solution since then. All I can say that >> if, either no datum information at all, or fully specified (i.e. datum >> name and parameters) are passed to g.proj as part of the input co-ordinate >> system description, then it won't attempt to interactively prompt. IMHO >> perhaps we need to look at ways the GUI can verify that the datum >> information is complete before it attempts to create the location? I >> really don't know what's best. > > Regardless of what's best, interactive prompting is worst. > > I don't have a problem with an approach where anything which isn't > explicitly specified gets a default value. IMHO, what really matters > is that the user has some way to provide this information; it's not up > to us to force them to do so. > > If using a default isn't considered acceptable, then missing > parameters should result in an error, not terminal interaction. > > As it stands, if you want g.proj to ensure that the defaults aren't > used, it should just be a matter of ensuring that the proj4= option > contains either towgs84= or nadgrids=, no? > > However, I would favour replacing the GPJ_ask_datum_params() call in > GPJ_osr_to_grass() with G_fatal_error(). In the absence of complete > datum information, the choice provided by the "interactive" parameter > would then be default-vs-error rather than default-vs-prompt. > > This would eliminate the need to modify g.proj. > > Prompting assumes the existence of stdin, and in most cases[1] > assuming the existence of stdin is a bug. > > [1] The main exception being when the user explicitly requests the use > of stdin. Libraries should *never* use stdin. > > Apart from GPJ_osr_to_grass(), the only other use of > GPJ_ask_datum_params() is in g.setproj, which is still a complete > mess. A fair amount of it could be made non-interactive by changing > the functions in get_num.c to obtain the requested parameter from a > key=value list rather than prompting for it. Most of the mess is due > to all the hard-coded special cases. __________________________________________ 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 Jan 6 17:07:43 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sat Jan 6 17:07:53 2007 Subject: [GRASS-dev] gis.m crashes on zoom to map existing in more than one mapset In-Reply-To: Message-ID: Thanks much Paul. The problem with the warning about duplicate map names, especially, was a long-standing bug that I previously saw no way around. This seems fixed very nicely now. Michael On 1/6/07 2:22 AM, "Paul Kelly" wrote: > On Sat, 6 Jan 2007, Glynn Clements wrote: > >> Merging stdout and stderr is purely a workaround for a Tcl misfeature >> (treating anything written to stderr as an error). In the case where >> you're actually parsing the output (rather than just dumping it to the >> "gronsole" widget), it's the wrong workaround. In that case, stderr >> should be redirected to a file or discarded (redirected to /dev/null >> or NUL). > > Of course. That's the simple and more obvious fix for the recent g.region > issues. I've updated gui/tcltk/gis.m/mapcanvas.tcl (after Michael's fixes > last night) to just discard stderr after all those g.region calls instead > of merging it with stdout. So the calls to g.region should be tripley > robust now (catch, discarding stderr, and checking the output lines match > a regexp). __________________________________________ 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 Jan 6 17:11:24 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sat Jan 6 17:11:32 2007 Subject: [GRASS-dev] G_tempfile() proposed changes [relevant to creating a new location] In-Reply-To: Message-ID: At least as far as the GUI goes, it tries to do its own cleanup of the tempfiles it creates. The development wxPython one does the same. AFAICT, these were never cleaned up automatically anyway. I wish they were, but it prompted me to include cleanup code that should be helpful in the current circumstance. Michael On 1/6/07 7:57 AM, "Paul Kelly" wrote: > I've had the attached changes (to G_tempfile(), g.tempfile and a couple of > other places) sitting around for a while, but Michael's comment about > changes to g.proj being forthcoming reminded me to hurry up and put them > forward for discussion. The changes amount to: > * Re-naming the current G_tempfile() to G_tempfile_in_mapset(). > * Change the calls to G_tempfile() in lib/gis/opencell.c to use the new > function G_tempfile_in_mapset() > * Write a new G_tempfile() that puts a tempfile in the directory pointed > to by the TEMP environment variable if it exists (this will be somewhere > writeable by the user on Windows) or P_tmpdir otherwise (/tmp on Unix or > root of current drive on Windows). > * Add a new command-line flag to g.tempfile to allow it to create a > tempfile in the current mapset if necessary. > * Change r.in.aster (as an example) to use g.tempfile in this way. There > would be more examples I'm sure we could find that want to create a large > tempfile somewhere there's more than likely to be enough space - the > original purpose of G_tempfile, according to comments in the source. > Although perhaps that's not all that relevant. Perhaps in the past /tmp > might have been likely to be very small? > > The reason I haven't applied the changes yet is that I'm slightly worried > about what the effect might be of the sudden change. In particular, that > tempfiles created by the current G_tempfile (i.e. in the current mapset) > get cleaned up at the end of the session and after the change they won't. > Should we just change it and fix things on a case-by-case basis? (Either > change them to create the tempfile in the mapset, or force them to delete > it?) A bit of a dilemma. > > Paul __________________________________________ 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 Jan 6 17:29:11 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sat Jan 6 17:29:23 2007 Subject: [GRASS-dev] GRASS startup window patches In-Reply-To: Message-ID: What about having a warning about the suboptimal datum being issued, now that we're on the way to dealing with such warnings in some way? This could suggest that the user run g.proj to correct the problems. Given that GRASS needs a location created to do anything, in some circumstances, it may be better to let g.proj go ahead and create a new location based on a georeferenced file and fix it later. A user may be well aware of the deficiencies in their data (or could be made aware via a warning) but simply needs to get the data up and visible to work with. It's always much better to have properly projected geodata, but I can certainly think of cases where all the stuff a user will be working with currently has the same deficiencies. I'm not trying to promote backing away from the fairly strict data quality standards that GRASS inherently tries to enforce. But just pointing out that there are cases where a user needs to be able to proceed in spite of data problems--which are often common in available products. Michael On 1/6/07 4:27 AM, "Paul Kelly" wrote: > Because then, if there is partially-specified datum information, a (likely > sub-optimal) default set of datum parameters must be used. I tried to > explain this here: > http://www.nabble.com/g.proj-and-datum-information-%28and-gis.m%29-t2484411.ht > ml#a6928102 > and haven't come up with an easier solution since then. All I can say that > if, either no datum information at all, or fully specified (i.e. datum > name and parameters) are passed to g.proj as part of the input co-ordinate > system description, then it won't attempt to interactively prompt. IMHO > perhaps we need to look at ways the GUI can verify that the datum > information is complete before it attempts to create the location? I > really don't know what's best. > __________________________________________ 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 Jan 6 18:03:57 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sat Jan 6 18:04:06 2007 Subject: [GRASS-dev] GRASS startup window patches In-Reply-To: Message-ID: Paul and Maris, I missed this message, but will try to catch up on responding to a few items. On 1/5/07 2:06 PM, "Paul Kelly" wrote: > Hello Maris, > A few points: > It's a bit hard to see what your patch does by looking at it - there seem > to be a lot of bogus changes where the line deleted and the line added are > the same - could it be an issue with Tab/space conversion settings in your > editor perhaps? > You don't need to put a changelog as comments in the file - it is saved > automatically when commited to CVS! Most of the epsg_options.tcl.in patch seems to be for internationalization. > > As we saw in the discussions about g.region and gis.m, using the Tcl catch > commands on GRASS commands isn't generally a good idea as Tcl falsely > assumes a command that writes to stderr is issuing an error. This applies > to g.proj too. If partially-specified datum information is passed to > g.proj, it WILL try to interactively prompt the user for complete > information. This is done by printing to stderr and looking for an input > on stdin.(The Tcl catch command will treat this as an error.) There are > also circumstances where g.proj will issue a warning (but still proceed to > create the location OK), and again this writes to stderr and the catch > command will erroneously assume there is an error. > > I think, until we can work out some way of always passing fully specified > datum information to g.proj, that when g.proj is used for location set-up > we should run it in a pop-up terminal Window. So if it does choose to > prompt the user it (while kludgy and archaic-looking) will actually work. > The procedure run_xterm in lib/gtcltk/gronsole.tcl has some Unix/Windows > Tcl code for running GRASS commands in a pop-up terminal Window (it would > be good to have this in a function for use by all the Tcl bits of GRASS, > not just those that use gronsole, but I'm not sure how to do that). Maybe for the moment, it would be best to add Paul's new code (done for mapcanvas.tcl last night) for stderr to this at the moment. Maybe the popup warning that Maris put in can be parsed OK, but I guess I'll need to look at it. I'm not in favor of using an interactive terminal for the reasons I've expressed before and Glynn's recent comments. I think the gronsole code is a bit misleading in this respect. It does allow you to run commands from a command line. It's the interactive part that doesn't work. > > But yes as you said below about using g.proj to create a new location > using a georeferenced file - that is exactly the same idea as using the > EPSG code. In fact better, as the recent update I made to g.proj a few > days ago now attempts to set initial region settings for the new location > from the extents of the file (using code taken from r.in.gdal and > v.in.ogr). I haven't really tested it yet though. The updates I did last night should make it possible to test this more. It seemed to work for me. > > Helena made the point that it was important to impress the concept of > setting the initial region for a location on the user, and that this was > lost a bit with the new "one click" location creation. I was thinking, > that it would be a good idea for the start-up GUI, after the location was > created, to read the region back in (using g.region probably) and then > present this to the user in a GUI screen similar to the curses-based > region setting that the old inter version of g.region used to have. If the > region had been set from a georeferenced file, it would probably be fine > and the user could just press OK, or if the location had been created e.g. > from an EPSG code there would just be a default 1pixel-sized region that > the user could then set. If a pretty GUI screen was created for this it > could also be used for setting the region in gis.m proper - the current > straight-down list of north, south, east, west, resolution etc. is > inferior IMHO to the old interactive terminal-based g.region. It's pretty easy to make a TclTk interface that mimics the curses-based one if this is desirable. The basic information from g.region can be put in the fields and allow the user to edit it. Dealing with projection information is much more complicated, which is why I haven't yet tackled a complete TclTk replacement for g.setproj. > > Before Christmas when I changed g.proj to call G_no_gisinit() instead of > G_gisinit(): that removed the issue whereby a whole template location with > valid mapset had to exist before actually creating a new location with > g.proj - now it just needs a GISRC file with the GISDBASE field set to > something valid. HOWEVER, the G_tempfile() issue (which does require a > valid current location and mapset) hasn't yet been fixed, so can't remove > all that stuff out of epsg_option.tcl just yet. But I will try and get the > time to propose something to the list soon and we can sort it out. I've made it so that creating a fake location can be pretty easily stripped out of epsg_option and file_option scripts. > > This e-mail has just been a bit of a brain-dump really, sorry about that A very helpful one. Thanks for all that both of you have been doing on this 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 rez at touchofmadness.com Sat Jan 6 18:26:47 2007 From: rez at touchofmadness.com (Brad Douglas) Date: Sat Jan 6 18:26:54 2007 Subject: [GRASS-dev] GRASS startup window patches In-Reply-To: References: Message-ID: <1168104407.18468.142.camel@devel> On Sat, 2007-01-06 at 09:29 -0700, Michael Barton wrote: > What about having a warning about the suboptimal datum being issued, now > that we're on the way to dealing with such warnings in some way? This could > suggest that the user run g.proj to correct the problems. > > Given that GRASS needs a location created to do anything, in some > circumstances, it may be better to let g.proj go ahead and create a new > location based on a georeferenced file and fix it later. A user may be well > aware of the deficiencies in their data (or could be made aware via a > warning) but simply needs to get the data up and visible to work with. It's > always much better to have properly projected geodata, but I can certainly > think of cases where all the stuff a user will be working with currently has > the same deficiencies. IMHO, that would be fine where absolutely necessary, with preference towards error wherever possible. The warnings should be verbose. Being too strict should be viewed as a [usability] bug. However, being too lax presents a separate set undesirable issues. -- Brad Douglas KB8UYR/6 Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From maris.gis at gmail.com Sat Jan 6 20:10:30 2007 From: maris.gis at gmail.com (Maris Nartiss) Date: Sat Jan 6 20:10:33 2007 Subject: [GRASS-dev] Re: GRASS startup window patches In-Reply-To: <1168104407.18468.142.camel@devel> References: <1168104407.18468.142.camel@devel> Message-ID: <2b3d8c1c0701061110g4550394ai11901cc1e8444449@mail.gmail.com> Hi all of You! I was not going to spawn such discussion, but it's damn good, as, hopefully, it will make GRASS more lamer friendly :) I have to apologizes about forgetting describe my patches. In my mind I was already looking how to fix other GRASS startup screen issues (Yes, there still are some of them) and forgot to tell everyone about what I'm doing. My apologies to all of you. I recreated gis_set patch with -b option, as it seems, that my text editor (kate) has set to strip whitespace at end of lines thus ending in unnecessary changes. Sorry about that. I still have to learn all that dev stuff :) As Michael has introduced refresh_loc procedure to refresh location list as result of any changes, I changed all places that had own location refresh code to use new location refreshments code. Second thing - previous code was safely expecting, that "cd" will never fail. I added new procedure to catch "cd" errors. Test yourself: cd GISDBASE && chmod -x LOCATION && grass63 && play around One HUGE startup screen issue is still remaining (aside from new location creation) - user can enter as mapset/location name characters, that will NOT be supported by GRASS (i.e. mapset with UTF-8 coded character). That's why I wrote email about what is allowed in location/mapset/map names and what is not [1]. Please, take 5 mins of your precious time to answer. Thank You! Thank you all for your great work and let's try to make GRASS pass "The Monkey" [2] test :) Maris. [1] http://grass.itc.it/pipermail/grass-dev/2007-January/028360.html [2] http://www.folklore.org/StoryView.py?project=Macintosh&story=Monkey_Lives.txt&sortOrder=Sort%20by%20Date&detail=medium -------------- next part -------------- A non-text attachment was scrubbed... Name: gis_set.patch2 Type: text/x-diff Size: 7832 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070106/e03acba8/gis_set.bin From michael.barton at asu.edu Sat Jan 6 20:42:59 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sat Jan 6 20:43:08 2007 Subject: [GRASS-dev] GRASS startup window patches In-Reply-To: <1168105543.18468.149.camel@devel> Message-ID: Paul and others, See below. On 1/6/07 10:45 AM, "Brad Douglas" wrote: > On Sat, 2007-01-06 at 09:39 -0700, Michael Barton wrote: >> Hi Brad, >> >> The line in my Platform.make file is correct--both in source and binary... >> >> PROJSHARE = /Library/Frameworks/PROJ.framework/Resources/proj >> >> >> But this does not seem to be doing anything. That is, the PROJSHARE value is >> not accessible in the normal ways I know of. I'm trying to figure out how to >> actually read this inside TclTk. Should a line be added to init.sh to make >> this an environmental variable? > > This is for gis_set.tcl, right? Actually, this is for use in epsg_option.tcl (epsg_option.tcl.ini in source for some odd reason). > > If so, lib/init/Makefile needs to be edited to apply the same technique > used on make_location_epsg.sh. During the build, a sed script gets run > and replaces PROJSHARE with the literal path. > OK. This finally tells me how this works. Thanks much. IMHO, this is really klunky and roundabout. And it doesn't work on my Mac for some reason. For the benefit of others... /lib/init/Makefile checks to see of PROJSHARE has been set in configure (as an environmental variable?). If not, it uses PROJSHAREDEFAULT (a different environmental variable?). In either case, it then runs a unix shell script (problems on Windows boxes and Macs?) that calls sed to replace the string "PROJSHARE" in the epsg_option.tcl.ini tcltk script with a literal path derived either from PROJSHARE or PROJSHAREDEFAULT. ================================ Here's the current code in /init/Make... if [ -z "$(PROJSHARE)" ] ; then \ sh ./projshare.sed "$(PROJSHAREDEFAULT)" epsg_option.tcl.in > $@ ; \ else \ sh ./projshare.sed "$(PROJSHARE)" epsg_option.tcl.in > $@ ; \ fi chmod 755 $@ Here is the code for the projshare.sed script... projshare=$1 file=$2 # MS-Windows TclTk does not recognize POSIX path. if [ "$file" = "epsg_option.tcl.in" -a -n "$MSYSCON" ] ; then msys_path=`echo $WD | sed -e 's+\\\\+/+g' -e 's+//bin/$++'` projshare=`echo "$projshare" | sed "s+^/usr+$msys_path+"` fi sed -e "s+PROJSHARE+$projshare+" $file ================================ IMHO, this could be considerably simplified and made more reliable cross-platform if PROJSHARE could be set as an environmental variable in init.sh (using the same methods of doing this as setting other variables at compile time in init.sh), be set as a GRASS environmental variable that could go into .grassrc6, or be put into a text file that could be read by the tcltk script. AFAICT, nothing except the TclTk script epsg_option.tcl needs to know where the epsg data file is located and I don't think it's a good idea to have a shell script try to alter a TclTk script. It isn't working on my Mac and I doubt if it works for Windows. Unfortunately, I don't understand the make system enough to make such changes myself and not mess something else up. 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 paul-grass at stjohnspoint.co.uk Sat Jan 6 22:46:42 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Sat Jan 6 22:46:44 2007 Subject: [GRASS-dev] Re: GRASS startup window patches In-Reply-To: <2b3d8c1c0701061110g4550394ai11901cc1e8444449@mail.gmail.com> References: <1168104407.18468.142.camel@devel> <2b3d8c1c0701061110g4550394ai11901cc1e8444449@mail.gmail.com> Message-ID: Hello Maris This looks good, and useful. I didn't realise Michael had added a location-list refresh function, but glad to see you've usefully added it after the "Create from projection values" button returns from running set_data and g.setproj. I think I will change it so a pop up terminal Window appears on both Unix and Windows for this - I really think it would be more useful than exiting back to the terminal the GUI was started from - on Windows for example this might not even exist! I still had difficulties getting your patch to apply cleanly though: sh-2.04$ patch -p0 Hi all of You! > I was not going to spawn such discussion, but it's damn good, as, > hopefully, it will make GRASS more lamer friendly :) > > I have to apologizes about forgetting describe my patches. In my mind > I was already looking how to fix other GRASS startup screen issues > (Yes, there still are some of them) and forgot to tell everyone about > what I'm doing. My apologies to all of you. > > I recreated gis_set patch with -b option, as it seems, that my text > editor (kate) has set to strip whitespace at end of lines thus ending > in unnecessary changes. Sorry about that. I still have to learn all > that dev stuff :) > As Michael has introduced refresh_loc procedure to refresh location > list as result of any changes, I changed all places that had own > location refresh code to use new location refreshments code. > Second thing - previous code was safely expecting, that "cd" will > never fail. I added new procedure to catch "cd" errors. > Test yourself: cd GISDBASE && chmod -x LOCATION && grass63 && play around > > One HUGE startup screen issue is still remaining (aside from new > location creation) - user can enter as mapset/location name > characters, that will NOT be supported by GRASS (i.e. mapset with > UTF-8 coded character). That's why I wrote email about what is allowed > in location/mapset/map names and what is not [1]. Please, take 5 mins > of your precious time to answer. Thank You! > > Thank you all for your great work and let's try to make GRASS pass > "The Monkey" [2] test :) > > > Maris. > > [1] http://grass.itc.it/pipermail/grass-dev/2007-January/028360.html > [2] > http://www.folklore.org/StoryView.py?project=Macintosh&story=Monkey_Lives.txt&sortOrder=Sort%20by%20Date&detail=medium > From grass-bugs at intevation.de Sat Jan 6 23:09:15 2007 From: grass-bugs at intevation.de (Request Tracker) Date: Sat Jan 6 23:09:17 2007 Subject: [GRASS-dev] [bug #5421] (grass) Bug importing r.in.gdal .flt format in the version 6.2.1 Message-ID: <20070106220915.43EDE10015A@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5421 ------------------------------------------------------------------------- Subject: Bug importing r.in.gdal .flt format in the version 6.2.1 Platform: GNU/Linux/x86 grass obtained from: Trento Italy site grass binary for platform: Downloaded precompiled Binaries GRASS Version: 6.2.1 Please enter your name and error description here. Don't write general statements such as "this could be better" - please explain in details how a certain problem can be solved or a feature be added/improved. Send different report for different problems. Thanks! Hi I have been working with the 6.0.1 relesase since 3 months ago and I have imported many files using r.in.gdal -o input=xx.flt output=xx It has been working fine in the previous release, but I have update the version to the 6.2.1 release and with the same command the way to import is wrong: it doesn't understand the file right, only pixel with no sense is shown... If you need any screen pictures and I will send it. My email is faguado@tsc.uvigo.es and I am Professor at Vigo University in Spain. Thanks Fernando -------------------------------------------- Managed by Request Tracker From hamish_nospam at yahoo.com Sun Jan 7 02:25:25 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Sun Jan 7 02:25:27 2007 Subject: [GRASS-dev] G_tempfile() proposed changes [relevant to creating a new location] Message-ID: <516291.41517.qm@web52710.mail.yahoo.com> Paul wrote: > I've had the attached changes (to G_tempfile(), g.tempfile and a couple of > other places) sitting around for a while, but Michael's comment about changes > to g.proj being forthcoming reminded me to hurry up and put them forward for > discussion. The changes amount to: > * Re-naming the current G_tempfile() to G_tempfile_in_mapset(). > * Change the calls to G_tempfile() in lib/gis/opencell.c to use the new > function G_tempfile_in_mapset() > * Write a new G_tempfile() that puts a tempfile in the directory pointed to > by the TEMP environment variable if it exists (this will be somewhere > writeable by the user on Windows) or P_tmpdir otherwise (/tmp on Unix or > root of current drive on Windows). > * Add a new command-line flag to g.tempfile to allow it to create a tempfile > in the current mapset if necessary. > * Change r.in.aster (as an example) to use g.tempfile in this way. There > would be more examples I'm sure we could find that want to create a large > tempfile somewhere there's more than likely to be enough space - the > original purpose of G_tempfile, according to comments in the source. > Although perhaps that's not all that relevant. Perhaps in the past /tmp > might have been likely to be very small? depends on how the user partitioned their drive. It's common to have /tmp in a small partition to prevent out of disk space DoS attacks. Hi, & a happy 2007, I have a few problems/questions with this. Such a big change to the way things are done requires an extrodinary reason. What's the need? [sorry not well set up to pour through the archives here] Is is just for creating new locations? (a single case when $MAPSET doesn't exist yet) Instead of changing G_tempfile() to G_tempfile_in_mapset(), why not leave G_tempfile() as-is and make a new G_tempfile_in_tmp() [or similar name] for the few cases that need that? Patches which do not address fundamental flaws in the system should follow the path of least damage. (patches which *do* address funamental flaws are of course another matter.) > The reason I haven't applied the changes yet is that I'm slightly worried > about what the effect might be of the sudden change. In particular, that > tempfiles created by the current G_tempfile (i.e. in the current mapset) get > cleaned up at the end of the session and after the change they won't. Should > we just change it and fix things on a case-by-case basis? (Either change > them to create the tempfile in the mapset, or force them to delete it?) A > bit of a dilemma. if in /tmp/ shouldn't they live in /tmp/grass-$USER-$$/, which gets removed when grass exits? [nb the /tmp/grass-$USER rmdir currently buggy if creating new locn or if you "Cancel" on the startup screen] As noted in an earlier post, there are cases (debugging, d.text, d.graph) where it is useful to leave small tmp files around for the rest of the session. While we are on the subject, still missing: G_tempdir() and "g.tempfile -d" Hamish (note heavy lack of sympathy for any change that messes up the grass code to accomodate broken/quirky {Windows|3rd party} compatibility software.) ps - don't mess with "g.region -g" pps- ps.map verbose command IS used in the wild, so don't break scripts by removing it altogether. Note it is multi-leveled, so it should keep at least 3 levels of verbosity triggered by --q,<>,--v, i.e. standard messages should use G_message(), but very verbose messages should hide G_message() in if(verbose >= G_max_verbose()) or whatever. I am in favour of separating mapping commands from program control, and letting the parser deal with the latter. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From hmitaso at unity.ncsu.edu Sun Jan 7 04:15:25 2007 From: hmitaso at unity.ncsu.edu (Helena Mitasova) Date: Sun Jan 7 04:15:31 2007 Subject: [GRASS-dev] Re: GRASS startup window patches, map names restrictions In-Reply-To: <2b3d8c1c0701061110g4550394ai11901cc1e8444449@mail.gmail.com> References: <1168104407.18468.142.camel@devel> <2b3d8c1c0701061110g4550394ai11901cc1e8444449@mail.gmail.com> Message-ID: On Jan 6, 2007, at 2:10 PM, Maris Nartiss wrote: > Hi all of You! > I was not going to spawn such discussion, but it's damn good, as, > hopefully, it will make GRASS more lamer friendly :) > > I have to apologizes about forgetting describe my patches. In my mind > I was already looking how to fix other GRASS startup screen issues > (Yes, there still are some of them) and forgot to tell everyone about > what I'm doing. My apologies to all of you. > > I recreated gis_set patch with -b option, as it seems, that my text > editor (kate) has set to strip whitespace at end of lines thus ending > in unnecessary changes. Sorry about that. I still have to learn all > that dev stuff :) > As Michael has introduced refresh_loc procedure to refresh location > list as result of any changes, I changed all places that had own > location refresh code to use new location refreshments code. > Second thing - previous code was safely expecting, that "cd" will > never fail. I added new procedure to catch "cd" errors. > Test yourself: cd GISDBASE && chmod -x LOCATION && grass63 && play > around > > One HUGE startup screen issue is still remaining (aside from new > location creation) - user can enter as mapset/location name > characters, that will NOT be supported by GRASS (i.e. mapset with > UTF-8 coded character). That's why I wrote email about what is allowed > in location/mapset/map names and what is not [1]. Please, take 5 mins > of your precious time to answer. Thank You! Maris -there are probably no explicit names restrictions in the documentation except for "." forbidden in the vector map names but here are some recommendations from our book - I was just working on it: Although it is possible to use all combinations of characters for the GRASS map names if the map name or expression is enclosed within quotes, it is safer to follow the name conventions described below. First, it is important to avoid spaces and special characters, such as a comma, dash, exclamation mark etc. in GRASS map names. Starting with GRASS6 dot is not allowed in the vector file names. It is also useful to include at least one letter in the map name to avoid confusion with numbers being treated as values, especially when using the map algebra module r.mapcalc. However, these are just recommendations not restrictions (e.g. I use underscore or dash in location names all the time). Helena > > Thank you all for your great work and let's try to make GRASS pass > "The Monkey" [2] test :) > > Maris. > > [1] http://grass.itc.it/pipermail/grass-dev/2007-January/028360.html > [2] http://www.folklore.org/StoryView.py? > project=Macintosh&story=Monkey_Lives.txt&sortOrder=Sort%20by% > 20Date&detail=medium > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From landa.martin at gmail.com Sun Jan 7 07:08:40 2007 From: landa.martin at gmail.com (Martin Landa) Date: Sun Jan 7 07:08:49 2007 Subject: [GRASS-dev] g.list -a In-Reply-To: <17823.11054.35596.752944@cerise.gclements.plus.com> References: <17806.65476.593110.361071@cerise.gclements.plus.com> <17809.48637.726595.182177@cerise.gclements.plus.com> <1a486f560701030845j37776763m4350ff8d011d9984@mail.gmail.com> <1a486f560701051507r4e666e00r9460246917a4057e@mail.gmail.com> <17823.11054.35596.752944@cerise.gclements.plus.com> Message-ID: Hi, 2007/1/6, Glynn Clements : [snip] > It's used differently; g.list has a type= option where the valid > option values are the types, while g.remove, g.rename and g.copy have > a separate option for each type. > > In terms of implementing "g.list type=all", the obvious first step > would be to add element->multiple=YES to the type= option so that you > can do e.g. "g.list type=rast,vect". Once that was done, it would be > relatively straightforward to allow "type=all". well, the new data type 'all' would be useful. I can imagine, for example `g.copy all=r,r1` or `g.remove all=r`, etc. I have modified the last patch according to that (removing -a flag). Do you think it could be committed to CVS. Other manage module will support this feature soon. Regards, Martin -- Martin Landa * http://gama.fsv.cvut.cz/~landa * -------------- next part -------------- A non-text attachment was scrubbed... Name: g_list_all-3.diff.gz Type: application/x-gzip Size: 2969 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070107/4b9c3738/g_list_all-3.diff.gz From michael.barton at asu.edu Sun Jan 7 07:12:37 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sun Jan 7 07:12:46 2007 Subject: [GRASS-dev] Re: grass-dev Digest, Vol 9, Issue 16 In-Reply-To: <200701070125.l071PxIS012968@grass.itc.it> Message-ID: Thanks for the explanation Maris. This helps understand the goal of your changes. On 1/6/07 6:25 PM, "grass-dev-request@grass.itc.it" wrote: > As Michael has introduced refresh_loc procedure to refresh location > list as result of any changes, I changed all places that had own > location refresh code to use new location refreshments code. > Second thing - previous code was safely expecting, that "cd" will > never fail. I added new procedure to catch "cd" errors. > Test yourself: cd GISDBASE && chmod -x LOCATION && grass63 && play around They sound like good ideas. I did test it on my Mac right away and it worked. I just didn't know what it did. Now that I do, I can look them over too. > > One HUGE startup screen issue is still remaining (aside from new > location creation) - user can enter as mapset/location name > characters, that will NOT be supported by GRASS (i.e. mapset with > UTF-8 coded character). That's why I wrote email about what is allowed > in location/mapset/map names and what is not [1]. Please, take 5 mins > of your precious time to answer. Thank You! Don't know the answer to this. Maybe someone else does. I think that new location creation is working pretty good now. You can use EPSG codes pretty easily for a change (need to get the PROJSHARE issue solved to avoid the annoyance of having to find the codes on Win and Mac boxes though), and I think the create location by georeferenced file should work on all platforms and for new startups now. It would be nice to have a replacement for g.setproj, but maybe that is not as high a priority now that the other methods work pretty well. What do you think? > > Thank you all for your great work and let's try to make GRASS pass > "The Monkey" [2] test :) I'm not sure that we can do this. :-\ But I agree that we need to do our best to make this easier to start, easier to use, and more foolproof. My personal goal (not that I can achieve it without a lot of help) is to make the GRASS UI better than the competition. That is, it should be useable by normal humans at least ;-) 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 Sun Jan 7 07:50:43 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sun Jan 7 07:50:52 2007 Subject: [GRASS-dev] Re: GRASS startup window patches In-Reply-To: Message-ID: Now that I know what the changes attempt to do, I tried it out. In my case at least, after making a new location, it went straight into GRASS. It didn't return to the startup screen so that the user could decide to use or not use the new location. This is not due to Maris' changes, but to the way the startup worked in the first place. Gis_set.tcl doesn't seem to even run g.setproj. It looks like it returns to init.sh for this. I'm not exactly sure why it is writing a bunch of values to stdout just prior to this either. Is it trying to set some environmental variables for init.sh? I don't mind committing this, but it seems like we ought to do a bit more first. What about having gis_set.tcl do the running of g.setproj and then return to the refreshed startup? This seems like a better, more consistent way to go. Michael On 1/6/07 2:46 PM, "Paul Kelly" wrote: > Apart from those issues it looks good and could be committed I think. I'm > not sure about the location and mapset names. > __________________________________________ 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 landa.martin at gmail.com Sun Jan 7 08:07:30 2007 From: landa.martin at gmail.com (Martin Landa) Date: Sun Jan 7 08:07:32 2007 Subject: [GRASS-dev] ps.map fprintf -> G_ In-Reply-To: References: <20070103165026.GB6831@localdomain> Message-ID: Hi, I have prepared a new version of the patch where verbose mapping instruction is removed. It will cause "ERROR: verbose : illegal request" when the verbose mapping instruction is used. Not sure if we can just remove this instruction... Regards, Martin 2007/1/4, Martin Landa : > Hi Jachym, > > 2007/1/3, Jachym Cepicky : > > Hi, > > nice job, thanks for the patch, but when I'm thinking about it, ... > > > > this patch makes ps.map set it's verbosity not by the --quiet > > or --verbose flags, but also according to the input configuration file. > > Right, this patch allows to set verbosity level by the --q/v flag or > by verbose mapping instruction. > > > imho, the simplest solution should be, remove the VERBOSE keyword from > > ps.map. It would not harm to anythink. I doubt, some people are parsing > > Not sure, it would break backward compatibility. OK, maybe the verbose > instruction should be removed later, now just printing appropriate > warning about it. There is also question about priority: the --q/v > flag should overwrite the mapping instruction or not? > > > output from ps.map in their scripts. > > > > If so, G_set_verbose function is the best solution. > > > > What do others think? > > ... > > > Jachym > > Thanks for the feedback Jachym. > > > > > On Tue, Dec 26, 2006 at 11:16:44AM +0100, Martin Landa wrote: > > > Hi all, > > > > > > trying to change fprintf to G_message/warning/fatal_error in ps.map > > > module I found one complication. There is a special mapping > > > instruction --- VERBOSE. I think this instruction should overwrite > > > GRASS_VERBOSE environment variable(??). There is also need to have a > > > special function G_set_verbose() which allows to set a given verbosity > > > level after first calling of G_verbose() fn. Please look at the patch > > > (especially at verbose.c.diff). Thanks a lot. > > > > > > Best regards, 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 > > > > -- > > Jachym Cepicky > > e-mail: jachym.cepicky@centrum.cz > > URL: http://les-ejk.cz > > GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub > > ----------------------------------------- > > OFFICE: > > Department of Geoinformation Technologies > > Zemedelska 3 > > 613 00, Brno > > Czech Republick > > e-mail: xcepicky@node.mendelu.cz > > URL: http://mapserver.mendelu.cz > > Tel.: +420 545 134 514 > > > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.3 (GNU/Linux) > > > > iD8DBQFFm97SyKt0uAjU4I8RAh4lAKCMce8cDJEO5Yf8Wra2msvgzAAfDwCfRraX > > tGACE41v2F2Yv2UKt6AXuEI= > > =2I9W > > -----END PGP SIGNATURE----- > > > > > > > > > -- > Martin Landa * http://gama.fsv.cvut.cz/~landa * > -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From landa.martin at gmail.com Sun Jan 7 08:08:08 2007 From: landa.martin at gmail.com (Martin Landa) Date: Sun Jan 7 08:08:11 2007 Subject: [GRASS-dev] ps.map fprintf -> G_ In-Reply-To: References: <20070103165026.GB6831@localdomain> Message-ID: and the patch ... ;-) 2007/1/7, Martin Landa : > Hi, > > I have prepared a new version of the patch where verbose mapping > instruction is removed. It will cause "ERROR: verbose : illegal > request" when the verbose mapping instruction is used. > > Not sure if we can just remove this instruction... > > Regards, Martin > > 2007/1/4, Martin Landa : > > Hi Jachym, > > > > 2007/1/3, Jachym Cepicky : > > > Hi, > > > nice job, thanks for the patch, but when I'm thinking about it, ... > > > > > > this patch makes ps.map set it's verbosity not by the --quiet > > > or --verbose flags, but also according to the input configuration file. > > > > Right, this patch allows to set verbosity level by the --q/v flag or > > by verbose mapping instruction. > > > > > imho, the simplest solution should be, remove the VERBOSE keyword from > > > ps.map. It would not harm to anythink. I doubt, some people are parsing > > > > Not sure, it would break backward compatibility. OK, maybe the verbose > > instruction should be removed later, now just printing appropriate > > warning about it. There is also question about priority: the --q/v > > flag should overwrite the mapping instruction or not? > > > > > output from ps.map in their scripts. > > > > > > If so, G_set_verbose function is the best solution. > > > > > > What do others think? > > > > ... > > > > > Jachym > > > > Thanks for the feedback Jachym. > > > > > > > > On Tue, Dec 26, 2006 at 11:16:44AM +0100, Martin Landa wrote: > > > > Hi all, > > > > > > > > trying to change fprintf to G_message/warning/fatal_error in ps.map > > > > module I found one complication. There is a special mapping > > > > instruction --- VERBOSE. I think this instruction should overwrite > > > > GRASS_VERBOSE environment variable(??). There is also need to have a > > > > special function G_set_verbose() which allows to set a given verbosity > > > > level after first calling of G_verbose() fn. Please look at the patch > > > > (especially at verbose.c.diff). Thanks a lot. > > > > > > > > Best regards, 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 > > > > > > -- > > > Jachym Cepicky > > > e-mail: jachym.cepicky@centrum.cz > > > URL: http://les-ejk.cz > > > GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub > > > ----------------------------------------- > > > OFFICE: > > > Department of Geoinformation Technologies > > > Zemedelska 3 > > > 613 00, Brno > > > Czech Republick > > > e-mail: xcepicky@node.mendelu.cz > > > URL: http://mapserver.mendelu.cz > > > Tel.: +420 545 134 514 > > > > > > > > > -----BEGIN PGP SIGNATURE----- > > > Version: GnuPG v1.4.3 (GNU/Linux) > > > > > > iD8DBQFFm97SyKt0uAjU4I8RAh4lAKCMce8cDJEO5Yf8Wra2msvgzAAfDwCfRraX > > > tGACE41v2F2Yv2UKt6AXuEI= > > > =2I9W > > > -----END PGP SIGNATURE----- > > > > > > > > > > > > > > > -- > > Martin Landa * http://gama.fsv.cvut.cz/~landa * > > > > > -- > Martin Landa * http://gama.fsv.cvut.cz/~landa * > -- Martin Landa * http://gama.fsv.cvut.cz/~landa * -------------- next part -------------- A non-text attachment was scrubbed... Name: ps_map-vq-2.diff.gz Type: application/x-gzip Size: 8209 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070107/6bf83130/ps_map-vq-2.diff-0001.gz From jachym.cepicky at centrum.cz Sun Jan 7 09:18:13 2007 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Sun Jan 7 09:18:22 2007 Subject: [GRASS-dev] ps.map fprintf -> G_ In-Reply-To: References: <20070103165026.GB6831@localdomain> Message-ID: <20070107081813.GC10502@localdomain> hi, On Sun, Jan 07, 2007 at 08:07:30AM +0100, Martin Landa wrote: > Hi, > > I have prepared a new version of the patch where verbose mapping > instruction is removed. It will cause "ERROR: verbose : illegal > request" when the verbose mapping instruction is used. On this place, I would vote for just a warning, so + /* Please, remove before GRASS 7 released */ if (KEY("verbose")) { - if (sscanf(data, "%d", &verbose) != 1) verbose = 2; + G_warning(_("verbose instruction was removed. Please use --verbose instead")); continue; } Otherwise, tha patch looks good to me Thank you Jachym > > Not sure if we can just remove this instruction... > > Regards, Martin > > 2007/1/4, Martin Landa : > >Hi Jachym, > > > >2007/1/3, Jachym Cepicky : > >> Hi, > >> nice job, thanks for the patch, but when I'm thinking about it, ... > >> > >> this patch makes ps.map set it's verbosity not by the --quiet > >> or --verbose flags, but also according to the input configuration file. > > > >Right, this patch allows to set verbosity level by the --q/v flag or > >by verbose mapping instruction. > > > >> imho, the simplest solution should be, remove the VERBOSE keyword from > >> ps.map. It would not harm to anythink. I doubt, some people are parsing > > > >Not sure, it would break backward compatibility. OK, maybe the verbose > >instruction should be removed later, now just printing appropriate > >warning about it. There is also question about priority: the --q/v > >flag should overwrite the mapping instruction or not? > > > >> output from ps.map in their scripts. > >> > >> If so, G_set_verbose function is the best solution. > >> > >> What do others think? > > > >... > > > >> Jachym > > > >Thanks for the feedback Jachym. > > > >> > >> On Tue, Dec 26, 2006 at 11:16:44AM +0100, Martin Landa wrote: > >> > Hi all, > >> > > >> > trying to change fprintf to G_message/warning/fatal_error in ps.map > >> > module I found one complication. There is a special mapping > >> > instruction --- VERBOSE. I think this instruction should overwrite > >> > GRASS_VERBOSE environment variable(??). There is also need to have a > >> > special function G_set_verbose() which allows to set a given verbosity > >> > level after first calling of G_verbose() fn. Please look at the patch > >> > (especially at verbose.c.diff). Thanks a lot. > >> > > >> > Best regards, 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 > >> > >> -- > >> Jachym Cepicky > >> e-mail: jachym.cepicky@centrum.cz > >> URL: http://les-ejk.cz > >> GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub > >> ----------------------------------------- > >> OFFICE: > >> Department of Geoinformation Technologies > >> Zemedelska 3 > >> 613 00, Brno > >> Czech Republick > >> e-mail: xcepicky@node.mendelu.cz > >> URL: http://mapserver.mendelu.cz > >> Tel.: +420 545 134 514 > >> > >> > >> -----BEGIN PGP SIGNATURE----- > >> Version: GnuPG v1.4.3 (GNU/Linux) > >> > >> iD8DBQFFm97SyKt0uAjU4I8RAh4lAKCMce8cDJEO5Yf8Wra2msvgzAAfDwCfRraX > >> tGACE41v2F2Yv2UKt6AXuEI= > >> =2I9W > >> -----END PGP SIGNATURE----- > >> > >> > >> > > > > > >-- > >Martin Landa * http://gama.fsv.cvut.cz/~landa * > > > > > -- > Martin Landa * http://gama.fsv.cvut.cz/~landa * -- Jachym Cepicky e-mail: jachym.cepicky@centrum.cz URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub ----------------------------------------- OFFICE: Department of Geoinformation Technologies Zemedelska 3 613 00, Brno Czech Republick e-mail: xcepicky@node.mendelu.cz URL: http://mapserver.mendelu.cz Tel.: +420 545 134 514 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070107/fe8d0026/attachment.bin From maris.gis at gmail.com Sun Jan 7 11:01:02 2007 From: maris.gis at gmail.com (Maris Nartiss) Date: Sun Jan 7 11:01:04 2007 Subject: [GRASS-dev] Re: GRASS startup window patches In-Reply-To: References: Message-ID: <2b3d8c1c0701070201l411fe3den6dbcaab8aa7ab248@mail.gmail.com> Paul, that documentation does not say anything about being able to use only one variable per global declaration. And gis_set.tcl already had multiple variables per global keyword. And finaly - it works with tcl/tk 8.4. Please, use second gis_set.tcl patch I sent - I added two more lines to set $location to blank, if GISDBASE is changed. Previously it wuold leave $location unchanged and thus be source of bug (change GISDBASE directory to empty dir, create new mapset an it will try to create one eaven if there are no locations, as $location contains old value). I also added "-nocomplain" flag for location refreshment's code to get around empty location list creation. On Linux with tcl-8.4.13 creating new location from EPSG code always returns to startup screen. No "start session with new location by default". If it acts differently on Mac, then it is an error. I do not own Mac and I do not know any of my freands with Mac (Mac's are not popular in my country) and thus I will not be able to help with debuging :( During my code hacking going stright to GRASS session and not to startup screen allways was result of (my) error and not result of normal action. In Konsole (KDE xterm like app), I still had tcl error messages in scrollback buffer - just a matter of scrolling window up to see errors. Maris. 2007/1/7, Michael Barton : > Now that I know what the changes attempt to do, I tried it out. In my case > at least, after making a new location, it went straight into GRASS. It > didn't return to the startup screen so that the user could decide to use or > not use the new location. > > This is not due to Maris' changes, but to the way the startup worked in the > first place. Gis_set.tcl doesn't seem to even run g.setproj. It looks like > it returns to init.sh for this. I'm not exactly sure why it is writing a > bunch of values to stdout just prior to this either. Is it trying to set > some environmental variables for init.sh? > > I don't mind committing this, but it seems like we ought to do a bit more > first. What about having gis_set.tcl do the running of g.setproj and then > return to the refreshed startup? This seems like a better, more consistent > way to go. > > Michael > > > On 1/6/07 2:46 PM, "Paul Kelly" wrote: > > > Apart from those issues it looks good and could be committed I think. I'm > > not sure about the location and mapset names. > > > > __________________________________________ > Michael Barton, Professor of Anthropology > School of Human Evolution & Social Change > Center for Social Dynamics & Complexity > Arizona State University > > phone: 480-965-6213 > fax: 480-965-7671 > www: http://www.public.asu.edu/~cmbarton > > > From glynn at gclements.plus.com Sun Jan 7 11:34:42 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Jan 7 11:34:47 2007 Subject: [GRASS-dev] G_tempfile() proposed changes [relevant to creating a new location] In-Reply-To: References: Message-ID: <17824.52418.927735.5798@cerise.gclements.plus.com> Paul Kelly wrote: > * Write a new G_tempfile() that puts a tempfile in the directory pointed > to by the TEMP environment variable if it exists (this will be somewhere > writeable by the user on Windows) or P_tmpdir otherwise (/tmp on Unix or > root of current drive on Windows). Unix uses $TMPDIR rather than $TEMP. I'd suggest that G_tempfile() should use $TMPDIR in preference to /tmp, to eliminate potential security issues related to the use of world-writable directories, although this isn't necessary if a private subdirectory is used. > The reason I haven't applied the changes yet is that I'm slightly worried > about what the effect might be of the sudden change. In particular, that > tempfiles created by the current G_tempfile (i.e. in the current mapset) > get cleaned up at the end of the session and after the change they won't. > Should we just change it and fix things on a case-by-case basis? (Either > change them to create the tempfile in the mapset, or force them to delete > it?) A bit of a dilemma. I would suggest using a private subdirectory of /tmp ($TEMP, $TMPDIR), linked to a particular session (i.e. use $GIS_LOCK in the directory name) so that we can clean it up safely. Was there a reason for not using the /tmp/grass--$GIS_LOCK directory (where the monitor sockets are stored)? I do feel that we should figure out a solution which allows for cleaning up (i.e. not using a directory which is shared with temporary files created by programs other than GRASS) before changing anything. -- Glynn Clements From maris.gis at gmail.com Sun Jan 7 11:34:59 2007 From: maris.gis at gmail.com (Maris Nartiss) Date: Sun Jan 7 11:35:02 2007 Subject: [GRASS-dev] Re: GRASS startup window patches, map names restrictions In-Reply-To: References: <1168104407.18468.142.camel@devel> <2b3d8c1c0701061110g4550394ai11901cc1e8444449@mail.gmail.com> Message-ID: <2b3d8c1c0701070234k359a82adp7a986ae363771334@mail.gmail.com> Well - there are some restrictions in real life. And they seem to be just undocumented. That's bad. I can confirm, that using non-latin character with UTF-8 encoding in mapset name, will make mapset/GRASS unusable. Map names also can not contain unicode characters. Location with unicode chars seem to be OK. Except, it will break startup screen in text mode :) IMHO other GRASS places are also not unicode aware. Locations can not contain spaces - creating new location in text mode startup screen will simply ignore anything after space. In GUI creating new location from EPSG code with space in name will simply result in nothing - no error, no location. Sometimes it will work. Probably we should push forward policy, that only latin characters and numbers are allowed in map/mapset names? Like "[a-Z] [0-9] _-". Pros for such approach: no need to check all GRASS code to be unicode etc. aware. Cons: limit's user choice; Unfriendly to non-English speakers. I see, that "," is now included in illegal character list - it's no longer possible to create raster map with comma in name. OFT: Comma is decimal separator in Latvian language (and others too) and thus I once created map name with comma. I was not able to use that map in other places anymore ;) Maris. 2007/1/7, Helena Mitasova : > > Maris -there are probably no explicit names restrictions in the > documentation > except for "." forbidden in the vector map names but here are some > recommendations > from our book - I was just working on it: > > Although it is possible to use all combinations of > characters for the GRASS map names if the map name > or expression is enclosed within quotes, > it is safer to follow the name conventions described below. > First, it is important to avoid spaces and special characters, such > as a comma, > dash, exclamation mark etc. in GRASS map names. > Starting with GRASS6 dot is not allowed in the vector file names. > It is also useful to include at least one letter in the map name > to avoid confusion with numbers being treated as values, especially > when using > the map algebra module r.mapcalc. > > However, these are just recommendations not restrictions (e.g. I use > underscore > or dash in location names all the time). > > Helena > From glynn at gclements.plus.com Sun Jan 7 11:38:41 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Jan 7 11:40:32 2007 Subject: [GRASS-dev] GRASS startup window patches In-Reply-To: References: <1168105543.18468.149.camel@devel> Message-ID: <17824.52657.644857.694755@cerise.gclements.plus.com> Michael Barton wrote: > IMHO, this could be considerably simplified and made more reliable > cross-platform if PROJSHARE could be set as an environmental variable in > init.sh (using the same methods of doing this as setting other variables at > compile time in init.sh), be set as a GRASS environmental variable that > could go into .grassrc6, or be put into a text file that could be read by > the tcltk script. Agreed. Hard-coding the path to the EPSG file is undesirable, and doesn't appear to be necessary. > AFAICT, nothing except the TclTk script epsg_option.tcl > needs to know where the epsg data file is located and I don't think it's a > good idea to have a shell script try to alter a TclTk script. It isn't > working on my Mac and I doubt if it works for Windows. Unfortunately, I > don't understand the make system enough to make such changes myself and not > mess something else up. If you adopt the approach of setting PROJSHARE as an environment variable in etc/Init.sh and just using $env(PROJSHARE) in Tcl code, you can just mimic the other etc/Init.sh substitutions in lib/init/Makefile. -- Glynn Clements From glynn at gclements.plus.com Sun Jan 7 11:51:35 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Jan 7 11:51:39 2007 Subject: [GRASS-dev] G_tempfile() proposed changes [relevant to creating a new location] In-Reply-To: <516291.41517.qm@web52710.mail.yahoo.com> References: <516291.41517.qm@web52710.mail.yahoo.com> Message-ID: <17824.53431.519717.71786@cerise.gclements.plus.com> Hamish wrote: > Instead of changing G_tempfile() to G_tempfile_in_mapset(), why not leave > G_tempfile() as-is and make a new G_tempfile_in_tmp() [or similar name] for the > few cases that need that? Because *most* usage of G_tempfile() doesn't need the file to reside in the mapset directory. It's the existing behaviour which is a special case. Essentially, there's no reason for the two (mapset directory and temporary directory) to be linked. Having them linked creates problems if you need to create a temporary file (e.g. for G_asprintf()) when you don't have a valid mapset, meaning that many libgis functions may require a valid mapset for no good reason. > As noted in an earlier post, there are cases (debugging, d.text, d.graph) where > it is useful to leave small tmp files around for the rest of the session. Right. However: 1. Such files don't need to persist between sessions. 2. If a module exits normally, we can assume that any temporary files which it hasn't removed are meant to persist for the remainder of the session. 3. If a module exits abnormally using G_fatal_error(), we may want to automatically remove any temporary files which it created (the only reason not to would be for debugging, and we can provide an environment variable for this purpose). For #3, it would help if we used a directory which was specific to GRASS (e.g. /tmp/grass-- rather than /tmp) so that we don't have to worry about deleting something we shouldn't. -- Glynn Clements From glynn at gclements.plus.com Sun Jan 7 11:54:54 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Jan 7 11:55:05 2007 Subject: [GRASS-dev] g.list -a In-Reply-To: References: <17806.65476.593110.361071@cerise.gclements.plus.com> <17809.48637.726595.182177@cerise.gclements.plus.com> <1a486f560701030845j37776763m4350ff8d011d9984@mail.gmail.com> <1a486f560701051507r4e666e00r9460246917a4057e@mail.gmail.com> <17823.11054.35596.752944@cerise.gclements.plus.com> Message-ID: <17824.53630.559151.84699@cerise.gclements.plus.com> Martin Landa wrote: > > It's used differently; g.list has a type= option where the valid > > option values are the types, while g.remove, g.rename and g.copy have > > a separate option for each type. > > > > In terms of implementing "g.list type=all", the obvious first step > > would be to add element->multiple=YES to the type= option so that you > > can do e.g. "g.list type=rast,vect". Once that was done, it would be > > relatively straightforward to allow "type=all". > > well, the new data type 'all' would be useful. I can imagine, for > example `g.copy all=r,r1` or `g.remove all=r`, etc. I can't imagine that ever being useful. Or, rather, I can imagine the danger far exceeding the usefulness, e.g. using "g.remove all=foo" as a shorthand for "g.remove rast=foo ; g.remove vect=foo" and forgetting that you had a region, icon, etc named "foo" which you didn't want to delete. -- Glynn Clements From paul-grass at stjohnspoint.co.uk Sun Jan 7 12:00:03 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Sun Jan 7 12:00:06 2007 Subject: [GRASS-dev] Re: GRASS startup window patches In-Reply-To: References: Message-ID: On Sat, 6 Jan 2007, Michael Barton wrote: > Now that I know what the changes attempt to do, I tried it out. In my case > at least, after making a new location, it went straight into GRASS. It > didn't return to the startup screen so that the user could decide to use or > not use the new location. > > This is not due to Maris' changes, but to the way the startup worked in the > first place. Gis_set.tcl doesn't seem to even run g.setproj. It looks like > it returns to init.sh for this. I'm not exactly sure why it is writing a > bunch of values to stdout just prior to this either. Is it trying to set > some environmental variables for init.sh? Something like that. I agree too that that's not the best way - in fact I'd already changed it that for Windows, when you click "Create location using projection values" it pops up a terminal window to run etc/set_data. It's not just g.setproj - etc/set_data also forces the user to set the initial region and in general does a bit more (I'm not 100% sure what else, but creating the projection files and setting the initial region are the main things). I would like it though that we could just run g.setproj and return to gis_set.tcl - as it's a bit confusing running set_data - after creating the location you have to press Ctrl-C to exit back out. If we can design a GUI widget to force the user to verify/set the initial region after creating a new location, then this could be presented after the 3 different methods of creating a new location. And then we could simplify the "using projection values" button to running g.setproj in a pop-up xterm Window and do the region setting through the GUI afterwards. > I don't mind committing this, but it seems like we ought to do a bit more > first. What about having gis_set.tcl do the running of g.setproj and then > return to the refreshed startup? This seems like a better, more consistent > way to go. I have committed Maris's patch now, with this extra modification. The thing is, you still need to press Ctrl-C to exit out of it after creating the new location. And that isn't obvious. But, like I said, once we can do the initial region setting in the GUI, then we can simplify that. Paul From paul-grass at stjohnspoint.co.uk Sun Jan 7 12:12:14 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Sun Jan 7 12:12:17 2007 Subject: [GRASS-dev] G_tempfile() proposed changes [relevant to creating a new location] In-Reply-To: <17824.53431.519717.71786@cerise.gclements.plus.com> References: <516291.41517.qm@web52710.mail.yahoo.com> <17824.53431.519717.71786@cerise.gclements.plus.com> Message-ID: On Sun, 7 Jan 2007, Glynn Clements wrote: > > Hamish wrote: > >> Instead of changing G_tempfile() to G_tempfile_in_mapset(), why not leave >> G_tempfile() as-is and make a new G_tempfile_in_tmp() [or similar name] for the >> few cases that need that? > > Because *most* usage of G_tempfile() doesn't need the file to reside > in the mapset directory. It's the existing behaviour which is a > special case. > > Essentially, there's no reason for the two (mapset directory and > temporary directory) to be linked. Having them linked creates problems > if you need to create a temporary file (e.g. for G_asprintf()) when > you don't have a valid mapset, meaning that many libgis functions may > require a valid mapset for no good reason. Just to clarify, the special case here was running g.proj to create a new location when there aren't any locations existing. Any library functions called by g.proj that use G_tempfile will fail because there is no current mapset to put the tempfile into. But there are other issues that have come up from time to time, if you search for G_tempfile on Google. It is kind of a recurring nagging problem, more a usage problem than a problem with the function itself I think. The documentation for G_tempfile says it is supposed to be used for large temporary files like maps, where the system temp directory might not have enough space. But in practice it's come to be used whenever a temporary file is needed for anything, and it's not always suitable. I feel if we don't make a wholesale change now it might lead to hard-to-detect little problems in years to come when everyone forgets about this and again assumes G_tempfile creates a "normal" temp file - It reminds me of the G_getl issue. I almost think it would have been better if G_getl had been re-written to support stripping Mac/DOS new line sequences as well as Unix ones instead of adding a new G_getl2 and changing case-by-case in modules. The newline problem causes loads of subtle problems on native Windows and it is often really hard to detect where, deep within a library that a call to G_getl should be replaced with G_getl2 to get round the problem. >> As noted in an earlier post, there are cases (debugging, d.text, d.graph) where >> it is useful to leave small tmp files around for the rest of the session. > > Right. However: > > 1. Such files don't need to persist between sessions. > > 2. If a module exits normally, we can assume that any temporary files > which it hasn't removed are meant to persist for the remainder of the > session. > > 3. If a module exits abnormally using G_fatal_error(), we may want to > automatically remove any temporary files which it created (the only > reason not to would be for debugging, and we can provide an > environment variable for this purpose). > > For #3, it would help if we used a directory which was specific to > GRASS (e.g. /tmp/grass-- rather than /tmp) so that > we don't have to worry about deleting something we shouldn't. The issue here I think is (IIRC) that session directory is only created when you start a GRASS session from Init.sh, right? So if some external program is calling GRASS modules, e.g. QGIS or something (not 100% sure how it works) it would have been OK up to now with just a few environment variables set - if we make this change there will have to be an official GRASS "session" for G_tempfile to work. Unless I've missed something. But yes I can't see any other way of easily deleting the temp files without accidentally deleting something else. From glynn at gclements.plus.com Sun Jan 7 12:12:41 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Jan 7 12:12:52 2007 Subject: [GRASS-dev] GRASS startup window patches In-Reply-To: References: <2b3d8c1c0701050927q34503896nf22c4de307f46485@mail.gmail.com> <17823.12576.712805.194692@cerise.gclements.plus.com> <17823.44140.49512.674843@cerise.gclements.plus.com> Message-ID: <17824.54697.634131.499979@cerise.gclements.plus.com> Paul Kelly wrote: > > As it stands, if you want g.proj to ensure that the defaults aren't > > used, it should just be a matter of ensuring that the proj4= option > > contains either towgs84= or nadgrids=, no? > > That's right. The g.proj -d output (although I was thinking of removing > it) already provides detailed information on the datum-related component > of any input co-ordinate system. It might be useful if this was > re-organised a bit and then another flag was added that would list the > possible choices of datum parameters for a particular input co-ordinate > system? AFAICT, it would be trivial for the GUI to do this itself using the information in etc/datumtransform.table The functionality currently provided by GPJ_ask_datum_params() amounts to a choice of: 1. list all entries in etc/datumtransform.table which match a given datum name, then allow the user to select one of them, or 2. ask the user to enter a PROJ option in one of the forms: towgs84=dx,dy,dz towgs84=dx,dy,dz,rx,ry,rz,m nadgrids=grid For #2, the string which the user enters is passed to proj verbatim without any validation. This is the sort of thing which the GUI can (and should) do by itself; none of it requires any support from libraries or a C module. -- Glynn Clements From landa.martin at gmail.com Sun Jan 7 12:26:24 2007 From: landa.martin at gmail.com (Martin Landa) Date: Sun Jan 7 12:26:27 2007 Subject: [GRASS-dev] g.list -a In-Reply-To: <17824.53630.559151.84699@cerise.gclements.plus.com> References: <17809.48637.726595.182177@cerise.gclements.plus.com> <1a486f560701030845j37776763m4350ff8d011d9984@mail.gmail.com> <1a486f560701051507r4e666e00r9460246917a4057e@mail.gmail.com> <17823.11054.35596.752944@cerise.gclements.plus.com> <17824.53630.559151.84699@cerise.gclements.plus.com> Message-ID: Hi, 2007/1/7, Glynn Clements : [snip] > > well, the new data type 'all' would be useful. I can imagine, for > > example `g.copy all=r,r1` or `g.remove all=r`, etc. > > I can't imagine that ever being useful. Or, rather, I can imagine the > danger far exceeding the usefulness, e.g. using "g.remove all=foo" as > a shorthand for "g.remove rast=foo ; g.remove vect=foo" and forgetting > that you had a region, icon, etc named "foo" which you didn't want to > delete. well, you are right, of course it could be too dangerous feature. On the other hand the user should know what he/she is doing;-) I can see 1) the special flag in g.list (-a -> all types) Q: the 'type' parameter should be requested or not requested? 2) the new data type 'all', Q: Should or shouldn't be avoided in other manage modules (like g.remove, g.copy)? 3) ... ? Not sure what is better or more useful. If we don't want to use 'all' in other modules (e.g. g.copy) I think the flag (1) would be (maybe) better. Martin -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From tutey at o2.pl Sun Jan 7 14:41:59 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Sun Jan 7 14:42:14 2007 Subject: [GRASS-dev] Re: [GRASS-user] problem with vi.in.ogr In-Reply-To: <200701062335.22781.jarekj@amu.edu.pl> References: <200701061758.11903.jarekj@amu.edu.pl> <459FEC95.2050004@o2.pl> <200701062335.22781.jarekj@amu.edu.pl> Message-ID: <45A0F8A7.3050606@o2.pl> Jarek Jasiewicz wrote: > Reasons found but problem exist: > > 34 points has exactly the same coors. So topology cannot be bulid.... Jarek Duplicate points should not make GRASS modules fail. Try this eg.: # create 34 (like in your case) duplicate point vector: i=0; while [ $i -ne 34 ]; do echo "100 100"; let "i++"; done | v.in.ascii out=pt34 fs=" " # export to shapefile v.out.ogr input=pt34 type=point dsn=pt34 olayer=pt34 # import it back: v.in.ogr dsn=$HOME/pt34/pt34.shp output=pt34_re [...] Importing map 34 features... ----------------------------------------------------- Building topology ... 34 primitives registered Building areas: 100% 0 areas built 0 isles built Attaching islands: Attaching centroids: 100% Topology was built. Number of nodes : 1 Number of primitives: 34 Number of points : 34 Number of lines : 0 Number of boundaries: 0 Number of centroids : 0 Number of areas : 0 Number of isles : 0 All works - for me. Maybe your shapefile is corrupted somehow? Can you send it for testing? > location is set on EPSG 2174 (Polish 1965 zone 4) > > when I try import shape with points to location: > > v.in.ogr -o dsn=/home/jarekj/shp/PunktyAZP.shp output=azp min_area=0.0001 > snap=-1 --overwrite > > I recive message: > > No projection name! Projection parameters likely to be meaningless. That's because GRASS doesn't know about the ESRIS's Double_Stereographic - propably because GDAL and PROJ don't know it. GDAL calls this projection "Oblique_Stereographic". I have fed all the EPSG codes that use "+proj=sterea" (including EPSG 2174 from your case) into epsg_tr.py -wkt, and all they are parsed as PROJECTION["Oblique_Stereographic"]. All the codes using "+proj=stere" are parsed as PROJECTION["Polar_Stereographic"]. There are no traces of other Sterographic projections supported by PROJ.4 (alsk, gall, gs48, gs50, lee_os, mil_os, ups) in my /usr/local/share/proj/epsg. According to [1] ESRI's Double_Stereographic is the same as GDAL's Oblique_Steregraphic. That would make sense. I have tried looking in the ESRI's resorces [2] but haven't found a direct answer though. Should Double_Stereographic be intepreted as Oblique_Steregraphic by GRASS? Or is to be fixed in PROJ.4 or GDAL? Paul? The are 18 EPSG codes using sterea. They all might result in same problems in the GRASS - ESRI data exchange. [1] http://udig.refractions.net/docs/api-geotools/org/geotools/ct/proj/Stereographic.html [2] http://webhelp.esri.com/arcgisdesktop/9.2/index.cfm?TopicName=Double_Stereographic Maciek From paul-grass at stjohnspoint.co.uk Sun Jan 7 15:30:09 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Sun Jan 7 15:30:14 2007 Subject: [GRASS-dev] Re: [GRASS-user] problem with vi.in.ogr In-Reply-To: <45A0F8A7.3050606@o2.pl> References: <200701061758.11903.jarekj@amu.edu.pl> <459FEC95.2050004@o2.pl> <200701062335.22781.jarekj@amu.edu.pl> <45A0F8A7.3050606@o2.pl> Message-ID: On Sun, 7 Jan 2007, Maciej Sieczka wrote: >> No projection name! Projection parameters likely to be meaningless. > > That's because GRASS doesn't know about the ESRIS's > Double_Stereographic - propably because GDAL and PROJ don't know it. > GDAL calls this projection "Oblique_Stereographic". > > I have fed all the EPSG codes that use "+proj=sterea" (including EPSG > 2174 from your case) into epsg_tr.py -wkt, and all they are parsed as > PROJECTION["Oblique_Stereographic"]. > > All the codes using "+proj=stere" are parsed as > PROJECTION["Polar_Stereographic"]. > > There are no traces of other Sterographic projections supported by > PROJ.4 (alsk, gall, gs48, gs50, lee_os, mil_os, ups) in my > /usr/local/share/proj/epsg. > > According to [1] ESRI's Double_Stereographic is the same as GDAL's > Oblique_Steregraphic. > > That would make sense. I have tried looking in the ESRI's resorces [2] > but haven't found a direct answer though. > > Should Double_Stereographic be intepreted as Oblique_Steregraphic by > GRASS? Or is to be fixed in PROJ.4 or GDAL? Paul? The relevant place to look is, I think, OSRMorphFromESRI() in ogr/ogr_srs_esri.cpp in the GDAL source tree. If you're sure of the equivalence (in terms of WKT names) you could file a bug in the GDAL bugzilla with some sample ESRI-style WKT and what it should be converted to, for Frank to look at. Or, if Double_Stereographic is a valid WKT projection name and it is just the conversion into PROJ.4 format that isn't being done correctly, then the function OSRExportToProj4() in ogr/ogr_srs_proj4.cpp is the one you're interested in. I see in the comments in the header there are quite a lot relating to stereographic already, so it is obviously a problem already. To summarise, it needs looked into a bit more to see whether it is the ESRI projection name that is wrong and non-standard (in which case it can be worked around in the OSRMorphFromESRI function) or if OGR's conversion from WKT projection names into PROJ equivalents is simply missing this case (in which case something should be changed in the OSRExportToProj4 function). Paul From jachym.cepicky at centrum.cz Sun Jan 7 19:00:08 2007 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Sun Jan 7 19:00:12 2007 Subject: [GRASS-dev] G_program_name to every message Message-ID: <20070107180008.GA8579@localdomain> Hallo, I think it would be nice, if G_message, G_warning and G_fatal_error would print module name at the beginning of the message. If the modules are used in scripts, it is sometimes difficult to identify, which C-module, used in the script, caused some problem or is printing the message. This is the case for e.g. r.report (file stats.c) too. What about adding G_program_name(); to every message, so that G_message("Hallo, world!"); would produce g.module: Hallo, world! and G_warning("Hallo, world!"); -> WARNING: g.module: Hallo, world! ?? The question is, how to do it... Imho the best place is printf_error(); in error.c What do you think? Jachym -- Jachym Cepicky e-mail: jachym.cepicky@centrum.cz URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub ----------------------------------------- OFFICE: Department of Geoinformation Technologies Zemedelska 3 613 00, Brno Czech Republick e-mail: xcepicky@node.mendelu.cz URL: http://mapserver.mendelu.cz Tel.: +420 545 134 514 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070107/2a86ca0e/attachment.bin From jachym.cepicky at centrum.cz Sun Jan 7 20:02:29 2007 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Sun Jan 7 20:02:35 2007 Subject: [GRASS-dev] v.clean and G_message Message-ID: <20070107190229.GA25756@localdomain> Hallo, v.clean prints lots of tables to stderr, using partly fprintf, partly G_message. I would suggest, the tables should be printed to STDOUT and new flag -q should be added, for turning this messages off. What do you think? Thanks Jachym -- Jachym Cepicky e-mail: jachym.cepicky@centrum.cz URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub ----------------------------------------- OFFICE: Department of Geoinformation Technologies Zemedelska 3 613 00, Brno Czech Republick e-mail: xcepicky@node.mendelu.cz URL: http://mapserver.mendelu.cz Tel.: +420 545 134 514 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070107/734ffcf4/attachment.bin From jachym.cepicky at centrum.cz Sun Jan 7 21:30:01 2007 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Sun Jan 7 21:30:14 2007 Subject: [GRASS-dev] v.in.dxf and modified version of G_percent Message-ID: <20070107203001.GA30196@localdomain> Hallo, in read_dxf.c (v.in.dxf) there is function big_percent(). This function prints information about progres while import. big_percent is defined like int big_percent(unsigned long n, unsigned long d, int s) while G_percent int G_percent (int n,int d,int s) IMHO v.in.dxf should use G_percent too. What kind of approach is the best: - Rewrite G_percent, so it uses long integers on input - New function G_percent_big for cases like this - Nothing, using G_percent directly will not cause any problem ?? Jachym -- Jachym Cepicky e-mail: jachym.cepicky@centrum.cz URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub ----------------------------------------- OFFICE: Department of Geoinformation Technologies Zemedelska 3 613 00, Brno Czech Republick e-mail: xcepicky@node.mendelu.cz URL: http://mapserver.mendelu.cz Tel.: +420 545 134 514 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070107/2cf858aa/attachment-0001.bin From rez at touchofmadness.com Sun Jan 7 22:17:18 2007 From: rez at touchofmadness.com (Brad Douglas) Date: Sun Jan 7 22:17:23 2007 Subject: [GRASS-dev] G_program_name to every message / r.li In-Reply-To: <20070107180008.GA8579@localdomain> References: <20070107180008.GA8579@localdomain> Message-ID: <1168204638.5112.27.camel@devel> On Sun, 2007-01-07 at 19:00 +0100, Jachym Cepicky wrote: > Hallo, > > I think it would be nice, if G_message, G_warning and G_fatal_error > would print module name at the beginning of the message. > > If the modules are used in scripts, it is sometimes difficult to > identify, which C-module, used in the script, caused some problem or is > printing the message. This is the case for e.g. r.report (file stats.c) > too. > > What about adding G_program_name(); to every message, so that > > G_message("Hallo, world!"); > > would produce > > g.module: Hallo, world! Why? This amounts to spam, IMHO. Some module names are 30 characters wide (I'm looking at you, r.li)! That's nearly half the terminal length. r.li's modules need to be renamed in keeping with other modules (mixed case, length, etc.). I do not envy anyone who has to use them without tab-completion or similar. -- Brad Douglas KB8UYR/6 Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From michael.barton at asu.edu Sun Jan 7 22:49:10 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sun Jan 7 22:49:20 2007 Subject: [GRASS-dev] Re: GRASS startup window patches In-Reply-To: Message-ID: Paul, I did a bit of testing along with some code clean up to see that gis_set.tcl is actually doing. On 1/7/07 4:00 AM, "Paul Kelly" wrote: > If we can design a GUI widget to force the user to verify/set the initial > region after creating a new location, then this could be presented after > the 3 different methods of creating a new location. And then we could > simplify the "using projection values" button to running g.setproj in a > pop-up xterm Window and do the region setting through the GUI afterwards. I now don't think that this will work. It looks like g.setproj will only work in already existing projected locations. That is, it won't work in xy locations and won't work unless there is already a valid PROJ_INFO file. So we're stuck with set_data for use in the GRASS startup. > >> I don't mind committing this, but it seems like we ought to do a bit more >> first. What about having gis_set.tcl do the running of g.setproj and then >> return to the refreshed startup? This seems like a better, more consistent >> way to go. > > I have committed Maris's patch now, with this extra modification. The > thing is, you still need to press Ctrl-C to exit out of it after creating > the new location. And that isn't obvious. But, like I said, once we can do > the initial region setting in the GUI, then we can simplify that. I wonder if some modifications to set_data might make this easier. Currently, it ONLY runs in interactive mode. What would it take to make set_data also run in non-interactive mode? Here is a suggestion if this is feasible. Maybe make g.setdata based on the set_data module in $GISBASE/etc. Inputs: database=[string; required] location=[string; required] mapset=[string (default=PERMANENT); optional] projclass=[xy, latlon, utm, other; required (or could have default)] loc_desc=[string; optional] datum=[string; optional (i.e., for xy)] datumtrans=[string; required (default=1)] ellipsoid=[string; optional or required? Default?] zone=[integer; optional] hemisphere=[n, s; optional] north=[float (accept DD:MM:SS for latlon?); required, optional, def?] south=[float (accept DD:MM:SS for latlon?); required, optional, def?] east=[float (accept DD:MM:SS for latlon?); required, optional, def?] west=[float (accept DD:MM:SS for latlon?); required, optional, def?] ewres=[float; required, optional, def?] nsres=[float; required, optional, def?] Outputs: -d list available datums for selected projclass (projclass must be defined) -e list available ellipsoids for selected datum (datum must be defined) -t (list available transforms for selected datums (datum must be defined) With something like this, a GUI wrapper could be built pretty easily. 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 Sun Jan 7 22:55:14 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sun Jan 7 22:55:23 2007 Subject: [GRASS-dev] Re: GRASS startup window patches In-Reply-To: <2b3d8c1c0701070201l411fe3den6dbcaab8aa7ab248@mail.gmail.com> Message-ID: Maris, It was the 'use projection values' option that went directly to GRASS. This is fixed now to work like the epsg and georeferenced file options. Michael On 1/7/07 3:01 AM, "Maris Nartiss" wrote: > On Linux with tcl-8.4.13 creating new location from EPSG code always > returns to startup screen. No "start session with new location by > default". If it acts differently on Mac, then it is an error. I do not > own Mac and I do not know any of my freands with Mac (Mac's are not > popular in my country) and thus I will not be able to help with > debuging :( __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Sun Jan 7 22:55:55 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sun Jan 7 22:56:05 2007 Subject: [GRASS-dev] Re: GRASS startup window patches In-Reply-To: <2b3d8c1c0701070201l411fe3den6dbcaab8aa7ab248@mail.gmail.com> Message-ID: Where is this patch? Did I miss it somehow? Michael On 1/7/07 3:01 AM, "Maris Nartiss" wrote: > Please, use second gis_set.tcl patch I sent - I added two more lines > to set $location to blank, if GISDBASE is changed. Previously it wuold > leave $location unchanged and thus be source of bug (change GISDBASE > directory to empty dir, create new mapset an it will try to create one > eaven if there are no locations, as $location contains old value). I > also added "-nocomplain" flag for location refreshment's code to get > around empty location list creation. __________________________________________ 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 rez at touchofmadness.com Sun Jan 7 22:58:10 2007 From: rez at touchofmadness.com (Brad Douglas) Date: Sun Jan 7 22:58:18 2007 Subject: [GRASS-dev] i.image.mosaic/i.landsat.rgb Message-ID: <1168207090.5112.36.camel@devel> Hello, i.image.mosaic errors out with the following: GRASS 6.3.cvs (black_rock):~ > i.image.mosaic image1=etm1.1 image2=etm2.1 image3=etm3.1 ATTENTION: Do not forget to set region properly to cover all images! i.image.mosaic: line 85: [: argument expected i.image.mosaic: line 106: [: argument expected i.image.mosaic: line 119: [: too many arguments With i.landsat.rgb, I get a bit farther, but produces a blank display. I'm quite certain that is not a desirable feature. :-) Could a good shell scripter take a look? -- Brad Douglas KB8UYR/6 Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From hmitaso at unity.ncsu.edu Sun Jan 7 23:23:43 2007 From: hmitaso at unity.ncsu.edu (Helena Mitasova) Date: Sun Jan 7 23:23:51 2007 Subject: [GRASS-dev] G_program_name to every message / r.li In-Reply-To: <1168204638.5112.27.camel@devel> References: <20070107180008.GA8579@localdomain> <1168204638.5112.27.camel@devel> Message-ID: On Jan 7, 2007, at 4:17 PM, Brad Douglas wrote: > On Sun, 2007-01-07 at 19:00 +0100, Jachym Cepicky wrote: >> Hallo, >> >> I think it would be nice, if G_message, G_warning and G_fatal_error >> would print module name at the beginning of the message. >> >> If the modules are used in scripts, it is sometimes difficult to >> identify, which C-module, used in the script, caused some problem >> or is >> printing the message. This is the case for e.g. r.report (file >> stats.c) >> too. >> >> What about adding G_program_name(); to every message, so that >> >> G_message("Hallo, world!"); >> >> would produce >> >> g.module: Hallo, world! > > Why? This amounts to spam, IMHO. Some module names are 30 characters > wide (I'm looking at you, r.li)! That's nearly half the terminal > length. > > r.li's modules need to be renamed in keeping with other modules (mixed > case, length, etc.). I do not envy anyone who has to use them without > tab-completion or similar. this was discussed already and new names were proposed - Serena was probably just waiting to get her CVS access approved? Serena, now that you have the access can you please change the names - it would be good to do it ASAP before people start using the long names in their scripts. as for the message, I tend to agree with jachym on this one, I think it would be useful to have the module name printed along with the message - except for r.li* the modules have quite reasonable names. Thanks, Helena > > > -- > Brad Douglas KB8UYR/6 > Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From dca.gis at gmail.com Mon Jan 8 02:40:05 2007 From: dca.gis at gmail.com (Daniel Calvelo) Date: Mon Jan 8 02:40:07 2007 Subject: [GRASS-dev] g.list -a In-Reply-To: References: <1a486f560701030845j37776763m4350ff8d011d9984@mail.gmail.com> <1a486f560701051507r4e666e00r9460246917a4057e@mail.gmail.com> <17823.11054.35596.752944@cerise.gclements.plus.com> <17824.53630.559151.84699@cerise.gclements.plus.com> Message-ID: <1a486f560701071740n2bc9b37ekdc5bdcc5d8205907@mail.gmail.com> On 1/7/07, Martin Landa wrote: > [...] > 1) the special flag in g.list (-a -> all types) Q: the 'type' > parameter should be requested or not requested? > > 2) the new data type 'all', Q: Should or shouldn't be avoided in other > manage modules (like g.remove, g.copy)? > > 3) ... ? > > Not sure what is better or more useful. If we don't want to use 'all' > in other modules (e.g. g.copy) I think the flag (1) would be (maybe) > better. If it is only useful in g.list, are there any reasons against creating a script g.list.all without options and well-structured output (i.e. parseable)? Daniel. From dca.gis at gmail.com Mon Jan 8 02:42:55 2007 From: dca.gis at gmail.com (Daniel Calvelo) Date: Mon Jan 8 02:42:56 2007 Subject: [GRASS-dev] G_program_name to every message In-Reply-To: <20070107180008.GA8579@localdomain> References: <20070107180008.GA8579@localdomain> Message-ID: <1a486f560701071742w1c85420dme5e0c44efc68ecc7@mail.gmail.com> Hi Jachym. Great idea. I would condition that on the debug environment variable. You might even consider adding __FILE__ and __LINE__ references then. Daniel. On 1/7/07, Jachym Cepicky wrote: > Hallo, > > I think it would be nice, if G_message, G_warning and G_fatal_error > would print module name at the beginning of the message. > > If the modules are used in scripts, it is sometimes difficult to > identify, which C-module, used in the script, caused some problem or is > printing the message. This is the case for e.g. r.report (file stats.c) > too. > > What about adding G_program_name(); to every message, so that > > G_message("Hallo, world!"); > > would produce > > g.module: Hallo, world! > > and > G_warning("Hallo, world!"); -> WARNING: g.module: Hallo, world! > > ?? > > The question is, how to do it... Imho the best place is printf_error(); > in error.c > > What do you think? > > Jachym > -- > Jachym Cepicky > e-mail: jachym.cepicky@centrum.cz > URL: http://les-ejk.cz > GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub > ----------------------------------------- > OFFICE: > Department of Geoinformation Technologies > Zemedelska 3 > 613 00, Brno > Czech Republick > e-mail: xcepicky@node.mendelu.cz > URL: http://mapserver.mendelu.cz > Tel.: +420 545 134 514 > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.3 (GNU/Linux) > > iD8DBQFFoTUoyKt0uAjU4I8RAklPAJ9nv9alWvXazqqsxzacKR0+uJA5lwCfTKxi > ZHX8m3KrvQyWQqUI3V/QRwQ= > =ns2o > -----END PGP SIGNATURE----- > > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > > -- -- Daniel Calvelo Aros From rez at touchofmadness.com Mon Jan 8 03:14:54 2007 From: rez at touchofmadness.com (Brad Douglas) Date: Mon Jan 8 03:14:58 2007 Subject: [GRASS-dev] G_program_name to every message In-Reply-To: <1a486f560701071742w1c85420dme5e0c44efc68ecc7@mail.gmail.com> References: <20070107180008.GA8579@localdomain> <1a486f560701071742w1c85420dme5e0c44efc68ecc7@mail.gmail.com> Message-ID: <1168222494.5112.71.camel@devel> No. The only place that is appropriate is G_debug(). Average users could care less about that information and will likely complain about it. On Sun, 2007-01-07 at 20:42 -0500, Daniel Calvelo wrote: > Hi Jachym. Great idea. I would condition that on the debug environment > variable. You might even consider adding __FILE__ and __LINE__ > references then. > > Daniel. > > On 1/7/07, Jachym Cepicky wrote: > > Hallo, > > > > I think it would be nice, if G_message, G_warning and G_fatal_error > > would print module name at the beginning of the message. > > > > If the modules are used in scripts, it is sometimes difficult to > > identify, which C-module, used in the script, caused some problem or is > > printing the message. This is the case for e.g. r.report (file stats.c) > > too. > > > > What about adding G_program_name(); to every message, so that > > > > G_message("Hallo, world!"); > > > > would produce > > > > g.module: Hallo, world! > > > > and > > G_warning("Hallo, world!"); -> WARNING: g.module: Hallo, world! > > > > ?? > > > > The question is, how to do it... Imho the best place is printf_error(); > > in error.c > > > > What do you think? -- Brad Douglas KB8UYR/6 Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From rez at touchofmadness.com Mon Jan 8 03:19:13 2007 From: rez at touchofmadness.com (Brad Douglas) Date: Mon Jan 8 03:19:18 2007 Subject: [GRASS-dev] G_program_name to every message In-Reply-To: <1168222494.5112.71.camel@devel> References: <20070107180008.GA8579@localdomain> <1a486f560701071742w1c85420dme5e0c44efc68ecc7@mail.gmail.com> <1168222494.5112.71.camel@devel> Message-ID: <1168222753.5112.72.camel@devel> Oops. I missed a key word when I read it: "debug". Sorry. On Sun, 2007-01-07 at 18:14 -0800, Brad Douglas wrote: > No. The only place that is appropriate is G_debug(). Average users > could care less about that information and will likely complain about > it. > > On Sun, 2007-01-07 at 20:42 -0500, Daniel Calvelo wrote: > > Hi Jachym. Great idea. I would condition that on the debug environment > > variable. You might even consider adding __FILE__ and __LINE__ > > references then. > > > > Daniel. > > > > On 1/7/07, Jachym Cepicky wrote: > > > Hallo, > > > > > > I think it would be nice, if G_message, G_warning and G_fatal_error > > > would print module name at the beginning of the message. > > > > > > If the modules are used in scripts, it is sometimes difficult to > > > identify, which C-module, used in the script, caused some problem or is > > > printing the message. This is the case for e.g. r.report (file stats.c) > > > too. > > > > > > What about adding G_program_name(); to every message, so that > > > > > > G_message("Hallo, world!"); > > > > > > would produce > > > > > > g.module: Hallo, world! > > > > > > and > > > G_warning("Hallo, world!"); -> WARNING: g.module: Hallo, world! > > > > > > ?? > > > > > > The question is, how to do it... Imho the best place is printf_error(); > > > in error.c > > > > > > What do you think? -- Brad Douglas KB8UYR/6 Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From dca.gis at gmail.com Mon Jan 8 03:24:36 2007 From: dca.gis at gmail.com (Daniel Calvelo) Date: Mon Jan 8 03:24:37 2007 Subject: [GRASS-dev] G_program_name to every message In-Reply-To: <1168222753.5112.72.camel@devel> References: <20070107180008.GA8579@localdomain> <1a486f560701071742w1c85420dme5e0c44efc68ecc7@mail.gmail.com> <1168222494.5112.71.camel@devel> <1168222753.5112.72.camel@devel> Message-ID: <1a486f560701071824y6ab61d7co4b7d31c5ac3c8c1c@mail.gmail.com> On 1/7/07, Brad Douglas wrote: > Oops. I missed a key word when I read it: "debug". Sorry. :) No harm. Indeed, for debugging purposes, it may give some extra information at little coding cost. > On Sun, 2007-01-07 at 18:14 -0800, Brad Douglas wrote: > > No. The only place that is appropriate is G_debug(). Average users > > could care less about that information and will likely complain about > > it. > > > > On Sun, 2007-01-07 at 20:42 -0500, Daniel Calvelo wrote: > > > Hi Jachym. Great idea. I would condition that on the debug environment > > > variable. You might even consider adding __FILE__ and __LINE__ > > > references then. > > > > > > Daniel. > > > > > > On 1/7/07, Jachym Cepicky wrote: > > > > Hallo, > > > > > > > > I think it would be nice, if G_message, G_warning and G_fatal_error > > > > would print module name at the beginning of the message. > > > > > > > > If the modules are used in scripts, it is sometimes difficult to > > > > identify, which C-module, used in the script, caused some problem or is > > > > printing the message. This is the case for e.g. r.report (file stats.c) > > > > too. > > > > > > > > What about adding G_program_name(); to every message, so that > > > > > > > > G_message("Hallo, world!"); > > > > > > > > would produce > > > > > > > > g.module: Hallo, world! > > > > > > > > and > > > > G_warning("Hallo, world!"); -> WARNING: g.module: Hallo, world! > > > > > > > > ?? > > > > > > > > The question is, how to do it... Imho the best place is printf_error(); > > > > in error.c > > > > > > > > What do you think? > > -- > Brad Douglas KB8UYR/6 > Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 > > -- -- Daniel Calvelo Aros From dca.gis at gmail.com Mon Jan 8 03:38:39 2007 From: dca.gis at gmail.com (Daniel Calvelo) Date: Mon Jan 8 03:38:41 2007 Subject: [GRASS-dev] i.image.mosaic/i.landsat.rgb In-Reply-To: <1168207090.5112.36.camel@devel> References: <1168207090.5112.36.camel@devel> Message-ID: <1a486f560701071838t297a1622w59921e27f5d7f140@mail.gmail.com> Brad, Try this version. Daniel. On 1/7/07, Brad Douglas wrote: > Hello, > > i.image.mosaic errors out with the following: > > GRASS 6.3.cvs (black_rock):~ > i.image.mosaic image1=etm1.1 > image2=etm2.1 image3=etm3.1 > > ATTENTION: Do not forget to set region properly to cover all images! > > i.image.mosaic: line 85: [: argument expected > i.image.mosaic: line 106: [: argument expected > i.image.mosaic: line 119: [: too many arguments > > With i.landsat.rgb, I get a bit farther, but produces a blank display. > I'm quite certain that is not a desirable feature. :-) > > Could a good shell scripter take a look? > > > -- > Brad Douglas KB8UYR/6 > Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > -- -- Daniel Calvelo Aros -------------- next part -------------- A non-text attachment was scrubbed... Name: i.image.mosaic Type: application/octet-stream Size: 5267 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070107/99f46b1e/i.image.obj From landa.martin at gmail.com Mon Jan 8 08:26:32 2007 From: landa.martin at gmail.com (Martin Landa) Date: Mon Jan 8 08:26:34 2007 Subject: [GRASS-dev] ps.map fprintf -> G_ In-Reply-To: <20070107081813.GC10502@localdomain> References: <20070103165026.GB6831@localdomain> <20070107081813.GC10502@localdomain> Message-ID: Hi, 2007/1/7, Jachym Cepicky : > On this place, I would vote for just a warning, so > > + /* Please, remove before GRASS 7 released */ > if (KEY("verbose")) > { > - if (sscanf(data, "%d", &verbose) != 1) verbose = 2; > + G_warning(_("verbose instruction was removed. Please use --verbose instead")); > continue; > } > > Otherwise, tha patch looks good to me done & committed to CVS. Thanks, Martin -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From tutey at o2.pl Mon Jan 8 12:20:14 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Mon Jan 8 12:20:17 2007 Subject: [GRASS-dev] v.clean and G_message In-Reply-To: <20070107190229.GA25756@localdomain> References: <20070107190229.GA25756@localdomain> Message-ID: <45A228EE.1050008@o2.pl> Jachym Cepicky wrote: > v.clean prints lots of tables to stderr, using partly fprintf, partly > G_message. > > I would suggest, the tables should be printed to STDOUT and new flag -q > should be added, for turning this messages off. > > What do you think? Hi Jachym You might like to take a look at http://intevation.de/rt/webrt?serial_num=4524 Maciek From tutey at o2.pl Mon Jan 8 12:26:13 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Mon Jan 8 12:26:19 2007 Subject: [GRASS-dev] g.list -a In-Reply-To: <1a486f560701071740n2bc9b37ekdc5bdcc5d8205907@mail.gmail.com> References: <1a486f560701030845j37776763m4350ff8d011d9984@mail.gmail.com> <1a486f560701051507r4e666e00r9460246917a4057e@mail.gmail.com> <17823.11054.35596.752944@cerise.gclements.plus.com> <17824.53630.559151.84699@cerise.gclements.plus.com> <1a486f560701071740n2bc9b37ekdc5bdcc5d8205907@mail.gmail.com> Message-ID: <45A22A55.7000907@o2.pl> Daniel Calvelo wrote: > On 1/7/07, Martin Landa wrote: >> > [...] >> 1) the special flag in g.list (-a -> all types) Q: the 'type' >> parameter should be requested or not requested? >> >> 2) the new data type 'all', Q: Should or shouldn't be avoided in other >> manage modules (like g.remove, g.copy)? >> >> 3) ... ? >> >> Not sure what is better or more useful. If we don't want to use 'all' >> in other modules (e.g. g.copy) I think the flag (1) would be (maybe) >> better. > > If it is only useful in g.list, are there any reasons against creating > a script g.list.all without options and well-structured output (i.e. > parseable)? Or maybe add option type=all to g.mlist? Maciek From mlennert at club.worldonline.be Mon Jan 8 13:29:42 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Mon Jan 8 13:27:56 2007 Subject: [GRASS-dev] ps.map fprintf -> G_ In-Reply-To: References: <20070103165026.GB6831@localdomain> <20070107081813.GC10502@localdomain> Message-ID: <45A23936.4080200@club.worldonline.be> On 08/01/07 08:26, Martin Landa wrote: > Hi, > > 2007/1/7, Jachym Cepicky : > >> On this place, I would vote for just a warning, so >> >> + /* Please, remove before GRASS 7 released */ >> if (KEY("verbose")) >> { >> - if (sscanf(data, "%d", &verbose) != 1) verbose = 2; >> + G_warning(_("verbose instruction was removed. Please use >> --verbose instead")); >> continue; >> } >> >> Otherwise, tha patch looks good to me > > done & committed to CVS. Just in case you missed this (from bottom of http://grass.itc.it/pipermail/grass5/2007-January/028390.html): Hamish wrote: > pps- ps.map verbose command IS used in the wild, so don't break scripts by > removing it altogether. Note it is multi-leveled, so it should keep at least 3 > levels of verbosity triggered by --q,<>,--v, i.e. standard messages should use > G_message(), but very verbose messages should hide G_message() in if(verbose >= > G_max_verbose()) or whatever. I am in favour of separating mapping commands > from program control, and letting the parser deal with the latter. Moritz From glynn at gclements.plus.com Mon Jan 8 15:04:00 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Jan 8 15:04:04 2007 Subject: [GRASS-dev] G_tempfile() proposed changes [relevant to creating a new location] In-Reply-To: References: <516291.41517.qm@web52710.mail.yahoo.com> <17824.53431.519717.71786@cerise.gclements.plus.com> Message-ID: <17826.20304.950048.230911@cerise.gclements.plus.com> Paul Kelly wrote: > > For #3, it would help if we used a directory which was specific to > > GRASS (e.g. /tmp/grass-- rather than /tmp) so that > > we don't have to worry about deleting something we shouldn't. > > The issue here I think is (IIRC) that session directory is only created > when you start a GRASS session from Init.sh, right? So if some external > program is calling GRASS modules, e.g. QGIS or something (not 100% sure > how it works) it would have been OK up to now with just a few environment > variables set - if we make this change there will have to be an official > GRASS "session" for G_tempfile to work. Unless I've missed something. G_tempfile() could always create the directory itself if it doesn't already exist. $GIS_LOCK would still need to be set in order to have a directory which is specific to a particular session. > But yes I can't see any other way of easily deleting the temp files > without accidentally deleting something else. It has since occurred to me that we could still run into problems due to PID re-use. Temporary files whose names contain the PID of the current process could have been created by a previous process with the same PID with the intent that they persist. The only 100% robust solution is to store "persistent temporary files" (is that an oxymoron?) in a different directory to "transient" temporary files. -- Glynn Clements From glynn at gclements.plus.com Mon Jan 8 15:12:37 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Jan 8 15:12:42 2007 Subject: [GRASS-dev] v.in.dxf and modified version of G_percent In-Reply-To: <20070107203001.GA30196@localdomain> References: <20070107203001.GA30196@localdomain> Message-ID: <17826.20821.439915.28039@cerise.gclements.plus.com> Jachym Cepicky wrote: > in read_dxf.c (v.in.dxf) there is function big_percent(). This function > prints information about progres while import. big_percent is defined > like > > int big_percent(unsigned long n, unsigned long d, int s) > > while G_percent > > int G_percent (int n,int d,int s) > > > IMHO v.in.dxf should use G_percent too. What kind of approach is the > best: > > - Rewrite G_percent, so it uses long integers on input > - New function G_percent_big for cases like this > - Nothing, using G_percent directly will not cause any problem I suggest taking the first approach. -- Glynn Clements From glynn at gclements.plus.com Mon Jan 8 15:35:55 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Jan 8 15:36:08 2007 Subject: [GRASS-dev] Re: GRASS startup window patches, map names restrictions In-Reply-To: <2b3d8c1c0701070234k359a82adp7a986ae363771334@mail.gmail.com> References: <1168104407.18468.142.camel@devel> <2b3d8c1c0701061110g4550394ai11901cc1e8444449@mail.gmail.com> <2b3d8c1c0701070234k359a82adp7a986ae363771334@mail.gmail.com> Message-ID: <17826.22220.592.931756@cerise.gclements.plus.com> Maris Nartiss wrote: > I can confirm, that using non-latin character with UTF-8 encoding in > mapset name, will make mapset/GRASS unusable. Can you provide any more details? > Map names also can not contain unicode characters. > Location with unicode chars seem to be OK. Except, it will break > startup screen in text mode :) > IMHO other GRASS places are also not unicode aware. GRASS itself shouldn't need to be "unicode aware"; most code should be "neutral" regarding encodings, i.e. just treat strings as strings of bytes, not characters. Problems are most likely to arise within the UI, where strings of bytes have to be decoded to strings of characters for rendering (this applies both to graphical toolkits and curses). > Probably we should push forward policy, that only latin characters and > numbers are allowed in map/mapset names? Like "[a-Z] [0-9] _-". Most ASCII punctuation characters should be allowed except when they already have specific meanings to GRASS (e.g. = and , are both significant to the parser, @ is used for map@mapset etc). Vector maps are problematic due to the decision to use map names as SQL table names without any translation, meaning that map names are constrained by SQL syntax. > Pros for such approach: no need to check all GRASS code to be unicode > etc. aware. > Cons: limit's user choice; Unfriendly to non-English speakers. GRASS C code should just treat all bytes in the range 128-255 as "letters", subject to the limitation that case-folding won't apply (i.e. ? and ? are considered different even in contexts where e and E are considered equal). If other libraries (e.g. Tcl/Tk) want to interpret byte strings as character strings, it's the user's responsibility to use an appropriate encoding. Curses is essentially limited to unibyte encodings; in any case, languages which absolutely require multibyte encodings (CJK) have problems due to "monospace" (halfwidth/fullwidth) issues. One other factor to bear in mind is that, on Windows, filenames (and thus map names, mapset names etc) are interpreted according to the current codepage, which almost certainly *won't* be UTF-8. -- Glynn Clements From landa.martin at gmail.com Mon Jan 8 15:50:49 2007 From: landa.martin at gmail.com (Martin Landa) Date: Mon Jan 8 15:50:52 2007 Subject: [GRASS-dev] ps.map fprintf -> G_ In-Reply-To: <45A23936.4080200@club.worldonline.be> References: <20070103165026.GB6831@localdomain> <20070107081813.GC10502@localdomain> <45A23936.4080200@club.worldonline.be> Message-ID: Hi, 2007/1/8, Moritz Lennert : > Hamish wrote: > > pps- ps.map verbose command IS used in the wild, so don't break scripts by > > removing it altogether. Note it is multi-leveled, so it should keep at least 3 > > levels of verbosity triggered by --q,<>,--v, i.e. standard messages should use > > G_message(), but very verbose messages should hide G_message() in if(verbose >= > > G_max_verbose()) or whatever. I am in favour of separating mapping commands > > from program control, and letting the parser deal with the latter. I am not sure if I understand well. It is true that verbose mapping instruction is multi-leveled (0|1|2). But in practice there was only one condition: if (verbose > 1) fprintf ();. It would be good to distinguish between standard and verbose messages as Hamish suggested. I am not sure what messages are "standard" and "very verbose". In the first patch verbose instruction overwrote the --v/q flags [1], now verbose instruction was removed and added a warning about that. So should I apply rather the first approach (including G_set_verbose) ? Martin [1] http://grass.itc.it/pipermail/grass-dev/2006-December/028272.html -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From glynn at gclements.plus.com Mon Jan 8 16:18:11 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Jan 8 16:18:17 2007 Subject: [GRASS-dev] G_program_name to every message In-Reply-To: <1168222494.5112.71.camel@devel> References: <20070107180008.GA8579@localdomain> <1a486f560701071742w1c85420dme5e0c44efc68ecc7@mail.gmail.com> <1168222494.5112.71.camel@devel> Message-ID: <17826.24755.553948.353356@cerise.gclements.plus.com> Brad Douglas wrote: > > Hi Jachym. Great idea. I would condition that on the debug environment > > variable. You might even consider adding __FILE__ and __LINE__ > > references then. > > No. The only place that is appropriate is G_debug(). Also, that would mean that G_debug() has to be a macro (within G_debug(), __FILE__ and __LINE__ will refer to G_debug() itself, not the caller, which isn't much use). But G_debug() is variadic, and variadic macros aren't ANSI C (gcc provides them as an extension). -- Glynn Clements From glynn at gclements.plus.com Mon Jan 8 16:25:04 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Jan 8 16:25:13 2007 Subject: [GRASS-dev] G_program_name to every message / r.li In-Reply-To: <1168204638.5112.27.camel@devel> References: <20070107180008.GA8579@localdomain> <1168204638.5112.27.camel@devel> Message-ID: <17826.25168.25663.59169@cerise.gclements.plus.com> Brad Douglas wrote: > > What about adding G_program_name(); to every message, so that > > > > G_message("Hallo, world!"); > > > > would produce > > > > g.module: Hallo, world! > > Why? This amounts to spam, IMHO. Some module names are 30 characters > wide (I'm looking at you, r.li)! That's nearly half the terminal > length. I can see it being useful, for the reasons Jachym gives; however: 1. It should be optional (although with all of these environment variables, I'm starting to worry about platforms which have a 4KiB limit on the combined size of the command line and the environment). 2. It might be better to put it on a line by itself, and only display it for the first message or warning, so: G_message("Hello,"); G_message("World!"); would produce e.g.: * g.module: Hello, World! rather than: g.module: Hello, g.module: World! This would be preferable in the cases of modules with long names and modules which are particularly verbose. -- Glynn Clements From paul-grass at stjohnspoint.co.uk Mon Jan 8 16:26:14 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Mon Jan 8 16:26:17 2007 Subject: [GRASS-dev] Re: GRASS startup window patches In-Reply-To: References: Message-ID: Hello Michael On Sun, 7 Jan 2007, Michael Barton wrote: > Paul, do you know how to get the information in PROJSHARE, as set in > configure, into an environmental variable instead of the current klunky way > it's used? I'd like to get this fixed in epsg_option--a last annoying issue. Sorry, missed this e-mail earlier. I've committed changes to CVS now that will set an environment variable called GRASS_PROJSHARE which should contain the correct path. It is set in Init.sh, and if the user sets GRASS_PROJSHARE before starting GRASS, then they can override it, i.e. over-ride the value that was set in the configure script. It can be referenced in epsg_option.tcl as $env(GRASS_PROJSHARE), but I had some troubles with the Tcl syntax so I didn't commit that part of the change. Essentially we should re-name epsg_option.tcl.in back to epsg_option.tcl, make the change there, and change the rule for epsg_option.tcl in the Makefile to look very similar to file_option.tcl. But even if you just make the change to epsg_option.tcl.in for now I can probably fix it up later. Assuming my ADSL connection stays up. Paul From glynn at gclements.plus.com Mon Jan 8 16:34:02 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Jan 8 16:34:13 2007 Subject: [GRASS-dev] i.image.mosaic/i.landsat.rgb In-Reply-To: <1a486f560701071838t297a1622w59921e27f5d7f140@mail.gmail.com> References: <1168207090.5112.36.camel@devel> <1a486f560701071838t297a1622w59921e27f5d7f140@mail.gmail.com> Message-ID: <17826.25706.51831.252405@cerise.gclements.plus.com> Daniel Calvelo wrote: > > i.image.mosaic errors out with the following: > > > > GRASS 6.3.cvs (black_rock):~ > i.image.mosaic image1=etm1.1 > > image2=etm2.1 image3=etm3.1 > > > > ATTENTION: Do not forget to set region properly to cover all images! > > > > i.image.mosaic: line 85: [: argument expected > > i.image.mosaic: line 106: [: argument expected > > i.image.mosaic: line 119: [: too many arguments > > Try this version. Looks good to me. FWIW, looking for unquoted variable substitutions with: cd $GISBASE/scripts grep -n '[^"]\$' * suggests that there may be quite a lot of these issues remaining. Many of those are false positives, e.g. because the variable substitution appears later in a quoted string rather than immediately after the opening quote. Also, some don't actually matter because the variable will always have a value which is a single word to the shell, but it's always a good idea to quote every variable substitution unless you actually *need* the value to be subjected to further parsing. Unquoted variable substitutions should be the exception rather than the norm. -- Glynn Clements From maris.gis at gmail.com Mon Jan 8 16:34:21 2007 From: maris.gis at gmail.com (Maris Nartiss) Date: Mon Jan 8 16:34:24 2007 Subject: [GRASS-dev] GRASS GEM and Ruby GEM name collision Message-ID: <2b3d8c1c0701080734q39b7856dya799c3b26862a3c4@mail.gmail.com> Hi folks, I just was browsing Gentoo bugzilla and found, that there is name collision between GRASS and Ruby Gems - both use "gem" as executable name. [1] As GEM is not yet very popular, could we just rename GEM executable to i.e. "grassgem" or something more specific? Or any other ideas how to fix name collision, as just using different install path (--prefix) is not a solution. WBR, Maris. [1] http://bugs.gentoo.org/show_bug.cgi?id=160809 From dca.gis at gmail.com Mon Jan 8 16:40:35 2007 From: dca.gis at gmail.com (Daniel Calvelo) Date: Mon Jan 8 16:40:38 2007 Subject: [GRASS-dev] GRASS GEM and Ruby GEM name collision In-Reply-To: <2b3d8c1c0701080734q39b7856dya799c3b26862a3c4@mail.gmail.com> References: <2b3d8c1c0701080734q39b7856dya799c3b26862a3c4@mail.gmail.com> Message-ID: <1a486f560701080740pc484bje8b7e514bde9f8f7@mail.gmail.com> 'g.em' :) ? Daniel On 1/8/07, Maris Nartiss wrote: > Hi folks, > > I just was browsing Gentoo bugzilla and found, that there is name > collision between GRASS and Ruby Gems - both use "gem" as executable > name. [1] > > As GEM is not yet very popular, could we just rename GEM executable to > i.e. "grassgem" or something more specific? Or any other ideas how to > fix name collision, as just using different install path (--prefix) is > not a solution. > > WBR, > Maris. > > [1] http://bugs.gentoo.org/show_bug.cgi?id=160809 > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > -- -- Daniel Calvelo Aros From glynn at gclements.plus.com Mon Jan 8 16:47:01 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Jan 8 16:47:05 2007 Subject: [GRASS-dev] g.list -a In-Reply-To: References: <17809.48637.726595.182177@cerise.gclements.plus.com> <1a486f560701030845j37776763m4350ff8d011d9984@mail.gmail.com> <1a486f560701051507r4e666e00r9460246917a4057e@mail.gmail.com> <17823.11054.35596.752944@cerise.gclements.plus.com> <17824.53630.559151.84699@cerise.gclements.plus.com> Message-ID: <17826.26485.477846.188869@cerise.gclements.plus.com> Martin Landa wrote: > I can see > > 1) the special flag in g.list (-a -> all types) Q: the 'type' > parameter should be requested or not requested? >From an implementation perspective, there is negligible difference between adding a -a flag or allowing a value of "all" for the type. The main difference is that a "-a" flag means that you need to remove the "required" attribute from the option and manually check that either -a or type= was given. > 2) the new data type 'all', Q: Should or shouldn't be avoided in other > manage modules (like g.remove, g.copy)? It doesn't make sense for the other modules, and might be problematic to implement; you would either have to perform a separate existence check for each type or ensure that non-existence of a particular type is handle correctly (e.g. "g.copy all=foo,foo2" *shouldn't* print a bunch of warnings: "no region named 'foo'", "no icon named 'foo'", ...). > Not sure what is better or more useful. If we don't want to use 'all' > in other modules (e.g. g.copy) I think the flag (1) would be (maybe) > better. Even if you used "all" in every module, you would still have to treat it separately; adding an "all" entry to etc/element_list wouldn't work. So, I don't really see much difference between: if (flag_a->answer) ... and: if (strcmp(element->answer, "all") == 0) ... in g.list. Actually, I'd favour the latter, as that leaves the "element->required = YES" intact, which makes the "g.list help" output a bit more informative. The help output (and HTML/XML output, the Tcl/Tk GUI etc) automatically indicates if a specific option is required, while manual either/or checks have to be documented manually and cannot be enforced by the GUI. -- Glynn Clements From tutey at o2.pl Mon Jan 8 17:17:48 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Mon Jan 8 17:17:52 2007 Subject: [GRASS-dev] GRASS GEM and Ruby GEM name collision In-Reply-To: <2b3d8c1c0701080734q39b7856dya799c3b26862a3c4@mail.gmail.com> References: <2b3d8c1c0701080734q39b7856dya799c3b26862a3c4@mail.gmail.com> Message-ID: <45A26EAC.3030505@o2.pl> Maris Nartiss wrote: > Hi folks, > > I just was browsing Gentoo bugzilla and found, that there is name > collision between GRASS and Ruby Gems - both use "gem" as executable > name. [1] > > As GEM is not yet very popular, could we just rename GEM executable to > i.e. "grassgem" or something more specific? Or any other ideas how to > fix name collision, as just using different install path (--prefix) is > not a solution. Hi, BTW, there is another issue - since gem is installed into the PREFIX/bin, versions comming with eg. GRASS 6.2.1 and 6.3 are in conflict. It used to be possible to have many GRASS versions installed in parallel, without confilcts. Maybe to fix it, along with changing the gem executable name, add a version suffix to it, and install only the link in PREFIX/bin, keeping the executable in $GISBASE/bin? I'd suggest the name to be gem_grass"suffix", eg. gem_grass63. Maciek P.S. There are references to following missing pictures in the GEM manual: /usr/lib/latex2html/icons/nx_grp_g.png /usr/lib/latex2html/icons/up_g.png /usr/lib/latex2html/icons/prev_g.png From jachym.cepicky at centrum.cz Mon Jan 8 18:21:07 2007 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Mon Jan 8 18:21:18 2007 Subject: [GRASS-dev] v.in.dxf and modified version of G_percent In-Reply-To: <17826.20821.439915.28039@cerise.gclements.plus.com> References: <20070107203001.GA30196@localdomain> <17826.20821.439915.28039@cerise.gclements.plus.com> Message-ID: <20070108172107.GA4201@localdomain> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070108/1247c49a/attachment.bin From jachym.cepicky at centrum.cz Mon Jan 8 18:26:08 2007 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Mon Jan 8 18:26:12 2007 Subject: [GRASS-dev] v.clean and G_message In-Reply-To: <45A228EE.1050008@o2.pl> References: <20070107190229.GA25756@localdomain> <45A228EE.1050008@o2.pl> Message-ID: <20070108172608.GB4201@localdomain> Hi, On Mon, Jan 08, 2007 at 12:20:14PM +0100, Maciej Sieczka wrote: > Jachym Cepicky wrote: > > > v.clean prints lots of tables to stderr, using partly fprintf, partly > > G_message. > > > > I would suggest, the tables should be printed to STDOUT and new flag -q > > should be added, for turning this messages off. > > > > What do you think? > > Hi Jachym > > You might like to take a look at > http://intevation.de/rt/webrt?serial_num=4524 > > Maciek Well, if I understand this well, v.clean is simply too verbose and it would be good to make it less verbose. I suggest, - redirect output from v.clean to stdout - add new flag -t/-q/-v for table/quiet/verbose printing/hiding the informations about cleaning tools and thier settings Any objections/suggestions ? Jachym -- Jachym Cepicky e-mail: jachym.cepicky@centrum.cz URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub ----------------------------------------- OFFICE: Department of Geoinformation Technologies Zemedelska 3 613 00, Brno Czech Republick e-mail: xcepicky@node.mendelu.cz URL: http://mapserver.mendelu.cz Tel.: +420 545 134 514 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070108/9314cf58/attachment.bin From rez at touchofmadness.com Mon Jan 8 22:38:50 2007 From: rez at touchofmadness.com (Brad Douglas) Date: Mon Jan 8 22:38:59 2007 Subject: [GRASS-dev] i.image.mosaic/i.landsat.rgb In-Reply-To: <17826.25706.51831.252405@cerise.gclements.plus.com> References: <1168207090.5112.36.camel@devel> <1a486f560701071838t297a1622w59921e27f5d7f140@mail.gmail.com> <17826.25706.51831.252405@cerise.gclements.plus.com> Message-ID: <1168292330.5112.80.camel@devel> On Mon, 2007-01-08 at 15:34 +0000, Glynn Clements wrote: > Daniel Calvelo wrote: > > > > i.image.mosaic errors out with the following: > > > > > > GRASS 6.3.cvs (black_rock):~ > i.image.mosaic image1=etm1.1 > > > image2=etm2.1 image3=etm3.1 > > > > > > ATTENTION: Do not forget to set region properly to cover all images! > > > > > > i.image.mosaic: line 85: [: argument expected > > > i.image.mosaic: line 106: [: argument expected > > > i.image.mosaic: line 119: [: too many arguments > > > > Try this version. > > Looks good to me. BTW, while that version got i.image.mosaic working, it's just as broken as i.landsat.rgb. It clips all images to the dimensions of the first one and overlays them, not patch them together. I've been using r.patch, instead. :( -- Brad Douglas KB8UYR/6 Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From grass-bugs at intevation.de Mon Jan 8 22:51:49 2007 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Mon Jan 8 22:51:51 2007 Subject: [GRASS-dev] [bug #5421] (grass) Bug importing r.in.gdal .flt format in the version 6.2.1 Message-ID: <20070108215149.7C3081005AD@lists.intevation.de> In communication offlist with Fernando the issue has been sorted out. The reason is either a bug in GDAL or a corrupted dataset. Not a GRASS bug. Closing it. Maciek -------------------------------------------- Managed by Request Tracker From michael.barton at asu.edu Tue Jan 9 07:16:18 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Jan 9 07:16:33 2007 Subject: [GRASS-dev] Problem with v.net change Message-ID: Jachym, The recent change you made to v.net seems to break it on my Mac. I just tried to compile it and got the following error... cmb-MBP:~/grass_dev/grass6/vector/v.net cmbarton$ make gcc -L/Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.8.2/lib -I/Library/Frameworks/GDAL.framework/unix/include -DPACKAGE=\""grassmods"\" -o /Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.8.2/bin/v.net OBJ.i686-apple-darwin8.8.2/main.o OBJ.i686-apple-darwin8.8.2/nodes.o OBJ.i686-apple-darwin8.8.2/report.o -lgrass_vect -lgrass_dbmibase -lgrass_gis -lgrass_datetime -lz -lgrass_dbmiclient -lgrass_dbmibase -lgrass_gis -lgrass_datetime -lz -lgrass_gis -lgrass_datetime -lz -lgrass_dgl -lgrass_dig2 -lgrass_gis -lgrass_datetime -lz -lgrass_rtree -lgrass_gis -lgrass_datetime -lz -lgrass_linkm -lgrass_rtree -lgrass_dig2 -lgrass_gis -lgrass_datetime -lz -lgrass_rtree -lgrass_dgl -lgrass_rtree -lgrass_linkm -lgrass_dbmiclient -lgrass_dbmibase -lgrass_gis -lgrass_datetime -lz -lgrass_gis -lgrass_datetime -lz -lgrass_dbmibase -lgrass_gis -lgrass_datetime -lz -L/Library/Frameworks/GDAL.framework/unix/lib -lgdal -L/Library/Frameworks/PROJ.framework/unix/lib -lproj -L/Library/Frameworks/GEOS.framework/unix/lib -lgeos -lgeos_c -liodbc -liodbcinst -L/Library/Frameworks/Xerces.framework/unix/lib -lxerces-c -lpthread -L/Library/Frameworks/UnixImageIO.framework/unix/lib -lgif -ljpeg -ltiff -lpng -lpam -lssl -lcrypto -lkrb5 -lz -lpthread -ldl -lxml2 -liconv -lm -framework SQLite3 -lgrass_gis -lgrass_datetime -lz -lz /usr/bin/ld: Undefined symbols: __ collect2: ld returned 1 exit status make: *** [/Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.8.2/bin/v.net] Error 1 cmb-MBP:~/grass_dev/grass6/vector/v.net cmbarton$ 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/20070108/5b1b009e/attachment.html From jachym.cepicky at centrum.cz Tue Jan 9 07:25:32 2007 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Tue Jan 9 07:25:36 2007 Subject: [GRASS-dev] Re: Problem with v.net change In-Reply-To: References: Message-ID: <20070109062532.GA15980@localdomain> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 fixed, sorry for this, I did not see it jachym On Mon, Jan 08, 2007 at 11:16:18PM -0700, Michael Barton wrote: > Jachym, > > The recent change you made to v.net seems to break it on my Mac. I just > tried to compile it and got the following error... > > > cmb-MBP:~/grass_dev/grass6/vector/v.net cmbarton$ make > gcc -L/Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.8.2/lib > -I/Library/Frameworks/GDAL.framework/unix/include > -DPACKAGE=\""grassmods"\" -o > /Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.8.2/bin/v.net > OBJ.i686-apple-darwin8.8.2/main.o OBJ.i686-apple-darwin8.8.2/nodes.o > OBJ.i686-apple-darwin8.8.2/report.o -lgrass_vect -lgrass_dbmibase > -lgrass_gis -lgrass_datetime -lz -lgrass_dbmiclient -lgrass_dbmibase > -lgrass_gis -lgrass_datetime -lz -lgrass_gis -lgrass_datetime -lz > -lgrass_dgl -lgrass_dig2 -lgrass_gis -lgrass_datetime -lz -lgrass_rtree > -lgrass_gis -lgrass_datetime -lz -lgrass_linkm -lgrass_rtree > -lgrass_dig2 -lgrass_gis -lgrass_datetime -lz -lgrass_rtree -lgrass_dgl > -lgrass_rtree -lgrass_linkm -lgrass_dbmiclient -lgrass_dbmibase -lgrass_gis > -lgrass_datetime -lz -lgrass_gis -lgrass_datetime -lz > -lgrass_dbmibase -lgrass_gis -lgrass_datetime -lz > -L/Library/Frameworks/GDAL.framework/unix/lib -lgdal > -L/Library/Frameworks/PROJ.framework/unix/lib -lproj > -L/Library/Frameworks/GEOS.framework/unix/lib -lgeos -lgeos_c -liodbc > -liodbcinst -L/Library/Frameworks/Xerces.framework/unix/lib -lxerces-c > -lpthread -L/Library/Frameworks/UnixImageIO.framework/unix/lib -lgif -ljpeg > -ltiff -lpng -lpam -lssl -lcrypto -lkrb5 -lz -lpthread -ldl -lxml2 -liconv > -lm -framework SQLite3 -lgrass_gis -lgrass_datetime -lz -lz > /usr/bin/ld: Undefined symbols: > __ > collect2: ld returned 1 exit status > make: *** > [/Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.8.2/bin/v.net] > Error 1 > cmb-MBP:~/grass_dev/grass6/vector/v.net cmbarton$ > > > 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 > > - -- Jachym Cepicky e-mail: jachym.cepicky@centrum.cz URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub - ----------------------------------------- OFFICE: Department of Geoinformation Technologies Zemedelska 3 613 00, Brno Czech Republick e-mail: xcepicky@node.mendelu.cz URL: http://mapserver.mendelu.cz Tel.: +420 545 134 514 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFFozVcyKt0uAjU4I8RAuUBAJ0YaJmwMGSLn7ceG4fjlfN3ckYxmACghHBE GF6yWp9Kdox6jiQXM90wwkY= =MH1s -----END PGP SIGNATURE----- From michael.barton at asu.edu Tue Jan 9 08:18:33 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Jan 9 08:18:50 2007 Subject: [GRASS-dev] Re: GRASS startup window patches In-Reply-To: Message-ID: Paul, On 1/8/07 8:26 AM, "Paul Kelly" wrote: > It can be referenced in epsg_option.tcl as $env(GRASS_PROJSHARE), but I > had some troubles with the Tcl syntax so I didn't commit that part of the > change. Essentially we should re-name epsg_option.tcl.in back to > epsg_option.tcl, make the change there, and change the rule for > epsg_option.tcl in the Makefile to look very similar to file_option.tcl. > But even if you just make the change to epsg_option.tcl.in for now I can > probably fix it up later. Assuming my ADSL connection stays up. I did all this. I'm a little nervous messing with make files, but this seemed pretty straightforward. I just used the reference to file_option.tcl as a model. I also removed projshare.sed and make_location_epsg.ini as they are no longer needed, along with their references in the makefile. I tested it all in a new build on my Mac and it went fine. The new environmental variable works very well. Thanks much. 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 benjamin.ducke at ufg.uni-kiel.de Tue Jan 9 08:53:49 2007 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Tue Jan 9 08:40:14 2007 Subject: [GRASS-dev] GRASS GEM and Ruby GEM name collision In-Reply-To: <45A26EAC.3030505@o2.pl> References: <2b3d8c1c0701080734q39b7856dya799c3b26862a3c4@mail.gmail.com> <45A26EAC.3030505@o2.pl> Message-ID: <45A34A0D.9020403@ufg.uni-kiel.de> OK, I have a few updates pending for GEM and will hopefully be able to commit them this weekend, fixing all the problems reported so far by various users. How about just using gem62, gem63 etc. as executable names -- wouldn't that be enough to make sure it does not conflict with the Ruby tool? Benjamin Maciej Sieczka wrote: > Maris Nartiss wrote: >> Hi folks, >> >> I just was browsing Gentoo bugzilla and found, that there is name >> collision between GRASS and Ruby Gems - both use "gem" as executable >> name. [1] >> >> As GEM is not yet very popular, could we just rename GEM executable to >> i.e. "grassgem" or something more specific? Or any other ideas how to >> fix name collision, as just using different install path (--prefix) is >> not a solution. > > Hi, > > BTW, there is another issue - since gem is installed into the > PREFIX/bin, versions comming with eg. GRASS 6.2.1 and 6.3 are in > conflict. It used to be possible to have many GRASS versions installed > in parallel, without confilcts. Maybe to fix it, along with changing > the gem executable name, add a version suffix to it, and install only > the link in PREFIX/bin, keeping the executable in $GISBASE/bin? > > I'd suggest the name to be gem_grass"suffix", eg. gem_grass63. > > Maciek > > P.S. > There are references to following missing pictures in the GEM manual: > > /usr/lib/latex2html/icons/nx_grp_g.png > /usr/lib/latex2html/icons/up_g.png > /usr/lib/latex2html/icons/prev_g.png > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > > -- Benjamin Ducke, M.A. Arch?oinformatik (Archaeoinformation Science) Institut f?r Ur- und Fr?hgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universit?t zu Kiel Johanna-Mestorf-Stra?e 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg From landa.martin at gmail.com Tue Jan 9 09:10:13 2007 From: landa.martin at gmail.com (Martin Landa) Date: Tue Jan 9 09:10:15 2007 Subject: [GRASS-dev] g.list -a In-Reply-To: <17826.26485.477846.188869@cerise.gclements.plus.com> References: <1a486f560701030845j37776763m4350ff8d011d9984@mail.gmail.com> <1a486f560701051507r4e666e00r9460246917a4057e@mail.gmail.com> <17823.11054.35596.752944@cerise.gclements.plus.com> <17824.53630.559151.84699@cerise.gclements.plus.com> <17826.26485.477846.188869@cerise.gclements.plus.com> Message-ID: Hi, 2007/1/8, Glynn Clements : > > 1) the special flag in g.list (-a -> all types) Q: the 'type' > > parameter should be requested or not requested? > > From an implementation perspective, there is negligible difference > between adding a -a flag or allowing a value of "all" for the type. > > The main difference is that a "-a" flag means that you need to remove > the "required" attribute from the option and manually check that > either -a or type= was given. > > > 2) the new data type 'all', Q: Should or shouldn't be avoided in other > > manage modules (like g.remove, g.copy)? > > It doesn't make sense for the other modules, and might be problematic > to implement; you would either have to perform a separate existence > check for each type or ensure that non-existence of a particular type > is handle correctly (e.g. "g.copy all=foo,foo2" *shouldn't* print a > bunch of warnings: "no region named 'foo'", "no icon named 'foo'", > ...). > > > Not sure what is better or more useful. If we don't want to use 'all' > > in other modules (e.g. g.copy) I think the flag (1) would be (maybe) > > better. > > Even if you used "all" in every module, you would still have to treat > it separately; adding an "all" entry to etc/element_list wouldn't > work. So, I don't really see much difference between: > > if (flag_a->answer) > ... > and: > if (strcmp(element->answer, "all") == 0) > ... > > in g.list. > > Actually, I'd favour the latter, as that leaves the > "element->required = YES" intact, which makes the "g.list help" output > a bit more informative. The help output (and HTML/XML output, the > Tcl/Tk GUI etc) automatically indicates if a specific option is > required, while manual either/or checks have to be documented > manually and cannot be enforced by the GUI. OK, your argumentation seems to be right. 1) Q: allowing multiple data type would be useful for the user - is it desired ? e.g. type=rast,vect,region 2) It seems better to add the type 'all' to g.list manually (especially because of the requested type parameter). I am not sure how to do it in an elegant way (see the patch) - my approach seems to be very ugly. Any objections or suggestions? Martin -- Martin Landa * http://gama.fsv.cvut.cz/~landa * -------------- next part -------------- A non-text attachment was scrubbed... Name: g_list_all-4.diff.gz Type: application/x-gzip Size: 2926 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070109/26b8acb0/g_list_all-4.diff.gz From landa.martin at gmail.com Tue Jan 9 09:17:50 2007 From: landa.martin at gmail.com (Martin Landa) Date: Tue Jan 9 09:17:52 2007 Subject: [GRASS-dev] g.list -a In-Reply-To: <45A22A55.7000907@o2.pl> References: <1a486f560701030845j37776763m4350ff8d011d9984@mail.gmail.com> <1a486f560701051507r4e666e00r9460246917a4057e@mail.gmail.com> <17823.11054.35596.752944@cerise.gclements.plus.com> <17824.53630.559151.84699@cerise.gclements.plus.com> <1a486f560701071740n2bc9b37ekdc5bdcc5d8205907@mail.gmail.com> <45A22A55.7000907@o2.pl> Message-ID: Hi, 2007/1/8, Maciej Sieczka : > Or maybe add option type=all to g.mlist? it is good idea (personally I am not sure if the type for all data types should be implemented in g.list). In any case g.mlist should be updated according to the changes in g.list (i.e. multiple type parameter). Martin -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From glynn at gclements.plus.com Tue Jan 9 12:16:27 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Jan 9 12:16:31 2007 Subject: [GRASS-dev] g.list -a In-Reply-To: References: <1a486f560701030845j37776763m4350ff8d011d9984@mail.gmail.com> <1a486f560701051507r4e666e00r9460246917a4057e@mail.gmail.com> <17823.11054.35596.752944@cerise.gclements.plus.com> <17824.53630.559151.84699@cerise.gclements.plus.com> <17826.26485.477846.188869@cerise.gclements.plus.com> Message-ID: <17827.31115.58158.918005@cerise.gclements.plus.com> Martin Landa wrote: > 1) Q: allowing multiple data type would be useful for the user - is it desired ? > e.g. type=rast,vect,region I think so. Once g.list can list all types, making it list an arbitrary set of types is simple enough. > 2) It seems better to add the type 'all' to g.list manually > (especially because of the requested type parameter). I am not sure > how to do it in an elegant way (see the patch) - my approach seems to > be very ugly. I would abandon the approach of having a separate "parse" function in favour of iterating over element->answers and listing each type as it's encountered. lib/do_list.c doesn't need to change; just have cmd/list.c call do_list() once for each type. -- Glynn Clements From maris.gis at gmail.com Tue Jan 9 12:49:07 2007 From: maris.gis at gmail.com (Maris Nartiss) Date: Tue Jan 9 12:49:09 2007 Subject: [GRASS-dev] Re: GRASS startup window patches, map names restrictions In-Reply-To: <17826.22220.592.931756@cerise.gclements.plus.com> References: <1168104407.18468.142.camel@devel> <2b3d8c1c0701061110g4550394ai11901cc1e8444449@mail.gmail.com> <2b3d8c1c0701070234k359a82adp7a986ae363771334@mail.gmail.com> <17826.22220.592.931756@cerise.gclements.plus.com> Message-ID: <2b3d8c1c0701090349h1ab3a32dm39ca91b7ec75d6be@mail.gmail.com> Hi Glynn, I know, that GRASS SHOULD be encoding etc. neutral, but not all GRASS code is 100% perfect and it may take too much time to check all possible breakage places. IMHO it would be more easy to just push some policy about allowing only latin letters and numbers + some safe symbols. Atleast until GRASS 7 with new GUI and major code check is done. This is a good topic for PSC to discuss/wote on ;) More comments inline. My system: Gentoo Linux 32bit ~x86, locale="lv_LV.UTF-8", last weeks GRASS 6.3cvs, tcl/tk 8.4.13 2007/1/8, Glynn Clements : > > Maris Nartiss wrote: > > > I can confirm, that using non-latin character with UTF-8 encoding in > > mapset name, will make mapset/GRASS unusable. > > Can you provide any more details? I created in startup screen new mapset called "????", pressed "enter grass" and gis.m startup failed due to fail of g.region with message: "Illegal filename. Character not allowed." > > > Map names also can not contain unicode characters. > > Location with unicode chars seem to be OK. Except, it will break > > startup screen in text mode :) > > IMHO other GRASS places are also not unicode aware. > > GRASS itself shouldn't need to be "unicode aware"; most code should be > "neutral" regarding encodings, i.e. just treat strings as strings of > bytes, not characters. > > Problems are most likely to arise within the UI, where strings of > bytes have to be decoded to strings of characters for rendering (this > applies both to graphical toolkits and curses). Same goes for map names from command line: GRASS 6.3.cvs (a new Location):~ > r.random.surface output=???? Illegal filename. Character v.random output=???? n=20 Illegal filename. Character . J?s?kas ar burtu. K??DA:Kartes nosaukums nav SQL savietojams. > > Probably we should push forward policy, that only latin characters and > > numbers are allowed in map/mapset names? Like "[a-Z] [0-9] _-". > > Most ASCII punctuation characters should be allowed except when they > already have specific meanings to GRASS (e.g. = and , are both > significant to the parser, @ is used for map@mapset etc). Space, "{" and "}" should be banned, as creating location "a new location" and mapset "a new mapset" or "{ a mapset }" will result in g.region fail: "Illegal filename. Character < > not allowed." Entering into location with space in name in text mode is impossible, as part before space is only accepted. Same applys to chars with special meanings in shell "$" "#" as they may be incorrectly escaped/enclosed in quotes in scripts or make scripting from console harder. > > Vector maps are problematic due to the decision to use map names as > SQL table names without any translation, meaning that map names are > constrained by SQL syntax. > > > Pros for such approach: no need to check all GRASS code to be unicode > > etc. aware. > > Cons: limit's user choice; Unfriendly to non-English speakers. > > GRASS C code should just treat all bytes in the range 128-255 as > "letters", subject to the limitation that case-folding won't apply > (i.e. ? and ? are considered different even in contexts where e and E > are considered equal). > > If other libraries (e.g. Tcl/Tk) want to interpret byte strings as > character strings, it's the user's responsibility to use an > appropriate encoding. > > Curses is essentially limited to unibyte encodings; in any case, > languages which absolutely require multibyte encodings (CJK) have > problems due to "monospace" (halfwidth/fullwidth) issues. > > One other factor to bear in mind is that, on Windows, filenames (and > thus map names, mapset names etc) are interpreted according to the > current codepage, which almost certainly *won't* be UTF-8. > > -- > Glynn Clements > As GRASS is more widely addopted in many countries, it should clrearly state it's position to UTF-8 and symbols in mapset/map names. Just trying to make GRASS better, Maris. From glynn at gclements.plus.com Tue Jan 9 13:31:34 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Jan 9 13:31:39 2007 Subject: [GRASS-dev] v.in.dxf and modified version of G_percent In-Reply-To: <20070108172107.GA4201@localdomain> References: <20070107203001.GA30196@localdomain> <17826.20821.439915.28039@cerise.gclements.plus.com> <20070108172107.GA4201@localdomain> Message-ID: <17827.35622.36336.878043@cerise.gclements.plus.com> Jachym Cepicky wrote: > > > IMHO v.in.dxf should use G_percent too. What kind of approach is the > > > best: > > > > > > - Rewrite G_percent, so it uses long integers on input > > > - New function G_percent_big for cases like this > > > - Nothing, using G_percent directly will not cause any problem > > > > I suggest taking the first approach. > > Could you review this patch, please? It seems to work for me, but I have > no real imagination about the number types and how they are compatible in C. I've committed it with a couple of minor changes: 1. The doxygen comments have been updated to the new prototypes. 2. The "s" parameter (which is a percentage) remains an "int". -- Glynn Clements From glynn at gclements.plus.com Tue Jan 9 22:41:42 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Jan 9 22:41:47 2007 Subject: [GRASS-dev] Re: GRASS startup window patches, map names restrictions In-Reply-To: <2b3d8c1c0701090349h1ab3a32dm39ca91b7ec75d6be@mail.gmail.com> References: <1168104407.18468.142.camel@devel> <2b3d8c1c0701061110g4550394ai11901cc1e8444449@mail.gmail.com> <2b3d8c1c0701070234k359a82adp7a986ae363771334@mail.gmail.com> <17826.22220.592.931756@cerise.gclements.plus.com> <2b3d8c1c0701090349h1ab3a32dm39ca91b7ec75d6be@mail.gmail.com> Message-ID: <17828.3094.303132.205067@cerise.gclements.plus.com> Maris Nartiss wrote: > I know, that GRASS SHOULD be encoding etc. neutral, but not all GRASS > code is 100% perfect and it may take too much time to check all > possible breakage places. IMHO it would be more easy to just push some > policy about allowing only latin letters and numbers + some safe > symbols. It might be worthwhile informing users that non-ASCII characters are problematic, but so far as developers are concerned, problems with non-ASCII characters should be fixed rather than worked around wherever practical, IMHO. Certainly: 1. Nothing should actively prohibit the user from using non-ASCII characters on the basis that other parts of GRASS *might* not handle them correctly. 2. Advising users of difficulties with non-ASCII characters shouldn't be considered a substitute for making code 8-bit clean. > > > I can confirm, that using non-latin character with UTF-8 encoding in > > > mapset name, will make mapset/GRASS unusable. > > > > Can you provide any more details? > > I created in startup screen new mapset called "-Dà-B¹-Dñ¶", pressed "enter-A > grass" and gis.m startup failed due to fail of g.region with message: > "Illegal filename. Character <Ä> not allowed." Right; that comes from the following in G_legal_filename(): if (*s == '/' || *s == '"' || *s == '\'' || *s <= ' ' || *s == '@' || *s == ',' || *s == '=' || *s == '*' || *s > 0176) { fprintf(stderr, _("Illegal filename. Character <%c> not allowed.\n"), *s); Note that it's probably *not* the "*s > 0176" test which is triggered, but the "*s <= ' '" test, as "s" has type "char *" and "char" with no "signed" or "unsigned" qualifier is normally signed. ANSI C states that it's implementation dependent whether "char" is signed or unsigned; gcc can be forced to use a particular interpretation with -funsigned-char or -fsigned-char. That issue is probably more significant than any actual encoding issues; G_legal_filename() probably isn't the only place that overlooked the fact that "char" normally ranges from -128 to 127, not 0 to 255. I strongly suggest removing that test from development versions, as it prevents us from testing anything related to filename encoding issues. > > > Probably we should push forward policy, that only latin characters and > > > numbers are allowed in map/mapset names? Like "[a-Z] [0-9] _-". > > > > Most ASCII punctuation characters should be allowed except when they > > already have specific meanings to GRASS (e.g. = and , are both > > significant to the parser, @ is used for map@mapset etc). > > Space, "{" and "}" should be banned, as creating location "a new > location" and mapset "a new mapset" or "{ a mapset }" will result in > g.region fail: > "Illegal filename. Character < > not allowed." > Entering into location with space in name in text mode is impossible, > as part before space is only accepted. The names of locations, mapsets and maps shouldn't contain spaces, but the database directory might (on Windows, the user might only be able to create files beneath e.g. "C:\Documents and Settings"), as might the names of files being imported or exported. > Same applys to chars with special meanings in shell "$" "#" as they > may be incorrectly escaped/enclosed in quotes in scripts or make > scripting from console harder. Those characters should be permitted. It's up to the user whether they consider issues related to Bourne shell syntax to be relevant. If they aren't typing map names into a shell, it isn't an issue. Shell scripts should work with whatever names they're given. Which isn't hard; you just need to remember to quote variable substitutions, i.e. "$foo" (with the quotes) rather than just $foo. Single and double quotes are currently prohibited, although that isn't strictly necessary. Both are slightly problematic in r.mapcalc (a map whose name includes both a single quote and a double quote cannot be entered), but even that could be fixed if it was an issue. The single quote is problematic mostly because of code such as: sprintf(buf, "g.foo map='%s'", mapname); system(buf); If we were to allow single quotes, every such use of system() would have to be fixed. OTOH, using system() is bad enough in and of itself; hopefully we will reduce its use in due course (G_spawn() doesn't have this problem, as it doesn't use /bin/sh). > As GRASS is more widely addopted in many countries, it should clrearly > state it's position to UTF-8 and symbols in mapset/map names. There are three distinct issues here: 1. ASCII punctuation (or characters which are otherwise "significant"). 2. Non-ASCII (8-bit) characters. 3. Multibyte encodings. #1 is problematic due to lots of individual cases, i.e. specific characters having a specific purpose in specific cases. #2 is problematic due to signed/unsigned issues in a few places, and due to third-party code which assumes specific encodings. #3 is problematic simply because multibyte encodings are harder to deal with than unibyte encodings, and most existing code assumes unibyte encodings (except for code related to FreeType fonts in the display system, which explicitly uses iconv to convert from a user-specified encoding to unicode). -- Glynn Clements From ychemin at gmail.com Wed Jan 10 08:45:00 2007 From: ychemin at gmail.com (Yann Chemin) Date: Wed Jan 10 08:45:11 2007 Subject: [GRASS-dev] s.surf.idw.mpi equivalent for grass6.x Message-ID: <6278879c0701092345o33e0df25pa40ed351aa43cb93@mail.gmail.com> Hi list, is there any "port" or new version of s.surf.idw.mpi to grass6.x. If not, what would be the (rough) direction to take to make it a 6.x program? thanks Yann -- ---- From grass-bugs at intevation.de Wed Jan 10 16:34:45 2007 From: grass-bugs at intevation.de (Request Tracker) Date: Wed Jan 10 16:34:47 2007 Subject: [GRASS-dev] [bug #5427] (grass) v.overlay does not run properly with operator=and Message-ID: <20070110153445.E2FAE1005A3@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5427 ------------------------------------------------------------------------- Subject: v.overlay does not run properly with operator=and Platform: GNU/Linux/x86 grass obtained from: Other (CDROM etc) grass binary for platform: Downloaded precompiled Binaries GRASS Version: 6.2.0-1 I've tested the following : create the intersection from layer B to layer A compared with intersection from layer A to layer B : CASE 1 : v.overlay ainput=mpnetwork atype=area binput=management_polygones atype=area output=base_cells operator=and CASE 2 : v.overlay ainput=management_polygones atype=area binput=mpnetwork atype=area output=base_cells operator=and The resulting intersection are different and seems to be uncorrect : CASE 1 : GRASS 6.2.0 (ALMERIA):~/Documents/ucl/alert/grass > v.db.select map=base_cells column=a_cat,b_cat,a_area_tot,b_area_tot where="a_cat=37" a_cat|b_cat|a_area_tot|b_area_tot 37|10|1000000|15000 37|13|1000000|0 37|1|1000000|0 37|8|1000000|0 37|14|1000000|0 37|11|1000000|1527000 CASE 2 : GRASS 6.2.0 (ALMERIA):~/Documents/ucl/alert/grass > v.db.select map=base_cells column=a_cat,b_cat,a_area_tot,b_area_tot where="b_cat=37" a_cat|b_cat|a_area_tot|b_area_tot ... this is a very strange behaviour ... the CASE 1 gives the correct intersection and not the CASE2 ... The problem is bigger that that : The attribute table created in CASE1 is not totally correct. The b_input as a b_tot_area value for all the vectors but in the resulting attribute table, you see that for b_cat 13, 1,8 and 14, the outputed value is 0. I can provide the input file if needed. Didrik -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Thu Jan 11 07:12:37 2007 From: grass-bugs at intevation.de (Request Tracker) Date: Thu Jan 11 07:12:40 2007 Subject: [GRASS-dev] [bug #5428] (grass) In installation Message-ID: <20070111061237.E48A810015A@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5428 ------------------------------------------------------------------------- Subject: In installation Platform: other grass binary for platform: Downloaded precompiled Binaries GRASS Version: 6.0.0 Hello This is Deepthi. I am a student I want to install the grass on Fedora 5 Actually I have tried all the istallation methods. Even I am unable to trackout the problem with my installation. I request you to send the sequence of installing GRASS on Fedora 5 with all required libraries and required information. My mail id is deep_4712@yahoo.com Thanks in advance -------------------------------------------- Managed by Request Tracker From mlennert at club.worldonline.be Thu Jan 11 10:03:16 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Thu Jan 11 10:01:28 2007 Subject: [GRASS-dev] gis.m crashes on zoom to map existing in more than one mapset In-Reply-To: References: Message-ID: <45A5FD54.2070804@club.worldonline.be> On 06/01/07 00:28, Michael Barton wrote: > I just committed Paul's fix that pipes g.region commands through grocat. > Maybe check to see if this fixes this crash on warning too. Sorry for the delay. Yes, this seems fixed now. Thanks ! Moritz From jachym.cepicky at centrum.cz Thu Jan 11 10:38:41 2007 From: jachym.cepicky at centrum.cz (Jachym Cepicky) Date: Thu Jan 11 10:38:45 2007 Subject: [GRASS-dev] georectifier - zooming and rectifying Message-ID: <20070111093841.GA15287@localdomain> Hello, while I was working with latest georectifier, I came to following issues: When I set couple of GCPs and zoom in/out, the GPCs are displayd always "one zoom step too late". It looks like they would use zoom scale from window/previous_zoom. Second thing: When I click on the "Rectify maps in the group" button, every window in the gis manager becomes inactive. Strange thing is, that processor does not work really hard (i.rectify is running with about 20-50 % load) and the whole process takes too long. When I run i.rectify from CLI, it takes only couple of minutes and the processor is really heated up. It is a bit confusing, just to sit in front of inactive gis manager and to see, that the computer is not really working and wonder, what is happening. I do not know, if we can do something with this issue - I beleave, it is something between Tcl and OS. I just ask, if it would be possible. Maybe small information window before calculation start, that "This could take couple of minutes", forking the "i.rectify process" to background, so that rest of the gis.m would be usable or something like this could help to keep the user informed. Thanks Jachym -- Jachym Cepicky e-mail: jachym.cepicky@centrum.cz URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub ----------------------------------------- OFFICE: Department of Geoinformation Technologies Zemedelska 3 613 00, Brno Czech Republick e-mail: xcepicky@node.mendelu.cz URL: http://mapserver.mendelu.cz Tel.: +420 545 134 514 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070111/e73012bf/attachment.bin From mlennert at club.worldonline.be Thu Jan 11 11:47:39 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Thu Jan 11 11:45:49 2007 Subject: [GRASS-dev] ps.map fprintf -> G_ In-Reply-To: References: <20070103165026.GB6831@localdomain> <20070107081813.GC10502@localdomain> <45A23936.4080200@club.worldonline.be> Message-ID: <45A615CB.9080802@club.worldonline.be> On 08/01/07 15:50, Martin Landa wrote: > Hi, > > 2007/1/8, Moritz Lennert : > >> Hamish wrote: >> > pps- ps.map verbose command IS used in the wild, so don't break >> scripts by >> > removing it altogether. Note it is multi-leveled, so it should keep >> at least 3 >> > levels of verbosity triggered by --q,<>,--v, i.e. standard messages >> should use >> > G_message(), but very verbose messages should hide G_message() in >> if(verbose >= >> > G_max_verbose()) or whatever. I am in favour of separating mapping >> commands >> > from program control, and letting the parser deal with the latter. > > I am not sure if I understand well. It is true that verbose mapping > instruction is multi-leveled (0|1|2). But in practice there was only > one condition: if (verbose > 1) fprintf ();. It would be good to > distinguish between standard and verbose messages as Hamish suggested. > I am not sure what messages are "standard" and "very verbose". > > In the first patch verbose instruction overwrote the --v/q flags [1], > now verbose instruction was removed and added a warning about that. So > should I apply rather the first approach (including G_set_verbose) ? I don't no about the different levels, but I think Hamish' main message was that you should not break existing scripts by removing the verbose command within ps.map. Moritz From landa.martin at gmail.com Thu Jan 11 15:09:28 2007 From: landa.martin at gmail.com (Martin Landa) Date: Thu Jan 11 15:09:30 2007 Subject: [GRASS-dev] g.list -a In-Reply-To: <17827.31115.58158.918005@cerise.gclements.plus.com> References: <1a486f560701051507r4e666e00r9460246917a4057e@mail.gmail.com> <17823.11054.35596.752944@cerise.gclements.plus.com> <17824.53630.559151.84699@cerise.gclements.plus.com> <17826.26485.477846.188869@cerise.gclements.plus.com> <17827.31115.58158.918005@cerise.gclements.plus.com> Message-ID: Hi Glynn, 2007/1/9, Glynn Clements : [snip] > > 2) It seems better to add the type 'all' to g.list manually > > (especially because of the requested type parameter). I am not sure > > how to do it in an elegant way (see the patch) - my approach seems to > > be very ugly. > > I would abandon the approach of having a separate "parse" function in > favour of iterating over element->answers and listing each type as > it's encountered. well, I have tried to simplify the patch. Functions parse() & do_list() are now called for each element->answers[i]. I hope it is better now. > lib/do_list.c doesn't need to change; just have cmd/list.c call > do_list() once for each type. I think that fn do_list() have to be rewritten because of the -f flags (calling of execl() fn) ? Martin > -- > Glynn Clements > -- Martin Landa * http://gama.fsv.cvut.cz/~landa * -------------- next part -------------- A non-text attachment was scrubbed... Name: g_list_all-5.diff.gz Type: application/x-gzip Size: 2480 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070111/8316d73f/g_list_all-5.diff.gz From glynn at gclements.plus.com Fri Jan 12 12:59:51 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Jan 12 12:59:57 2007 Subject: [GRASS-dev] g.list -a In-Reply-To: References: <1a486f560701051507r4e666e00r9460246917a4057e@mail.gmail.com> <17823.11054.35596.752944@cerise.gclements.plus.com> <17824.53630.559151.84699@cerise.gclements.plus.com> <17826.26485.477846.188869@cerise.gclements.plus.com> <17827.31115.58158.918005@cerise.gclements.plus.com> Message-ID: <17831.30775.97473.434440@cerise.gclements.plus.com> Martin Landa wrote: > [snip] > > > > 2) It seems better to add the type 'all' to g.list manually > > > (especially because of the requested type parameter). I am not sure > > > how to do it in an elegant way (see the patch) - my approach seems to > > > be very ugly. > > > > I would abandon the approach of having a separate "parse" function in > > favour of iterating over element->answers and listing each type as > > it's encountered. > > well, I have tried to simplify the patch. Functions parse() & > do_list() are now called for each element->answers[i]. I hope it is > better now. + if (G_parser(argc, argv)) + { + fprintf (stderr, _("\nWhere %s is one of:\n"), element->key); + show_elements(); + exit(EXIT_FAILURE); + } If G_parser() fails, the program should just call exit(EXIT_FAILURE); G_parser() will print an error message detailing why it failed. > > lib/do_list.c doesn't need to change; just have cmd/list.c call > > do_list() once for each type. > > I think that fn do_list() have to be rewritten because of the -f flags > (calling of execl() fn) ? No; do_list() can remain untouched, while the handling of -f should remain essentially the same, except that it should use G_spawn() instead of execl(). -- Glynn Clements From grass-bugs at intevation.de Fri Jan 12 16:29:13 2007 From: grass-bugs at intevation.de (Request Tracker) Date: Fri Jan 12 16:29:16 2007 Subject: [GRASS-dev] [bug #5431] (grass) landscape generator - control patches Message-ID: <20070112152913.D7DC61005CB@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5431 ------------------------------------------------------------------------- Subject: landscape generator - control patches Platform: GNU/Linux/x86 grass binary for platform: Compiled from Sources GRASS Version: cvs 11.01.2007 Hello, the landscape generating modules in GRASS are great but it would be very handy if you can control for size/shape/amount of patches (Total amount of habitat in the window, amount of patches, mean patch size + stddev, shape + stddev etc.) Such a program existed (LSF), I contacted the authors of the LSF Program for fragmented landscapes generation (Christina D. Hargis1, John A. Bissonette1 and John L. David (1998) The behavior of landscape metrics commonly used in the study of habitat fragmentation. Landscape Ecology Volume 13, Number 3 / June 1998) This software was used to "generate artificial landscapes that mimicked fragmentation processes while controlling the size and shape of patches in the landscape and the mode of disturbance growth". Unfortunately the program does not exist anymore (development stopped) and the language was written for a software which is now proprietary hence it is not available anymore. Such a module would be very handy in conjunction with already existing modules (landscape generater, r.li) regards, Martin -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Fri Jan 12 17:04:41 2007 From: grass-bugs at intevation.de (Request Tracker) Date: Fri Jan 12 17:04:43 2007 Subject: [GRASS-dev] [bug #5432] (grass) gis.m: display option (e.g. contrast stretch) Message-ID: <20070112160441.8343C1005C5@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5432 ------------------------------------------------------------------------- Subject: gis.m: display option (e.g. contrast stretch) grass obtained from: Trento Italy site grass binary for platform: Compiled from Sources Hello, a checkbox with various options beside the "base raster map to display" button in gis.m would be great to control the raster display in the monitor like a log transform, contrast stretch, histogram equalised etc. Without creating a new image - just the display is changed not the actual image. regards, Martin -------------------------------------------- Managed by Request Tracker From michael.barton at asu.edu Fri Jan 12 17:20:43 2007 From: michael.barton at asu.edu (Michael Barton) Date: Fri Jan 12 17:21:04 2007 Subject: [GRASS-dev] georectifier - zooming and rectifying In-Reply-To: <20070111093841.GA15287@localdomain> Message-ID: Thanks for the information Jachym On 1/11/07 2:38 AM, "Jachym Cepicky" wrote: > Hello, > > while I was working with latest georectifier, I came to following > issues: > > When I set couple of GCPs and zoom in/out, the GPCs are displayd > always "one zoom step too late". It looks like they would use zoom > scale from window/previous_zoom. This should be fixable, though I don't quite understand what you are describing. > > Second thing: > When I click on the "Rectify maps in the group" button, every window > in the gis manager becomes inactive. Strange thing is, that > processor does not work really hard (i.rectify is running with about > 20-50 % load) and the whole process takes too long. > > When I run i.rectify from CLI, it takes only couple of minutes and > the processor is really heated up. > > It is a bit confusing, just to sit in front of inactive gis manager > and to see, that the computer is not really working and wonder, what > is happening. This is baffling since all the georectifier does is run i.rectify for rasters and v.transform for vectors. Then it copies the created maps into the current location/mapset. The holdup might be in the latter step, but I can't say at the moment. Maybe something I can look at over the weekend. Michael > > I do not know, if we can do something with this issue - I beleave, > it is something between Tcl and OS. I just ask, if it would be > possible. Maybe small information window before calculation start, > that "This could take couple of minutes", forking the "i.rectify > process" to background, so that rest of the gis.m would be usable or > something like this could help to keep the user informed. > > Thanks > > Jachym > __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From tutey at o2.pl Fri Jan 12 17:41:04 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Fri Jan 12 17:41:08 2007 Subject: [GRASS-dev] georectifier - zooming and rectifying In-Reply-To: <20070111093841.GA15287@localdomain> References: <20070111093841.GA15287@localdomain> Message-ID: <45A7BA20.7070209@o2.pl> Jachym Cepicky wrote: > Second thing: > When I click on the "Rectify maps in the group" button, every window > in the gis manager becomes inactive. Strange thing is, that > processor does not work really hard (i.rectify is running with about > 20-50 % load) and the whole process takes too long. > > When I run i.rectify from CLI, it takes only couple of minutes and > the processor is really heated up. > > It is a bit confusing, just to sit in front of inactive gis manager > and to see, that the computer is not really working and wonder, what > is happening. > > I do not know, if we can do something with this issue - I beleave, > it is something between Tcl and OS. I just ask, if it would be > possible. I'm not sure if this is the same issue, but I have noticed that few hundred lines of output are able to freeze TCL/TK window of eg. r.stats, v.hull, nviz. See a bug report: http://intevation.de/rt/webrt?serial_num=4487 Maciek From grass-bugs at intevation.de Sat Jan 13 11:02:27 2007 From: grass-bugs at intevation.de (Request Tracker) Date: Sat Jan 13 11:02:38 2007 Subject: [GRASS-dev] [bug #5433] (grass) grass bug Message-ID: <20070113100227.889A71005AF@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5433 ------------------------------------------------------------------------- Subject: grass bug Platform: WindowsNT/2000/XP grass obtained from: Mirror of Trento site grass binary for platform: Compiled from Sources GRASS Version: 6.3 Please enter your name and error description here. Don't write general statements such as "this could be better" - please explain in details how a certain problem can be solved or a feature be added/improved. Send different report for different problems. Thanks! -------------------------------------------- Managed by Request Tracker From landa.martin at gmail.com Sat Jan 13 11:29:28 2007 From: landa.martin at gmail.com (Martin Landa) Date: Sat Jan 13 11:29:31 2007 Subject: [GRASS-dev] g.list -a In-Reply-To: <17831.30775.97473.434440@cerise.gclements.plus.com> References: <17823.11054.35596.752944@cerise.gclements.plus.com> <17824.53630.559151.84699@cerise.gclements.plus.com> <17826.26485.477846.188869@cerise.gclements.plus.com> <17827.31115.58158.918005@cerise.gclements.plus.com> <17831.30775.97473.434440@cerise.gclements.plus.com> Message-ID: Hi Glynn, 2007/1/12, Glynn Clements : [snip] > + if (G_parser(argc, argv)) > + { > + fprintf (stderr, _("\nWhere %s is one of:\n"), element->key); > + show_elements(); > + exit(EXIT_FAILURE); > + } > > If G_parser() fails, the program should just call exit(EXIT_FAILURE); > G_parser() will print an error message detailing why it failed. Yes, but the function show_elements() provides the user additional information why it failed. Would you like to remove it (maybe I have missed something)? Where type is one of: rast (raster files) rast3d (raster3D files) vect (binary vector files) oldvect (old (GRASS 5.0) binary vector files) asciivect (ascii vector files) icon (paint icon files) labels (paint label files) sites (site list files) region (region definition files) region3d (region3D definition files) group (imagery group files) 3dview (3D view parameters) > > > lib/do_list.c doesn't need to change; just have cmd/list.c call > > > do_list() once for each type. > > > > I think that fn do_list() have to be rewritten because of the -f flags > > (calling of execl() fn) ? > > No; do_list() can remain untouched, while the handling of -f should > remain essentially the same, except that it should use G_spawn() > instead of execl(). Ops, you are right. Maybe I need study GRASS API more deeply:-) Thanks for pointing to the G_spawn! Now it works. Regards, Martin -- Martin Landa * http://gama.fsv.cvut.cz/~landa * -------------- next part -------------- A non-text attachment was scrubbed... Name: g_list_all-6.diff.gz Type: application/x-gzip Size: 2161 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070113/a1ea0171/g_list_all-6.diff.gz From glynn at gclements.plus.com Sat Jan 13 18:57:03 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Jan 13 18:57:10 2007 Subject: [GRASS-dev] g.list -a In-Reply-To: References: <17823.11054.35596.752944@cerise.gclements.plus.com> <17824.53630.559151.84699@cerise.gclements.plus.com> <17826.26485.477846.188869@cerise.gclements.plus.com> <17827.31115.58158.918005@cerise.gclements.plus.com> <17831.30775.97473.434440@cerise.gclements.plus.com> Message-ID: <17833.7535.261073.724875@cerise.gclements.plus.com> Martin Landa wrote: > > + if (G_parser(argc, argv)) > > + { > > + fprintf (stderr, _("\nWhere %s is one of:\n"), element->key); > > + show_elements(); > > + exit(EXIT_FAILURE); > > + } > > > > If G_parser() fails, the program should just call exit(EXIT_FAILURE); > > G_parser() will print an error message detailing why it failed. > > Yes, but the function show_elements() provides the user additional > information why it failed. Would you like to remove it (maybe I have > missed something)? > > Where type is one of: > rast (raster files) > rast3d (raster3D files) > vect (binary vector files) > oldvect (old (GRASS 5.0) binary vector files) > asciivect (ascii vector files) > icon (paint icon files) > labels (paint label files) > sites (site list files) > region (region definition files) > region3d (region3D definition files) > group (imagery group files) > 3dview (3D view parameters) The built-in error handling will display the following message: Error: value out of range for parameter Legal range: rast,rast3d,vect,oldvect,asciivect,icon,labels,sites,region,region3d,group,3dview IMHO, this is sufficient. Note that the type descriptions *aren't* shown if you use "g.list help", only if there is a parsing error (which isn't limited to an invalid value for the type= option). OTOH, I'm not really that bothered about this issue; assuming that it compiles okay, I'll commit your latest version. > > > > lib/do_list.c doesn't need to change; just have cmd/list.c call > > > > do_list() once for each type. > > > > > > I think that fn do_list() have to be rewritten because of the -f flags > > > (calling of execl() fn) ? > > > > No; do_list() can remain untouched, while the handling of -f should > > remain essentially the same, except that it should use G_spawn() > > instead of execl(). > > Ops, you are right. Maybe I need study GRASS API more deeply:-) Thanks > for pointing to the G_spawn! Now it works. FWIW, I've added a native Windows version of G_spawn(), although I haven't had chance to test it yet. -- Glynn Clements From landa.martin at gmail.com Sat Jan 13 20:15:40 2007 From: landa.martin at gmail.com (Martin Landa) Date: Sat Jan 13 20:15:46 2007 Subject: [GRASS-dev] g.list -a In-Reply-To: <17833.7535.261073.724875@cerise.gclements.plus.com> References: <17824.53630.559151.84699@cerise.gclements.plus.com> <17826.26485.477846.188869@cerise.gclements.plus.com> <17827.31115.58158.918005@cerise.gclements.plus.com> <17831.30775.97473.434440@cerise.gclements.plus.com> <17833.7535.261073.724875@cerise.gclements.plus.com> Message-ID: Glynn, I committed changes to CVS. Once more thanks a lot for the help and valuable feedback. Martin 2007/1/13, Glynn Clements : > > Martin Landa wrote: > > > > + if (G_parser(argc, argv)) > > > + { > > > + fprintf (stderr, _("\nWhere %s is one of:\n"), element->key); > > > + show_elements(); > > > + exit(EXIT_FAILURE); > > > + } > > > > > > If G_parser() fails, the program should just call exit(EXIT_FAILURE); > > > G_parser() will print an error message detailing why it failed. > > > > Yes, but the function show_elements() provides the user additional > > information why it failed. Would you like to remove it (maybe I have > > missed something)? > > > > Where type is one of: > > rast (raster files) > > rast3d (raster3D files) > > vect (binary vector files) > > oldvect (old (GRASS 5.0) binary vector files) > > asciivect (ascii vector files) > > icon (paint icon files) > > labels (paint label files) > > sites (site list files) > > region (region definition files) > > region3d (region3D definition files) > > group (imagery group files) > > 3dview (3D view parameters) > > The built-in error handling will display the following message: > > Error: value out of range for parameter > Legal range: rast,rast3d,vect,oldvect,asciivect,icon,labels,sites,region,region3d,group,3dview > > IMHO, this is sufficient. Note that the type descriptions *aren't* > shown if you use "g.list help", only if there is a parsing error > (which isn't limited to an invalid value for the type= option). > > OTOH, I'm not really that bothered about this issue; assuming that it > compiles okay, I'll commit your latest version. > > > > > > lib/do_list.c doesn't need to change; just have cmd/list.c call > > > > > do_list() once for each type. > > > > > > > > I think that fn do_list() have to be rewritten because of the -f flags > > > > (calling of execl() fn) ? > > > > > > No; do_list() can remain untouched, while the handling of -f should > > > remain essentially the same, except that it should use G_spawn() > > > instead of execl(). > > > > Ops, you are right. Maybe I need study GRASS API more deeply:-) Thanks > > for pointing to the G_spawn! Now it works. > > FWIW, I've added a native Windows version of G_spawn(), although I > haven't had chance to test it yet. > > -- > Glynn Clements > -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From landa.martin at gmail.com Sat Jan 13 22:02:34 2007 From: landa.martin at gmail.com (Martin Landa) Date: Sat Jan 13 22:02:37 2007 Subject: [GRASS-dev] ps.map fprintf -> G_ In-Reply-To: <45A615CB.9080802@club.worldonline.be> References: <20070103165026.GB6831@localdomain> <20070107081813.GC10502@localdomain> <45A23936.4080200@club.worldonline.be> <45A615CB.9080802@club.worldonline.be> Message-ID: Hi, 2007/1/11, Moritz Lennert : [snip] > I don't no about the different levels, but I think Hamish' main message > was that you should not break existing scripts by removing the verbose > command within ps.map. OK, now fixed in CVS. Verbose mapping instruction can overwrite the GRASS_VERBOSE environment variable. Regards, Martin -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From michael.barton at asu.edu Sat Jan 13 23:16:30 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sat Jan 13 23:16:47 2007 Subject: [GRASS-dev] [bug #5432] (grass) gis.m: display option (e.g. contrast stretch) In-Reply-To: <20070112160441.8343C1005C5@lists.intevation.de> Message-ID: The GUI is built using existing GRASS commands. The raster display panel uses d.rast and d.his to produce the display options. There is no option in d.rast (or d.his) to control the display in the monitor like you are suggesting (though this could be nice). The only way I can think of to do what you request is to wrap in r.colors into the display panel. However, this would change the color table for the map. That is, this would be the new default color table until you select a new color table. A button to launch r.colors might be handy, though it's pretty accessible from the menu too. Michael On 1/12/07 9:04 AM, "Request Tracker" wrote: > this bug's URL: http://intevation.de/rt/webrt?serial_num=5432 > ------------------------------------------------------------------------- > > Subject: gis.m: display option (e.g. contrast stretch) > > grass obtained from: Trento Italy site > grass binary for platform: Compiled from Sources > > Hello, > > a checkbox with various options beside the "base raster map to display" > button in gis.m would be great to control the raster display in the monitor > like a log transform, contrast stretch, histogram equalised etc. > Without creating a new image - just the display is changed not the actual > image. > > regards, Martin > > > > -------------------------------------------- Managed by Request Tracker > > __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From glynn at gclements.plus.com Mon Jan 15 02:31:58 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Jan 15 02:32:08 2007 Subject: [GRASS-dev] g.list -a In-Reply-To: References: <17824.53630.559151.84699@cerise.gclements.plus.com> <17826.26485.477846.188869@cerise.gclements.plus.com> <17827.31115.58158.918005@cerise.gclements.plus.com> <17831.30775.97473.434440@cerise.gclements.plus.com> <17833.7535.261073.724875@cerise.gclements.plus.com> Message-ID: <17834.55694.188332.613967@cerise.gclements.plus.com> Martin Landa wrote: > I committed changes to CVS. I've changed it to use G_spawn() rather than G_spawn_ex(), as it doesn't need any of the advanced features provided by the latter, and the former has a native Windows implementation. Also, I've changed G_spawn[_ex] so that the argument list starts with argv[0] rather than argv[1], for compatibility with execl() and _spawnl(), and fixed a bug in G_spawn() (the terminating NULL pointer wasn't being added to the array). -- Glynn Clements From paul-grass at stjohnspoint.co.uk Mon Jan 15 11:40:04 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Mon Jan 15 11:40:27 2007 Subject: [GRASS-dev] Re: [Qgis-developer] Windows native GRASS build In-Reply-To: <340505ef0701010447s39a3912fy439fbb8274fba804@mail.gmail.com> References: <340505ef0701010447s39a3912fy439fbb8274fba804@mail.gmail.com> Message-ID: On Mon, 1 Jan 2007, Radim Blazek wrote: > On 1/1/07, Tim Sutton wrote: >> Happy new year all! >> >> For those of you following the GRASS on windows efforts with QGIS, I >> have now got GRASS building with all but about 20 modules under >> msys/windows. I havent compiled in postgresql support yet.. GRASS >> attribute viewing and man page viewing are now working under windows >> qgis for me. There are two small issues remaining that I noticed (and >> maybe more that others will notice): >> >> 1) Every time a layer is added a black console box temporarily appears >> and then disappears. > > It is known problem, db driver is exe and when it is started by spawnl() > it opens Windows console for a while. I am not Win expert and I dont know > how to avoid this. I have asked already in QGIS and GRASS devel lists. Just wondering, if the newly improved G_spawn() might be a possible tidier solution for this? Not sure and not really able to test patches here yet as my Windows build is still having the db driver communication problem described by Moritz in earlier e-mails. Must get round to trying it with a different database. Just wanted to put it on the list anyway. Sorry can't take the idea any further right now, but the relevant file is lib/db/dbmi_client/start.c Paul From tutey at o2.pl Mon Jan 15 22:55:49 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Mon Jan 15 22:55:59 2007 Subject: [GRASS-dev] GRASS at GForge first steps - second encounter Message-ID: <45ABF865.4010604@o2.pl> Hi, In the past few weeks as time allowed I finished setting up the trackers at GForge. Before they are announced for users, I'm kindly asking developers to have a look at what was done and let me know if there is something that still needs a change or fix. Under the GRASS GForge project [4] there are 9 trackers now: - code feature requests - code issues - code patches - doc feature requests - doc issues - doc patches - website feature requests - website issues - website patches Issues tracker is for bugs, and "bad features", aka "defects". Feature reqests for wishes. Patches are for user submitted patches, if the user doesn't have CVS write access but wants to share his fix. They will also be used for patches which shouldn't go into CVS (yet), but we want to keep the track of them for later. When there is a an issue reported and nobody picks it up right away, I'm going to be the first contact person - ie. gather more info until it is a good material for a developer to work on; I'll also prune duplicate reports, close obvious wrong ones, etc. I can also fix some minor stuff like docs, shell scripts etc. When patch is submitted to a patches tracker, and nobody steps up to take care of the patch, there are first-contacts also, who will do a similar job here: Jachym Chepicky - code patches. Scott Mitchell - website patches. Martin Landa - doc patches. As I don't have any programming skills, and my insight into GRASS website is poor, code and website experts are inevitable to evalute the submitted patches. For docs patches I'll try to help Martin as I can. Many thanks Guys! Trackers are available for public view, but in order to be able to post (including creating a new report), you must setup your account at GForge first [3]. This is to avoid http spam. All trackers' new submitions will be automatically forwarded to grass-dev list. All the following traffic will be stored in the tracker and forwarded only to folks discussing the ticket. However, anybody can "monitor" (see GForge manual [6]) any ticket, or a whole tracker, to be forwaded all the related traffic. If you want to be able to modify the contents of trackers, you should request to join the GRASS project at GForge as "developer" [5]. GForge provides many functionalities. AFAIK, it was aggreed that we are currently going to use only the trackers, as all the other functionalities are implemented in the current GRASS infrastructure (besides surveys; there might be some use for them - let's keep them in mind :) ). Although there are various project member "roles" possible to define, IMHO we should only use 3: admin, developer and user: 1. "Admin" is in charge of managing requests to join the project and configuring the GRASS project at GForge. Currently there are 2 admins: I and Bernard Reiter. We could use another backup in case we are both away. Anybody? 2. "Developer" can do most of the things that admin can. Only that he doesn't have his duties and he can't remove the whole project. But he still can add/modify/delete trackers as well as delete tickets for good. It was neccessary to provide that much power to "developers" so that they could move tickets between the trackers. "Developers" - please use your power wisely and drop me a line before doing something more intrusive :). 3. "User". He can open new tickets in the trackers, reply to other tickets and "monitor", participate in surveys ("admin" and "developer" can too, of course). GForge manuals are here: [6]. [1]http://wald.intevation.org/tracker/?atid=182&group_id=21&func=browse [2]http://wald.intevation.org/tracker/?atid=183&group_id=21&func=browse [3]http://wald.intevation.org/account/register.php [4]http://wald.intevation.org/projects/grass/ [5]http://wald.intevation.org/project/request.php?group_id=21 [6]http://gforge.org/docman/index.php?group_id=1&selected_doc_group_id=5&language_id=1 Maciek From epatton at nrcan.gc.ca Tue Jan 16 17:11:46 2007 From: epatton at nrcan.gc.ca (Patton, Eric) Date: Tue Jan 16 17:11:50 2007 Subject: [GRASS-dev] GRASS at GForge first steps - second encounter In-Reply-To: <45ABF865.4010604@o2.pl> References: <45ABF865.4010604@o2.pl> Message-ID: Maciek, Thanks for your hard work in taking the lead on this - much appreciated. I'll login and have a look and get back to you with comments. Cheers, -- Eric Patton email: epatton@nrcan.gc.ca > -----Original Message----- > From: grass-dev-bounces@grass.itc.it > [mailto:grass-dev-bounces@grass.itc.it] On Behalf Of Maciej Sieczka > Sent: Monday, January 15, 2007 5:56 PM > To: grass-dev > Subject: [GRASS-dev] GRASS at GForge first steps - second encounter > > Hi, > > In the past few weeks as time allowed I finished setting up > the trackers at GForge. > > Before they are announced for users, I'm kindly asking > developers to have a look at what was done and let me know if > there is something that still needs a change or fix. From tutey at o2.pl Tue Jan 16 19:03:15 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Tue Jan 16 19:03:23 2007 Subject: [GRASS-dev] new r.out.gdal fails to preserve 8bit color In-Reply-To: <458C0E4B.9080101@o2.pl> References: <458C0E4B.9080101@o2.pl> Message-ID: <45AD1363.7060307@o2.pl> Maciej Sieczka wrote: > Vytautas, > > Exporting a CELL GRASS raster, value range 0-255, r.out.gdal issues an: > > ERROR 6: SetColorInterpretation() not supported for this dataset. > > and the output map is greyscale. There is a discussion about this defect on the GDAL dev list: http://www.nabble.com/r.out.gdal%3A-SetColorInterpretation%28%29-not-supported-tf3021127.html Maciek From neteler at itc.it Tue Jan 16 21:53:41 2007 From: neteler at itc.it (Markus Neteler) Date: Tue Jan 16 21:53:43 2007 Subject: [GRASS-dev] new r.out.gdal fails to preserve 8bit color In-Reply-To: <45AD1363.7060307@o2.pl> References: <458C0E4B.9080101@o2.pl> <45AD1363.7060307@o2.pl> Message-ID: <20070116205341.GA17578@bartok.itc.it> On Tue, Jan 16, 2007 at 07:03:15PM +0100, Maciej Sieczka wrote: > Maciej Sieczka wrote: > > Vytautas, > > > > Exporting a CELL GRASS raster, value range 0-255, r.out.gdal issues an: > > > > ERROR 6: SetColorInterpretation() not supported for this dataset. > > > > and the output map is greyscale. > > There is a discussion about this defect on the GDAL dev list: > http://www.nabble.com/r.out.gdal%3A-SetColorInterpretation%28%29-not-supported-tf3021127.html > Probably the mapgdal.c file of MapServer could be an inspiration? Markus From neteler at itc.it Tue Jan 16 22:14:17 2007 From: neteler at itc.it (Markus Neteler) Date: Tue Jan 16 22:14:18 2007 Subject: [GRASS-dev] new r.out.gdal fails to preserve 8bit color In-Reply-To: <20070116205341.GA17578@bartok.itc.it> References: <458C0E4B.9080101@o2.pl> <45AD1363.7060307@o2.pl> <20070116205341.GA17578@bartok.itc.it> Message-ID: <20070116211416.GE17578@bartok.itc.it> On Tue, Jan 16, 2007 at 09:53:41PM +0100, Markus Neteler wrote: > On Tue, Jan 16, 2007 at 07:03:15PM +0100, Maciej Sieczka wrote: > > Maciej Sieczka wrote: > > > Vytautas, > > > > > > Exporting a CELL GRASS raster, value range 0-255, r.out.gdal issues an: > > > > > > ERROR 6: SetColorInterpretation() not supported for this dataset. > > > > > > and the output map is greyscale. > > > > There is a discussion about this defect on the GDAL dev list: > > http://www.nabble.com/r.out.gdal%3A-SetColorInterpretation%28%29-not-supported-tf3021127.html > > > > Probably the mapgdal.c file of MapServer could be an inspiration? I found some more: http://www.nabble.com/Re:-How-to-set-a-ColorTable-from-scratch--p5000321.html http://www.archivesat.com/FreeGIS_project/thread1933209.htm and GDAL apps/gdalwarpsimple.c Still lost :-) Markus From mlennert at club.worldonline.be Wed Jan 17 09:23:25 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Wed Jan 17 09:22:01 2007 Subject: [GRASS-dev] new r.out.gdal fails to preserve 8bit color In-Reply-To: <20070116211416.GE17578@bartok.itc.it> References: <458C0E4B.9080101@o2.pl> <45AD1363.7060307@o2.pl> <20070116205341.GA17578@bartok.itc.it> <20070116211416.GE17578@bartok.itc.it> Message-ID: <45ADDCFD.3030302@club.worldonline.be> On 16/01/07 22:14, Markus Neteler wrote: > On Tue, Jan 16, 2007 at 09:53:41PM +0100, Markus Neteler wrote: >> On Tue, Jan 16, 2007 at 07:03:15PM +0100, Maciej Sieczka wrote: >>> Maciej Sieczka wrote: >>>> Vytautas, >>>> >>>> Exporting a CELL GRASS raster, value range 0-255, r.out.gdal issues an: >>>> >>>> ERROR 6: SetColorInterpretation() not supported for this dataset. >>>> >>>> and the output map is greyscale. >>> There is a discussion about this defect on the GDAL dev list: >>> http://www.nabble.com/r.out.gdal%3A-SetColorInterpretation%28%29-not-supported-tf3021127.html >>> >> Probably the mapgdal.c file of MapServer could be an inspiration? > > I found some more: > > http://www.nabble.com/Re:-How-to-set-a-ColorTable-from-scratch--p5000321.html > http://www.archivesat.com/FreeGIS_project/thread1933209.htm > > and GDAL > apps/gdalwarpsimple.c > > Still lost :-) In the very first thread, Frank says: "Generally speaking to produce a GeoTIFF file with a color table after using Create() to create it, you need to do the SetColorTable() *before* writing any raster data." I don't see any call to SetColorTable in main.c of r.out.gdal. Could this be the problem ? Moritz From neteler at itc.it Wed Jan 17 10:04:35 2007 From: neteler at itc.it (Markus Neteler) Date: Wed Jan 17 10:04:45 2007 Subject: [GRASS-dev] new r.out.gdal fails to preserve 8bit color In-Reply-To: <45ADDCFD.3030302@club.worldonline.be> References: <458C0E4B.9080101@o2.pl> <45AD1363.7060307@o2.pl> <20070116205341.GA17578@bartok.itc.it> <20070116211416.GE17578@bartok.itc.it> <45ADDCFD.3030302@club.worldonline.be> Message-ID: <45ADE6A3.1090604@itc.it> Moritz Lennert wrote on 01/17/2007 09:23 AM: > On 16/01/07 22:14, Markus Neteler wrote: >> On Tue, Jan 16, 2007 at 09:53:41PM +0100, Markus Neteler wrote: >>> On Tue, Jan 16, 2007 at 07:03:15PM +0100, Maciej Sieczka wrote: >>>> Maciej Sieczka wrote: >>>>> Vytautas, >>>>> >>>>> Exporting a CELL GRASS raster, value range 0-255, r.out.gdal >>>>> issues an: >>>>> >>>>> ERROR 6: SetColorInterpretation() not supported for this dataset. >>>>> >>>>> and the output map is greyscale. >>>> There is a discussion about this defect on the GDAL dev list: >>>> http://www.nabble.com/r.out.gdal%3A-SetColorInterpretation%28%29-not-supported-tf3021127.html >>>> >>>> >>> Probably the mapgdal.c file of MapServer could be an inspiration? >> >> I found some more: >> >> http://www.nabble.com/Re:-How-to-set-a-ColorTable-from-scratch--p5000321.html >> >> http://www.archivesat.com/FreeGIS_project/thread1933209.htm >> >> and GDAL >> apps/gdalwarpsimple.c >> >> Still lost :-) > > > In the very first thread, Frank says: > > "Generally speaking to produce a GeoTIFF file with a color table after > using Create() to create it, you need to do the SetColorTable() > *before* writing any raster data." > > I don't see any call to SetColorTable in main.c of r.out.gdal. Could > this be the problem ? Yes. Right now I have submitted related code based on the GRASS-GDAL plugin. It now creates color rules, but the color interpretation is still wrong (gray instead of RGB). Please someone may revisit it. Markus From Roger.Bivand at nhh.no Wed Jan 17 10:12:37 2007 From: Roger.Bivand at nhh.no (Roger Bivand) Date: Wed Jan 17 10:12:46 2007 Subject: [GRASS-dev] new r.out.gdal fails to preserve 8bit color In-Reply-To: <45ADDCFD.3030302@club.worldonline.be> Message-ID: On Wed, 17 Jan 2007, Moritz Lennert wrote: > On 16/01/07 22:14, Markus Neteler wrote: > > On Tue, Jan 16, 2007 at 09:53:41PM +0100, Markus Neteler wrote: > >> On Tue, Jan 16, 2007 at 07:03:15PM +0100, Maciej Sieczka wrote: > >>> Maciej Sieczka wrote: > >>>> Vytautas, > >>>> > >>>> Exporting a CELL GRASS raster, value range 0-255, r.out.gdal issues an: > >>>> > >>>> ERROR 6: SetColorInterpretation() not supported for this dataset. > >>>> > >>>> and the output map is greyscale. > >>> There is a discussion about this defect on the GDAL dev list: > >>> http://www.nabble.com/r.out.gdal%3A-SetColorInterpretation%28%29-not-supported-tf3021127.html > >>> > >> Probably the mapgdal.c file of MapServer could be an inspiration? > > > > I found some more: > > > > http://www.nabble.com/Re:-How-to-set-a-ColorTable-from-scratch--p5000321.html > > http://www.archivesat.com/FreeGIS_project/thread1933209.htm > > > > and GDAL > > apps/gdalwarpsimple.c > > > > Still lost :-) > > > In the very first thread, Frank says: > > "Generally speaking to produce a GeoTIFF file with a color table after > using Create() to create it, you need to do the SetColorTable() *before* > writing any raster data." > > I don't see any call to SetColorTable in main.c of r.out.gdal. Could > this be the problem ? In the R rgdal package, we use R code to generate three byte RGB bands, then make a PCT from those. I'm not sure where on the GDAL site one can find a direct route to go from an external palette to filling the PCT, although it looks as though it is made up of nc colours each of four RGBA bytes (not tried). R function RGB2PCT and help pages show some ideas, C++ code in function RGDAL_GenCMap in src/gdal-bindings.cpp. Roger > > Moritz > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > -- Roger Bivand Economic Geography Section, Department of Economics, Norwegian School of Economics and Business Administration, Helleveien 30, N-5045 Bergen, Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43 e-mail: Roger.Bivand@nhh.no From neteler at itc.it Wed Jan 17 10:21:04 2007 From: neteler at itc.it (Markus Neteler) Date: Wed Jan 17 10:21:08 2007 Subject: [GRASS-dev] new r.out.gdal fails to preserve 8bit color In-Reply-To: <45ADE6A3.1090604@itc.it> References: <458C0E4B.9080101@o2.pl> <45AD1363.7060307@o2.pl> <20070116205341.GA17578@bartok.itc.it> <20070116211416.GE17578@bartok.itc.it> <45ADDCFD.3030302@club.worldonline.be> <45ADE6A3.1090604@itc.it> Message-ID: <45ADEA80.2040307@itc.it> Markus Neteler wrote on 01/17/2007 10:04 AM: > Moritz Lennert wrote on 01/17/2007 09:23 AM: >> On 16/01/07 22:14, Markus Neteler wrote: >>> On Tue, Jan 16, 2007 at 09:53:41PM +0100, Markus Neteler wrote: >>>> On Tue, Jan 16, 2007 at 07:03:15PM +0100, Maciej Sieczka wrote: >>>>> Maciej Sieczka wrote: >>>>>> Vytautas, >>>>>> >>>>>> Exporting a CELL GRASS raster, value range 0-255, r.out.gdal >>>>>> issues an: >>>>>> >>>>>> ERROR 6: SetColorInterpretation() not supported for this dataset. >>>>>> >>>>>> and the output map is greyscale. >>>>> There is a discussion about this defect on the GDAL dev list: >>>>> http://www.nabble.com/r.out.gdal%3A-SetColorInterpretation%28%29-not-supported-tf3021127.html >>>>> >>>>> >>>> Probably the mapgdal.c file of MapServer could be an inspiration? >>> >>> I found some more: >>> >>> http://www.nabble.com/Re:-How-to-set-a-ColorTable-from-scratch--p5000321.html >>> >>> http://www.archivesat.com/FreeGIS_project/thread1933209.htm >>> >>> and GDAL >>> apps/gdalwarpsimple.c >>> >>> Still lost :-) >> >> >> In the very first thread, Frank says: >> >> "Generally speaking to produce a GeoTIFF file with a color table >> after using Create() to create it, you need to do the SetColorTable() >> *before* writing any raster data." >> >> I don't see any call to SetColorTable in main.c of r.out.gdal. Could >> this be the problem ? > > Yes. > Right now I have submitted related code based on the GRASS-GDAL plugin. > It now creates color rules, but the color interpretation is still > wrong (gray instead of RGB). > > Please someone may revisit it. It appears that G_get_f_color_rule() doesn't return what it should. No clue how to fix it. Markus From neteler at itc.it Wed Jan 17 15:03:03 2007 From: neteler at itc.it (Markus Neteler) Date: Wed Jan 17 15:03:04 2007 Subject: [GRASS-dev] g.region: multiple vector maps support added Message-ID: <20070117140302.GD12716@bartok.itc.it> Hi, I have added multiple maps support for vect= parameter in g.region in CVS. Now you can set the current region also from several vector maps (for raster it was already there): g.region vect=ammprvBL g.region vect=ammprvBL,ammprv Cheers markus From warmerdam at pobox.com Wed Jan 17 17:24:49 2007 From: warmerdam at pobox.com (Frank Warmerdam) Date: Wed Jan 17 15:46:02 2007 Subject: [GRASS-dev] new r.out.gdal fails to preserve 8bit color In-Reply-To: <45ADDCFD.3030302@club.worldonline.be> References: <458C0E4B.9080101@o2.pl> <45AD1363.7060307@o2.pl> <20070116205341.GA17578@bartok.itc.it> <20070116211416.GE17578@bartok.itc.it> <45ADDCFD.3030302@club.worldonline.be> Message-ID: <45AE4DD1.5010606@pobox.com> Moritz Lennert wrote: > In the very first thread, Frank says: > > "Generally speaking to produce a GeoTIFF file with a color table after > using Create() to create it, you need to do the SetColorTable() *before* > writing any raster data." > > I don't see any call to SetColorTable in main.c of r.out.gdal. Could > this be the problem ? Moritz, Yes, I would imagine so! Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | President OSGeo, http://osgeo.org From grass-bugs at intevation.de Wed Jan 17 16:28:01 2007 From: grass-bugs at intevation.de (Request Tracker) Date: Wed Jan 17 16:28:03 2007 Subject: [GRASS-dev] [bug #5440] (grass) Message-ID: <20070117152801.EF5711006B4@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5440 ------------------------------------------------------------------------- Subject: -------------------------------------------- Managed by Request Tracker From tutey at o2.pl Wed Jan 17 16:36:37 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Wed Jan 17 16:37:00 2007 Subject: [GRASS-dev] g.region: multiple vector maps support added In-Reply-To: <20070117140302.GD12716@bartok.itc.it> References: <20070117140302.GD12716@bartok.itc.it> Message-ID: <45AE4285.2010301@o2.pl> Markus Neteler wrote: > I have added multiple maps support for vect= parameter > in g.region in CVS. Now you can set the current region > also from several vector maps (for raster it was already > there): > > g.region vect=ammprvBL > g.region vect=ammprvBL,ammprv That's a cool new feature. I've been missing it. Thanks much! Maciek From neteler at itc.it Wed Jan 17 16:39:56 2007 From: neteler at itc.it (Markus Neteler) Date: Wed Jan 17 16:39:59 2007 Subject: [GRASS-dev] Re: [Gdal-dev] GDAL/OGR 1.4.0 Released In-Reply-To: <45AE4206.3060605@o2.pl> References: <459FE60D.1070001@pobox.com> <45A9FEAC.9090305@o2.pl> <20070114193921.GB24022@bartok.itc.it> <45AA96D6.5020909@o2.pl> <20070116135215.GI6232@bartok.itc.it> <45AD10AA.6020808@o2.pl> <20070116205432.GB17578@bartok.itc.it> <45AE4206.3060605@o2.pl> Message-ID: <20070117153956.GB22844@bartok.itc.it> OK. configure:2939: checking for G_asprintf in -lgrass_gis configure:2969: gcc -o conftest -O2 conftest.c -lgrass_gis -L/usr/local/grass-6.3.cvs/lib -lgrass_I -lgrass_vask -lgrass_gmath -lgrass_gis -lgrass_datetime -lgrass_gproj -lgrass_vect -lgrass_dbmibase -lgrass_dbmiclient -lgrass_dgl -lgrass_dig2 -lgrass_rtree -lgrass_linkm -L/usr/local/lib -lgdal >&5 /usr/local/lib/libgeos_c.so.1: undefined reference to `geos::WKBReader::read(std::basic_istream >&)' /usr/local/lib/libgeos_c.so.1: undefined reference to `geos::WKBWriter::write(geos::Geometry const&, std::basic_ostream >&)' /usr/local/lib/libgeos_c.so.1: undefined reference to `geos::Point::getCoordinatesRO() const' /usr/local/lib/libgeos_c.so.1: undefined reference to `geos::WKBWriter::WKBWriter(int, int)' collect2: ld returned 1 exit status What does ldd /usr/local/grass-6.3.cvs/lib/*6.3.cvs*.so say? I assume that geos slips in through libgdal. BTW: Mine points to libgeos.so.2 => /usr/local/lib/libgeos.so.2 (0x0000002a95c03000) libgeos_c.so.1 => /usr/local/lib/libgeos_c.so.1 (0x0000002a95e0f000) Is it possible that your GEOS is a bit old? Or that you have two GEOS libs in parallel? Just guessing, Markus On Wed, Jan 17, 2007 at 04:34:30PM +0100, Maciej Sieczka wrote: > Markus Neteler wrote: > > > Can you send the config.log file? > > Sure. It's already here: > > http://www.nabble.com/attachment/8115821/0/config.log.bz2 > > Paul already looked into it: > > http://www.nabble.com/gdal-grass-plugin-fails-during-.-configure-with-GRASS-6.3-CVS-tf2904798.html#a8115502 > > Maciek -- Markus Neteler http://mpa.itc.it/markus/ ITC-irst - Centro per la Ricerca Scientifica e Tecnologica MPBA - Predictive Models for Biol. & Environ. Data Analysis Via Sommarive, 18 - 38050 Povo (Trento), Italy From tutey at o2.pl Wed Jan 17 17:22:28 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Wed Jan 17 17:22:33 2007 Subject: [GRASS-dev] Re: [Gdal-dev] GDAL/OGR 1.4.0 Released In-Reply-To: <20070117153956.GB22844@bartok.itc.it> References: <459FE60D.1070001@pobox.com> <45A9FEAC.9090305@o2.pl> <20070114193921.GB24022@bartok.itc.it> <45AA96D6.5020909@o2.pl> <20070116135215.GI6232@bartok.itc.it> <45AD10AA.6020808@o2.pl> <20070116205432.GB17578@bartok.itc.it> <45AE4206.3060605@o2.pl> <20070117153956.GB22844@bartok.itc.it> Message-ID: <45AE4D44.20902@o2.pl> Markus Neteler wrote: > OK. > configure:2939: checking for G_asprintf in -lgrass_gis > configure:2969: gcc -o conftest -O2 conftest.c -lgrass_gis -L/usr/local/grass-6.3.cvs/lib -lgrass_I -lgrass_vask -lgrass_gmath -lgrass_gis -lgrass_datetime -lgrass_gproj -lgrass_vect -lgrass_dbmibase -lgrass_dbmiclient -lgrass_dgl -lgrass_dig2 -lgrass_rtree -lgrass_linkm -L/usr/local/lib -lgdal >&5 > /usr/local/lib/libgeos_c.so.1: undefined reference to `geos::WKBReader::read(std::basic_istream >&)' > /usr/local/lib/libgeos_c.so.1: undefined reference to `geos::WKBWriter::write(geos::Geometry const&, std::basic_ostream >&)' > /usr/local/lib/libgeos_c.so.1: undefined reference to `geos::Point::getCoordinatesRO() const' > /usr/local/lib/libgeos_c.so.1: undefined reference to `geos::WKBWriter::WKBWriter(int, int)' > collect2: ld returned 1 exit status > > What does > ldd /usr/local/grass-6.3.cvs/lib/*6.3.cvs*.so > say? See the attached ldd_grass.txt. > I assume that geos slips in through libgdal. BTW: Mine points to > libgeos.so.2 => /usr/local/lib/libgeos.so.2 (0x0000002a95c03000) > libgeos_c.so.1 => /usr/local/lib/libgeos_c.so.1 (0x0000002a95e0f000) > > Is it possible that your GEOS is a bit old? 2.2.3 - the latest stable. Do I have have to use GEOS 3 RC? GDAL 1.4 CVS 2007-01-14 didn't complain. Nothing relevant here: http://www.gdal.org/NEWS.html. > Or that you have two GEOS libs in parallel? Nope. Only one. Built myself. Installed into /usr/local. > Just guessing, Thanks, I hope this can be worked out somehow. Maciek -------------- next part -------------- /usr/local/grass-6.3.cvs/lib/libgrass_bitmap.6.3.cvs.so: linux-gate.so.1 => (0xffffe000) libgrass_linkm.so => /usr/local/grass-6.3.cvs/lib/libgrass_linkm.so (0xb7fad000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7e7e000) /lib/ld-linux.so.2 (0x80000000) /usr/local/grass-6.3.cvs/lib/libgrass_btree.6.3.cvs.so: linux-gate.so.1 => (0xffffe000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7e5e000) /lib/ld-linux.so.2 (0x80000000) /usr/local/grass-6.3.cvs/lib/libgrass_cdhc.6.3.cvs.so: linux-gate.so.1 => (0xffffe000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7e21000) /lib/ld-linux.so.2 (0x80000000) /usr/local/grass-6.3.cvs/lib/libgrass_D.6.3.cvs.so: linux-gate.so.1 => (0xffffe000) libgrass_gis.so => /usr/local/grass-6.3.cvs/lib/libgrass_gis.so (0xb7f05000) libgrass_datetime.so => /usr/local/grass-6.3.cvs/lib/libgrass_datetime.so (0xb7efd000) libz.so.1 => /usr/lib/libz.so.1 (0xb7ee9000) libgrass_raster.so => /usr/local/grass-6.3.cvs/lib/libgrass_raster.so (0xb7ede000) libgrass_pngdriver.so => /usr/local/grass-6.3.cvs/lib/libgrass_pngdriver.so (0xb7ed7000) libgrass_driver.so => /usr/local/grass-6.3.cvs/lib/libgrass_driver.so (0xb7eca000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb7e61000) libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb7e3e000) libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7e1c000) libgrass_display.so => /usr/local/grass-6.3.cvs/lib/libgrass_display.so (0xb7e11000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7ce2000) /lib/ld-linux.so.2 (0x80000000) /usr/local/grass-6.3.cvs/lib/libgrass_datetime.6.3.cvs.so: linux-gate.so.1 => (0xffffe000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7eb0000) /lib/ld-linux.so.2 (0x80000000) /usr/local/grass-6.3.cvs/lib/libgrass_dbmibase.6.3.cvs.so: linux-gate.so.1 => (0xffffe000) libgrass_gis.so => /usr/local/grass-6.3.cvs/lib/libgrass_gis.so (0xb7f8c000) libgrass_datetime.so => /usr/local/grass-6.3.cvs/lib/libgrass_datetime.so (0xb7f84000) libz.so.1 => /usr/lib/libz.so.1 (0xb7f70000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7e41000) /lib/ld-linux.so.2 (0x80000000) /usr/local/grass-6.3.cvs/lib/libgrass_dbmiclient.6.3.cvs.so: linux-gate.so.1 => (0xffffe000) libgrass_dbmibase.so => /usr/local/grass-6.3.cvs/lib/libgrass_dbmibase.so (0xb7f86000) libgrass_gis.so => /usr/local/grass-6.3.cvs/lib/libgrass_gis.so (0xb7f41000) libgrass_datetime.so => /usr/local/grass-6.3.cvs/lib/libgrass_datetime.so (0xb7f39000) libz.so.1 => /usr/lib/libz.so.1 (0xb7f25000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7df6000) /lib/ld-linux.so.2 (0x80000000) /usr/local/grass-6.3.cvs/lib/libgrass_dbmidriver.6.3.cvs.so: linux-gate.so.1 => (0xffffe000) libgrass_dbmibase.so => /usr/local/grass-6.3.cvs/lib/libgrass_dbmibase.so (0xb7ee9000) libgrass_gis.so => /usr/local/grass-6.3.cvs/lib/libgrass_gis.so (0xb7ea4000) libgrass_datetime.so => /usr/local/grass-6.3.cvs/lib/libgrass_datetime.so (0xb7e9c000) libz.so.1 => /usr/lib/libz.so.1 (0xb7e88000) libgrass_dbstubs.so => /usr/local/grass-6.3.cvs/lib/libgrass_dbstubs.so (0xb7e85000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7d55000) /lib/ld-linux.so.2 (0x80000000) /usr/local/grass-6.3.cvs/lib/libgrass_dbstubs.6.3.cvs.so: linux-gate.so.1 => (0xffffe000) libgrass_dbmibase.so => /usr/local/grass-6.3.cvs/lib/libgrass_dbmibase.so (0xb7f8e000) libgrass_gis.so => /usr/local/grass-6.3.cvs/lib/libgrass_gis.so (0xb7f49000) libgrass_datetime.so => /usr/local/grass-6.3.cvs/lib/libgrass_datetime.so (0xb7f41000) libz.so.1 => /usr/lib/libz.so.1 (0xb7f2d000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7dfe000) /lib/ld-linux.so.2 (0x80000000) /usr/local/grass-6.3.cvs/lib/libgrass_dgl.6.3.cvs.so: linux-gate.so.1 => (0xffffe000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7e06000) /lib/ld-linux.so.2 (0x80000000) /usr/local/grass-6.3.cvs/lib/libgrass_dig2.6.3.cvs.so: linux-gate.so.1 => (0xffffe000) libgrass_gis.so => /usr/local/grass-6.3.cvs/lib/libgrass_gis.so (0xb7f08000) libgrass_datetime.so => /usr/local/grass-6.3.cvs/lib/libgrass_datetime.so (0xb7f00000) libz.so.1 => /usr/lib/libz.so.1 (0xb7eec000) libgrass_rtree.so => /usr/local/grass-6.3.cvs/lib/libgrass_rtree.so (0xb7ee7000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7db8000) /lib/ld-linux.so.2 (0x80000000) /usr/local/grass-6.3.cvs/lib/libgrass_display.6.3.cvs.so: linux-gate.so.1 => (0xffffe000) libgrass_gis.so => /usr/local/grass-6.3.cvs/lib/libgrass_gis.so (0xb7f1c000) libgrass_datetime.so => /usr/local/grass-6.3.cvs/lib/libgrass_datetime.so (0xb7f14000) libz.so.1 => /usr/lib/libz.so.1 (0xb7f00000) libgrass_raster.so => /usr/local/grass-6.3.cvs/lib/libgrass_raster.so (0xb7ef5000) libgrass_pngdriver.so => /usr/local/grass-6.3.cvs/lib/libgrass_pngdriver.so (0xb7eee000) libgrass_driver.so => /usr/local/grass-6.3.cvs/lib/libgrass_driver.so (0xb7ee1000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb7e78000) libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb7e55000) libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7e33000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7d04000) /lib/ld-linux.so.2 (0x80000000) /usr/local/grass-6.3.cvs/lib/libgrass_driver.6.3.cvs.so: linux-gate.so.1 => (0xffffe000) libgrass_gis.so => /usr/local/grass-6.3.cvs/lib/libgrass_gis.so (0xb7ee0000) libgrass_datetime.so => /usr/local/grass-6.3.cvs/lib/libgrass_datetime.so (0xb7ed8000) libz.so.1 => /usr/lib/libz.so.1 (0xb7ec4000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb7e5b000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7d2c000) /lib/ld-linux.so.2 (0x80000000) /usr/local/grass-6.3.cvs/lib/libgrass_dspf.6.3.cvs.so: linux-gate.so.1 => (0xffffe000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7de2000) /lib/ld-linux.so.2 (0x80000000) /usr/local/grass-6.3.cvs/lib/libgrass_edit.6.3.cvs.so: linux-gate.so.1 => (0xffffe000) libgrass_gis.so => /usr/local/grass-6.3.cvs/lib/libgrass_gis.so (0xb7edf000) libgrass_datetime.so => /usr/local/grass-6.3.cvs/lib/libgrass_datetime.so (0xb7ed7000) libz.so.1 => /usr/lib/libz.so.1 (0xb7ec3000) libgrass_vask.so => /usr/local/grass-6.3.cvs/lib/libgrass_vask.so (0xb7ebd000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7d8e000) libncurses.so.5 => /lib/libncurses.so.5 (0xb7d4c000) /lib/ld-linux.so.2 (0x80000000) libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7d49000) /usr/local/grass-6.3.cvs/lib/libgrass_form.6.3.cvs.so: linux-gate.so.1 => (0xffffe000) libgrass_gis.so => /usr/local/grass-6.3.cvs/lib/libgrass_gis.so (0xb7ed1000) libgrass_datetime.so => /usr/local/grass-6.3.cvs/lib/libgrass_datetime.so (0xb7ec9000) libz.so.1 => /usr/lib/libz.so.1 (0xb7eb5000) libgrass_dbmiclient.so => /usr/local/grass-6.3.cvs/lib/libgrass_dbmiclient.so (0xb7eac000) libgrass_dbmibase.so => /usr/local/grass-6.3.cvs/lib/libgrass_dbmibase.so (0xb7e9f000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7d6f000) /lib/ld-linux.so.2 (0x80000000) /usr/local/grass-6.3.cvs/lib/libgrass_g3d.6.3.cvs.so: linux-gate.so.1 => (0xffffe000) libgrass_gis.so => /usr/local/grass-6.3.cvs/lib/libgrass_gis.so (0xb7ea4000) libgrass_datetime.so => /usr/local/grass-6.3.cvs/lib/libgrass_datetime.so (0xb7e9c000) libz.so.1 => /usr/lib/libz.so.1 (0xb7e88000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7d59000) /lib/ld-linux.so.2 (0x80000000) /usr/local/grass-6.3.cvs/lib/libgrass_gis.6.3.cvs.so: linux-gate.so.1 => (0xffffe000) libz.so.1 => /usr/lib/libz.so.1 (0xb7e9e000) libgrass_datetime.so => /usr/local/grass-6.3.cvs/lib/libgrass_datetime.so (0xb7e96000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7d67000) /lib/ld-linux.so.2 (0x80000000) /usr/local/grass-6.3.cvs/lib/libgrass_gmath.6.3.cvs.so: linux-gate.so.1 => (0xffffe000) libgrass_gis.so => /usr/local/grass-6.3.cvs/lib/libgrass_gis.so (0xb7f41000) libgrass_datetime.so => /usr/local/grass-6.3.cvs/lib/libgrass_datetime.so (0xb7f39000) libz.so.1 => /usr/lib/libz.so.1 (0xb7f25000) libfftw3.so.3 => /usr/lib/libfftw3.so.3 (0xb7e51000) libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7e2f000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7d00000) libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7ced000) /lib/ld-linux.so.2 (0x80000000) /usr/local/grass-6.3.cvs/lib/libgrass_gproj.6.3.cvs.so: linux-gate.so.1 => (0xffffe000) libgrass_gis.so => /usr/local/grass-6.3.cvs/lib/libgrass_gis.so (0xb7eec000) libgrass_datetime.so => /usr/local/grass-6.3.cvs/lib/libgrass_datetime.so (0xb7ee4000) libz.so.1 => /usr/lib/libz.so.1 (0xb7ed0000) libproj.so.0 => /usr/local/lib/libproj.so.0 (0xb7ea0000) libgdal.so.1 => /usr/local/lib/libgdal.so.1 (0xb7944000) libgeos.so.2 => /usr/local/lib/libgeos.so.2 (0xb785a000) libgeos_c.so.1 => /usr/local/lib/libgeos_c.so.1 (0xb784c000) libpq.so.4 => /usr/lib/libpq.so.4 (0xb7830000) libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb780e000) librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0xb7806000) libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7803000) libsqlite3.so.0 => /usr/lib/libsqlite3.so.0 (0xb77b2000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7682000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb75a8000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb759d000) libssl.so.0.9.8 => /usr/lib/i686/cmov/libssl.so.0.9.8 (0xb7560000) libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8 (0xb7431000) libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xb73b7000) libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0xb7394000) libcom_err.so.2 => /lib/libcom_err.so.2 (0xb7391000) libcrypt.so.1 => /lib/tls/i686/cmov/libcrypt.so.1 (0xb7364000) libresolv.so.2 => /lib/tls/i686/cmov/libresolv.so.2 (0xb7351000) libnsl.so.1 => /lib/tls/i686/cmov/libnsl.so.1 (0xb733c000) libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7329000) /lib/ld-linux.so.2 (0x80000000) libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0xb7324000) /usr/local/grass-6.3.cvs/lib/libgrass_I.6.3.cvs.so: linux-gate.so.1 => (0xffffe000) libgrass_gmath.so => /usr/local/grass-6.3.cvs/lib/libgrass_gmath.so (0xb7f2f000) libgrass_gis.so => /usr/local/grass-6.3.cvs/lib/libgrass_gis.so (0xb7eea000) libgrass_datetime.so => /usr/local/grass-6.3.cvs/lib/libgrass_datetime.so (0xb7ee2000) libz.so.1 => /usr/lib/libz.so.1 (0xb7ece000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7d9f000) libfftw3.so.3 => /usr/lib/libfftw3.so.3 (0xb7ccb000) libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7ca8000) /lib/ld-linux.so.2 (0x80000000) libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7c96000) /usr/local/grass-6.3.cvs/lib/libgrass_interpdata.6.3.cvs.so: linux-gate.so.1 => (0xffffe000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7e10000) /lib/ld-linux.so.2 (0x80000000) /usr/local/grass-6.3.cvs/lib/libgrass_interpfl.6.3.cvs.so: linux-gate.so.1 => (0xffffe000) libgrass_gis.so => /usr/local/grass-6.3.cvs/lib/libgrass_gis.so (0xb7eb9000) libgrass_datetime.so => /usr/local/grass-6.3.cvs/lib/libgrass_datetime.so (0xb7eb1000) libz.so.1 => /usr/lib/libz.so.1 (0xb7e9d000) libgrass_vect.so => /usr/local/grass-6.3.cvs/lib/libgrass_vect.so (0xb7e6d000) libgrass_dbmibase.so => /usr/local/grass-6.3.cvs/lib/libgrass_dbmibase.so (0xb7e60000) libgrass_dbmiclient.so => /usr/local/grass-6.3.cvs/lib/libgrass_dbmiclient.so (0xb7e56000) libgrass_dgl.so => /usr/local/grass-6.3.cvs/lib/libgrass_dgl.so (0xb7e41000) libgrass_dig2.so => /usr/local/grass-6.3.cvs/lib/libgrass_dig2.so (0xb7e30000) libgrass_rtree.so => /usr/local/grass-6.3.cvs/lib/libgrass_rtree.so (0xb7e2b000) libgrass_linkm.so => /usr/local/grass-6.3.cvs/lib/libgrass_linkm.so (0xb7e29000) libgdal.so.1 => /usr/local/lib/libgdal.so.1 (0xb78cc000) libgeos.so.2 => /usr/local/lib/libgeos.so.2 (0xb77e2000) libgeos_c.so.1 => /usr/local/lib/libgeos_c.so.1 (0xb77d5000) libpq.so.4 => /usr/lib/libpq.so.4 (0xb77b9000) libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7797000) librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0xb778f000) libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb778b000) libsqlite3.so.0 => /usr/lib/libsqlite3.so.0 (0xb773a000) libgrass_sites.so => /usr/local/grass-6.3.cvs/lib/libgrass_sites.so (0xb7734000) libgrass_bitmap.so => /usr/local/grass-6.3.cvs/lib/libgrass_bitmap.so (0xb7731000) libgrass_qtree.so => /usr/local/grass-6.3.cvs/lib/libgrass_qtree.so (0xb772f000) libgrass_interpdata.so => /usr/local/grass-6.3.cvs/lib/libgrass_interpdata.so (0xb772c000) libgrass_gmath.so => /usr/local/grass-6.3.cvs/lib/libgrass_gmath.so (0xb7727000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb75f8000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb751e000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7513000) libssl.so.0.9.8 => /usr/lib/i686/cmov/libssl.so.0.9.8 (0xb74d5000) libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8 (0xb73a6000) libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xb732d000) libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0xb730a000) libcom_err.so.2 => /lib/libcom_err.so.2 (0xb7307000) libcrypt.so.1 => /lib/tls/i686/cmov/libcrypt.so.1 (0xb72da000) libresolv.so.2 => /lib/tls/i686/cmov/libresolv.so.2 (0xb72c6000) libnsl.so.1 => /lib/tls/i686/cmov/libnsl.so.1 (0xb72b1000) libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb729f000) /lib/ld-linux.so.2 (0x80000000) libfftw3.so.3 => /usr/lib/libfftw3.so.3 (0xb71cb000) libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0xb71c5000) /usr/local/grass-6.3.cvs/lib/libgrass_Iortho.6.3.cvs.so: linux-gate.so.1 => (0xffffe000) libgrass_gis.so => /usr/local/grass-6.3.cvs/lib/libgrass_gis.so (0xb7ee4000) libgrass_datetime.so => /usr/local/grass-6.3.cvs/lib/libgrass_datetime.so (0xb7edc000) libz.so.1 => /usr/lib/libz.so.1 (0xb7ec8000) libgrass_I.so => /usr/local/grass-6.3.cvs/lib/libgrass_I.so (0xb7eba000) libgrass_gmath.so => /usr/local/grass-6.3.cvs/lib/libgrass_gmath.so (0xb7eb5000) libgrass_vask.so => /usr/local/grass-6.3.cvs/lib/libgrass_vask.so (0xb7eae000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7d7f000) libfftw3.so.3 => /usr/lib/libfftw3.so.3 (0xb7cab000) libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7c89000) libncurses.so.5 => /lib/libncurses.so.5 (0xb7c48000) /lib/ld-linux.so.2 (0x80000000) libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7c36000) libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7c32000) /usr/local/grass-6.3.cvs/lib/libgrass_lidar.6.3.cvs.so: linux-gate.so.1 => (0xffffe000) libgrass_vect.so => /usr/local/grass-6.3.cvs/lib/libgrass_vect.so (0xb7f5d000) libgrass_dbmibase.so => /usr/local/grass-6.3.cvs/lib/libgrass_dbmibase.so (0xb7f50000) libgrass_gis.so => /usr/local/grass-6.3.cvs/lib/libgrass_gis.so (0xb7f0b000) libgrass_datetime.so => /usr/local/grass-6.3.cvs/lib/libgrass_datetime.so (0xb7f03000) libz.so.1 => /usr/lib/libz.so.1 (0xb7eef000) libgrass_dbmiclient.so => /usr/local/grass-6.3.cvs/lib/libgrass_dbmiclient.so (0xb7ee5000) libgrass_dgl.so => /usr/local/grass-6.3.cvs/lib/libgrass_dgl.so (0xb7ed0000) libgrass_dig2.so => /usr/local/grass-6.3.cvs/lib/libgrass_dig2.so (0xb7ebf000) libgrass_rtree.so => /usr/local/grass-6.3.cvs/lib/libgrass_rtree.so (0xb7eba000) libgrass_linkm.so => /usr/local/grass-6.3.cvs/lib/libgrass_linkm.so (0xb7eb8000) libgdal.so.1 => /usr/local/lib/libgdal.so.1 (0xb795b000) libgeos.so.2 => /usr/local/lib/libgeos.so.2 (0xb7871000) libgeos_c.so.1 => /usr/local/lib/libgeos_c.so.1 (0xb7864000) libpq.so.4 => /usr/lib/libpq.so.4 (0xb7848000) libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7826000) librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0xb781e000) libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb781a000) libsqlite3.so.0 => /usr/lib/libsqlite3.so.0 (0xb77c9000) libgrass_segment.so => /usr/local/grass-6.3.cvs/lib/libgrass_segment.so (0xb77c6000) libgrass_gmath.so => /usr/local/grass-6.3.cvs/lib/libgrass_gmath.so (0xb77c1000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7692000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb75b7000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb75ac000) libssl.so.0.9.8 => /usr/lib/i686/cmov/libssl.so.0.9.8 (0xb756f000) libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8 (0xb7440000) libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xb73c7000) libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0xb73a3000) libcom_err.so.2 => /lib/libcom_err.so.2 (0xb73a0000) libcrypt.so.1 => /lib/tls/i686/cmov/libcrypt.so.1 (0xb7373000) libresolv.so.2 => /lib/tls/i686/cmov/libresolv.so.2 (0xb7360000) libnsl.so.1 => /lib/tls/i686/cmov/libnsl.so.1 (0xb734b000) libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7339000) /lib/ld-linux.so.2 (0x80000000) libfftw3.so.3 => /usr/lib/libfftw3.so.3 (0xb7264000) libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0xb725f000) /usr/local/grass-6.3.cvs/lib/libgrass_linkm.6.3.cvs.so: linux-gate.so.1 => (0xffffe000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7e30000) /lib/ld-linux.so.2 (0x80000000) /usr/local/grass-6.3.cvs/lib/libgrass_lrs.6.3.cvs.so: linux-gate.so.1 => (0xffffe000) libgrass_vect.so => /usr/local/grass-6.3.cvs/lib/libgrass_vect.so (0xb7f0e000) libgrass_dbmibase.so => /usr/local/grass-6.3.cvs/lib/libgrass_dbmibase.so (0xb7f01000) libgrass_gis.so => /usr/local/grass-6.3.cvs/lib/libgrass_gis.so (0xb7ebc000) libgrass_datetime.so => /usr/local/grass-6.3.cvs/lib/libgrass_datetime.so (0xb7eb4000) libz.so.1 => /usr/lib/libz.so.1 (0xb7ea0000) libgrass_dbmiclient.so => /usr/local/grass-6.3.cvs/lib/libgrass_dbmiclient.so (0xb7e96000) libgrass_dgl.so => /usr/local/grass-6.3.cvs/lib/libgrass_dgl.so (0xb7e81000) libgrass_dig2.so => /usr/local/grass-6.3.cvs/lib/libgrass_dig2.so (0xb7e70000) libgrass_rtree.so => /usr/local/grass-6.3.cvs/lib/libgrass_rtree.so (0xb7e6b000) libgrass_linkm.so => /usr/local/grass-6.3.cvs/lib/libgrass_linkm.so (0xb7e69000) libgdal.so.1 => /usr/local/lib/libgdal.so.1 (0xb790c000) libgeos.so.2 => /usr/local/lib/libgeos.so.2 (0xb7822000) libgeos_c.so.1 => /usr/local/lib/libgeos_c.so.1 (0xb7815000) libpq.so.4 => /usr/lib/libpq.so.4 (0xb77f9000) libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb77d7000) librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0xb77cf000) libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb77cb000) libsqlite3.so.0 => /usr/lib/libsqlite3.so.0 (0xb777a000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb764b000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7571000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7566000) libssl.so.0.9.8 => /usr/lib/i686/cmov/libssl.so.0.9.8 (0xb7528000) libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8 (0xb73f9000) libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xb7380000) libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0xb735d000) libcom_err.so.2 => /lib/libcom_err.so.2 (0xb735a000) libcrypt.so.1 => /lib/tls/i686/cmov/libcrypt.so.1 (0xb732c000) libresolv.so.2 => /lib/tls/i686/cmov/libresolv.so.2 (0xb7319000) libnsl.so.1 => /lib/tls/i686/cmov/libnsl.so.1 (0xb7304000) libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb72f2000) /lib/ld-linux.so.2 (0x80000000) libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0xb72ed000) /usr/local/grass-6.3.cvs/lib/libgrass_ogsf.6.3.cvs.so: linux-gate.so.1 => (0xffffe000) libgrass_gis.so => /usr/local/grass-6.3.cvs/lib/libgrass_gis.so (0xb7f3e000) libgrass_datetime.so => /usr/local/grass-6.3.cvs/lib/libgrass_datetime.so (0xb7f36000) libz.so.1 => /usr/lib/libz.so.1 (0xb7f22000) libgrass_bitmap.so => /usr/local/grass-6.3.cvs/lib/libgrass_bitmap.so (0xb7f1f000) libgrass_linkm.so => /usr/local/grass-6.3.cvs/lib/libgrass_linkm.so (0xb7f1d000) libgrass_vect.so => /usr/local/grass-6.3.cvs/lib/libgrass_vect.so (0xb7eec000) libgrass_dbmibase.so => /usr/local/grass-6.3.cvs/lib/libgrass_dbmibase.so (0xb7edf000) libgrass_dbmiclient.so => /usr/local/grass-6.3.cvs/lib/libgrass_dbmiclient.so (0xb7ed6000) libgrass_dgl.so => /usr/local/grass-6.3.cvs/lib/libgrass_dgl.so (0xb7ec1000) libgrass_dig2.so => /usr/local/grass-6.3.cvs/lib/libgrass_dig2.so (0xb7eb0000) libgrass_rtree.so => /usr/local/grass-6.3.cvs/lib/libgrass_rtree.so (0xb7eab000) libgdal.so.1 => /usr/local/lib/libgdal.so.1 (0xb794e000) libgeos.so.2 => /usr/local/lib/libgeos.so.2 (0xb7864000) libgeos_c.so.1 => /usr/local/lib/libgeos_c.so.1 (0xb7857000) libpq.so.4 => /usr/lib/libpq.so.4 (0xb783b000) libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7819000) librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0xb7811000) libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb780d000) libsqlite3.so.0 => /usr/lib/libsqlite3.so.0 (0xb77bc000) libGL.so.1 => /usr/lib/libGL.so.1 (0xb771c000) libGLU.so.1 => /usr/lib/libGLU.so.1 (0xb76a6000) libtiff.so.4 => /usr/lib/libtiff.so.4 (0xb7656000) libavcodec.so.0d => /usr/lib/libavcodec.so.0d (0xb72e2000) libgrass_sites.so => /usr/local/grass-6.3.cvs/lib/libgrass_sites.so (0xb72db000) libgrass_g3d.so => /usr/local/grass-6.3.cvs/lib/libgrass_g3d.so (0xb72bf000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7190000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb70b6000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb70ab000) libssl.so.0.9.8 => /usr/lib/i686/cmov/libssl.so.0.9.8 (0xb706d000) libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8 (0xb6f3e000) libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xb6ec5000) libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0xb6ea2000) libcom_err.so.2 => /lib/libcom_err.so.2 (0xb6e9f000) libcrypt.so.1 => /lib/tls/i686/cmov/libcrypt.so.1 (0xb6e71000) libresolv.so.2 => /lib/tls/i686/cmov/libresolv.so.2 (0xb6e5e000) libnsl.so.1 => /lib/tls/i686/cmov/libnsl.so.1 (0xb6e49000) libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb6e37000) /lib/ld-linux.so.2 (0x80000000) libXext.so.6 => /usr/lib/libXext.so.6 (0xb6e2a000) libX11.so.6 => /usr/lib/libX11.so.6 (0xb6d43000) libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0xb6d24000) libvorbis.so.0 => /usr/lib/libvorbis.so.0 (0xb6cfc000) libvorbisenc.so.2 => /usr/lib/libvorbisenc.so.2 (0xb6bfe000) libogg.so.0 => /usr/lib/libogg.so.0 (0xb6bf9000) libtheora.so.0 => /usr/lib/libtheora.so.0 (0xb6bc0000) libdc1394_control.so.13 => /usr/lib/libdc1394_control.so.13 (0xb6bb1000) libraw1394.so.5 => /usr/lib/libraw1394.so.5 (0xb6bac000) libgsm.so.1 => /usr/lib/libgsm.so.1 (0xb6b9c000) libmp3lame.so.0 => /usr/lib/libmp3lame.so.0 (0xb6afa000) libfaac.so.0 => /usr/lib/libfaac.so.0 (0xb6ae9000) libxvidcore.so.4 => /usr/lib/libxvidcore.so.4 (0xb69ce000) libavutil.so.0d => /usr/lib/libavutil.so.0d (0xb69c9000) libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0xb69c4000) libXau.so.6 => /usr/lib/libXau.so.6 (0xb69c1000) libmp4v2.so.0 => /usr/lib/libmp4v2.so.0 (0xb6924000) /usr/local/grass-6.3.cvs/lib/libgrass_pngdriver.6.3.cvs.so: linux-gate.so.1 => (0xffffe000) libgrass_driver.so => /usr/local/grass-6.3.cvs/lib/libgrass_driver.so (0xb7f20000) libgrass_gis.so => /usr/local/grass-6.3.cvs/lib/libgrass_gis.so (0xb7edb000) libgrass_datetime.so => /usr/local/grass-6.3.cvs/lib/libgrass_datetime.so (0xb7ed3000) libz.so.1 => /usr/lib/libz.so.1 (0xb7ebf000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb7e56000) libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb7e33000) libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7e10000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7ce1000) /lib/ld-linux.so.2 (0x80000000) /usr/local/grass-6.3.cvs/lib/libgrass_qtree.6.3.cvs.so: linux-gate.so.1 => (0xffffe000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7e97000) /lib/ld-linux.so.2 (0x80000000) /usr/local/grass-6.3.cvs/lib/libgrass_raster.6.3.cvs.so: linux-gate.so.1 => (0xffffe000) libgrass_driver.so => /usr/local/grass-6.3.cvs/lib/libgrass_driver.so (0xb7fb7000) libgrass_gis.so => /usr/local/grass-6.3.cvs/lib/libgrass_gis.so (0xb7f72000) libgrass_datetime.so => /usr/local/grass-6.3.cvs/lib/libgrass_datetime.so (0xb7f6a000) libz.so.1 => /usr/lib/libz.so.1 (0xb7f56000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb7eed000) libgrass_pngdriver.so => /usr/local/grass-6.3.cvs/lib/libgrass_pngdriver.so (0xb7ee5000) libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb7ec2000) libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7ea0000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7d71000) /lib/ld-linux.so.2 (0x80000000) /usr/local/grass-6.3.cvs/lib/libgrass_rowio.6.3.cvs.so: linux-gate.so.1 => (0xffffe000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7e2c000) /lib/ld-linux.so.2 (0x80000000) /usr/local/grass-6.3.cvs/lib/libgrass_rtree.6.3.cvs.so: linux-gate.so.1 => (0xffffe000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7dfa000) /lib/ld-linux.so.2 (0x80000000) /usr/local/grass-6.3.cvs/lib/libgrass_segment.6.3.cvs.so: linux-gate.so.1 => (0xffffe000) libgrass_gis.so => /usr/local/grass-6.3.cvs/lib/libgrass_gis.so (0xb7f53000) libgrass_datetime.so => /usr/local/grass-6.3.cvs/lib/libgrass_datetime.so (0xb7f4b000) libz.so.1 => /usr/lib/libz.so.1 (0xb7f37000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7e08000) /lib/ld-linux.so.2 (0x80000000) /usr/local/grass-6.3.cvs/lib/libgrass_shape.6.3.cvs.so: linux-gate.so.1 => (0xffffe000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7e11000) /lib/ld-linux.so.2 (0x80000000) /usr/local/grass-6.3.cvs/lib/libgrass_sim.6.3.cvs.so: linux-gate.so.1 => (0xffffe000) libgrass_gis.so => /usr/local/grass-6.3.cvs/lib/libgrass_gis.so (0x9b8e8000) libgrass_datetime.so => /usr/local/grass-6.3.cvs/lib/libgrass_datetime.so (0x9b8e0000) libz.so.1 => /usr/lib/libz.so.1 (0x9b8cc000) libgrass_bitmap.so => /usr/local/grass-6.3.cvs/lib/libgrass_bitmap.so (0x9b8c9000) libgrass_linkm.so => /usr/local/grass-6.3.cvs/lib/libgrass_linkm.so (0x9b8c7000) libgrass_dbmiclient.so => /usr/local/grass-6.3.cvs/lib/libgrass_dbmiclient.so (0x9b8bd000) libgrass_dbmibase.so => /usr/local/grass-6.3.cvs/lib/libgrass_dbmibase.so (0x9b8b0000) libgrass_gmath.so => /usr/local/grass-6.3.cvs/lib/libgrass_gmath.so (0x9b8ab000) libgrass_sites.so => /usr/local/grass-6.3.cvs/lib/libgrass_sites.so (0x9b8a5000) libgrass_vect.so => /usr/local/grass-6.3.cvs/lib/libgrass_vect.so (0x9b875000) libgrass_dgl.so => /usr/local/grass-6.3.cvs/lib/libgrass_dgl.so (0x9b85f000) libgrass_dig2.so => /usr/local/grass-6.3.cvs/lib/libgrass_dig2.so (0x9b84e000) libgrass_rtree.so => /usr/local/grass-6.3.cvs/lib/libgrass_rtree.so (0x9b849000) libgdal.so.1 => /usr/local/lib/libgdal.so.1 (0x9b2ed000) libgeos.so.2 => /usr/local/lib/libgeos.so.2 (0x9b203000) libgeos_c.so.1 => /usr/local/lib/libgeos_c.so.1 (0x9b1f6000) libpq.so.4 => /usr/lib/libpq.so.4 (0x9b1d9000) libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0x9b1b7000) librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0x9b1af000) libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0x9b1ac000) libsqlite3.so.0 => /usr/lib/libsqlite3.so.0 (0x9b15b000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x9b02c000) libfftw3.so.3 => /usr/lib/libfftw3.so.3 (0x9af57000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x9ae7d000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x9ae72000) libssl.so.0.9.8 => /usr/lib/i686/cmov/libssl.so.