[GRASS-user] Re: Strange r.mapcalc results
r.univar based comparison: What if there was a small geometric shift between the 2 maps. Would I notice if both maps have enough NULLs around the edges? r.mapcalc diffmap = map1 - map2 How would I separate NULL,NULL cases from cases where one map has a value, but the other has NULL? And after thinking twice about my earlier posted test results, I still do not understand the logic of the isnull() results: isnull(mapA) isnull(mapT) gives NULL (Test1) isnull(mapA) isnull(mapT) gives 1(Test3) This doesn't make sense to me, which might be my fault, though. Test1 $ r.mapcalc 'result = isnull(mapA) isnull(mapT) || mapA == mapT ? 1 : 2' $ r.stats -c result 1 799796 * 3200204 Test3 $ r.mapcalc 'result = isnull(mapA) isnull(mapT) ? 1 : mapA == mapT ? 2 : 3' $ r.stats -c result 1 3200204 2 799796 Hermann Hamish wrote: Hermann wrote: I am trying to find out if 2 raster layers are exactly identical. I usually do g.region rast=map1,map2 r.univar map1 r.univar map2 and make sure the output is the same. another way is r.mapcalc diffmap = map1 - map2 r.univar diffmap see also wish #618 https://trac.osgeo.org/grass/ticket/618 Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: Exporting attributes to GMT ASCII format using v.out.ogr
Benjamin Ducke wrote: IMHO choosing line/boundary as a default for ANY map (i.e. even one that has no such geometries) is a bug, not useful default behaviour. So I would expect any scripts that use v.out.ogr in earnest to be setting the type= option explicitly, anyhow. IMHO, that applies to many vector modules. Having as default answer for the type option all types can produce unexpected and undesired results. The user would want a module to act only on certain types, but it is easy to forget setting the type option accordingly and then all vector object types are processed. Rather have the type option not set at all by default and exit with an error if no type is selected? Markus M The problem reported earlier with exporting areas to GMT format seems to me to illustrate this. The relationship between lines, boundaries and areas can be very confusing, especially when data export/import is concerned. Actually, I would like to improve the area export logics so that problems like Eric experienced will get more rare in the future. Anyhow, if there is a consensus that the old default behaviour needs to stay, I will change the automatic export type determination to only run on user demand, via a flag. Cheers, Ben - Original Message - From: Hamish hamis...@yahoo.com To: Eric Patton epat...@nrcan.gc.ca Cc: grass-user grass-user@lists.osgeo.org, Hermann Peifer pei...@gmx.eu Sent: Monday, September 21, 2009 9:35:49 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: [GRASS-user] Re: Exporting attributes to GMT ASCII format using v.out.ogr Hamish: I would ask if it acts any differently in latest grass 6.5 or 7 svn builds? (6.5 change may be reverted as it may break backwards compatibility / expected behaviour) Eric: Which change are you referring to? I'm using the latest 6.5.svn, and all seems to run smoothly. make that in new cases make things better, but subtly break backwards compatibility / expected behaviour in existing scripts. ie an old script for 6.x should produce the same output as a new script at the cost of the default action not being as nice. I don't really know if this is just hypothetical or if it could really screw somebody up. (ie if it matters or not) r39128 https://trac.osgeo.org/grass/log/grass/branches/develbranch_6/vector/v.out.ogr Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] 2nd call for papers - 2010 Conference on Integrative Landscape Modeling, Linking environmental, social and computer sciences
Hello dear Grass - users, 2010 Conference on Integrative Landscape Modeling Linking environmental, social and computer sciences Montpellier, France, February 3rd-5th, 2010 2nd call for papers The 2010 international conference on integrative landscape modelling will gather leading scientists in each of the main disciplines dealing with ecosystems and landscape simulation and management, complex dynamic modelling and assessment of vulnerability, resilience and adaptation of agro- and eco-systems under human influence. The main objectives of the conference are: To discuss the objectives, priorities and expectations when modelling the functioning of landscapes; To share experience about landscape modelling and to identify major existing conceptual and technological gaps; To release a ‘state of the art’ about landscape modelling and simulation; To start building an international network on integrative ecosystems and landscape modelling. If you are interested in attending this conference, please send an extended abstract of your original work related to any aspect (thematic, conceptual, epistemological, technical) of integrative landscape modelling (4 pages max. including figures and tables and references), no later than October, 31st. You will be notified whether your paper is accepted for an oral or poster session by November, 30th. More information and online pre-registration: http://www.umr-lisah.fr/rtra-projects/landmod2010.html Steering committee Jean-Christophe FABRE, Laboratory of study of interactions among soils, agrosystems and hydrosystems, INRA Montpellier, France Marc JAEGER, Botany and computational plant architecture laboratory, Cirad Montpellier, France Xavier LOUCHART, Laboratory of study of interactions among soils, agrosystems and hydrosystems, INRA Montpellier, France Jean-Pierre MULLER, Renewable resources and environment management laboratory, Cirad Montpellier, France Scientific committee Philippe ACKERER, Institute of Fluids Mechanics, University of Strasbourg, France Richard ASPINALL, Macaulay Institute, Aberdeen, UK Daniel AUCLAIR, Research Unit AMAP Botany and Computational Plant Architecture, Cirad, Montpellier, France Olivier BARRETEAU, Research Unit G-EAU Water Management, Stakeholders, Uses, CEMAGREF, Montpellier, France Lluís BROTONS, Landscape Ecology Group, Technological Forestry Centre of Catalonia, Solsona, Spain Yves BRUNET, Research Unit of Functional Ecology and Environmental Physics, INRA Bordeaux, France Christine FURST, Institute for Soil Science and Site Ecology, Dresden University of Technology, Germany Cédric GAUCHEREL, Research Unit AMAP Botany and Computational Plant Architecture, Cirad, Montpellier, France Volker GRIMM, Department of Ecological Modelling, Helmholtz Center for Environmental Research, Leipzig, Germany Sandra LUQUE, Dynamics and management of mountain ecosystems, CEMAGREF, Grenoble, France Dawn PARKER, School of planning, University of Waterloo, Canada Tom A. VELDKAMP, Landscape Centre, Wageningen, The Netherlands Secretariat: LandMod2010 UMR LISAH - 2 place P. Viala F-34060 Montpellier cedex 1 – France Tel : +33 (0)4 99 61 21 60 Fax : +33 (0)4 67 63 26 14 br...@supagro.inra.fr -- * Michaël Rabotin Ingénieur d'étude en géomatique Laboratoire d'étude des Interactions Sol, Agrosystème et Hydrosystème UMR LISAH SupAgro-INRA-IRD Bat. 24 2 place Viala 34060 Montpellier cedex 1 FRANCE Téléphone : 33 (0)4 99 61 23 85 Secrétariat : 33 (0)4 99 61 22 61 Fax : 33 (0)4 67 63 26 14 E-mail : rabo...@supagro.inra.fr * ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: Exporting attributes to GMT ASCII format using v.out.ogr
Please note that I have reverted the default for v.out.ogr's type= in 6.5 SVN to line,boundary. In 7 SVN it remains auto and that seems to work well enough. The added challenge re. v.out.ogr is that not all supported OGR formats can handle mixed geometries. Unfortunately, the current GDAL 1.6 API also does not seem to have a function to query this, so we can't deal with it in a more automated way just yet. I agree that type selection in general needs a clean-up and be more consistent and easy on the poor users. Let's collect some ideas on this. Ben - Original Message - From: Markus Metz markus.metz.gisw...@googlemail.com To: Benjamin Ducke benjamin.du...@oxfordarch.co.uk, grass-user grass-user@lists.osgeo.org Cc: Hermann Peifer pei...@gmx.eu, Eric Patton epat...@nrcan.gc.ca Sent: Thursday, September 24, 2009 9:42:57 AM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: [GRASS-user] Re: Exporting attributes to GMT ASCII format using v.out.ogr Benjamin Ducke wrote: IMHO choosing line/boundary as a default for ANY map (i.e. even one that has no such geometries) is a bug, not useful default behaviour. So I would expect any scripts that use v.out.ogr in earnest to be setting the type= option explicitly, anyhow. IMHO, that applies to many vector modules. Having as default answer for the type option all types can produce unexpected and undesired results. The user would want a module to act only on certain types, but it is easy to forget setting the type option accordingly and then all vector object types are processed. Rather have the type option not set at all by default and exit with an error if no type is selected? Markus M The problem reported earlier with exporting areas to GMT format seems to me to illustrate this. The relationship between lines, boundaries and areas can be very confusing, especially when data export/import is concerned. Actually, I would like to improve the area export logics so that problems like Eric experienced will get more rare in the future. Anyhow, if there is a consensus that the old default behaviour needs to stay, I will change the automatic export type determination to only run on user demand, via a flag. Cheers, Ben - Original Message - From: Hamish hamis...@yahoo.com To: Eric Patton epat...@nrcan.gc.ca Cc: grass-user grass-user@lists.osgeo.org, Hermann Peifer pei...@gmx.eu Sent: Monday, September 21, 2009 9:35:49 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: [GRASS-user] Re: Exporting attributes to GMT ASCII format using v.out.ogr Hamish: I would ask if it acts any differently in latest grass 6.5 or 7 svn builds? (6.5 change may be reverted as it may break backwards compatibility / expected behaviour) Eric: Which change are you referring to? I'm using the latest 6.5.svn, and all seems to run smoothly. make that in new cases make things better, but subtly break backwards compatibility / expected behaviour in existing scripts. ie an old script for 6.x should produce the same output as a new script at the cost of the default action not being as nice. I don't really know if this is just hypothetical or if it could really screw somebody up. (ie if it matters or not) r39128 https://trac.osgeo.org/grass/log/grass/branches/develbranch_6/vector/v.out.ogr Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] thresh in v.select?
Hi all, I am using grass6.5, so I can use some v.select options. Now I have a general problem with objects that are very, very close to each other: only some digits far behind the comma are different. Is there a way to define the accuracy? Thanks for hints, Achim ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: Exporting attributes to GMT ASCII format using v.out.ogr
Benjamin Ducke wrote: Please note that I have reverted the default for v.out.ogr's type= in 6.5 SVN to line,boundary. That's not exactly a bug (maybe yes because default settings can produce wrong results?), but areas won't be exported correctly with these default settings. The resulting shapefile has lines not polygons, and attributes get lost because boundaries usually don't have categories, and if they do have, these categories do not represent the properties of the two areas to the left and right. What would probably work most of the time is point,line,area as default. Markus M In 7 SVN it remains auto and that seems to work well enough. The added challenge re. v.out.ogr is that not all supported OGR formats can handle mixed geometries. Unfortunately, the current GDAL 1.6 API also does not seem to have a function to query this, so we can't deal with it in a more automated way just yet. I agree that type selection in general needs a clean-up and be more consistent and easy on the poor users. Let's collect some ideas on this. Ben - Original Message - From: Markus Metz markus.metz.gisw...@googlemail.com To: Benjamin Ducke benjamin.du...@oxfordarch.co.uk, grass-user grass-user@lists.osgeo.org Cc: Hermann Peifer pei...@gmx.eu, Eric Patton epat...@nrcan.gc.ca Sent: Thursday, September 24, 2009 9:42:57 AM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: [GRASS-user] Re: Exporting attributes to GMT ASCII format using v.out.ogr Benjamin Ducke wrote: IMHO choosing line/boundary as a default for ANY map (i.e. even one that has no such geometries) is a bug, not useful default behaviour. So I would expect any scripts that use v.out.ogr in earnest to be setting the type= option explicitly, anyhow. IMHO, that applies to many vector modules. Having as default answer for the type option all types can produce unexpected and undesired results. The user would want a module to act only on certain types, but it is easy to forget setting the type option accordingly and then all vector object types are processed. Rather have the type option not set at all by default and exit with an error if no type is selected? Markus M The problem reported earlier with exporting areas to GMT format seems to me to illustrate this. The relationship between lines, boundaries and areas can be very confusing, especially when data export/import is concerned. Actually, I would like to improve the area export logics so that problems like Eric experienced will get more rare in the future. Anyhow, if there is a consensus that the old default behaviour needs to stay, I will change the automatic export type determination to only run on user demand, via a flag. Cheers, Ben - Original Message - From: Hamish hamis...@yahoo.com To: Eric Patton epat...@nrcan.gc.ca Cc: grass-user grass-user@lists.osgeo.org, Hermann Peifer pei...@gmx.eu Sent: Monday, September 21, 2009 9:35:49 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: [GRASS-user] Re: Exporting attributes to GMT ASCII format using v.out.ogr Hamish: I would ask if it acts any differently in latest grass 6.5 or 7 svn builds? (6.5 change may be reverted as it may break backwards compatibility / expected behaviour) Eric: Which change are you referring to? I'm using the latest 6.5.svn, and all seems to run smoothly. make that in new cases make things better, but subtly break backwards compatibility / expected behaviour in existing scripts. ie an old script for 6.x should produce the same output as a new script at the cost of the default action not being as nice. I don't really know if this is just hypothetical or if it could really screw somebody up. (ie if it matters or not) r39128 https://trac.osgeo.org/grass/log/grass/branches/develbranch_6/vector/v.out.ogr Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] strange behavior of i.cluster with sample=1,1
dear grass users, i'm working on landsat imagery and i need to do some automatic classification so i'm doing several tests with i.cluster (first, after that i will also try i.cass or i.gensigset). As I wanted to see the impact of the sample parameter, i launch a script with several variations and i noticed this result: when the sample parameter is becoming smaller, i.cluster tend to converge to only 1 class ... I was thinking that with more samples the result will be more accurate but it seems to be the oposit ... with the default value for sample, the result is always correct ... Is there something wrong with the fact to use sample=1,1 (or sample=10,10) instead of the default value sample=56,71 ? for the moment i'm working with landsat 5 or 7 imagery, so in the case of land use with a very reduce location (ex: small rivers), having samples only each 56x15m=840m can occult some land use category ... I have the same error on gras 6.3 or 6.4, grass did'nt notice any error, and I have enought of ram (only 65% used) ... do you have an idea of what is going wrong and what can i try to solve this problem? I join the results of i.cluster with 20 classes and sample=1,1 parameter set, the others have default values = it goes wrong imediately ... and with default sample (56,71), everything works ... Paramètres du cluster Nombre de classes initiales: 20 Taille minimum de classe :17 Séparation minimum entre classes: 0.00 Pourcentage de convergence: 98.00 Nombre maximum d'itérations: 30 Intervalle d'échantillonnage en ligne: 1 Intervalle d'échantillonnage en colonne: 1 Taille de l'échantillon : 40439680 points [ ...] Distribution des classes 1826562 24892 450783 312030 852164 16461112323198278046830198913214292 34722393559417324673927395262249348 20136031977504175473112258981750284 itération 1 ### 2 classes, 0.01% points stables Distribution des classes 38277534 0 0 0 0 0 0 0 0 0 02162146 0 0 0 0 0 0 0 0 itération 2 ### 1 classes, 5.35% points stables Distribution des classes 0 0 0 0 0 0 0 0 0 0 0 40439680 0 0 0 0 0 0 0 0 itération 3 ### 1 classes, 100.00% points stables Distribution des classes 0 0 0 0 0 0 0 0 0 0 0 40439680 0 0 0 0 0 0 0 0 -- Sylvain Maillard Doctorant en Sciences de l'Environnement Laboratoire Chimie Provence - UMR 6264 / Université de Provence la Tour du Valat - Centre de recherche pour la conservation des zones humides méditerranéennes Le Sambuc 13200 Arles France mail: maill...@tourduvalat.org tél:04.90.97.29.79 fax:04.90.97.20.19 www.tourduvalat.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] stream network extraction
Hi Markus, hi all, I'm trying to compilate the code of r.stream.extract (from addOns) but when I run make command it gives me this error: annal...@annalisa-laptop:~/grass_dev64/raster/r.stream.extract$ sudo make test -d OBJ.i686-pc-linux-gnu || mkdir -p OBJ.i686-pc-linux-gnu gcc -I/home/annalisa/grass_dev64/dist.i686-pc-linux-gnu/include -g -Wall -I/usr/local/include-DPACKAGE=\grassmods\ -I/home/annalisa/grass_dev64/dist.i686-pc-linux-gnu/include -o OBJ.i686-pc-linux-gnu/close.o -c close.c close.c: In function ‘close_streamvect’: close.c:33: warning: format not a string literal and no format arguments close.c:152: warning: format not a string literal and no format arguments close.c:184: warning: format not a string literal and no format arguments close.c:210: warning: format not a string literal and no format arguments close.c:218: warning: format not a string literal and no format arguments close.c:221: error: too few arguments to function ‘Vect_build’ close.c: In function ‘close_maps’: close.c:242: warning: format not a string literal and no format arguments make: *** [OBJ.i686-pc-linux-gnu/close.o] Error 1 close.c:221: error: too few arguments to function ‘Vect_build’ Where am I going wrong? thanks Anna 2009/9/23 Jarosław Jasiewicz jar...@amu.edu.pl Markus Metz pisze: Jarosław Jasiewicz wrote: rest of r.stream* modules including new r.stream.stats for Hortonian statistics are now available by grass addons page and by grass add-ons svn repository. I actually move tutorial on r.stream* to grass wiki page. Great, IMHO the tutorials on your website are very helpful and show nicely all the various results the new r.stream.* modules can produce. Maybe a link to the wiki page can be added to the manuals? Markus M Will be, Jarek ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Strange r.mapcalc results
Hermann Peifer wrote: I am trying to find out if 2 raster layers are exactly identical. I am not an experienced mapcalc user, so I am wondering, where the 3200204 NULL values come from, in Test1. The result in Test2 is what I expected. My obviously wrong understanding was that I wouldn't need the special operator ||| in Test1, as NULL values are already treated specially by isnull() Any hint from the experts? Test1 $ r.mapcalc 'result = isnull(mapA) isnull(mapT) || mapA == mapT ? 1 : 2' Test2 $ r.mapcalc 'result = isnull(mapA) isnull(mapT) ||| mapA == mapT ? 1 : 2' If mapA and mapT are both null, then Test 1 reduces to: result = isnull(mapA) isnull(mapT) || mapA == mapT - result = isnull(null) isnull(null) || null == null - result = 1 1 || null - result = 1 || null - result = null while Test2 reduces to: result = isnull(mapA) isnull(mapT) ||| mapA == mapT - result = isnull(null) isnull(null) ||| null == null - result = 1 1 ||| null - result = 1 ||| null - result = 1 The || and operators always propagate nulls (i.e. they return null if either operand is null), while ||| and return a non-null result where possible (i.e. ||| returns 1 if either operand is non-zero, returns 0 if either operand is zero). -- Glynn Clements gl...@gclements.plus.com ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] CYGWIN
Cverckova, Lubica wrote: Does anyone know when the new release of Cygwin (for Windows) will come out? When someone reminds me to build it ;) I'll look into making a package for 6.4.0-RC5. -- Glynn Clements gl...@gclements.plus.com ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] stream network extraction
Hi, 2009/9/24 annagrass6 annagra...@gmail.com: Hi Markus, hi all, I'm trying to compilate the code of r.stream.extract (from addOns) but when I run make command it gives me this error: annal...@annalisa-laptop:~/grass_dev64/raster/r.stream.extract$ sudo make test -d OBJ.i686-pc-linux-gnu || mkdir -p OBJ.i686-pc-linux-gnu gcc -I/home/annalisa/grass_dev64/dist.i686-pc-linux-gnu/include -g -Wall -I/usr/local/include -DPACKAGE=\grassmods\ -I/home/annalisa/grass_dev64/dist.i686-pc-linux-gnu/include -o OBJ.i686-pc-linux-gnu/close.o -c close.c close.c: In function ‘close_streamvect’: close.c:33: warning: format not a string literal and no format arguments close.c:152: warning: format not a string literal and no format arguments close.c:184: warning: format not a string literal and no format arguments close.c:210: warning: format not a string literal and no format arguments close.c:218: warning: format not a string literal and no format arguments close.c:221: error: too few arguments to function ‘Vect_build’ close.c: In function ‘close_maps’: close.c:242: warning: format not a string literal and no format arguments make: *** [OBJ.i686-pc-linux-gnu/close.o] Error 1 close.c:221: error: too few arguments to function ‘Vect_build’ Where am I going wrong? update your GRASS. In r34288 was eliminate non-standard logging mechanism, currently Vect_build() takes only one argument - pointer to Map_info structure. Martin -- Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: Strange r.mapcalc results
Glynn, Thanks indeed for the enlightening. I am new to the mapcalc business and my obviously wrong (AWK-based) thinking was that mapcalc would do a lazy evaluation of the conditions, i.e. 1 1 || something would always be 1, whatever something was. Now I know better. Thanks again, Hermann Glynn Clements wrote: Hermann Peifer wrote: I am trying to find out if 2 raster layers are exactly identical. I am not an experienced mapcalc user, so I am wondering, where the 3200204 NULL values come from, in Test1. The result in Test2 is what I expected. My obviously wrong understanding was that I wouldn't need the special operator ||| in Test1, as NULL values are already treated specially by isnull() Any hint from the experts? Test1 $ r.mapcalc 'result = isnull(mapA) isnull(mapT) || mapA == mapT ? 1 : 2' Test2 $ r.mapcalc 'result = isnull(mapA) isnull(mapT) ||| mapA == mapT ? 1 : 2' If mapA and mapT are both null, then Test 1 reduces to: result = isnull(mapA) isnull(mapT) || mapA == mapT - result = isnull(null) isnull(null) || null == null - result = 1 1 || null - result = 1 || null - result = null while Test2 reduces to: result = isnull(mapA) isnull(mapT) ||| mapA == mapT - result = isnull(null) isnull(null) ||| null == null - result = 1 1 ||| null - result = 1 ||| null - result = 1 The || and operators always propagate nulls (i.e. they return null if either operand is null), while ||| and return a non-null result where possible (i.e. ||| returns 1 if either operand is non-zero, returns 0 if either operand is zero). ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: Exporting attributes to GMT ASCII format using v.out.ogr
Benjamin Ducke wrote: Please note that I have reverted the default for v.out.ogr's type= in 6.5 SVN to line,boundary. In 7 SVN it remains auto and that seems to work well enough. thanks. I am glad to have the type=auto option in 6.5, it is a useful addition. maybe it is being a bit too strict with the no-changes to the module interface in a stable release rule, but then we can't guarantee that someone isn't aware of + relying on the old default=lines in a script, so the best we can do is avoid as many backwards-incompatibilities as we can and make the trunk version contain the ideal way. Plus this way we can claim the new release is backwards-compatible without fine print. cheers, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: Strange r.mapcalc results
Hermann Peifer wrote: Thanks indeed for the enlightening. I am new to the mapcalc business and my obviously wrong (AWK-based) thinking was that mapcalc would do a lazy evaluation of the conditions, i.e. 1 1 || something would always be 1, whatever something was. Now I know better. r.mapcalc never does short-circuit evaluation. This is true for if() and ?: as well as ,||,,|||. and || propagate nulls, while and ||| return non-null where possible. All four operators are symmetric, so e.g. null() ||| 1 and 1 ||| null() both evaluate to 1. -- Glynn Clements gl...@gclements.plus.com ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] The tomcat shut down when encounter some error grass commond
2009/9/23 Sören Gebbert soerengebb...@gmx.de
Hello maven,
i guess the problem is located in your GrassMain.java line 200:
if (ps.exitValue() != 0) {
System.exit(ps.exitValue());
}
AFAIK, the tomcat server uses a container to run the several servlet
threads
inside.
If you call from any servlet thread the System.exit() command, the server
will
be shutdown.
Java doc of System.exit():
Hi,thanks, you are right, I have solved this problem,but I want to know how
to judge a grass commond(called in my javaProgram) is successfully exected?
Terminates the currently running Java Virtual Machine.
Best regards
Soeren
Am Sunday 20 September 2009 05:21:29 schrieb maven apache:
Hi,
In my application ,I provide a interface which can called by users to
execute some geo process through the web,for example,user send a map,and
a
width to the server ,then the server can do a buffer operation using the
grass(the server make the grass commond) according to the parameter from
client .
But I found that if user give a invalide parameter, then the grass
commond
maybe error, I can get the error message in the log, but my web server
(tomcat)shut down itself.
Any one have encountered the same suitation?
Annex is my java class to set up the grass environment. I hope some can
check it and identify it if any problem exist.
The GrassMain is the main class to set up the environment,the GrassThread
is to get the output result , the GrassThreadError is to get the error
message if so.
Thanks!
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] The tomcat shut down when encounter some error grass commond
2009/9/23 Sören Gebbert soerengebb...@gmx.de
Hello maven,
i guess the problem is located in your GrassMain.java line 200:
if (ps.exitValue() != 0) {
System.exit(ps.exitValue());
}
AFAIK, the tomcat server uses a container to run the several servlet
threads
inside.
If you call from any servlet thread the System.exit() command, the server
will
be shutdown.
Java doc of System.exit():
Terminates the currently running Java Virtual Machine.
Thanks, you are right! ^_^
I have solved this problem,however I want to know how to judge whether the
grass commond(which I call in my program)is executed successfully?
Best regards
Soeren
Am Sunday 20 September 2009 05:21:29 schrieb maven apache:
Hi,
In my application ,I provide a interface which can called by users to
execute some geo process through the web,for example,user send a map,and
a
width to the server ,then the server can do a buffer operation using the
grass(the server make the grass commond) according to the parameter from
client .
But I found that if user give a invalide parameter, then the grass
commond
maybe error, I can get the error message in the log, but my web server
(tomcat)shut down itself.
Any one have encountered the same suitation?
Annex is my java class to set up the grass environment. I hope some can
check it and identify it if any problem exist.
The GrassMain is the main class to set up the environment,the GrassThread
is to get the output result , the GrassThreadError is to get the error
message if so.
Thanks!
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
