From glynn at gclements.plus.com Thu Feb 1 03:18:30 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Feb 1 03:18:34 2007 Subject: [GRASS-dev] Re: gui startup bug (new locn by epsg code) In-Reply-To: References: <20070130140432.7686fcf0.hamish_nospam@yahoo.com> <2b3d8c1c0701300222g384000d8rc79efe8fb6210532@mail.gmail.com> <17855.51830.443551.556031@cerise.gclements.plus.com> Message-ID: <17857.19958.486121.757194@cerise.gclements.plus.com> Paul Kelly wrote: > >> How do you propose it is fixed? It is arguable IMHO that the problem is > >> not in g.proj. It will only interactively prompt if *partially complete* > >> datum information is passed to it. If the GUI passes projection > >> information that has been pre-processed so the datum part is OK, then it > >> will not interactively prompt. This was discussed in an earlier thread. > > > > Yes, and I proposed a solution: replace the call to > > GPJ_ask_datum_params() with either a call to G_fatal_error() or some > > form of error indication (e.g. "return -1"). Assuming the availability > > of a terminal to obtain missing data from the user is a bug in > > GPJ_osr_to_grass(). > > > > Unless someone else proposes an alternative solution soon, I intend to > > change GPJ_osr_to_grass() to simply ignore the "interactive" > > parameter; if datum parameters are missing, you get the defaults; it > > will be up to the user to fix it afterwards. That approach has the > > advantage that it doesn't require any changes to calling programs > > (g.proj, v.in.ogr, r.in.gdal). > > If it has to be done I wouldn't like to see the functionality to choose > datum parameters from the tables in GRASS relegated to only g.setproj. > I was thinking along the lines of adding a new "interactive" flag to > g.proj. That takes us back to the issue of the GUI needing to determine whether or not a module is interactive. It's bad enough that modules don't report (via --tcltk, --interface-description, etc) whether or not they are interactive, but that can be fixed easily enough[1]. What can't easily be fixed is modules which are either interactive or not depending upon the specific combination of flags and options; how is a module supposed to communicate that information to the GUI? [1] I was planning on adding an "interactive" field (and possibly "xmonitor" or similar) to struct GModule, so that interactive modules would do e.g.: module = G_define_module(); ... module->interactive = YES; This information would then be passed to the GUI so that it knows that the module requires a terminal. > If this flag was specified along with -p, -j, -w or -c it would prompt as > at present if datum information was incomplete; if used along with the -d > flag then after reporting the datum information it would ask the user if > he/she wished to change the parameters. > > And every other place that calls GPJ_osr_to_grass() or GPJ_wkt_to_grass() > (I'm thinking of r.in.gdal and v.in.ogr and g.proj without the > -i/interactive flag specified) would set the interactive flag in the > function to 0. IMHO, the right way to do this is to simply remove the interactive flag from those functions, and leave it to the caller to update the datum transformation if necessary. g.setproj is at least consistent: it is interactive to the core, and calls GPJ_ask_datum_params() directly. Other modules (i.e. g.proj, r.in.gdal and v.in.ogr) should: 1. Provide an option to allow the user to specify any additional parameters, e.g. "projparms=nadgrids=conus". 2. If complete information isn't provided by either the source data or the aforementioned option, either: a) use the default values and print a warning, or b) generate an error indicating that you must manually specify either nadgrids or towgs84 via the option. -- Glynn Clements From glynn at gclements.plus.com Thu Feb 1 04:10:14 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Feb 1 04:11:38 2007 Subject: [GRASS-dev] r.colors In-Reply-To: <20070201100936.636c115f.hamish_nospam@yahoo.com> References: <200701311112.l0VBCWHL027468@grass.itc.it> <20070201100936.636c115f.hamish_nospam@yahoo.com> Message-ID: <17857.23062.930293.59640@cerise.gclements.plus.com> Hamish wrote: > > Since we're talking about color rules, I should mention that it is > > confusing to users to have 2 lists of predefined color tables show up > > in the r.colors GUI. I know what the difference is, but it is not > > obvious to most users. Since these additional rules files have been > > accompanying GRASS for a couple years now how about... > > > > 1. we include these color rules in the list of predefined color > > tables, and 2. change the second list to a browse function where a > > user could easily input her/his own color rules file without having to > > use a redirect from the command line. > > note that the second list (rules=) doesn't allow grey.eq, grey.log. > > can the file browser be told to start out in $GISBASE/etc/colors? > (I'm pretty sure I already know the answer for TclTk: "no") > > rules= files are easier to add and maintain, the only thing colors= has > going for it is the rules can be little programs, and long time > backwards compatitbility. FWIW, my original plan was to change the color= option to use the files once it had been tested and we had figured out how to deal with the special cases (grey.eq, grey.log). Somewhere along the line, I forgot about it. > I guess the other option is a new rulesfile= file browser option to load > custom rules, but I think your point was to reduce complexity :) > Perhaps that's better for a wrapper script that pipes the input file > into r.colors. > > FWIW r.colors will take rules interactively if you start it with: > > GRASS> r.colors map_name color=rules I suggest adding a file= option; this would imply color=rules and read the rules from a named file rather than stdin. The only differences between this and rules= are: 1. rules= requires that the rules file reside in $GISBASE/etc/colors, and 2. rules= has a list of valid options, while file= would accept any filename. -- Glynn Clements From michael.barton at asu.edu Thu Feb 1 06:47:28 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Feb 1 06:47:43 2007 Subject: [GRASS-dev] r.colors In-Reply-To: <17857.23062.930293.59640@cerise.gclements.plus.com> Message-ID: This is exactly how I was envisioning it. This makes it relatively easy to occasionally add to or change the default color tables that ship with GRASS, and also makes it easier for a user to access their own custom color tables. Michael On 1/31/07 8:10 PM, "Glynn Clements" wrote: > > Hamish wrote: > >>> Since we're talking about color rules, I should mention that it is >>> confusing to users to have 2 lists of predefined color tables show up >>> in the r.colors GUI. I know what the difference is, but it is not >>> obvious to most users. Since these additional rules files have been >>> accompanying GRASS for a couple years now how about... >>> >>> 1. we include these color rules in the list of predefined color >>> tables, and 2. change the second list to a browse function where a >>> user could easily input her/his own color rules file without having to >>> use a redirect from the command line. >> >> note that the second list (rules=) doesn't allow grey.eq, grey.log. >> >> can the file browser be told to start out in $GISBASE/etc/colors? >> (I'm pretty sure I already know the answer for TclTk: "no") >> >> rules= files are easier to add and maintain, the only thing colors= has >> going for it is the rules can be little programs, and long time >> backwards compatitbility. > > FWIW, my original plan was to change the color= option to use the > files once it had been tested and we had figured out how to deal with > the special cases (grey.eq, grey.log). Somewhere along the line, I > forgot about it. > >> I guess the other option is a new rulesfile= file browser option to load >> custom rules, but I think your point was to reduce complexity :) >> Perhaps that's better for a wrapper script that pipes the input file >> into r.colors. >> >> FWIW r.colors will take rules interactively if you start it with: >> >> GRASS> r.colors map_name color=rules > > I suggest adding a file= option; this would imply color=rules and read > the rules from a named file rather than stdin. The only differences > between this and rules= are: > > 1. rules= requires that the rules file reside in $GISBASE/etc/colors, > and > 2. rules= has a list of valid options, while file= would accept any > filename. __________________________________________ 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 Feb 1 06:52:32 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Feb 1 06:52:41 2007 Subject: New --script flag was: Re: [GRASS-dev] how to display a vector map for d.path in gis.m? In-Reply-To: <45C0952E.4010306@itc.it> Message-ID: Glynn, Could you explain how this works a bit more? It sounds cool, but I don't quite understand how it might be used. Michael On 1/31/07 6:10 AM, "Markus Neteler" wrote: > Glynn Clements wrote on 01/30/2007 11:04 PM: >> Glynn Clements wrote: >> >> >>> Hmm; it might be useful to have some means of automatically generating >>> the corresponding g.parser description for a given command. There are >>> probably quite a few scripts whose options are (almost) identical to >>> an existing command. I'll look into it. >>> >> >> I've extended G_parser() with a --script flag, which writes out a >> script with g.parser syntax to mimic the behaviour of the module. This >> shoud make it easier to write scripts which mimic an existing command. >> > Really cool! Thanks, Glynn. > > Markus > > __________________________________________ 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 Thu Feb 1 18:51:35 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Thu Feb 1 18:51:39 2007 Subject: [GRASS-dev] Re: [GRASS-user] Re: v.buffer creates artefact - bug? In-Reply-To: <45C0D19B.8080108@o2.pl> References: <20070130101832.20040@gmx.net> <45BF48AB.9090109@itc.it> <45BFBD29.2030908@o2.pl> <2b3d8c1c0701301444i339e0d43tf3b95e63071be3c@mail.gmail.com> <45C0D19B.8080108@o2.pl> Message-ID: <45C228A7.2070500@o2.pl> Maciej Sieczka wrote: > Hamish said it was not reproducible on his "Debian/Sarge, gcc 3.3.5, > linux 2.4.27-3-686 on a P4". > > Maybe GCC version makes the difference? I'll try GCC 3 when possible. So I did, gcc 3.3.6 on Ubunutu 6.06 32bit Pentium M. No good. Exactly the same bug crops out as with gcc 4.03. Hamish, Are you still not able to reproduce this? You might be holding the key to a fix. Maciek From landa.martin at gmail.com Thu Feb 1 21:52:34 2007 From: landa.martin at gmail.com (Martin Landa) Date: Thu Feb 1 21:52:41 2007 Subject: [GRASS-dev] Re: Wxgrass status update In-Reply-To: References: Message-ID: Hi, I am really *not* sure whether to re-open grass-gui mailing list or not. Generally speaking, the less mailing list exist the better for the users and developers. On the other hand this issue (i.e. GRASS-GUI) is long-running in GRASS community and (maybe) should be separated from grass-dev. I really don't know. Regards, Martin 2007/2/1, J?chym ?epick? : > Hmm, one problem: > > http://grass.itc.it/community/support.php > > GRASSGUI belongs to the old and unused mailing lists.. shall we move > the discussion to grass-dev? > > > Jachym > > 2007/2/1, Martin Landa : > > Hi all, > > > > I also vote for moving this discussion to the grass-gui mailing list... > > > > Best regards, Martin > > > > 2007/2/1, J?chym ?epick? : > > > maybe we should move the discussion to grass-gui list again... > > > > > > jachym > > > > > > 2007/2/1, Michael Barton : > > > > Jachym, > > > > > > > > I did a quick glance and it looks like it will make working with display > > > > layers much easier. Options panels can use these classes to define how > > > > layers should be displayed. > > > > > > > > Somewhere we'll need to wrap this code into the integrated application. This > > > > module is called render.py in my version--the one that I proposed renaming. > > > > Maybe disputil.py would make more sense in the long run. I'm not sure yet > > > > how much we should split up different functions into distinct smaller > > > > modules and how much they should be expressed as classes in included in > > > > larger modules. > > > > > > > > As we go along, we should keep trying to refactor like you've done here, and > > > > produce clean code that will be easier to maintain in the future. I've > > > > become acutely aware of this after untangling a lot of ancient TclTk > > > > spaghetti code (some of it not so ancient and mine). > > > > > > > > I'm copying a couple of other people who've been working on the interface > > > > and wx.Python recently so that they can have a link to this site and start > > > > to get an idea of where we are at. > > > > > > > > Cheers > > > > Michael > > > > > > > > I'm copying a couple other folks > > > > > > > > On 2/1/07 1:45 AM, "J?chym ?epick?" wrote: > > > > > > > > > hi Michael, it is good, that you are back! > > > > > > > > > > > > > > > > > > > > 2007/2/1, Michael Barton : > > > > >> > > > > >> Jachym, > > > > >> > > > > >> I'm actually working with wx.Python again. Thank goodness it is starting to > > > > >> come back to me after a 5 month hiatus. I decided to just focus on the > > > > >> mundane tasks of the layer manager. This is good practice for me and pretty > > > > >> straightforward in many respects, though sufficiently challenging (ie., > > > > >> difficult) that progress remains slow--for me at least. And I've only got > > > > >> bits and pieces of time to devote to this at the moment. > > > > >> > > > > >> What I've got now is a wx.Choicebook with a page for each display opened. > > > > >> On that page is a wx.Notebook with a layer tree (at least theoretically > > > > >> since I'm still trying to make it work) notebook page and a command console > > > > >> notebook page. Each layer (i.e., node in the tree) will need a way to > > > > >> indicate the name of the map in the layer, some indication (e.g., an icon) > > > > >> of whether it is raster or vector (or something else), a way to make the > > > > >> layer active/inactive, and some way to call up a panel to set the display > > > > >> options for the layer. It looks like wx.CustomTreeCtrl will work quite well > > > > >> for this. Once I get that far, I'll put it up on the cvs so that anyone can > > > > >> play with it. If you'd like to see where I'm at any time, just let me know > > > > >> and I'll send you some files. > > > > >> > > > > >> One other thing is that the render.py module has become a handy place to > > > > >> stash a few methods to track open displays, related variables, and the like > > > > >> so that they don't instantiate new displays or control panels when > > > > >> called--along with other display rendering functions. If it continues to > > > > >> serve in this way, do you think we should rename it to something like > > > > >> mapfunct.py or multifunct.py??? > > > > >> > > > > >> Just wanted to bring you up to date. Hope your trip is going well. > > > > >> > > > > >> Cheers > > > > >> 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 > > > > >> > > > > >> > > > > > > > > > > I started to define new set of classes, which should be easy to use > > > > > and more logical orderd. > > > > > > > > > > Please look at the > > > > > https://grasssvn.itc.it/grasssvn/grassaddons/trunk/grassaddons/gui/#_trunk_gra > > > > > ssaddons_gui_ > > > > > > > > > > you can test it with > > > > > > > > > > python mapimg.py > > > > > > > > > > and see the documentation with > > > > > > > > > > pydoc ./mapimg.py > > > > > > > > > > How to work with it, look at the end of mapimg.py > > > > > > > > > > Idea is, that each Map has defined set of layers (rasters, vectors, > > > > > graphs, WMS, WCS, ...). This set of layers should be taken over by > > > > > each Display. > > > > > > > > > > Let me know, if you like it > > > > > > > > > > I moved the work to grasssvn-addons repository, because this are all > > > > > fresh ideas and the code is not mature yet. Ones we have basic working > > > > > GUI, we shoul reorganize gui/wxpython directory. subversion anables us > > > > > to rename the files and so on. > > > > > > > > > > I hope, you like it > > > > > > > > > > Jachym > > > > > > > > > > P.S. I Sent this e-mail in a copy to Martin Landa - second GUI developer. > > > > > > > > __________________________________________ > > > > 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 gmail com > > > URL: http://les-ejk.cz > > > GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub > > > > > > > > > -- > > Martin Landa * http://gama.fsv.cvut.cz/~landa * > > > > > -- > Jachym Cepicky > e-mail: jachym.cepicky gmail com > URL: http://les-ejk.cz > GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub > -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From michael.barton at asu.edu Thu Feb 1 23:29:02 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Feb 1 23:29:33 2007 Subject: [GRASS-dev] Re: Wxgrass status update In-Reply-To: Message-ID: Given recent discussions on the developer list, we should probably just move discussions to there. I wanted to start out with getting in touch with the group of people who initially have been working on the GUI and wx.Python especially to make sure that they were in the loop. Along this line... 1. How can I put stuff on the subversion server (I can get a subversion client of course, but will need permissions) 2. There is already stuff on the cvs, so we need to coordinate with the main cvs site too. Michael On 2/1/07 1:52 PM, "Martin Landa" wrote: > Hi, I am really *not* sure whether to re-open grass-gui mailing list or not. > Generally speaking, the less mailing list exist the better for the users and > developers. On the other hand this issue (i.e. GRASS-GUI) is long-running in > GRASS community and (maybe) should be separated from grass-dev. I really don't > know. Regards, Martin __________________________________________ 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 grass-bugs at intevation.de Fri Feb 2 03:31:25 2007 From: grass-bugs at intevation.de (Request Tracker) Date: Fri Feb 2 03:31:27 2007 Subject: [GRASS-dev] [bug #5462] (grass) GRASS should support exporting E00 Message-ID: <20070202023125.A221A1006B3@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5462 ------------------------------------------------------------------------- Subject: GRASS should support exporting E00 Platform: WindowsNT/2000/XP grass obtained from: Trento Italy site grass binary for platform: Downloaded precompiled Binaries GRASS Version: 6.2 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! Dear GRASS Development Team I have been using GRASS in native window-Cygwin since 2000. In Thailand, many agencies use ESRI'software such as Arc/Info, Arc View Program. Also, the Arc-Node-Topology are be influenced the data model –Coverage that have Topology. I try export data from GRASS into shape file and import into Arc View: Topology generated in GRASS is not found in Arc View table. It is possible that GRASS will be support v.out.e00 in the next version.Infact, I am using both arc/info and grass, So, I demand GRASS version 6.0 supporting export e.00 format (V.out.e00), because I can exchange GIS data between agencies in Thailand that mostly use arc/info. Best Regards Boonlue Kachenchart Boonlue Kachenchart : Lecturer Faculty of Environment and Resource Studies, Mahidol University, 999 Phuttamonthon Road, Salaya, Phuttamonthon, Nakhon Pathom 73170, Thailand Phone +66-2441-5000 ext 141, +669-7714510 Fax +66-2441-9509-10 -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Fri Feb 2 05:32:37 2007 From: grass-bugs at intevation.de (Request Tracker) Date: Fri Feb 2 05:32:38 2007 Subject: [GRASS-dev] [bug #5463] (grass) v.in.dxf support for spaces in layer names Message-ID: <20070202043237.E32F01006B3@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5463 ------------------------------------------------------------------------- Subject: v.in.dxf support for spaces in layer names v.in.dxf fails to load in DXF layers which include spaces in their names. it fails during the SQL create table step. Is there a lib fn to SQL-proof layer names? (eg v.in.ascii, v.in.ogr space -> underscore) thanks, Hamish -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Fri Feb 2 06:40:34 2007 From: grass-bugs at intevation.de (Request Tracker) Date: Fri Feb 2 06:40:37 2007 Subject: [GRASS-dev] [bug #5464] (grass) libdal .so.1 error Message-ID: <20070202054034.C72F51005C4@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5464 ------------------------------------------------------------------------- Subject: libdal .so.1 error Platform: GNU/Linux/x86 grass obtained from: Trento Italy site grass binary for platform: Compiled from Sources GRASS Version: 6.2.1 dear sir >> i would like to inform u my errors when installing grass 6 , after i create progect ,location ,mapset , and when i want to enter grass the window of grass appear for short time and closed and give the massege of error , that libgdal so.1 , no such directory that mean error in vector project please tell me what shall i do to over take this problem , and finally my Thanks for u . ayad ali faris ph.d. student osmania University ,Hyderabad , India email : ayadfaris@yahoo.com -------------------------------------------- Managed by Request Tracker From glynn at gclements.plus.com Fri Feb 2 07:08:04 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Feb 2 07:11:50 2007 Subject: New --script flag was: Re: [GRASS-dev] how to display a vector map for d.path in gis.m? In-Reply-To: References: <45C0952E.4010306@itc.it> Message-ID: <17858.54596.123846.962875@cerise.gclements.plus.com> Michael Barton wrote: > >>> Hmm; it might be useful to have some means of automatically generating > >>> the corresponding g.parser description for a given command. There are > >>> probably quite a few scripts whose options are (almost) identical to > >>> an existing command. I'll look into it. > >>> > >> > >> I've extended G_parser() with a --script flag, which writes out a > >> script with g.parser syntax to mimic the behaviour of the module. This > >> shoud make it easier to write scripts which mimic an existing command. > >> > > Really cool! Thanks, Glynn. > > Could you explain how this works a bit more? It sounds cool, but I don't > quite understand how it might be used. Taking d.path as an example, you would first run e.g.: d.path --script > d.path.sh This will generate a script which contains the g.parser boilerplate which would be required for a script with the same set of options as d.path. To this script, you would append something like the following: cmd=d.path if [ "$GIS_FLAG_G" != 0 ] ; then cmd="$cmd -g" ; fi if [ "$GIS_OPT_MAP" != "" ] ; then cmd="$cmd map=$GIS_OPT_MAP" ; fi if [ "$GIS_OPT_TYPE" != "" ] ; then cmd="$cmd type=$GIS_OPT_TYPE" ; fi if [ "$GIS_OPT_ALAYER" != "" ] ; then cmd="$cmd alayer=$GIS_OPT_ALAYER" ; fi if [ "$GIS_OPT_NLAYER" != "" ] ; then cmd="$cmd nlayer=$GIS_OPT_NLAYER" ; fi if [ "$GIS_OPT_AFCOL" != "" ] ; then cmd="$cmd afcol=$GIS_OPT_AFCOL" ; fi if [ "$GIS_OPT_ABCOL" != "" ] ; then cmd="$cmd abcol=$GIS_OPT_ABCOL" ; fi if [ "$GIS_OPT_NCOL" != "" ] ; then cmd="$cmd ncol=$GIS_OPT_NCOL" ; fi if [ "$GIS_OPT_COLOR" != "" ] ; then cmd="$cmd color=$GIS_OPT_COLOR" ; fi if [ "$GIS_OPT_HCOLOR" != "" ] ; then cmd="$cmd hcolor=$GIS_OPT_HCOLOR" ; fi if [ "$GIS_OPT_BGCOLOR" != "" ] ; then cmd="$cmd bgcolor=$GIS_OPT_BGCOLOR" ; fi d.vect "$GIS_OPT_MAP" exec $cmd This script should run "d.vect ", then run d.path with whatever options were passed to the d.path.sh script. Essentially, if you want to write a script which behaves like some existing command, the --script option can be used to avoid having to type out the g.parser boilerplate by hand. -- Glynn Clements From michael.barton at asu.edu Fri Feb 2 07:13:52 2007 From: michael.barton at asu.edu (Michael Barton) Date: Fri Feb 2 07:14:05 2007 Subject: New --script flag was: Re: [GRASS-dev] how to display a vector map for d.path in gis.m? In-Reply-To: <17858.54596.123846.962875@cerise.gclements.plus.com> Message-ID: Thanks for the explanation. Michael On 2/1/07 11:08 PM, "Glynn Clements" wrote: > > Michael Barton wrote: > >>>>> Hmm; it might be useful to have some means of automatically generating >>>>> the corresponding g.parser description for a given command. There are >>>>> probably quite a few scripts whose options are (almost) identical to >>>>> an existing command. I'll look into it. >>>>> >>>> >>>> I've extended G_parser() with a --script flag, which writes out a >>>> script with g.parser syntax to mimic the behaviour of the module. This >>>> shoud make it easier to write scripts which mimic an existing command. >>>> >>> Really cool! Thanks, Glynn. >> >> Could you explain how this works a bit more? It sounds cool, but I don't >> quite understand how it might be used. > > Taking d.path as an example, you would first run e.g.: > > d.path --script > d.path.sh > > This will generate a script which contains the g.parser boilerplate > which would be required for a script with the same set of options as > d.path. > > To this script, you would append something like the following: > > cmd=d.path > if [ "$GIS_FLAG_G" != 0 ] ; then cmd="$cmd -g" ; fi > if [ "$GIS_OPT_MAP" != "" ] ; then cmd="$cmd map=$GIS_OPT_MAP" ; fi > if [ "$GIS_OPT_TYPE" != "" ] ; then cmd="$cmd type=$GIS_OPT_TYPE" ; fi > if [ "$GIS_OPT_ALAYER" != "" ] ; then cmd="$cmd alayer=$GIS_OPT_ALAYER" ; fi > if [ "$GIS_OPT_NLAYER" != "" ] ; then cmd="$cmd nlayer=$GIS_OPT_NLAYER" ; fi > if [ "$GIS_OPT_AFCOL" != "" ] ; then cmd="$cmd afcol=$GIS_OPT_AFCOL" ; fi > if [ "$GIS_OPT_ABCOL" != "" ] ; then cmd="$cmd abcol=$GIS_OPT_ABCOL" ; fi > if [ "$GIS_OPT_NCOL" != "" ] ; then cmd="$cmd ncol=$GIS_OPT_NCOL" ; fi > if [ "$GIS_OPT_COLOR" != "" ] ; then cmd="$cmd color=$GIS_OPT_COLOR" ; fi > if [ "$GIS_OPT_HCOLOR" != "" ] ; then cmd="$cmd hcolor=$GIS_OPT_HCOLOR" ; fi > if [ "$GIS_OPT_BGCOLOR" != "" ] ; then cmd="$cmd bgcolor=$GIS_OPT_BGCOLOR" ; > fi > d.vect "$GIS_OPT_MAP" > exec $cmd > > This script should run "d.vect ", then run d.path with whatever > options were passed to the d.path.sh script. > > Essentially, if you want to write a script which behaves like some > existing command, the --script option can be used to avoid having to > type out the g.parser boilerplate by hand. __________________________________________ 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 Fri Feb 2 10:52:37 2007 From: jachym.cepicky at centrum.cz (=?ISO-8859-2?Q?J=E1chym_=C8epick=FD?=) Date: Fri Feb 2 10:52:40 2007 Subject: [GRASS-dev] Re: Wxgrass status update In-Reply-To: References: Message-ID: Hi, 2007/2/1, Michael Barton : > > 2. There is already stuff on the cvs, so we need to coordinate with the main > cvs site too. Since I started to rewrite the files from scratch, I just wanted to have the work in separate repository, until it is mature enough to be copied in the CVS. The new concept should also make it easier possible to split the work between more people (I hope at least). I tried to start to write some documentation in the wiki [1] with some proposals. j [1] http://grass.gdf-hannover.de/wiki/GRASS_GUI#wxPython_GUI -- Jachym Cepicky e-mail: jachym.cepicky gmail com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub From neteler at itc.it Fri Feb 2 11:07:54 2007 From: neteler at itc.it (Markus Neteler) Date: Fri Feb 2 11:07:56 2007 Subject: [GRASS-dev] [bug #5463] (grass) v.in.dxf support for spaces in layer names In-Reply-To: <20070202043237.E32F01006B3@lists.intevation.de> References: <20070202043237.E32F01006B3@lists.intevation.de> Message-ID: <45C30D7A.30406@itc.it> Request Tracker wrote on 02/02/2007 05:32 AM: > this bug's URL: http://intevation.de/rt/webrt?serial_num=5463 > ------------------------------------------------------------------------- > > Subject: v.in.dxf support for spaces in layer names > > v.in.dxf fails to load in DXF layers which include spaces in their names. > > it fails during the SQL create table step. > > Is there a lib fn to SQL-proof layer names? (eg v.in.ascii, v.in.ogr space -> > underscore) > See main.c of v.in.ogr, around line 586. That part might be moved up to library level. Markus From jachym.cepicky at centrum.cz Fri Feb 2 11:51:36 2007 From: jachym.cepicky at centrum.cz (=?ISO-8859-2?Q?J=E1chym_=C8epick=FD?=) Date: Fri Feb 2 11:51:46 2007 Subject: [GRASS-dev] Re: Wxgrass status update In-Reply-To: References: Message-ID: hi Michael, 2007/2/1, Michael Barton : > Jachym, > > I did a quick glance and it looks like it will make working with display > layers much easier. Options panels can use these classes to define how > layers should be displayed. > > Somewhere we'll need to wrap this code into the integrated application. This > module is called render.py in my version--the one that I proposed renaming. > Maybe disputil.py would make more sense in the long run. I'm not sure yet > how much we should split up different functions into distinct smaller > modules and how much they should be expressed as classes in included in > larger modules. > > As we go along, we should keep trying to refactor like you've done here, and > produce clean code that will be easier to maintain in the future. I've > become acutely aware of this after untangling a lot of ancient TclTk > spaghetti code (some of it not so ancient and mine). > > Cheers > Michael If you don't mind, I would start over the weekend or on Monday to rewrite mapdispl.py, so it uses new mapimg.py (maybe it should be renamed to maprender.py?). Jachym > On 2/1/07 1:45 AM, "J?chym ?epick?" wrote: > > > hi Michael, it is good, that you are back! > > > > > > > > 2007/2/1, Michael Barton : > >> > >> Jachym, > >> > >> I'm actually working with wx.Python again. Thank goodness it is starting to > >> come back to me after a 5 month hiatus. I decided to just focus on the > >> mundane tasks of the layer manager. This is good practice for me and pretty > >> straightforward in many respects, though sufficiently challenging (ie., > >> difficult) that progress remains slow--for me at least. And I've only got > >> bits and pieces of time to devote to this at the moment. > >> > >> What I've got now is a wx.Choicebook with a page for each display opened. > >> On that page is a wx.Notebook with a layer tree (at least theoretically > >> since I'm still trying to make it work) notebook page and a command console > >> notebook page. Each layer (i.e., node in the tree) will need a way to > >> indicate the name of the map in the layer, some indication (e.g., an icon) > >> of whether it is raster or vector (or something else), a way to make the > >> layer active/inactive, and some way to call up a panel to set the display > >> options for the layer. It looks like wx.CustomTreeCtrl will work quite well > >> for this. Once I get that far, I'll put it up on the cvs so that anyone can > >> play with it. If you'd like to see where I'm at any time, just let me know > >> and I'll send you some files. > >> > >> One other thing is that the render.py module has become a handy place to > >> stash a few methods to track open displays, related variables, and the like > >> so that they don't instantiate new displays or control panels when > >> called--along with other display rendering functions. If it continues to > >> serve in this way, do you think we should rename it to something like > >> mapfunct.py or multifunct.py??? > >> > >> Just wanted to bring you up to date. Hope your trip is going well. > >> > >> Cheers > >> 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 > >> > >> > > > > I started to define new set of classes, which should be easy to use > > and more logical orderd. > > > > Please look at the > > https://grasssvn.itc.it/grasssvn/grassaddons/trunk/grassaddons/gui/#_trunk_gra > > ssaddons_gui_ > > > > you can test it with > > > > python mapimg.py > > > > and see the documentation with > > > > pydoc ./mapimg.py > > > > How to work with it, look at the end of mapimg.py > > > > Idea is, that each Map has defined set of layers (rasters, vectors, > > graphs, WMS, WCS, ...). This set of layers should be taken over by > > each Display. > > > > Let me know, if you like it > > > > I moved the work to grasssvn-addons repository, because this are all > > fresh ideas and the code is not mature yet. Ones we have basic working > > GUI, we shoul reorganize gui/wxpython directory. subversion anables us > > to rename the files and so on. > > > > I hope, you like it > > > > Jachym > > > > P.S. I Sent this e-mail in a copy to Martin Landa - second GUI developer. > > __________________________________________ > 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 gmail com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub From jachym.cepicky at gmail.com Fri Feb 2 15:42:50 2007 From: jachym.cepicky at gmail.com (=?ISO-8859-2?Q?J=E1chym_=C8epick=FD?=) Date: Fri Feb 2 15:42:53 2007 Subject: [GRASS-dev] G_legal_filename and "/" Message-ID: Hi, IMHO "/" character is legal character in file name. I suggest change line 43 in lib/gis/legal_filename.c: - if (*s == '/' || *s == '"' || *s == '\'' || *s <= ' ' || + if (*s == '"' || *s == '\'' || *s <= ' ' || What do you think? Jachym -- Jachym Cepicky e-mail: jachym.cepicky gmail com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub From grass-bugs at intevation.de Fri Feb 2 16:56:20 2007 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Fri Feb 2 16:56:22 2007 Subject: [GRASS-dev] [bug #5462] (grass) GRASS should support exporting E00 Message-ID: <20070202155620.EFCF51005C7@lists.intevation.de> guest wrote (Fri, Feb 2 2007 03:31:25): > It is possible that GRASS will be support v.out.e00 in the next > version.Infact, I am using both arc/info and grass, So, I demand GRASS > version 6.0 supporting export e.00 format (V.out.e00), because I can > exchange GIS data between agencies in Thailand that mostly use arc/info. I suppose that the best way to go, and most likely to succeed, would be to ask for (even better - fund) the support for writing E00 in GDAL/OGR library http://www.gdal.org/ogr/, which GRASS uses for vector import/export. Then a wide variety of FOSS GIS, including GRASS, could use this functionality. Note that GDAL 1.4.0 already supports E00 for reading. See: http://www.gdal.org/NEWS.html Maciek -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Fri Feb 2 17:24:43 2007 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Fri Feb 2 17:24:45 2007 Subject: [GRASS-dev] [bug #5454] (grass) projection units incorrectly pluralized Message-ID: <20070202162443.B797E1005CC@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5454 Request number 5454 was commented on by 'msieczka' (Maciek Sieczka). Responding to this message will send mail to the requestor. Request Tracker rt@intevation.de -------------------------------------------------------------- Cc: grass-dev@grass.itc.it hbowman wrote (Tue, Jan 30 2007 08:01:04): > "foots" problem happens when location was created from EPSG code, "g.proj -c". I have tried to reproduce the error, but I'm not able to create a location from the 2258 EPSG code in question. After I enter a new location name, the 2258 code, and press 'Define location' gui freezes and I have to "kill -9" it. Location is not created. This does not happen with other (metric) projections I tried. Maciek -------------------------------------------- Managed by Request Tracker From jachym.cepicky at gmail.com Fri Feb 2 17:24:39 2007 From: jachym.cepicky at gmail.com (=?ISO-8859-2?Q?J=E1chym_=C8epick=FD?=) Date: Fri Feb 2 17:24:48 2007 Subject: [GRASS-dev] Re: python gis manager concept In-Reply-To: References: Message-ID: hi, 2007/2/2, Michael Barton : > Jachym, > > I like the concept and it is close to what I've been doing. I've attached a > screenshot of it. The main difference is that after consideration, I made > the choicebook (varient of notebook) for the display at the top of the > hierarchy and added a notebook with tree controls and console for a display > to each page. This seems easier to track controls for each display. My > earlier version looked more like yours. One nice thing about using a choice > book is that you don't have to worry about space for tabs as you add more > pages (i.e., displays). I like the idea to have direct access to each monitor. Yours approach means that you have the double click - first at the choice book and than at the desired monitor... I would prefer the panel approach also because you can add "x" (close) button to the top of each panel. Maybe this is a topic for GRASS survey? > > I like the idea of a command line at the bottom. This should make a lot of > people happy too. I added your screenshot to the wiki [1] , so we can compare side-by-side each proposal and maybe piece the best peaces from all together. Jachym [1] http://grass.gdf-hannover.de/wiki/GRASS_GUI#Screenshots_with_proposed_shapes > On 2/1/07 8:31 AM, "J?chym ?epick?" wrote: > > > Hi, > > > > things are movig slowly forward. As you might know, I started to write > > some low-level code for rednering raster, vector, graph, wms, ..., > > layers into map image. The code is avaliable in GRASSSVN-Addons > > repository [1]. > > > > I started also to think about the GIS-Manager concept. I prepared some > > "preview" using wxglade (this is not the best tool thought) - you can > > open the file gism.wxg (attached) in wxglade and play with it a bit. I > > send also the screenshot of this try attached to this e-mail. > > > > In this version of gism, menubar and tool bar are missing - this is > > not intention. What I wanted to present with this is the notebook > > concept -- each display has it's own notebook panel in which the > > layer tree is stored. > > > > On the bottom of gismanager, GRASS command line is ready for quick usage. > > > > What do you think about this concept? Please feel free to redesign > > this proposal and share your ideas. > > > > I think, we should stop for a while to code and start to discuss about > > the future design. The current Tcl/Tk gis manager has shown many > > things and we should think about it's design for a while, before we > > start to rewrite it using python. > > > > Looking forward to your comments > > > > Jachym > > > > [1] > > https://grasssvn.itc.it/grasssvn/grassaddons/trunk/grassaddons/gui/#_trunk_gra > > ssaddons_gui_ > > __________________________________________ > 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 gmail com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub From landa.martin at gmail.com Fri Feb 2 17:35:19 2007 From: landa.martin at gmail.com (Martin Landa) Date: Fri Feb 2 17:35:22 2007 Subject: [GRASS-dev] implementing drop column into DBF driver In-Reply-To: <20061204163327.GC25728@bartok.itc.it> References: <20061204163327.GC25728@bartok.itc.it> Message-ID: Hi, I have tried to solve this problem. I think in a very ugly way, but it seems to work (see the attached patch). Regards, Martin 2006/12/4, Markus Neteler : > Hi, > > I tried to implement drop column into DBF driver to get > rid of columns like 'cat_' when re-importing an exported map: > echo "ALTER TABLE mymap DROP COLUMN cat_" | db.execute > > Attached the changes to lib/db/sqlp/ and /db/drivers/dbf/ > > The idea is to load the table internally in SQLP_DROP_COLUMN > (such as SQLP_ADD_COLUMN does) but to jump over the column > which we want to drop. > So I took load_table() and made it load_table_selective(), > most likely in an ugly way. > > While ugly, it could work but apparently I never reach > SQLP_DROP_COLUMN. It bails out with > > ... > D3/3: sql: ALTER TABLE mymap DROP COLUMN cat_ > D3/3: SQL statement parsed successfully: ALTER TABLE mymap DROP COLUMN cat_ > ... > D3/3: add_column(): tab = 11, type = 3, name = edg_id, width = 20, decimals = 6 > D3/3: Doing SQL command <8> on DBF table... (see include/sqlp.h) > dbmi: Protocol error > D2/3: G__home home = /home/neteler > ERROR: Error while executing: "ALTER TABLE mymap DROP COLUMN cat_ > " > > I have no clue why. Help is welcome. > > Thanks, > Markus > > > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > > > -- Martin Landa * http://gama.fsv.cvut.cz/~landa * -------------- next part -------------- A non-text attachment was scrubbed... Name: dbf-drop-col-3.diff.gz Type: application/x-gzip Size: 2060 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070202/84ce75e4/dbf-drop-col-3.diff-0001.gz From michael.barton at asu.edu Fri Feb 2 18:14:56 2007 From: michael.barton at asu.edu (Michael Barton) Date: Fri Feb 2 18:15:00 2007 Subject: [GRASS-dev] FW: python gis manager concept In-Reply-To: Message-ID: Forgot to copy the developer list on this. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton ------ Forwarded Message > From: Michael Barton > Date: Fri, 02 Feb 2007 09:46:52 -0700 > To: J?chym ?epick? > Conversation: python gis manager concept > Subject: Re: python gis manager concept > > Jachym, > > If it helps, I've got events set so that clicking on any display will > automatically bring up it's choicebook page. Selecting a choicebook page will > also automatically select the appropriate display. > > The notebook tab works just as well as a choicebook pull-down, with a little > less effort as you point out. They function exactly the same, except for the > interface (tabs vs. pulldown) for selecting a page. My only concern that > prompted the choicebook was the space needed for tabs when multiple displays > are opened. But realistically, most people probably won't open more than 2-3 > monitors at most. > > I put the notebook page tabs (for layer or console control) on the side so as > to keep them physically separated from the interface for selecting the > display--for better visibility, maybe reducing control 'clutter' a bit, and to > aid clumsy clickers. They could go on top if it works better. > > I could easily go either way. It only takes changing one word in the line to > start it (wx.Notebook <-> wx.Choicebook) to change it around--a nice part of > working with wx.Python. > > Michael > > > On 2/2/07 9:24 AM, "J?chym ?epick?" wrote: > >> hi, 2007/2/2, Michael Barton : > Jachym, > > I like >> the concept and it is close to what I've been doing. I've attached a > >> screenshot of it. The main difference is that after consideration, I made > >> the choicebook (varient of notebook) for the display at the top of the > >> hierarchy and added a notebook with tree controls and console for a display > >> to each page. This seems easier to track controls for each display. My > >> earlier version looked more like yours. One nice thing about using a choice > >> book is that you don't have to worry about space for tabs as you add more > >> pages (i.e., displays). I like the idea to have direct access to each >> monitor. Yours approach means that you have the double click - first at the >> choice book and than at the desired monitor... I would prefer the panel >> approach also because you can add "x" (close) button to the top of each >> panel. Maybe this is a topic for GRASS survey? > > I like the idea of a >> command line at the bottom. This should make a lot of > people happy too. I >> added your screenshot to the wiki [1] , so we can compare side-by-side each >> proposal and maybe piece the best peaces from all together. Jachym [1] >> http://grass.gdf-hannover.de/wiki/GRASS_GUI#Screenshots_with_proposed_shapes >> >>> On 2/1/07 8:31 AM, "J?chym ?epick?" wrote: > > > >> Hi, > > > > things are movig slowly forward. As you might know, I started to >> write > > some low-level code for rednering raster, vector, graph, wms, >> ..., > >>> layers into map image. The code is avaliable in GRASSSVN-Addons > > >> repository [1]. > > > > I started also to think about the GIS-Manager >> concept. >> I prepared some > > "preview" using wxglade (this is not the best tool >> thought) - you can > > open the file gism.wxg (attached) in wxglade and play >> with it a bit. I > > send also the screenshot of this try attached to this >> e-mail. > > > > In this version of gism, menubar and tool bar are missing - >> this is > > not intention. What I wanted to present with this is the >> notebook > > concept -- each display has it's own notebook panel in which >> the > > layer tree is stored. > > > > On the bottom of gismanager, GRASS >> command line is ready for quick usage. > > > > What do you think about this >> concept? Please feel free to redesign > > this proposal and share your >> ideas. > > > > I think, we should stop for a while to code and start to >> discuss about > > the future design. The current Tcl/Tk gis manager has shown >> many > > things and we should think about it's design for a while, before >> we > >>> start to rewrite it using python. > > > > Looking forward to your comments > >>> > > Jachym > > > > [1] > > >> https://grasssvn.itc.it/grasssvn/grassaddons/trunk/grassaddons/gui/#_trunk_gr>> a >> > > ssaddons_gui_ > > __________________________________________ > 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 gmail com URL: http://les-ejk.cz GPG: >> http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub > > __________________________________________ > 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 ------ End of Forwarded Message From grass-bugs at intevation.de Fri Feb 2 18:23:53 2007 From: grass-bugs at intevation.de (Paul Kelly via RT) Date: Fri Feb 2 18:23:54 2007 Subject: [GRASS-dev] [bug #5454] (grass) projection units incorrectly pluralized Message-ID: <20070202172353.2A8D21005C7@lists.intevation.de> I have fixed the "foots" bug now; see http://grass.itc.it/pipermail/grass-commit/2007-January/026497.html I will commit a temporary solution to the GUI freezing problem (changing g.proj so it won't prompt for the datum info unless you ask it to be interactive) shortly. -------------------------------------------- Managed by Request Tracker From neteler at itc.it Fri Feb 2 21:19:28 2007 From: neteler at itc.it (Markus Neteler) Date: Fri Feb 2 21:19:30 2007 Subject: [GRASS-dev] d.rgb and d.zoom Message-ID: <20070202201928.GA14273@bartok.itc.it> Hi, would it be possible to change something so that d.zoom also understands if only d.rgb was used in the monitor? Markus From neteler at itc.it Fri Feb 2 23:08:54 2007 From: neteler at itc.it (Markus Neteler) Date: Fri Feb 2 23:09:06 2007 Subject: [GRASS-dev] implementing drop column into DBF driver In-Reply-To: References: <20061204163327.GC25728@bartok.itc.it> Message-ID: <20070202220854.GA16915@bartok.itc.it> Martin, nice, I have tested it successfully (DBF driver). Also written v.db.dropcol and tested that with DBF and PG driver. Once you changes are in CVS, I'll submit v.db.dropcol. Still it would be good to have more people testing the proposed patch. Thanks Markus On Fri, Feb 02, 2007 at 05:35:19PM +0100, Martin Landa wrote: > Hi, > > I have tried to solve this problem. I think in a very ugly way, but it > seems to work (see the attached patch). > > Regards, Martin > > 2006/12/4, Markus Neteler : > >Hi, > > > >I tried to implement drop column into DBF driver to get > >rid of columns like 'cat_' when re-importing an exported map: > >echo "ALTER TABLE mymap DROP COLUMN cat_" | db.execute > > > >Attached the changes to lib/db/sqlp/ and /db/drivers/dbf/ > > > >The idea is to load the table internally in SQLP_DROP_COLUMN > >(such as SQLP_ADD_COLUMN does) but to jump over the column > >which we want to drop. > >So I took load_table() and made it load_table_selective(), > >most likely in an ugly way. > > > >While ugly, it could work but apparently I never reach > >SQLP_DROP_COLUMN. It bails out with > > > >... > >D3/3: sql: ALTER TABLE mymap DROP COLUMN cat_ > >D3/3: SQL statement parsed successfully: ALTER TABLE mymap DROP COLUMN cat_ > >... > >D3/3: add_column(): tab = 11, type = 3, name = edg_id, width = 20, > >decimals = 6 > >D3/3: Doing SQL command <8> on DBF table... (see include/sqlp.h) > >dbmi: Protocol error > >D2/3: G__home home = /home/neteler > >ERROR: Error while executing: "ALTER TABLE mymap DROP COLUMN cat_ > > " > > > >I have no clue why. Help is welcome. > > > >Thanks, > >Markus From glynn at gclements.plus.com Sat Feb 3 03:59:53 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Feb 3 04:00:00 2007 Subject: [GRASS-dev] G_legal_filename and "/" In-Reply-To: References: Message-ID: <17859.64169.743115.453979@cerise.gclements.plus.com> J-B?chym ?epick? wrote:-A > IMHO "/" character is legal character in file name. I suggest change > line 43 in lib/gis/legal_filename.c: > > > - if (*s == '/' || *s == '"' || *s == '\'' || *s <= ' ' || > > + if (*s == '"' || *s == '\'' || *s <= ' ' || > > What do you think? No, "/" most definitely isn't a legal character in a filename, as it's used as a directory separator on all supported platforms. It's legal in a *pathname*, but that isn't what G_legal_filename() is meant for. -- Glynn Clements From glynn at gclements.plus.com Sat Feb 3 04:11:56 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Feb 3 04:11:58 2007 Subject: [GRASS-dev] d.rgb and d.zoom In-Reply-To: <20070202201928.GA14273@bartok.itc.it> References: <20070202201928.GA14273@bartok.itc.it> Message-ID: <17859.64892.614885.382959@cerise.gclements.plus.com> Markus Neteler wrote: > would it be possible to change something so that > d.zoom also understands if only d.rgb was used > in the monitor? d.zoom/redraw.c should have an option to use d.redraw to redraw the display. It's arguable that should be the *only* option (i.e. no rast= or vector= options). -- Glynn Clements From jachym.cepicky at gmail.com Sat Feb 3 15:29:47 2007 From: jachym.cepicky at gmail.com (=?ISO-8859-2?Q?J=E1chym_=C8epick=FD?=) Date: Sat Feb 3 15:29:51 2007 Subject: [GRASS-dev] G_legal_filename and "/" In-Reply-To: <17859.64169.743115.453979@cerise.gclements.plus.com> References: <17859.64169.743115.453979@cerise.gclements.plus.com> Message-ID: hi Glynn, 2007/2/3, Glynn Clements : > > J-B?chym ?epick? wrote:-A > > > IMHO "/" character is legal character in file name. I suggest change > > line 43 in lib/gis/legal_filename.c: > > > > > > - if (*s == '/' || *s == '"' || *s == '\'' || *s <= ' ' || > > > > + if (*s == '"' || *s == '\'' || *s <= ' ' || > > > > What do you think? > > No, "/" most definitely isn't a legal character in a filename, as it's > used as a directory separator on all supported platforms. It's legal > in a *pathname*, but that isn't what G_legal_filename() is meant for. > > -- > Glynn Clements > While using g.pnmcomp with output file specified by full path (e.g. "/tmp/out.png"), I get the warning about Illegal character in file name. How to avoid this problem? Thanks Jachym -- Jachym Cepicky e-mail: jachym.cepicky gmail com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub From glynn at gclements.plus.com Sun Feb 4 04:17:02 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Feb 4 04:17:12 2007 Subject: [GRASS-dev] G_legal_filename and "/" In-Reply-To: References: <17859.64169.743115.453979@cerise.gclements.plus.com> Message-ID: <17861.20526.722927.60060@cerise.gclements.plus.com> J-B?chym ?epick? wrote:-A > > > IMHO "/" character is legal character in file name. I suggest change > > > line 43 in lib/gis/legal_filename.c: > > > > > > > > > - if (*s == '/' || *s == '"' || *s == '\'' || *s <= ' ' || > > > > > > + if (*s == '"' || *s == '\'' || *s <= ' ' || > > > > > > What do you think? > > > > No, "/" most definitely isn't a legal character in a filename, as it's > > used as a directory separator on all supported platforms. It's legal > > in a *pathname*, but that isn't what G_legal_filename() is meant for. > > While using g.pnmcomp with output file specified by full path (e.g. > "/tmp/out.png"), I get the warning about Illegal character in file > name. That's because I added bogus "gisprompt" definitions to the output= and outmask= options, so the parser thinks that these options are supposed to be map names. Fixed in CVS. -- Glynn Clements From grass-bugs at intevation.de Sun Feb 4 11:55:49 2007 From: grass-bugs at intevation.de (Request Tracker) Date: Sun Feb 4 11:55:51 2007 Subject: [GRASS-dev] [bug #5470] (grass) Version of the Networking Guide with me, while Message-ID: <20070204105549.697181005C7@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5470 ------------------------------------------------------------------------- as the apparent winner the philosophy of the Bush administration would hurt= the school's reputation. Wednesday, SMU President R. Gerald think tank ded= icated tobenefits were increasing the University to stop trying to land Geo= rge W. Bush's presidential library. of social conscience, so York, who grad= uated from an online petition drive Thursdayministers fromopposed Bush's f= oreign Wednesday, SMU President R. Gerald in the library competition polic= y, mainly the war in Iraq. This exciting stocks right for your business! It will aid you to feel the top of market!!! No more doubts like =93and what if I lose my=94 money=85=94 MARSHAL HOLDINGS INC(MHII.OB) EXAMINED stock!!! Exactly 300% of your success on markets of shares Watch chart that we included and don=92t waste time!!! DAtE Price 01.30.07 0.02$ 02.05.07 0.07$ You can get more information using your broker web-site! WARNING: It is impossible to BUY this amazing stock via online brokers site= PLEASE call up YOUR broker AND MAKE your order. GET this amazing stock on= MONDAY!!! on a newly createdSMU emerged ministers from a university bearing the Meth= odist name is utterly inappropriate."ministers fromare very concerning," sa= id onenot return calls seeking comment Thursday."Methodists of his presiden= cy with a university bearing the Methodist name is utterly inappropriate."S= MU officials did have Turner said those fears were unfounded. with just = SMU, the 11,000-student, private university, which is first lady Laura Bush= 's alma mater.will be financed with a on a newly createdwill be financed w= ith a Wednesday, SMU President R. Gerald an online petition drive Thursday --- Headers Follow --- >From hereiam_lord@juno.com Sun Feb 4 11:55:49 2007 Return-Path: Delivered-To: grass-bugs@lists.intevation.de Received: from kolab.intevation.de (salmakis.hq.intevation.de [192.168.11.9]) by lists.intevation.de (Postfix) with ESMTP id 471901005C5 for ; Sun, 4 Feb 2007 11:55:49 +0100 (CET) Received: from localhost (localhost.localdomain [127.0.0.1]) by kolab.intevation.de (Postfix) with ESMTP id 2EE99108ECA for ; Sun, 4 Feb 2007 11:55:49 +0100 (CET) Received: from localhost (localhost.localdomain [127.0.0.1]) by kolab.intevation.de (Postfix) with ESMTP id 1718C108EE5 for ; Sun, 4 Feb 2007 11:55:49 +0100 (CET) Received: from COMP1 (158.136.pppoe.mari-el.ru [217.106.136.158]) by kolab.intevation.de (Postfix) with ESMTP id 50148108ECA for ; Sun, 4 Feb 2007 11:55:48 +0100 (CET) Received: from 64.136.20.83 (HELO mx.nyc.untd.com) by intevation.de with esmtp (Y,9VS=O@* LCW<)-) id (WU2*D-,@*JT.-W3 for grass-bugs@intevation.de; Sun, 4 Feb 2007 10:55:57 -0180 Date: Sun, 4 Feb 2007 10:55:57 -0180 From: MarkMaureen X-Mailer: The Bat! (v2.10.01) Personal X-Priority: 3 (Normal) Message-ID: <997524257.77589197679177@thebat.net> To: grass-bugs@intevation.de Subject: Version of the Networking Guide with me, while MIME-Version: 1.0 Content-Type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: quoted-printable X-Spam: Not detected X-Virus-Scanned: by amavisd-new at intevation.de X-Spam-Status: No, hits=1.692 tagged_above=-999 required=3 tests=[BAYES_50=0.9, FORGED_JUNO_RCVD=0.792] X-Spam-Level: * -------------------------------------------- Managed by Request Tracker From twiens at interbaun.com Sun Feb 4 15:50:45 2007 From: twiens at interbaun.com (Trevor Wiens) Date: Sun Feb 4 15:47:47 2007 Subject: [GRASS-dev] Re: python gis manager concept In-Reply-To: References: Message-ID: <20070204075045.6cd79eb1@localhost.localdomain> On Fri, 2 Feb 2007 17:24:39 +0100 J?chym ?epick? wrote: --snip--- > > I added your screenshot to the wiki [1] , so we can compare > side-by-side each proposal and maybe piece the best peaces from all > together. I've added some comments to the wiki about layout and methods. > > Jachym > > [1] http://grass.gdf-hannover.de/wiki/GRASS_GUI#Screenshots_with_proposed_shapes T -- Trevor Wiens twiens@interbaun.com The significant problems that we face cannot be solved at the same level of thinking we were at when we created them. (Albert Einstein) From michael.barton at asu.edu Sun Feb 4 17:38:41 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sun Feb 4 17:42:01 2007 Subject: [GRASS-dev] [bug #5454] (grass) projection units incorrectly pluralized In-Reply-To: <20070202172353.2A8D21005C7@lists.intevation.de> Message-ID: Thanks very much Paul. This will ameliorate a problem that is especially disconcerting to users in that it generate no error messages. Michael On 2/2/07 10:23 AM, "Paul Kelly via RT" wrote: > I have fixed the "foots" bug now; see > http://grass.itc.it/pipermail/grass-commit/2007-January/026497.html > I will commit a temporary solution to the GUI freezing problem (changing > g.proj so it won't prompt for the datum info unless you ask it to be > interactive) shortly. > > -------------------------------------------- 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 grass-bugs at intevation.de Sun Feb 4 23:44:35 2007 From: grass-bugs at intevation.de (Request Tracker) Date: Sun Feb 4 23:44:36 2007 Subject: [GRASS-dev] [bug #5471] (grass) d.vect too noisy Message-ID: <20070204224435.72AA71006A9@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5471 ------------------------------------------------------------------------- Subject: d.vect too noisy G63> d.erase G63> d.rast elevation.dem G63> d.vect bugsites icon=basic/diamond col=white fcol=red WARNING: Line color and background color are the same! or G63> d.erase blue G63> d.vect bugsites icon=basic/diamond col=white fcol=red WARNING: Line color and background color are the same! If that warning needs to exist at all, it should check to see if the monitor command list is empty or there are no raster maps displayed (eg d.what.rast) before doing so. Otherwise it is unneeded noise in the terminal whenever you use the color white for something -- which may make a more important error message harder to spot. thanks, Hamish -------------------------------------------- Managed by Request Tracker From paul-grass at stjohnspoint.co.uk Mon Feb 5 02:34:59 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Mon Feb 5 02:35:17 2007 Subject: [GRASS-dev] Re: New location creation and 1x1 boundaries In-Reply-To: <421EA2D5-CE8B-4E81-B3AE-6DAE480B2058@unity.ncsu.edu> References: <20070204164007.GB4578@bartok.itc.it> <421EA2D5-CE8B-4E81-B3AE-6DAE480B2058@unity.ncsu.edu> Message-ID: Hello Helena (Cc to dev list with comments about region setting, GUI and g.region) On Sun, 4 Feb 2007, Helena Mitasova wrote: [...] > the problem with this case is that there is no tool to modify the default > window > (except for r.in.gdal -e and you need to have the right file to do it) > so you are stuck with 1x1x1 and it propagates to each new mapset when you > create it. > For old users it is OK because we all know that we need to set the region > before doing anything and if we find the 1x1x1 DEFAULT_WIND annoying > we can edit it directly or copy a properly set WIND to DEFAULT_WIND. > But for new users it can get pretty confusing. > > Probably adding an option to g.region to modify the DEFAULT_WIND when > PERMANENT is your current mapset would solve it along with a message asking > the user to do that after setting the location from EPSG, or PROJ parameters. I agree about g.region, and about the startup GUI (currently gis_set.tcl) I feel it should allow the user to set the initial region there and then. The text-based location creation (etc/set_data) does this and I think the graphical startup should too - as you said everything assumes that the default region is an attribute of the location that has been explicitly set when it was created. But as the Tcl/Tk GUI interfaces to grass using commands, I think adding an option to g.region to set the default region is a pre-requisite for this. Paul > It would be very convenient if the option included possibility to copy the > current > WIND to DEFAULT_WIND. This would be useful also for situations when the user > wants to change the DEFAULT_WIND for whatever reason (for example if he > works with many different regions and wants to have one that covers all of > them > for convenience). > > Thanks a lot for looking into this - we are finding all kinds surprising > problems > when working on the book that probably new users have to go through and that > normally do not bother us, > > Helena > From glynn at gclements.plus.com Mon Feb 5 06:40:55 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Feb 5 06:40:58 2007 Subject: [GRASS-dev] [bug #5471] (grass) d.vect too noisy In-Reply-To: <20070204224435.72AA71006A9@lists.intevation.de> References: <20070204224435.72AA71006A9@lists.intevation.de> Message-ID: <17862.50023.467921.374992@cerise.gclements.plus.com> Request Tracker wrote: > this bug's URL: http://intevation.de/rt/webrt?serial_num=5471 > ------------------------------------------------------------------------- > > Subject: d.vect too noisy > > G63> d.erase > G63> d.rast elevation.dem > G63> d.vect bugsites icon=basic/diamond col=white fcol=red > WARNING: Line color and background color are the same! > > or > > G63> d.erase blue > G63> d.vect bugsites icon=basic/diamond col=white fcol=red > WARNING: Line color and background color are the same! > > If that warning needs to exist at all, it should check to see if the monitor > command list is empty or there are no raster maps displayed (eg d.what.rast) > before doing so. That still won't catch the case where you're using the PNG driver with GRASS_BACKGROUNDCOLOR or GRASS_TRANSPARENT. There are probably other similar cases. IMHO, the warning should simply be removed. -- Glynn Clements From hamish_nospam at yahoo.com Mon Feb 5 08:06:34 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Feb 5 08:07:02 2007 Subject: [GRASS-dev] Re: [bug #5454] (grass) projection units incorrectly pluralized In-Reply-To: <20070202172353.2A8D21005C7@lists.intevation.de> References: <20070202172353.2A8D21005C7@lists.intevation.de> Message-ID: <20070205200634.7217027e.hamish_nospam@yahoo.com> Paul Kelly via RT wrote: > I have fixed the "foots" bug now; see > http://grass.itc.it/pipermail/grass-commit/2007-January/026497.html > I will commit a temporary solution to the GUI freezing problem > (changing g.proj so it won't prompt for the datum info unless you ask > it to be interactive) shortly. Idea: It would create a new epsg=code[,n] option: g.proj -c location=newLocation epsg=#### It would exit with EXIT_FAILURE if the datum transform parm is ambiguous. Here's the cunning part: "epsg=####,n" would pick param 1,2,3,.. from the list. "epsg=####,0" would print available options to stdout and exit with an EXIT_SUCCESS return code. If the EPSG code isn't found, it exits with EXIT_FAILURE. The output is in CSV or a parsable format a GUI could read & make into a nice GUI popup. Maybe with a header comment line for humans. In the GUI: - user selects create new location with EPSG code $EPSG. - gui runs "catch `g.proj epsg=$EPSG` > /dev/null" - If exit code is 0, gui creates new location with: "g.proj -c location=$LOCATION epsg=$EPSG" - If exit code is 1, gui runs: "g.proj epsg=$EPSG,0" then parses the output and creates a new GUI popup with radiobutton options generated from that. (see d.menu) (If it fails again, EPSG code is bad) Once a parm is selected and [Create] is clicked, the popup runs "g.proj -c location=$LOCATION epsg=$EPSG,$N" IMO this would be many many times better than forcing a value (you wouldn't even know better transform parms exist), and isn't a huge amount to code. Hamish From maris.gis at gmail.com Mon Feb 5 10:35:04 2007 From: maris.gis at gmail.com (Maris Nartiss) Date: Mon Feb 5 10:35:09 2007 Subject: [GRASS-dev] Re: Nviz animation wish In-Reply-To: References: <2b3d8c1c0701261142t165647f0u310857c4262464ea@mail.gmail.com> Message-ID: <2b3d8c1c0702050135r688188f4q4a7708d4c3f78fcd@mail.gmail.com> Hi Michael and others, as I wrote, some time a go I found using NVIZ animation tools too complex and ended with custom script controlling camera position, view angle and scene contents. As whole NVIZ is just a large tcl/tk script, it's not so hard to create own, similar script. Today I wonder how it's possible, that script was working, but as I have some nice animations created with that script [1], it should be working ;) So - if You are short on time to learn how to use NVIZ animation tools and not affraid from tcl code, feel free to use it for ideas. NVIZ dev's - sorry for ugly hack around Your hard work, Maris. [1] http://mpa.itc.it/markus/grass61/demos/rlake/ 2007/1/29, Michael Barton : > This discussion has been enlightening. However, it might be good to get back > to the original wish that prompted it. > > Currently, in the NVIZ animation panel, you can set key frames and NVIZ will > interpolate between the key frames to produce an on-screen animation. It > will optionally save an image sequence (as per discussion below) that can be > transformed into an animation file by 3rd party software. This is fine. > However, the only characteristics animated are the position and orientation > of the 2.5D rendering. > > What I asked was if this could be enhanced to also include the color and > other features of the rendering. That is, keyframe 1 shows the landscape > with one color drape, keyframe 2 shows it in a second color drape, and > keyframe 3 shows it in a 3rd color drape. Then when the animation is run, > you would see the landscape changing smoothly from color 1 to 2 to 3. If > desired, you would still output these to an image sequence (rather than to > an mpeg or other animation file). Similarly, could it handle something like > z-exaggeration or lighting direction? > > So, does the Togl command that drives the keyframe animation now also accept > color rendering (and other) information, or only position and orientation? > > Michael > > > -------------- next part -------------- # How it works: # 1) Create NVIZ state file; # 2) Copy surface ID that You will change (in this example it is lake with changing water level); # 3) Set camera position; # 4) Play script in NVIZ. # # This script is based on d.nviz output. I wrote it a year(?) a go and now wonder - how it is # possible that it works? # Anyway - a good beginning for creating own, custom animation script. # # Maris, 05. 02. 2007. # # NVIZ state file SendScriptLineWait "load_state_aux /some/path/to/nviz_state3" script_play puts "Starts... "; set FRAMES 264; # surf*foo is random generated when loading surface. Some normal way must exist, # currently it is copied from state file. set mhandle3 [ReturnMapHandle surf*1138896892]; # More info in source: # src/vizualisation/nviz/anim_support.c SendScriptLine "Nclear_keys" SendScriptLine "Nupdate_frames" SendScriptLine "Nset_numsteps $FRAMES" SendScriptLine "Nupdate_frames" #SendScriptLine "Nset_interp_mode linear" SendScriptLine "Nset_interp_mode spline" SendScriptLine "Nset_tension 0.1" SendScriptLine "Nupdate_frames" # Single camera position with real coordinates # position.c SendScriptLine "Nmove_to_real 584633.854316 6409321.829185 90" SendScriptLine "Nset_focus_real 573750.33564192 6401754.65674798 55" SendScriptLine "Nadd_key 1 KF_ALL_MASK 1 0.0" SendScriptLine "Nmove_to_real 591744.816528 6402709.021853 280" SendScriptLine "Nset_focus_real 573750.33564192 6401754.65674798 55" SendScriptLine "Nadd_key 2 KF_ALL_MASK 1 0.0" SendScriptLine "Nmove_to_real 590487.090928 6392080.094127 600" SendScriptLine "Nset_focus_real 573750.33564192 6401754.65674798 55" SendScriptLine "Nadd_key 3.5 KF_ALL_MASK 1 0.0" SendScriptLine "Nmove_to_real 580760.958497 6386028.557726 1000" SendScriptLine "Nset_focus_real 573750.33564192 6401754.65674798 55" SendScriptLine "Nadd_key 5.5 KF_ALL_MASK 1 0.0" SendScriptLine "Nmove_to_real 570099.802071 6387302.139704 2000" SendScriptLine "Nset_focus_real 573750.33564192 6401754.65674798 55" SendScriptLine "Nadd_key 9 KF_ALL_MASK 1 0.0" set num 0 for {set frame 1} {$frame <= $FRAMES} {incr frame} { set name frame set num2 [format "%04d" $num] append name $num2 ".ppm" # Change perspective per frame(zoom out) :) #set persp [expr ($frame * 2)+60 ] #SendScriptLine "Nchange_persp $persp" SendScriptLine "global NVIZ_BLANK_MAPS" SendScriptLine "set NVIZ_BLANK_MAPS {}" if {$frame < $FRAMES} then { ; # Maps are redrawn on evey fourth frame. if {[lsearch {} $frame] == -1} then { if {[lsearch {} $frame] > -1} then { SendScriptLine "lappend NVIZ_BLANK_MAPS [ExtractMapID $mhandle3]" } else { set foo [expr int($frame/3)+1]; # redraw every 3rd frame # list of all maps - frames. Nasty, but works :) # First - set values for displayed surface SendScriptLine "$mhandle3 set_att topo [lindex {bun_391@lake_fill bun_392@lake_fill bun_393@lake_fill } $foo]" # Then set surface color SendScriptLine "$mhandle3 set_att color [lindex {bun_391@lake_fill bun_392@lake_fill bun_393@lake_fill } $foo]" # IIRC this was surface position - I set it a bit abowe it's values, so it always is on top. SendScriptLine "$mhandle3 set_trans 0 0 [lindex {40.0 40.1 40.2} $foo]" # Last thing - set resolution. SendScriptLine "$mhandle3 set_res poly 1 1" # puts "foo: $foo frame $frame"; } } } SendScriptLine "Ndo_framestep $frame 1" #puts "Ndo_framestep $frame 1" after 1; SendScriptLine "Nwrite_ppm $name " incr num } SendScriptLine "Noff_screen 0" SendScriptLine "set ScriptPlaying 0" puts "DONE!" From hamish_nospam at yahoo.com Mon Feb 5 10:47:43 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Feb 5 10:47:53 2007 Subject: [GRASS-dev] Re: [GRASS-user] Re: v.buffer creates artefact - bug? In-Reply-To: <45C228A7.2070500@o2.pl> References: <20070130101832.20040@gmx.net> <45BF48AB.9090109@itc.it> <45BFBD29.2030908@o2.pl> <2b3d8c1c0701301444i339e0d43tf3b95e63071be3c@mail.gmail.com> <45C0D19B.8080108@o2.pl> <45C228A7.2070500@o2.pl> Message-ID: <20070205224743.25c53be1.hamish_nospam@yahoo.com> > > Hamish said it was not reproducible on his "Debian/Sarge, gcc 3.3.5, > > linux 2.4.27-3-686 on a P4". > > > > Maybe GCC version makes the difference? I'll try GCC 3 when > > possible. Maciej wrote: > So I did, gcc 3.3.6 on Ubunutu 6.06 32bit Pentium M. No good. Exactly > the same bug crops out as with gcc 4.03. > > Hamish, > Are you still not able to reproduce this? You might be holding the key > to a fix. AFAIR, we were able to isolate it to this polygon shape: # (working in Spearfish) GRASS> v.in.ascii out=ditch_1205 form=standard -n << EOF B 4 600727.68682251 5677973.32091602 600739.16582305 5678137.49568095 600736.32863997 5678140.4618269 600730.63832718 5678056.67823368 B 2 600730.63832718 5678056.67823368 600725.02385533 5677974.01131491 C 1 1 600730.04890192 5678035.56666655 1 1205 B 2 600727.68682251 5677973.32091602 600725.02385533 5677974.01131491 EOF # and then: GRASS> v.buffer ditch_1205 out=ditch_1205_b1 type=area buffer=1 GRASS> v.buffer ditch_1205 out=ditch_1205_b4 type=area buffer=4 Doing this with current CVS both ditch_1205_b1 and ditch_1205_b4 look totally normal for me. So I still can't recreate it. shrug. This probably isn't it, but I use CFLAGS="-g" to compile in debug info, which I think has the side effect of initing all memory to 0's which changes the expression of some memory bugs. -note there is another extant bug in v.buffer I do know the cause of- (but not a solution) If you have lines shaped like an "E" or an "M", the resulatant buffered area has a good chance of placing the new area's centroid very close to a line feature. One of the "is it real" tests v.buffer/main.c does is to check the distance from a centroid to the line feature, and in this case the line pokes into the middle of the area so the distance will be very small and the test returns incorrect results. Also note that Radim often suggested that v.buffer should be rewritten from scratch-- doc/vector/TODO: " v.buffer -------- Completely rewrite if possible or at least fix the bug which is probably in clean_parallel() in lib/vector/Vlib/buffer.c. " Hamish [I've little spare time to keep up with the mailing lists right now, so sorry for any delayed/missed responses; be sure bug #2765 gets updated if you find a good clue] From landa.martin at gmail.com Mon Feb 5 11:06:49 2007 From: landa.martin at gmail.com (Martin Landa) Date: Mon Feb 5 11:06:56 2007 Subject: [GRASS-dev] [bug #5471] (grass) d.vect too noisy In-Reply-To: <17862.50023.467921.374992@cerise.gclements.plus.com> References: <20070204224435.72AA71006A9@lists.intevation.de> <17862.50023.467921.374992@cerise.gclements.plus.com> Message-ID: Hi, I think it could be removed. If not I can imagine WARNING: Line color and *default* background color are the same only in *MAXLVEL* of verbosity. But I am not sure if this warning makes sense to the user. Martin 2007/2/5, Glynn Clements : > > Request Tracker wrote: > > > this bug's URL: http://intevation.de/rt/webrt?serial_num=5471 > > ------------------------------------------------------------------------- > > > > Subject: d.vect too noisy > > > > G63> d.erase > > G63> d.rast elevation.dem > > G63> d.vect bugsites icon=basic/diamond col=white fcol=red > > WARNING: Line color and background color are the same! > > > > or > > > > G63> d.erase blue > > G63> d.vect bugsites icon=basic/diamond col=white fcol=red > > WARNING: Line color and background color are the same! > > > > If that warning needs to exist at all, it should check to see if the monitor > > command list is empty or there are no raster maps displayed (eg d.what.rast) > > before doing so. > > That still won't catch the case where you're using the PNG driver with > GRASS_BACKGROUNDCOLOR or GRASS_TRANSPARENT. There are probably other > similar cases. > > IMHO, the warning should simply be removed. > > -- > Glynn Clements > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From maris.gis at gmail.com Mon Feb 5 11:07:57 2007 From: maris.gis at gmail.com (Maris Nartiss) Date: Mon Feb 5 11:08:03 2007 Subject: [GRASS-dev] Re: v.buffer creates artefact - bug? In-Reply-To: <20070205224743.25c53be1.hamish_nospam@yahoo.com> References: <20070130101832.20040@gmx.net> <45BF48AB.9090109@itc.it> <45BFBD29.2030908@o2.pl> <2b3d8c1c0701301444i339e0d43tf3b95e63071be3c@mail.gmail.com> <45C0D19B.8080108@o2.pl> <45C228A7.2070500@o2.pl> <20070205224743.25c53be1.hamish_nospam@yahoo.com> Message-ID: <2b3d8c1c0702050207x4d9b8eb9t3b4f78fa8c20773a@mail.gmail.com> Hi all, I was palying a bit with bug-trigering vector and You can see results in attachments - setting buffer to 10m will give different buffer top, setting buffer to 1 m will return more annoying result and stopping buffer process before clean is visible in third image. I also looked in v.buffer code, but my C skeelz are too lame to undrstand it, but I noticed lot of comments with "TODO" and "Should work like this". Also there is some stuff relaying on asumption, thath some stuff is listed clockwise or counterclockwise, etc. Also I was not able to create buffers for boundary, centroid. They are listed in v.buffer man page but I do not see any code related to them in v.buffer. Hope more info will help, Maris. 2007/2/5, Hamish : > > > Hamish said it was not reproducible on his "Debian/Sarge, gcc 3.3.5, > > > linux 2.4.27-3-686 on a P4". > > > > > > Maybe GCC version makes the difference? I'll try GCC 3 when > > > possible. > Maciej wrote: > > So I did, gcc 3.3.6 on Ubunutu 6.06 32bit Pentium M. No good. Exactly > > the same bug crops out as with gcc 4.03. > > > > Hamish, > > Are you still not able to reproduce this? You might be holding the key > > to a fix. > > > AFAIR, we were able to isolate it to this polygon shape: > > # (working in Spearfish) > GRASS> v.in.ascii out=ditch_1205 form=standard -n << EOF > B 4 > 600727.68682251 5677973.32091602 > 600739.16582305 5678137.49568095 > 600736.32863997 5678140.4618269 > 600730.63832718 5678056.67823368 > B 2 > 600730.63832718 5678056.67823368 > 600725.02385533 5677974.01131491 > C 1 1 > 600730.04890192 5678035.56666655 > 1 1205 > B 2 > 600727.68682251 5677973.32091602 > 600725.02385533 5677974.01131491 > EOF > > # and then: > GRASS> v.buffer ditch_1205 out=ditch_1205_b1 type=area buffer=1 > GRASS> v.buffer ditch_1205 out=ditch_1205_b4 type=area buffer=4 > > > Doing this with current CVS both ditch_1205_b1 and ditch_1205_b4 look > totally normal for me. So I still can't recreate it. shrug. > > This probably isn't it, but I use CFLAGS="-g" to compile in debug info, > which I think has the side effect of initing all memory to 0's which > changes the expression of some memory bugs. > > > > -note there is another extant bug in v.buffer I do know the cause of- > (but not a solution) > > If you have lines shaped like an "E" or an "M", the resulatant buffered > area has a good chance of placing the new area's centroid very close to > a line feature. One of the "is it real" tests v.buffer/main.c does is > to check the distance from a centroid to the line feature, and in this > case the line pokes into the middle of the area so the distance will be > very small and the test returns incorrect results. > > > Also note that Radim often suggested that v.buffer should be rewritten > from scratch-- doc/vector/TODO: > " > v.buffer > -------- > Completely rewrite if possible or at least fix the bug which is > probably in clean_parallel() in lib/vector/Vlib/buffer.c. > " > > > Hamish > > [I've little spare time to keep up with the mailing lists right now, so > sorry for any delayed/missed responses; be sure bug #2765 gets updated if > you find a good clue] > -------------- next part -------------- A non-text attachment was scrubbed... Name: vbuffer_issue_10m.png Type: image/png Size: 14688 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070205/fe7a9ba7/vbuffer_issue_10m-0001.png -------------- next part -------------- A non-text attachment was scrubbed... Name: vbuffer_issue_1m.png Type: image/png Size: 13546 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070205/fe7a9ba7/vbuffer_issue_1m-0001.png -------------- next part -------------- A non-text attachment was scrubbed... Name: vbuffer_issue_4m_clean.png Type: image/png Size: 12641 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070205/fe7a9ba7/vbuffer_issue_4m_clean-0001.png From landa.martin at gmail.com Mon Feb 5 11:52:54 2007 From: landa.martin at gmail.com (Martin Landa) Date: Mon Feb 5 11:52:55 2007 Subject: [GRASS-dev] implementing drop column into DBF driver In-Reply-To: <20070202220854.GA16915@bartok.itc.it> References: <20061204163327.GC25728@bartok.itc.it> <20070202220854.GA16915@bartok.itc.it> Message-ID: Hi Markus, the patch has been committed to CVS. It would be nice if more users test it... Best regards, Martin 2007/2/2, Markus Neteler : > Martin, > > nice, I have tested it successfully (DBF driver). > Also written v.db.dropcol and tested that with DBF and PG > driver. > > Once you changes are in CVS, I'll submit v.db.dropcol. > Still it would be good to have more people testing the > proposed patch. > > Thanks > Markus > > On Fri, Feb 02, 2007 at 05:35:19PM +0100, Martin Landa wrote: > > Hi, > > > > I have tried to solve this problem. I think in a very ugly way, but it > > seems to work (see the attached patch). > > > > Regards, Martin > > > > 2006/12/4, Markus Neteler : > > >Hi, > > > > > >I tried to implement drop column into DBF driver to get > > >rid of columns like 'cat_' when re-importing an exported map: > > >echo "ALTER TABLE mymap DROP COLUMN cat_" | db.execute > > > > > >Attached the changes to lib/db/sqlp/ and /db/drivers/dbf/ > > > > > >The idea is to load the table internally in SQLP_DROP_COLUMN > > >(such as SQLP_ADD_COLUMN does) but to jump over the column > > >which we want to drop. > > >So I took load_table() and made it load_table_selective(), > > >most likely in an ugly way. > > > > > >While ugly, it could work but apparently I never reach > > >SQLP_DROP_COLUMN. It bails out with > > > > > >... > > >D3/3: sql: ALTER TABLE mymap DROP COLUMN cat_ > > >D3/3: SQL statement parsed successfully: ALTER TABLE mymap DROP COLUMN cat_ > > >... > > >D3/3: add_column(): tab = 11, type = 3, name = edg_id, width = 20, > > >decimals = 6 > > >D3/3: Doing SQL command <8> on DBF table... (see include/sqlp.h) > > >dbmi: Protocol error > > >D2/3: G__home home = /home/neteler > > >ERROR: Error while executing: "ALTER TABLE mymap DROP COLUMN cat_ > > > " > > > > > >I have no clue why. Help is welcome. > > > > > >Thanks, > > >Markus > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From hamish_nospam at yahoo.com Mon Feb 5 12:05:51 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Feb 5 12:06:00 2007 Subject: [GRASS-dev] Re: v.buffer creates artefact - bug? In-Reply-To: <2b3d8c1c0702050207x4d9b8eb9t3b4f78fa8c20773a@mail.gmail.com> References: <20070130101832.20040@gmx.net> <45BF48AB.9090109@itc.it> <45BFBD29.2030908@o2.pl> <2b3d8c1c0701301444i339e0d43tf3b95e63071be3c@mail.gmail.com> <45C0D19B.8080108@o2.pl> <45C228A7.2070500@o2.pl> <20070205224743.25c53be1.hamish_nospam@yahoo.com> <2b3d8c1c0702050207x4d9b8eb9t3b4f78fa8c20773a@mail.gmail.com> Message-ID: <20070206000551.7ec60c22.hamish_nospam@yahoo.com> Maris Nartiss wrote: > > Also I was not able to create buffers for boundary, centroid. They are > listed in v.buffer man page but I do not see any code related to them > in v.buffer. only features with a category number will be buffered. Typically boundaries are not assigned cats. Add with v.category. for centroid try type=centroid. Hamish From neteler at itc.it Mon Feb 5 14:22:05 2007 From: neteler at itc.it (Markus Neteler) Date: Mon Feb 5 14:22:07 2007 Subject: [GRASS-dev] implementing drop column into DBF driver In-Reply-To: References: <20061204163327.GC25728@bartok.itc.it> <20070202220854.GA16915@bartok.itc.it> Message-ID: <45C72F7D.6080808@itc.it> Martin Landa wrote on 02/05/2007 11:52 AM: > Hi Markus, > > the patch has been committed to CVS. It would be nice if more users > test it... Thanks Martin and Daniel for making this possible! Markus From neteler at itc.it Mon Feb 5 14:26:47 2007 From: neteler at itc.it (Markus Neteler) Date: Mon Feb 5 14:26:49 2007 Subject: [GRASS-dev] v.db.dropcol added Message-ID: <45C73097.9000604@itc.it> Hi, thanks to the new ALTER TABLE DROP COLUMN addition for the DBF driver, I have submitted a new "v.db.dropcol" script to CVS. It includes extra code for SQLite DBs since SQLite doesn't originally support column dropping. Using "v.db.dropcol", however, you can drop columns in any GRASS table connected to a vector map. Testing obviously welcome. cheers Markus From neteler at itc.it Mon Feb 5 15:12:22 2007 From: neteler at itc.it (Markus Neteler) Date: Mon Feb 5 15:12:26 2007 Subject: [GRASS-dev] r.li (landscape indices) In-Reply-To: <20070130124544.75256f5f.hamish_nospam@yahoo.com> References: <20070130124544.75256f5f.hamish_nospam@yahoo.com> Message-ID: <45C73B46.8040903@itc.it> Hi, I would really get this one solved... we are currently updating the GRASS book (3rd edition) and it would be a pain to either not write about r.li or to have the names wrong. Hamish wrote on 01/30/2007 12:45 AM: > serena wrote: > >> If there aren't problems I'll change r.li names. >> ... >> so: >> > [including Serena's updates] > > >> r.li.contrastWeightedEdgeDensity will be r.li.cwed >> r.li.dominance will be r.li.dominance >> > > nice > > >> r.li.edgedensity will be r.li.edgedens >> > > IMO r.li.edgedensity is preferable (16 chars). > > >> r.li.meanPatchSize will be r.li.meanps >> r.li.meanPixelAttribute will be r.li.meanpa >> > > similar enough to be confusing? > what about r.li.patchsize or r.li.mps ?? > > I don't have very good ideas about the other one: > r.li.pixelatt ?? r.li.meanpixatt ?? r.li.mpa ?? > (of those I prefer r.li.mpa, ....) > > >> r.li.patchAreaDistributionCV will be r.li.padcv >> r.li.patchAreaDistributionRANGE will be r.li.padrange >> r.li.patchAreaDistributionSD will be r.li.padsd >> > > nice > > >> r.li.patchdensity will be r.li.patchdens >> > > IMO r.li.patchdensity is preferable (17 chars). > > >> r.li.patchnumber will be r.li.patchnum >> r.li.richness will be r.li.richness >> r.li.shannon will be r.li.shannon >> r.li.shape will be r.li.shape >> r.li.simpson will be r.li.simpson >> > > nice. > > >> also, because of the structure of r.li, I think is not a good idea to >> lump different modules. >> > > ok. > I mean, we can discuss this forever or just finally do it. thanks, Markus From epatton at nrcan.gc.ca Mon Feb 5 15:18:56 2007 From: epatton at nrcan.gc.ca (Patton, Eric) Date: Mon Feb 5 15:19:01 2007 Subject: [GRASS-dev] v.db.dropcol added In-Reply-To: <45C73097.9000604@itc.it> References: <45C73097.9000604@itc.it> Message-ID: This is good news - a very long-awaited feature for the db.* modules! Thanks! -- 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 Markus Neteler > Sent: Monday, February 05, 2007 9:27 AM > To: grass developers list > Subject: [GRASS-dev] v.db.dropcol added > > Hi, > > thanks to the new ALTER TABLE DROP COLUMN addition for the > DBF driver, I have submitted a new "v.db.dropcol" script to > CVS. It includes extra code for SQLite DBs since SQLite > doesn't originally support column dropping. Using > "v.db.dropcol", however, you can drop columns in any GRASS > table connected to a vector map. Testing obviously welcome. > > cheers > Markus > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > From cavallini at faunalia.it Mon Feb 5 15:24:36 2007 From: cavallini at faunalia.it (Paolo Cavallini) Date: Mon Feb 5 15:24:42 2007 Subject: [GRASS-dev] r.li (landscape indices) In-Reply-To: <45C73B46.8040903@itc.it> References: <20070130124544.75256f5f.hamish_nospam@yahoo.com> <45C73B46.8040903@itc.it> Message-ID: <45C73E24.5080804@faunalia.it> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Serena wrote me she has a new version available. Serena, could you please send it at your earliest convenience? pc Markus Neteler ha scritto: > Hi, > > I would really get this one solved... we are currently updating the > GRASS book > (3rd edition) and it would be a pain to either not write about r.li or > to have > the names wrong. > > > Hamish wrote on 01/30/2007 12:45 AM: >> serena wrote: >> >>> If there aren't problems I'll change r.li names. >>> > ... >>> so: >>> >> [including Serena's updates] >> >> >>> r.li.contrastWeightedEdgeDensity will be r.li.cwed >>> r.li.dominance will be r.li.dominance >>> >> >> nice >> >> >>> r.li.edgedensity will be r.li.edgedens >>> >> >> IMO r.li.edgedensity is preferable (16 chars). >> >> >>> r.li.meanPatchSize will be r.li.meanps >>> r.li.meanPixelAttribute will be r.li.meanpa >>> >> >> similar enough to be confusing? >> what about r.li.patchsize or r.li.mps ?? >> >> I don't have very good ideas about the other one: >> r.li.pixelatt ?? r.li.meanpixatt ?? r.li.mpa ?? >> (of those I prefer r.li.mpa, ....) >> >> >>> r.li.patchAreaDistributionCV will be r.li.padcv >>> r.li.patchAreaDistributionRANGE will be r.li.padrange >>> r.li.patchAreaDistributionSD will be r.li.padsd >>> >> >> nice >> >> >>> r.li.patchdensity will be r.li.patchdens >>> >> >> IMO r.li.patchdensity is preferable (17 chars). >> >> >>> r.li.patchnumber will be r.li.patchnum >>> r.li.richness will be r.li.richness >>> r.li.shannon will be r.li.shannon >>> r.li.shape will be r.li.shape >>> r.li.simpson will be r.li.simpson >>> >> >> nice. >> >> >>> also, because of the structure of r.li, I think is not a good idea to >>> lump different modules. - -- 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 iD8DBQFFxz4j/NedwLUzIr4RAptiAJ9r8HSq7TsOFKz8XBwwVTLslFatUgCfX8OB 1rJDKnaY4P34jezQxVjRcPk= =yogp -----END PGP SIGNATURE----- From pallecch at cli.di.unipi.it Mon Feb 5 15:28:56 2007 From: pallecch at cli.di.unipi.it (pallecch@cli.di.unipi.it) Date: Mon Feb 5 15:28:58 2007 Subject: [GRASS-dev] r.li (landscape indices) In-Reply-To: <45C73B46.8040903@itc.it> References: <20070130124544.75256f5f.hamish_nospam@yahoo.com> <45C73B46.8040903@itc.it> Message-ID: <20070205152856.z22uwzensg8ccokk@webmail.cli.di.unipi.it> ok, I'll change the names as Hamish suggests, but at this moment my pc is out of service and so I can't update r.li in the server. I can only send to you the new version of r.li. -serena- Quoting Markus Neteler : > Hi, > > I would really get this one solved... we are currently updating the > GRASS book > (3rd edition) and it would be a pain to either not write about r.li or > to have > the names wrong. > > > Hamish wrote on 01/30/2007 12:45 AM: >> serena wrote: >> >>> If there aren't problems I'll change r.li names. >>> > ... >>> so: >>> >> [including Serena's updates] >> >> >>> r.li.contrastWeightedEdgeDensity will be r.li.cwed >>> r.li.dominance will be r.li.dominance >>> >> >> nice >> >> >>> r.li.edgedensity will be r.li.edgedens >>> >> >> IMO r.li.edgedensity is preferable (16 chars). >> >> >>> r.li.meanPatchSize will be r.li.meanps >>> r.li.meanPixelAttribute will be r.li.meanpa >>> >> >> similar enough to be confusing? >> what about r.li.patchsize or r.li.mps ?? >> >> I don't have very good ideas about the other one: >> r.li.pixelatt ?? r.li.meanpixatt ?? r.li.mpa ?? >> (of those I prefer r.li.mpa, ....) >> >> >>> r.li.patchAreaDistributionCV will be r.li.padcv >>> r.li.patchAreaDistributionRANGE will be r.li.padrange >>> r.li.patchAreaDistributionSD will be r.li.padsd >>> >> >> nice >> >> >>> r.li.patchdensity will be r.li.patchdens >>> >> >> IMO r.li.patchdensity is preferable (17 chars). >> >> >>> r.li.patchnumber will be r.li.patchnum >>> r.li.richness will be r.li.richness >>> r.li.shannon will be r.li.shannon >>> r.li.shape will be r.li.shape >>> r.li.simpson will be r.li.simpson >>> >> >> nice. >> >> >>> also, because of the structure of r.li, I think is not a good idea to >>> lump different modules. >>> >> >> ok. >> > > I mean, we can discuss this forever or just finally do it. > > thanks, > Markus > > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From michael.barton at asu.edu Mon Feb 5 16:10:12 2007 From: michael.barton at asu.edu (Michael Barton) Date: Mon Feb 5 16:11:32 2007 Subject: [GRASS-dev] Re: [bug #5454] (grass) projection units incorrectly pluralized In-Reply-To: <20070205200634.7217027e.hamish_nospam@yahoo.com> Message-ID: I haven't thought through all the implications, but on the face of it this sounds like a reasonable solution. If implemented, hopefully it would be able to run without lockup (succeed or fail with warning) with the current TclTk scripts until the GUI could be re-written for this. On 2/5/07 12:06 AM, "Hamish" wrote: > Paul Kelly via RT wrote: >> I have fixed the "foots" bug now; see >> http://grass.itc.it/pipermail/grass-commit/2007-January/026497.html >> I will commit a temporary solution to the GUI freezing problem >> (changing g.proj so it won't prompt for the datum info unless you ask >> it to be interactive) shortly. > > Idea: > > It would create a new epsg=code[,n] option: > > g.proj -c location=newLocation epsg=#### > > It would exit with EXIT_FAILURE if the datum transform parm is ambiguous. > > Here's the cunning part: > > "epsg=####,n" would pick param 1,2,3,.. from the list. > > "epsg=####,0" would print available options to stdout and exit with an > EXIT_SUCCESS return code. If the EPSG code isn't found, it exits with > EXIT_FAILURE. The output is in CSV or a parsable format a GUI could read > & make into a nice GUI popup. Maybe with a header comment line for humans. > > In the GUI: > - user selects create new location with EPSG code $EPSG. > > - gui runs "catch `g.proj epsg=$EPSG` > /dev/null" > > - If exit code is 0, gui creates new location with: > "g.proj -c location=$LOCATION epsg=$EPSG" > > - If exit code is 1, gui runs: > "g.proj epsg=$EPSG,0" then parses the output and creates a new > GUI popup with radiobutton options generated from that. (see d.menu) > (If it fails again, EPSG code is bad) > > Once a parm is selected and [Create] is clicked, the popup runs > "g.proj -c location=$LOCATION epsg=$EPSG,$N" > > > IMO this would be many many times better than forcing a value (you > wouldn't even know better transform parms exist), and isn't a huge > amount to code. > > > > Hamish > > __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From grass-bugs at intevation.de Mon Feb 5 16:28:24 2007 From: grass-bugs at intevation.de (Request Tracker) Date: Mon Feb 5 16:28:25 2007 Subject: [GRASS-dev] [bug #5475] (grass) tanks Message-ID: <20070205152824.ECD101005C4@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5475 ------------------------------------------------------------------------- Subject: tanks grass binary for platform: Compiled from Sources 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 JGillette at rfmd.com Mon Feb 5 17:48:24 2007 From: JGillette at rfmd.com (John Gillette) Date: Mon Feb 5 17:48:29 2007 Subject: [GRASS-dev] v.db.dropcol added Message-ID: Hi Markus, I looked at you script without actually running it. I have a few questions (which may or may not be good). (1) You check for an error in the non-sqlite case. Shouldn't you also check in the sqlite case? (2) If there is an error, the script exits before erasing the TMP files. Shouldn't you erase these even if there is an error? (3) I think you missed $TMP.coldesc. You want to erase that one too? Thanks for all your hard work. John > -----Original Message----- > From: grass-dev-bounces@grass.itc.it > [mailto:grass-dev-bounces@grass.itc.it] On Behalf Of Markus Neteler > Sent: Monday, February 05, 2007 8:27 AM > To: grass developers list > Subject: [GRASS-dev] v.db.dropcol added > > Hi, > > thanks to the new ALTER TABLE DROP COLUMN addition for the > DBF driver, I have submitted a new "v.db.dropcol" script to > CVS. It includes extra code for SQLite DBs since SQLite > doesn't originally support column dropping. Using > "v.db.dropcol", however, you can drop columns in any GRASS > table connected to a vector map. Testing obviously welcome. > > cheers > Markus > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > From neteler at itc.it Mon Feb 5 18:01:06 2007 From: neteler at itc.it (Markus Neteler) Date: Mon Feb 5 18:01:07 2007 Subject: [GRASS-dev] v.db.dropcol added In-Reply-To: References: Message-ID: <20070205170106.GL29595@bartok.itc.it> Hi John, On Mon, Feb 05, 2007 at 11:48:24AM -0500, John Gillette wrote: > Hi Markus, > > I looked at you script without actually running it. I have a few > questions (which may or may not be good). excellent observations! > (1) You check for an error in the non-sqlite case. Shouldn't you also > check in the sqlite case? Sure. Fixed. > (2) If there is an error, the script exits before erasing the TMP files. > Shouldn't you erase these even if there is an error? Yep. Also fixed (now with common cleanup() function). > (3) I think you missed $TMP.coldesc. You want to erase that one too? Right. Fixed. > Thanks for all your hard work. Thanks for your feedback! Updated in CVS. Markus > John > > > -----Original Message----- > > From: grass-dev-bounces@grass.itc.it > > [mailto:grass-dev-bounces@grass.itc.it] On Behalf Of Markus Neteler > > Sent: Monday, February 05, 2007 8:27 AM > > To: grass developers list > > Subject: [GRASS-dev] v.db.dropcol added > > > > Hi, > > > > thanks to the new ALTER TABLE DROP COLUMN addition for the > > DBF driver, I have submitted a new "v.db.dropcol" script to > > CVS. It includes extra code for SQLite DBs since SQLite > > doesn't originally support column dropping. Using > > "v.db.dropcol", however, you can drop columns in any GRASS > > table connected to a vector map. Testing obviously welcome. > > > > cheers > > Markus > > > > _______________________________________________ > > grass-dev mailing list > > grass-dev@grass.itc.it > > http://grass.itc.it/mailman/listinfo/grass-dev > > From grass-bugs at intevation.de Tue Feb 6 00:15:37 2007 From: grass-bugs at intevation.de (Request Tracker) Date: Tue Feb 6 00:15:39 2007 Subject: [GRASS-dev] [bug #5478] (grass) v.in.gpsbabel broken for attributes Message-ID: <20070205231537.CECF11005C4@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5478 ------------------------------------------------------------------------- Subject: v.in.gpsbabel broken for attributes Platform: GNU/Linux/x86 grass obtained from: CVS grass binary for platform: Compiled from Sources Hi, I tried v.in.gpsbabel today, but: v.in.gpsbabel -t in=/dev/ttyUSB0 format=garmin out=mytracks Downloading Tracks from GPS 'style=/home/neteler/soft/63grass_cvsexp/dist.i686-pc-linux-gnu/etc/grass_write_ascii.style' is an unknown option to gpx. Attempting waypoint projection transform with cs2cs Importing with v.in.ascii WARNING: The vector 'mytracks' already exists and will be overwritten. Building topology ... 104 primitives registered Building areas: 100% 0 areas built 0 isles built Attaching islands: Attaching centroids: 100% Topology was built. Number of nodes : 198 Number of primitives: 104 Number of points : 0 Number of lines : 104 Number of boundaries: 0 Number of centroids : 0 Number of areas : 0 Number of isles : 0 v.in.ascii complete. v.in.gpsbabel: line vector "mytracks@neteler" successfully created Creating new table.. Populating table with attributes.. DBMI-DBF driver error: SQL parser error in statement: INSERT INTO mytracks VALUES (1, ' ', , , ' ', , ) Error in db_execute_immediate() ERROR: Error while executing: "INSERT INTO mytracks VALUES (1, ' ', , , ' ', , ) " Connecting attribute table to vector file.. WARNING: The table is now part of vector map and may be deleted or overwritten by GRASS modules WARNING: Select privileges were granted on the table Done. Apparently the style file is no longer accepted in this form when downloading tracks/routes from GPS. http://www.gpsbabel.org/htmldoc-1.3.2/fmt_gpx.html http://www.gpsbabel.org/htmldoc-development/fmt_custom.html Markus -------------------------------------------- Managed by Request Tracker From hmitaso at unity.ncsu.edu Tue Feb 6 06:27:44 2007 From: hmitaso at unity.ncsu.edu (Helena Mitasova) Date: Tue Feb 6 06:27:59 2007 Subject: [GRASS-dev] r.surf.idw2 In-Reply-To: <2b3d8c1c0702050135r688188f4q4a7708d4c3f78fcd@mail.gmail.com> References: <2b3d8c1c0701261142t165647f0u310857c4262464ea@mail.gmail.com> <2b3d8c1c0702050135r688188f4q4a7708d4c3f78fcd@mail.gmail.com> Message-ID: <59A71753-22DC-42F4-A644-D088D4CFFDEA@unity.ncsu.edu> I would like to ask the same question as Michael did in 2004 (but I did not find any answer) - why do we keep r.surf.idw2? It gets stuck even with relatively medium size rasters that r.surf.idw computes in seconds. And it does not support lat/long (r.surf.idw does). Thank you, Helena From hamish_nospam at yahoo.com Tue Feb 6 08:03:26 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Feb 6 08:05:58 2007 Subject: [GRASS-dev] Re: [bug #5454] (grass) projection units incorrectly pluralized In-Reply-To: References: <20070205200634.7217027e.hamish_nospam@yahoo.com> Message-ID: <20070206200326.78e44b29.hamish_nospam@yahoo.com> Hamish wrote: > > Idea: > > > > It would create a new epsg=code[,n] option: > > > > g.proj -c location=newLocation epsg=#### > > > > It would exit with EXIT_FAILURE if the datum transform parm is ambiguous. > > > > Here's the cunning part: > > > > "epsg=####,n" would pick param 1,2,3,.. from the list. > > > > "epsg=####,0" would print available options to stdout and exit with an > > EXIT_SUCCESS return code. If the EPSG code isn't found, it exits with > > EXIT_FAILURE. The output is in CSV or a parsable format a GUI could read > > & make into a nice GUI popup. Maybe with a header comment line for humans. > > > > In the GUI: > > - user selects create new location with EPSG code $EPSG. > > > > - gui runs "catch `g.proj epsg=$EPSG` > /dev/null" > > > > - If exit code is 0, gui creates new location with: > > "g.proj -c location=$LOCATION epsg=$EPSG" > > > > - If exit code is 1, gui runs: > > "g.proj epsg=$EPSG,0" then parses the output and creates a new > > GUI popup with radiobutton options generated from that. (see d.menu) > > (If it fails again, EPSG code is bad) > > > > Once a parm is selected and [Create] is clicked, the popup runs > > "g.proj -c location=$LOCATION epsg=$EPSG,$N" > > > > > > IMO this would be many many times better than forcing a value (you > > wouldn't even know better transform parms exist), and isn't a huge > > amount to code. Michael: > I haven't thought through all the implications, but on the face of it this > sounds like a reasonable solution. If implemented, hopefully it would be > able to run without lockup (succeed or fail with warning) with the current > TclTk scripts until the GUI could be re-written for this. The whole idea is to made g.proj fully non-interactive and leave that to the GUI. I guess instead of epsg=####[,n] the [,n] part should go in a datumtrans= option as it could apply to georef=,wkt=,proj4= as well. This would print a GUI parsable list of options: (or error if bad epsg code) g.proj epsg=#### datumtrans=0 or g.proj epsg=#### datumtrans=list if there is only one item on the list the GUI would automatically run with that, "datumtrans=1" would be the default answer: g.proj -c loc=newLoc epsg=#### If multiple options the GUI would create a dialog from the list, then create the new location with: g.proj -c loc=newLoc epsg=#### datumtrans=2 or g.proj -c loc=newLoc epsg=#### datumtrans=conus # ??? Not sure if it should take text "list,conus,etc". Probably that is unneeded pain. Aliasing "list" to "0" would be nice but wouldn't get past parser checks for TYPE_INTEGER and parm->options="0-100";. Hamish From epatton at nrcan.gc.ca Tue Feb 6 16:11:48 2007 From: epatton at nrcan.gc.ca (Patton, Eric) Date: Tue Feb 6 16:11:51 2007 Subject: [GRASS-dev] v.db.dropcol Message-ID: Hi Markus, I check out this new module today with the latest CVS update. Works great with dbf driver on Ubuntu 6.06. ~ Eric. From epatton at nrcan.gc.ca Tue Feb 6 16:23:49 2007 From: epatton at nrcan.gc.ca (Patton, Eric) Date: Tue Feb 6 16:23:51 2007 Subject: [GRASS-dev] v.db.dropcol Message-ID: It also removes columns from table with sqlite driver with no errors. Nice! ~ Eric. -----Original Message----- From: grass-dev-bounces@grass.itc.it To: grass-dev@grass.itc.it Sent: 2/6/2007 10:11 AM Subject: [GRASS-dev] v.db.dropcol Hi Markus, I check out this new module today with the latest CVS update. Works great with dbf driver on Ubuntu 6.06. ~ Eric. _______________________________________________ grass-dev mailing list grass-dev@grass.itc.it http://grass.itc.it/mailman/listinfo/grass-dev From neteler at itc.it Tue Feb 6 17:40:21 2007 From: neteler at itc.it (Markus Neteler) Date: Tue Feb 6 17:40:24 2007 Subject: [GRASS-dev] r.li (landscape indices) In-Reply-To: <20070205152856.z22uwzensg8ccokk@webmail.cli.di.unipi.it> References: <20070130124544.75256f5f.hamish_nospam@yahoo.com> <45C73B46.8040903@itc.it> <20070205152856.z22uwzensg8ccokk@webmail.cli.di.unipi.it> Message-ID: <45C8AF75.2000005@itc.it> Serena, if your PC won't work in the foreseeable future, please send the patches. Thanks Markus pallecch@cli.di.unipi.it wrote on 02/05/2007 03:28 PM: > ok, I'll change the names as Hamish suggests, but at this moment my pc > is out of service and so I can't update r.li in the server. I can only > send to you the new version of r.li. > -serena- > > Quoting Markus Neteler : > >> Hi, >> >> I would really get this one solved... we are currently updating the >> GRASS book >> (3rd edition) and it would be a pain to either not write about r.li or >> to have >> the names wrong. >> >> >> Hamish wrote on 01/30/2007 12:45 AM: >>> serena wrote: >>> >>>> If there aren't problems I'll change r.li names. >>>> >> ... >>>> so: >>>> >>> [including Serena's updates] >>> >>> >>>> r.li.contrastWeightedEdgeDensity will be r.li.cwed >>>> r.li.dominance will be r.li.dominance >>>> >>> >>> nice >>> >>> >>>> r.li.edgedensity will be r.li.edgedens >>>> >>> >>> IMO r.li.edgedensity is preferable (16 chars). >>> >>> >>>> r.li.meanPatchSize will be r.li.meanps >>>> r.li.meanPixelAttribute will be r.li.meanpa >>>> >>> >>> similar enough to be confusing? >>> what about r.li.patchsize or r.li.mps ?? >>> >>> I don't have very good ideas about the other one: >>> r.li.pixelatt ?? r.li.meanpixatt ?? r.li.mpa ?? >>> (of those I prefer r.li.mpa, ....) >>> >>> >>>> r.li.patchAreaDistributionCV will be r.li.padcv >>>> r.li.patchAreaDistributionRANGE will be r.li.padrange >>>> r.li.patchAreaDistributionSD will be r.li.padsd >>>> >>> >>> nice >>> >>> >>>> r.li.patchdensity will be r.li.patchdens >>>> >>> >>> IMO r.li.patchdensity is preferable (17 chars). >>> >>> >>>> r.li.patchnumber will be r.li.patchnum >>>> r.li.richness will be r.li.richness >>>> r.li.shannon will be r.li.shannon >>>> r.li.shape will be r.li.shape >>>> r.li.simpson will be r.li.simpson >>>> >>> >>> nice. >>> >>> >>>> also, because of the structure of r.li, I think is not a good idea to >>>> lump different modules. >>>> >>> >>> ok. >>> >> >> I mean, we can discuss this forever or just finally do it. >> >> thanks, >> Markus >> >> > > > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > From grass-bugs at intevation.de Tue Feb 6 18:14:32 2007 From: grass-bugs at intevation.de (Request Tracker) Date: Tue Feb 6 18:14:33 2007 Subject: [GRASS-dev] [bug #5481] (grass) BFD 2.16.91.0.7 20060317 internal error, aborting at elfcode.h Message-ID: <20070206171432.191921005AB@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5481 ------------------------------------------------------------------------- Subject: BFD 2.16.91.0.7 20060317 internal error, aborting at elfcode.h Platform: GNU/Linux/x86_64 grass obtained from: Trento Italy site grass binary for platform: Compiled from Sources GRASS Version: grass 6.2.1 (2006) I've got this message in a make >& make.out gcc -shared -o /usr/local/src/grass-6.2.1/dist./lib/libgrass_gproj.6.2.1.so -L/usr/local/src/grass-6.2.1/dist./lib -Wl,--export-dynamic -Wl,-rpath-link,/usr/local/src/grass-6.2.1/dist./lib OBJ./get_proj.o OBJ./do_proj.o OBJ./convert.o OBJ./datum.o OBJ./ellipse.o -lgrass_gis -lgrass_datetime -lz -lproj -L/usr/lib64 -lgdal && if [ -z "" ] ; then ln -f -s libgrass_gproj.6.2.1.so /usr/local/src/grass-6.2.1/dist./lib/libgrass_gproj.so; fi /usr/bin/ld: BFD 2.16.91.0.7 20060317 internal error, aborting at elfcode.h line 190 in bfd_elf64_swap_symbol_in /usr/bin/ld: Please report this bug. collect2: ld returned 1 exit status make[2]: *** [/usr/local/src/grass-6.2.1/dist./lib/libgrass_gproj.6.2.1.so] Error 1 make[2]: se sale del directorio `/usr/local/src/grass-6.2.1/lib/proj I configured with ./configure --prefix=/usr/local --enable-64bit --with-postgres-includes=/usr/include/pgsql --enable-shared Anyway, I've could compile GRASS, but with I push enter button in the splash-project window a child killed segmentation violation it's produced (the console still go on, with some commands). I wish this can be helpful for you. Best Regards, Miriam -------------------------------------------- Managed by Request Tracker From glynn at gclements.plus.com Tue Feb 6 22:30:12 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Feb 6 22:30:15 2007 Subject: [GRASS-dev] [bug #5481] (grass) BFD 2.16.91.0.7 20060317 internal error, aborting at elfcode.h In-Reply-To: <20070206171432.191921005AB@lists.intevation.de> References: <20070206171432.191921005AB@lists.intevation.de> Message-ID: <17864.62308.930552.987235@cerise.gclements.plus.com> Request Tracker wrote: > this bug's URL: http://intevation.de/rt/webrt?serial_num=5481 > ------------------------------------------------------------------------- > > Subject: BFD 2.16.91.0.7 20060317 internal error, aborting at elfcode.h > > Platform: GNU/Linux/x86_64 > grass obtained from: Trento Italy site > grass binary for platform: Compiled from Sources > GRASS Version: grass 6.2.1 (2006) > > I've got this message in a make >& make.out > > gcc -shared -o /usr/local/src/grass-6.2.1/dist./lib/libgrass_gproj.6.2.1.so -L/usr/local/src/grass-6.2.1/dist./lib -Wl,--export-dynamic -Wl,-rpath-link,/usr/local/src/grass-6.2.1/dist./lib OBJ./get_proj.o OBJ./do_proj.o OBJ./convert.o OBJ./datum.o OBJ./ellipse.o -lgrass_gis -lgrass_datetime -lz -lproj -L/usr/lib64 -lgdal && if [ -z "" ] ; then ln -f -s libgrass_gproj.6.2.1.so /usr/local/src/grass-6.2.1/dist./lib/libgrass_gproj.so; fi > /usr/bin/ld: BFD 2.16.91.0.7 20060317 internal error, aborting at elfcode.h line 190 in bfd_elf64_swap_symbol_in > > /usr/bin/ld: Please report this bug. This is an error in "ld" (the linker, from the "binutils" package). It should be reported to the binutils maintainers, or to the maintainers of your OS distribution. There isn't anything which the GRASS developers can do about it. -- Glynn Clements From grass-bugs at intevation.de Tue Feb 6 23:14:16 2007 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Tue Feb 6 23:14:18 2007 Subject: [GRASS-dev] [bug #5263] (grass) r.to.vect: -v flag doesn't transfer cat values Message-ID: <20070206221416.D04281005AF@lists.intevation.de> hbowman wrote (Thu, Nov 9 2006 06:32:54): > Subject: r.to.vect: -v flag doesn't transfer cat values Without -v the categories are not assigned for feature=line either. This is propably not desired, but not a bug deal as one can use v.category later. However, in case of -v I guess that v.category not assigning the categories makes a sane thing. Because, how to assing input raster lines values as categories to output vector lines, when they are overlapping input raster cells of different value, .eg: http://kufaya.googlepages.com/lines.png Looks like r.to.vect feauture=line cares only about the line's shape, and it's propably doing it by design. Am I thinking any good here? Do we call it a feature? Shall I document this? > the vector map is created but the lines have no cats > v.info: > | Number of dblinks: 0 FWIW, this is not a proof for a lack of categories. A vector can have categories and no dblinks. v.category option=report would do instead. Maciek -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Tue Feb 6 23:28:18 2007 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Tue Feb 6 23:28:19 2007 Subject: [GRASS-dev] [bug #5171] (grass) v.to.db: indicator of multiple categories is not printed Message-ID: <20070206222818.34FBF1005AF@lists.intevation.de> guest wrote (Mon, Sep 25 2006 12:05:21): > Subject: v.to.db: indicator of multiple categories is not printed This bug is still present in current 6.3 CVS. Maciek -------------------------------------------- Managed by Request Tracker From paul-grass at stjohnspoint.co.uk Wed Feb 7 00:14:29 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Wed Feb 7 00:14:39 2007 Subject: [GRASS-dev] Re: [bug #5454] (grass) projection units incorrectly pluralized In-Reply-To: <20070206200326.78e44b29.hamish_nospam@yahoo.com> References: <20070205200634.7217027e.hamish_nospam@yahoo.com> <20070206200326.78e44b29.hamish_nospam@yahoo.com> Message-ID: On Tue, 6 Feb 2007, Hamish wrote: > Hamish wrote: >>> Idea: >>> >>> It would create a new epsg=code[,n] option: >>> >>> g.proj -c location=newLocation epsg=#### >>> >>> It would exit with EXIT_FAILURE if the datum transform parm is ambiguous. >>> >>> Here's the cunning part: >>> >>> "epsg=####,n" would pick param 1,2,3,.. from the list. >>> >>> "epsg=####,0" would print available options to stdout and exit with an >>> EXIT_SUCCESS return code. If the EPSG code isn't found, it exits with >>> EXIT_FAILURE. The output is in CSV or a parsable format a GUI could read >>> & make into a nice GUI popup. Maybe with a header comment line for humans. >>> >>> In the GUI: >>> - user selects create new location with EPSG code $EPSG. >>> >>> - gui runs "catch `g.proj epsg=$EPSG` > /dev/null" >>> >>> - If exit code is 0, gui creates new location with: >>> "g.proj -c location=$LOCATION epsg=$EPSG" >>> >>> - If exit code is 1, gui runs: >>> "g.proj epsg=$EPSG,0" then parses the output and creates a new >>> GUI popup with radiobutton options generated from that. (see d.menu) >>> (If it fails again, EPSG code is bad) >>> >>> Once a parm is selected and [Create] is clicked, the popup runs >>> "g.proj -c location=$LOCATION epsg=$EPSG,$N" >>> >>> >>> IMO this would be many many times better than forcing a value (you >>> wouldn't even know better transform parms exist), and isn't a huge >>> amount to code. > > Michael: >> I haven't thought through all the implications, but on the face of it this >> sounds like a reasonable solution. If implemented, hopefully it would be >> able to run without lockup (succeed or fail with warning) with the current >> TclTk scripts until the GUI could be re-written for this. > > The whole idea is to made g.proj fully non-interactive and leave that to the > GUI. > > I guess instead of epsg=####[,n] the [,n] part should go in a datumtrans= > option as it could apply to georef=,wkt=,proj4= as well. > > This would print a GUI parsable list of options: (or error if bad epsg code) > g.proj epsg=#### datumtrans=0 > or > g.proj epsg=#### datumtrans=list Yes it's starting to make more sense now when you put it like that. Although as Glynn said maybe the GUI should be reading the datumtransform tables itself, although again it has no way of telling from the EPSG code what the associated datum is. Even I am not sure how it does it. Some magic inside the OGR library I think. I still worry a little that it depends too much on the existing structure of support for datum transform parameters within GRASS. Michael made an interesting point that perhaps the EPSG database contains some sets of paramters. But even if it does, we can't guarantee that they're correct or complete or best. The whole point of the EPSG database is (from it's name) petroleum survey, I presume. Which means it would be more likely to include datum paramters useful for oilfield areas etc.? I don't know if it does contain paramters, nor how to extract them. I would guess though that it doesn't use PROJ.4 syntax, nor contain New Zealand Map Grid tables or Canadian NTv2 tables etc. the way GRASS does. I think a solution acceptable to everyone is gradually forming over time. This is what I hoped would happen! > if there is only one item on the list the GUI would automatically run > with that, "datumtrans=1" would be the default answer: > g.proj -c loc=newLoc epsg=#### Actually the function GPJ_get_default_datum_params_by_name() in lib/proj/datum.c returns a "default", which for various reasons is actually the last in the list... > > If multiple options the GUI would create a dialog from the list, > then create the new location with: > g.proj -c loc=newLoc epsg=#### datumtrans=2 > or > g.proj -c loc=newLoc epsg=#### datumtrans=conus # ??? > > > Not sure if it should take text "list,conus,etc". > Probably that is unneeded pain. Aliasing "list" to "0" would be nice Yes I see where you're coming from, I think. If the first item in the list was the default anyway this would work out nicely. Maybe omitting the datumtrans option could mean use the default instead of datumtrans=1? Paul > but wouldn't get past parser checks for TYPE_INTEGER and > parm->options="0-100";. > > > > Hamish > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > From paul-grass at stjohnspoint.co.uk Wed Feb 7 01:30:54 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Wed Feb 7 01:31:04 2007 Subject: [GRASS-dev] Re: winGRASS In-Reply-To: <3359.164.15.134.77.1166451769.squirrel@geog-pc40.ulb.ac.be> References: <1451.164.15.134.77.1166435384.squirrel@geog-pc40.ulb.ac.be> <2087.164.15.134.77.1166441036.squirrel@geog-pc40.ulb.ac.be> <3359.164.15.134.77.1166451769.squirrel@geog-pc40.ulb.ac.be> Message-ID: On Mon, 18 Dec 2006, Moritz Lennert wrote: > Here are some more issues: > > - export map canvas to graphics file: > > couldn't execute "rm": no such file or directory > couldn't execute "rm": no such file or directory > while executing > "exec rm $path.ppm" > ("jpg" arm line 7) > invoked from within > "switch $type { > "ppm" { > return > } > "tif" { > exec gdal_translate $path.ppm $path.tif -of GTIFF > exec rm $path.ppm > } > "bmp" { > e..." > (procedure "MapToolBar::savefile" line 22) > invoked from within > "MapToolBar::savefile jpg 50" > (menu invoke) > > So, graphics file gets created, but the original ppm file is not erased. I think Michael has fixed those occurences of exec rm now so the Tcl file delete function is used. So it should be OK. > > - In an earlier mail I wrote: "I noticed that I can close the com.exe > window and still continue using grass. Is there any reason to keep this > open ? If not, is there a way to close it automatically ? Just a question > of not multiplying unnecessary windows." > > Actually, I imagine that this window could potentially be used for > scripting, or ? But gis.m does not background itself, so I don't have a > prompt in the com.exe window. Is this linked to Hamish' recent changes > taking away the "&" ? > > Moritz > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > From paul-grass at stjohnspoint.co.uk Wed Feb 7 01:39:53 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Wed Feb 7 01:39:56 2007 Subject: [GRASS-dev] Re: winGRASS In-Reply-To: <3359.164.15.134.77.1166451769.squirrel@geog-pc40.ulb.ac.be> References: <1451.164.15.134.77.1166435384.squirrel@geog-pc40.ulb.ac.be> <2087.164.15.134.77.1166441036.squirrel@geog-pc40.ulb.ac.be> <3359.164.15.134.77.1166451769.squirrel@geog-pc40.ulb.ac.be> Message-ID: Hello Moritz Better late than never to respond to some of these issues. (Sorry about that last mail; sent it far too soon...) On Mon, 18 Dec 2006, Moritz Lennert wrote: > Here are some more issues: > [...] > Did that. I also added a 'set GRASS_WISH=' command in grass63.bat, as it > didn't seem to find my wish command. Right. init.bat will need to be changed to set GRASS_WISH by default I think - I was under the impression that it only needed to be set if the wish executable wasn't in the path, but there seem to be places in gis.m and nviz that rely on it being set and crash if it isn't. FWIW with the Activestate Tcl/Tk that I was using there are executables named both wish.exe and wish84.exe, which are identical. With the MinGW Tcl/Tk there is only wish84.exe. > Now, to go on: > > - I had hoped that Radim's patch for dbmi_client > (http://grass.itc.it/pipermail/grass5/2006-December/028118.html) might > solve the issue I've had with the db protocol errors, but apparently this > is not the case. When I push the 'show the attribute columns' in a vector > panel, I still get > > ******* > Displaying column types/names for database connection of layer 1: > dbmi: Protocol error > > Cannot open table > ******** > > and a 'v.db.select' on the same map gives me: > > ******** > 'vector/streams' was found in more mapsets (also found in user1). > dbmi: Protocol error > > Cannot open select cursor > ********* > > Radim, as you have been working on this these days, do you have an idea > what might be wrong ? I can confirm similar problems. I tried to import a Shapefile with v.in.ogr. I went quite deep into debugging it and got nowhere at all, although I should have taken better notes. I did confirm though that compiling the library with -mwindows as Radim suggested on the list made no difference either. I think trying with a different database, PostgreSQL perhaps is the next big step to debugging this. See if the behaviour is the same as with dbf and if not we can isolate it a bit more. (Markus, this is what you were asking about what would be the next step towards solving this.) > - I noticed that I can close the com.exe window and still continue using > grass. Is there any reason to keep this open ? If not, is there a way to > close it automatically ? Just a question of not multiplying unnecessary > windows. It is running init.bat. When gis.m exits then etc/clean_temp will be run to clean up the temporary files. It is possible to minmise it (by editing the properties of the shortcut to grass63.bat) but I don't know how to make it disappear. > - Help does not work. In individual command windows, the help button is > desactivated. In layer panels in the main GIS Manager window, when I push > the help button, I get: > > child process exited abnormally > child process exited abnormally > while executing > "exec -- g.manual d.vect >& NUL:" > ("eval" body line 1) > invoked from within > "eval [list exec -- $cmd] $args >& $devnull" > (procedure "run" line 8) > invoked from within > "run g.manual d.vect" > ("uplevel" body line 1) > invoked from within > "uplevel \#0 $cmd" > (procedure "Button::_release" line 18) > invoked from within > "Button::_release .mainframe.frame.pw1.f1.frame.sw.sf.frame.fr.name.e" > (command bound to event) > This was due to g.parser assuming the shell (c:\msys\1.0\bin\sh.exe) that it needed to run g.manual (required for all the help) was in the path. I have since changed the way it operates on Windows to first check the environment variable GRASS_SH before looking for sh.exe in the path. So the help should work now. > - export map canvas to graphics file: > > couldn't execute "rm": no such file or directory > couldn't execute "rm": no such file or directory > while executing > "exec rm $path.ppm" > ("jpg" arm line 7) > invoked from within > "switch $type { > "ppm" { > return > } > "tif" { > exec gdal_translate $path.ppm $path.tif -of GTI$ > exec rm $path.ppm > } > "bmp" { > e..." > (procedure "MapToolBar::savefile" line 22) > invoked from within > "MapToolBar::savefile jpg 50" > (menu invoke) > > So, graphics file gets created, but the original ppm file is not erased. I think Michael has fixed those occurences of exec rm now so the Tcl file delete function is used. So it should be OK. Another outstanding issue is Nviz. It was working on Windows for a while (looked great with Michael's new user interface improvements) but since Bob changed it back to the script startup rather than running the nviz.exe executable directly it no longer works on Windows. In fact I recently tried to revert those changes and found it still wouldn't work; got stuck at the Please Wait screen. A pity, because there is probably very little needs changed to have it working again. There are also a few other things that need tidying up. Having backslashes instead of forward slashes in the setting of WINGISBASE in grass63.bat is an obvious one. Should be really simple with use of sed in the Makefile but I couldn't get it to work. More later. Paul From grass-bugs at intevation.de Wed Feb 7 03:38:27 2007 From: grass-bugs at intevation.de (Request Tracker) Date: Wed Feb 7 03:38:39 2007 Subject: [GRASS-dev] [bug #5482] (grass) Help with problem Message-ID: <20070207023827.393211005AF@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5482 ------------------------------------------------------------------------- Subject: Help with problem My PC has crashed. urgent. -------------------------------------------- Managed by Request Tracker From hamish_nospam at yahoo.com Wed Feb 7 03:02:58 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Feb 7 04:38:10 2007 Subject: [GRASS-dev] g.rp In-Reply-To: References: <20070205200634.7217027e.hamish_nospam@yahoo.com> <20070206200326.78e44b29.hamish_nospam@yahoo.com> Message-ID: <20070207150258.3c310a09.hamish_nospam@yahoo.com> > > Hamish wrote: > >>> Idea: > > The whole idea is to made g.proj fully non-interactive and leave > > that to the GUI. .. > > This would print a GUI parsable list of options: (or error if bad > > epsg code) g.proj epsg=#### datumtrans=0 > > or > > g.proj epsg=#### datumtrans=list Paul: > Yes it's starting to make more sense now when you put it like that. > Although as Glynn said maybe the GUI should be reading the > datumtransform tables itself, I would think it better to pass that through a g.* module. * It's cleaner to abstract it/consolidate it out of the GUI. * The epsg file the GUI is using might not exactly match the version GRASS is using. (eg --with-proj-share= only is for GUI startup) > although again it has no way of telling from the EPSG code what the > associated datum is. Even I am not sure how it does it. Some magic > inside the OGR library I think. FWIW, NZ Map Grid's entry reads as follows: # NZGD49 / New Zealand Map Grid <27200> +proj=nzmg +lat_0=-41 +lon_0=173 +x_0=2510000 +y_0=6023150 +ellps=intl +datum=nzgd49 +units=m +no_defs <> That says nothing about how to convert to the nzgd49 datum. We give three options: 7 parm, 3 parm, or NTv2 distortion grid. Nothing in the EPSG file using the NZ 1949 datum does: /usr/share/proj$ grep nzgd49 epsg | grep '+towgs84=' /usr/share/proj$ > I still worry a little that it depends too much on the existing > structure of support for datum transform parameters within GRASS. > Michael made an interesting point that perhaps the EPSG database > contains some sets of paramters. Not in the NZ case anyway... > But even if it does, we can't guarantee that they're correct or > complete or best. The whole point of the EPSG database is (from it's > name) petroleum survey, I presume. Which means it would be more likely > to include datum paramters useful for oilfield areas etc.? IIRC from the past Frank/Gerald/Clifford posts on the proj4 mailing list, the list is maintained for the benefit of people drilling holes in the ground. The horizontal distance error incurred by differing datum transform parms is probably only academic to that crowd, and updated to more "correct" values as a service to the rest of us. Similar to projections originally developed by military sources only being accurate enough to direct artillery fire, where errors of less than a meter aren't important. > I don't know if it does contain paramters, nor how to extract them. I > would guess though that it doesn't use PROJ.4 syntax, nor contain New > Zealand Map Grid tables or Canadian NTv2 tables etc. the way GRASS > does. IIUC, every now and then Frank pulls the database and runs some scripts to convert EPSG DB format (wkt??) to PROJ4 format and create the various /usr/share/proj/epsg files. The script is obviously pretty good, but it isn't totally foolproof and IIUC has some hardcoded "fixes" built in. Then Markus does some magic and updates grass6/lib/proj/ellipsoid.csv, gcs.csv, gdal_datum.csv, projop_wparm.csv, unit_of_measure.csv, stateplane.csv from Frank's new PROJ4 CVS version. > I think a solution acceptable to everyone is gradually forming over > time. This is what I hoped would happen! > > > if there is only one item on the list the GUI would automatically > > run with that, "datumtrans=1" would be the default answer: > > g.proj -c loc=newLoc epsg=#### > > Actually the function GPJ_get_default_datum_params_by_name() in > lib/proj/datum.c returns a "default", which for various reasons is > actually the last in the list... As long as there is some hinting, we can make the rest happen in code. It shouldn't be too hard to reindex the list. (he says not having looked at the code :) > > If multiple options the GUI would create a dialog from the list, > > then create the new location with: > > g.proj -c loc=newLoc epsg=#### datumtrans=2 > > or > > g.proj -c loc=newLoc epsg=#### datumtrans=conus # ??? > > > > Not sure if it should take text "list,conus,etc". > > Probably that is unneeded pain. Aliasing "list" to "0" would be nice > > Yes I see where you're coming from, I think. If the first item in the > list was the default anyway this would work out nicely. Maybe > omitting the datumtrans option could mean use the default instead of > datumtrans=1? Well my idea was put the default first and when combined with ->answer="1" it happens automatically. I'd prefer to use the parser to pick the default answer rather than it happen somewhere inside the black box, but it guess it doesn't have to. My main goal was that the default parm should be the default option, regardless of order. The easiest way to have that happen is to call it "1" and have parm->answer="1" in the option's parser def'n, after making sure the default parm comes first. > I think a solution acceptable to everyone is gradually forming over > time. This is what I hoped would happen! It would be nice. I guess another thing missing is region setting code to replace E_edit_cellhd(). More g.proj -c options? region=n,s,e,w nsres= ewres= Also we need to have a replacement GUI top-down location creation method (pick type, then projection, then datum), vs the bottom-up EPSG code way. Maybe a g.listproj module that would give existing type, SP, proj lists from lib fns in a CSV or other GUI parsable format? e.g. this would call a non-paged version of lib/gis/get_projname.c: g.listproj type=projections or g.listproj type=state_plane ?? I have no idea how to handle the more complicated stuff like setting custom ellipsoids in g.setproj. Hamish From michael.barton at asu.edu Wed Feb 7 05:02:08 2007 From: michael.barton at asu.edu (Michael Barton) Date: Wed Feb 7 05:02:26 2007 Subject: [GRASS-dev] Re: winGRASS In-Reply-To: Message-ID: I have a problem like this on versions of GRASS that I compile myself on my Mac. It doesn't happen on versions that William Kyngesbury compiles. In my case, all of GRASS is correctly compiling against an x11 tcltk that I specify, but nviz insists on compiling against an aqua version also on my machine. It creates a bad nviz binary file (the one that Bob's script calls). I can substitute one that William compiles and all is well. Maybe something similar is happening to you? Michael On 2/6/07 5:39 PM, "Paul Kelly" wrote: > Another outstanding issue is Nviz. It was working on Windows for a while > (looked great with Michael's new user interface improvements) but since > Bob changed it back to the script startup rather than running the nviz.exe > executable directly it no longer works on Windows. In fact I recently > tried to revert those changes and found it still wouldn't work; got stuck > at the Please Wait screen. A pity, because there is probably very little > needs changed to have it working again. __________________________________________ 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 dylan.beaudette at gmail.com Wed Feb 7 08:26:54 2007 From: dylan.beaudette at gmail.com (Dylan Beaudette) Date: Wed Feb 7 08:27:13 2007 Subject: [GRASS-dev] units for output raster derived from v.kernel Message-ID: <3c5546140702062326gbc3aba4rbd9936731e393666@mail.gmail.com> I have looked over the man page for v.kernel, but cannot find any information regarding the units of the values generated by v.kernel. This might be something worth adding... however: are the units: (no. observations) / (cell size of region) ? (no. observations) / (base unit defined in region) ? For example, if v.kernel produced a raster with a maximum value of 1x10^-3, and the base unit defined in my region is a 'meter' it would make sense to say that the units would be counts / square meter . Any ideas? PS: once this is nailed down, it would be a good idea to add it to the man page. Cheers, Dylan From hamish_nospam at yahoo.com Wed Feb 7 08:39:25 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Feb 7 08:39:49 2007 Subject: [GRASS-dev] new ps.map border option Message-ID: <20070207203925.649c2def.hamish_nospam@yahoo.com> Hi, ps.map now has an optional 'border' instruction to control the existence, color, and width of the box around the map area. this resolves wish #3389. enjoy, Hamish From glynn at gclements.plus.com Wed Feb 7 08:57:04 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Feb 7 08:59:40 2007 Subject: [GRASS-dev] Re: [bug #5454] (grass) projection units incorrectly pluralized In-Reply-To: References: <20070205200634.7217027e.hamish_nospam@yahoo.com> <20070206200326.78e44b29.hamish_nospam@yahoo.com> Message-ID: <17865.34384.625260.159914@cerise.gclements.plus.com> Paul Kelly wrote: > > This would print a GUI parsable list of options: (or error if bad epsg code) > > g.proj epsg=#### datumtrans=0 > > or > > g.proj epsg=#### datumtrans=list > > Yes it's starting to make more sense now when you put it like that. > Although as Glynn said maybe the GUI should be reading the datumtransform > tables itself, although again it has no way of telling from the EPSG code > what the associated datum is. Even I am not sure how it does it. Some > magic inside the OGR library I think. My guess is from some combination of the CSV/WKT files in /usr/[local/]share/gdal. Some of the entries in the EPSG file have explicit +datum= options, but most don't. Ultimately, I don't think that replicating the OSR stuff within the GUI is a viable option; we need a utility that gets this information from GDAL. -- Glynn Clements From neteler at itc.it Wed Feb 7 10:14:12 2007 From: neteler at itc.it (Markus Neteler) Date: Wed Feb 7 10:14:25 2007 Subject: [GRASS-dev] Re: winGRASS In-Reply-To: References: <1451.164.15.134.77.1166435384.squirrel@geog-pc40.ulb.ac.be> <2087.164.15.134.77.1166441036.squirrel@geog-pc40.ulb.ac.be> <3359.164.15.134.77.1166451769.squirrel@geog-pc40.ulb.ac.be> Message-ID: <45C99864.40202@itc.it> Paul, Moritz, all, I have added the vector-DB problem to http://grass.gdf-hannover.de/wiki/WinGRASS_Current_Status#What_is_missing.3F My suggestion is to maintain the list there updated. Markus Paul Kelly wrote on 02/07/2007 01:39 AM: > Hello Moritz > Better late than never to respond to some of these issues. > (Sorry about that last mail; sent it far too soon...) > > On Mon, 18 Dec 2006, Moritz Lennert wrote: > >> Here are some more issues: >> > [...] >> Did that. I also added a 'set GRASS_WISH=' command in grass63.bat, as it >> didn't seem to find my wish command. > > Right. init.bat will need to be changed to set GRASS_WISH by default I > think - I was under the impression that it only needed to be set if the > wish executable wasn't in the path, but there seem to be places in gis.m > and nviz that rely on it being set and crash if it isn't. FWIW with the > Activestate Tcl/Tk that I was using there are executables named both > wish.exe and wish84.exe, which are identical. With the MinGW Tcl/Tk there > is only wish84.exe. > > >> Now, to go on: >> >> - I had hoped that Radim's patch for dbmi_client >> (http://grass.itc.it/pipermail/grass5/2006-December/028118.html) might >> solve the issue I've had with the db protocol errors, but apparently >> this >> is not the case. When I push the 'show the attribute columns' in a >> vector >> panel, I still get >> >> ******* >> Displaying column types/names for database connection of layer 1: >> dbmi: Protocol error >> >> Cannot open table >> ******** >> >> and a 'v.db.select' on the same map gives me: >> >> ******** >> 'vector/streams' was found in more mapsets (also found in user1). >> dbmi: Protocol error >> >> Cannot open select cursor >> ********* >> >> Radim, as you have been working on this these days, do you have an idea >> what might be wrong ? > > I can confirm similar problems. I tried to import a Shapefile with > v.in.ogr. I went quite deep into debugging it and got nowhere at all, > although I should have taken better notes. I did confirm though that > compiling the library with -mwindows as Radim suggested on the list made > no difference either. I think trying with a different database, > PostgreSQL > perhaps is the next big step to debugging this. See if the behaviour is > the same as with dbf and if not we can isolate it a bit more. > (Markus, this is what you were asking about what would be the next step > towards solving this.) > >> - I noticed that I can close the com.exe window and still continue using >> grass. Is there any reason to keep this open ? If not, is there a way to >> close it automatically ? Just a question of not multiplying unnecessary >> windows. > > It is running init.bat. When gis.m exits then etc/clean_temp will be run > to clean up the temporary files. It is possible to minmise it (by editing > the properties of the shortcut to grass63.bat) but I don't know how to > make it disappear. > >> - Help does not work. In individual command windows, the help button is >> desactivated. In layer panels in the main GIS Manager window, when I >> push >> the help button, I get: >> >> child process exited abnormally >> child process exited abnormally >> while executing >> "exec -- g.manual d.vect >& NUL:" >> ("eval" body line 1) >> invoked from within >> "eval [list exec -- $cmd] $args >& $devnull" >> (procedure "run" line 8) >> invoked from within >> "run g.manual d.vect" >> ("uplevel" body line 1) >> invoked from within >> "uplevel \#0 $cmd" >> (procedure "Button::_release" line 18) >> invoked from within >> "Button::_release .mainframe.frame.pw1.f1.frame.sw.sf.frame.fr.name.e" >> (command bound to event) >> > > This was due to g.parser assuming the shell (c:\msys\1.0\bin\sh.exe) that > it needed to run g.manual (required for all the help) was in the path. I > have since changed the way it operates on Windows to first check the > environment variable GRASS_SH before looking for sh.exe in the path. So > the help should work now. > >> - export map canvas to graphics file: >> >> couldn't execute "rm": no such file or directory >> couldn't execute "rm": no such file or directory >> while executing >> "exec rm $path.ppm" >> ("jpg" arm line 7) >> invoked from within >> "switch $type { >> "ppm" { >> return >> } >> "tif" { >> exec gdal_translate $path.ppm $path.tif >> -of GTI$ >> exec rm $path.ppm >> } >> "bmp" { >> e..." >> (procedure "MapToolBar::savefile" line 22) >> invoked from within >> "MapToolBar::savefile jpg 50" >> (menu invoke) >> >> So, graphics file gets created, but the original ppm file is not erased. > > I think Michael has fixed those occurences of exec rm now so the Tcl file > delete function is used. So it should be OK. > > Another outstanding issue is Nviz. It was working on Windows for a while > (looked great with Michael's new user interface improvements) but > since Bob changed it back to the script startup rather than running > the nviz.exe > executable directly it no longer works on Windows. In fact I recently > tried to revert those changes and found it still wouldn't work; got > stuck at the Please Wait screen. A pity, because there is probably > very little needs changed to have it working again. > > There are also a few other things that need tidying up. Having > backslashes > instead of forward slashes in the setting of WINGISBASE in grass63.bat is > an obvious one. Should be really simple with use of sed in the Makefile > but I couldn't get it to work. > > More later. > > Paul > > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From neteler at itc.it Wed Feb 7 10:18:22 2007 From: neteler at itc.it (Markus Neteler) Date: Wed Feb 7 10:18:30 2007 Subject: [GRASS-dev] v.digit: Could not set Tcl system encoding fixed Message-ID: <45C9995E.7010700@itc.it> Hi, Roberto Flor and me have fixed the bug "v.digit: Could not set Tcl system encoding" http://intevation.de/rt/webrt?serial_num=4110 Please test. I'll backport it to 6.2.x then. Note: For mysterious Tcl (?) reasons I cannot set iso8859-1 and iso8859-2 but utf-8, iso8859-15, iso2210-jp, koi8-r, euc-jp etc work. Maybe my installation... Markus From grass-bugs at intevation.de Wed Feb 7 10:59:11 2007 From: grass-bugs at intevation.de (Request Tracker) Date: Wed Feb 7 10:59:28 2007 Subject: [GRASS-dev] [bug #5483] (grass) g.mremove through gis manager GUI seems not to work well Message-ID: <20070207095911.CADFA1005C4@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5483 ------------------------------------------------------------------------- Subject: g.mremove through gis manager GUI seems not to work well Platform: GNU/Linux/ppc grass obtained from: Mirror of Trento site grass binary for platform: Compiled from Sources GRASS Version: GRASS6.2/6.3 Aldo Clerici. The command File > Manage maps and volumes > Remove maps using expressions and wildcards require an acknowledgment in the form: Collecting map names for current mapset .... g.remove rast=geology.new,slope.new Did you mean this (y/n)? But it seems not to accept any kind of input (y,yes,n,no). It seems to wait for something else. Same behaviour in grass6.2 and 6.3. The same command g.mremove in command line mode works well. -------------------------------------------- Managed by Request Tracker From neteler at itc.it Wed Feb 7 11:07:47 2007 From: neteler at itc.it (Markus Neteler) Date: Wed Feb 7 11:07:50 2007 Subject: [GRASS-dev] [bug #5483] (grass) g.mremove through gis manager GUI seems not to work well In-Reply-To: <20070207095911.CADFA1005C4@lists.intevation.de> References: <20070207095911.CADFA1005C4@lists.intevation.de> Message-ID: <45C9A4F3.5040304@itc.it> Request Tracker wrote on 02/07/2007 10:59 AM: > this bug's URL: http://intevation.de/rt/webrt?serial_num=5483 > ------------------------------------------------------------------------- > > Subject: g.mremove through gis manager GUI seems not to work well > > Platform: GNU/Linux/ppc > grass obtained from: Mirror of Trento site > grass binary for platform: Compiled from Sources > GRASS Version: GRASS6.2/6.3 > > Aldo Clerici. > The command File > Manage maps and volumes > Remove maps using expressions and wildcards require an acknowledgment in the form: > > Collecting map names for current mapset .... > g.remove rast=geology.new,slope.new > Did you mean this (y/n)? > > But it seems not to accept any kind of input (y,yes,n,no). It seems to wait for something else. > Aldo, up to now interactive input in tcl based dialogs is not possible. Using the -f flag (force removal) you can delete also in gis.m. Probably we need to enforce -f somehow in gis.m - how to do that? Markus > Same behaviour in grass6.2 and 6.3. > The same command g.mremove in command line mode works well. > > > -------------------------------------------- Managed by Request Tracker > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > From paul-grass at stjohnspoint.co.uk Wed Feb 7 13:20:04 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Wed Feb 7 13:21:12 2007 Subject: [GRASS-dev] Re: winGRASS In-Reply-To: References: Message-ID: Hello Michael If you use the --with-opengl=aqua configure option then nviz will use the aqua Tcl/Tk, but I thought that was desired? See William's comments here: http://grass.itc.it/pipermail/grass-dev/2006-November/027480.html Perhaps William just compiled his in the brief period while it was working, and now it is no longer working again? Just an idea Paul On Tue, 6 Feb 2007, Michael Barton wrote: > I have a problem like this on versions of GRASS that I compile myself on my > Mac. It doesn't happen on versions that William Kyngesbury compiles. In my > case, all of GRASS is correctly compiling against an x11 tcltk that I > specify, but nviz insists on compiling against an aqua version also on my > machine. It creates a bad nviz binary file (the one that Bob's script > calls). I can substitute one that William compiles and all is well. Maybe > something similar is happening to you? > > Michael > > > On 2/6/07 5:39 PM, "Paul Kelly" wrote: > >> Another outstanding issue is Nviz. It was working on Windows for a while >> (looked great with Michael's new user interface improvements) but since >> Bob changed it back to the script startup rather than running the nviz.exe >> executable directly it no longer works on Windows. In fact I recently >> tried to revert those changes and found it still wouldn't work; got stuck >> at the Please Wait screen. A pity, because there is probably very little >> needs changed to have it working again. > > __________________________________________ > Michael Barton, Professor of Anthropology > School of Human Evolution & Social Change > Center for Social Dynamics & Complexity > Arizona State University > > phone: 480-965-6213 > fax: 480-965-7671 > www: http://www.public.asu.edu/~cmbarton > > > From glynn at gclements.plus.com Wed Feb 7 15:59:58 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Feb 7 15:59:59 2007 Subject: [GRASS-dev] [bug #5483] (grass) g.mremove through gis manager GUI seems not to work well In-Reply-To: <45C9A4F3.5040304@itc.it> References: <20070207095911.CADFA1005C4@lists.intevation.de> <45C9A4F3.5040304@itc.it> Message-ID: <17865.59758.189673.884182@cerise.gclements.plus.com> Markus Neteler wrote: > > Subject: g.mremove through gis manager GUI seems not to work well > > > > Platform: GNU/Linux/ppc > > grass obtained from: Mirror of Trento site > > grass binary for platform: Compiled from Sources > > GRASS Version: GRASS6.2/6.3 > > > > Aldo Clerici. > > The command File > Manage maps and volumes > Remove maps using expressions and wildcards require an acknowledgment in the form: > > > > Collecting map names for current mapset .... > > g.remove rast=geology.new,slope.new > > Did you mean this (y/n)? > > > > But it seems not to accept any kind of input (y,yes,n,no). It seems to wait for something else. > > > > Aldo, > up to now interactive input in tcl based dialogs is not possible. > Using the -f flag (force removal) you can delete also in gis.m. > > Probably we need to enforce -f somehow in gis.m - how to do that? I've committed a fix which removes the prompting code. The -f flag remains for compatibility but is ignored. -- Glynn Clements From michael.barton at asu.edu Wed Feb 7 16:14:54 2007 From: michael.barton at asu.edu (Michael Barton) Date: Wed Feb 7 16:14:59 2007 Subject: [GRASS-dev] [bug #5483] (grass) g.mremove through gis manager GUI seems not to work well In-Reply-To: <45C9A4F3.5040304@itc.it> Message-ID: These kinds of interactive questions and often extraneous warnings seem to be popping a lot recently. It's almost like they were built into the code but not being triggered and some recent change has triggered them. An especially annoying one warns me that map I am using is indeed the same map that I am using in the mapset where I'm working. The problem reported here hangs the code in the auto-generated gui dialogs for modules, not the general GIS Manager gui. I haven't ventured into that code much; Cedric Shock and Glynn Clements know it best. I suspect that you're right and the -f flag needs to be added as a default when the module is started without arguments (i.e., launches the module GUI). The odd thing is that this was not happening until recently. So the larger question is why are we now getting a lot of verbose warnings and interaction request that didn't happen before? Michael On 2/7/07 3:07 AM, "Markus Neteler" wrote: > Request Tracker wrote on 02/07/2007 10:59 AM: >> this bug's URL: http://intevation.de/rt/webrt?serial_num=5483 >> ------------------------------------------------------------------------- >> >> Subject: g.mremove through gis manager GUI seems not to work well >> >> Platform: GNU/Linux/ppc >> grass obtained from: Mirror of Trento site >> grass binary for platform: Compiled from Sources >> GRASS Version: GRASS6.2/6.3 >> >> Aldo Clerici. >> The command File > Manage maps and volumes > Remove maps using expressions >> and wildcards require an acknowledgment in the form: >> >> Collecting map names for current mapset .... >> g.remove rast=geology.new,slope.new >> Did you mean this (y/n)? >> >> But it seems not to accept any kind of input (y,yes,n,no). It seems to wait >> for something else. >> > > Aldo, > up to now interactive input in tcl based dialogs is not possible. > Using the -f flag (force removal) you can delete also in gis.m. > > Probably we need to enforce -f somehow in gis.m - how to do that? > > Markus > >> Same behaviour in grass6.2 and 6.3. >> The same command g.mremove in command line mode works well. >> >> >> -------------------------------------------- Managed by Request Tracker >> >> _______________________________________________ >> grass-dev mailing list >> grass-dev@grass.itc.it >> http://grass.itc.it/mailman/listinfo/grass-dev >> > > __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Wed Feb 7 16:15:43 2007 From: michael.barton at asu.edu (Michael Barton) Date: Wed Feb 7 16:15:50 2007 Subject: [GRASS-dev] [bug #5483] (grass) g.mremove through gis manager GUI seems not to work well In-Reply-To: <17865.59758.189673.884182@cerise.gclements.plus.com> Message-ID: I didn't read far enough in my mail list today. Thanks very much Glynn for fixing this. Michael On 2/7/07 7:59 AM, "Glynn Clements" wrote: > > Markus Neteler wrote: > >>> Subject: g.mremove through gis manager GUI seems not to work well >>> >>> Platform: GNU/Linux/ppc >>> grass obtained from: Mirror of Trento site >>> grass binary for platform: Compiled from Sources >>> GRASS Version: GRASS6.2/6.3 >>> >>> Aldo Clerici. >>> The command File > Manage maps and volumes > Remove maps using expressions >>> and wildcards require an acknowledgment in the form: >>> >>> Collecting map names for current mapset .... >>> g.remove rast=geology.new,slope.new >>> Did you mean this (y/n)? >>> >>> But it seems not to accept any kind of input (y,yes,n,no). It seems to wait >>> for something else. >>> >> >> Aldo, >> up to now interactive input in tcl based dialogs is not possible. >> Using the -f flag (force removal) you can delete also in gis.m. >> >> Probably we need to enforce -f somehow in gis.m - how to do that? > > I've committed a fix which removes the prompting code. The -f flag > remains for compatibility but is ignored. __________________________________________ 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 Feb 7 16:23:27 2007 From: michael.barton at asu.edu (Michael Barton) Date: Wed Feb 7 16:23:32 2007 Subject: [GRASS-dev] Re: winGRASS In-Reply-To: Message-ID: Paul, There are some aesthetic issues with aqua TclTk. It creates larger widgets with extra space around them, for example. There are also a few functionality issues, but not serious ones anymore (at least I don't think so). Because most GRASS users are working in Linux, I try to use the x11 version for development to make sure it 'looks good' in that platform. I should probably try the aqua version again to see how it is doing now. William's compilations of nviz always seem to work currently and mine always seem to fail. I think that the nviz part of the compilation does respect the --with-opengl=x11 or --with-opengl=aqua flag, but does not seem to respect the --with-tcltk-includes=/usr/local/tcltk/include and --with-tcltk-libs=/usr/local/tcltk/lib flags. It just goes to the system default. I don't know enough about tweaking compilation parameters to know how to fix this (In fact I don't hardly anything about tweaking compilation parameters). Michael On 2/7/07 5:20 AM, "Paul Kelly" wrote: > Hello Michael > If you use the --with-opengl=aqua configure option then nviz will use the > aqua Tcl/Tk, but I thought that was desired? > See William's comments here: > http://grass.itc.it/pipermail/grass-dev/2006-November/027480.html > > Perhaps William just compiled his in the brief period while it was > working, and now it is no longer working again? > > Just an idea > > Paul > > On Tue, 6 Feb 2007, Michael Barton wrote: > >> I have a problem like this on versions of GRASS that I compile myself on my >> Mac. It doesn't happen on versions that William Kyngesbury compiles. In my >> case, all of GRASS is correctly compiling against an x11 tcltk that I >> specify, but nviz insists on compiling against an aqua version also on my >> machine. It creates a bad nviz binary file (the one that Bob's script >> calls). I can substitute one that William compiles and all is well. Maybe >> something similar is happening to you? >> >> Michael >> >> >> On 2/6/07 5:39 PM, "Paul Kelly" wrote: >> >>> Another outstanding issue is Nviz. It was working on Windows for a while >>> (looked great with Michael's new user interface improvements) but since >>> Bob changed it back to the script startup rather than running the nviz.exe >>> executable directly it no longer works on Windows. In fact I recently >>> tried to revert those changes and found it still wouldn't work; got stuck >>> at the Please Wait screen. A pity, because there is probably very little >>> needs changed to have it working again. >> >> __________________________________________ >> 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 neteler at itc.it Wed Feb 7 16:51:00 2007 From: neteler at itc.it (Markus Neteler) Date: Wed Feb 7 16:51:04 2007 Subject: [GRASS-dev] Re: winGRASS In-Reply-To: <45C99864.40202@itc.it> References: <1451.164.15.134.77.1166435384.squirrel@geog-pc40.ulb.ac.be> <2087.164.15.134.77.1166441036.squirrel@geog-pc40.ulb.ac.be> <3359.164.15.134.77.1166451769.squirrel@geog-pc40.ulb.ac.be> <45C99864.40202@itc.it> Message-ID: <45C9F564.5010109@itc.it> Markus Neteler wrote on 02/07/2007 10:14 AM: > Paul, Moritz, all, > > I have added the vector-DB problem to > > http://grass.gdf-hannover.de/wiki/WinGRASS_Current_Status#What_is_missing.3F > > My suggestion is to maintain the list there updated. I have now also added Paul's comments on how to compile winGRASS natively: http://grass.gdf-hannover.de/wiki/WinGRASS_Current_Status -> Compilation Don't hesitate to update the page :-) Markus From tutey at o2.pl Wed Feb 7 16:51:33 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Wed Feb 7 16:51:36 2007 Subject: [GRASS-dev] v.digit: Could not set Tcl system encoding fixed In-Reply-To: <45C9995E.7010700@itc.it> References: <45C9995E.7010700@itc.it> Message-ID: <45C9F585.30406@o2.pl> Markus Neteler wrote: > Hi, > > Roberto Flor and me have fixed the bug > "v.digit: Could not set Tcl system encoding" > http://intevation.de/rt/webrt?serial_num=4110 > > Please test. I'll backport it to 6.2.x then. > > Note: For mysterious Tcl (?) reasons I cannot set iso8859-1 and iso8859-2 > but utf-8, iso8859-15, iso2210-jp, koi8-r, euc-jp etc work. > Maybe my installation... I confirm. Same happens on my instalation. tcl/tk 8.4.12, Ubuntu Dapper 32bit. Maciek From tutey at o2.pl Wed Feb 7 19:12:32 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Wed Feb 7 19:12:48 2007 Subject: [GRASS-dev] Re: [GRASS-user] how to clean vector file after reprojection In-Reply-To: <45C9FBDE.6000703@club.worldonline.be> References: <45C88D49.7050808@club.worldonline.be> <20070207123152.73566847.hamish_nospam@yahoo.com> <45C9E0BC.1050508@club.worldonline.be> <45C9FBDE.6000703@club.worldonline.be> Message-ID: <45CA1690.6020503@o2.pl> Moritz Lennert wrote: > http://moritz.homelinux.org/grass/source_v_digit2.jpg > > And zooming even further (I'm in the centimeter range there): > > http://moritz.homelinux.org/grass/source_v_digit3.jpg > > The lines are not closed, but they are still recognized as an area. > > I assume I must be getting something wrong here, but I don't really > understand what... Maritz, All, This *is* weird! There should be node between the boundaries on your last picture, which would connect them, and let the area be closed. Although not exactly the same issue, I sometimes too have problems with areas topology when editing data in v.digit or GRASS Edit /QGIS: after I split a boundary somewhere near a vertex (eg. on the corner of a rectangular area), to connect another boundary at this location, suddenly areas "get bad" after I snap a new boundary to that node. It it's almost 100% reproducible; please watch this screenkast to see what I mean: http://kufaya.googlepages.com/vdigit_bnd.html As you can see I'm not doing anything wrong. And all seems clean until I digitize the the 4th boundary. For absolutely no reason the topology of areas gets bad. And moving vertices around fixes that, after few blind guesses. Anybody can reproduce that? I can, on 4 machines with Ubuntu Dapper. The problem was here since I rememeber - on Mandrake when I was using it, then on Ubuntu Breezy, now Ubuntu Dapper. It is propably not a bug in v.digit, as the same problem crops out in QGIS. This reminds me of http://www.nabble.com/v.buffer-creates-artefact---bug--tf3141568.html#a8733836, where the area's topology seems OK in v.digit, but v.buffer cannot handle the input vector correctly until it's "touched by magic". Maybe Moritze's problem is another manifestation of the same bug? His boundary is green, which means all-snapped, but there is no node. What the heck? Maciek From woklist at kyngchaos.com Wed Feb 7 21:08:57 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Wed Feb 7 21:09:09 2007 Subject: [GRASS-dev] Re: [GRASS-user] problems using r.proj with large data set In-Reply-To: <17797.60295.671067.744836@cerise.gclements.plus.com> References: <009801c71a20$2e223d60$3e40ae80@ace.uiuc.edu> <7746318.post@talk.nabble.com> <457882F8.2020001@o2.pl> <17784.51544.421727.643216@cerise.gclements.plus.com> <17797.60295.671067.744836@cerise.gclements.plus.com> Message-ID: <9E06EBB8-9577-4146-AA53-0FC27855EC6F@kyngchaos.com> I just had a reason to try this out (nearly forgot about it). I'm a little confused - you say here that the cache size is fixed, yet there is an option to set the cache size (in MB) mentioned in the docs. Maybe this was added later? The docs should probably also be updated with info relevant to r.proj.seg, instead of being a straight copy of the r.proj description. On to trying to run it - tempfile problems (I recall seeing something about tempfiles on the list). In location saproj, mapset srtm. Projecting data from location world (LL proj), mapset sa, map sa (7.5GB): > r.proj.seg loc=world map=sa in=sa out=srtm Input Projection Parameters: blah blah Output Projection Parameters: blah blah Input: blah blah Output: blah blah ERROR: can't make mapset element .tmp/Sumomo.local (/Volumes/Guu/gis/grassdb/world/srtm/.tmp) [it doesn't get to the "Allocating memory and reading input map..." message] ... how the heck is it getting world/srtm as the current mapset (for creating temp files in)!? It should be saproj/srtm. Somehow the location is getting mixed up. > g.gisenv get=MAPSET srtm > g.gisenv get=LOCATION_NAME saproj return the correct values. On Dec 17, 2006, at 7:14 PM, Glynn Clements wrote: > I've added to CVS a modified version of r.proj named r.proj.seg. This > behaves identically to r.proj, but uses a tile cache rather than > reading the entire map into memory. > > Currently, each tile is 64 * 64 cells, and the size of the cache is > fixed at 2 * (nx + ny) tiles (where nx * ny is the size of the source > region in tiles), which I would expect to suffice for any realistic > transformation. > > [It will definitely suffice for any affine or "near"-affine > transformation. It would be useful to know what level of distortion > needs to be accommodated in practice.] > > Cache replacement is random (i.e. when a new tile is loaded, the tile > which it replaces is selected at random). In practice, random > replacement tends to work almost as well as an "optimal" algorithm, > but without the overhead of maintaining usage statistics, as well as > not having any degenerate cases. > > Suggestions for improvements and/or performance statistics for > "real-world" usage are welcome. > ----- William Kyngesburye http://www.kyngchaos.com/ "Oh, look, I seem to have fallen down a deep, dark hole. Now what does that remind me of? Ah, yes - life." - Marvin From tutey at o2.pl Wed Feb 7 21:46:28 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Wed Feb 7 21:46:40 2007 Subject: [GRASS-dev] Re: v.buffer creates artefact - bug? In-Reply-To: <2b3d8c1c0702050207x4d9b8eb9t3b4f78fa8c20773a@mail.gmail.com> References: <20070130101832.20040@gmx.net> <45BF48AB.9090109@itc.it> <45BFBD29.2030908@o2.pl> <2b3d8c1c0701301444i339e0d43tf3b95e63071be3c@mail.gmail.com> <45C0D19B.8080108@o2.pl> <45C228A7.2070500@o2.pl> <20070205224743.25c53be1.hamish_nospam@yahoo.com> <2b3d8c1c0702050207x4d9b8eb9t3b4f78fa8c20773a@mail.gmail.com> Message-ID: <45CA3AA4.803@o2.pl> Maris, Maris Nartiss wrote: > Hi all, > > I was palying a bit with bug-trigering vector and You can see results > in attachments - setting buffer to 10m will give different buffer top, > setting buffer to 1 m will return more annoying result and stopping > buffer process before clean is visible in third image. > > I also looked in v.buffer code, but my C skeelz are too lame to > undrstand it, but I noticed lot of comments with "TODO" and "Should > work like this". Also there is some stuff relaying on asumption, thath > some stuff is listed clockwise or counterclockwise, etc. I suppose this last thing might matter. Please note that the following ASCII vector is buffered bad (it's the one you have already tested, the infamous ditch_1205): B 4 600727.68682251 5677973.32091602 600739.16582305 5678137.49568095 600736.32863997 5678140.4618269 600730.63832718 5678056.67823368 B 2 600730.63832718 5678056.67823368 600725.02385533 5677974.01131491 C 1 1 600730.04890192 5678035.56666655 1 1205 B 2 600727.68682251 5677973.32091602 600725.02385533 5677974.01131491 While it's slightly different version (same coordinates, but a different order of vertices - it's well visible in meld/kdif/xdiff) is buffered fine. B 2 600730.63832718 5678056.67823368 600725.02385533 5677974.01131491 C 1 1 600730.04890192 5678035.56666655 1 1205 B 2 600727.68682251 5677973.32091602 600725.02385533 5677974.01131491 B 4 600727.68682251 5677973.32091602 600739.16582305 5678137.49568095 600736.32863997 5678140.4618269 600730.63832718 5678056.67823368 Can you try that? > 2007/2/5, Hamish : >> This probably isn't it, but I use CFLAGS="-g" to compile in debug info, >> which I think has the side effect of initing all memory to 0's which >> changes the expression of some memory bugs. I will try that tomorrow anyway. Who knows. Maciek From grass-bugs at intevation.de Wed Feb 7 22:53:16 2007 From: grass-bugs at intevation.de (Request Tracker) Date: Wed Feb 7 22:53:21 2007 Subject: [GRASS-dev] [bug #5485] (grass) v.overly with and operator sometimes produces wrong results Message-ID: <20070207215316.01ACA1005C9@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5485 ------------------------------------------------------------------------- Subject: v.overly with and operator sometimes produces wrong results Platform: GNU/Linux/x86_64 grass obtained from: Trento Italy site grass binary for platform: Compiled from Sources GRASS Version: 6.2.0 My name is Andras Fabian, and I use GRASS for a flight simulator project (see more info under http://www.alpilotx.de/documentation.html) Now I have observed, that in some rare situations, the following command "v.overlay -t ainput=pre_extract atype=area alayer=1 binput=biogeo_clip btype=area blayer=1 output=exportAlpine operator=and olayer=1,0,0 --overwrite" doesn't produce the expected result. To be more exact, it seems as if it turns one of the polygons inside out. To use the above command: pre_extract is a bunch of - mostly - smaller polygons already cut to a 1x1 degree tile. biogeo_clip is another large (usually only one) polygon, which was clipped to a 1x1 degree area (so essentially biogeo_clip often has 2-3 flat sides from 1x1 clipping area and the rest is some decently jagged line). So what I want with my command is: I would like to have all polygons from pre_extract which are inside biogeo_clip. This almost allays works - but not every time. And my observation is, that this happens in the rare situation when some boundary lines of biogeo_clip exactly overlap with pre_extract. If you need a test dataset (I suppose), which reproduces this behavior, please let me know. I have put it aside (copied the folders out of /vector subfolder of my working set) - I also saved the "bad result" exportAlpine. And this test is nice, because it is only only some 200Kb in size. Thank you, Andras Fabian -------------------------------------------- Managed by Request Tracker From hamish_nospam at yahoo.com Wed Feb 7 23:38:27 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Feb 7 23:43:32 2007 Subject: [GRASS-dev] [bug #5483] (grass) g.mremove through gis manager GUI seems not to work well In-Reply-To: <17865.59758.189673.884182@cerise.gclements.plus.com> References: <20070207095911.CADFA1005C4@lists.intevation.de> <45C9A4F3.5040304@itc.it> <17865.59758.189673.884182@cerise.gclements.plus.com> Message-ID: <20070208113827.56c056e0.hamish_nospam@yahoo.com> Aldo: > > > Subject: g.mremove through gis manager GUI seems not to work well > > > > > > The command File > Manage maps and volumes > Remove maps using > > > expressions and wildcards require an acknowledgment in the form: > > > > > > Collecting map names for current mapset .... > > > g.remove rast=geology.new,slope.new > > > Did you mean this (y/n)? > > > > > > But it seems not to accept any kind of input (y,yes,n,no). It > > > seems to wait for something else. Markus: > > up to now interactive input in tcl based dialogs is not possible. > > Using the -f flag (force removal) you can delete also in gis.m. > > > > Probably we need to enforce -f somehow in gis.m - how to do that? Glynn: > I've committed a fix which removes the prompting code. The -f flag > remains for compatibility but is ignored. I understand the push to remove interactive, but this one is a fairly important failsafe and I wouldn't mind it staying. With the -f flag a non-interactive mode is available. An -i or --interactive flag as rm uses could be added, but who would bother setting up an alias to use it? Problably not the new users who would benefit from it the most. To answer Markus's question, you can preset/hint an option's answer in the GUI by giving it on the command line and adding the --ui switch to force a GUI: g.mremove -f --ui I've backported a fix using this method to the 6.2 GUI menu.tcl: -command {execute "g.mremove -f --ui" }} .. as for 6.3, ? Hamish From hamish_nospam at yahoo.com Wed Feb 7 23:42:56 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Feb 7 23:48:23 2007 Subject: [GRASS-dev] [bug #5483] (grass) g.mremove through gis manager GUI seems not to work well In-Reply-To: References: <45C9A4F3.5040304@itc.it> Message-ID: <20070208114256.55f87bd9.hamish_nospam@yahoo.com> Michael Barton wrote: > > These kinds of interactive questions and often extraneous warnings > seem to be popping a lot recently. It's almost like they were built > into the code but not being triggered and some recent change has > triggered them. .. > The odd thing is that this was not happening until recently. So the > larger question is why are we now getting a lot of verbose warnings > and interaction request that didn't happen before? No, I think this is a long standing problem, nothing new. Maybe we are just getting wider testing of the 6.2 code now? > An especially annoying one warns me that map I am using is indeed the > same map that I am using in the mapset where I'm working. Can you cite a specfic command that triggers that & file it in a bug report? Hamish From hamish_nospam at yahoo.com Thu Feb 8 00:09:55 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Feb 8 00:20:13 2007 Subject: [GRASS-dev] Re: [GRASS-user] how to clean vector file after reprojection In-Reply-To: <45C9FBDE.6000703@club.worldonline.be> References: <45C88D49.7050808@club.worldonline.be> <20070207123152.73566847.hamish_nospam@yahoo.com> <45C9E0BC.1050508@club.worldonline.be> <45C9FBDE.6000703@club.worldonline.be> Message-ID: <20070208120955.15945773.hamish_nospam@yahoo.com> Moritz Lennert wrote: > http://moritz.homelinux.org/grass/source_display.jpg BTW, the change to little circles from "X"s in gis.m are very nice for point data, but can be a bit deceptive for centroids. e.g. a coastline with lots of tiny offshore islands along the coast, the circle symbols are bigger than the islands and the islands get "idealized". - is there a way in gis.m to paint the centroids differently than points? (keep them as "X"s) failing that, - is there a way in gis.m to disable centroid drawing by default? Hamish From paul-grass at stjohnspoint.co.uk Thu Feb 8 01:06:48 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Thu Feb 8 01:06:52 2007 Subject: [GRASS-dev] new ps.map border option In-Reply-To: <20070207203925.649c2def.hamish_nospam@yahoo.com> References: <20070207203925.649c2def.hamish_nospam@yahoo.com> Message-ID: On Wed, 7 Feb 2007, Hamish wrote: > Hi, > > ps.map now has an optional 'border' instruction to control the > existence, color, and width of the box around the map area. > > this resolves wish #3389. That's great! Will be a godsend to someone somewhere I'm sure. Paul From paul-grass at stjohnspoint.co.uk Thu Feb 8 01:16:58 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Thu Feb 8 01:17:01 2007 Subject: [GRASS-dev] g.rp In-Reply-To: <20070207150258.3c310a09.hamish_nospam@yahoo.com> References: <20070205200634.7217027e.hamish_nospam@yahoo.com> <20070206200326.78e44b29.hamish_nospam@yahoo.com> <20070207150258.3c310a09.hamish_nospam@yahoo.com> Message-ID: On Wed, 7 Feb 2007, Hamish wrote: >> Actually the function GPJ_get_default_datum_params_by_name() in >> lib/proj/datum.c returns a "default", which for various reasons is >> actually the last in the list... > > As long as there is some hinting, we can make the rest happen in code. > It shouldn't be too hard to reindex the list. (he says not having looked > at the code :) No not hard at all. In fact I have just changed it. The original thinking was that since the "default" parameters were unlikely to be optimum it made sense to put them at the end of the list so the user didn't consider them a good default choice. But it isn't that important especially since we've added the more informative comment about being unlikely to be optimum. >>> If multiple options the GUI would create a dialog from the list, >>> then create the new location with: >>> g.proj -c loc=newLoc epsg=#### datumtrans=2 >>> or >>> g.proj -c loc=newLoc epsg=#### datumtrans=conus # ??? >>> >>> Not sure if it should take text "list,conus,etc". >>> Probably that is unneeded pain. Aliasing "list" to "0" would be nice >> >> Yes I see where you're coming from, I think. If the first item in the >> list was the default anyway this would work out nicely. Maybe >> omitting the datumtrans option could mean use the default instead of >> datumtrans=1? > > Well my idea was put the default first and when combined with > ->answer="1" it happens automatically. I'd prefer to use the parser to > pick the default answer rather than it happen somewhere inside the black > box, but it guess it doesn't have to. Yes that is very neat, I agree (and have changed the order of the list as mentioned above). > My main goal was that the default parm should be the default option, > regardless of order. The easiest way to have that happen is to call it > "1" and have parm->answer="1" in the option's parser def'n, after making > sure the default parm comes first. > >> I think a solution acceptable to everyone is gradually forming over >> time. This is what I hoped would happen! > > It would be nice. I guess another thing missing is region setting > code to replace E_edit_cellhd(). More g.proj -c options? > region=n,s,e,w > nsres= > ewres= I think I would prefer Helena's solution of adding a flag to g.region to allow it to set the default region. The GUI could then call g.region on the new location (after updating .grassrc) following its creation with g.proj. > Also we need to have a replacement GUI top-down location creation method > (pick type, then projection, then datum), vs the bottom-up EPSG code way. > > Maybe a g.listproj module that would give existing type, SP, proj lists > from lib fns in a CSV or other GUI parsable format? > e.g. this would call a non-paged version of lib/gis/get_projname.c: > g.listproj type=projections > or > g.listproj type=state_plane > ?? If the way the new datumtrans flag works for g.proj is a success it could probably be done in a very similar way, using library functions in lib/proj/ellipse.c and lib/proj/datum.c to read the system ellipsoid and datum tables. Maybe - I haven't really thought it through. Might get a bit out of hand. Paul From paul-grass at stjohnspoint.co.uk Thu Feb 8 01:20:27 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Thu Feb 8 01:20:31 2007 Subject: [GRASS-dev] [bug #5483] (grass) g.mremove through gis manager GUI seems not to work well In-Reply-To: <20070208113827.56c056e0.hamish_nospam@yahoo.com> References: <20070207095911.CADFA1005C4@lists.intevation.de> <45C9A4F3.5040304@itc.it> <17865.59758.189673.884182@cerise.gclements.plus.com> <20070208113827.56c056e0.hamish_nospam@yahoo.com> Message-ID: On Thu, 8 Feb 2007, Hamish wrote: > Markus: >>> up to now interactive input in tcl based dialogs is not possible. >>> Using the -f flag (force removal) you can delete also in gis.m. >>> >>> Probably we need to enforce -f somehow in gis.m - how to do that? > > Glynn: >> I've committed a fix which removes the prompting code. The -f flag >> remains for compatibility but is ignored. > > I understand the push to remove interactive, but this one is a fairly > important failsafe and I wouldn't mind it staying. With the -f flag a I agree this seems a bit of a dangerous change, especially since an easy workaround was available... hope it doesn't catch anybody out who is just experimenting with a wildcard pattern but not sure if it's the one they want! I know I have used it like that in the past anyway. > non-interactive mode is available. An -i or --interactive flag as rm > uses could be added, but who would bother setting up an alias to use it? > Problably not the new users who would benefit from it the most. > > > To answer Markus's question, you can preset/hint an option's answer in > the GUI by giving it on the command line and adding the --ui switch to > force a GUI: > > g.mremove -f --ui > > I've backported a fix using this method to the 6.2 GUI menu.tcl: > -command {execute "g.mremove -f --ui" }} > > > .. as for 6.3, ? > > > Hamish > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > From hamish_nospam at yahoo.com Thu Feb 8 05:12:43 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Feb 8 05:12:47 2007 Subject: [GRASS-dev] WxPython front-end to ps.map In-Reply-To: <45C9ED30.1090506@o2.pl> References: <20070207203925.649c2def.hamish_nospam@yahoo.com> <45C9ED30.1090506@o2.pl> Message-ID: <20070208171243.23fc25cf.hamish_nospam@yahoo.com> Hamish: > > ps.map now has an optional 'border' instruction to control the > > existence, color, and width of the box around the map area. Paul: > That's great! Will be a godsend to someone somewhere I'm sure. The next step is to write a wxPython GUI cartographic composer frontend which will create a ps.map instructions file and run that to create a PostScript file. ps.map can make very professional hardcopy maps, but it needs a user friendly front-end. see http://grass.gdf-hannover.de/wiki/GRASS_GUI#Components There was a TclTk start for this in d.m, gui/tcltk/d.m/print.tcl. This is not meant replace a Print button for the current display monitor, it's a stand alone hardcopy plot generator. That print button could write to a ps.map file, but maybe it is very easy to write directly to PostScript from the map canvas, like Michael has done for gis.m? Hamish From hamish_nospam at yahoo.com Thu Feb 8 05:28:34 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Feb 8 05:28:40 2007 Subject: [GRASS-dev] g.proj to create a new location In-Reply-To: References: <20070205200634.7217027e.hamish_nospam@yahoo.com> <20070206200326.78e44b29.hamish_nospam@yahoo.com> <20070207150258.3c310a09.hamish_nospam@yahoo.com> Message-ID: <20070208172834.0eb44e14.hamish_nospam@yahoo.com> Paul Kelly wrote: > The original thinking was that since the "default" parameters were > unlikely to be optimum it made sense to put them at the end of the > list so the user didn't consider them a good default choice. But it > isn't that important especially since we've added the more > informative comment about being unlikely to be optimum. Hmm. Is the default based on logic or is it just picked as the first listed in the file, or something like that? If it is random we can keep the code simpler. Keeping the first entry as default means that the datumtrans= option (and thus GUI) can be skipped in the case there is only one option. H: > > It would be nice. I guess another thing missing is region setting > > code to replace E_edit_cellhd(). More g.proj -c options? P: > I think I would prefer Helena's solution of adding a flag to g.region > to allow it to set the default region. The GUI could then call > g.region on the new location (after updating .grassrc) following its > creation with g.proj. Yes, that's better. The new location would have to be created and switched into before running g.region in PERMANENT, and then the GUI wizard would take you on to creating a user mapset before switching into that and launching a new GRASS session. > If the way the new datumtrans flag works for g.proj is a success it > could probably be done in a very similar way, using library functions > in lib/proj/ellipse.c and lib/proj/datum.c to read the system > ellipsoid and datum tables. Maybe - I haven't really thought it > through. Might get a bit out of hand. Well, we can get the epsg= and datumtrans= options working, and then worry about those issues- maybe we will learn some along the way. It may be that g.proj is not the best place to put a top-down chooser and we'd need a new module "g.newlocation" or something? Hamish From neteler at itc.it Thu Feb 8 08:44:56 2007 From: neteler at itc.it (Markus Neteler) Date: Thu Feb 8 08:44:58 2007 Subject: [GRASS-dev] v.digit: Could not set Tcl system encoding fixed In-Reply-To: <45C9F585.30406@o2.pl> References: <45C9995E.7010700@itc.it> <45C9F585.30406@o2.pl> Message-ID: <45CAD4F8.5050400@itc.it> Maciej Sieczka wrote on 02/07/2007 04:51 PM: > Markus Neteler wrote: > >> Hi, >> >> Roberto Flor and me have fixed the bug >> "v.digit: Could not set Tcl system encoding" >> http://intevation.de/rt/webrt?serial_num=4110 >> >> Please test. I'll backport it to 6.2.x then. >> >> Note: For mysterious Tcl (?) reasons I cannot set iso8859-1 and iso8859-2 >> but utf-8, iso8859-15, iso2210-jp, koi8-r, euc-jp etc work. >> Maybe my installation... >> > > I confirm. Same happens on my instalation. tcl/tk 8.4.12, Ubuntu Dapper > 32bit. > So we are happy since most of the encodings now work. Markus From maris.gis at gmail.com Thu Feb 8 08:58:01 2007 From: maris.gis at gmail.com (Maris Nartiss) Date: Thu Feb 8 08:58:04 2007 Subject: [GRASS-dev] Re: v.buffer creates artefact - bug? In-Reply-To: <45CA3AA4.803@o2.pl> References: <20070130101832.20040@gmx.net> <45BF48AB.9090109@itc.it> <45BFBD29.2030908@o2.pl> <2b3d8c1c0701301444i339e0d43tf3b95e63071be3c@mail.gmail.com> <45C0D19B.8080108@o2.pl> <45C228A7.2070500@o2.pl> <20070205224743.25c53be1.hamish_nospam@yahoo.com> <2b3d8c1c0702050207x4d9b8eb9t3b4f78fa8c20773a@mail.gmail.com> <45CA3AA4.803@o2.pl> Message-ID: <2b3d8c1c0702072358m7962bdaey8b8aa7e630b51f3c@mail.gmail.com> Hi Maciej, I imported both ascii snippets with v.in.ascii -n format=standard and they looked like same. Created buffer with size=1 and type=area. Results where same as in my previous tests. For first ascii snippet, I got shrinked vector area (like removed vector from inside of area) plus the mystic circle in middle. Second one - good order - worked as expected - I got correct buffer. It seems, that v.buffer expects some features to be in right order(tm). Next thing to find is it v.buffer specific or it's a design failure in V_lib. As I wrote already, v.* code is a bit more complex than I can understand - no help form me, just testing. I will recompile my GRASS too with -g CFLAG and repeat test. If result will differ, I will report. Maris. 2007/2/7, Maciej Sieczka : > Maris, > > Maris Nartiss wrote: > > Hi all, > > > > I was palying a bit with bug-trigering vector and You can see results > > in attachments - setting buffer to 10m will give different buffer top, > > setting buffer to 1 m will return more annoying result and stopping > > buffer process before clean is visible in third image. > > > > I also looked in v.buffer code, but my C skeelz are too lame to > > undrstand it, but I noticed lot of comments with "TODO" and "Should > > work like this". Also there is some stuff relaying on asumption, thath > > some stuff is listed clockwise or counterclockwise, etc. > > I suppose this last thing might matter. Please note that the following > ASCII vector is buffered bad (it's the one you have already tested, the > infamous ditch_1205): > > B 4 > 600727.68682251 5677973.32091602 > 600739.16582305 5678137.49568095 > 600736.32863997 5678140.4618269 > 600730.63832718 5678056.67823368 > B 2 > 600730.63832718 5678056.67823368 > 600725.02385533 5677974.01131491 > C 1 1 > 600730.04890192 5678035.56666655 > 1 1205 > B 2 > 600727.68682251 5677973.32091602 > 600725.02385533 5677974.01131491 > > While it's slightly different version (same coordinates, but a > different order of vertices - it's well visible in meld/kdif/xdiff) is > buffered fine. > > B 2 > 600730.63832718 5678056.67823368 > 600725.02385533 5677974.01131491 > C 1 1 > 600730.04890192 5678035.56666655 > 1 1205 > B 2 > 600727.68682251 5677973.32091602 > 600725.02385533 5677974.01131491 > B 4 > 600727.68682251 5677973.32091602 > 600739.16582305 5678137.49568095 > 600736.32863997 5678140.4618269 > 600730.63832718 5678056.67823368 > > Can you try that? > > > 2007/2/5, Hamish : > > >> This probably isn't it, but I use CFLAGS="-g" to compile in debug info, > >> which I think has the side effect of initing all memory to 0's which > >> changes the expression of some memory bugs. > > I will try that tomorrow anyway. Who knows. > > Maciek > From mlennert at club.worldonline.be Thu Feb 8 10:00:07 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Thu Feb 8 09:57:46 2007 Subject: [GRASS-dev] Re: [GRASS-user] how to clean vector file after reprojection In-Reply-To: <20070208120955.15945773.hamish_nospam@yahoo.com> References: <45C88D49.7050808@club.worldonline.be> <20070207123152.73566847.hamish_nospam@yahoo.com> <45C9E0BC.1050508@club.worldonline.be> <45C9FBDE.6000703@club.worldonline.be> <20070208120955.15945773.hamish_nospam@yahoo.com> Message-ID: <45CAE697.2090900@club.worldonline.be> On 08/02/07 00:09, Hamish wrote: > Moritz Lennert wrote: >> http://moritz.homelinux.org/grass/source_display.jpg > > > BTW, the change to little circles from "X"s in gis.m are very nice for > point data, but can be a bit deceptive for centroids. > > e.g. a coastline with lots of tiny offshore islands along the coast, the > circle symbols are bigger than the islands and the islands get > "idealized". > > - is there a way in gis.m to paint the centroids differently than > points? (keep them as "X"s) just chose whatever symbol you like > > failing that, > > - is there a way in gis.m to disable centroid drawing by default? What is wrong with just disabling the 'centroid' button ? Moritz From jachym.cepicky at gmail.com Thu Feb 8 10:11:46 2007 From: jachym.cepicky at gmail.com (=?ISO-8859-2?Q?J=E1chym_=C8epick=FD?=) Date: Thu Feb 8 10:11:47 2007 Subject: [GRASS-dev] WxPython front-end to ps.map In-Reply-To: <20070208171243.23fc25cf.hamish_nospam@yahoo.com> References: <20070207203925.649c2def.hamish_nospam@yahoo.com> <45C9ED30.1090506@o2.pl> <20070208171243.23fc25cf.hamish_nospam@yahoo.com> Message-ID: hi, 2007/2/8, Hamish : > Hamish: > > > ps.map now has an optional 'border' instruction to control the > > > existence, color, and width of the box around the map area. > > Paul: > > That's great! Will be a godsend to someone somewhere I'm sure. > > The next step is to write a wxPython GUI cartographic composer frontend > which will create a ps.map instructions file and run that to create a > PostScript file. ps.map can make very professional hardcopy maps, but it > needs a user friendly front-end. > > see > http://grass.gdf-hannover.de/wiki/GRASS_GUI#Components > > There was a TclTk start for this in d.m, gui/tcltk/d.m/print.tcl. > > This is not meant replace a Print button for the current display > monitor, it's a stand alone hardcopy plot generator. That print button > could write to a ps.map file, but maybe it is very easy to write > directly to PostScript from the map canvas, like Michael has done for > gis.m? > > > Hamish > As soon as new map display class will be defined in wxPython, I would like to build georectifing, ps.map and digitizing tool on top of it. Michael is currently working on it. We are using wxPython 2.8, and there are small problems with this version on debian-based distros (compilation works well, but the packaging system does not like some definitions). Jachym -- Jachym Cepicky e-mail: jachym.cepicky gmail com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub From mlennert at club.worldonline.be Thu Feb 8 10:26:05 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Thu Feb 8 10:23:45 2007 Subject: [GRASS-dev] WxPython front-end to ps.map In-Reply-To: References: <20070207203925.649c2def.hamish_nospam@yahoo.com> <45C9ED30.1090506@o2.pl> <20070208171243.23fc25cf.hamish_nospam@yahoo.com> Message-ID: <45CAECAD.7020505@club.worldonline.be> On 08/02/07 10:11, J?chym ?epick? wrote: > hi, > > 2007/2/8, Hamish : >> Hamish: >> > > ps.map now has an optional 'border' instruction to control the >> > > existence, color, and width of the box around the map area. >> >> Paul: >> > That's great! Will be a godsend to someone somewhere I'm sure. >> >> The next step is to write a wxPython GUI cartographic composer frontend >> which will create a ps.map instructions file and run that to create a >> PostScript file. ps.map can make very professional hardcopy maps, but it >> needs a user friendly front-end. >> >> see >> http://grass.gdf-hannover.de/wiki/GRASS_GUI#Components >> >> There was a TclTk start for this in d.m, gui/tcltk/d.m/print.tcl. >> >> This is not meant replace a Print button for the current display >> monitor, it's a stand alone hardcopy plot generator. That print button >> could write to a ps.map file, but maybe it is very easy to write >> directly to PostScript from the map canvas, like Michael has done for >> gis.m? Yes, but currently what is written from the map canvas is the rasterized PNG image, not the original vector information, which makes working on the resulting ps file in a vector graphics program impossible... > > As soon as new map display class will be defined in wxPython, I would > like to build georectifing, ps.map and digitizing tool on top of it. > Is there any possibility of changing the display system so that vector data is displayed as such in the display or at least the content of the display could be directly exported to ps or pdf as vector ? Just naive questions, but this might determine whether it is better to concentrate on a ps.map frontend or on direct vector export of the display. Moritz From jachym.cepicky at gmail.com Thu Feb 8 10:52:00 2007 From: jachym.cepicky at gmail.com (=?ISO-8859-2?Q?J=E1chym_=C8epick=FD?=) Date: Thu Feb 8 10:52:03 2007 Subject: [GRASS-dev] WxPython front-end to ps.map In-Reply-To: <45CAECAD.7020505@club.worldonline.be> References: <20070207203925.649c2def.hamish_nospam@yahoo.com> <45C9ED30.1090506@o2.pl> <20070208171243.23fc25cf.hamish_nospam@yahoo.com> <45CAECAD.7020505@club.worldonline.be> Message-ID: hi > >> This is not meant replace a Print button for the current display > >> monitor, it's a stand alone hardcopy plot generator. That print button > >> could write to a ps.map file, but maybe it is very easy to write > >> directly to PostScript from the map canvas, like Michael has done for > >> gis.m? > > Yes, but currently what is written from the map canvas is the rasterized > PNG image, not the original vector information, which makes working on > the resulting ps file in a vector graphics program impossible... > > > > > As soon as new map display class will be defined in wxPython, I would > > like to build georectifing, ps.map and digitizing tool on top of it. > > > > Is there any possibility of changing the display system so that vector > data is displayed as such in the display or at least the content of the > display could be directly exported to ps or pdf as vector ? > > Just naive questions, but this might determine whether it is better to > concentrate on a ps.map frontend or on direct vector export of the display. > > Moritz > well, this puts us back to discussion about basic GUI concept. The chosen one, Python+some graphical library (currently wxWidgets) stands for * fast development * more people able to help with the development: it will be always easier to learn python, then C(++) and it's usage together with Qt/wxWdigets/Gtk+/... but there are also some disadvantages: * the gui will be never as fast as compiled one * since there is no properly working swig interface, it would be very difficult to access raster and vector data with help of Python. But it would be very difficult to rewrite whole d.vect module in any other language. I would say, if we would need to rewrite Map Displays so they access raster and vector files directly, we would need to code this parts in C. It would take us too much time IMHO. My imagination is, to use Map Display with pop-up tool bar(s) for specific tools -- if there is someone, who disagrees with this point, please raise your hand. ps.map is very good tool for creation of hard-copy maps. It should not be too big task to add tool, which would generate configuration file for ps.map based on map display content. For the future, it would be good to improve d.vect to be able to display e.g. dashed lines and so on and to improve ps.map so it is possible to work with multiple raster tiles and so on. Just my 2 cents Jachym -- Jachym Cepicky e-mail: jachym.cepicky gmail com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub From hamish_nospam at yahoo.com Thu Feb 8 11:06:09 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Feb 8 11:06:33 2007 Subject: [GRASS-dev] Re: [GRASS-user] how to clean vector file after reprojection In-Reply-To: <45CAE697.2090900@club.worldonline.be> References: <45C88D49.7050808@club.worldonline.be> <20070207123152.73566847.hamish_nospam@yahoo.com> <45C9E0BC.1050508@club.worldonline.be> <45C9FBDE.6000703@club.worldonline.be> <20070208120955.15945773.hamish_nospam@yahoo.com> <45CAE697.2090900@club.worldonline.be> Message-ID: <20070208230609.54f2f145.hamish_nospam@yahoo.com> Moritz Lennert wrote: > > - is there a way in gis.m to paint the centroids differently than > > points? (keep them as "X"s) > > just chose whatever symbol you like > > > failing that, > > - is there a way in gis.m to disable centroid drawing by default? > > What is wrong with just disabling the 'centroid' button ? .. it should plot nicely by default .. Hamish From hamish_nospam at yahoo.com Thu Feb 8 11:43:13 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Feb 8 11:43:18 2007 Subject: [GRASS-dev] g.proj to create a new location In-Reply-To: References: <20070205200634.7217027e.hamish_nospam@yahoo.com> <20070206200326.78e44b29.hamish_nospam@yahoo.com> <20070207150258.3c310a09.hamish_nospam@yahoo.com> Message-ID: <20070208234313.6073c8d4.hamish_nospam@yahoo.com> I have now added new epsg= and datumtrans= options to g.proj in CVS. The epsg= option to create new location by EPSG code is fully functional: (it just plugs the code into a PROJ4 format string) G63> g.proj -c loc=newlocNZTM epsg=2193 Location newlocNZTM created! If it needs more info WRT datum transform options, it currently goes interactive as the datumtrans= option to list or select datum transform parms is not yet functional. Paul, can you try and connect this to get_datum_transform_by_name() and GPJ_ask_datum_params(), or wherever the number needs to get to? Mucho gracias. I guess we can ignore custom transform parms, they can be specified using the proj4= option. Hamish From mlennert at club.worldonline.be Thu Feb 8 11:54:14 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Thu Feb 8 11:51:53 2007 Subject: [GRASS-dev] WxPython front-end to ps.map In-Reply-To: References: <20070207203925.649c2def.hamish_nospam@yahoo.com> <45C9ED30.1090506@o2.pl> <20070208171243.23fc25cf.hamish_nospam@yahoo.com> <45CAECAD.7020505@club.worldonline.be> Message-ID: <45CB0156.7070506@club.worldonline.be> On 08/02/07 10:52, J?chym ?epick? wrote: > hi > >> >> This is not meant replace a Print button for the current display >> >> monitor, it's a stand alone hardcopy plot generator. That print button >> >> could write to a ps.map file, but maybe it is very easy to write >> >> directly to PostScript from the map canvas, like Michael has done for >> >> gis.m? >> >> Yes, but currently what is written from the map canvas is the rasterized >> PNG image, not the original vector information, which makes working on >> the resulting ps file in a vector graphics program impossible... >> >> > >> > As soon as new map display class will be defined in wxPython, I would >> > like to build georectifing, ps.map and digitizing tool on top of it. >> > >> >> Is there any possibility of changing the display system so that vector >> data is displayed as such in the display or at least the content of the >> display could be directly exported to ps or pdf as vector ? >> >> Just naive questions, but this might determine whether it is better to >> concentrate on a ps.map frontend or on direct vector export of the >> display. >> >> Moritz >> > > well, this puts us back to discussion about basic GUI concept. The > chosen one, Python+some graphical library (currently wxWidgets) stands > for > > * fast development > * more people able to help with the development: it will be always > easier to learn python, then C(++) and it's usage together with > Qt/wxWdigets/Gtk+/... > > but there are also some disadvantages: > > * the gui will be never as fast as compiled one > * since there is no properly working swig interface, it would be very > difficult to access raster and vector data with help of Python. But it > would be very difficult to rewrite whole d.vect module in any other > language. > > I would say, if we would need to rewrite Map Displays so they access > raster and vector files directly, we would need to code this parts in > C. It would take us too much time IMHO. > > My imagination is, to use Map Display with pop-up tool bar(s) for > specific tools -- if there is someone, who disagrees with this point, > please raise your hand. ps.map is very good tool for creation of > hard-copy maps. It should not be too big task to add tool, which would > generate configuration file for ps.map based on map display content. > > For the future, it would be good to improve d.vect to be able to > display e.g. dashed lines and so on and to improve ps.map so it is > possible to work with multiple raster tiles and so on. > Glynn has mentioned reflections on rewriting the whole display architecture (see http://grass.itc.it/pipermail/grass5/2006-May/023325.html). But I agree that until this is done, advancing with the combination of PNG/PPM displayed in map canvas + ps.map for output is probably the best solution. I also agree that ps.map needs a series of improvements[1] to make it really good for cartography...but I know that it's up to me to make them ;-) Moritz [1] one example: at this stage proportionate symbols are not drawn in descending order of size, thus potentially hiding smaller symbols. I corrected that in the new version of d.vect.chart I proposed, but it is still an issue in ps.map. This gets even more complicated when you want to add a color scheme to that as you have to use a separate vpoints command for each color and making sorting symbols by size almost impossible, but allowing the use of the RGB column in ps.map would solve that (I remember there being mails about this latter issue, but can't find them now). Maybe not a fundamental issue for most, but a show stopper for adopting GRASS as the main GIS and cartography tool here in my department where a lot of proportionate symbol maps are drawn. From glynn at gclements.plus.com Thu Feb 8 12:12:18 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Feb 8 12:12:22 2007 Subject: [GRASS-dev] Re: [GRASS-user] problems using r.proj with large data set In-Reply-To: <9E06EBB8-9577-4146-AA53-0FC27855EC6F@kyngchaos.com> References: <009801c71a20$2e223d60$3e40ae80@ace.uiuc.edu> <7746318.post@talk.nabble.com> <457882F8.2020001@o2.pl> <17784.51544.421727.643216@cerise.gclements.plus.com> <17797.60295.671067.744836@cerise.gclements.plus.com> <9E06EBB8-9577-4146-AA53-0FC27855EC6F@kyngchaos.com> Message-ID: <17867.1426.935411.652226@cerise.gclements.plus.com> William Kyngesburye wrote: > I just had a reason to try this out (nearly forgot about it). I'm a > little confused - you say here that the cache size is fixed, yet > there is an option to set the cache size (in MB) mentioned in the > docs. Maybe this was added later? Yes. The current version defauxts to 2*(nx+ny) blocks, but can be overriden via the memory= option. > The docs should probably also be updated with info relevant to > r.proj.seg, instead of being a straight copy of the r.proj description. The only thing that differs between the two is the memory= option. I'm not sure what needs to be said about that option beyond what's already in its description string. > On to trying to run it - tempfile problems (I recall seeing something > about tempfiles on the list). Right; it needs to create a temporary file. > In location saproj, mapset srtm. Projecting data from location world > (LL proj), mapset sa, map sa (7.5GB): > > > r.proj.seg loc=world map=sa in=sa out=srtm > > Input Projection Parameters: blah blah > Output Projection Parameters: blah blah > Input: blah blah > Output: blah blah > > ERROR: can't make mapset element .tmp/Sumomo.local > (/Volumes/Guu/gis/grassdb/world/srtm/.tmp) > > [it doesn't get to the "Allocating memory and reading input map..." > message] > > ... how the heck is it getting world/srtm as the current mapset (for > creating temp files in)!? It should be saproj/srtm. Somehow the > location is getting mixed up. Aha. r.proj.seg (and r.proj) both work by switching environments between the input and output locations. It appears to be creating the temporary file while the input location is active, when it should be using the output location (you may not have write permission for the input location). Thanks for discovering this; I'll apply the following as soon as I've tested it: --- raster/r.proj.seg/readcell.c 19 Dec 2006 13:24:54 -0000 1.3 +++ raster/r.proj.seg/readcell.c 8 Feb 2007 10:59:22 -0000 @@ -51,7 +51,10 @@ if (nblocks < nx * ny) { + /* Temporary file must be created in output location */ + G__switch_env(); filename = G_tempfile(); + G__switch_env(); c->fd = open(filename, O_RDWR|O_CREAT|O_EXCL, 0600); if (c->fd < 0) G_fatal_error("Unable to open temporary file"); -- Glynn Clements From glynn at gclements.plus.com Thu Feb 8 12:24:12 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Feb 8 12:27:46 2007 Subject: [GRASS-dev] Re: winGRASS In-Reply-To: References: Message-ID: <17867.2140.206218.11697@cerise.gclements.plus.com> Michael Barton wrote: > I think that the nviz part of the compilation does respect the > --with-opengl=x11 or --with-opengl=aqua flag, but does not seem to respect > the --with-tcltk-includes=/usr/local/tcltk/include and > --with-tcltk-libs=/usr/local/tcltk/lib flags. It just goes to the system > default. I don't know enough about tweaking compilation parameters to know > how to fix this (In fact I don't hardly anything about tweaking compilation > parameters). The NVIZ Makefile will add both sets of -I switches to the compilation command. Those switches will affect how all headers are located. You can't tell the compiler to look for specific headers in specific directories. I note that the NVIZ Makefile *doesn't* use $(OPENGLINC), which is almost certainly a bug. This doesn't affect the version of Tcl/Tk used for d.m/gis.m, which is determined at run-time by $GRASS_WISH. -- Glynn Clements From glynn at gclements.plus.com Thu Feb 8 12:33:47 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Feb 8 12:33:50 2007 Subject: [GRASS-dev] [bug #5483] (grass) g.mremove through gis manager GUI seems not to work well In-Reply-To: <20070208113827.56c056e0.hamish_nospam@yahoo.com> References: <20070207095911.CADFA1005C4@lists.intevation.de> <45C9A4F3.5040304@itc.it> <17865.59758.189673.884182@cerise.gclements.plus.com> <20070208113827.56c056e0.hamish_nospam@yahoo.com> Message-ID: <17867.2715.298187.307696@cerise.gclements.plus.com> Hamish wrote: > > > up to now interactive input in tcl based dialogs is not possible. > > > Using the -f flag (force removal) you can delete also in gis.m. > > > > > > Probably we need to enforce -f somehow in gis.m - how to do that? > > > I've committed a fix which removes the prompting code. The -f flag > > remains for compatibility but is ignored. > > I understand the push to remove interactive, but this one is a fairly > important failsafe and I wouldn't mind it staying. With the -f flag a > non-interactive mode is available. An -i or --interactive flag as rm > uses could be added, but who would bother setting up an alias to use it? > Problably not the new users who would benefit from it the most. A -i flag would be all well and good, *if* you could guarantee that there was a terminal from which to obtain the user's response. Fixing bugs (e.g. assuming the presence of a terminal) takes precedence over implementing wishes (e.g. a -i flag). There's also the issue that currently there's no way to tell the GUI that it needs to either hide the -i flag from the user, or use an xterm if the -i flag is enabled. Ultimately, a module is either interactive or it isn't. If it's even slightly interactive, then it's interactive, and that reduces its usability. > To answer Markus's question, you can preset/hint an option's answer in > the GUI by giving it on the command line and adding the --ui switch to > force a GUI: > > g.mremove -f --ui > > I've backported a fix using this method to the 6.2 GUI menu.tcl: > -command {execute "g.mremove -f --ui" }} What happens if the user deselects the -f switch from the GUI? Is there any way to kill the hung process? -- Glynn Clements From glynn at gclements.plus.com Thu Feb 8 12:41:52 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Feb 8 12:41:54 2007 Subject: [GRASS-dev] v.digit: Could not set Tcl system encoding fixed In-Reply-To: <45CAD4F8.5050400@itc.it> References: <45C9995E.7010700@itc.it> <45C9F585.30406@o2.pl> <45CAD4F8.5050400@itc.it> Message-ID: <17867.3200.384675.355130@cerise.gclements.plus.com> Markus Neteler wrote: > >> Roberto Flor and me have fixed the bug > >> "v.digit: Could not set Tcl system encoding" > >> http://intevation.de/rt/webrt?serial_num=4110 > >> > >> Please test. I'll backport it to 6.2.x then. > >> > >> Note: For mysterious Tcl (?) reasons I cannot set iso8859-1 and iso8859-2 > >> but utf-8, iso8859-15, iso2210-jp, koi8-r, euc-jp etc work. > >> Maybe my installation... > >> > > > > I confirm. Same happens on my instalation. tcl/tk 8.4.12, Ubuntu Dapper > > 32bit. > > So we are happy since most of the encodings now work. Not having ISO-8859-1 working is a pretty major issue. Can you provide more details, preferably including a recipe to reproduce the issue using either spearfish or a new location? -- Glynn Clements From hamish_nospam at yahoo.com Thu Feb 8 12:45:50 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Feb 8 12:45:57 2007 Subject: [GRASS-dev] WxPython front-end to ps.map In-Reply-To: References: <20070207203925.649c2def.hamish_nospam@yahoo.com> <45C9ED30.1090506@o2.pl> <20070208171243.23fc25cf.hamish_nospam@yahoo.com> Message-ID: <20070209004550.7bdb9b61.hamish_nospam@yahoo.com> J?chym ?epick? wrote: > As soon as new map display class will be defined in wxPython, I would > like to build georectifing, ps.map and digitizing tool on top of it. Great! > Michael is currently working on it. We are using wxPython 2.8, and > there are small problems with this version on debian-based distros > (compilation works well, but the packaging system does not like some > definitions). :-/ I was waiting for Debian/Etch to give it a try. That will ship with wx 2.6.3 (c.July 2006), so that will still not be enough? Is 2.8 full of goodies that the earlier versions from 6 months ago lack? > * since there is no properly working swig interface, it would be very > difficult to access raster and vector data with help of Python. If we will be doing heavy Python GUI programming it seems obvious to spend some time at the beginning getting the swig interface working properly, if currently it isn't. That would save us a lot of pain in the long run. Hamish From glynn at gclements.plus.com Thu Feb 8 12:48:45 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Feb 8 12:49:07 2007 Subject: [GRASS-dev] WxPython front-end to ps.map In-Reply-To: <45CAECAD.7020505@club.worldonline.be> References: <20070207203925.649c2def.hamish_nospam@yahoo.com> <45C9ED30.1090506@o2.pl> <20070208171243.23fc25cf.hamish_nospam@yahoo.com> <45CAECAD.7020505@club.worldonline.be> Message-ID: <17867.3613.858298.118086@cerise.gclements.plus.com> Moritz Lennert wrote: > > As soon as new map display class will be defined in wxPython, I would > > like to build georectifing, ps.map and digitizing tool on top of it. > > Is there any possibility of changing the display system so that vector > data is displayed as such in the display or at least the content of the > display could be directly exported to ps or pdf as vector ? No. At least, not in the short/medium term. You're talking about a completely new display architecture. The current architecture is entirely unsuitable for writing a PostScript/PDF/SVG/etc "driver". Note that any display architecture which *was* suitable for generating PostScript/etc output would be rule out the use of G_plot_polygon() etc for rendering, so d.vect would need to be fixed. -- Glynn Clements From mlennert at club.worldonline.be Thu Feb 8 14:11:00 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Thu Feb 8 14:08:51 2007 Subject: [GRASS-dev] gis.m: error message when trying to add layer without open map display Message-ID: <45CB2164.2010205@club.worldonline.be> Michael, Since you have been busy working on error catching in gis.m: I've always found that the error that occurs when you try to add a layer even though there is no open map display quite difficult to understand for newbies: invalid command name ".mainframe.frame.pw1.f0.frame.pgs.fpage_1.sw.tree_1" invalid command name ".mainframe.frame.pw1.f0.frame.pgs.fpage_1.sw.tree_1" while executing "$tree($mon) selection get" (procedure "GmTree::add" line 11) invoked from within "GmTree::add vector" ("uplevel" body line 1) invoked from within "uplevel \#0 $cmd" (procedure "Button::_release" line 18) invoked from within "Button::_release .mainframe.topf.tb0.bbox2.b0" (command bound to event) Would it be possible to catch this and produce a nicer error message such as: "You need to open a map display first." ? Moritz From neteler at itc.it Thu Feb 8 15:43:02 2007 From: neteler at itc.it (Markus Neteler) Date: Thu Feb 8 15:43:05 2007 Subject: [GRASS-dev] v.digit: Could not set Tcl system encoding fixed In-Reply-To: <17867.3200.384675.355130@cerise.gclements.plus.com> References: <45C9995E.7010700@itc.it> <45C9F585.30406@o2.pl> <45CAD4F8.5050400@itc.it> <17867.3200.384675.355130@cerise.gclements.plus.com> Message-ID: <45CB36F6.1070906@itc.it> Glynn Clements wrote on 02/08/2007 12:41 PM: > Markus Neteler wrote: > > >>>> Roberto Flor and me have fixed the bug >>>> "v.digit: Could not set Tcl system encoding" >>>> http://intevation.de/rt/webrt?serial_num=4110 >>>> >>>> Please test. I'll backport it to 6.2.x then. >>>> >>>> Note: For mysterious Tcl (?) reasons I cannot set iso8859-1 and iso8859-2 >>>> but utf-8, iso8859-15, iso2210-jp, koi8-r, euc-jp etc work. >>>> Maybe my installation... >>>> >>>> >>> I confirm. Same happens on my instalation. tcl/tk 8.4.12, Ubuntu Dapper >>> 32bit. >>> >> So we are happy since most of the encodings now work. >> > > Not having ISO-8859-1 working is a pretty major issue. > I am still not sure if it is a local problem or a general one or depends on the tcltk version. > Can you provide more details, preferably including a recipe to > reproduce the issue using either spearfish or a new location? > Sure (eg Spearfish): d.mon x0 v.digit -n newmap # now go to "Settings" icon, "Table" tab, "Add column", add a column of your choice, "Create table" # close the "Settings" window # digitize a line # enter a value into the attribute popup form # "submit button" (default is utf-8 which seems to work) # change the encoding, click "submit button" again and voila' the error appear in the terminal Markus From jachym.cepicky at gmail.com Thu Feb 8 15:53:58 2007 From: jachym.cepicky at gmail.com (=?ISO-8859-2?Q?J=E1chym_=C8epick=FD?=) Date: Thu Feb 8 15:54:33 2007 Subject: [GRASS-dev] v.to.rast with colors from GRASSRGB column Message-ID: Hi, this patch adds support for raster color rules based on values stored in database table in defined column to v.to.rast module example usage: v.to.rast in=jgeology out=tmp --o use=attr column=cat -a I hope it is worth to add this to cvs. Adding support for labels should not be big problem any more. Jachym -- Jachym Cepicky e-mail: jachym.cepicky gmail com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub -------------- next part -------------- A non-text attachment was scrubbed... Name: v.to.rast.diff Type: text/x-patch Size: 9712 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070208/42ed5bb5/v.to.rast-0001.bin From woklist at kyngchaos.com Thu Feb 8 16:11:18 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Thu Feb 8 16:11:36 2007 Subject: [GRASS-dev] Re: [GRASS-user] problems using r.proj with large data set In-Reply-To: <17867.1426.935411.652226@cerise.gclements.plus.com> References: <009801c71a20$2e223d60$3e40ae80@ace.uiuc.edu> <7746318.post@talk.nabble.com> <457882F8.2020001@o2.pl> <17784.51544.421727.643216@cerise.gclements.plus.com> <17797.60295.671067.744836@cerise.gclements.plus.com> <9E06EBB8-9577-4146-AA53-0FC27855EC6F@kyngchaos.com> <17867.1426.935411.652226@cerise.gclements.plus.com> Message-ID: On Feb 8, 2007, at 5:12 AM, Glynn Clements wrote: >> The docs should probably also be updated with info relevant to >> r.proj.seg, instead of being a straight copy of the r.proj >> description. > > The only thing that differs between the two is the memory= option. I'm > not sure what needs to be said about that option beyond what's already > in its description string. > maybe mention it in the description? Other than the memory option and name >> In location saproj, mapset srtm. Projecting data from location world >> (LL proj), mapset sa, map sa (7.5GB): >> >>> r.proj.seg loc=world map=sa in=sa out=srtm >> >> Input Projection Parameters: blah blah >> Output Projection Parameters: blah blah >> Input: blah blah >> Output: blah blah >> >> ERROR: can't make mapset element .tmp/Sumomo.local >> (/Volumes/Guu/gis/grassdb/world/srtm/.tmp) >> >> [it doesn't get to the "Allocating memory and reading input map..." >> message] >> >> ... how the heck is it getting world/srtm as the current mapset (for >> creating temp files in)!? It should be saproj/srtm. Somehow the >> location is getting mixed up. > > Aha. > > r.proj.seg (and r.proj) both work by switching environments between > the input and output locations. It appears to be creating the > temporary file while the input location is active, when it should be > using the output location (you may not have write permission for the > input location). > That's the odd part - it's really a combination of the input *location* and the output (current) *mapset* name. > Thanks for discovering this; I'll apply the following as soon as I've > tested it: > > --- raster/r.proj.seg/readcell.c 19 Dec 2006 13:24:54 -0000 1.3 > +++ raster/r.proj.seg/readcell.c 8 Feb 2007 10:59:22 -0000 > @@ -51,7 +51,10 @@ > > if (nblocks < nx * ny) > { > + /* Temporary file must be created in output location */ > + G__switch_env(); > filename = G_tempfile(); > + G__switch_env(); > c->fd = open(filename, O_RDWR|O_CREAT|O_EXCL, 0600); > if (c->fd < 0) > G_fatal_error("Unable to open temporary file"); > I didn't see the switch_env in main just before readcell is called (and might not have realized what it meant had seen it). I'll give this a try, it'll help project the second have of this project today if it works. Since you didn't get any response before, I'll try some timing tests to compare r.proj and r.proj.seg, and compare the data generated, some time in the next week or so. ----- William Kyngesburye http://www.kyngchaos.com/ [Trillian] What are you supposed to do WITH a maniacally depressed robot? [Marvin] You think you have problems? What are you supposed to do if you ARE a maniacally depressed robot? No, don't try and answer, I'm 50,000 times more intelligent than you and even I don't know the answer... - HitchHiker's Guide to the Galaxy From neteler at itc.it Thu Feb 8 16:20:38 2007 From: neteler at itc.it (Markus Neteler) Date: Thu Feb 8 16:20:39 2007 Subject: [GRASS-dev] WxPython front-end to ps.map In-Reply-To: <20070209004550.7bdb9b61.hamish_nospam@yahoo.com> References: <20070207203925.649c2def.hamish_nospam@yahoo.com> <45C9ED30.1090506@o2.pl> <20070208171243.23fc25cf.hamish_nospam@yahoo.com> <20070209004550.7bdb9b61.hamish_nospam@yahoo.com> Message-ID: <45CB3FC6.3020305@itc.it> Hamish wrote on 02/08/2007 12:45 PM: > J?chym ?epick? wrote: > > ... >> * since there is no properly working swig interface, it would be very >> difficult to access raster and vector data with help of Python. >> > > If we will be doing heavy Python GUI programming it seems obvious to > spend some time at the beginning getting the swig interface working > properly, if currently it isn't. That would save us a lot of pain in the > long run. > I still hope that Alessandro Frigeri submits his patches for the SWIG interface such as session management and so forth (he presented it at the last year's Lausanne conference). It would be a waste of time to re-invent that again. markus From michael.barton at asu.edu Thu Feb 8 17:00:48 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Feb 8 17:01:04 2007 Subject: [GRASS-dev] Re: gis.m: error message when trying to add layer without open map display In-Reply-To: <45CB2164.2010205@club.worldonline.be> Message-ID: Moritz, I'll try to see what's going on with this. It probably has to do with the necessary link between a layer tree and a display. A better error message would likely be "You need to open a display before adding map layers" Michael On 2/8/07 6:11 AM, "Moritz Lennert" wrote: > Michael, > > Since you have been busy working on error catching in gis.m: I've always > found that the error that occurs when you try to add a layer even though > there is no open map display quite difficult to understand for newbies: > > invalid command name ".mainframe.frame.pw1.f0.frame.pgs.fpage_1.sw.tree_1" > invalid command name ".mainframe.frame.pw1.f0.frame.pgs.fpage_1.sw.tree_1" > while executing > "$tree($mon) selection get" > (procedure "GmTree::add" line 11) > invoked from within > "GmTree::add vector" > ("uplevel" body line 1) > invoked from within > "uplevel \#0 $cmd" > (procedure "Button::_release" line 18) > invoked from within > "Button::_release .mainframe.topf.tb0.bbox2.b0" > (command bound to event) > > > Would it be possible to catch this and produce a nicer error message > such as: "You need to open a map display first." ? > > Moritz __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Thu Feb 8 17:07:35 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Feb 8 17:08:01 2007 Subject: [GRASS-dev] Re: grass-dev Digest, Vol 10, Issue 12 In-Reply-To: <200702080758.l187w9Tl031099@grass.itc.it> Message-ID: On 2/8/07 12:58 AM, "grass-dev-request@grass.itc.it" wrote: > - is there a way in gis.m to paint the centroids differently than > points? (keep them as "X"s) Just change the icon from /basic/circle to /basic/x in the layer options dialog. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Thu Feb 8 17:12:57 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Feb 8 17:13:02 2007 Subject: [GRASS-dev] g.proj to create a new location In-Reply-To: <20070208172834.0eb44e14.hamish_nospam@yahoo.com> Message-ID: Hamish and Paul, I've followed this closely and tried to save relevant emails, but it's been a bit complicated. I've been trying to put aside TclTk and work on the wx.Python GUI, but this seems important to do in the existing TclTk interface. Any chance you could briefly summarize how g.proj now works (or will work) with these changes so that I can try to update the TclTk interface for this? Michael On 2/7/07 9:28 PM, "Hamish" wrote: > Paul Kelly wrote: >> The original thinking was that since the "default" parameters were >> unlikely to be optimum it made sense to put them at the end of the >> list so the user didn't consider them a good default choice. But it >> isn't that important especially since we've added the more >> informative comment about being unlikely to be optimum. > > Hmm. Is the default based on logic or is it just picked as the first > listed in the file, or something like that? If it is random we can > keep the code simpler. Keeping the first entry as default means that the > datumtrans= option (and thus GUI) can be skipped in the case there is > only one option. > > H: >>> It would be nice. I guess another thing missing is region setting >>> code to replace E_edit_cellhd(). More g.proj -c options? > P: >> I think I would prefer Helena's solution of adding a flag to g.region >> to allow it to set the default region. The GUI could then call >> g.region on the new location (after updating .grassrc) following its >> creation with g.proj. > > Yes, that's better. > > The new location would have to be created and switched into before > running g.region in PERMANENT, and then the GUI wizard would take you > on to creating a user mapset before switching into that and launching > a new GRASS session. > > >> If the way the new datumtrans flag works for g.proj is a success it >> could probably be done in a very similar way, using library functions >> in lib/proj/ellipse.c and lib/proj/datum.c to read the system >> ellipsoid and datum tables. Maybe - I haven't really thought it >> through. Might get a bit out of hand. > > Well, we can get the epsg= and datumtrans= options working, and then > worry about those issues- maybe we will learn some along the way. > It may be that g.proj is not the best place to put a top-down chooser > and we'd need a new module "g.newlocation" or something? > > > Hamish > > __________________________________________ 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 Feb 8 17:25:07 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Thu Feb 8 17:22:51 2007 Subject: [GRASS-dev] gis.m: not drawing centroids by default In-Reply-To: <20070208230609.54f2f145.hamish_nospam@yahoo.com> References: <45C88D49.7050808@club.worldonline.be> <20070207123152.73566847.hamish_nospam@yahoo.com> <45C9E0BC.1050508@club.worldonline.be> <45C9FBDE.6000703@club.worldonline.be> <20070208120955.15945773.hamish_nospam@yahoo.com> <45CAE697.2090900@club.worldonline.be> <20070208230609.54f2f145.hamish_nospam@yahoo.com> Message-ID: <45CB4EE3.4060506@club.worldonline.be> On 08/02/07 11:06, Hamish wrote: > Moritz Lennert wrote: >>> - is there a way in gis.m to paint the centroids differently than >>> points? (keep them as "X"s) >> just chose whatever symbol you like >> >>> failing that, >>> - is there a way in gis.m to disable centroid drawing by default? >> What is wrong with just disabling the 'centroid' button ? > > > .. it should plot nicely by default .. --- vector.tcl 2007-01-29 12:17:21.000000000 +0100 +++ vectornew.tcl 2007-02-08 17:21:17.000000000 +0100 @@ -138,7 +138,7 @@ set opt($count,1,type_point) 1 set opt($count,1,type_line) 1 set opt($count,1,type_boundary) 1 - set opt($count,1,type_centroid) 1 + set opt($count,1,type_centroid) 0 set opt($count,1,type_area) 1 set opt($count,1,type_face) 0 in gui/tcltk/gis.m/vector.tcl is all it needs. Is more a question of finding out what people prefer. Personally, I actually agree with Hamish that this might be the better default. Moritz From michael.barton at asu.edu Thu Feb 8 17:33:04 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Feb 8 17:33:12 2007 Subject: [GRASS-dev] WxPython front-end to ps.map In-Reply-To: Message-ID: Here is a bit of information that might be helpful in looking ahead. TclTk does indeed have vector drawing that **could** replace the current d.vect rasterized display, at least for digitizing and quite possibly for display too. Something along the lines of v.edit could utilize this. However, I'd really like to push ahead with wx.Python instead of spending more time on TclTk since we've decided to abandon that venerable platform. The newest version of wx.Python (2.8) has a couple different modules that support true vector objects rather than just rasterized displays (this was more of an issue with version 2.6 and below). I don't yet know which would work better for GRASS vectors, but if we can make use of them, it will provide much better looking vector output and digitizing. Nevertheless, a cartographic module is a different beast from the kinds of working displays we have now. Building on ps.map might well be the best avenue to take with this, since much of the coding has been done and it can be controlled by commands and scripts. As someone just said, the old dm TclTk print module was an early start in that direction. Michael On 2/8/07 2:52 AM, "J?chym ?epick?" wrote: > My imagination is, to use Map Display with pop-up tool bar(s) for > specific tools -- if there is someone, who disagrees with this point, > please raise your hand. ps.map is very good tool for creation of > hard-copy maps. It should not be too big task to add tool, which would > generate configuration file for ps.map based on map display content. > > For the future, it would be good to improve d.vect to be able to > display e.g. dashed lines and so on and to improve ps.map so it is > possible to work with multiple raster tiles and so on. __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Thu Feb 8 17:38:01 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Feb 8 17:38:07 2007 Subject: [GRASS-dev] Re: gis.m: not drawing centroids by default In-Reply-To: <45CB4EE3.4060506@club.worldonline.be> Message-ID: I agree that for me, I'd rather have centroids turned off by default. I left them on because they'd been on by default before. Not a great reason, but I didn't want to be too radical after changing the default icon from x to circle ;-) Michael On 2/8/07 9:25 AM, "Moritz Lennert" wrote: > On 08/02/07 11:06, Hamish wrote: >> Moritz Lennert wrote: >>>> - is there a way in gis.m to paint the centroids differently than >>>> points? (keep them as "X"s) >>> just chose whatever symbol you like >>> >>>> failing that, >>>> - is there a way in gis.m to disable centroid drawing by default? >>> What is wrong with just disabling the 'centroid' button ? >> >> >> .. it should plot nicely by default .. > > --- vector.tcl 2007-01-29 12:17:21.000000000 +0100 > +++ vectornew.tcl 2007-02-08 17:21:17.000000000 +0100 > @@ -138,7 +138,7 @@ > set opt($count,1,type_point) 1 > set opt($count,1,type_line) 1 > set opt($count,1,type_boundary) 1 > - set opt($count,1,type_centroid) 1 > + set opt($count,1,type_centroid) 0 > set opt($count,1,type_area) 1 > set opt($count,1,type_face) 0 > > in gui/tcltk/gis.m/vector.tcl is all it needs. Is more a question of > finding out what people prefer. > > Personally, I actually agree with Hamish that this might be the better > default. > > Moritz __________________________________________ 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 neteler at itc.it Thu Feb 8 18:02:42 2007 From: neteler at itc.it (Markus Neteler) Date: Thu Feb 8 18:02:43 2007 Subject: [GRASS-dev] r.li (landscape indices) In-Reply-To: <20070205152856.z22uwzensg8ccokk@webmail.cli.di.unipi.it> References: <20070130124544.75256f5f.hamish_nospam@yahoo.com> <45C73B46.8040903@itc.it> <20070205152856.z22uwzensg8ccokk@webmail.cli.di.unipi.it> Message-ID: <45CB57B2.80603@itc.it> Hi, it's done :-) I have received latest changes from Serena via Paolo and uploaded it to CVS with a series of further fixes (documentation basically and Windows to Unix file encoding). We now have: r.li: package overview r.li.cwed: Calculates contrast Weighted Edge Density index on a raster map r.li.dominance: Calculates dominance's diversity index on a raster map r.li.edgedensity: Calculates edge density index on a raster map, using a 4 neighbour algorithm r.li.mpa: Calculates mean pixel attribute index on a raster map. r.li.mps: Calculates mean patch size index on a raster map, using a 4 neighbour algorithm r.li.padcv: Calculates coefficient of variation of patch area on a raster map r.li.padrange: Calculates range of patch area size on a raster map r.li.padsd: Calculates standard deviation of patch area a raster map r.li.patchdensity: Calculates patch density index on a raster map, using a 4 neighbour algorithm r.li.patchnum: Calculates patch number index on a raster map, using a 4 neighbour algorithm r.li.richness: Calculates dominance's diversity index on a raster map. r.li.setup: Configuration editor for r.li.'index' r.li.shannon: Calculates Shannon's diversity index on a raster map r.li.shape: Calculates shape index on a raster map r.li.simpson: Calculates Simpson's diversity index on a raster map. Looks like a pretty nice suite now. Please test. Thanks for your hard work, Serena! Markus From Agustin.Diez at uv.es Thu Feb 8 18:41:09 2007 From: Agustin.Diez at uv.es (Agustin Diez Castillo) Date: Thu Feb 8 18:41:13 2007 Subject: [GRASS-dev] v.extrude crashes In-Reply-To: <45CB57B2.80603@itc.it> References: <45CB57B2.80603@itc.it> Message-ID: <3245625193adiez@uv.es> v.extrude caused wish 8.4 to crash in two different cvs builds from Kyngchaos. Model: PowerMac7,2, BootROM 5.1.4f0, 2 processors, PowerPC 970 (2.2), 1.8 GHz, 1 GB Graphics: GeForce FX 5200, GeForce FX 5200, AGP, 64 MB Date/Time: 2007-02-08 18:32:45.993 +0100 OS Version: 10.4.8 (Build 8L127) Report Version: 4 Command: wish8.4 Path: /Applications/Grass/GRASS_63_cvs_070205.app/Contents/Resources/bin/wish8.4 Parent: v.extrude [7271] Version: GRASS 6.3.0-CVS-07020401 (6.3.0) PID: 7272 Thread: 0 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x7c0802ee Thread 0 Crashed: 0 libtk8.4.dylib 0x0b0282ac RecomputePlacement + 464 1 libtcl8.4.dylib 0x0a069b9c TclServiceIdle + 100 2 libtcl8.4.dylib 0x0a058738 Tcl_DoOneEvent + 380 3 libtk8.4.dylib 0x0b00b814 Tk_UpdateObjCmd + 72 4 libtcl8.4.dylib 0x0a010ce0 TclEvalObjvInternal + 760 5 libtcl8.4.dylib 0x0a034338 TclExecuteByteCode + 2692 6 libtcl8.4.dylib 0x0a038fa4 TclCompEvalObj + 372 7 libtcl8.4.dylib 0x0a063120 TclObjInterpProc + 384 8 libtcl8.4.dylib 0x0a010ce0 TclEvalObjvInternal + 760 9 libtcl8.4.dylib 0x0a010f94 Tcl_EvalEx + 380 10 libtcl8.4.dylib 0x0a0206d4 TraceVarProc + 464 11 libtcl8.4.dylib 0x0a06ef94 CallVarTraces + 588 12 libtcl8.4.dylib 0x0a06f4e0 TclPtrSetVar + 996 13 libtcl8.4.dylib 0x0a034c0c TclExecuteByteCode + 4952 14 libtcl8.4.dylib 0x0a038fa4 TclCompEvalObj + 372 15 libtcl8.4.dylib 0x0a063120 TclObjInterpProc + 384 16 libtcl8.4.dylib 0x0a010ce0 TclEvalObjvInternal + 760 17 libtcl8.4.dylib 0x0a034338 TclExecuteByteCode + 2692 18 libtcl8.4.dylib 0x0a038fa4 TclCompEvalObj + 372 19 libtcl8.4.dylib 0x0a063120 TclObjInterpProc + 384 20 libtcl8.4.dylib 0x0a010ce0 TclEvalObjvInternal + 760 21 libtcl8.4.dylib 0x0a034338 TclExecuteByteCode + 2692 22 libtcl8.4.dylib 0x0a038fa4 TclCompEvalObj + 372 23 libtcl8.4.dylib 0x0a063120 TclObjInterpProc + 384 24 libtcl8.4.dylib 0x0a010ce0 TclEvalObjvInternal + 760 25 libtcl8.4.dylib 0x0a034338 TclExecuteByteCode + 2692 26 libtcl8.4.dylib 0x0a038fa4 TclCompEvalObj + 372 27 libtcl8.4.dylib 0x0a011b78 Tcl_EvalObjEx + 468 28 libtcl8.4.dylib 0x0a0175c0 Tcl_IfObjCmd + 472 29 libtcl8.4.dylib 0x0a010ce0 TclEvalObjvInternal + 760 30 libtcl8.4.dylib 0x0a034338 TclExecuteByteCode + 2692 31 libtcl8.4.dylib 0x0a038fa4 TclCompEvalObj + 372 32 libtcl8.4.dylib 0x0a063120 TclObjInterpProc + 384 33 libtcl8.4.dylib 0x0a010ce0 TclEvalObjvInternal + 760 34 libtcl8.4.dylib 0x0a034338 TclExecuteByteCode + 2692 35 libtcl8.4.dylib 0x0a038fa4 TclCompEvalObj + 372 36 libtcl8.4.dylib 0x0a011b78 Tcl_EvalObjEx + 468 37 libtcl8.4.dylib 0x0a044274 TclChannelEventScriptInvoker + 64 38 libtcl8.4.dylib 0x0a0475a8 Tcl_NotifyChannel + 288 39 libtcl8.4.dylib 0x0a07c79c FileHandlerEventProc + 124 40 libtcl8.4.dylib 0x0a05836c Tcl_ServiceEvent + 160 41 libtcl8.4.dylib 0x0a058724 Tcl_DoOneEvent + 360 42 libtk8.4.dylib 0x0b014310 Tk_MainLoop + 60 43 libtk8.4.dylib 0x0b0215f8 Tk_MainEx + 1536 44 wish8.4 0x00005a94 main + 60 45 wish8.4 0x00005678 _start + 760 46 wish8.4 0x0000537c start + 48 Thread 1: 0 libSystem.B.dylib 0x9001f08c select + 12 1 libtcl8.4.dylib 0x0a07cd68 NotifierThreadProc + 456 2 libSystem.B.dylib 0x9002b508 _pthread_body + 96 Thread 0 crashed with PPC Thread State 64: srr0: 0x000000000b0282ac srr1: 0x100000000000f030 vrsave: 0x0000000000000000 cr: 0x24044428 xer: 0x0000000000000000 lr: 0x000000000b02846c ctr: 0x0000000090000dc8 r0: 0x0000000000000000 r1: 0x00000000bfffb390 r2: 0x0000000043300000 r3: 0x000000007c0802a6 r4: 0x00000000006a8608 r5: 0x000000007fffffff r6: 0x0000000090010008 r7: 0xffffffff80808080 r8: 0x0000000000000000 r9: 0x0000000039210048 r10: 0x0000000000000000 r11: 0x000000000b0b80ec r12: 0x0000000090000dc8 r13: 0x0000000000000684 r14: 0x000000000001907c r15: 0x0000000000010408 r16: 0x00000000bfffbf18 r17: 0x00000000bfffc4d4 r18: 0x00000000006d2008 r19: 0x000000000000001a r20: 0x00000000bfffb834 r21: 0x0000000000000000 r22: 0x0000000000000000 r23: 0x0000000000000001 r24: 0x0000000000000000 r25: 0x0000000000000001 r26: 0x00000000ffffffff r27: 0x0000000000000000 r28: 0x0000000000000957 r29: 0x000000000064fc68 r30: 0x000000000b083558 r31: 0x000000000b0280ec Binary Images Description: 0x1000 - 0x5fff wish8.4 /Applications/Grass/GRASS_63_cvs_070205.app/Contents/Resources/bin/wish8.4 0xa000000 - 0xa08afff libtcl8.4.dylib /Applications/Grass/GRASS_63_cvs_070205.app/Contents/Resources/lib/libtcl8.4.dylib 0xb000000 - 0xb0b3fff libtk8.4.dylib /Applications/Grass/GRASS_63_cvs_070205.app/Contents/Resources/lib/libtk8.4dylib 0x8f544000 - 0x8f60ffff libX11.6.dylib /usr/X11R6/lib/libX11.6.dylib 0x8fe00000 - 0x8fe51fff dyld 45.3 /usr/lib/dyld 0x90000000 - 0x901bcfff libSystem.B.dylib /usr/lib/libSystem.B.dylib 0x90214000 - 0x90219fff libmathCommon.A.dylib /usr/lib/system/libmathCommon.A.dylib 0x907ba000 - 0x90893fff com.apple.CoreFoundation 6.4.6 (368.27) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 0x908de000 - 0x909e0fff libicucore.A.dylib /usr/lib/libicucore.A.dylib 0x90a3a000 - 0x90abefff libobjc.A.dylib /usr/lib/libobjc.A.dylib 0x90b6e000 - 0x90b80fff libauto.dylib /usr/lib/libauto.dylib 0x94bee000 - 0x94c0efff libmx.A.dylib /usr/lib/libmx.A.dylib ****************************************************** Dr. Agust?n Diez Castillo Departament de Prehist?ria i Arqueologia Universitat de Val?ncia Phone: Avda. Blasco Iba?ez, 28 Fax: Val?ncia 46010 ****************************************************** From michael.barton at asu.edu Thu Feb 8 19:37:12 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Feb 8 19:37:35 2007 Subject: [GRASS-dev] Re: gis.m: error message when trying to add layer without open map display In-Reply-To: <45CB4BAF.4020208@club.worldonline.be> Message-ID: Fixed in the cvs. Michael On 2/8/07 9:11 AM, "Moritz Lennert" wrote: > On 08/02/07 17:00, Michael Barton wrote: >> Moritz, >> >> I'll try to see what's going on with this. It probably has to do with the >> necessary link between a layer tree and a display. A better error message >> would likely be "You need to open a display before adding map layers" > > yes, definitely better. > > Thanks ! > > Moritz > >> >> >> Michael >> >> >> On 2/8/07 6:11 AM, "Moritz Lennert" wrote: >> >>> Michael, >>> >>> Since you have been busy working on error catching in gis.m: I've always >>> found that the error that occurs when you try to add a layer even though >>> there is no open map display quite difficult to understand for newbies: >>> >>> invalid command name ".mainframe.frame.pw1.f0.frame.pgs.fpage_1.sw.tree_1" >>> invalid command name ".mainframe.frame.pw1.f0.frame.pgs.fpage_1.sw.tree_1" >>> while executing >>> "$tree($mon) selection get" >>> (procedure "GmTree::add" line 11) >>> invoked from within >>> "GmTree::add vector" >>> ("uplevel" body line 1) >>> invoked from within >>> "uplevel \#0 $cmd" >>> (procedure "Button::_release" line 18) >>> invoked from within >>> "Button::_release .mainframe.topf.tb0.bbox2.b0" >>> (command bound to event) >>> >>> >>> Would it be possible to catch this and produce a nicer error message >>> such as: "You need to open a map display first." ? >>> >>> Moritz >> >> __________________________________________ >> 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 >> > __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Thu Feb 8 19:56:58 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Feb 8 19:57:14 2007 Subject: [GRASS-dev] Re: gis.m: not drawing centroids by default In-Reply-To: <45CB4EE3.4060506@club.worldonline.be> Message-ID: Fixed in cvs. Centroid are now off by default (but can be turned on if desired). I also switched the positions of the area and centroid display check buttons to group the normally displayed features and the normally not displayed features (i.e., centroids and faces). Michael On 2/8/07 9:25 AM, "Moritz Lennert" wrote: > On 08/02/07 11:06, Hamish wrote: >> Moritz Lennert wrote: >>>> - is there a way in gis.m to paint the centroids differently than >>>> points? (keep them as "X"s) >>> just chose whatever symbol you like >>> >>>> failing that, >>>> - is there a way in gis.m to disable centroid drawing by default? >>> What is wrong with just disabling the 'centroid' button ? >> >> >> .. it should plot nicely by default .. > > --- vector.tcl 2007-01-29 12:17:21.000000000 +0100 > +++ vectornew.tcl 2007-02-08 17:21:17.000000000 +0100 > @@ -138,7 +138,7 @@ > set opt($count,1,type_point) 1 > set opt($count,1,type_line) 1 > set opt($count,1,type_boundary) 1 > - set opt($count,1,type_centroid) 1 > + set opt($count,1,type_centroid) 0 > set opt($count,1,type_area) 1 > set opt($count,1,type_face) 0 > > in gui/tcltk/gis.m/vector.tcl is all it needs. Is more a question of > finding out what people prefer. > > Personally, I actually agree with Hamish that this might be the better > default. > > Moritz __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Thu Feb 8 19:57:38 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Feb 8 19:57:48 2007 Subject: [GRASS-dev] r.li (landscape indices) In-Reply-To: <45CB57B2.80603@itc.it> Message-ID: OK. Now that the names are finalized, they can go in the menu. Michael On 2/8/07 10:02 AM, "Markus Neteler" wrote: > Hi, > > it's done :-) > I have received latest changes from Serena via Paolo and uploaded > it to CVS with a series of further fixes (documentation basically and > Windows to Unix file encoding). > > We now have: > r.li: package overview > r.li.cwed: Calculates contrast Weighted Edge Density index on a raster map > r.li.dominance: Calculates dominance's diversity index on a raster map > r.li.edgedensity: Calculates edge density index on a raster map, using a > 4 neighbour algorithm > r.li.mpa: Calculates mean pixel attribute index on a raster map. > r.li.mps: Calculates mean patch size index on a raster map, using a 4 > neighbour algorithm > r.li.padcv: Calculates coefficient of variation of patch area on a > raster map > r.li.padrange: Calculates range of patch area size on a raster map > r.li.padsd: Calculates standard deviation of patch area a raster map > r.li.patchdensity: Calculates patch density index on a raster map, using > a 4 neighbour algorithm > r.li.patchnum: Calculates patch number index on a raster map, using a 4 > neighbour algorithm > r.li.richness: Calculates dominance's diversity index on a raster map. > r.li.setup: Configuration editor for r.li.'index' > r.li.shannon: Calculates Shannon's diversity index on a raster map > r.li.shape: Calculates shape index on a raster map > r.li.simpson: Calculates Simpson's diversity index on a raster map. > > > Looks like a pretty nice suite now. Please test. > Thanks for your hard work, Serena! > > Markus > > __________________________________________ 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 dylan.beaudette at gmail.com Thu Feb 8 20:44:34 2007 From: dylan.beaudette at gmail.com (Dylan Beaudette) Date: Thu Feb 8 20:09:09 2007 Subject: [GRASS-dev] WxPython front-end to ps.map In-Reply-To: <17867.3613.858298.118086@cerise.gclements.plus.com> References: <20070207203925.649c2def.hamish_nospam@yahoo.com> <45CAECAD.7020505@club.worldonline.be> <17867.3613.858298.118086@cerise.gclements.plus.com> Message-ID: <200702081144.34725.dylan.beaudette@gmail.com> On Thursday 08 February 2007 03:48, Glynn Clements wrote: > Moritz Lennert wrote: > > > As soon as new map display class will be defined in wxPython, I would > > > like to build georectifing, ps.map and digitizing tool on top of it. > > > > Is there any possibility of changing the display system so that vector > > data is displayed as such in the display or at least the content of the > > display could be directly exported to ps or pdf as vector ? > > No. At least, not in the short/medium term. > > You're talking about a completely new display architecture. The > current architecture is entirely unsuitable for writing a > PostScript/PDF/SVG/etc "driver". > > Note that any display architecture which *was* suitable for generating > PostScript/etc output would be rule out the use of G_plot_polygon() > etc for rendering, so d.vect would need to be fixed. Having specialized output drivers seems like it might help retain CLI functionality _and_ potential to create high quality output. Using R as an example: # plot something to the screen, low res but functional x11() plot(x, y, ...) # plot something to a PDF file: nice crisp lines, etc. pdf(file='new.pdf', width=6, height=10) plot(x, y, ... # close the file dev.off() This approach allows the same commands to draw on the screen or out to any number of files: png() , postscript(), pdf(), fig(), ... you get the idea Generalizing the d.* commands sufficiently would be the challenge... it would be a great improvement to just output an Xmon to PDF - with real vector representation of lines, etc. Just some thoughts, Cheers, -- Dylan Beaudette Soils and Biogeochemistry Graduate Group University of California at Davis 530.754.7341 From glynn at gclements.plus.com Thu Feb 8 21:15:01 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Feb 8 21:15:03 2007 Subject: [GRASS-dev] Re: [GRASS-user] problems using r.proj with large data set In-Reply-To: References: <009801c71a20$2e223d60$3e40ae80@ace.uiuc.edu> <7746318.post@talk.nabble.com> <457882F8.2020001@o2.pl> <17784.51544.421727.643216@cerise.gclements.plus.com> <17797.60295.671067.744836@cerise.gclements.plus.com> <9E06EBB8-9577-4146-AA53-0FC27855EC6F@kyngchaos.com> <17867.1426.935411.652226@cerise.gclements.plus.com> Message-ID: <17867.33989.527871.1303@cerise.gclements.plus.com> William Kyngesburye wrote: > > r.proj.seg (and r.proj) both work by switching environments between > > the input and output locations. It appears to be creating the > > temporary file while the input location is active, when it should be > > using the output location (you may not have write permission for the > > input location). > > That's the odd part - it's really a combination of the input > *location* and the output (current) *mapset* name. Ah. Now *that* is a bug in either G_tempfile() or G_mapset(), depending upon your perspective. G_mapset() does one-shot initialisation, i.e. it takes a copy of the value of the MAPSET variable the first time that it's called, and returns the copied value thereafter. G__mapset() returns the value directly. Note that G_location() behaves like G__mapset() rather than like G_mapset() (i.e. it returns the value of the LOCATION_NAME variable directly). There isn't a location equivalent of G_mapset(). All in all, this is likely to lead to, er, "counter-intuitive" behaviour in conjunction G__switch_env(). Needless to say, none of this appears to be documented anywhere. Actually, I doubt that anyone was even aware of this until now; I didn't notice this specific issue in your first message, only that the directory was "wrong". -- Glynn Clements From glynn at gclements.plus.com Thu Feb 8 21:28:52 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Feb 8 21:28:56 2007 Subject: [GRASS-dev] WxPython front-end to ps.map In-Reply-To: References: <20070207203925.649c2def.hamish_nospam@yahoo.com> <45C9ED30.1090506@o2.pl> <20070208171243.23fc25cf.hamish_nospam@yahoo.com> <45CAECAD.7020505@club.worldonline.be> Message-ID: <17867.34820.333618.496638@cerise.gclements.plus.com> J-B?chym ?epick? wrote:-A > * the gui will be never as fast as compiled one Unless the GUI is going to do its own rendering, that isn't really an issue. > I would say, if we would need to rewrite Map Displays so they access > raster and vector files directly, we would need to code this parts in > C. It would take us too much time IMHO. I would caution against that. The GRASS API was designed for traditional one-shot utilities; it is entirely unsuited to persistent applications such as a GUI. E.g.: 1. If anything unexpected occurs, the usual response is to call G_fatal_error(), which terminates the process. 2. The core libraries have many global variables, which are initialised either by the loader at program startup, by G_gisinit(), or on first access. In many (most?) cases, there is no way to reset the library state back to its initial state. > My imagination is, to use Map Display with pop-up tool bar(s) for > specific tools -- if there is someone, who disagrees with this point, > please raise your hand. ps.map is very good tool for creation of > hard-copy maps. It should not be too big task to add tool, which would > generate configuration file for ps.map based on map display content. > > For the future, it would be good to improve d.vect to be able to > display e.g. dashed lines That's an architectural change. I really don't want to see the existing graphics system (libraster etc) improved. It's long overdue to be replaced with something better. Unfortunately, the problem with a better API is that it's the interface which needs to change, rather than just the implementation. And that involves re-writing a lot of d.* modules. > and so on and to improve ps.map so it is possible to work with > multiple raster tiles and so on. Are you talking about overlaying raster maps? One thing to bear in mind here is that you need level 3 PostScript for masked images (images with transparent pixels), and there are plenty of printers out there which don't support level 3. -- Glynn Clements From woklist at kyngchaos.com Thu Feb 8 21:29:53 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Thu Feb 8 21:29:59 2007 Subject: [GRASS-dev] Re: [GRASS-user] problems using r.proj with large data set In-Reply-To: References: <009801c71a20$2e223d60$3e40ae80@ace.uiuc.edu> <7746318.post@talk.nabble.com> <457882F8.2020001@o2.pl> <17784.51544.421727.643216@cerise.gclements.plus.com> <17797.60295.671067.744836@cerise.gclements.plus.com> <9E06EBB8-9577-4146-AA53-0FC27855EC6F@kyngchaos.com> <17867.1426.935411.652226@cerise.gclements.plus.com> Message-ID: <8D78CDF6-FD1C-47FC-AAA7-F34C815DB6A9@kyngchaos.com> On Feb 8, 2007, at 9:11 AM, William Kyngesburye wrote: >> The only thing that differs between the two is the memory= option. >> I'm >> not sure what needs to be said about that option beyond what's >> already >> in its description string. >> > maybe mention it in the description? Other than the memory option > and name Oops, forgot to finish my thoughts. Other than the memory option and module name, it doesn't really say how it operates differently from r.proj. Some hint about situations one might want to use it would be good. Maybe mention that there will be more disk activity. Add cross-references in each to the other. Both see-also links, and in r.proj, a hint about using r.proj.seg for large rasters and where memory is limited. > I'll give this a try, it'll help project the second have of this > project today if it works. Since you didn't get any response > before, I'll try some timing tests to compare r.proj and > r.proj.seg, and compare the data generated, some time in the next > week or so. > Works great. Now I can do something else while this is crunching. Dual cores is not much help for multitasking when all of memory is tied up, causing lots of swapping ^_^ My first impression is that speed (perceived, since I'm not twiddling my thumbs) is comparable. Though there is a lot of disk thrashing (good thing the data is on an external drive). ----- William Kyngesburye http://www.kyngchaos.com/ First Pogril: Why is life like sticking your head in a bucket filled with hyena offal? Second Pogril: I don't know. Why IS life like sticking your head in a bucket filled with hyena offal? First Pogril: I don't know either. Wretched, isn't it? -HitchHiker's Guide to the Galaxy From michael.barton at asu.edu Thu Feb 8 21:54:44 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Feb 8 21:54:55 2007 Subject: [GRASS-dev] r.li (landscape indices) In-Reply-To: Message-ID: Should I take the r.le series out of the menu? My understanding is that the r.li set pretty much replaces them functionally. Michael On 2/8/07 11:57 AM, "Michael Barton" wrote: > OK. Now that the names are finalized, they can go in the menu. > > Michael > > > On 2/8/07 10:02 AM, "Markus Neteler" wrote: > >> Hi, >> >> it's done :-) >> I have received latest changes from Serena via Paolo and uploaded >> it to CVS with a series of further fixes (documentation basically and >> Windows to Unix file encoding). >> >> We now have: >> r.li: package overview >> r.li.cwed: Calculates contrast Weighted Edge Density index on a raster map >> r.li.dominance: Calculates dominance's diversity index on a raster map >> r.li.edgedensity: Calculates edge density index on a raster map, using a >> 4 neighbour algorithm >> r.li.mpa: Calculates mean pixel attribute index on a raster map. >> r.li.mps: Calculates mean patch size index on a raster map, using a 4 >> neighbour algorithm >> r.li.padcv: Calculates coefficient of variation of patch area on a >> raster map >> r.li.padrange: Calculates range of patch area size on a raster map >> r.li.padsd: Calculates standard deviation of patch area a raster map >> r.li.patchdensity: Calculates patch density index on a raster map, using >> a 4 neighbour algorithm >> r.li.patchnum: Calculates patch number index on a raster map, using a 4 >> neighbour algorithm >> r.li.richness: Calculates dominance's diversity index on a raster map. >> r.li.setup: Configuration editor for r.li.'index' >> r.li.shannon: Calculates Shannon's diversity index on a raster map >> r.li.shape: Calculates shape index on a raster map >> r.li.simpson: Calculates Simpson's diversity index on a raster map. >> >> >> Looks like a pretty nice suite now. Please test. >> Thanks for your hard work, Serena! >> >> Markus >> >> > > __________________________________________ > 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 > > __________________________________________ 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 Feb 8 22:01:16 2007 From: michael.barton at asu.edu (Michael Barton) Date: Thu Feb 8 22:01:27 2007 Subject: [GRASS-dev] WxPython front-end to ps.map In-Reply-To: <17867.34820.333618.496638@cerise.gclements.plus.com> Message-ID: Something I proposed is that we really limit the number of d.* modules used in the new GUI. All the decorations (e.g., scale, north arrows, text, histogram, maybe grids or others) would be better done within wx.Python rather than rendered into raster maps by a d.* module as they are now. They would look much better and offer greater flexibility in placement options and appearance. I'm not proposing that we get rid of such modules, just not use them in the new GUI. That would reduce the amount of d.* module rewriting needed perhaps. Michael On 2/8/07 1:28 PM, "Glynn Clements" wrote: > > J-B?chym ?epick? wrote:-A > >> * the gui will be never as fast as compiled one > > Unless the GUI is going to do its own rendering, that isn't really an > issue. > >> I would say, if we would need to rewrite Map Displays so they access >> raster and vector files directly, we would need to code this parts in >> C. It would take us too much time IMHO. > > I would caution against that. > > The GRASS API was designed for traditional one-shot utilities; it is > entirely unsuited to persistent applications such as a GUI. E.g.: > > 1. If anything unexpected occurs, the usual response is to call > G_fatal_error(), which terminates the process. > > 2. The core libraries have many global variables, which are > initialised either by the loader at program startup, by G_gisinit(), > or on first access. In many (most?) cases, there is no way to reset > the library state back to its initial state. > >> My imagination is, to use Map Display with pop-up tool bar(s) for >> specific tools -- if there is someone, who disagrees with this point, >> please raise your hand. ps.map is very good tool for creation of >> hard-copy maps. It should not be too big task to add tool, which would >> generate configuration file for ps.map based on map display content. >> >> For the future, it would be good to improve d.vect to be able to >> display e.g. dashed lines > > That's an architectural change. I really don't want to see the > existing graphics system (libraster etc) improved. It's long overdue > to be replaced with something better. Unfortunately, the problem with > a better API is that it's the interface which needs to change, rather > than just the implementation. And that involves re-writing a lot of > d.* modules. > >> and so on and to improve ps.map so it is possible to work with >> multiple raster tiles and so on. > > Are you talking about overlaying raster maps? One thing to bear in > mind here is that you need level 3 PostScript for masked images > (images with transparent pixels), and there are plenty of printers out > there which don't support level 3. __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From jachym.cepicky at gmail.com Thu Feb 8 22:41:57 2007 From: jachym.cepicky at gmail.com (=?ISO-8859-2?Q?J=E1chym_=C8epick=FD?=) Date: Thu Feb 8 22:42:00 2007 Subject: [GRASS-dev] WxPython front-end to ps.map In-Reply-To: <17867.34820.333618.496638@cerise.gclements.plus.com> References: <20070207203925.649c2def.hamish_nospam@yahoo.com> <45C9ED30.1090506@o2.pl> <20070208171243.23fc25cf.hamish_nospam@yahoo.com> <45CAECAD.7020505@club.worldonline.be> <17867.34820.333618.496638@cerise.gclements.plus.com> Message-ID: 2007/2/8, Glynn Clements : > > > > For the future, it would be good to improve d.vect to be able to > > display e.g. dashed lines > > That's an architectural change. I really don't want to see the > existing graphics system (libraster etc) improved. It's long overdue > to be replaced with something better. Unfortunately, the problem with > a better API is that it's the interface which needs to change, rather > than just the implementation. And that involves re-writing a lot of > d.* modules. well, I was only thinking on easier coding of GUI for ps.map, so that the user could see the preview of the result. > > > and so on and to improve ps.map so it is possible to work with > > multiple raster tiles and so on. > > Are you talking about overlaying raster maps? One thing to bear in > mind here is that you need level 3 PostScript for masked images > (images with transparent pixels), and there are plenty of printers out > there which don't support level 3. > no, but IIRC if you have multiple backdrop raster maps ordered into tiles, you have to patch them (using r.patch). if ps.map would be able to work with multiple not-overlaying raster maps, this step would not be necessary. myhcaj -- Jachym Cepicky e-mail: jachym.cepicky gmail com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub From smitch at mac.com Thu Feb 8 22:44:01 2007 From: smitch at mac.com (Scott Mitchell) Date: Thu Feb 8 22:44:18 2007 Subject: [GRASS-dev] r.gwflow and r3.gwflow compile errors Message-ID: <8A42C7AC-7453-4F47-94BE-938B163AF780@mac.com> I just updated my grass6-cvs to check out the r.li - but two other modules didn't compile, the new gwflow. [smitch@gracilis r.gwflow]$ make gcc -L/fc2root/home/smitch/src/cvsgrass/grass6/dist.i686-pc-linux-gnu/ lib -Wl,--export-dynamic -Wl,-rpath-link,/fc2root/home/smitch/src/ cvsgrass/grass6/dist.i686-pc-linux-gnu/lib -DPACKAGE= \""grassmods"\" -o /fc2root/home/smitch/src/cvsgrass/grass6/dist.i686- pc-linux-gnu/bin/r.gwflow OBJ.i686-pc-linux-gnu/main.o -lgrass_gis - lgrass_datetime -lz -lm -lz OBJ.i686-pc-linux-gnu/main.o: In function `create_solve_les': /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:503: undefined reference to `N_assemble_les_2d' /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:503: undefined reference to `N_assemble_les_2d' /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:514: undefined reference to `N_solver_bicgstab' /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:517: undefined reference to `N_solver_lu' /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:511: undefined reference to `N_solver_cg' /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:520: undefined reference to `N_solver_gauss' OBJ.i686-pc-linux-gnu/main.o: In function `copy_result': /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:484: undefined reference to `N_put_array_2d_value_dcell' /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:468: undefined reference to `N_get_array_2d_value_dcell' /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:477: undefined reference to `N_get_array_2d_value_dcell' OBJ.i686-pc-linux-gnu/main.o: In function `write_result': /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:431: undefined reference to `N_get_array_2d_value_dcell' OBJ.i686-pc-linux-gnu/main.o: In function `fill_array_2d': /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:387: undefined reference to `N_put_array_2d_value_dcell' OBJ.i686-pc-linux-gnu/main.o: In function `main': /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:215: undefined reference to `N_alloc_geom_data' /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:225: undefined reference to `N_alloc_les_callback_2d' /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:226: undefined reference to `N_callback_gwflow_2d' /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:226: undefined reference to `N_set_les_callback_2d_func' /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:229: undefined reference to `N_alloc_gwflow_data2d' /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:326: undefined reference to `N_free_les' /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:328: undefined reference to `N_free_gwflow_data2d' /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:290: undefined reference to `N_free_les' collect2: ld returned 1 exit status make: *** [/fc2root/home/smitch/src/cvsgrass/grass6/dist.i686-pc- linux-gnu/bin/r.gwflow] Error 1 Same general problem in the 3D version. I do have the header files for these functions, as far as I can tell. Does this look familiar to anyone? Suggestions? From soerengebbert at gmx.de Thu Feb 8 23:03:43 2007 From: soerengebbert at gmx.de (Soeren Gebbert) Date: Thu Feb 8 22:55:15 2007 Subject: [GRASS-dev] r.gwflow and r3.gwflow compile errors In-Reply-To: <8A42C7AC-7453-4F47-94BE-938B163AF780@mac.com> References: <8A42C7AC-7453-4F47-94BE-938B163AF780@mac.com> Message-ID: <200702082303.44881.soerengebbert@gmx.de> Hi, it looks like the linker is not able to find the new gpde library. Maybe the lib was not build? I will try to reproduce and fix this. Maybe i should remove the new modules from the Makefiles .... . Regards Soeren Am Donnerstag, 8. Februar 2007 22:44 schrieb Scott Mitchell: > I just updated my grass6-cvs to check out the r.li - but two other > modules didn't compile, the new gwflow. > > [smitch@gracilis r.gwflow]$ make > gcc -L/fc2root/home/smitch/src/cvsgrass/grass6/dist.i686-pc-linux-gnu/ > lib -Wl,--export-dynamic -Wl,-rpath-link,/fc2root/home/smitch/src/ > cvsgrass/grass6/dist.i686-pc-linux-gnu/lib -DPACKAGE= > \""grassmods"\" -o /fc2root/home/smitch/src/cvsgrass/grass6/dist.i686- > pc-linux-gnu/bin/r.gwflow OBJ.i686-pc-linux-gnu/main.o -lgrass_gis - > lgrass_datetime -lz -lm -lz > OBJ.i686-pc-linux-gnu/main.o: In function `create_solve_les': > /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:503: > undefined reference to `N_assemble_les_2d' > /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:503: > undefined reference to `N_assemble_les_2d' > /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:514: > undefined reference to `N_solver_bicgstab' > /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:517: > undefined reference to `N_solver_lu' > /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:511: > undefined reference to `N_solver_cg' > /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:520: > undefined reference to `N_solver_gauss' > OBJ.i686-pc-linux-gnu/main.o: In function `copy_result': > /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:484: > undefined reference to `N_put_array_2d_value_dcell' > /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:468: > undefined reference to `N_get_array_2d_value_dcell' > /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:477: > undefined reference to `N_get_array_2d_value_dcell' > OBJ.i686-pc-linux-gnu/main.o: In function `write_result': > /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:431: > undefined reference to `N_get_array_2d_value_dcell' > OBJ.i686-pc-linux-gnu/main.o: In function `fill_array_2d': > /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:387: > undefined reference to `N_put_array_2d_value_dcell' > OBJ.i686-pc-linux-gnu/main.o: In function `main': > /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:215: > undefined reference to `N_alloc_geom_data' > /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:225: > undefined reference to `N_alloc_les_callback_2d' > /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:226: > undefined reference to `N_callback_gwflow_2d' > /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:226: > undefined reference to `N_set_les_callback_2d_func' > /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:229: > undefined reference to `N_alloc_gwflow_data2d' > /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:326: > undefined reference to `N_free_les' > /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:328: > undefined reference to `N_free_gwflow_data2d' > /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:290: > undefined reference to `N_free_les' > collect2: ld returned 1 exit status > make: *** [/fc2root/home/smitch/src/cvsgrass/grass6/dist.i686-pc- > linux-gnu/bin/r.gwflow] Error 1 > > Same general problem in the 3D version. I do have the header files > for these functions, as far as I can tell. > > Does this look familiar to anyone? Suggestions? > > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From smitch at mac.com Thu Feb 8 23:12:17 2007 From: smitch at mac.com (Scott Mitchell) Date: Thu Feb 8 23:12:25 2007 Subject: [GRASS-dev] r.gwflow and r3.gwflow compile errors In-Reply-To: <200702082303.44881.soerengebbert@gmx.de> References: <8A42C7AC-7453-4F47-94BE-938B163AF780@mac.com> <200702082303.44881.soerengebbert@gmx.de> Message-ID: On 8 Feb 2007, at 17:03, Soeren Gebbert wrote: > Hi, > it looks like the linker is not able to find the new gpde library. > Maybe the lib was not build? > I have object files in the lib/gpde/OBJ.i686-pc-linux-gnu/ directory, but nothing with gpde in the name in dist.i686-pc-linux- gnu/lib > I will try to reproduce and fix this. > > Maybe i should remove the new modules from the Makefiles .... . > > Regards > Soeren > > Am Donnerstag, 8. Februar 2007 22:44 schrieb Scott Mitchell: >> I just updated my grass6-cvs to check out the r.li - but two other >> modules didn't compile, the new gwflow. >> >> [smitch@gracilis r.gwflow]$ make >> gcc -L/fc2root/home/smitch/src/cvsgrass/grass6/dist.i686-pc-linux- >> gnu/ >> lib -Wl,--export-dynamic -Wl,-rpath-link,/fc2root/home/smitch/src/ >> cvsgrass/grass6/dist.i686-pc-linux-gnu/lib -DPACKAGE= >> \""grassmods"\" -o /fc2root/home/smitch/src/cvsgrass/grass6/ >> dist.i686- >> pc-linux-gnu/bin/r.gwflow OBJ.i686-pc-linux-gnu/main.o -lgrass_gis - >> lgrass_datetime -lz -lm -lz >> OBJ.i686-pc-linux-gnu/main.o: In function `create_solve_les': >> /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:503: >> undefined reference to `N_assemble_les_2d' >> /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:503: >> undefined reference to `N_assemble_les_2d' >> /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:514: >> undefined reference to `N_solver_bicgstab' >> /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:517: >> undefined reference to `N_solver_lu' >> /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:511: >> undefined reference to `N_solver_cg' >> /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:520: >> undefined reference to `N_solver_gauss' >> OBJ.i686-pc-linux-gnu/main.o: In function `copy_result': >> /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:484: >> undefined reference to `N_put_array_2d_value_dcell' >> /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:468: >> undefined reference to `N_get_array_2d_value_dcell' >> /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:477: >> undefined reference to `N_get_array_2d_value_dcell' >> OBJ.i686-pc-linux-gnu/main.o: In function `write_result': >> /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:431: >> undefined reference to `N_get_array_2d_value_dcell' >> OBJ.i686-pc-linux-gnu/main.o: In function `fill_array_2d': >> /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:387: >> undefined reference to `N_put_array_2d_value_dcell' >> OBJ.i686-pc-linux-gnu/main.o: In function `main': >> /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:215: >> undefined reference to `N_alloc_geom_data' >> /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:225: >> undefined reference to `N_alloc_les_callback_2d' >> /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:226: >> undefined reference to `N_callback_gwflow_2d' >> /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:226: >> undefined reference to `N_set_les_callback_2d_func' >> /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:229: >> undefined reference to `N_alloc_gwflow_data2d' >> /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:326: >> undefined reference to `N_free_les' >> /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:328: >> undefined reference to `N_free_gwflow_data2d' >> /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:290: >> undefined reference to `N_free_les' >> collect2: ld returned 1 exit status >> make: *** [/fc2root/home/smitch/src/cvsgrass/grass6/dist.i686-pc- >> linux-gnu/bin/r.gwflow] Error 1 >> >> Same general problem in the 3D version. I do have the header files >> for these functions, as far as I can tell. >> >> Does this look familiar to anyone? Suggestions? >> >> >> _______________________________________________ >> grass-dev mailing list >> grass-dev@grass.itc.it >> http://grass.itc.it/mailman/listinfo/grass-dev From soerengebbert at gmx.de Thu Feb 8 23:29:54 2007 From: soerengebbert at gmx.de (Soeren Gebbert) Date: Thu Feb 8 23:21:27 2007 Subject: [GRASS-dev] r.gwflow and r3.gwflow compile errors In-Reply-To: References: <8A42C7AC-7453-4F47-94BE-938B163AF780@mac.com> <200702082303.44881.soerengebbert@gmx.de> Message-ID: <200702082329.57009.soerengebbert@gmx.de> Am Donnerstag, 8. Februar 2007 23:12 schrieb Scott Mitchell: > On 8 Feb 2007, at 17:03, Soeren Gebbert wrote: > > Hi, > > it looks like the linker is not able to find the new gpde library. > > Maybe the lib was not build? > > I have object files in the lib/gpde/OBJ.i686-pc-linux-gnu/ > directory, but nothing with gpde in the name in dist.i686-pc-linux- > gnu/lib I just downloaded the latest cvs version, configured and compiled it. No problems detected. Maybe if you do a "make distclean, configure, make" the problem will be solved? Because to get the library to work i needed to modify the Grass.make.in in grass. So after a new configuration everything should be fine. Best regards Soeren > > > I will try to reproduce and fix this. > > > > Maybe i should remove the new modules from the Makefiles .... . > > > > Regards > > Soeren > > > > Am Donnerstag, 8. Februar 2007 22:44 schrieb Scott Mitchell: > >> I just updated my grass6-cvs to check out the r.li - but two other > >> modules didn't compile, the new gwflow. > >> > >> [smitch@gracilis r.gwflow]$ make > >> gcc -L/fc2root/home/smitch/src/cvsgrass/grass6/dist.i686-pc-linux- > >> gnu/ > >> lib -Wl,--export-dynamic -Wl,-rpath-link,/fc2root/home/smitch/src/ > >> cvsgrass/grass6/dist.i686-pc-linux-gnu/lib -DPACKAGE= > >> \""grassmods"\" -o /fc2root/home/smitch/src/cvsgrass/grass6/ > >> dist.i686- > >> pc-linux-gnu/bin/r.gwflow OBJ.i686-pc-linux-gnu/main.o -lgrass_gis - > >> lgrass_datetime -lz -lm -lz > >> OBJ.i686-pc-linux-gnu/main.o: In function `create_solve_les': > >> /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:503: > >> undefined reference to `N_assemble_les_2d' > >> /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:503: > >> undefined reference to `N_assemble_les_2d' > >> /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:514: > >> undefined reference to `N_solver_bicgstab' > >> /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:517: > >> undefined reference to `N_solver_lu' > >> /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:511: > >> undefined reference to `N_solver_cg' > >> /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:520: > >> undefined reference to `N_solver_gauss' > >> OBJ.i686-pc-linux-gnu/main.o: In function `copy_result': > >> /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:484: > >> undefined reference to `N_put_array_2d_value_dcell' > >> /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:468: > >> undefined reference to `N_get_array_2d_value_dcell' > >> /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:477: > >> undefined reference to `N_get_array_2d_value_dcell' > >> OBJ.i686-pc-linux-gnu/main.o: In function `write_result': > >> /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:431: > >> undefined reference to `N_get_array_2d_value_dcell' > >> OBJ.i686-pc-linux-gnu/main.o: In function `fill_array_2d': > >> /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:387: > >> undefined reference to `N_put_array_2d_value_dcell' > >> OBJ.i686-pc-linux-gnu/main.o: In function `main': > >> /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:215: > >> undefined reference to `N_alloc_geom_data' > >> /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:225: > >> undefined reference to `N_alloc_les_callback_2d' > >> /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:226: > >> undefined reference to `N_callback_gwflow_2d' > >> /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:226: > >> undefined reference to `N_set_les_callback_2d_func' > >> /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:229: > >> undefined reference to `N_alloc_gwflow_data2d' > >> /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:326: > >> undefined reference to `N_free_les' > >> /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:328: > >> undefined reference to `N_free_gwflow_data2d' > >> /fc2root/home/smitch/src/cvsgrass/grass6/raster/r.gwflow/main.c:290: > >> undefined reference to `N_free_les' > >> collect2: ld returned 1 exit status > >> make: *** [/fc2root/home/smitch/src/cvsgrass/grass6/dist.i686-pc- > >> linux-gnu/bin/r.gwflow] Error 1 > >> > >> Same general problem in the 3D version. I do have the header files > >> for these functions, as far as I can tell. > >> > >> Does this look familiar to anyone? Suggestions? > >> > >> > >> _______________________________________________ > >> grass-dev mailing list > >> grass-dev@grass.itc.it > >> http://grass.itc.it/mailman/listinfo/grass-dev > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From grass-bugs at intevation.de Thu Feb 8 23:28:25 2007 From: grass-bugs at intevation.de (Request Tracker) Date: Thu Feb 8 23:28:26 2007 Subject: [GRASS-dev] [bug #5486] (grass) antonio Message-ID: <20070208222825.B5E741006CC@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5486 ------------------------------------------------------------------------- Subject: antonio Platform: WindowsNT/2000/XP grass obtained from: Trento Italy site grass binary for platform: Compiled from Sources 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 grass-bugs at intevation.de Thu Feb 8 23:30:03 2007 From: grass-bugs at intevation.de (Request Tracker) Date: Thu Feb 8 23:30:05 2007 Subject: [GRASS-dev] [bug #5487] (grass) Message-ID: <20070208223003.68E571006CC@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5487 ------------------------------------------------------------------------- Subject: -------------------------------------------- Managed by Request Tracker From glynn at gclements.plus.com Thu Feb 8 23:38:39 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Feb 8 23:38:41 2007 Subject: [GRASS-dev] v.digit: Could not set Tcl system encoding fixed In-Reply-To: <45CB36F6.1070906@itc.it> References: <45C9995E.7010700@itc.it> <45C9F585.30406@o2.pl> <45CAD4F8.5050400@itc.it> <17867.3200.384675.355130@cerise.gclements.plus.com> <45CB36F6.1070906@itc.it> Message-ID: <17867.42607.267308.193576@cerise.gclements.plus.com> Markus Neteler wrote: > >>>> Roberto Flor and me have fixed the bug > >>>> "v.digit: Could not set Tcl system encoding" > >>>> http://intevation.de/rt/webrt?serial_num=4110 > >>>> > >>>> Please test. I'll backport it to 6.2.x then. > >>>> > >>>> Note: For mysterious Tcl (?) reasons I cannot set iso8859-1 and iso8859-2 > >>>> but utf-8, iso8859-15, iso2210-jp, koi8-r, euc-jp etc work. > >>>> Maybe my installation... > >>>> > >>>> > >>> I confirm. Same happens on my instalation. tcl/tk 8.4.12, Ubuntu Dapper > >>> 32bit. > >>> > >> So we are happy since most of the encodings now work. > >> > > > > Not having ISO-8859-1 working is a pretty major issue. > > > I am still not sure if it is a local problem or a general one or depends > on the tcltk version. > > Can you provide more details, preferably including a recipe to > > reproduce the issue using either spearfish or a new location? > > > Sure (eg Spearfish): > d.mon x0 > v.digit -n newmap > # now go to "Settings" icon, "Table" tab, "Add column", add a column of > your choice, "Create table" > # close the "Settings" window > # digitize a line > # enter a value into the attribute popup form > # "submit button" (default is utf-8 which seems to work) > # change the encoding, click "submit button" again and voila' the error > appear in the terminal Okay. I'm pretty sure that the problem is that lib/form/form.c doesn't call Tcl_Main(), so the library path doesn't get set, so Tcl can't find its .enc files. Realistically, if you are trying to use Tcl/Tk and your program *doesn't* look very much like tkAppInit.c, all bets are off. Rather than trying to process the data from the form library in C, form.c should just register the commands then do the rest in Tcl. -- Glynn Clements From mlennert at club.worldonline.be Fri Feb 9 00:14:43 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Fri Feb 9 00:12:22 2007 Subject: [GRASS-dev] Re: winGRASS In-Reply-To: References: <1451.164.15.134.77.1166435384.squirrel@geog-pc40.ulb.ac.be> <2087.164.15.134.77.1166441036.squirrel@geog-pc40.ulb.ac.be> <3359.164.15.134.77.1166451769.squirrel@geog-pc40.ulb.ac.be> Message-ID: <1211.85.10.69.190.1170976483.squirrel@geog-pc40.ulb.ac.be> On Wed, February 7, 2007 01:39, Paul Kelly wrote: > On Mon, 18 Dec 2006, Moritz Lennert wrote: >> - I had hoped that Radim's patch for dbmi_client >> (http://grass.itc.it/pipermail/grass5/2006-December/028118.html) might >> solve the issue I've had with the db protocol errors, but apparently >> this >> is not the case. When I push the 'show the attribute columns' in a >> vector >> panel, I still get >> >> ******* >> Displaying column types/names for database connection of layer 1: >> dbmi: Protocol error >> >> Cannot open table >> ******** >> >> and a 'v.db.select' on the same map gives me: >> >> ******** >> 'vector/streams' was found in more mapsets (also found in user1). >> dbmi: Protocol error >> >> Cannot open select cursor >> ********* >> >> Radim, as you have been working on this these days, do you have an idea >> what might be wrong ? > > I can confirm similar problems. I tried to import a Shapefile with > v.in.ogr. I went quite deep into debugging it and got nowhere at all, > although I should have taken better notes. I did confirm though that > compiling the library with -mwindows as Radim suggested on the list made > no difference either. I think trying with a different database, PostgreSQL > perhaps is the next big step to debugging this. See if the behaviour is > the same as with dbf and if not we can isolate it a bit more. > (Markus, this is what you were asking about what would be the next step > towards solving this.) Ok, so at least for me this will be one of the current priorities in trying to debug. >> - Help does not work. In individual command windows, the help button is >> desactivated. In layer panels in the main GIS Manager window, when I >> push >> the help button, I get: >> >> child process exited abnormally >> child process exited abnormally >> while executing >> "exec -- g.manual d.vect >& NUL:" >> ("eval" body line 1) >> invoked from within >> "eval [list exec -- $cmd] $args >& $devnull" >> (procedure "run" line 8) >> invoked from within >> "run g.manual d.vect" >> ("uplevel" body line 1) >> invoked from within >> "uplevel \#0 $cmd" >> (procedure "Button::_release" line 18) >> invoked from within >> "Button::_release .mainframe.frame.pw1.f1.frame.sw.sf.frame.fr.name.e" >> (command bound to event) >> > > This was due to g.parser assuming the shell (c:\msys\1.0\bin\sh.exe) that > it needed to run g.manual (required for all the help) was in the path. I > have since changed the way it operates on Windows to first check the > environment variable GRASS_SH before looking for sh.exe in the path. So > the help should work now. No, I still see exactly the same situation (with cvs from Feb. 5): greyed out in individual module gui, error message in gis.m layer panel. > >> - export map canvas to graphics file: >> >> couldn't execute "rm": no such file or directory >> couldn't execute "rm": no such file or directory >> while executing >> "exec rm $path.ppm" >> ("jpg" arm line 7) >> invoked from within >> "switch $type { >> "ppm" { >> return >> } >> "tif" { >> exec gdal_translate $path.ppm $path.tif >> -of GTI$ >> exec rm $path.ppm >> } >> "bmp" { >> e..." >> (procedure "MapToolBar::savefile" line 22) >> invoked from within >> "MapToolBar::savefile jpg 50" >> (menu invoke) >> >> So, graphics file gets created, but the original ppm file is not erased. > > I think Michael has fixed those occurences of exec rm now so the Tcl file > delete function is used. So it should be OK. Yes, works now. - New thing in current (5/2) version: it seems that the grass63.bat file is not adapted and copied to the bin directory during 'make install'. Next to the db issues, I propose to actually work through the GDF tutorial to test the functionalities in there. Should be a good starting point. Moritz From hamish_nospam at yahoo.com Fri Feb 9 00:54:08 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Feb 9 00:54:22 2007 Subject: [GRASS-dev] [bug #5483] (grass) g.mremove through gis manager GUI seems not to work well In-Reply-To: <17867.2715.298187.307696@cerise.gclements.plus.com> References: <20070207095911.CADFA1005C4@lists.intevation.de> <45C9A4F3.5040304@itc.it> <17865.59758.189673.884182@cerise.gclements.plus.com> <20070208113827.56c056e0.hamish_nospam@yahoo.com> <17867.2715.298187.307696@cerise.gclements.plus.com> Message-ID: <20070209125408.6eb1b737.hamish_nospam@yahoo.com> Glynn Clements wrote: > > > I've committed a fix which removes the prompting code. The -f flag > > > remains for compatibility but is ignored. > Hamish wrote: > > you can preset/hint an option's answer in the GUI by giving it on > > the command line and adding the --ui switch to force a GUI: > > > > g.mremove -f --ui > > > > I've backported a fix using this method to the 6.2 GUI menu.tcl: > > -command {execute "g.mremove -f --ui" }} Glynn: > Ultimately, a module is either interactive or it isn't. If it's even > slightly interactive, then it's interactive, and that reduces its > usability. .. > What happens if the user deselects the -f switch from the GUI? Is > there any way to kill the hung process? Then they get stuck. We'd have to change the option's description which read: "-f (use only if you know what you are doing)". Users are likely to deselect it based on that, esp if they are new. Other alternatives: * remove g.mremove from the GUI menu all together -- leave it as a power tool from the command line if you know what you are doing. * write a wrapper --script for g.mremove which doesn't include the -f flag, and have the GUI call that. Hamish From hamish_nospam at yahoo.com Fri Feb 9 00:57:57 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Feb 9 01:00:48 2007 Subject: [GRASS-dev] Re: gis.m: error message when trying to add layer without open map display In-Reply-To: References: <45CB2164.2010205@club.worldonline.be> Message-ID: <20070209125757.7a555824.hamish_nospam@yahoo.com> Moritz: > > Since you have been busy working on error catching in gis.m: I've > > always found that the error that occurs when you try to add a layer > > even though there is no open map display quite difficult to > > understand for newbies: > > > > invalid command name > > ".mainframe.frame.pw1.f0.frame.pgs.fpage_1.sw.tree_1" invalid > > command name ".mainframe.frame.pw1.f0.frame.pgs.fpage_1.sw.tree_1" > > while executing > > "$tree($mon) selection get" .. > > Would it be possible to catch this and produce a nicer error message > > such as: "You need to open a map display first." ? Michael: > I'll try to see what's going on with this. It probably has to do with > the necessary link between a layer tree and a display. A better error > message would likely be "You need to open a display before adding map > layers" Even better: Don't bother with error messages, do what the user wanted: open a new display if needed & add the layer. Hamish From hamish_nospam at yahoo.com Fri Feb 9 01:09:32 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Feb 9 01:09:40 2007 Subject: [GRASS-dev] Re: [GRASS-user] problems using r.proj with large data set In-Reply-To: <8D78CDF6-FD1C-47FC-AAA7-F34C815DB6A9@kyngchaos.com> References: <009801c71a20$2e223d60$3e40ae80@ace.uiuc.edu> <7746318.post@talk.nabble.com> <457882F8.2020001@o2.pl> <17784.51544.421727.643216@cerise.gclements.plus.com> <17797.60295.671067.744836@cerise.gclements.plus.com> <9E06EBB8-9577-4146-AA53-0FC27855EC6F@kyngchaos.com> <17867.1426.935411.652226@cerise.gclements.plus.com> <8D78CDF6-FD1C-47FC-AAA7-F34C815DB6A9@kyngchaos.com> Message-ID: <20070209130932.4f1f5cb7.hamish_nospam@yahoo.com> William Kyngesburye wrote: > > Other than the memory option and module name, it doesn't really say > how it operates differently from r.proj. Some hint about situations > one might want to use it would be good. Maybe mention that there > will be more disk activity. > > Add cross-references in each to the other. Both see-also links, and > in r.proj, a hint about using r.proj.seg for large rasters and where > memory is limited. Is the long term plan to fully replace r.proj with r.proj.seg after r.proj.seg gets enough testing? Glynn: > G_mapset() does one-shot initialisation, i.e. it takes a copy of the > value of the MAPSET variable the first time that it's called, and > returns the copied value thereafter. G__mapset() returns the value > directly. so will this fix the imediate problem? G__tempfile() do { sprintf (name, "%d.%d", pid, uniq++) ; - G__file_name (path, element, name, G_mapset()) ; + G__file_name (path, element, name, G__mapset()) ; } Hamish From hamish_nospam at yahoo.com Fri Feb 9 01:24:36 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Feb 9 01:30:30 2007 Subject: [GRASS-dev] gis.m: not drawing centroids by default In-Reply-To: <45CB4EE3.4060506@club.worldonline.be> References: <45C88D49.7050808@club.worldonline.be> <20070207123152.73566847.hamish_nospam@yahoo.com> <45C9E0BC.1050508@club.worldonline.be> <45C9FBDE.6000703@club.worldonline.be> <20070208120955.15945773.hamish_nospam@yahoo.com> <45CAE697.2090900@club.worldonline.be> <20070208230609.54f2f145.hamish_nospam@yahoo.com> <45CB4EE3.4060506@club.worldonline.be> Message-ID: <20070209132436.283d8ae3.hamish_nospam@yahoo.com> Moritz Lennert wrote: > - set opt($count,1,type_centroid) 1 > + set opt($count,1,type_centroid) 0 > set opt($count,1,type_area) 1 > set opt($count,1,type_face) 0 > > in gui/tcltk/gis.m/vector.tcl is all it needs. Is more a question of > finding out what people prefer. It's a dumbing down vs ease of use compromise... no correct answer.. Others may not agree, but IMO centroids are a "debugging" feature and it is ok to have them off by default from the GUI. Regarless, a solution that sets their default symbol to "x" while leaving the points default symbol as "o" would be nice. Hamish From hamish_nospam at yahoo.com Fri Feb 9 02:20:21 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Feb 9 02:20:32 2007 Subject: [GRASS-dev] r.gwflow and r3.gwflow compile errors In-Reply-To: <200702082303.44881.soerengebbert@gmx.de> References: <8A42C7AC-7453-4F47-94BE-938B163AF780@mac.com> <200702082303.44881.soerengebbert@gmx.de> Message-ID: <20070209142021.66042540.hamish_nospam@yahoo.com> Soeren Gebbert wrote: > it looks like the linker is not able to find the new gpde library. > Maybe the lib was not build? > I will try to reproduce and fix this. They build fine for me. Scott, did you run "make distclean" before rebuilding from the latest CVS? > Maybe i should remove the new modules from the Makefiles .... . The development version is allowed to be broken as long as someone is actively working on the problem. Hamish From glynn at gclements.plus.com Fri Feb 9 02:37:27 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Feb 9 02:40:46 2007 Subject: [GRASS-dev] WxPython front-end to ps.map In-Reply-To: References: <17867.34820.333618.496638@cerise.gclements.plus.com> Message-ID: <17867.53335.663271.396571@cerise.gclements.plus.com> Michael Barton wrote: > Something I proposed is that we really limit the number of d.* modules used > in the new GUI. All the decorations (e.g., scale, north arrows, text, > histogram, maybe grids or others) would be better done within wx.Python > rather than rendered into raster maps by a d.* module as they are now. They > would look much better and offer greater flexibility in placement options > and appearance. I'm not proposing that we get rid of such modules, just not > use them in the new GUI. That would reduce the amount of d.* module > rewriting needed perhaps. d.* aren't just for interactive use. Any new architecture needs to allow for scripted creation of graphics (e.g. web applications). BTW, there are two distinct types of graphics: georeferenced and not. Of the above examples, all but histograms are georeferenced (or may be; text can be either). Having graphics generated by two different mechanisms would require some effort to ensure that "annotations" actually aligned with the maps. -- Glynn Clements From michael.barton at asu.edu Fri Feb 9 03:02:32 2007 From: michael.barton at asu.edu (Michael Barton) Date: Fri Feb 9 03:02:42 2007 Subject: [GRASS-dev] Re: gis.m: error message when trying to add layer without open map display In-Reply-To: <20070209125757.7a555824.hamish_nospam@yahoo.com> Message-ID: Good idea, but considerably more work to program this. Michael On 2/8/07 4:57 PM, "Hamish" wrote: > Moritz: >>> Since you have been busy working on error catching in gis.m: I've >>> always found that the error that occurs when you try to add a layer >>> even though there is no open map display quite difficult to >>> understand for newbies: >>> >>> invalid command name >>> ".mainframe.frame.pw1.f0.frame.pgs.fpage_1.sw.tree_1" invalid >>> command name ".mainframe.frame.pw1.f0.frame.pgs.fpage_1.sw.tree_1" >>> while executing >>> "$tree($mon) selection get" > .. >>> Would it be possible to catch this and produce a nicer error message >>> such as: "You need to open a map display first." ? > > Michael: >> I'll try to see what's going on with this. It probably has to do with >> the necessary link between a layer tree and a display. A better error >> message would likely be "You need to open a display before adding map >> layers" > > Even better: Don't bother with error messages, do what the user wanted: > open a new display if needed & add the layer. > > > Hamish __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From hamish_nospam at yahoo.com Fri Feb 9 03:12:04 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Feb 9 03:12:12 2007 Subject: [GRASS-dev] WxPython front-end to ps.map In-Reply-To: <17867.53335.663271.396571@cerise.gclements.plus.com> References: <17867.34820.333618.496638@cerise.gclements.plus.com> <17867.53335.663271.396571@cerise.gclements.plus.com> Message-ID: <20070209151204.427b3a9c.hamish_nospam@yahoo.com> Glynn Clements wrote: > > Michael Barton wrote: > > > Something I proposed is that we really limit the number of d.* > > modules used in the new GUI. All the decorations (e.g., scale, north > > arrows, text, histogram, maybe grids or others) would be better done > > within wx.Python rather than rendered into raster maps by a d.* > > module as they are now. They would look much better and offer > > greater flexibility in placement options and appearance. I'm not > > proposing that we get rid of such modules, just not use them in the > > new GUI. That would reduce the amount of d.* module rewriting needed > > perhaps. > > d.* aren't just for interactive use. Any new architecture needs to > allow for scripted creation of graphics (e.g. web applications). > > BTW, there are two distinct types of graphics: georeferenced and not. > Of the above examples, all but histograms are georeferenced (or may > be; text can be either). Having graphics generated by two different > mechanisms would require some effort to ensure that "annotations" > actually aligned with the maps. FYI, "d.barscale -n" is not georeferenced, either is d.graph (without the -m flag). d.graph can be used for scripted creation of graphics; perhaps not as efficiently as direct calls, but I don't think it is so slow either. Certainly it is flexible. (I'm not arguing to use it for the GUI, I'm just pointing out that it exists and could help with prototypes) Hamish From hamish_nospam at yahoo.com Fri Feb 9 03:21:25 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Feb 9 03:22:49 2007 Subject: [GRASS-dev] g.proj to create a new location In-Reply-To: References: <20070208172834.0eb44e14.hamish_nospam@yahoo.com> Message-ID: <20070209152125.2f9a5f1f.hamish_nospam@yahoo.com> Michael Barton wrote: > > I've followed this closely and tried to save relevant emails, but it's > been a bit complicated. I've been trying to put aside TclTk and work > on the wx.Python GUI, but this seems important to do in the existing > TclTk interface. > > Any chance you could briefly summarize how g.proj now works (or will > work) with these changes so that I can try to update the TclTk > interface for this? The non-interactive datum parm bit isn't ready yet, so no TclTk changes to worry about right now. This is ready: g.proj -c proj4=+init=epsg:$epsg_code location=$epsgLocation can now be: g.proj -c epsg=$epsg_code location=$epsgLocation But you will still get prompted for transform parms if needed. Once the datumtrans= list + selection option is working there will be some TclTk'ing required to take advantage of that. Hamish From michael.barton at asu.edu Fri Feb 9 04:27:51 2007 From: michael.barton at asu.edu (Michael Barton) Date: Fri Feb 9 04:28:00 2007 Subject: [GRASS-dev] gis.m: not drawing centroids by default In-Reply-To: <20070209132436.283d8ae3.hamish_nospam@yahoo.com> Message-ID: I agree, but don't think it is dumbing down. That would be taking them out altogether. It is trying to find a set of things to view by default so that most people don't have to mess with it most of the time. This is difficult without extensive marketing studies--and sometimes even with them. Michael On 2/8/07 5:24 PM, "Hamish" wrote: > It's a dumbing down vs ease of use compromise... no correct answer.. > > Others may not agree, but IMO centroids are a "debugging" feature and it > is ok to have them off by default from the GUI. Regarless, a solution > that sets their default symbol to "x" while leaving the points default > symbol as "o" would be nice. __________________________________________ 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 Fri Feb 9 04:46:13 2007 From: michael.barton at asu.edu (Michael Barton) Date: Fri Feb 9 04:46:24 2007 Subject: [GRASS-dev] WxPython front-end to ps.map In-Reply-To: <17867.53335.663271.396571@cerise.gclements.plus.com> Message-ID: On 2/8/07 6:37 PM, "Glynn Clements" wrote: > Michael Barton wrote: > >> Something I proposed is that we really limit the number of d.* modules used >> in the new GUI. All the decorations (e.g., scale, north arrows, text, >> histogram, maybe grids or others) would be better done within wx.Python >> rather than rendered into raster maps by a d.* module as they are now. They >> would look much better and offer greater flexibility in placement options >> and appearance. I'm not proposing that we get rid of such modules, just not >> use them in the new GUI. That would reduce the amount of d.* module >> rewriting needed perhaps. > > d.* aren't just for interactive use. Any new architecture needs to > allow for scripted creation of graphics (e.g. web applications). Indeed. That's why I don't propose we get rid of them. > > BTW, there are two distinct types of graphics: georeferenced and not. > Of the above examples, all but histograms are georeferenced (or may > be; text can be either). Having graphics generated by two different > mechanisms would require some effort to ensure that "annotations" > actually aligned with the maps. I'm not sure that it's important to have scales and north arrows georeferenced. Some may disagree of course. But scales were georeferenced in earlier versions of MapInfo and I always thought it was a pain. Georeferencing of some text is indeed important. Vector labels are the best example. But these are created from a text file generated by v.label. I've already got a simple example in TclTk of how such a file can be parsed into labels generated by the GUI. Doing something like contour labels would be nice, but we don't have a particularly good way to do that now by any method (a "contour" setting for v.label might be nice). Grids are georeferenced of course. The ones we have are pretty nice, but it wouldn't be that hard to generate them in the GUI since it is necessary to track earth coordinates for region setting of the display anyway. This would allow more control over stroke form, width, and color, as well as grid label placement. An RGB/HIS display seems like it needs to stay as a layer. Cell numbers and arrows might be better wrapped into the raster control in the GUI, even if they remain separate d.* modules. Thematic maps and charts seem like they should be a vector option rather than separate layers. This could be done with GUI code without needing to combine the d.* modules. However, if we did true vector rendering for primitives, we'd want the same quality in thematic maps and charts. I'm not sure if this makes any considered recoding any easier or not. But the upshot is that vector primitives, thematic maps, and charts seem the best candidates for some reworking of the C code for display. Most of the other d.* effects can work with current code or be replaced by GUI generated graphics if we want. As you point out, this is more work at the GUI coding end. I'm not sure which will take more effort. 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 hamish_nospam at yahoo.com Fri Feb 9 05:00:22 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Feb 9 05:00:43 2007 Subject: [GRASS-dev] WxPython front-end to ps.map In-Reply-To: <45CB0156.7070506@club.worldonline.be> References: <20070207203925.649c2def.hamish_nospam@yahoo.com> <45C9ED30.1090506@o2.pl> <20070208171243.23fc25cf.hamish_nospam@yahoo.com> <45CAECAD.7020505@club.worldonline.be> <45CB0156.7070506@club.worldonline.be> Message-ID: <20070209170022.5b4f9ef5.hamish_nospam@yahoo.com> Moritz Lennert wrote: > [1] one example: at this stage proportionate symbols are not drawn in > descending order of size, thus potentially hiding smaller symbols. I > corrected that in the new version of d.vect.chart I proposed, but it > is still an issue in ps.map. This gets even more complicated when you > want to add a color scheme to that as you have to use a separate > vpoints command for each color and making sorting symbols by size > almost impossible, but allowing the use of the RGB column in ps.map > would solve that (I remember there being mails about this latter > issue, but can't find them now). > Maybe not a fundamental issue for most, but a show stopper for > adopting GRASS as the main GIS and cartography tool here in my > department where a lot of proportionate symbol maps are drawn. http://intevation.de/rt/webrt?serial_num=5129 What about cases like Markus's PHP earthquake map, where you want the new big symbols to be drawn on top of older ones? If automatically sorted, there is no way to unsort them in cases when that is more appropriate. work-around 1) fillcolor = none work-around 2) border color = none. Then all are equal depth :) work-around 3) things are drawn by their cat #, so add a column, populate it with a ranking, and then use v.reclass column= to use them as cat numbers. Support for GRASSRGB in ps.map is wish #3299. Hamish From hamish_nospam at yahoo.com Fri Feb 9 05:50:37 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Feb 9 05:52:06 2007 Subject: [GRASS-dev] WxPython front-end to ps.map In-Reply-To: References: <17867.53335.663271.396571@cerise.gclements.plus.com> Message-ID: <20070209175037.2ab40532.hamish_nospam@yahoo.com> Michael Barton wrote: > Doing something like contour labels would be nice, but we don't have a > particularly good way to do that now by any method (a "contour" > setting for v.label might be nice). My experience with auto-placed contour labels in Surfer and Matlab has left me fairly unimpressed. Maybe GMT has something better. Idea to do it in GRASS: v.to.points dmax= + "d.vect disp=attr" or "v.labels -a" for rotation. Maybe GRASS 5's d.vect.labels could? I can't remember. Hamish From cavallini at faunalia.it Fri Feb 9 07:35:24 2007 From: cavallini at faunalia.it (Paolo Cavallini) Date: Fri Feb 9 07:35:42 2007 Subject: [GRASS-dev] r.li (landscape indices) In-Reply-To: References: Message-ID: <45CC162C.3000200@faunalia.it> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is very much up to Markus. The current set of indices in r.li is more limited than in r.le, though. I understand that keeping them side to side can be confusing to new users. pc Michael Barton ha scritto: > Should I take the r.le series out of the menu? My understanding is that the > r.li set pretty much replaces them functionally. > > Michael - -- 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 iD8DBQFFzBYs/NedwLUzIr4RAh5EAKCvkVuKoPcJ+fBJ7i4JNkKD711z0wCgn39U m+0a35C9VjjBWz/tezV8IGk= =nwqY -----END PGP SIGNATURE----- From neteler at itc.it Fri Feb 9 09:06:27 2007 From: neteler at itc.it (Markus Neteler) Date: Fri Feb 9 09:06:29 2007 Subject: [GRASS-dev] r.li (landscape indices) In-Reply-To: <45CC162C.3000200@faunalia.it> References: <45CC162C.3000200@faunalia.it> Message-ID: <45CC2B83.8060606@itc.it> Hi, I don't think that I can judge that because I don't know which parts of r.le really (still) work and if r.li was already tested. Markus Paolo Cavallini wrote on 02/09/2007 07:35 AM: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > This is very much up to Markus. The current set of indices in r.li is > more limited than in r.le, though. I understand that keeping them side > to side can be confusing to new users. > pc > > Michael Barton ha scritto: > >> Should I take the r.le series out of the menu? My understanding is that the >> r.li set pretty much replaces them functionally. >> >> Michael >> From neteler at itc.it Fri Feb 9 09:08:14 2007 From: neteler at itc.it (Markus Neteler) Date: Fri Feb 9 09:08:15 2007 Subject: [GRASS-dev] r.gwflow and r3.gwflow compile errors In-Reply-To: <20070209142021.66042540.hamish_nospam@yahoo.com> References: <8A42C7AC-7453-4F47-94BE-938B163AF780@mac.com> <200702082303.44881.soerengebbert@gmx.de> <20070209142021.66042540.hamish_nospam@yahoo.com> Message-ID: <45CC2BEE.7080104@itc.it> Hamish wrote on 02/09/2007 02:20 AM: > Soeren Gebbert wrote: > >> it looks like the linker is not able to find the new gpde library. >> Maybe the lib was not build? >> I will try to reproduce and fix this. >> > > They build fine for me. Scott, did you run "make distclean" before > rebuilding from the latest CVS? > Right, this is needed since the initial "make" step after "configure" copies some include files into the right place. I got into the same trap first, then remembered "if in doubt, run'make distclean'" which solved the problem. I have compiled it successfully on 32 and 64bit machines. Markus From neteler at itc.it Fri Feb 9 09:10:27 2007 From: neteler at itc.it (Markus Neteler) Date: Fri Feb 9 09:10:28 2007 Subject: [GRASS-dev] v.digit: Could not set Tcl system encoding fixed (bug #4110) In-Reply-To: <17867.42607.267308.193576@cerise.gclements.plus.com> References: <45C9995E.7010700@itc.it> <45C9F585.30406@o2.pl> <45CAD4F8.5050400@itc.it> <17867.3200.384675.355130@cerise.gclements.plus.com> <45CB36F6.1070906@itc.it> <17867.42607.267308.193576@cerise.gclements.plus.com> Message-ID: <45CC2C73.5030206@itc.it> Glynn Clements wrote on 02/08/2007 11:38 PM: > Markus Neteler wrote: > > >>>>>> Roberto Flor and me have fixed the bug >>>>>> "v.digit: Could not set Tcl system encoding" >>>>>> http://intevation.de/rt/webrt?serial_num=4110 >>>>>> >>>>>> Please test. I'll backport it to 6.2.x then. >>>>>> >>>>>> Note: For mysterious Tcl (?) reasons I cannot set iso8859-1 and iso8859-2 >>>>>> but utf-8, iso8859-15, iso2210-jp, koi8-r, euc-jp etc work. >>>>>> Maybe my installation... >>>>>> >>>>>> >>>>>> >>>>> I confirm. Same happens on my instalation. tcl/tk 8.4.12, Ubuntu Dapper >>>>> 32bit. >>>>> >>>>> >>>> So we are happy since most of the encodings now work. >>>> >>>> >>> Not having ISO-8859-1 working is a pretty major issue. >>> >>> >> I am still not sure if it is a local problem or a general one or depends >> on the tcltk version. >> >>> Can you provide more details, preferably including a recipe to >>> reproduce the issue using either spearfish or a new location? >>> >>> >> Sure (eg Spearfish): >> d.mon x0 >> v.digit -n newmap >> # now go to "Settings" icon, "Table" tab, "Add column", add a column of >> your choice, "Create table" >> # close the "Settings" window >> # digitize a line >> # enter a value into the attribute popup form >> # "submit button" (default is utf-8 which seems to work) >> # change the encoding, click "submit button" again and voila' the error >> appear in the terminal >> > > Okay. > > I'm pretty sure that the problem is that lib/form/form.c doesn't call > Tcl_Main(), so the library path doesn't get set, so Tcl can't find its > .enc files. > > Realistically, if you are trying to use Tcl/Tk and your program > *doesn't* look very much like tkAppInit.c, all bets are off. > > Rather than trying to process the data from the form library in C, > form.c should just register the commands then do the rest in Tcl. > Since I know nothing about tcl, I'll leave that to the experts. AFAIK form.c was originally written by Radim. Markus From grass-bugs at intevation.de Fri Feb 9 09:10:30 2007 From: grass-bugs at intevation.de (Request Tracker) Date: Fri Feb 9 09:10:31 2007 Subject: [bug #5488] (grass) Re: [GRASS-dev] v.digit: Could not set Tcl system encoding fixed (bug #4110) Message-ID: <20070209081030.0DC951006CC@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5488 ------------------------------------------------------------------------- Glynn Clements wrote on 02/08/2007 11:38 PM: > Markus Neteler wrote: > > >>>>>> Roberto Flor and me have fixed the bug >>>>>> "v.digit: Could not set Tcl system encoding" >>>>>> http://intevation.de/rt/webrt?serial_num=4110 >>>>>> >>>>>> Please test. I'll backport it to 6.2.x then. >>>>>> >>>>>> Note: For mysterious Tcl (?) reasons I cannot set iso8859-1 and iso8859-2 >>>>>> but utf-8, iso8859-15, iso2210-jp, koi8-r, euc-jp etc work. >>>>>> Maybe my installation... >>>>>> >>>>>> >>>>>> >>>>> I confirm. Same happens on my instalation. tcl/tk 8.4.12, Ubuntu Dapper >>>>> 32bit. >>>>> >>>>> >>>> So we are happy since most of the encodings now work. >>>> >>>> >>> Not having ISO-8859-1 working is a pretty major issue. >>> >>> >> I am still not sure if it is a local problem or a general one or depends >> on the tcltk version. >> >>> Can you provide more details, preferably including a recipe to >>> reproduce the issue using either spearfish or a new location? >>> >>> >> Sure (eg Spearfish): >> d.mon x0 >> v.digit -n newmap >> # now go to "Settings" icon, "Table" tab, "Add column", add a column of >> your choice, "Create table" >> # close the "Settings" window >> # digitize a line >> # enter a value into the attribute popup form >> # "submit button" (default is utf-8 which seems to work) >> # change the encoding, click "submit button" again and voila' the error >> appear in the terminal >> > > Okay. > > I'm pretty sure that the problem is that lib/form/form.c doesn't call > Tcl_Main(), so the library path doesn't get set, so Tcl can't find its > .enc files. > > Realistically, if you are trying to use Tcl/Tk and your program > *doesn't* look very much like tkAppInit.c, all bets are off. > > Rather than trying to process the data from the form library in C, > form.c should just register the commands then do the rest in Tcl. > Since I know nothing about tcl, I'll leave that to the experts. AFAIK form.c was originally written by Radim. Markus --- Headers Follow --- >From neteler@itc.it Fri Feb 9 09:10:29 2007 Return-Path: Delivered-To: grass-bugs@lists.intevation.de Received: from kolab.intevation.de (salmakis.hq.intevation.de [192.168.11.9]) by lists.intevation.de (Postfix) with ESMTP id 9EABF1006CB for ; Fri, 9 Feb 2007 09:10:29 +0100 (CET) Received: from localhost (localhost.localdomain [127.0.0.1]) by kolab.intevation.de (Postfix) with ESMTP id 7A154109397 for ; Fri, 9 Feb 2007 09:10:29 +0100 (CET) Received: from localhost (localhost.localdomain [127.0.0.1]) by kolab.intevation.de (Postfix) with ESMTP id 1F67D10AD0B for ; Fri, 9 Feb 2007 09:10:29 +0100 (CET) Received: from lancelot.itc.it (ns.itc.it [217.77.80.3]) by kolab.intevation.de (Postfix) with ESMTP id E7FC0109397 for ; Fri, 9 Feb 2007 09:10:27 +0100 (CET) Received: from lancelot (unknown [127.0.0.1]) by lancelot.itc.it (Symantec Mail Security) with ESMTP id 7F9E638C215 for ; Fri, 9 Feb 2007 09:10:27 +0100 (CET) X-AuditID: d94d5003-aed5bbb0000004c3-db-45cc2c73af88 Message-ID: <45CC2C73.5030206@itc.it> Date: Fri, 09 Feb 2007 09:10:27 +0100 From: Markus Neteler User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: Glynn Clements Cc: grass developers list , Request Tracker Subject: Re: [GRASS-dev] v.digit: Could not set Tcl system encoding fixed (bug #4110) References: <45C9995E.7010700@itc.it> <45C9F585.30406@o2.pl> <45CAD4F8.5050400@itc.it> <17867.3200.384675.355130@cerise.gclements.plus.com> <45CB36F6.1070906@itc.it> <17867.42607.267308.193576@cerise.gclements.plus.com> In-Reply-To: <17867.42607.267308.193576@cerise.gclements.plus.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Feb 2007 08:10:27.0211 (UTC) FILETIME=[C1C84DB0:01C74C21] X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: by amavisd-new at intevation.de X-Spam-Status: No, hits=-5 tagged_above=-999 required=3 tests=[BAYES_00=-5] X-Spam-Level: -------------------------------------------- Managed by Request Tracker From mlennert at club.worldonline.be Fri Feb 9 09:33:32 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Fri Feb 9 09:31:11 2007 Subject: [GRASS-dev] WxPython front-end to ps.map In-Reply-To: References: Message-ID: <45CC31DC.4040802@club.worldonline.be> On 09/02/07 04:46, Michael Barton wrote: > Thematic maps and charts seem like they should be a vector option rather > than separate layers. This could be done with GUI code without needing to > combine the d.* modules. However, if we did true vector rendering for > primitives, we'd want the same quality in thematic maps and charts. > > I'm not sure if this makes any considered recoding any easier or not. But > the upshot is that vector primitives, thematic maps, and charts seem the > best candidates for some reworking of the C code for display. Most of the > other d.* effects can work with current code or be replaced by GUI generated > graphics if we want. As you point out, this is more work at the GUI coding > end. I'm not sure which will take more effort. I'm not sure I completely understand what you mean here, and as we are still (albeit slowly, I admit) working on a C replacement of d.vect.thematic, it would be good to know what we should take into account. I do have to agree with Glynn, though, in that we should try to not code two parallel and different ways of drawing things, one for the command line and one for the GUI. I am afraid that this would almost inevitably lead to inconsistencies and definitely to twice the work load trying to keep everything up to date. IMHO, GRASS's strength is its modularity and the GUI should be on top of that, not replace it. Moritz From glynn at gclements.plus.com Fri Feb 9 10:20:17 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Feb 9 10:20:21 2007 Subject: [GRASS-dev] WxPython front-end to ps.map In-Reply-To: <200702081144.34725.dylan.beaudette@gmail.com> References: <20070207203925.649c2def.hamish_nospam@yahoo.com> <45CAECAD.7020505@club.worldonline.be> <17867.3613.858298.118086@cerise.gclements.plus.com> <200702081144.34725.dylan.beaudette@gmail.com> Message-ID: <17868.15569.809267.225649@cerise.gclements.plus.com> Dylan Beaudette wrote: > > > > As soon as new map display class will be defined in wxPython, I would > > > > like to build georectifing, ps.map and digitizing tool on top of it. > > > > > > Is there any possibility of changing the display system so that vector > > > data is displayed as such in the display or at least the content of the > > > display could be directly exported to ps or pdf as vector ? > > > > No. At least, not in the short/medium term. > > > > You're talking about a completely new display architecture. The > > current architecture is entirely unsuitable for writing a > > PostScript/PDF/SVG/etc "driver". > > > > Note that any display architecture which *was* suitable for generating > > PostScript/etc output would be rule out the use of G_plot_polygon() > > etc for rendering, so d.vect would need to be fixed. > > Having specialized output drivers seems like it might help retain CLI > functionality _and_ potential to create high quality output. Using R as an > example: > > # plot something to the screen, low res but functional > x11() > plot(x, y, ...) > > # plot something to a PDF file: nice crisp lines, etc. > pdf(file='new.pdf', width=6, height=10) > plot(x, y, ... > # close the file > dev.off() > > This approach allows the same commands to draw on the screen or out to any > number of files: > png() , postscript(), pdf(), fig(), ... you get the idea > > Generalizing the d.* commands sufficiently would be the challenge... it would > be a great improvement to just output an Xmon to PDF - with real vector > representation of lines, etc. My original preference for a new graphics API was to have d.* commands simply generate PostScript conforming to certain conventions. The resulting PostScript could then be drawn on screen (x11 driver), rendered to an image (PNG/PPM/BMP/etc drivers) or sent to a printer (either a native PostScript printer or via the ljet/PCL/etc drivers). Unfortunately, rendering vector maps using PostScript is between 1 and 2 orders of magnitude slower than using XDrawLine(), which is bad for interactive use. So we still need some kind of intermediate layer which provides a speed-before-quality option for drawing lines. [PostScript draws lines by filling closed paths; there isn't much point in allowing for single-pixel lines when you're primarily targeting devices with resolutions of 300 DPI and upwards.] -- Glynn Clements From grass-bugs at intevation.de Fri Feb 9 10:40:46 2007 From: grass-bugs at intevation.de (Request Tracker) Date: Fri Feb 9 10:40:48 2007 Subject: [GRASS-dev] [bug #5489] (grass) d.font error in GRASS6.2/6.3 Message-ID: <20070209094046.8B1711006CB@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5489 ------------------------------------------------------------------------- Subject: d.font error in GRASS6.2/6.3 Platform: GNU/Linux/x86 grass obtained from: Mirror of Trento site grass binary for platform: Compiled from Sources GRASS Version: 6.2/6.3 cvs snapshot Aldo Clerici In GRASS6.2, the GIS Manager GUI 'Config >Text > Select default text' command, gives the following error: No socket to connect to for monitor No graphics device selected The commands d.font font=romans works well in command line mode (after a minitor is open). Also in GRASS6.3 the commands doesn't work but a different error message is issued. In command line mode the error is: WARNING /usr/local/grass-6.3.cvs/etc/freetypecap: No FreeType definition file. Greetings -------------------------------------------- Managed by Request Tracker From glynn at gclements.plus.com Fri Feb 9 10:40:45 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Feb 9 10:40:50 2007 Subject: [GRASS-dev] Re: [GRASS-user] problems using r.proj with large data set In-Reply-To: <20070209130932.4f1f5cb7.hamish_nospam@yahoo.com> References: <009801c71a20$2e223d60$3e40ae80@ace.uiuc.edu> <7746318.post@talk.nabble.com> <457882F8.2020001@o2.pl> <17784.51544.421727.643216@cerise.gclements.plus.com> <17797.60295.671067.744836@cerise.gclements.plus.com> <9E06EBB8-9577-4146-AA53-0FC27855EC6F@kyngchaos.com> <17867.1426.935411.652226@cerise.gclements.plus.com> <8D78CDF6-FD1C-47FC-AAA7-F34C815DB6A9@kyngchaos.com> <20070209130932.4f1f5cb7.hamish_nospam@yahoo.com> Message-ID: <17868.16797.736678.350911@cerise.gclements.plus.com> Hamish wrote: > > Other than the memory option and module name, it doesn't really say > > how it operates differently from r.proj. Some hint about situations > > one might want to use it would be good. Maybe mention that there > > will be more disk activity. > > > > Add cross-references in each to the other. Both see-also links, and > > in r.proj, a hint about using r.proj.seg for large rasters and where > > memory is limited. > > > Is the long term plan to fully replace r.proj with r.proj.seg after > r.proj.seg gets enough testing? Yes. > > G_mapset() does one-shot initialisation, i.e. it takes a copy of the > > value of the MAPSET variable the first time that it's called, and > > returns the copied value thereafter. G__mapset() returns the value > > directly. > > so will this fix the imediate problem? G__tempfile() > > do > { > sprintf (name, "%d.%d", pid, uniq++) ; > - G__file_name (path, element, name, G_mapset()) ; > + G__file_name (path, element, name, G__mapset()) ; > } That will fix the general G__tempfile() issue. My previous fix should suffice for r.proj.seg. By switching back to the original environment before calling G_tempfile(), G_mapset() and G__mapset() should produce the same results. Actually, G__tempfile() probably shouldn't be called while the alternate environment is active, as it will create the temporary file in the location from the alternate environment (i.e. the source location), when you probably want it to be in the current location (according to $GISRC). There's still the general issue that any other functions which use G_mapset() may not behave as expected while an alternate environment is active. -- Glynn Clements From pallecch at cli.di.unipi.it Fri Feb 9 10:55:26 2007 From: pallecch at cli.di.unipi.it (pallecch@cli.di.unipi.it) Date: Fri Feb 9 10:55:31 2007 Subject: [GRASS-dev] r.li (landscape indices) In-Reply-To: <45CC2B83.8060606@itc.it> References: <45CC162C.3000200@faunalia.it> <45CC2B83.8060606@itc.it> Message-ID: <20070209105526.itz9s6qza8gwogg0@webmail.cli.di.unipi.it> I am in agreement with Paolo. -serena- Quoting Markus Neteler : > Hi, > > I don't think that I can judge that because I don't know which parts > of r.le really (still) work and if r.li was already tested. > > Markus > > Paolo Cavallini wrote on 02/09/2007 07:35 AM: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> This is very much up to Markus. The current set of indices in r.li is >> more limited than in r.le, though. I understand that keeping them side >> to side can be confusing to new users. >> pc >> >> Michael Barton ha scritto: >> >>> Should I take the r.le series out of the menu? My understanding is that the >>> r.li set pretty much replaces them functionally. >>> >>> Michael >>> > > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From mlennert at club.worldonline.be Fri Feb 9 11:33:05 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Fri Feb 9 11:30:44 2007 Subject: [GRASS-dev] WxPython front-end to ps.map In-Reply-To: <20070209170022.5b4f9ef5.hamish_nospam@yahoo.com> References: <20070207203925.649c2def.hamish_nospam@yahoo.com> <45C9ED30.1090506@o2.pl> <20070208171243.23fc25cf.hamish_nospam@yahoo.com> <45CAECAD.7020505@club.worldonline.be> <45CB0156.7070506@club.worldonline.be> <20070209170022.5b4f9ef5.hamish_nospam@yahoo.com> Message-ID: <45CC4DE1.2090100@club.worldonline.be> On 09/02/07 05:00, Hamish wrote: > Moritz Lennert wrote: >> [1] one example: at this stage proportionate symbols are not drawn in >> descending order of size, thus potentially hiding smaller symbols. I >> corrected that in the new version of d.vect.chart I proposed, but it >> is still an issue in ps.map. This gets even more complicated when you >> want to add a color scheme to that as you have to use a separate >> vpoints command for each color and making sorting symbols by size >> almost impossible, but allowing the use of the RGB column in ps.map >> would solve that (I remember there being mails about this latter >> issue, but can't find them now). >> Maybe not a fundamental issue for most, but a show stopper for >> adopting GRASS as the main GIS and cartography tool here in my >> department where a lot of proportionate symbol maps are drawn. > > http://intevation.de/rt/webrt?serial_num=5129 > > What about cases like Markus's PHP earthquake map, where you want the > new big symbols to be drawn on top of older ones? If automatically > sorted, there is no way to unsort them in cases when that is more > appropriate. I get your point. Maybe it would be possible to offer the choice. > > work-around 1) fillcolor = none > > work-around 2) border color = none. Then all are equal depth :) > > work-around 3) things are drawn by their cat #, so add a column, > populate it with a ranking, and then use v.reclass column= to use them > as cat numbers. > 3) Sounds like something to explore. The other two are generally not satisfactory... > Support for GRASSRGB in ps.map is wish #3299. > Martin, you are registered as having taken up this wish. Were you planning on working on it ? Moritz From smitch at mac.com Fri Feb 9 15:23:41 2007 From: smitch at mac.com (Scott Mitchell) Date: Fri Feb 9 15:23:48 2007 Subject: [GRASS-dev] r.gwflow and r3.gwflow compile errors In-Reply-To: <45CC2BEE.7080104@itc.it> References: <8A42C7AC-7453-4F47-94BE-938B163AF780@mac.com> <200702082303.44881.soerengebbert@gmx.de> <20070209142021.66042540.hamish_nospam@yahoo.com> <45CC2BEE.7080104@itc.it> Message-ID: <74AE45F4-5C7A-481C-B05C-849B142E6D82@mac.com> Ah, yes, I forgot that one, sorry. I only did make clean. I blame the head cold ;) Rebuilding... Sure enough, fixed. Thanks, all! Scott On 9 Feb 2007, at 03:08, Markus Neteler wrote: > Hamish wrote on 02/09/2007 02:20 AM: >> Soeren Gebbert wrote: >> >>> it looks like the linker is not able to find the new gpde library. >>> Maybe the lib was not build? >>> I will try to reproduce and fix this. >>> >> >> They build fine for me. Scott, did you run "make distclean" before >> rebuilding from the latest CVS? >> > Right, this is needed since the initial "make" step after "configure" > copies some include files into the right place. > I got into the same trap first, then remembered > "if in doubt, run'make distclean'" > > which solved the problem. I have compiled it successfully on 32 and > 64bit machines. > > Markus From paul-grass at stjohnspoint.co.uk Fri Feb 9 15:25:08 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Fri Feb 9 15:25:14 2007 Subject: [GRASS-dev] Re: winGRASS In-Reply-To: <1211.85.10.69.190.1170976483.squirrel@geog-pc40.ulb.ac.be> References: <1451.164.15.134.77.1166435384.squirrel@geog-pc40.ulb.ac.be> <2087.164.15.134.77.1166441036.squirrel@geog-pc40.ulb.ac.be> <3359.164.15.134.77.1166451769.squirrel@geog-pc40.ulb.ac.be> <1211.85.10.69.190.1170976483.squirrel@geog-pc40.ulb.ac.be> Message-ID: On Fri, 9 Feb 2007, Moritz Lennert wrote: >>> - Help does not work. In individual command windows, the help button is >>> desactivated. In layer panels in the main GIS Manager window, when I >>> push >>> the help button, I get: >>> >>> child process exited abnormally >>> child process exited abnormally >>> while executing >>> "exec -- g.manual d.vect >& NUL:" >>> ("eval" body line 1) >>> invoked from within >>> "eval [list exec -- $cmd] $args >& $devnull" >>> (procedure "run" line 8) >>> invoked from within >>> "run g.manual d.vect" >>> ("uplevel" body line 1) >>> invoked from within >>> "uplevel \#0 $cmd" >>> (procedure "Button::_release" line 18) >>> invoked from within >>> "Button::_release .mainframe.frame.pw1.f1.frame.sw.sf.frame.fr.name.e" >>> (command bound to event) >>> >> >> This was due to g.parser assuming the shell (c:\msys\1.0\bin\sh.exe) that >> it needed to run g.manual (required for all the help) was in the path. I >> have since changed the way it operates on Windows to first check the >> environment variable GRASS_SH before looking for sh.exe in the path. So >> the help should work now. > > No, I still see exactly the same situation (with cvs from Feb. 5): greyed > out in individual module gui, error message in gis.m layer panel. OK this seems very complicated. For me, it works from the button with the GRASS logo superimposed with a green question mark in the layer panel. It also works from the Help menu in gis.m. Does g.manual work for you when you run it from the command-line (grass63.bat -text)? The problem with the greyed out button is due to this check in the make_fun_buttons() function in gui/tcltk/gis.m/runandoutput.tcl # Turn off help button if the help file doesn't exist if {! [file exists $env(GISBASE)/docs/html/$pgm_name.html]} { $buttonframe.help configure -state disabled } For some reason $pgm_name has .exe at the end so the test fails. BUT - this is just a clone of the code for the standalone Tcl/Tk dialog in lib/gis/gui.tcl, and it works there (for me anyway - can you confirm if you run a command from the command-line without any arguments that the Help button isn't greyed out and works?). The $pgm_name there, wherever it is derived from, doesn't have .exe at the end. I'm really not sure where it's coming from; find Tcl code hard enough to follow anyway and not sure about the way everything interacts here anyway. Another interesting point is that in lib/gis/gui.tcl the help button runs: exec $env(GRASS_HTML_BROWSER) $env(GISBASE)/docs/html/$pgm_name.html & whereas most places in gis.m run g.manual $pgm_name or something similar. As g.manual requires a bash interpreter to run, maybe the former solution is more platform-independent? Or are other places not supposed to access $GRASS_HTML_BROWSER - should it be just for g.manual to use? [...] > - New thing in current (5/2) version: it seems that the grass63.bat file > is not adapted and copied to the bin directory during 'make install'. This should be fixed as of yesterday, also the problem with the directory separator characters in grass63.bat should be all sorted. Paul From michael.barton at asu.edu Fri Feb 9 16:20:53 2007 From: michael.barton at asu.edu (Michael Barton) Date: Fri Feb 9 16:21:08 2007 Subject: [GRASS-dev] r.li (landscape indices) In-Reply-To: <20070209105526.itz9s6qza8gwogg0@webmail.cli.di.unipi.it> Message-ID: I've left both in for now given the uncertainty. I hope users won't be too confused, but rather amazed that GRASS has two different landscape analysis packages ;-) Michael On 2/9/07 2:55 AM, "pallecch@cli.di.unipi.it" wrote: > I am in agreement with Paolo. > -serena- > > Quoting Markus Neteler : > >> Hi, >> >> I don't think that I can judge that because I don't know which parts >> of r.le really (still) work and if r.li was already tested. >> >> Markus >> >> Paolo Cavallini wrote on 02/09/2007 07:35 AM: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> This is very much up to Markus. The current set of indices in r.li is >>> more limited than in r.le, though. I understand that keeping them side >>> to side can be confusing to new users. >>> pc >>> >>> Michael Barton ha scritto: >>> >>>> Should I take the r.le series out of the menu? My understanding is that the >>>> r.li set pretty much replaces them functionally. >>>> >>>> Michael >>>> >> >> > > > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > __________________________________________ 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 Fri Feb 9 16:37:21 2007 From: michael.barton at asu.edu (Michael Barton) Date: Fri Feb 9 16:37:47 2007 Subject: [GRASS-dev] [bug #5489] (grass) d.font error in GRASS6.2/6.3 In-Reply-To: <20070209094046.8B1711006CB@lists.intevation.de> Message-ID: Question to those who may know... Is d.font simply unusable without an x11 display monitor? If so, I'll just take it off the GUI menu. Or is the warning that you need to run d.mon another example of an old (and a little misleading) message that is now getting properly parsed and displayed in the output window? I tried setting some fonts and I couldn't find any text affected. I checked d.grid, d.histogram, and d.text. I think I remember that the font setting doesn't persist or something like that. Michael On 2/9/07 2:40 AM, "Request Tracker" wrote: > this bug's URL: http://intevation.de/rt/webrt?serial_num=5489 > ------------------------------------------------------------------------- > > Subject: d.font error in GRASS6.2/6.3 > > Platform: GNU/Linux/x86 > grass obtained from: Mirror of Trento site > grass binary for platform: Compiled from Sources > GRASS Version: 6.2/6.3 cvs snapshot > > Aldo Clerici > In GRASS6.2, the GIS Manager GUI 'Config >Text > Select default text' command, > gives the following error: > No socket to connect to for monitor > No graphics device selected > The commands d.font font=romans works well in command line mode (after a > minitor is open). > > Also in GRASS6.3 the commands doesn't work but a different error message is > issued. > In command line mode the error is: > WARNING /usr/local/grass-6.3.cvs/etc/freetypecap: No FreeType definition file. > > Greetings > > > > -------------------------------------------- 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 Fri Feb 9 18:55:01 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Feb 9 18:57:58 2007 Subject: [GRASS-dev] [bug #5489] (grass) d.font error in GRASS6.2/6.3 In-Reply-To: References: <20070209094046.8B1711006CB@lists.intevation.de> Message-ID: <17868.46453.143635.880150@cerise.gclements.plus.com> Michael Barton wrote: > Question to those who may know... > > Is d.font simply unusable without an x11 display monitor? It's unusable without a *monitor*. It works with any driver (XDRIVER, PNG driver), but it isn't meaningful when using direct rendering. > If so, I'll just > take it off the GUI menu. Or is the warning that you need to run d.mon > another example of an old (and a little misleading) message that is now > getting properly parsed and displayed in the output window? > > I tried setting some fonts and I couldn't find any text affected. I checked > d.grid, d.histogram, and d.text. > > I think I remember that the font setting doesn't persist or something like > that. Yep. When using direct rendering, the driver state is essentially re-initialised for each command, as if you had run e.g.: d.mon start=PNG d.foo yadda yadda d.mon stop=PNG Programs whose sole purpose is to modify driver state (e.g. d.font, d.frame) are meaningless when direct rendering is used. In a technical sense, they still "work", but they're pointless. This is why direct rendering has GRASS_FONT, GRASS_FT_FONT and GRASS_FT_ENCODING; there isn't any other way to set this state. Ideally, the GUI needs to allow you to set these variables globally, and to override them for individual "layers". Even when gis.m used a standalone PNGdriver monitor, setting the font was problematic, as individual commands can change the font for their own purposes, and any changes would then persist for subsequent commands. Consequently, the font that was used for a particular layer could change depending upon the order in which layers were rendered. -- Glynn Clements From michael.barton at asu.edu Fri Feb 9 19:04:28 2007 From: michael.barton at asu.edu (Michael Barton) Date: Fri Feb 9 19:04:32 2007 Subject: [GRASS-dev] [bug #5489] (grass) d.font error in GRASS6.2/6.3 In-Reply-To: <17868.46453.143635.880150@cerise.gclements.plus.com> Message-ID: OK. It is coming back to me, but this is a very nice summary. So I should simply drop d.font and d.font.freetype from the GUI menu. They are meaningless in that context. We could replace them with a script that sets GRASS_FONT and GRASS_FT_FONT. I think the layers that use text and can set text (e.g., the text layers) are coded to check the current status of the global variables and set them back when done. Michael On 2/9/07 10:55 AM, "Glynn Clements" wrote: > This is why direct rendering has GRASS_FONT, GRASS_FT_FONT and > GRASS_FT_ENCODING; there isn't any other way to set this state. > > Ideally, the GUI needs to allow you to set these variables globally, > and to override them for individual "layers". __________________________________________ 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 tutey at o2.pl Fri Feb 9 19:34:19 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Fri Feb 9 19:34:24 2007 Subject: [GRASS-dev] new bug tracking for GRASS Message-ID: <45CCBEAB.5020602@o2.pl> Hi, I'm pleased to officialy announce the new GRASS tracking system powered by GForge ready to use. GForge is a feature-rich system for collaborating on a software project http://gforge.org/. Thanks to Intevation GmbH http://www.intevation.de/index.en.html, who invited us to use their GForge setup at http://wald.intevation.org/, there are 9 trackers for GRASS now [1]: - 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' trackers are for user submitted patches, if the user doesn't have CVS write access but wants to share his fix/improvement. They will also be used for patches which shouldn't go into CVS for a reason, but we want to keep the track of them for later. When an issue is 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. as time allows. When a patch is submitted, and nobody steps up to take care of it, there are first-contacts also, who will do a similar job here: Jachym Chepicky - code patches. Scott Mitchell - website patches. Martin Landa - doc patches. I will try to help if I can, too. Thanks Guys! Trackers are available for public view, but in order to be able to post (including creating a new report) and use all the features of the trackers, you need to setup an account at GForge first [2] and join the GRASS project at GForge [3]. All trackers' new submissions will be automatically forwarded to the GRASS development mailing list [4]. All followup traffic will be stored in the tracker and forwarded only to parties discussing the ticket. However, any project member can "monitor" a ticket, or a whole tracker, in order to receive all the related traffic (see GForge manual [6]). GForge provides many functionalities. Currently we are going to use only the trackers, as all the other functionalities are implemented in the current GRASS infrastructure (besides surveys; maybe there will be some use for them - let's keep them in mind :) ). There are 3 project member "roles": admin, developer and user. 1. "Admin" manages requests to join the project and maintains the GRASS project at GForge. Currently there are 2 admins: I and Bernard Reiter. 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 GRASS 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 you are not sure about :). 3. "User" can open new tickets in the trackers, reply to other tickets and "monitor", participate in surveys ("admin" and "developer" can too, of course). The former GRASS Request Tracker can be used to examine the previously resolved issues, and those that were still in progress as the new system was released [5]. GForge manuals are here: [6]. [1]http://wald.intevation.org/tracker/?group_id=21 [2]http://wald.intevation.org/account/register.php [3]http://wald.intevation.org/project/request.php?group_id=21 [4]http://grass.itc.it/community/support.php#devellists [5]http://intevation.de/rt/webrt?q_status=open&q_queue=grass [6]http://gforge.org/docman/index.php?group_id=1&selected_doc_group_id=5&language_id=1 Maciek From michael.barton at asu.edu Fri Feb 9 19:56:47 2007 From: michael.barton at asu.edu (Michael Barton) Date: Fri Feb 9 19:56:57 2007 Subject: [GRASS-dev] WxPython front-end to ps.map In-Reply-To: <45CC31DC.4040802@club.worldonline.be> Message-ID: Moritz, Sorry for the confusion. I'm thinking of how map layers are presented to users in the layer control panel. It might be cleaner to have a single "vector" layer button instead of "vector", "thematic map", and "thematic chart" buttons. In the options panel for the vector layer, you could decide whether this would display a single color vector map, thematic display of the vector map, or a thematic chart of the vector map. In other words, there would be a single control/options panel that would wrap d.vect, d.vect.thematic, and d.vect.chart. Again, I'm not talking about what we should do with the modules, only how they could be presented to a GUI user. However, if we have a different way of rendering vectors (i.e., a rewrite of the vector display somehow), I think it should include the thematic and chart mapping, rather than just the simply vector display. Michael On 2/9/07 1:33 AM, "Moritz Lennert" wrote: > On 09/02/07 04:46, Michael Barton wrote: > >> Thematic maps and charts seem like they should be a vector option rather >> than separate layers. This could be done with GUI code without needing to >> combine the d.* modules. However, if we did true vector rendering for >> primitives, we'd want the same quality in thematic maps and charts. >> >> I'm not sure if this makes any considered recoding any easier or not. But >> the upshot is that vector primitives, thematic maps, and charts seem the >> best candidates for some reworking of the C code for display. Most of the >> other d.* effects can work with current code or be replaced by GUI generated >> graphics if we want. As you point out, this is more work at the GUI coding >> end. I'm not sure which will take more effort. > > > I'm not sure I completely understand what you mean here, and as we are > still (albeit slowly, I admit) working on a C replacement of > d.vect.thematic, it would be good to know what we should take into account. > > I do have to agree with Glynn, though, in that we should try to not code > two parallel and different ways of drawing things, one for the command > line and one for the GUI. I am afraid that this would almost inevitably > lead to inconsistencies and definitely to twice the work load trying to > keep everything up to date. IMHO, GRASS's strength is its modularity and > the GUI should be on top of that, not replace it. > > Moritz __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics and Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From landa.martin at gmail.com Fri Feb 9 20:00:01 2007 From: landa.martin at gmail.com (Martin Landa) Date: Fri Feb 9 20:00:03 2007 Subject: [GRASS-dev] WxPython front-end to ps.map In-Reply-To: <45CC4DE1.2090100@club.worldonline.be> References: <20070207203925.649c2def.hamish_nospam@yahoo.com> <45C9ED30.1090506@o2.pl> <20070208171243.23fc25cf.hamish_nospam@yahoo.com> <45CAECAD.7020505@club.worldonline.be> <45CB0156.7070506@club.worldonline.be> <20070209170022.5b4f9ef5.hamish_nospam@yahoo.com> <45CC4DE1.2090100@club.worldonline.be> Message-ID: Hi, 2007/2/9, Moritz Lennert : > > Support for GRASSRGB in ps.map is wish #3299. > > > > Martin, you are registered as having taken up this wish. Were you > planning on working on it ? I am planning to implement it. BTW Hamish are you going to work on this issue? I know ps.map module better then me. Martin -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From dylan.beaudette at gmail.com Fri Feb 9 20:42:57 2007 From: dylan.beaudette at gmail.com (Dylan Beaudette) Date: Fri Feb 9 20:42:58 2007 Subject: [GRASS-dev] WxPython front-end to ps.map In-Reply-To: <20070209175037.2ab40532.hamish_nospam@yahoo.com> References: <17867.53335.663271.396571@cerise.gclements.plus.com> <20070209175037.2ab40532.hamish_nospam@yahoo.com> Message-ID: <3c5546140702091142j57d167d8v6debdd2b8f256f7c@mail.gmail.com> On 2/8/07, Hamish wrote: > Michael Barton wrote: > > Doing something like contour labels would be nice, but we don't have a > > particularly good way to do that now by any method (a "contour" > > setting for v.label might be nice). > > > My experience with auto-placed contour labels in Surfer and Matlab has > left me fairly unimpressed. Maybe GMT has something better. I think that it does: http://169.237.35.250/~dylan/NPS/elev.png however, GMT does not have an automatic labelling system for points , line, etc. - each label location has to be defined. > > Idea to do it in GRASS: > v.to.points dmax= + "d.vect disp=attr" or "v.labels -a" for rotation. > > > Maybe GRASS 5's d.vect.labels could? I can't remember. > > > Hamish > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > From glynn at gclements.plus.com Fri Feb 9 23:41:03 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Feb 9 23:44:04 2007 Subject: [GRASS-dev] [bug #5489] (grass) d.font error in GRASS6.2/6.3 In-Reply-To: References: <17868.46453.143635.880150@cerise.gclements.plus.com> Message-ID: <17868.63615.219209.740461@cerise.gclements.plus.com> Michael Barton wrote: > So I should simply drop d.font and d.font.freetype from the GUI menu. They > are meaningless in that context. Yes. > We could replace them with a script that sets GRASS_FONT and GRASS_FT_FONT. If by "script", you mean "Tcl code", then yes. An external script (run with exec) won't work. > I think the layers that use text and can set text (e.g., the text layers) > are coded to check the current status of the global variables and set them > back when done. With direct rendering, there's no need. Any state changes which a d.* command makes will only last for the duration of that command. -- Glynn Clements From grass-codepatches at wald.intevation.org Sat Feb 10 00:17:36 2007 From: grass-codepatches at wald.intevation.org (grass-codepatches@wald.intevation.org) Date: Sat Feb 10 00:20:20 2007 Subject: [GRASS-dev] [grass-code patches][277] label and color support for v.to.rast Message-ID: <20070209231736.EA9641801DA7@pyrosoma.intevation.org> code patches item #277, was opened at 2007-02-10 00:17 Status: Open Priority: 3 Submitted By: Jachym Cepicky (jachym) Assigned to: Nobody (None) Summary: label and color support for v.to.rast Patch status: None Patch type: enhancement GRASS component: vector GRASS version: CVS HEAD GRASS CVS checkout date, if applies (YYMMDD): Initial Comment: This patch adds two flags and two options to v.to.rast: -l -a rgb_column label_column Color and label of raster map categories can be set from vector attribute table. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=205&aid=277&group_id=21 From cavallini at faunalia.it Sat Feb 10 09:00:11 2007 From: cavallini at faunalia.it (Paolo Cavallini) Date: Sat Feb 10 09:00:49 2007 Subject: [GRASS-dev] r.li (landscape indices) In-Reply-To: <45CC2B83.8060606@itc.it> References: <45CC162C.3000200@faunalia.it> <45CC2B83.8060606@itc.it> Message-ID: <45CD7B8B.9040503@faunalia.it> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 r.li wa tested. futhermore, we're doing some additional testing for the upcoming IT grass meeting. pc Markus Neteler ha scritto: > Hi, > > I don't think that I can judge that because I don't know which parts > of r.le really (still) work and if r.li was already tested. > > Markus - -- 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 iD8DBQFFzXuK/NedwLUzIr4RAmmEAJ90P/fzbqvE+ltWtncj6eNlSwRHIwCfeOaE fALM6+CGwrOvE5mGLJ5eGW0= =YlGQ -----END PGP SIGNATURE----- From neteler at itc.it Sat Feb 10 10:18:59 2007 From: neteler at itc.it (Markus Neteler) Date: Sat Feb 10 10:19:00 2007 Subject: [GRASS-dev] r.li (landscape indices) In-Reply-To: <45CD7B8B.9040503@faunalia.it> References: <45CC162C.3000200@faunalia.it> <45CC2B83.8060606@itc.it> <45CD7B8B.9040503@faunalia.it> Message-ID: <20070210091859.GB12029@bartok.itc.it> I tried r.li.setup today and it failed due to a mixture of Windows and Unix encoding: GRASS 6.3.cvs (spearfish60):~ > r.li.setup help bash: /home/neteler/soft/63grass_cvsexp/dist.i686-pc-linux-gnu/scripts/r.li.setup: /bin/sh^M: bad interpreter: File or directory not found I have fixed that in CVS now. Remaining problem (?): file raster/r.li/r.li.mps/mps.c raster/r.li/r.li.mps/mps.c: UTF-8 Unicode C program text Should this file converted to ASCII, too? If yes, how? My 'iconv' tries failed. Markus On Sat, Feb 10, 2007 at 09:00:11AM +0100, Paolo Cavallini wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > r.li wa tested. futhermore, we're doing some additional testing for the > upcoming IT grass meeting. > pc > From glynn at gclements.plus.com Sat Feb 10 11:02:57 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Feb 10 11:03:06 2007 Subject: [GRASS-dev] r.li (landscape indices) In-Reply-To: <20070210091859.GB12029@bartok.itc.it> References: <45CC162C.3000200@faunalia.it> <45CC2B83.8060606@itc.it> <45CD7B8B.9040503@faunalia.it> <20070210091859.GB12029@bartok.itc.it> Message-ID: <17869.38993.384579.292607@cerise.gclements.plus.com> Markus Neteler wrote: > I tried r.li.setup today and it failed due to a mixture > of Windows and Unix encoding: > > GRASS 6.3.cvs (spearfish60):~ > r.li.setup help > bash: /home/neteler/soft/63grass_cvsexp/dist.i686-pc-linux-gnu/scripts/r.li.setup: /bin/sh^M: bad interpreter: File or directory not found > > I have fixed that in CVS now. > > > Remaining problem (?): > file raster/r.li/r.li.mps/mps.c > raster/r.li/r.li.mps/mps.c: UTF-8 Unicode C program text > > Should this file converted to ASCII, too? If yes, how? My 'iconv' > tries failed. The file has a non-ASCII character in the comment at line 1171: else /*l'albero non ? null*/ As every other comment in that file is in English, the obvious solution is to translate the comment, thus eliminating the need for any non-ASCII characters. -- Glynn Clements From neteler at itc.it Sat Feb 10 11:05:10 2007 From: neteler at itc.it (Markus Neteler) Date: Sat Feb 10 11:05:11 2007 Subject: [GRASS-dev] r.li (landscape indices) In-Reply-To: <17869.38993.384579.292607@cerise.gclements.plus.com> References: <45CC162C.3000200@faunalia.it> <45CC2B83.8060606@itc.it> <45CD7B8B.9040503@faunalia.it> <20070210091859.GB12029@bartok.itc.it> <17869.38993.384579.292607@cerise.gclements.plus.com> Message-ID: <20070210100510.GF12029@bartok.itc.it> On Sat, Feb 10, 2007 at 10:02:57AM +0000, Glynn Clements wrote: > Markus Neteler wrote: > > Remaining problem (?): > > file raster/r.li/r.li.mps/mps.c > > raster/r.li/r.li.mps/mps.c: UTF-8 Unicode C program text > > > > > Should this file converted to ASCII, too? If yes, how? My 'iconv' > > tries failed. > > The file has a non-ASCII character in the comment at line 1171: > > else /*l'albero non ? null*/ > > As every other comment in that file is in English, the obvious > solution is to translate the comment, thus eliminating the need for > any non-ASCII characters. Fixed in CVS. Markus From grass-websiteissues at wald.intevation.org Sat Feb 10 11:37:04 2007 From: grass-websiteissues at wald.intevation.org (grass-websiteissues@wald.intevation.org) Date: Sat Feb 10 11:51:35 2007 Subject: [GRASS-dev] [grass-website issues][278] Link in tutorials page doesn't work Message-ID: <20070210103704.CE9201801DA3@pyrosoma.intevation.org> website issues item #278, was opened at 2007-02-10 11:37 Status: Open Priority: 3 Submitted By: Carlos D?vila (carluti) Assigned to: Nobody (None) Summary: Link in tutorials page doesn't work Issue status: None Site section: Docs Site timestamp (YYMMDD): 070210 Initial Comment: The link http://ecologia.unex.es/grass/Introduccion_a_Grass_v.1.1.pdf found under http://grass.itc.it/gdp/tutorials.php in the Spanish section no longer works. It should be updated (I've tried to find current link, but couldn't) or removed. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=210&aid=278&group_id=21 From grass-codeissues at wald.intevation.org Sat Feb 10 12:21:07 2007 From: grass-codeissues at wald.intevation.org (grass-codeissues@wald.intevation.org) Date: Sat Feb 10 12:48:57 2007 Subject: [GRASS-dev] [grass-code issues][279] Define location with EPSG codes hangs grass Message-ID: <20070210112107.D49651801DA7@pyrosoma.intevation.org> code issues item #279, was opened at 2007-02-10 12:21 Status: Open Priority: 3 Submitted By: Carlos D?vila (carluti) Assigned to: Nobody (None) Summary: Define location with EPSG codes hangs grass Issue type: module bug Issue status: None GRASS version: CVS HEAD GRASS component: None Operating system: Linux Operating system version: debian testing 2.6.18-3-486 GRASS CVS checkout date, if applies (YYMMDD): 070210 Initial Comment: When I try to define a new location from startup window, using the option EPSG codes I give the code number (23030) and click on Define location button and grass hangs and I have to close and restart it. I've tried in two different machines with the same linux and grass installation (cvs snapshot from 07-02-04 and 07-02-10) and problem is the same ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=279&group_id=21 From rez at touchofmadness.com Sat Feb 10 15:32:18 2007 From: rez at touchofmadness.com (Brad Douglas) Date: Sat Feb 10 15:32:22 2007 Subject: [GRASS-dev] i.spectral Message-ID: <1171117938.31381.64.camel@devel> Hello, For those interested, I added an option to i.spectral to allow writing output plot to a PNG image file. Would it also be useful to add an option to write the gnuplot commands to a file for editing and rendering? It already exists, but i.spectral discards to file after render. -- Brad Douglas KB8UYR/6 Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From glynn at gclements.plus.com Sat Feb 10 15:59:04 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Feb 10 15:59:10 2007 Subject: [GRASS-dev] v.digit: Could not set Tcl system encoding fixed (bug #4110) In-Reply-To: <45CC2C73.5030206@itc.it> References: <45C9995E.7010700@itc.it> <45C9F585.30406@o2.pl> <45CAD4F8.5050400@itc.it> <17867.3200.384675.355130@cerise.gclements.plus.com> <45CB36F6.1070906@itc.it> <17867.42607.267308.193576@cerise.gclements.plus.com> <45CC2C73.5030206@itc.it> Message-ID: <17869.56760.385929.175604@cerise.gclements.plus.com> Markus Neteler wrote: > > I'm pretty sure that the problem is that lib/form/form.c doesn't call > > Tcl_Main(), so the library path doesn't get set, so Tcl can't find its > > .enc files. > > > > Realistically, if you are trying to use Tcl/Tk and your program > > *doesn't* look very much like tkAppInit.c, all bets are off. > > > > Rather than trying to process the data from the form library in C, > > form.c should just register the commands then do the rest in Tcl. > > Since I know nothing about tcl, I'll leave that to the experts. AFAIK > form.c was > originally written by Radim. The attached patch appears to work, insofar as v.digit appears to work as before, minus the encoding errors. OTOH, I know next to nothing about v.digit (or the vector stuff in general), so it would probably be a good idea for it to be tested by someone who is familiar with v.digit. Essentially, the form utility (lib/form/form.c) has been rewritten as a typical "extended wish", with the communication with the form library being performed in Tcl. -- Glynn Clements -------------- next part -------------- Index: lib/form/form.c =================================================================== RCS file: /grassrepository/grass6/lib/form/form.c,v retrieving revision 1.17 diff -u -r1.17 form.c --- lib/form/form.c 6 Feb 2007 11:15:03 -0000 1.17 +++ lib/form/form.c 10 Feb 2007 14:51:52 -0000 @@ -12,12 +12,6 @@ #include #include -#ifdef __MINGW32__ -#include -#define F_SETFL 4 /* Set file status flags. */ -#define O_NONBLOCK 0x0004 /* Non-blocking I/O. */ -#endif - /* Structure to store column names and values */ typedef struct { @@ -26,21 +20,11 @@ char *value; } COLUMN; -char *Drvname, *Dbname, *Tblname, *Key; - -COLUMN *Columns = NULL; -int allocatedRows = 0; /* allocated space */ -int nRows = 0; +static char *Drvname, *Dbname, *Tblname, *Key; -int form_open = 0; - -/* Close form */ -int close_form(ClientData cdata, Tcl_Interp * interp, int argc, char *argv[]) -{ - G_debug(3, "close_form()"); - form_open = 0; - return TCL_OK; -} +static COLUMN *Columns = NULL; +static int allocatedRows = 0; /* allocated space */ +static int nRows = 0; /* Start new sql update */ int reset_values(ClientData cdata, Tcl_Interp * interp, int argc, char *argv[]) @@ -267,151 +251,49 @@ /* * Form */ -int main(int argc, char *argv[]) +int Tcl_AppInit(Tcl_Interp *interp) { - int length; - int ret; - char buf[5000]; - char *child_html, *child_title; - static FILE *child_send, *child_recv; - static Tcl_Interp *interp; - static int frmid = 0; - char *encoding_val; - - G_gisinit("form"); - - G_debug(2, "Form: main()"); - - setlocale(LC_CTYPE, ""); - - child_recv = stdin; - child_send = stdout; - - while (1) { - fd_set waitset; - struct timeval tv; - - tv.tv_sec = 0; - tv.tv_usec = 200; - - FD_ZERO(&waitset); - FD_SET(fileno(stdin), &waitset); - - if (select(FD_SETSIZE, &waitset, NULL, NULL, &tv) < 0) { - perror("form: select"); - } - - ret = read(fileno(stdin), &(buf[0]), 1); -#ifndef __MINGW32__ - fcntl(fileno(child_recv), F_SETFL, O_NONBLOCK); /* Don't wait if pipe is empty */ -#endif - if (ret == 0) - break; /* Pipe was closed by parent -> quit */ - if (ret == 1) { - G_debug(3, "Form: received = '%c'", buf[0]); - if (buf[0] == 'O') { - if (!form_open) { - G_debug(3, "Form is not opened"); - /* Open the window and display the form */ - interp = Tcl_CreateInterp(); - if (Tcl_Init(interp) == TCL_ERROR) - G_fatal_error("Tcl_Init failed: %s\n", interp->result); - if (Tk_Init(interp) == TCL_ERROR) - G_fatal_error("Tk_Init failed: %s\n", interp->result); - - Tcl_CreateCommand(interp, "submit", (Tcl_CmdProc *) submit, - (ClientData) NULL, - (Tcl_CmdDeleteProc *) NULL); - Tcl_CreateCommand(interp, "set_value", - (Tcl_CmdProc *) set_value, - (ClientData) NULL, - (Tcl_CmdDeleteProc *) NULL); - Tcl_CreateCommand(interp, "reset_values", - (Tcl_CmdProc *) reset_values, - (ClientData) NULL, - (Tcl_CmdDeleteProc *) NULL); - Tcl_CreateCommand(interp, "close_form", - (Tcl_CmdProc *) close_form, - (ClientData) NULL, - (Tcl_CmdDeleteProc *) NULL); - - sprintf(buf, "%s/etc/form/form.tcl", G_gisbase()); - ret = Tcl_EvalFile(interp, buf); - if (ret == TCL_ERROR) { - if (interp->result != NULL) - G_fatal_error("Cannot open form: %s\n", - interp->result); - else - G_fatal_error("Cannot open form\n"); - } + if (Tcl_Init(interp) == TCL_ERROR) + return TCL_ERROR; + if (Tk_Init(interp) == TCL_ERROR) + return TCL_ERROR; - form_open = 1; - } - G_debug(2, "Open form %d", frmid); - /* Read title */ - fgets(buf, 1000, child_recv); - length = atoi(buf); /* length of the string */ - G_debug(2, "length = %d", length); - child_title = (char *)G_malloc(length + 1); - fread(child_title, length, 1, child_recv); - child_title[length] = '\0'; - - /* Read html */ - fgets(buf, 1000, child_recv); - length = atoi(buf); /* length of the string */ - G_debug(2, "length = %d", length); - child_html = (char *)G_malloc(length + 1); - fread(child_html, length, 1, child_recv); - child_html[length] = '\0'; - - memset(buf, '\0', strlen(buf)); - - encoding_val = G__getenv("GRASS_DB_ENCODING"); - Tcl_ExternalToUtf(interp, - Tcl_GetEncoding(interp, encoding_val), - child_html, strlen(child_html), 0, NULL, - buf, strlen(child_html) * 2, NULL, NULL, - NULL); - - G_debug(3, "Current GRASS_DB_ENCODING: %s", encoding_val); - if (Tcl_SetSystemEncoding(interp, encoding_val) == TCL_ERROR) { - fprintf(stderr, - "Could not set Tcl system encoding to %s\n", - encoding_val); - } + Tcl_StaticPackage(interp, "Tk", Tk_Init, Tk_SafeInit); - G_debug(2, "Form: html = %s", buf); + /* + * Call Tcl_CreateCommand for application-specific commands, if + * they weren't already created by the init procedures called above. + */ + + Tcl_CreateCommand(interp, "submit", (Tcl_CmdProc *) submit, + (ClientData) NULL, + (Tcl_CmdDeleteProc *) NULL); + Tcl_CreateCommand(interp, "set_value", + (Tcl_CmdProc *) set_value, + (ClientData) NULL, + (Tcl_CmdDeleteProc *) NULL); + Tcl_CreateCommand(interp, "reset_values", + (Tcl_CmdProc *) reset_values, + (ClientData) NULL, + (Tcl_CmdDeleteProc *) NULL); + /* + * Specify a user-specific startup file to invoke if the application + * is run interactively. Typically the startup file is "~/.apprc" + * where "app" is the name of the application. If this line is deleted + * then no user-specific startup file will be run under any conditions. + */ - /* Insert new page */ - Tcl_SetVar(interp, "html", buf, 0); - sprintf(buf, "add_form %d \"%s\"", frmid, child_title); - Tcl_Eval(interp, buf); - - fprintf(child_send, "O"); /* OK */ - fflush(child_send); - frmid++; - G_debug(2, "Form displayed\n"); - } - else if (buf[0] == 'C') { /* clear old forms */ - Tcl_Eval(interp, "clear_nb"); - fprintf(child_send, "O"); /* OK */ - fflush(child_send); - } - else if (buf[0] == 'D') { /* done! */ - Tcl_Eval(interp, "clear_nb"); - fprintf(child_send, "O"); /* OK */ - fflush(child_send); - break; - } - } - - Tcl_Eval(interp, "update"); - } + Tcl_SetVar(interp, "tcl_rcFileName", "~/.grassformrc", TCL_GLOBAL_ONLY); + return TCL_OK; +} - Tcl_Eval(interp, "destroy ."); - G_debug(3, "Form: end\n"); - exit(0); +int main(int argc, char *argv[]) +{ + G_gisinit("form"); + G_debug(2, "Form: main()"); - return 0; + Tk_Main(argc, argv, Tcl_AppInit); + return 0; } + Index: lib/form/form.tcl =================================================================== RCS file: /grassrepository/grass6/lib/form/form.tcl,v retrieving revision 1.3 diff -u -r1.3 form.tcl --- lib/form/form.tcl 17 Feb 2003 06:41:03 -0000 1.3 +++ lib/form/form.tcl 10 Feb 2007 14:51:52 -0000 @@ -2,17 +2,9 @@ package require -exact BWidget 1.2.1 #package require http -set formpath $env(GISBASE)/etc/form/ +set formpath $env(GISBASE)/etc/form source $formpath/html_library.tcl -set submit_result "" -set submit_msg "" -set html "" - -set nb [NoteBook .nb] -$nb configure -width 300 -height 500 -pack .nb -fill both -expand yes - proc create_submit_msg { formid } { global submit_result submit_msg formf @@ -70,4 +62,97 @@ create_submit_msg $formid } +proc make_form {} { + global nb + + set nb [NoteBook .nb] + $nb configure -width 300 -height 500 + pack .nb -fill both -expand yes +} + +proc close_form {} { + global form_open + wm withdraw . + set form_open false +} + +proc process_command {} { + global env + global child_recv child_send + global form_open encoding_val frmid + global html + + if {[eof $child_recv]} { + exit 0 + } + + set cmd [read $child_recv 1] + + switch $cmd { + O { + if {! $form_open} { + wm state . normal + set form_open true + } + # Read title + set length [gets $child_recv] + set child_title [read $child_recv $length] + + # Read html + set length [gets $child_recv] + set child_html [read $child_recv $length] + + set child_html [encoding convertfrom $encoding_val $child_html] + + # Insert new page + set html $child_html + add_form $frmid $child_title + + puts -nonewline $child_send O + flush $child_send + incr frmid + } + C { # clear old forms + clear_nb + puts -nonewline $child_send O + flush $child_send + } + D { # done! + clear_nb + puts -nonewline $child_send O + flush $child_send + + destroy . + exit 0 + } + } +} + +make_form + +wm protocol . WM_DELETE_WINDOW close_form + bind . { if { "%W" == "."} { close_form } } + +set submit_result "" +set submit_msg "" +set html "" + +set frmid 0 +set form_open true + +set child_recv stdin +set child_send stdout + +set encoding_val [exec g.gisenv GRASS_DB_ENCODING] +if {$encoding_val == ""} { + set encoding_val [encoding system] +} + +if {[catch {encoding system $encoding_val}]} { + puts stderr "Could not set Tcl system encoding to $encoding_val" +} + +fconfigure $child_recv -buffering none -encoding binary -translation binary + +fileevent $child_recv readable process_command Index: lib/form/open.c =================================================================== RCS file: /grassrepository/grass6/lib/form/open.c,v retrieving revision 1.13 diff -u -r1.13 open.c --- lib/form/open.c 7 Nov 2006 06:05:07 -0000 1.13 +++ lib/form/open.c 10 Feb 2007 14:51:52 -0000 @@ -51,9 +51,6 @@ #endif /*USE_G_SOCKS*/ int length; /* child */ - char buf[2000]; - - G_debug ( 2, "F_open(): title = %s", title); @@ -70,6 +67,8 @@ } if ( pid == 0 ) { /* Child */ + char command[2000], script[2000]; + G_debug ( 2, "CHILD" ); /* Note: If you are forking in a Tk based apllication you @@ -94,9 +93,10 @@ - sprintf(buf,"%s/etc/form/form", G_gisbase()); + sprintf(command, "%s/etc/form/form", G_gisbase()); + sprintf(script, "%s/etc/form/form.tcl", G_gisbase()); - execl ("/bin/sh", "sh", "-c", buf, NULL); + execl(command, "form", "-f", script, NULL); G_debug(2, "CHILD END\n"); exit (0); From grass-bugs at intevation.de Sat Feb 10 15:59:12 2007 From: grass-bugs at intevation.de (Request Tracker) Date: Sat Feb 10 15:59:14 2007 Subject: [bug #5490] (grass) Re: [GRASS-dev] v.digit: Could not set Tcl system encoding fixed (bug #4110) Message-ID: <20070210145912.7A3361006A6@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5490 ------------------------------------------------------------------------- --8XkdMeO807 Content-Type: text/plain; charset=us-ascii Content-Description: message body and .signature Content-Transfer-Encoding: 7bit Markus Neteler wrote: > > I'm pretty sure that the problem is that lib/form/form.c doesn't call > > Tcl_Main(), so the library path doesn't get set, so Tcl can't find its > > .enc files. > > > > Realistically, if you are trying to use Tcl/Tk and your program > > *doesn't* look very much like tkAppInit.c, all bets are off. > > > > Rather than trying to process the data from the form library in C, > > form.c should just register the commands then do the rest in Tcl. > > Since I know nothing about tcl, I'll leave that to the experts. AFAIK > form.c was > originally written by Radim. The attached patch appears to work, insofar as v.digit appears to work as before, minus the encoding errors. OTOH, I know next to nothing about v.digit (or the vector stuff in general), so it would probably be a good idea for it to be tested by someone who is familiar with v.digit. Essentially, the form utility (lib/form/form.c) has been rewritten as a typical "extended wish", with the communication with the form library being performed in Tcl. -- Glynn Clements --8XkdMeO807 Content-Type: text/plain Content-Description: lib/form patch Content-Disposition: inline; filename="form.diff" Content-Transfer-Encoding: base64 SW5kZXg6IGxpYi9mb3JtL2Zvcm0uYw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KUkNTIGZpbGU6IC9ncmFz c3JlcG9zaXRvcnkvZ3Jhc3M2L2xpYi9mb3JtL2Zvcm0uYyx2DQpyZXRyaWV2aW5nIHJldmlz aW9uIDEuMTcNCmRpZmYgLXUgLXIxLjE3IGZvcm0uYw0KLS0tIGxpYi9mb3JtL2Zvcm0uYwk2 IEZlYiAyMDA3IDExOjE1OjAzIC0wMDAwCTEuMTcNCisrKyBsaWIvZm9ybS9mb3JtLmMJMTAg RmViIDIwMDcgMTQ6NTE6NTIgLTAwMDANCkBAIC0xMiwxMiArMTIsNiBAQA0KICNpbmNsdWRl IDxncmFzcy9kYm1pLmg+DQogI2luY2x1ZGUgPGdyYXNzL2Zvcm0uaD4NCiANCi0jaWZkZWYg X19NSU5HVzMyX18NCi0jaW5jbHVkZSA8d2luc29jay5oPg0KLSNkZWZpbmUgICAgICAgIEZf U0VURkwgICAgICAgICA0CS8qIFNldCBmaWxlIHN0YXR1cyBmbGFncy4gICovDQotI2RlZmlu ZSAgICAgICAgT19OT05CTE9DSyAgICAgIDB4MDAwNAkvKiBOb24tYmxvY2tpbmcgSS9PLiAg Ki8NCi0jZW5kaWYNCi0NCiAvKiBTdHJ1Y3R1cmUgdG8gc3RvcmUgY29sdW1uIG5hbWVzIGFu ZCB2YWx1ZXMgKi8NCiB0eXBlZGVmIHN0cnVjdA0KIHsNCkBAIC0yNiwyMSArMjAsMTEgQEAN CiAgICAgY2hhciAqdmFsdWU7DQogfSBDT0xVTU47DQogDQotY2hhciAqRHJ2bmFtZSwgKkRi bmFtZSwgKlRibG5hbWUsICpLZXk7DQotDQotQ09MVU1OICpDb2x1bW5zID0gTlVMTDsNCi1p bnQgYWxsb2NhdGVkUm93cyA9IDA7CQkJLyogYWxsb2NhdGVkIHNwYWNlICovDQotaW50IG5S b3dzID0gMDsNCitzdGF0aWMgY2hhciAqRHJ2bmFtZSwgKkRibmFtZSwgKlRibG5hbWUsICpL ZXk7DQogDQotaW50IGZvcm1fb3BlbiA9IDA7DQotDQotLyogQ2xvc2UgZm9ybSAqLw0KLWlu dCBjbG9zZV9mb3JtKENsaWVudERhdGEgY2RhdGEsIFRjbF9JbnRlcnAgKiBpbnRlcnAsIGlu dCBhcmdjLCBjaGFyICphcmd2W10pDQotew0KLSAgICBHX2RlYnVnKDMsICJjbG9zZV9mb3Jt KCkiKTsNCi0gICAgZm9ybV9vcGVuID0gMDsNCi0gICAgcmV0dXJuIFRDTF9PSzsNCi19DQor c3RhdGljIENPTFVNTiAqQ29sdW1ucyA9IE5VTEw7DQorc3RhdGljIGludCBhbGxvY2F0ZWRS b3dzID0gMDsJCQkvKiBhbGxvY2F0ZWQgc3BhY2UgKi8NCitzdGF0aWMgaW50IG5Sb3dzID0g MDsNCiANCiAvKiBTdGFydCBuZXcgc3FsIHVwZGF0ZSAqLw0KIGludCByZXNldF92YWx1ZXMo Q2xpZW50RGF0YSBjZGF0YSwgVGNsX0ludGVycCAqIGludGVycCwgaW50IGFyZ2MsIGNoYXIg KmFyZ3ZbXSkNCkBAIC0yNjcsMTUxICsyNTEsNDkgQEANCiAvKiANCiAgKiAgRm9ybSANCiAg Ki8NCi1pbnQgbWFpbihpbnQgYXJnYywgY2hhciAqYXJndltdKQ0KK2ludCBUY2xfQXBwSW5p dChUY2xfSW50ZXJwICppbnRlcnApDQogew0KLSAgICBpbnQgbGVuZ3RoOw0KLSAgICBpbnQg cmV0Ow0KLSAgICBjaGFyIGJ1Zls1MDAwXTsNCi0gICAgY2hhciAqY2hpbGRfaHRtbCwgKmNo aWxkX3RpdGxlOw0KLSAgICBzdGF0aWMgRklMRSAqY2hpbGRfc2VuZCwgKmNoaWxkX3JlY3Y7 DQotICAgIHN0YXRpYyBUY2xfSW50ZXJwICppbnRlcnA7DQotICAgIHN0YXRpYyBpbnQgZnJt aWQgPSAwOw0KLSAgICBjaGFyICplbmNvZGluZ192YWw7DQotDQotICAgIEdfZ2lzaW5pdCgi Zm9ybSIpOw0KLQ0KLSAgICBHX2RlYnVnKDIsICJGb3JtOiBtYWluKCkiKTsNCi0NCi0gICAg c2V0bG9jYWxlKExDX0NUWVBFLCAiIik7DQotDQotICAgIGNoaWxkX3JlY3YgPSBzdGRpbjsN Ci0gICAgY2hpbGRfc2VuZCA9IHN0ZG91dDsNCi0NCi0gICAgd2hpbGUgKDEpIHsNCi0JZmRf c2V0IHdhaXRzZXQ7DQotCXN0cnVjdCB0aW1ldmFsIHR2Ow0KLQ0KLQl0di50dl9zZWMgPSAw Ow0KLQl0di50dl91c2VjID0gMjAwOw0KLQ0KLQlGRF9aRVJPKCZ3YWl0c2V0KTsNCi0JRkRf U0VUKGZpbGVubyhzdGRpbiksICZ3YWl0c2V0KTsNCi0NCi0JaWYgKHNlbGVjdChGRF9TRVRT SVpFLCAmd2FpdHNldCwgTlVMTCwgTlVMTCwgJnR2KSA8IDApIHsNCi0JICAgIHBlcnJvcigi Zm9ybTogc2VsZWN0Iik7DQotCX0NCi0NCi0JcmV0ID0gcmVhZChmaWxlbm8oc3RkaW4pLCAm KGJ1ZlswXSksIDEpOw0KLSNpZm5kZWYgX19NSU5HVzMyX18NCi0JZmNudGwoZmlsZW5vKGNo aWxkX3JlY3YpLCBGX1NFVEZMLCBPX05PTkJMT0NLKTsJLyogRG9uJ3Qgd2FpdCBpZiBwaXBl IGlzIGVtcHR5ICovDQotI2VuZGlmDQotCWlmIChyZXQgPT0gMCkNCi0JICAgIGJyZWFrOwkJ LyogUGlwZSB3YXMgY2xvc2VkIGJ5IHBhcmVudCAtPiBxdWl0ICovDQotCWlmIChyZXQgPT0g MSkgew0KLQkgICAgR19kZWJ1ZygzLCAiRm9ybTogcmVjZWl2ZWQgPSAnJWMnIiwgYnVmWzBd KTsNCi0JICAgIGlmIChidWZbMF0gPT0gJ08nKSB7DQotCQlpZiAoIWZvcm1fb3Blbikgew0K LQkJICAgIEdfZGVidWcoMywgIkZvcm0gaXMgbm90IG9wZW5lZCIpOw0KLQkJICAgIC8qIE9w ZW4gdGhlIHdpbmRvdyBhbmQgZGlzcGxheSB0aGUgZm9ybSAqLw0KLQkJICAgIGludGVycCA9 IFRjbF9DcmVhdGVJbnRlcnAoKTsNCi0JCSAgICBpZiAoVGNsX0luaXQoaW50ZXJwKSA9PSBU Q0xfRVJST1IpDQotCQkJR19mYXRhbF9lcnJvcigiVGNsX0luaXQgZmFpbGVkOiAlc1xuIiwg aW50ZXJwLT5yZXN1bHQpOw0KLQkJICAgIGlmIChUa19Jbml0KGludGVycCkgPT0gVENMX0VS Uk9SKQ0KLQkJCUdfZmF0YWxfZXJyb3IoIlRrX0luaXQgZmFpbGVkOiAlc1xuIiwgaW50ZXJw LT5yZXN1bHQpOw0KLQ0KLQkJICAgIFRjbF9DcmVhdGVDb21tYW5kKGludGVycCwgInN1Ym1p dCIsIChUY2xfQ21kUHJvYyAqKSBzdWJtaXQsDQotCQkJCSAgICAgIChDbGllbnREYXRhKSBO VUxMLA0KLQkJCQkgICAgICAoVGNsX0NtZERlbGV0ZVByb2MgKikgTlVMTCk7DQotCQkgICAg VGNsX0NyZWF0ZUNvbW1hbmQoaW50ZXJwLCAic2V0X3ZhbHVlIiwNCi0JCQkJICAgICAgKFRj bF9DbWRQcm9jICopIHNldF92YWx1ZSwNCi0JCQkJICAgICAgKENsaWVudERhdGEpIE5VTEws DQotCQkJCSAgICAgIChUY2xfQ21kRGVsZXRlUHJvYyAqKSBOVUxMKTsNCi0JCSAgICBUY2xf Q3JlYXRlQ29tbWFuZChpbnRlcnAsICJyZXNldF92YWx1ZXMiLA0KLQkJCQkgICAgICAoVGNs X0NtZFByb2MgKikgcmVzZXRfdmFsdWVzLA0KLQkJCQkgICAgICAoQ2xpZW50RGF0YSkgTlVM TCwNCi0JCQkJICAgICAgKFRjbF9DbWREZWxldGVQcm9jICopIE5VTEwpOw0KLQkJICAgIFRj bF9DcmVhdGVDb21tYW5kKGludGVycCwgImNsb3NlX2Zvcm0iLA0KLQkJCQkgICAgICAoVGNs X0NtZFByb2MgKikgY2xvc2VfZm9ybSwNCi0JCQkJICAgICAgKENsaWVudERhdGEpIE5VTEws DQotCQkJCSAgICAgIChUY2xfQ21kRGVsZXRlUHJvYyAqKSBOVUxMKTsNCi0NCi0JCSAgICBz cHJpbnRmKGJ1ZiwgIiVzL2V0Yy9mb3JtL2Zvcm0udGNsIiwgR19naXNiYXNlKCkpOw0KLQkJ ICAgIHJldCA9IFRjbF9FdmFsRmlsZShpbnRlcnAsIGJ1Zik7DQotCQkgICAgaWYgKHJldCA9 PSBUQ0xfRVJST1IpIHsNCi0JCQlpZiAoaW50ZXJwLT5yZXN1bHQgIT0gTlVMTCkNCi0JCQkg ICAgR19mYXRhbF9lcnJvcigiQ2Fubm90IG9wZW4gZm9ybTogJXNcbiIsDQotCQkJCQkgIGlu dGVycC0+cmVzdWx0KTsNCi0JCQllbHNlDQotCQkJICAgIEdfZmF0YWxfZXJyb3IoIkNhbm5v dCBvcGVuIGZvcm1cbiIpOw0KLQkJICAgIH0NCisJaWYgKFRjbF9Jbml0KGludGVycCkgPT0g VENMX0VSUk9SKQ0KKwkJcmV0dXJuIFRDTF9FUlJPUjsNCiANCisJaWYgKFRrX0luaXQoaW50 ZXJwKSA9PSBUQ0xfRVJST1IpDQorCQlyZXR1cm4gVENMX0VSUk9SOw0KIA0KLQkJICAgIGZv cm1fb3BlbiA9IDE7DQotCQl9DQotCQlHX2RlYnVnKDIsICJPcGVuIGZvcm0gJWQiLCBmcm1p ZCk7DQotCQkvKiBSZWFkIHRpdGxlICovDQotCQlmZ2V0cyhidWYsIDEwMDAsIGNoaWxkX3Jl Y3YpOw0KLQkJbGVuZ3RoID0gYXRvaShidWYpOwkvKiBsZW5ndGggb2YgdGhlIHN0cmluZyAq Lw0KLQkJR19kZWJ1ZygyLCAibGVuZ3RoID0gJWQiLCBsZW5ndGgpOw0KLQkJY2hpbGRfdGl0 bGUgPSAoY2hhciAqKUdfbWFsbG9jKGxlbmd0aCArIDEpOw0KLQkJZnJlYWQoY2hpbGRfdGl0 bGUsIGxlbmd0aCwgMSwgY2hpbGRfcmVjdik7DQotCQljaGlsZF90aXRsZVtsZW5ndGhdID0g J1wwJzsNCi0NCi0JCS8qIFJlYWQgaHRtbCAqLw0KLQkJZmdldHMoYnVmLCAxMDAwLCBjaGls ZF9yZWN2KTsNCi0JCWxlbmd0aCA9IGF0b2koYnVmKTsJLyogbGVuZ3RoIG9mIHRoZSBzdHJp bmcgKi8NCi0JCUdfZGVidWcoMiwgImxlbmd0aCA9ICVkIiwgbGVuZ3RoKTsNCi0JCWNoaWxk X2h0bWwgPSAoY2hhciAqKUdfbWFsbG9jKGxlbmd0aCArIDEpOw0KLQkJZnJlYWQoY2hpbGRf aHRtbCwgbGVuZ3RoLCAxLCBjaGlsZF9yZWN2KTsNCi0JCWNoaWxkX2h0bWxbbGVuZ3RoXSA9 ICdcMCc7DQotDQotCQltZW1zZXQoYnVmLCAnXDAnLCBzdHJsZW4oYnVmKSk7DQotDQotCQll bmNvZGluZ192YWwgPSBHX19nZXRlbnYoIkdSQVNTX0RCX0VOQ09ESU5HIik7DQotCQlUY2xf RXh0ZXJuYWxUb1V0ZihpbnRlcnAsDQotCQkJCSAgVGNsX0dldEVuY29kaW5nKGludGVycCwg ZW5jb2RpbmdfdmFsKSwNCi0JCQkJICBjaGlsZF9odG1sLCBzdHJsZW4oY2hpbGRfaHRtbCks IDAsIE5VTEwsDQotCQkJCSAgYnVmLCBzdHJsZW4oY2hpbGRfaHRtbCkgKiAyLCBOVUxMLCBO VUxMLA0KLQkJCQkgIE5VTEwpOw0KLQ0KLQkJR19kZWJ1ZygzLCAiQ3VycmVudCBHUkFTU19E Ql9FTkNPRElORzogJXMiLCBlbmNvZGluZ192YWwpOw0KLQkJaWYgKFRjbF9TZXRTeXN0ZW1F bmNvZGluZyhpbnRlcnAsIGVuY29kaW5nX3ZhbCkgPT0gVENMX0VSUk9SKSB7DQotCQkgICAg ZnByaW50ZihzdGRlcnIsDQotCQkJICAgICJDb3VsZCBub3Qgc2V0IFRjbCBzeXN0ZW0gZW5j b2RpbmcgdG8gJXNcbiIsDQotCQkJICAgIGVuY29kaW5nX3ZhbCk7DQotCQl9DQorCVRjbF9T dGF0aWNQYWNrYWdlKGludGVycCwgIlRrIiwgVGtfSW5pdCwgVGtfU2FmZUluaXQpOw0KIA0K LQkJR19kZWJ1ZygyLCAiRm9ybTogaHRtbCA9ICVzIiwgYnVmKTsNCisJLyoNCisJICogQ2Fs bCBUY2xfQ3JlYXRlQ29tbWFuZCBmb3IgYXBwbGljYXRpb24tc3BlY2lmaWMgY29tbWFuZHMs IGlmDQorCSAqIHRoZXkgd2VyZW4ndCBhbHJlYWR5IGNyZWF0ZWQgYnkgdGhlIGluaXQgcHJv Y2VkdXJlcyBjYWxsZWQgYWJvdmUuDQorCSAqLw0KKw0KKwlUY2xfQ3JlYXRlQ29tbWFuZChp bnRlcnAsICJzdWJtaXQiLCAoVGNsX0NtZFByb2MgKikgc3VibWl0LA0KKwkJCSAgKENsaWVu dERhdGEpIE5VTEwsDQorCQkJICAoVGNsX0NtZERlbGV0ZVByb2MgKikgTlVMTCk7DQorCVRj bF9DcmVhdGVDb21tYW5kKGludGVycCwgInNldF92YWx1ZSIsDQorCQkJICAoVGNsX0NtZFBy b2MgKikgc2V0X3ZhbHVlLA0KKwkJCSAgKENsaWVudERhdGEpIE5VTEwsDQorCQkJICAoVGNs X0NtZERlbGV0ZVByb2MgKikgTlVMTCk7DQorCVRjbF9DcmVhdGVDb21tYW5kKGludGVycCwg InJlc2V0X3ZhbHVlcyIsDQorCQkJICAoVGNsX0NtZFByb2MgKikgcmVzZXRfdmFsdWVzLA0K KwkJCSAgKENsaWVudERhdGEpIE5VTEwsDQorCQkJICAoVGNsX0NtZERlbGV0ZVByb2MgKikg TlVMTCk7DQorCS8qDQorCSAqIFNwZWNpZnkgYSB1c2VyLXNwZWNpZmljIHN0YXJ0dXAgZmls ZSB0byBpbnZva2UgaWYgdGhlIGFwcGxpY2F0aW9uDQorCSAqIGlzIHJ1biBpbnRlcmFjdGl2 ZWx5LiAgVHlwaWNhbGx5IHRoZSBzdGFydHVwIGZpbGUgaXMgIn4vLmFwcHJjIg0KKwkgKiB3 aGVyZSAiYXBwIiBpcyB0aGUgbmFtZSBvZiB0aGUgYXBwbGljYXRpb24uICBJZiB0aGlzIGxp bmUgaXMgZGVsZXRlZA0KKwkgKiB0aGVuIG5vIHVzZXItc3BlY2lmaWMgc3RhcnR1cCBmaWxl IHdpbGwgYmUgcnVuIHVuZGVyIGFueSBjb25kaXRpb25zLg0KKwkgKi8NCiANCi0JCS8qIElu c2VydCBuZXcgcGFnZSAqLw0KLQkJVGNsX1NldFZhcihpbnRlcnAsICJodG1sIiwgYnVmLCAw KTsNCi0JCXNwcmludGYoYnVmLCAiYWRkX2Zvcm0gJWQgXCIlc1wiIiwgZnJtaWQsIGNoaWxk X3RpdGxlKTsNCi0JCVRjbF9FdmFsKGludGVycCwgYnVmKTsNCi0NCi0JCWZwcmludGYoY2hp bGRfc2VuZCwgIk8iKTsJLyogT0sgKi8NCi0JCWZmbHVzaChjaGlsZF9zZW5kKTsNCi0JCWZy bWlkKys7DQotCQlHX2RlYnVnKDIsICJGb3JtIGRpc3BsYXllZFxuIik7DQotCSAgICB9DQot CSAgICBlbHNlIGlmIChidWZbMF0gPT0gJ0MnKSB7CS8qIGNsZWFyIG9sZCBmb3JtcyAqLw0K LQkJVGNsX0V2YWwoaW50ZXJwLCAiY2xlYXJfbmIiKTsNCi0JCWZwcmludGYoY2hpbGRfc2Vu ZCwgIk8iKTsJLyogT0sgKi8NCi0JCWZmbHVzaChjaGlsZF9zZW5kKTsNCi0JICAgIH0NCi0J ICAgIGVsc2UgaWYgKGJ1ZlswXSA9PSAnRCcpIHsJLyogZG9uZSEgKi8NCi0JCVRjbF9FdmFs KGludGVycCwgImNsZWFyX25iIik7DQotCQlmcHJpbnRmKGNoaWxkX3NlbmQsICJPIik7CS8q IE9LICovDQotCQlmZmx1c2goY2hpbGRfc2VuZCk7DQotCQlicmVhazsNCi0JICAgIH0NCi0J fQ0KLQ0KLQlUY2xfRXZhbChpbnRlcnAsICJ1cGRhdGUiKTsNCi0gICAgfQ0KKwlUY2xfU2V0 VmFyKGludGVycCwgInRjbF9yY0ZpbGVOYW1lIiwgIn4vLmdyYXNzZm9ybXJjIiwgVENMX0dM T0JBTF9PTkxZKTsNCisJcmV0dXJuIFRDTF9PSzsNCit9DQogDQotICAgIFRjbF9FdmFsKGlu dGVycCwgImRlc3Ryb3kgLiIpOw0KLSAgICBHX2RlYnVnKDMsICJGb3JtOiBlbmRcbiIpOw0K LSAgICBleGl0KDApOw0KK2ludCBtYWluKGludCBhcmdjLCBjaGFyICphcmd2W10pDQorew0K KwlHX2dpc2luaXQoImZvcm0iKTsNCisJR19kZWJ1ZygyLCAiRm9ybTogbWFpbigpIik7DQog DQotICAgIHJldHVybiAwOw0KKwlUa19NYWluKGFyZ2MsIGFyZ3YsIFRjbF9BcHBJbml0KTsN CisJcmV0dXJuIDA7DQogfQ0KKw0KSW5kZXg6IGxpYi9mb3JtL2Zvcm0udGNsDQo9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09DQpSQ1MgZmlsZTogL2dyYXNzcmVwb3NpdG9yeS9ncmFzczYvbGliL2Zvcm0vZm9y bS50Y2wsdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjMNCmRpZmYgLXUgLXIxLjMgZm9ybS50 Y2wNCi0tLSBsaWIvZm9ybS9mb3JtLnRjbAkxNyBGZWIgMjAwMyAwNjo0MTowMyAtMDAwMAkx LjMNCisrKyBsaWIvZm9ybS9mb3JtLnRjbAkxMCBGZWIgMjAwNyAxNDo1MTo1MiAtMDAwMA0K QEAgLTIsMTcgKzIsOSBAQA0KIHBhY2thZ2UgcmVxdWlyZSAtZXhhY3QgQldpZGdldCAxLjIu MSANDQogI3BhY2thZ2UgcmVxdWlyZSBodHRwDQ0KIA0NCi1zZXQgZm9ybXBhdGggJGVudihH SVNCQVNFKS9ldGMvZm9ybS8gDQ0KK3NldCBmb3JtcGF0aCAkZW52KEdJU0JBU0UpL2V0Yy9m b3JtDQ0KIHNvdXJjZSAkZm9ybXBhdGgvaHRtbF9saWJyYXJ5LnRjbA0NCiANDQotc2V0IHN1 Ym1pdF9yZXN1bHQgIiINDQotc2V0IHN1Ym1pdF9tc2cgIiINDQotc2V0IGh0bWwgIiINDQot DQ0KLXNldCBuYiBbTm90ZUJvb2sgLm5iXQ0NCi0kbmIgY29uZmlndXJlIC13aWR0aCAzMDAg LWhlaWdodCA1MDANDQotcGFjayAubmIgLWZpbGwgYm90aCAtZXhwYW5kIHllcw0NCi0NDQog cHJvYyBjcmVhdGVfc3VibWl0X21zZyB7IGZvcm1pZCAgfSAgew0NCiAgICAgZ2xvYmFsIHN1 Ym1pdF9yZXN1bHQgc3VibWl0X21zZyBmb3JtZg0NCiANDQpAQCAtNzAsNCArNjIsOTcgQEAN CiAgICAgY3JlYXRlX3N1Ym1pdF9tc2cgJGZvcm1pZCAgIA0NCiB9DQ0KIA0NCitwcm9jIG1h a2VfZm9ybSB7fSB7DQ0KKwlnbG9iYWwgbmINDQorDQ0KKwlzZXQgbmIgW05vdGVCb29rIC5u Yl0NDQorCSRuYiBjb25maWd1cmUgLXdpZHRoIDMwMCAtaGVpZ2h0IDUwMA0NCisJcGFjayAu bmIgLWZpbGwgYm90aCAtZXhwYW5kIHllcw0NCit9DQ0KKw0NCitwcm9jIGNsb3NlX2Zvcm0g e30gew0NCisJZ2xvYmFsIGZvcm1fb3Blbg0NCisJd20gd2l0aGRyYXcgLg0NCisJc2V0IGZv cm1fb3BlbiBmYWxzZQ0NCit9DQ0KKw0NCitwcm9jIHByb2Nlc3NfY29tbWFuZCB7fSB7DQ0K KwlnbG9iYWwgZW52DQ0KKwlnbG9iYWwgY2hpbGRfcmVjdiBjaGlsZF9zZW5kIA0NCisJZ2xv YmFsIGZvcm1fb3BlbiBlbmNvZGluZ192YWwgZnJtaWQNDQorCWdsb2JhbCBodG1sDQ0KKw0N CisJaWYge1tlb2YgJGNoaWxkX3JlY3ZdfSB7DQ0KKwkJZXhpdCAwDQ0KKwl9DQ0KKw0NCisJ c2V0IGNtZCBbcmVhZCAkY2hpbGRfcmVjdiAxXQ0NCisNDQorCXN3aXRjaCAkY21kIHsNDQor CQlPIHsNDQorCQkJaWYgeyEgJGZvcm1fb3Blbn0gew0NCisJCQkJd20gc3RhdGUgLiBub3Jt YWwNDQorCQkJCXNldCBmb3JtX29wZW4gdHJ1ZQ0NCisJCQl9DQ0KKwkJCSMgIFJlYWQgdGl0 bGUgDQ0KKwkJCXNldCBsZW5ndGggW2dldHMgJGNoaWxkX3JlY3ZdDQ0KKwkJCXNldCBjaGls ZF90aXRsZSBbcmVhZCAkY2hpbGRfcmVjdiAkbGVuZ3RoXQ0NCisNDQorCQkJIyAgUmVhZCBo dG1sIA0NCisJCQlzZXQgbGVuZ3RoIFtnZXRzICRjaGlsZF9yZWN2XQ0NCisJCQlzZXQgY2hp bGRfaHRtbCBbcmVhZCAkY2hpbGRfcmVjdiAkbGVuZ3RoXQ0NCisNDQorCQkJc2V0IGNoaWxk X2h0bWwgW2VuY29kaW5nIGNvbnZlcnRmcm9tICRlbmNvZGluZ192YWwgJGNoaWxkX2h0bWxd DQ0KKw0NCisJCQkjICBJbnNlcnQgbmV3IHBhZ2UgDQ0KKwkJCXNldCBodG1sICRjaGlsZF9o dG1sDQ0KKwkJCWFkZF9mb3JtICRmcm1pZCAkY2hpbGRfdGl0bGUNDQorDQ0KKwkJCXB1dHMg LW5vbmV3bGluZSAkY2hpbGRfc2VuZCBPDQ0KKwkJCWZsdXNoICRjaGlsZF9zZW5kDQ0KKwkJ CWluY3IgZnJtaWQNDQorCQl9DQ0KKwkJQyB7CSMgIGNsZWFyIG9sZCBmb3JtcyANDQorCQkJ Y2xlYXJfbmINDQorCQkJcHV0cyAtbm9uZXdsaW5lICRjaGlsZF9zZW5kIE8NDQorCQkJZmx1 c2ggJGNoaWxkX3NlbmQNDQorCQl9DQ0KKwkJRCB7CSMgIGRvbmUhIA0NCisJCQljbGVhcl9u Yg0NCisJCQlwdXRzIC1ub25ld2xpbmUgJGNoaWxkX3NlbmQgTw0NCisJCQlmbHVzaCAkY2hp bGRfc2VuZA0NCisNDQorCQkJZGVzdHJveSAuDQ0KKwkJCWV4aXQgMA0NCisJCX0NDQorCX0N DQorfQ0NCisNDQorbWFrZV9mb3JtDQ0KKw0NCit3bSBwcm90b2NvbCAuIFdNX0RFTEVURV9X SU5ET1cgY2xvc2VfZm9ybQ0NCisNDQogYmluZCAuIDxEZXN0cm95PiB7IGlmIHsgIiVXIiA9 PSAiLiJ9IHsgY2xvc2VfZm9ybSB9IH0NDQorDQ0KK3NldCBzdWJtaXRfcmVzdWx0ICIiDQ0K K3NldCBzdWJtaXRfbXNnICIiDQ0KK3NldCBodG1sICIiDQ0KKw0NCitzZXQgZnJtaWQgMA0N CitzZXQgZm9ybV9vcGVuIHRydWUNDQorDQ0KK3NldCBjaGlsZF9yZWN2IHN0ZGluDQ0KK3Nl dCBjaGlsZF9zZW5kIHN0ZG91dA0NCisNDQorc2V0IGVuY29kaW5nX3ZhbCBbZXhlYyBnLmdp c2VudiBHUkFTU19EQl9FTkNPRElOR10NDQoraWYgeyRlbmNvZGluZ192YWwgPT0gIiJ9IHsN DQorCXNldCBlbmNvZGluZ192YWwgW2VuY29kaW5nIHN5c3RlbV0NDQorfQ0NCisNDQoraWYg e1tjYXRjaCB7ZW5jb2Rpbmcgc3lzdGVtICRlbmNvZGluZ192YWx9XX0gew0NCisJcHV0cyBz dGRlcnIgIkNvdWxkIG5vdCBzZXQgVGNsIHN5c3RlbSBlbmNvZGluZyB0byAkZW5jb2Rpbmdf dmFsIg0NCit9DQ0KKw0NCitmY29uZmlndXJlICRjaGlsZF9yZWN2IC1idWZmZXJpbmcgbm9u ZSAtZW5jb2RpbmcgYmluYXJ5IC10cmFuc2xhdGlvbiBiaW5hcnkNDQorDQ0KK2ZpbGVldmVu dCAkY2hpbGRfcmVjdiByZWFkYWJsZSBwcm9jZXNzX2NvbW1hbmQNDQpJbmRleDogbGliL2Zv cm0vb3Blbi5jDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09DQpSQ1MgZmlsZTogL2dyYXNzcmVwb3NpdG9yeS9n cmFzczYvbGliL2Zvcm0vb3Blbi5jLHYNCnJldHJpZXZpbmcgcmV2aXNpb24gMS4xMw0KZGlm ZiAtdSAtcjEuMTMgb3Blbi5jDQotLS0gbGliL2Zvcm0vb3Blbi5jCTcgTm92IDIwMDYgMDY6 MDU6MDcgLTAwMDAJMS4xMw0KKysrIGxpYi9mb3JtL29wZW4uYwkxMCBGZWIgMjAwNyAxNDo1 MTo1MiAtMDAwMA0KQEAgLTUxLDkgKzUxLDYgQEANCiAjZW5kaWYgLypVU0VfR19TT0NLUyov DQogICAgIGludCAgICAgICAgbGVuZ3RoOw0KICAgICAvKiBjaGlsZCAqLw0KLSAgICBjaGFy ICAgICAgICBidWZbMjAwMF07DQotICAgIA0KLQ0KICAgICANCiAgICAgR19kZWJ1ZyAoIDIs ICJGX29wZW4oKTogdGl0bGUgPSAlcyIsIHRpdGxlKTsNCiAgICAgDQpAQCAtNzAsNiArNjcs OCBAQA0KICAgICB9DQogDQogICAgIGlmICggcGlkID09IDAgKSB7IC8qIENoaWxkICovDQor CWNoYXIgY29tbWFuZFsyMDAwXSwgc2NyaXB0WzIwMDBdOw0KKw0KICAgICAgICAgR19kZWJ1 ZyAoIDIsICJDSElMRCIgKTsNCiANCiAgICAgICAgIC8qIE5vdGU6IElmIHlvdSBhcmUgZm9y a2luZyBpbiBhIFRrIGJhc2VkIGFwbGxpY2F0aW9uICB5b3UNCkBAIC05NCw5ICs5MywxMCBA QA0KIA0KIA0KIAkNCi0Jc3ByaW50ZihidWYsIiVzL2V0Yy9mb3JtL2Zvcm0iLCBHX2dpc2Jh c2UoKSk7DQorCXNwcmludGYoY29tbWFuZCwgIiVzL2V0Yy9mb3JtL2Zvcm0iLCBHX2dpc2Jh c2UoKSk7DQorCXNwcmludGYoc2NyaXB0LCAgIiVzL2V0Yy9mb3JtL2Zvcm0udGNsIiwgR19n aXNiYXNlKCkpOw0KIA0KLQlleGVjbCAoIi9iaW4vc2giLCAic2giLCAiLWMiLCBidWYsIE5V TEwpOw0KKwlleGVjbChjb21tYW5kLCAiZm9ybSIsICItZiIsIHNjcmlwdCwgTlVMTCk7DQog CQ0KIAlHX2RlYnVnKDIsICJDSElMRCBFTkRcbiIpOw0KIAlleGl0ICgwKTs= --8XkdMeO807-- --- Headers Follow --- >From glynn@gclements.plus.com Sat Feb 10 15:59:12 2007 Return-Path: Delivered-To: grass-bugs@lists.intevation.de Received: from kolab.intevation.de (salmakis.hq.intevation.de [192.168.11.9]) by lists.intevation.de (Postfix) with ESMTP id 147611005CB for ; Sat, 10 Feb 2007 15:59:12 +0100 (CET) Received: from localhost (localhost.localdomain [127.0.0.1]) by kolab.intevation.de (Postfix) with ESMTP id EF60B108ECA for ; Sat, 10 Feb 2007 15:59:11 +0100 (CET) Received: from localhost (localhost.localdomain [127.0.0.1]) by kolab.intevation.de (Postfix) with ESMTP id B3293109152 for ; Sat, 10 Feb 2007 15:59:11 +0100 (CET) Received: from cerise.gclements.plus.com (82-71-30-52.dsl.in-addr.zen.co.uk [82.71.30.52]) by kolab.intevation.de (Postfix) with ESMTP id 3780E108ECA for ; Sat, 10 Feb 2007 15:59:09 +0100 (CET) Received: from cerise.gclements.plus.com (localhost [127.0.0.1]) by cerise.gclements.plus.com (8.13.7/8.13.7) with ESMTP id l1AEx4Qt012042; Sat, 10 Feb 2007 14:59:04 GMT Received: (from glynn@localhost) by cerise.gclements.plus.com (8.13.7/8.13.7/Submit) id l1AEx40l012039; Sat, 10 Feb 2007 14:59:04 GMT From: Glynn Clements MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8XkdMeO807" Content-Transfer-Encoding: 7bit Message-ID: <17869.56760.385929.175604@cerise.gclements.plus.com> Date: Sat, 10 Feb 2007 14:59:04 +0000 To: Markus Neteler Cc: Request Tracker , grass developers list Subject: Re: [GRASS-dev] v.digit: Could not set Tcl system encoding fixed (bug #4110) In-Reply-To: <45CC2C73.5030206@itc.it> References: <45C9995E.7010700@itc.it> <45C9F585.30406@o2.pl> <45CAD4F8.5050400@itc.it> <17867.3200.384675.355130@cerise.gclements.plus.com> <45CB36F6.1070906@itc.it> <17867.42607.267308.193576@cerise.gclements.plus.com> <45CC2C73.5030206@itc.it> X-Mailer: VM 7.07 under 21.4 (patch 20) "Double Solitaire" XEmacs Lucid X-Virus-Scanned: by amavisd-new at intevation.de X-Spam-Status: No, hits=-5 tagged_above=-999 required=3 tests=[BAYES_00=-5] X-Spam-Level: -------------------------------------------- Managed by Request Tracker From paul-grass at stjohnspoint.co.uk Sat Feb 10 16:10:59 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Sat Feb 10 16:11:00 2007 Subject: [GRASS-dev] g.proj to create a new location In-Reply-To: <20070208234313.6073c8d4.hamish_nospam@yahoo.com> References: <20070205200634.7217027e.hamish_nospam@yahoo.com> <20070206200326.78e44b29.hamish_nospam@yahoo.com> <20070207150258.3c310a09.hamish_nospam@yahoo.com> <20070208234313.6073c8d4.hamish_nospam@yahoo.com> Message-ID: Hello Hamish On Thu, 8 Feb 2007, Hamish wrote: > I have now added new epsg= and datumtrans= options to g.proj in CVS. > > The epsg= option to create new location by EPSG code is fully > functional: (it just plugs the code into a PROJ4 format string) > > G63> g.proj -c loc=newlocNZTM epsg=2193 > Location newlocNZTM created! > > If it needs more info WRT datum transform options, it currently goes > interactive as the datumtrans= option to list or select datum transform > parms is not yet functional. Paul, can you try and connect this to > get_datum_transform_by_name() and GPJ_ask_datum_params(), or wherever > the number needs to get to? Mucho gracias. I have this working now in my local copy, but just realised a slight flaw with it. Because we are assuming a default of datumtrans=1, there is no way to assume if the user specifically asked for the 1st set of datum transformation parameters, or they are just using the default. Up to now, if the user didn't specifically specify datum transformation parameters, they were not written into the PROJ_INFO, only the datum name. When necessary then (e.g. using one of the re-projection modules), the current default parameters for that datum would be read from the datum.table file and used. So if the default changed (e.g. we discovered it was wrong and updated it) the user wouldn't need to edit their location to take advantage of the update. But if the parameters are written into the PROJ_INFO, then whatever default was in force at the time becomes set in stone. The logic in a few parts of the GRASS gproj library also uses the presence/absence of specific transformation parameters in the PROJ_INFO as an indicator of how likely any parameters present are to be correct/appropriate for the location. E.g. when writing an output WKT file, GRASS always puts the datum name in, but only adds TOWGS84 parameters if they were specifically specified in the PROJ_INFO. Again, the logic is that the parameters had been specifically specified so there was a good chance they were correct and there was no harm promulgating them on. But if the user had just accepted the default parameters, then we're not so sure if they're appropriate for the specific area of the data, so just put the datum name in and whoever receives the export data can use their own initiative in choosing appropriate parameters. With this new functionality however, we are always assuming the user specified datumtrans=xxx, so the parameters are always written in. I'm not sure what to do about this, whether it's nothing to worry about or not. Also, I was wondering what format would be appropriate for the GUI-parsable list of datum transformation parameters. In the copy I have I'm just printing to stdout the list that you got by typing list at the old interactive prompt. Are there any existing examples of something similar I wonder. Paul From michael.barton at asu.edu Sat Feb 10 17:14:35 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sat Feb 10 17:14:45 2007 Subject: [GRASS-dev] [grass-code issues][279] Define location with EPSG codes hangs grass In-Reply-To: <20070210112107.D49651801DA7@pyrosoma.intevation.org> Message-ID: This is a known problem. Some EPSG codes don't have quite enough information to properly define a project. The underlying GRASS module then attempts to "ask" the user for more information, assuming that the user is running the module from an interactive xterminal. Because the user is NOT running the module from an interactive xterminal, there is no way for the user to know that more information is needed or to respond. This is currently being fixed. Michael On 2/10/07 4:21 AM, "grass-codeissues@wald.intevation.org" wrote: > code issues item #279, was opened at 2007-02-10 12:21 > Status: Open > Priority: 3 > Submitted By: Carlos D?vila (carluti) > Assigned to: Nobody (None) > Summary: Define location with EPSG codes hangs grass > Issue type: module bug > Issue status: None > GRASS version: CVS HEAD > GRASS component: None > Operating system: Linux > Operating system version: debian testing 2.6.18-3-486 > GRASS CVS checkout date, if applies (YYMMDD): 070210 > > > Initial Comment: > When I try to define a new location from startup window, using the option EPSG > codes I give the code number (23030) and click on Define location button and > grass hangs and I have to close and restart it. I've tried in two different > machines with the same linux and grass installation (cvs snapshot from > 07-02-04 and 07-02-10) and problem is the same > > ---------------------------------------------------------------------- > > You can respond by visiting: > http://wald.intevation.org/tracker/?func=detail&atid=204&aid=279&group_id=21 > > __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From grass-codepatches at wald.intevation.org Sat Feb 10 18:21:22 2007 From: grass-codepatches at wald.intevation.org (grass-codepatches@wald.intevation.org) Date: Sat Feb 10 20:26:58 2007 Subject: [GRASS-dev] [grass-code patches][280] Fix Help button in gis.m raster/vector display conf locks up gis.m Message-ID: <20070210172122.DD35C1801DAA@pyrosoma.intevation.org> code patches item #280, was opened at 2007-02-10 19:21 Status: Open Priority: 3 Submitted By: M?ris Narti?s (marisn) Assigned to: Nobody (None) Summary: Fix Help button in gis.m raster/vector display conf locks up gis.m Patch status: None Patch type: fix GRASS component: gis.m GRASS version: CVS HEAD GRASS CVS checkout date, if applies (YYMMDD): 070210 Initial Comment: In GRASS 6.2.1 if You press "Help" to get help about raster/vector displaying, it will run g.manual and lock up gis.m till You close browser (konqueror). Not good. In GRASS 6.3.cvs if You do same, gis.m will remain locked also after closing help browser (konqueror). Only way out after pressing help is to use xkill. Really bad. This patch changes all "run g.manual foo" in gis.m to "spawn g.manual foo". It works now for me with CVS head (10.02.2007.) and Konqueror. I can open help and continue to use gis.m in same time. If looks OK, somebody commit it, please. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=205&aid=280&group_id=21 From grass-codepatches at wald.intevation.org Sat Feb 10 20:30:22 2007 From: grass-codepatches at wald.intevation.org (grass-codepatches@wald.intevation.org) Date: Sat Feb 10 20:31:21 2007 Subject: [GRASS-dev] [grass-code patches][281] Fix for gis.m profile dialog division by zero Message-ID: <20070210193022.BFA281801DAA@pyrosoma.intevation.org> code patches item #281, was opened at 2007-02-10 21:30 Status: Open Priority: 3 Submitted By: M?ris Narti?s (marisn) Assigned to: Nobody (None) Summary: Fix for gis.m profile dialog division by zero Patch status: None Patch type: fix GRASS component: gis.m GRASS version: CVS HEAD GRASS CVS checkout date, if applies (YYMMDD): 070210 Initial Comment: This patch prevents gis.m profile tool from dividing by zero and makes popup windows to appear on top of profile window and not gis.m main window. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=205&aid=281&group_id=21 From landa.martin at gmail.com Sat Feb 10 21:29:13 2007 From: landa.martin at gmail.com (Martin Landa) Date: Sat Feb 10 21:29:16 2007 Subject: [GRASS-dev] Re: [GRASS-user] r.fillnulls in the latest cvs version doesn't work appropriately In-Reply-To: <17870.2363.656280.59518@cerise.gclements.plus.com> References: <17868.48904.170493.919381@cerise.gclements.plus.com> <17870.2363.656280.59518@cerise.gclements.plus.com> Message-ID: Hi, 2007/2/10, Glynn Clements : [snip] > > I hope I fixed this problem or I missed something? Now: > > > > g.region -m == g.region -gm (== g.region -pgm) > > Actually, I don't consider -gm => -gpm to be "correct"; what do you > use if you *only* want the resolution in metres, and not the region? My original idea was to make the -g flag more "universal". It means shell-style output used in combination with *other* print flags. This cased a lot of problems. AFAIK the -m flag is currently the same as the -mg (or now -mgp) flag combination. I think it is not the right solution, the -m flag should print *only* resolution as Glynn suggests. I suppose to start implementing Glynn's proposal from the scratch -- the print parameter and to supersede the print flags, and in the future versions of GRASS remove them. What do you think about it? > Explicitly adding -p in r.nulls is preferable, IMHO. OK. Martin [CC: grassdev] -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From glynn at gclements.plus.com Sat Feb 10 22:28:48 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Feb 10 22:29:48 2007 Subject: [GRASS-dev] Re: [GRASS-user] r.fillnulls in the latest cvs version doesn't work appropriately In-Reply-To: References: <17868.48904.170493.919381@cerise.gclements.plus.com> <17870.2363.656280.59518@cerise.gclements.plus.com> Message-ID: <17870.14608.644999.935213@cerise.gclements.plus.com> Martin Landa wrote: > > > I hope I fixed this problem or I missed something? Now: > > > > > > g.region -m == g.region -gm (== g.region -pgm) > > > > Actually, I don't consider -gm => -gpm to be "correct"; what do you > > use if you *only* want the resolution in metres, and not the region? > > My original idea was to make the -g flag more "universal". It means > shell-style output used in combination with *other* print flags. This > cased a lot of problems. > > AFAIK the -m flag is currently the same as the -mg (or now -mgp) flag > combination. I think it is not the right solution, the -m flag should > print *only* resolution as Glynn suggests. > > I suppose to start implementing Glynn's proposal from the scratch -- > the print parameter and to supersede the print flags, and in the > future versions of GRASS remove them. What do you think about it? For now, I suggest reverting the changes to the printing flags, and thinking about a print= option instead. AFAICT, backwards compatibility requires that the printing flags remain a mess. One consequence is that you will need to duplicate printwindow.c. Trying to make one version handle both the existing mess (which essentially dictates that certain combinations of switches will print various pieces of information in entirely different formats) and a sane system will result in unmanageable complexity. -- Glynn Clements From michael.barton at asu.edu Sat Feb 10 22:36:06 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sat Feb 10 22:36:16 2007 Subject: [GRASS-dev] Re: [GRASS-user] r.fillnulls in the latest cvs version doesn't work appropriately In-Reply-To: Message-ID: However this gets set, we'll need to change all references in in various places in the GUI. I hope the g.region flags and options can stabilize soon. Michael On 2/10/07 1:29 PM, "Martin Landa" wrote: > Hi, > > 2007/2/10, Glynn Clements : > > [snip] > >>> I hope I fixed this problem or I missed something? Now: >>> >>> g.region -m == g.region -gm (== g.region -pgm) >> >> Actually, I don't consider -gm => -gpm to be "correct"; what do you >> use if you *only* want the resolution in metres, and not the region? > > My original idea was to make the -g flag more "universal". It means > shell-style output used in combination with *other* print flags. This > cased a lot of problems. > > AFAIK the -m flag is currently the same as the -mg (or now -mgp) flag > combination. I think it is not the right solution, the -m flag should > print *only* resolution as Glynn suggests. > > I suppose to start implementing Glynn's proposal from the scratch -- > the print parameter and to supersede the print flags, and in the > future versions of GRASS remove them. What do you think about it? > >> Explicitly adding -p in r.nulls is preferable, IMHO. > > OK. > > Martin > > [CC: grassdev] __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From neteler at itc.it Sat Feb 10 23:25:58 2007 From: neteler at itc.it (Markus Neteler) Date: Sat Feb 10 23:25:59 2007 Subject: [GRASS-dev] d.text vs d.text.freetype vs d.text.new Message-ID: <20070210222558.GA6790@bartok.itc.it> Hi, while starting to write up the changes in GRASS 6.3 for an upcoming 6.3.0 release, I found that we have d.text d.text.freetype d.text.new What is the state of d.text.new? Markus From glynn at gclements.plus.com Sun Feb 11 02:40:35 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Feb 11 02:40:38 2007 Subject: [GRASS-dev] d.text vs d.text.freetype vs d.text.new In-Reply-To: <20070210222558.GA6790@bartok.itc.it> References: <20070210222558.GA6790@bartok.itc.it> Message-ID: <17870.29715.29314.131138@cerise.gclements.plus.com> Markus Neteler wrote: > while starting to write up the changes in GRASS 6.3 for > an upcoming 6.3.0 release, I found that we have > d.text > d.text.freetype > d.text.new > > What is the state of d.text.new? AFAICT, it's essentially a superset of the other two. Although it lacks the charset=, path= and -c switches from d.text.freetype, that functionality is available through other means (-c is implied if text= isn't used, the encoding and path can be set in the freetypecap file or via d.font[.freetype]). -- Glynn Clements From tutey at o2.pl Sun Feb 11 12:58:02 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Sun Feb 11 12:58:22 2007 Subject: [GRASS-dev] [bug #5483] (grass) g.mremove through gis manager GUI seems not to work well In-Reply-To: References: <20070207095911.CADFA1005C4@lists.intevation.de> <45C9A4F3.5040304@itc.it> <17865.59758.189673.884182@cerise.gclements.plus.com> <20070208113827.56c056e0.hamish_nospam@yahoo.com> Message-ID: <45CF04CA.5060105@o2.pl> Paul Kelly wrote: > On Thu, 8 Feb 2007, Hamish wrote: > >> Markus: >>>> up to now interactive input in tcl based dialogs is not possible. >>>> Using the -f flag (force removal) you can delete also in gis.m. >>>> >>>> Probably we need to enforce -f somehow in gis.m - how to do that? >> >> Glynn: >>> I've committed a fix which removes the prompting code. The -f flag >>> remains for compatibility but is ignored. >> >> I understand the push to remove interactive, but this one is a fairly >> important failsafe and I wouldn't mind it staying. With the -f flag a > > I agree this seems a bit of a dangerous change, especially since an easy > workaround was available... hope it doesn't catch anybody out who is > just experimenting with a wildcard pattern but not sure if it's the one > they want! I know I have used it like that in the past anyway. I'm uneasy about this change too. Users who knew how g.mremove worked in past will be surprised the safety question has been removed. Some of them will be surprised badly, learning it when a precious map is removed with the rest of the crowd on a sudden, while the user expected y/n prompt. I was never really carefull when giving the wildcard to g.mremove. Propably nobody was, since we knew g.mremove will let us me verify the wildcard's result before deleting data. Now the wildcard has to be perfect at a first attempt, which is a unrealistic requirement when you have dozens of maps in the mapset. I agree that the interactivity has to be removed when possible, but in this case it is too radical change I guess. It would be all OK if g.mremove never asked for confirmation. But since it used to, it's behaviour as users knew it for years is changed, and this change will lead to data loss and user frustration. I don't think such radical changes, even as fixes, should be allowed during GRASS 6. What do you think about this: if g.mremove cannot remain half-interactive, I'd suggest getting rid of it alltogether, and replacing it's manual page with an instruction how to use "g.mlist sep=," and feed it's output to g.remove by hand (I can write it). Although removing a module during GRASS 6 should be avoided too, I think that this would do less harm than letting g.mremove delete user's data without control. Or maybe revert the changes in g.mremove as it was, for GRASS 6, and postpone working on it to GRASS 7? As for GRASS 7, I'd still vote on removing it completely, as described above, instead of removing it's interactiveness, for the sake of user's data. Maciek From grass-codeissues at wald.intevation.org Sun Feb 11 12:59:29 2007 From: grass-codeissues at wald.intevation.org (grass-codeissues@wald.intevation.org) Date: Sun Feb 11 13:23:53 2007 Subject: [GRASS-dev] [grass-code issues][282] Label size fixed in dialog Message-ID: <20070211115929.D9DC01801DA1@pyrosoma.intevation.org> code issues item #282, was opened at 2007-02-11 12:59 Status: Open Priority: 3 Submitted By: Carlos D?vila (carluti) Assigned to: Nobody (None) Summary: Label size fixed in dialog Issue type: None Issue status: None GRASS version: CVS HEAD GRASS component: GUI other Operating system: Linux Operating system version: debian testing 2.6.18-3-486 GRASS CVS checkout date, if applies (YYMMDD): Initial Comment: Last label in the dialog "Define location using EPSG projection codes" from "GRASS Startup" has a fixed size, so that message appear cut in some languages when it's longer than English original one. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=282&group_id=21 From grass-codepatches at wald.intevation.org Sun Feb 11 14:18:20 2007 From: grass-codepatches at wald.intevation.org (grass-codepatches@wald.intevation.org) Date: Sun Feb 11 14:19:09 2007 Subject: [GRASS-dev] [grass-code patches][283] Fix gis.m canvas division by zero on zoom-in and other enhancements Message-ID: <20070211131820.87CB71801A19@pyrosoma.intevation.org> code patches item #283, was opened at 2007-02-11 15:18 Status: Open Priority: 3 Submitted By: M?ris Narti?s (marisn) Assigned to: Nobody (None) Summary: Fix gis.m canvas division by zero on zoom-in and other enhancements Patch status: None Patch type: fix GRASS component: gis.m GRASS version: CVS HEAD GRASS CVS checkout date, if applies (YYMMDD): 070211 Initial Comment: This patch fixes following bugs and usability problems: * If user zooms too far in, it gets prompt about it and not about division by zero (this should be enhanced more to promt to user sooner than map width exceeds resolution); * Warning if user querys map but has no layer selected; * Zoom in/out by rectangle now draws black/yellow dashed rectangle as pure yellow was not visible on yellow maps; * If user zooms in/out by rectangle and has moved mouse for less than 15 pixels, it is asumed to be a click. Prevents users from zooming in/out too much by accident; * Measure tool now works also by single cilck like in other GIS apps (QGIS, ArcView etc.). Old style (by draging) also works; * Warning if user zooms to map but has no map selected. ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=205&aid=283&group_id=21 From michael.barton at asu.edu Sun Feb 11 18:41:56 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sun Feb 11 18:42:49 2007 Subject: [GRASS-dev] [grass-code patches][280] Fix Help button in gis.m raster/vector display conf locks up gis.m In-Reply-To: <20070210172122.DD35C1801DAA@pyrosoma.intevation.org> Message-ID: Maris, When I try both "run" and "spawn" procedures for starting g.manual on my Mac x11 GUI, both work fine without locking up anything. So I can't track why it may be locking on yours (a few other people reported this issue, but it has been variable in its persistence AFAICT). However, if I use spawn, it generates the following message in the terminal every time the module help button is pressed. Starting browser for module d.rast... Other than a bit of clutter, this doesn't cause any other issues (but why do we have this rather pointless message being sent to stderr?) There was some recent discussion about help functionality/non-functionality under windows and I remember something about the menu version of GRASS help working, while the buttons in the options panels and module dialogs were problematic sometimes. This is the code for help in the menu. Maybe it would work better on all systems (requires "global devnull" to be declared in the relevant procedure). exec g.manual -i d.rast > $devnull & Does this work without lockup for you? Does it work for Windows...anyone? Michael On 2/10/07 10:21 AM, "grass-codepatches@wald.intevation.org" wrote: > code patches item #280, was opened at 2007-02-10 19:21 > Status: Open > Priority: 3 > Submitted By: M?ris Narti?s (marisn) > Assigned to: Nobody (None) > Summary: Fix Help button in gis.m raster/vector display conf locks up gis.m > Patch status: None > Patch type: fix > GRASS component: gis.m > GRASS version: CVS HEAD > GRASS CVS checkout date, if applies (YYMMDD): 070210 > > > Initial Comment: > In GRASS 6.2.1 if You press "Help" to get help about raster/vector displaying, > it will run g.manual and lock up gis.m till You close browser (konqueror). Not > good. > In GRASS 6.3.cvs if You do same, gis.m will remain locked also after closing > help browser (konqueror). Only way out after pressing help is to use xkill. > Really bad. > > This patch changes all "run g.manual foo" in gis.m to "spawn g.manual foo". It > works now for me with CVS head (10.02.2007.) and Konqueror. I can open help > and continue to use gis.m in same time. If looks OK, somebody commit it, > please. > > ---------------------------------------------------------------------- > > You can respond by visiting: > http://wald.intevation.org/tracker/?func=detail&atid=205&aid=280&group_id=21 > > __________________________________________ 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 Feb 11 18:53:58 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sun Feb 11 18:54:08 2007 Subject: [GRASS-dev] [grass-code patches][281] Fix for gis.m profile dialog division by zero In-Reply-To: <20070210193022.BFA281801DAA@pyrosoma.intevation.org> Message-ID: Maris, Do you know what is making this divide by 0 and under what circumstances (e.g., range of elevation values on map, location/projection characteristics)? On my system, with a build of 2 days ago, the profiling works fine with the "normal" map of the Spearfish 30m DEM. This happened a couple times before when the GRASS module used for calculating the total elevation range was giving incorrect information in certain circumstances and when there were changes in the function of g.region flags. It was an example of the cascade of effects that can happen if a module function is changed in seemingly minor ways. The error trapping is a good idea in any case. But I want to make sure we also understand the cause rather than just treat the symptoms. Michael On 2/10/07 12:30 PM, "grass-codepatches@wald.intevation.org" wrote: > code patches item #281, was opened at 2007-02-10 21:30 > Status: Open > Priority: 3 > Submitted By: M?ris Narti?s (marisn) > Assigned to: Nobody (None) > Summary: Fix for gis.m profile dialog division by zero > Patch status: None > Patch type: fix > GRASS component: gis.m > GRASS version: CVS HEAD > GRASS CVS checkout date, if applies (YYMMDD): 070210 > > > Initial Comment: > This patch prevents gis.m profile tool from dividing by zero and makes popup > windows to appear on top of profile window and not gis.m main window. > > ---------------------------------------------------------------------- > > You can respond by visiting: > http://wald.intevation.org/tracker/?func=detail&atid=205&aid=281&group_id=21 > > __________________________________________ 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 Feb 11 19:10:26 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Feb 11 19:10:31 2007 Subject: [GRASS-dev] [bug #5483] (grass) g.mremove through gis manager GUI seems not to work well In-Reply-To: <45CF04CA.5060105@o2.pl> References: <20070207095911.CADFA1005C4@lists.intevation.de> <45C9A4F3.5040304@itc.it> <17865.59758.189673.884182@cerise.gclements.plus.com> <20070208113827.56c056e0.hamish_nospam@yahoo.com> <45CF04CA.5060105@o2.pl> Message-ID: <17871.23570.679544.688973@cerise.gclements.plus.com> Maciej Sieczka wrote: > >>>> up to now interactive input in tcl based dialogs is not possible. > >>>> Using the -f flag (force removal) you can delete also in gis.m. > >>>> > >>>> Probably we need to enforce -f somehow in gis.m - how to do that? > >> > >> Glynn: > >>> I've committed a fix which removes the prompting code. The -f flag > >>> remains for compatibility but is ignored. > >> > >> I understand the push to remove interactive, but this one is a fairly > >> important failsafe and I wouldn't mind it staying. With the -f flag a > > > > I agree this seems a bit of a dangerous change, especially since an easy > > workaround was available... hope it doesn't catch anybody out who is > > just experimenting with a wildcard pattern but not sure if it's the one > > they want! I know I have used it like that in the past anyway. > > I'm uneasy about this change too. Users who knew how g.mremove worked > in past will be surprised the safety question has been removed. Some of > them will be surprised badly, learning it when a precious map is > removed with the rest of the crowd on a sudden, while the user expected > y/n prompt. > > I was never really carefull when giving the wildcard to g.mremove. > Propably nobody was, since we knew g.mremove will let us me verify the > wildcard's result before deleting data. Now the wildcard has to be > perfect at a first attempt, which is a unrealistic requirement when you > have dozens of maps in the mapset. > > I agree that the interactivity has to be removed when possible, but in > this case it is too radical change I guess. It would be all OK if > g.mremove never asked for confirmation. But since it used to, it's > behaviour as users knew it for years is changed, and this change will > lead to data loss and user frustration. I don't think such radical > changes, even as fixes, should be allowed during GRASS 6. Okay, I can see your point here. > What do you think about this: if g.mremove cannot remain > half-interactive, I'd suggest getting rid of it alltogether, and > replacing it's manual page with an instruction how to use "g.mlist > sep=," and feed it's output to g.remove by hand (I can write it). > Although removing a module during GRASS 6 should be avoided too, I > think that this would do less harm than letting g.mremove delete user's > data without control. > > Or maybe revert the changes in g.mremove as it was, for GRASS 6, and > postpone working on it to GRASS 7? As for GRASS 7, I'd still vote on > removing it completely, as described above, instead of removing it's > interactiveness, for the sake of user's data. Alternative possibilities: 1. Rename g.mremove (e.g. to g.remove.multi); if anyone asks where it went, remind them that the new version doesn't request confirmation. 2. Revert g.mremove, add a version which doesn't prompt, change gis.m to only refer to the non-prompting version. Personally, I'd favour #1; option #2 undermines attempts to get developers to realise that terminal interaction is unacceptable. In my experience, any rule with an "except in special cases" qualifier may as well not exist. Everyone thinks that their pet case qualifies, and you end up with a useless mess. Either you can rely upon GRASS commands being scriptable, or you can't. Right now, you can't; if you try to build something on top of GRASS, sooner or later something is going to try to prompt the non-existent user for input which will never arrive. -- Glynn Clements From maris.gis at gmail.com Sun Feb 11 19:30:53 2007 From: maris.gis at gmail.com (Maris Nartiss) Date: Sun Feb 11 19:30:56 2007 Subject: [GRASS-dev] Re: Fix for gis.m profile dialog division by zero In-Reply-To: References: <20070210193022.BFA281801DAA@pyrosoma.intevation.org> Message-ID: <2b3d8c1c0702111030q59a8e536nf84e4e1f73fcfc42@mail.gmail.com> Hi Michael, it will divide by zero on any non-normal map - think of binary map (1,null). It has no sense for such maps to create profiles, but it does not mean that gis.m should fail if user is dumb. It's one of my thisweekends efforts to make gis.m foolproof. :) Maris. 2007/2/11, Michael Barton : > Maris, > > Do you know what is making this divide by 0 and under what circumstances > (e.g., range of elevation values on map, location/projection > characteristics)? On my system, with a build of 2 days ago, the profiling > works fine with the "normal" map of the Spearfish 30m DEM. > > This happened a couple times before when the GRASS module used for > calculating the total elevation range was giving incorrect information in > certain circumstances and when there were changes in the function of > g.region flags. It was an example of the cascade of effects that can happen > if a module function is changed in seemingly minor ways. > > The error trapping is a good idea in any case. But I want to make sure we > also understand the cause rather than just treat the symptoms. > > Michael > > > On 2/10/07 12:30 PM, "grass-codepatches@wald.intevation.org" > wrote: > > > code patches item #281, was opened at 2007-02-10 21:30 > > Status: Open > > Priority: 3 > > Submitted By: M?ris Narti?s (marisn) > > Assigned to: Nobody (None) > > Summary: Fix for gis.m profile dialog division by zero > > Patch status: None > > Patch type: fix > > GRASS component: gis.m > > GRASS version: CVS HEAD > > GRASS CVS checkout date, if applies (YYMMDD): 070210 > > > > > > Initial Comment: > > This patch prevents gis.m profile tool from dividing by zero and makes > popup > > windows to appear on top of profile window and not gis.m main window. > > > > ---------------------------------------------------------------------- > > > > You can respond by visiting: > > > http://wald.intevation.org/tracker/?func=detail&atid=205&aid=281&group_id=21 > > > > > > __________________________________________ > 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 Feb 11 21:11:06 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sun Feb 11 21:11:16 2007 Subject: [GRASS-dev] Profiler updates Message-ID: Maris, I committed your patch to profile.tcl with a few modifications. The window placement is a nice improvement. There was already an error trap for profiles with a 0 length, so I deleted your 2nd trap for this condition. I also moved the trap for elevation range = 0 up a bit to immediately after the spot where the procedure for generating elevation range is called. I thought of another potential problem but haven?t found a way to trap it. If you send r.profile any coordinates that extend beyond the current region, it will crash and crash the entire GUI?in spite of the fact that the call to r.profile is trapped with a catch statement. The profiler generates correct coordinates for any place on the display, regardless of whether it extends beyond the region boundaries or not. However, r.profile apparently chokes on coordinates outside the region. I?m not sure if this can really be called a bug in r.profile, but it should probably fail more gracefully. 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/20070211/657afcff/attachment.html From paul-grass at stjohnspoint.co.uk Sun Feb 11 22:02:52 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Sun Feb 11 22:02:57 2007 Subject: [GRASS-dev] [grass-code patches][280] Fix Help button in gis.m raster/vector display conf locks up gis.m In-Reply-To: <20070210172122.DD35C1801DAA@pyrosoma.intevation.org> References: <20070210172122.DD35C1801DAA@pyrosoma.intevation.org> Message-ID: Hello Maris On Sat, 10 Feb 2007 grass-codepatches@wald.intevation.org wrote: > Initial Comment: > In GRASS 6.2.1 if You press "Help" to get help about raster/vector displaying, it will run g.manual and lock up gis.m till You close browser (konqueror). Not good. > In GRASS 6.3.cvs if You do same, gis.m will remain locked also after closing help browser (konqueror). Only way out after pressing help is to use xkill. Really bad. > > This patch changes all "run g.manual foo" in gis.m to "spawn g.manual foo". It works now for me with CVS head (10.02.2007.) and Konqueror. I can open help and continue to use gis.m in same time. If looks OK, somebody commit it, please. IMHO this is a feature of g.manual, rather than a bug in the GUI. If you run g.manual from the command-line you get the same situation - the command prompt is unusable until the browser is closed again. This has annoyed me many times but I never did anything about it as I considered it a feature rather than a bug---if you run g.manual -m (for man page rather than HTML output) the terminal window is used for reading the help pages so it would be impossible to use it anyway. An historical feature IMHO, but I agree also that it would be desirable to change it. I think though rather than patching the GUI, a better solution (which will also benefit command-line users) would be to change g.manual so it spawns the help browser and then exits, rather than waiting for the user to close the browser before exiting as at present. Also (for Maciek) comments: 1. The e-mails (like this one I'm replying to) coming from the request tracker have very long lines in them. Very hard to read in some e-mail clients. Is it possible for the lines to be automatically broken if the user entering the bug doesn't put line breaks in? 2. Is it possible for the e-mails to have grass-dev@grass.itc.it in the To field rather than noreply@wald.intevation.org? What is that for? When I select Reply-to-all it would be easier if the dev list was included in the recipients and I didn't have to edit the Cc field manually. Paul From hamish_nospam at yahoo.com Mon Feb 12 00:08:38 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Feb 12 00:08:45 2007 Subject: [GRASS-dev] d.text vs d.text.freetype vs d.text.new In-Reply-To: <17870.29715.29314.131138@cerise.gclements.plus.com> References: <20070210222558.GA6790@bartok.itc.it> <17870.29715.29314.131138@cerise.gclements.plus.com> Message-ID: <20070212120838.6b789f76.hamish_nospam@yahoo.com> Markus wrote: > > while starting to write up the changes in GRASS 6.3 for > > an upcoming 6.3.0 release, I found that we have > > d.text > > d.text.freetype > > d.text.new > > > > What is the state of d.text.new? Glynn wrote: > AFAICT, it's essentially a superset of the other two. > > Although it lacks the charset=, path= and -c switches from > d.text.freetype, that functionality is available through other means > (-c is implied if text= isn't used, the encoding and path can be set > in the freetypecap file or via d.font[.freetype]). WRT publishing the name, note that d.text.new must be a temporary name, and it only exists in the development version (the name will become an anachronism at some point in the future). We need to figure out what to do with it, currently IIUC it is mainly there to help with changing fonts in the GUI-- My guess is that the new WxPython GUI will place text directly on the canvas and not rely on a d.* module at all. So the question is, what is the future of the d.text.* modules as they will exist to support the command line xmon version of GRASS? And in the short term, what to rename d.text.new, or will it replace d.text? Hamish From michael.barton at asu.edu Mon Feb 12 00:21:58 2007 From: michael.barton at asu.edu (Michael Barton) Date: Mon Feb 12 00:22:06 2007 Subject: [GRASS-dev] Re: Fix for gis.m profile dialog division by zero In-Reply-To: <2b3d8c1c0702111030q59a8e536nf84e4e1f73fcfc42@mail.gmail.com> Message-ID: OK. If it's for foolproofing, then the error trap is perfect. I just wanted to make sure that there was no new systematic problem with elevation ranges on a valid map to profile. Michael On 2/11/07 11:30 AM, "Maris Nartiss" wrote: > Hi Michael, > > it will divide by zero on any non-normal map - think of binary map (1,null). > It has no sense for such maps to create profiles, but it does not mean > that gis.m should fail if user is dumb. It's one of my thisweekends > efforts to make gis.m foolproof. :) > > Maris. > > 2007/2/11, Michael Barton : >> Maris, >> >> Do you know what is making this divide by 0 and under what circumstances >> (e.g., range of elevation values on map, location/projection >> characteristics)? On my system, with a build of 2 days ago, the profiling >> works fine with the "normal" map of the Spearfish 30m DEM. >> >> This happened a couple times before when the GRASS module used for >> calculating the total elevation range was giving incorrect information in >> certain circumstances and when there were changes in the function of >> g.region flags. It was an example of the cascade of effects that can happen >> if a module function is changed in seemingly minor ways. >> >> The error trapping is a good idea in any case. But I want to make sure we >> also understand the cause rather than just treat the symptoms. >> >> Michael >> >> >> On 2/10/07 12:30 PM, "grass-codepatches@wald.intevation.org" >> wrote: >> >>> code patches item #281, was opened at 2007-02-10 21:30 >>> Status: Open >>> Priority: 3 >>> Submitted By: M?ris Narti?s (marisn) >>> Assigned to: Nobody (None) >>> Summary: Fix for gis.m profile dialog division by zero >>> Patch status: None >>> Patch type: fix >>> GRASS component: gis.m >>> GRASS version: CVS HEAD >>> GRASS CVS checkout date, if applies (YYMMDD): 070210 >>> >>> >>> Initial Comment: >>> This patch prevents gis.m profile tool from dividing by zero and makes >> popup >>> windows to appear on top of profile window and not gis.m main window. >>> >>> ---------------------------------------------------------------------- >>> >>> You can respond by visiting: >>> >> http://wald.intevation.org/tracker/?func=detail&atid=205&aid=281&group_id=21 >>> >>> >> >> __________________________________________ >> 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 glynn at gclements.plus.com Mon Feb 12 00:27:04 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Feb 12 00:27:07 2007 Subject: [GRASS-dev] d.text vs d.text.freetype vs d.text.new In-Reply-To: <20070212120838.6b789f76.hamish_nospam@yahoo.com> References: <20070210222558.GA6790@bartok.itc.it> <17870.29715.29314.131138@cerise.gclements.plus.com> <20070212120838.6b789f76.hamish_nospam@yahoo.com> Message-ID: <17871.42568.848623.288714@cerise.gclements.plus.com> Hamish wrote: > > > while starting to write up the changes in GRASS 6.3 for > > > an upcoming 6.3.0 release, I found that we have > > > d.text > > > d.text.freetype > > > d.text.new > > > > > > What is the state of d.text.new? > > Glynn wrote: > > AFAICT, it's essentially a superset of the other two. > > > > Although it lacks the charset=, path= and -c switches from > > d.text.freetype, that functionality is available through other means > > (-c is implied if text= isn't used, the encoding and path can be set > > in the freetypecap file or via d.font[.freetype]). > > > WRT publishing the name, note that d.text.new must be a temporary name, > and it only exists in the development version (the name will become an > anachronism at some point in the future). > > We need to figure out what to do with it, currently IIUC it is mainly > there to help with changing fonts in the GUI-- My guess is that the new > WxPython GUI will place text directly on the canvas and not rely on a > d.* module at all. > > So the question is, what is the future of the d.text.* modules as they > will exist to support the command line xmon version of GRASS? And in the > short term, what to rename d.text.new, or will it replace d.text? It should replace d.text. Also, d.text.freetype and d.font.freetype are now essentially redundant, as d.text.new and d.font can use FreeType fonts. They may as well be retained in the short term; the existing d.text should probably be kept as e.g. d.text.old for a transitional period. -- Glynn Clements From michael.barton at asu.edu Mon Feb 12 00:27:20 2007 From: michael.barton at asu.edu (Michael Barton) Date: Mon Feb 12 00:27:28 2007 Subject: [GRASS-dev] [grass-code patches][283] Fix gis.m canvas division by zero on zoom-in and other enhancements In-Reply-To: <20070211131820.87CB71801A19@pyrosoma.intevation.org> Message-ID: These sound like very nice enhancements, especially trapping various potential user errors. Thanks for all the work you're doing on this. I'll try them out and commit if they work fine on my alternate platform. Michael On 2/11/07 6:18 AM, "grass-codepatches@wald.intevation.org" wrote: > code patches item #283, was opened at 2007-02-11 15:18 > Status: Open > Priority: 3 > Submitted By: M?ris Narti?s (marisn) > Assigned to: Nobody (None) > Summary: Fix gis.m canvas division by zero on zoom-in and other enhancements > Patch status: None > Patch type: fix > GRASS component: gis.m > GRASS version: CVS HEAD > GRASS CVS checkout date, if applies (YYMMDD): 070211 > > > Initial Comment: > This patch fixes following bugs and usability problems: > * If user zooms too far in, it gets prompt about it and not about division by > zero (this should be enhanced more to promt to user sooner than map width > exceeds resolution); > * Warning if user querys map but has no layer selected; > * Zoom in/out by rectangle now draws black/yellow dashed rectangle as pure > yellow was not visible on yellow maps; > * If user zooms in/out by rectangle and has moved mouse for less than 15 > pixels, it is asumed to be a click. Prevents users from zooming in/out too > much by accident; > * Measure tool now works also by single cilck like in other GIS apps (QGIS, > ArcView etc.). Old style (by draging) also works; > * Warning if user zooms to map but has no map selected. > > ---------------------------------------------------------------------- > > You can respond by visiting: > http://wald.intevation.org/tracker/?func=detail&atid=205&aid=283&group_id=21 > > __________________________________________ 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 Feb 12 00:59:53 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Feb 12 01:01:00 2007 Subject: [GRASS-dev] Display system updates Message-ID: <17871.44537.496100.306445@cerise.gclements.plus.com> I've committed a significant clean-up to the display architecture (libraries and drivers). The main change is that the drivers no longer maintain a palette; all colours are specified directly as R/G/B values. The following application-level functions have been removed: R_Color R_Raster R_Raster_char R_Raster_int R_Reset_color R_Reset_colors Any code which used them has been re-written to use alternatives, essentially: old new R_Color R_RGB_color R_Raster R_RGB_raster R_Raster_char R_RGB_raster R_Raster_int R_RGB_raster R_Reset_color n/a R_Reset_colors n/a Apart from removing a significant amount of (essentially unnecessary) code, it simplifies the programming interface. Rather than having to allocate palette entries, store the R/G/B values in the palette, then specify colours as palette indices, the R/G/B values are specified directly. An added bonus is that any rasters drawn using the display library (D_draw_cell, D_draw_raster etc) will use the display's full colour depth (previously, they were truncated to 15 bpp / 32768 colours to limit the amount of palette data which was uploaded). The only "loss" is that there's no chance of R_color_table_float() or d.colormode being resurrected. Given that 6.x has never included d.colormode, and nobody seemed to notice, it seems safe to assume that the days of 256-colour displays are essentially over (I haven't run a 256-colour desktop since I upgraded my 386 to a 486 sometime around 1995). 256-colour displays still work, you're just limited to the default 6x6x6 colour-cube palette, rather than being able to choose a custom palette. The complete list of modules which required changes is: display/d.extract display/d.mapgraph display/d.path display/d.text.freetype display/d.text.new display/d.text display/d.vect display/d.what.vect imagery/i.vpoints vector/v.digit It's probably worth giving these a brief check to ensure that colours are still handled correctly (e.g. color=0:100:0 should give dark green, etc). A (marginally) related change is that the standard_colors_rgb and standard_color_names arrays are no longer exported (there was a problem with using array variables exported from shared libraries on some platforms), and the MAX_COLOR_NUM and MAXCOLOR macros no longer exist. Instead, the following functions are provided by libgis (declared in ): extern int G_num_standard_colors(void); extern struct color_rgb G_standard_color_rgb(int n); extern int G_num_standard_color_names(void); extern const struct color_name *G_standard_color_name(int n); R_standard_color() remains, as do D_parse_color() and D_raster_use_color(), although the last two now use an internal palette (they can't use the driver's palette, as it doesn't have one). -- Glynn Clements From hamish_nospam at yahoo.com Mon Feb 12 01:36:39 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Feb 12 01:36:51 2007 Subject: [GRASS-dev] Re: [GRASS-user] problems using r.proj with large data set In-Reply-To: <17868.16797.736678.350911@cerise.gclements.plus.com> References: <009801c71a20$2e223d60$3e40ae80@ace.uiuc.edu> <7746318.post@talk.nabble.com> <457882F8.2020001@o2.pl> <17784.51544.421727.643216@cerise.gclements.plus.com> <17797.60295.671067.744836@cerise.gclements.plus.com> <9E06EBB8-9577-4146-AA53-0FC27855EC6F@kyngchaos.com> <17867.1426.935411.652226@cerise.gclements.plus.com> <8D78CDF6-FD1C-47FC-AAA7-F34C815DB6A9@kyngchaos.com> <20070209130932.4f1f5cb7.hamish_nospam@yahoo.com> <17868.16797.736678.350911@cerise.gclements.plus.com> Message-ID: <20070212133639.02a45a62.hamish_nospam@yahoo.com> Glynn Clements wrote: > > so will this fix the imediate problem? G__tempfile() > > > > do > > { > > sprintf (name, "%d.%d", pid, uniq++) ; > > - G__file_name (path, element, name, G_mapset()) ; > > + G__file_name (path, element, name, G__mapset()) ; > > } > > That will fix the general G__tempfile() issue. > > My previous fix should suffice for r.proj.seg. By switching back to > the original environment before calling G_tempfile(), G_mapset() and > G__mapset() should produce the same results. > > Actually, G__tempfile() probably shouldn't be called while the > alternate environment is active, as it will create the temporary file > in the location from the alternate environment (i.e. the source > location), when you probably want it to be in the current location > (according to $GISRC). So $ETC/clean_temp won't be run and we need to be extra sure that the tempfile is removed when the program exits, either successfully or unsuccessfully. > There's still the general issue that any other functions which use > G_mapset() may not behave as expected while an alternate environment > is active. At least we are now aware of the problem, and as well we already know well which cases invoke an alternate environment. And hopefully we can move away from that sort of trick with time (ala Michael's georectifier). Hamish From hamish_nospam at yahoo.com Mon Feb 12 01:41:12 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Feb 12 01:41:44 2007 Subject: [GRASS-dev] WxPython front-end to ps.map In-Reply-To: <17868.15569.809267.225649@cerise.gclements.plus.com> References: <20070207203925.649c2def.hamish_nospam@yahoo.com> <45CAECAD.7020505@club.worldonline.be> <17867.3613.858298.118086@cerise.gclements.plus.com> <200702081144.34725.dylan.beaudette@gmail.com> <17868.15569.809267.225649@cerise.gclements.plus.com> Message-ID: <20070212134112.086eda54.hamish_nospam@yahoo.com> Glynn Clements wrote: > My original preference for a new graphics API was to have d.* commands > simply generate PostScript conforming to certain conventions. The > resulting PostScript could then be drawn on screen (x11 driver), > rendered to an image (PNG/PPM/BMP/etc drivers) or sent to a printer > (either a native PostScript printer or via the ljet/PCL/etc drivers). > > Unfortunately, rendering vector maps using PostScript is between 1 and > 2 orders of magnitude slower than using XDrawLine(), which is bad for > interactive use. So we still need some kind of intermediate layer > which provides a speed-before-quality option for drawing lines. What about adding a [E]PostScript display driver? Akin to the PNG driver, vs. the x11 driver. It would primarily be intended for hardcopy output, but could potentially be used for (slow) GUI protoypes. Hamish From hamish_nospam at yahoo.com Mon Feb 12 01:46:38 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Feb 12 01:46:59 2007 Subject: [GRASS-dev] [bug #5489] (grass) d.font error in GRASS6.2/6.3 In-Reply-To: <17868.46453.143635.880150@cerise.gclements.plus.com> References: <20070209094046.8B1711006CB@lists.intevation.de> <17868.46453.143635.880150@cerise.gclements.plus.com> Message-ID: <20070212134638.3a144f56.hamish_nospam@yahoo.com> Glynn Clements wrote: > > This is why direct rendering has GRASS_FONT, GRASS_FT_FONT and > GRASS_FT_ENCODING; there isn't any other way to set this state. Could you document these 3 in lib/init/variables.html ? thanks, Hamish From hamish_nospam at yahoo.com Mon Feb 12 04:34:04 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Feb 12 04:36:29 2007 Subject: [GRASS-dev] [grass-code patches][280] Fix Help button in gis.m raster/vector display conf locks up gis.m In-Reply-To: References: <20070210172122.DD35C1801DAA@pyrosoma.intevation.org> Message-ID: <20070212163404.33ff26fd.hamish_nospam@yahoo.com> Paul Kelly wrote: > > IMHO this is a feature of g.manual, rather than a bug in the GUI. If > you run g.manual from the command-line you get the same situation - > the command prompt is unusable until the browser is closed again. > This has annoyed me many times but I never did anything about it as I > considered it a feature rather than a bug---if you run g.manual -m > (for man page rather than HTML output) the terminal window is used > for reading the help pages so it would be impossible to use it > anyway. An historical feature IMHO, but I agree also that it would be > desirable to change it. > > I think though rather than patching the GUI, a better solution (which > will also benefit command-line users) would be to change g.manual so > it spawns the help browser and then exits, rather than waiting for > the user to close the browser before exiting as at present. I had applied such a g.manual& patch in the past, but it was reverted after we discovered that some people were using text based browsers (lynx, links) to view the help pages, and this caused problems for them. that discussion: http://thread.gmane.org/gmane.comp.gis.grass.devel/6702 FWIW, In my ~/.grass.bashrc I export GRASS_HTML_BROWSER=dillo, which is Very Fast (and flags html bugs) but noisy to stderr. I guess folks using a text based web browser for the help pages could use man instead of lynx. Also, I never managed to get the command line options right so firefox would open a new window in the current workspace; if used for GRASS help it opens the page in the current tab a an existing firefox in another workspace. I've the same problem with Googlizer. mozilla -remote "openurl(http://www.mozilla.org)" http://www.linux.org.uk/~telsa/BitsAndPieces/googlizer.html (nice little tool- highlight a word and click on the "G" icon on the taskbar to do a search for that word. useless triva: the author is Alan Cox's SO) Also, for me, "man $module" works the same as "g.manual -m $module" but with less keystrokes. Hamish From hamish_nospam at yahoo.com Mon Feb 12 05:20:04 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Feb 12 05:21:08 2007 Subject: [GRASS-dev] Profiler updates In-Reply-To: References: Message-ID: <20070212172004.7f6a1f8e.hamish_nospam@yahoo.com> Michael Barton wrote: > > I committed your patch to profile.tcl with a few modifications. The > window placement is a nice improvement. There was already an error > trap for profiles with a 0 length, so I deleted your 2nd trap for this > condition. I also moved the trap for elevation range = 0 up a bit to > immediately after the spot where the procedure for generating > elevation range is called. > > I thought of another potential problem but haven?t found a way to trap > it. If you send r.profile any coordinates that extend beyond the > current region, it will crash and crash the entire GUI?in spite of the > fact that the call to r.profile is trapped with a catch statement. The > profiler generates correct coordinates for any place on the display, > regardless of whether it extends beyond the region boundaries or not. > However, r.profile apparently chokes on coordinates outside the > region. > > I?m not sure if this can really be called a bug in r.profile, but it > should probably fail more gracefully. This is a bug in r.profile. Out of region values are not correct. spearfish example: d.mon x0 # stretch the window so it is twice as wide as it is tall g.region rast=elevation.dem d.erase color=grey d.rast elevation.dem r.profile -i in=elevation.dem res=300 If you go off the left edge of the region, the answers are wrong. If you go off the right edge, the answers are very wrong, then 0. # next re-strech the window so it is taller that wide. If you go off the bottom: WARNING: [elevation.dem in PERMANENT] - read request for row 471 is outside region and a the program exits. If you go off the top: ERROR: Coordinate request outsite current region settings and a the program exits. d.what.rast gives a "You are clicking outside the map" warning. r.what gives a warning before reporting a NULL ("*"): G63> r.what in=elevation.dem east_north=602283,4913294 ** note ** 602283 4913294 is outside your current window 602283|4913294||* So it would seem appropriate that r.profile out-of-region should report a "NULL" result (to stdout) and warning that the endpoint is out of region (G_warning() to stderr). Hamish From michael.barton at asu.edu Mon Feb 12 05:25:44 2007 From: michael.barton at asu.edu (Michael Barton) Date: Mon Feb 12 05:25:53 2007 Subject: [GRASS-dev] Profiler updates In-Reply-To: <20070212172004.7f6a1f8e.hamish_nospam@yahoo.com> Message-ID: This sounds like a good assessment and suggestion. Michael On 2/11/07 9:20 PM, "Hamish" wrote: > Michael Barton wrote: >> >> I committed your patch to profile.tcl with a few modifications. The >> window placement is a nice improvement. There was already an error >> trap for profiles with a 0 length, so I deleted your 2nd trap for this >> condition. I also moved the trap for elevation range = 0 up a bit to >> immediately after the spot where the procedure for generating >> elevation range is called. >> >> I thought of another potential problem but haven?t found a way to trap >> it. If you send r.profile any coordinates that extend beyond the >> current region, it will crash and crash the entire GUI?in spite of the >> fact that the call to r.profile is trapped with a catch statement. The >> profiler generates correct coordinates for any place on the display, >> regardless of whether it extends beyond the region boundaries or not. >> However, r.profile apparently chokes on coordinates outside the >> region. >> >> I?m not sure if this can really be called a bug in r.profile, but it >> should probably fail more gracefully. > > > This is a bug in r.profile. Out of region values are not correct. > > spearfish example: > > d.mon x0 > # stretch the window so it is twice as wide as it is tall > g.region rast=elevation.dem > d.erase color=grey > d.rast elevation.dem > r.profile -i in=elevation.dem res=300 > > If you go off the left edge of the region, the answers are wrong. > If you go off the right edge, the answers are very wrong, then 0. > > # next re-strech the window so it is taller that wide. > > If you go off the bottom: > WARNING: [elevation.dem in PERMANENT] - read request for row 471 is > outside region > and a the program exits. > > If you go off the top: > ERROR: Coordinate request outsite current region settings > and a the program exits. > > > d.what.rast gives a "You are clicking outside the map" warning. > > r.what gives a warning before reporting a NULL ("*"): > > G63> r.what in=elevation.dem east_north=602283,4913294 > ** note ** 602283 4913294 is outside your current window > 602283|4913294||* > > > So it would seem appropriate that r.profile out-of-region should report > a "NULL" result (to stdout) and warning that the endpoint is out of > region (G_warning() to stderr). > > > > Hamish __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From hamish_nospam at yahoo.com Mon Feb 12 05:32:53 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Feb 12 05:34:55 2007 Subject: [GRASS-dev] [grass-code patches][280] Fix Help button in gis.m raster/vector display conf locks up gis.m In-Reply-To: References: <20070210172122.DD35C1801DAA@pyrosoma.intevation.org> Message-ID: <20070212173253.6fb6e283.hamish_nospam@yahoo.com> Michael Barton wrote: > > Starting browser for module d.rast... lib/init/init.sh sets this: elif [ "$HOSTTYPE" = "macintosh" -o "$HOSTTYPE" = "powermac" -o "$HOSTTYPE" = "powerpc" ] ; then GRASS_HTML_BROWSER=open As for MacOSX you can do "open URL" from the command line to launch safari. Apparently that forks itself into a background process, but that behavior is specific to OSX's "open" command. If GRASS_HTML_BROWSER is set to a regular program name, it probably won't background itself. Hamish From c.michael.barton at gmail.com Mon Feb 12 05:41:46 2007 From: c.michael.barton at gmail.com (Michael Barton) Date: Mon Feb 12 05:42:09 2007 Subject: [GRASS-dev] [grass-code patches][280] Fix Help button in gis.m raster/vector display conf locks up gis.m In-Reply-To: <20070212173253.6fb6e283.hamish_nospam@yahoo.com> References: <20070210172122.DD35C1801DAA@pyrosoma.intevation.org> <20070212173253.6fb6e283.hamish_nospam@yahoo.com> Message-ID: <8AA4B153-E4E9-416E-9425-2E69F27CEE98@asu.edu> Right. But why is a message generated to tell me that I am starting a browser for module d.rast... This is what I intended to do, and a message to this effect sent to stderr seems redundant. I can see getting a message "Unable to open browser for module d.rast...", but I don't see why one is necessary to tell the user that the program is indeed doing what it is supposed to do. (grumble grumble grumble). This is a message that I don't remember seeing before. Michael On Feb 11, 2007, at 9:32 PM, Hamish wrote: > Michael Barton wrote: >> >> Starting browser for module d.rast... > > lib/init/init.sh sets this: > > elif [ "$HOSTTYPE" = "macintosh" -o "$HOSTTYPE" = "powermac" -o > "$HOSTTYPE" = "powerpc" ] ; then > GRASS_HTML_BROWSER=open > > > As for MacOSX you can do "open URL" from the command line to launch > safari. > > Apparently that forks itself into a background process, but that > behavior > is specific to OSX's "open" command. If GRASS_HTML_BROWSER is set to a > regular program name, it probably won't background itself. > > > Hamish ____________________ C. Michael Barton, Professor of Anthropology School of Human Evolution and Social Change PO Box 872402 Arizona State University Tempe, AZ 85287-2402 USA Phone: 480-965-6262 Fax: 480-965-7671 www: From hamish_nospam at yahoo.com Mon Feb 12 06:17:30 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Feb 12 06:17:34 2007 Subject: [GRASS-dev] g.proj to create a new location In-Reply-To: References: <20070205200634.7217027e.hamish_nospam@yahoo.com> <20070206200326.78e44b29.hamish_nospam@yahoo.com> <20070207150258.3c310a09.hamish_nospam@yahoo.com> <20070208234313.6073c8d4.hamish_nospam@yahoo.com> Message-ID: <20070212181730.4e58fc20.hamish_nospam@yahoo.com> > Hamish wrote: > > I have now added new epsg= and datumtrans= options to g.proj in CVS. .. > > If it needs more info WRT datum transform options, it currently goes > > interactive as the datumtrans= option to list or select datum > > transform parms is not yet functional. Paul, can you try and connect > > this to get_datum_transform_by_name() and GPJ_ask_datum_params(), or > > wherever the number needs to get to? Mucho gracias. Paul wrote: > I have this working now in my local copy, Great. > but just realised a slight flaw with it. Because we are assuming a > default of datumtrans=1, there is no way to assume if the user > specifically asked for the 1st set of datum transformation parameters, > or they are just using the default. Up to now, if the user didn't > specifically specify datum transformation parameters, they were not > written into the PROJ_INFO, only the datum name. ok, so how about: datumtrans=-1 # write the list (including a "none" option) and exit datumtrans=0 # no datum specified datumtrans=1 # default datumtrans=2,.. # add'l options datumtrans=1 remains the default, but if multiple options exist, load the picker. Or do we always want to open the picker to allow ="none", even when there is only one option? So after it gets a EPSG code it creates a new loc'n in two passes. The first time it runs with datumtrans=-1 to get the list, and the second it runs with the user specified answer. If the only option is "none" (eg epsg already specifies +towgs84=, as with NZTM <2193>) it skips the second pass (GUI picker) and directly creates the loc'n. > When necessary then (e.g. using one of the re-projection modules), the > current default parameters for that datum would be read from the > datum.table file and used. So if the default changed (e.g. we > discovered it was wrong and updated it) the user wouldn't need to edit > their location to take advantage of the update. But if the parameters > are written into the PROJ_INFO, then whatever default was in force at > the time becomes set in stone. That makes sense. the above datumtrans="none" suggestion would keep that the same. > I'm not sure what to do about this, whether it's nothing to worry > about or not. Worrying is good, as downstream effects of this decision will directly affect the data. (eg WKT .prj export imported into something else) > Also, I was wondering what format would be appropriate for the > GUI-parsable list of datum transformation parameters. In the copy I > have I'm just printing to stdout the list that you got by typing list > at the old interactive prompt. Are there any existing examples of > something similar I wonder. The GUI needs to be able to transform it into a radio button list somehow. I guess it could just search for the existing "^---$" text to separate entries and re-use the existing formatting of the individual entries. Also it would be nice if it could pre-select the default option when the GUI picker is opened. If it must be broken up into fields, "|" doesn't appear in the epsg file, lib/gis/datum.table, nor lib/gis/datumtransform.table so could be used as a field separator. It would be nice for the list to be human- readable if called from the command line. Or is the current output structured enough to rely on '^---$' and '\n' for that? Will the default always be what's in "datum.table"? ie the default is always the 3-term +towgs84=dx,dy,dz parms? outstanding issue: allow these datumtrans= word aliases? list => -1 none => 0 default => 1 # bonus: three_term => a seven_term => b Hamish From hamish_nospam at yahoo.com Mon Feb 12 07:03:26 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Feb 12 07:03:34 2007 Subject: [GRASS-dev] [grass-code patches][280] Fix Help button in gis.m raster/vector display conf locks up gis.m In-Reply-To: <8AA4B153-E4E9-416E-9425-2E69F27CEE98@asu.edu> References: <20070210172122.DD35C1801DAA@pyrosoma.intevation.org> <20070212173253.6fb6e283.hamish_nospam@yahoo.com> <8AA4B153-E4E9-416E-9425-2E69F27CEE98@asu.edu> Message-ID: <20070212190326.21e6fc11.hamish_nospam@yahoo.com> H: > >> Starting browser for module d.rast... > > > > lib/init/init.sh sets this: > > > > elif [ "$HOSTTYPE" = "macintosh" -o "$HOSTTYPE" = "powermac" -o > > "$HOSTTYPE" = "powerpc" ] ; then > > GRASS_HTML_BROWSER=open > > > > > > As for MacOSX you can do "open URL" from the command line to launch > > safari. > > > > Apparently that forks itself into a background process, but that > > behavior is specific to OSX's "open" command. If GRASS_HTML_BROWSER > > is set to a regular program name, it probably won't background > > itself. sorry, the above is wrong. There is an override in scripts/g.manual: #hack for MacOSX: if [ "$HOSTTYPE" = "macintosh" ] ; then BROWSERNAME="default Macintosh web browser" Michael Barton wrote: > Right. But why is a message generated to tell me that I am starting a > browser for module d.rast... This is what I intended to do, and a > message to this effect sent to stderr seems redundant. I can see > getting a message "Unable to open browser for module > d.rast...", but I don't see why one is necessary to tell the user > that the program is indeed doing what it is supposed to do. (grumble > grumble grumble). This is a message that I don't remember seeing > before. That message has been there since the first version. I guess it is like websites opening a new browser window instead of exiting the current page when you click on an external link (!@$@#%&*). Some sort of "not my fault if this doesn't work" absolving legaleese I guess. Also the new brower may take several seconds to load and the user may become impatient and open it twice, esp. if it returns to the prompt. options: 1) send the message to stderr with `echo "" 1>&2`, where all good shell script status messages should go. 2) "g.manual --quiet" makes it go away 2) restrict it to when "g.manual --verbose" is called 3) remove it (problem if GRASS_HTML_BROWSER is bad?) 4) do nothing #1 and #2 are now done in 6.3-CVS. Hamish From hamish_nospam at yahoo.com Mon Feb 12 07:42:28 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Feb 12 07:42:33 2007 Subject: [GRASS-dev] Re: [GRASS-user] new bug tracking for GRASS In-Reply-To: <45CCBEAB.5020602@o2.pl> References: <45CCBEAB.5020602@o2.pl> Message-ID: <20070212194228.105028da.hamish_nospam@yahoo.com> In the bug tracker view, can the default "Assignee:" field be set to "Any" instead of "Unassigned"? ie currently you only see new bugs, not all open bugs unless you submit a new custom query. someone browsing for a bug won't know that it is missing from the list as it has already been taken by <>. ? thanks, Hamish From c.michael.barton at gmail.com Mon Feb 12 08:17:35 2007 From: c.michael.barton at gmail.com (Michael Barton) Date: Mon Feb 12 08:17:45 2007 Subject: [GRASS-dev] [grass-code patches][280] Fix Help button in gis.m raster/vector display conf locks up gis.m In-Reply-To: <20070212190326.21e6fc11.hamish_nospam@yahoo.com> References: <20070210172122.DD35C1801DAA@pyrosoma.intevation.org> <20070212173253.6fb6e283.hamish_nospam@yahoo.com> <8AA4B153-E4E9-416E-9425-2E69F27CEE98@asu.edu> <20070212190326.21e6fc11.hamish_nospam@yahoo.com> Message-ID: <13DD9A18-F690-47DB-B2FF-DB8B9510300D@asu.edu> g.manual --quiet is a good solution. Thanks. Michael On Feb 11, 2007, at 11:03 PM, Hamish wrote: > H: >>>> Starting browser for module d.rast... >>> >>> lib/init/init.sh sets this: >>> >>> elif [ "$HOSTTYPE" = "macintosh" -o "$HOSTTYPE" = "powermac" -o >>> "$HOSTTYPE" = "powerpc" ] ; then >>> GRASS_HTML_BROWSER=open >>> >>> >>> As for MacOSX you can do "open URL" from the command line to launch >>> safari. >>> >>> Apparently that forks itself into a background process, but that >>> behavior is specific to OSX's "open" command. If GRASS_HTML_BROWSER >>> is set to a regular program name, it probably won't background >>> itself. > > > sorry, the above is wrong. There is an override in scripts/g.manual: > > #hack for MacOSX: > if [ "$HOSTTYPE" = "macintosh" ] ; then > BROWSERNAME="default Macintosh web browser" > > Michael Barton wrote: >> Right. But why is a message generated to tell me that I am starting a >> browser for module d.rast... This is what I intended to do, and a >> message to this effect sent to stderr seems redundant. I can see >> getting a message "Unable to open browser for module >> d.rast...", but I don't see why one is necessary to tell the user >> that the program is indeed doing what it is supposed to do. (grumble >> grumble grumble). This is a message that I don't remember seeing >> before. > > That message has been there since the first version. I guess it is > like > websites opening a new browser window instead of exiting the current > page when you click on an external link (!@$@#%&*). Some sort of "not > my fault if this doesn't work" absolving legaleese I guess. Also the > new brower may take several seconds to load and the user may become > impatient and open it twice, esp. if it returns to the prompt. > > options: > 1) send the message to stderr with `echo "" 1>&2`, where all good > shell script status messages should go. > 2) "g.manual --quiet" makes it go away > 2) restrict it to when "g.manual --verbose" is called > 3) remove it (problem if GRASS_HTML_BROWSER is bad?) > 4) do nothing > > #1 and #2 are now done in 6.3-CVS. > > > Hamish ____________________ C. Michael Barton, Professor of Anthropology School of Human Evolution and Social Change PO Box 872402 Arizona State University Tempe, AZ 85287-2402 USA Phone: 480-965-6262 Fax: 480-965-7671 www: From hamish_nospam at yahoo.com Mon Feb 12 08:36:33 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Feb 12 08:36:37 2007 Subject: [GRASS-dev] GUI startup doesn't source ~/.grass.bashrc In-Reply-To: <8AA4B153-E4E9-416E-9425-2E69F27CEE98@asu.edu> References: <20070210172122.DD35C1801DAA@pyrosoma.intevation.org> <20070212173253.6fb6e283.hamish_nospam@yahoo.com> <8AA4B153-E4E9-416E-9425-2E69F27CEE98@asu.edu> Message-ID: <20070212203633.60d18326.hamish_nospam@yahoo.com> Another issue.. gis.m loaded from init.sh ignores ~/.grass.bashrc. e.g. my ~/.grass.bashrc has: export GRASS_HTML_BROWSER=dillo If I start GRASS in -gui mode the [Help] button from the gis.m menus ignores my $GRASS_HTML_BROWSER setting and uses Mozilla. If I start gis.m from an already running GRASS prompt, [Help] loads dillo. Should: - the terminal session somehow start gis.m instead of init.sh - gis.m "source" .grass.bashrc (& co.) if it exists - in init.sh move source .grass.bashrc (& co.) before the gui startup - or we drop .rc support for GUI GRASS :-( Polluting ~/.bashrc with a lot of GRASS stuff is a pain. Another example: in .grass.bashrc I renice GRASS to a low priority (+15) so during long processing jobs I can work on other things without much slowdown. Hamish From radim.blazek at gmail.com Mon Feb 12 09:03:28 2007 From: radim.blazek at gmail.com (Radim Blazek) Date: Mon Feb 12 09:03:31 2007 Subject: [GRASS-dev] new bug tracking for GRASS In-Reply-To: <45CCBEAB.5020602@o2.pl> References: <45CCBEAB.5020602@o2.pl> Message-ID: <340505ef0702120003n135d2257nd074f109c8617573@mail.gmail.com> Somehow I was automaticaly (?) subscribed to the system so that I am now recieving mails from grass-codepatches@wald.intevation.org. How can I unsubscribe from the system, I don't know even my login, I tried various. Thanks Radim On 2/9/07, Maciej Sieczka wrote: > Hi, > > I'm pleased to officialy announce the new GRASS tracking system powered > by GForge ready to use. > > GForge is a feature-rich system for collaborating on a software project > http://gforge.org/. > > Thanks to Intevation GmbH http://www.intevation.de/index.en.html, who > invited us to use their GForge setup at http://wald.intevation.org/, > there are 9 trackers for GRASS now [1]: > > - 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' trackers are for user submitted patches, if the user doesn't > have CVS write access but wants to share his fix/improvement. They will > also be used for patches which shouldn't go into CVS for a reason, but > we want to keep the track of them for later. > > When an issue is 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. as time allows. > > When a patch is submitted, and nobody steps up to take care of it, > there are first-contacts also, who will do a similar job here: > > Jachym Chepicky - code patches. > Scott Mitchell - website patches. > Martin Landa - doc patches. > > I will try to help if I can, too. Thanks Guys! > > Trackers are available for public view, but in order to be able to post > (including creating a new report) and use all the features of the > trackers, you need to setup an account at GForge first [2] and join the > GRASS project at GForge [3]. > > All trackers' new submissions will be automatically forwarded to the > GRASS development mailing list [4]. All followup traffic will be stored > in the tracker and forwarded only to parties discussing the ticket. > However, any project member can "monitor" a ticket, or a whole tracker, > in order to receive all the related traffic (see GForge manual [6]). > > GForge provides many functionalities. Currently we are going to use > only the trackers, as all the other functionalities are implemented in > the current GRASS infrastructure (besides surveys; maybe there will be > some use for them - let's keep them in mind :) ). > > There are 3 project member "roles": admin, developer and user. > > 1. "Admin" manages requests to join the project and maintains the GRASS > project at GForge. Currently there are 2 admins: I and Bernard Reiter. > > 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 GRASS 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 you are not sure about :). > > 3. "User" can open new tickets in the trackers, reply to other tickets > and "monitor", participate in surveys ("admin" and "developer" can too, > of course). > > The former GRASS Request Tracker can be used to examine the previously > resolved issues, and those that were still in progress as the new > system was released [5]. > > GForge manuals are here: [6]. > > [1]http://wald.intevation.org/tracker/?group_id=21 > [2]http://wald.intevation.org/account/register.php > [3]http://wald.intevation.org/project/request.php?group_id=21 > [4]http://grass.itc.it/community/support.php#devellists > [5]http://intevation.de/rt/webrt?q_status=open&q_queue=grass > [6]http://gforge.org/docman/index.php?group_id=1&selected_doc_group_id=5&language_id=1 > > Maciek > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > From hamish_nospam at yahoo.com Mon Feb 12 10:23:33 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Feb 12 10:23:47 2007 Subject: [GRASS-dev] [bug #5483] (grass) g.mremove through gis manager GUI seems not to work well In-Reply-To: <17871.23570.679544.688973@cerise.gclements.plus.com> References: <20070207095911.CADFA1005C4@lists.intevation.de> <45C9A4F3.5040304@itc.it> <17865.59758.189673.884182@cerise.gclements.plus.com> <20070208113827.56c056e0.hamish_nospam@yahoo.com> <45CF04CA.5060105@o2.pl> <17871.23570.679544.688973@cerise.gclements.plus.com> Message-ID: <20070212222333.4932aebe.hamish_nospam@yahoo.com> Maciej: > > What do you think about this: if g.mremove cannot remain > > half-interactive, I'd suggest getting rid of it alltogether, and > > replacing it's manual page with an instruction how to use "g.mlist > > sep=," and feed it's output to g.remove by hand (I can write it). No, just remove it from the GUI if the possibility of interactivity is an issue, or create a wrapper script for the GUI which does not include the offending flag. I don't think it is so bad to have command-line-only power-tools, and to leave g.mremove out of the GUI if that's what is required. > > Although removing a module during GRASS 6 should be avoided too, I > > think that this would do less harm than letting g.mremove delete > > user's data without control. Removing a module during GRASS 6 should not be allowed at all. That will break scripts and render documentation+books out of date. > > Or maybe revert the changes in g.mremove as it was, for GRASS 6, and > > postpone working on it to GRASS 7? As for GRASS 7, I'd still vote on > > removing it completely, as described above, instead of removing it's > > interactiveness, for the sake of user's data. Glynn: > Alternative possibilities: > > 1. Rename g.mremove (e.g. to g.remove.multi); if anyone asks where it > went, remind them that the new version doesn't request confirmation. > > 2. Revert g.mremove, add a version which doesn't prompt, change gis.m > to only refer to the non-prompting version. > > Personally, I'd favour #1; option #2 undermines attempts to get > developers to realise that terminal interaction is unacceptable. Personally I'd prefer #2 or removing g.mremove from the GUI menu vs. adding yet another duplicate module. but wait -- ** A compromise idea: make g.mremove without "-f" exit (0 or 1?) after listing the files the regex would match; have it only delete something if "-f" is used. The extra tick of brain activity to type the extra 3 chars should be enough to invoke the do-I-really-want-to-do-this 2nd thought, if not, well that's not our problem, we tried. That way we only "break" interactive mode, and the new solution is in a way interactive (they have to retype the command). -- patch attached. > In my experience, any rule with an "except in special cases" qualifier > may as well not exist. Everyone thinks that their pet case qualifies, > and you end up with a useless mess. > > Either you can rely upon GRASS commands being scriptable, or you > can't. Right now, you can't; Point taken. > if you try to build something on top of GRASS, sooner or later > something is going to try to prompt the non-existent user for input > which will never arrive. It's a worthy goal, and something we should do for GRASS 7, but we can't go around breaking people's scripts in order to make their scripts easier to write! [Glynn's patch in CVS does not do that; some of the proposed solutions might] As far as g.mremove goes, I imagine scripters figured out they needed to use "-f" when they wrote it. So how do folks feel about the compromise solution? Without -f it skips the y/n prompt, forcing "no", and a functional g.remove command line is sent to stdout for perusal[, piping, logging, whatever], along with a message to stderr that you need to use -f if you actually want to remove files. Hamish -------------- next part -------------- Index: scripts/g.mremove/g.mremove =================================================================== RCS file: /home/grass/grassrepository/grass6/scripts/g.mremove/g.mremove,v retrieving revision 1.11 diff -u -r1.11 g.mremove --- scripts/g.mremove/g.mremove 7 Feb 2007 14:58:49 -0000 1.11 +++ scripts/g.mremove/g.mremove 12 Feb 2007 09:09:05 -0000 @@ -28,7 +28,7 @@ #%flag #% key: f -#% description: ignored (retained for compatibility with previous versions) +#% description: force removal (required for actual deletion of files) #%end #%option @@ -205,5 +205,14 @@ echo "No data found." exit 1 fi + +if [ $force -eq 0 ] ; then + echo "The following files would be deleted:" 1>&2 + echo "g.remove $rast $rast3d $vect $icon $labels $region $group $dview" + echo 1>&2 + echo "You must use the force flag to actually remove them. Exiting." 1>&2 + exit 0 +fi + exec g.remove $rast $rast3d $vect $icon $labels $region $group $dview From bernhard at intevation.de Mon Feb 12 11:21:27 2007 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon Feb 12 11:21:48 2007 Subject: [GRASS-dev] new bug tracking for GRASS In-Reply-To: <340505ef0702120003n135d2257nd074f109c8617573@mail.gmail.com> References: <45CCBEAB.5020602@o2.pl> <340505ef0702120003n135d2257nd074f109c8617573@mail.gmail.com> Message-ID: <200702121121.31879.bernhard@intevation.de> On Monday 12 February 2007 09:03, Radim Blazek wrote: > Somehow I was automaticaly (?) subscribed to the system > so that I am now recieving mails from > grass-codepatches@wald.intevation.org. > How can I unsubscribe from the system, I don't know even > my login, I tried various. To me knowledge there is not automatic system for subscriptions. You only get a login for Wald, if you apply for one yourself. (Possible at https://wald.intevation.org/account/register.php .) I guess what you are seeing are the new submission that are send to grass-devel, see Maciej's description. > On 2/9/07, Maciej Sieczka wrote: > > Thanks to Intevation GmbH http://www.intevation.de/index.en.html, who > > invited us to use their GForge setup at http://wald.intevation.org/, > > there are 9 trackers for GRASS now [1]: > > All trackers' new submissions will be automatically forwarded to the > > GRASS development mailing list [4]. All followup traffic will be stored > > in the tracker and forwarded only to parties discussing the ticket. > > However, any project member can "monitor" a ticket, or a whole tracker, > > in order to receive all the related traffic (see GForge manual [6]). To confirm this hypotheses I suggest you take a look at the email headers of the emails in question and check if they contain the list-id of the grass-devel list. If you do not want to see those emails one possible solution can be filtering on your side. Best, Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company); Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Amtsgericht Osnabr?ck, HRB 18998, USt-Id DE204854484 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070212/d62afcb7/attachment.bin From grass-docfeaturerequests at wald.intevation.org Mon Feb 12 12:46:53 2007 From: grass-docfeaturerequests at wald.intevation.org (grass-docfeaturerequests@wald.intevation.org) Date: Mon Feb 12 13:08:43 2007 Subject: [GRASS-dev] [grass-doc feature requests][284] rasterintro.html should mention MASK, CELL, NULL Message-ID: <20070212114653.B5BAE1801DA1@pyrosoma.intevation.org> doc feature requests item #284, was opened at 2007-02-13 00:46 Status: Open Priority: 3 Submitted By: Hamish Bowman (hamish) Assigned to: Nobody (None) Summary: rasterintro.html should mention MASK, CELL, NULL Doc section: introduction Issue status: None Initial Comment: Hi, raster/rasterintro.html needs to talk about MASK maps and how they work. Also it should mention what CELL, FCELL, DCELL maps are, and also mention something about NULL support. Beyond CELL/DCELL types, maybe mention something about category vs floating point (soil types vs DEM) maps? Both can be CELL maps, but they are logically different. thanks! Hamish ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=206&aid=284&group_id=21 From neteler at itc.it Mon Feb 12 13:16:37 2007 From: neteler at itc.it (Markus Neteler) Date: Mon Feb 12 13:16:39 2007 Subject: [GRASS-dev] bugtracker mail subject lines too long In-Reply-To: <20070212114653.B5BAE1801DA1@pyrosoma.intevation.org> References: <20070212114653.B5BAE1801DA1@pyrosoma.intevation.org> Message-ID: <20070212121637.GA14452@bartok.itc.it> Hi Maciej, would it be possible to shorten the new bugtracker subject line prefixes? e.g. this one, Re: [GRASS-dev] [grass-doc feature requests][284] rasterintro.html should mention MASK 1 10 20 30 40 48 only at position 48 relevant info starts. With my 80x25 terminal I see on 80-48 chars which isn't much. It's getting worse once an issue is discussed. (Re: Re: etc) What about [grass-doc feature requests] -> [grass-doc FR] or simply P: patch F: feature request I: issue? Thanks, Markus On Mon, Feb 12, 2007 at 12:46:53PM +0100, grass-docfeaturerequests@wald.intevation.org wrote: > doc feature requests item #284, was opened at 2007-02-13 00:46 > Status: Open > Priority: 3 > Submitted By: Hamish Bowman (hamish) > Assigned to: Nobody (None) > Summary: rasterintro.html should mention MASK, CELL, NULL > Doc section: introduction > Issue status: None From hamish_nospam at yahoo.com Mon Feb 12 13:37:16 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Feb 12 13:37:22 2007 Subject: [GRASS-dev] spam on the wiki :( Message-ID: <20070213013716.08f3d9a5.hamish_nospam@yahoo.com> Hi, On 7 Feb a user called 'Mikael' added a huge list of mostly invisible links to the main wiki page and the 'GRASS_Wiki:About' page. This is done as a scummy move to take advantage of our good web browser ranking to push their customer's rankings slightly higher. I have now removed the spam. I would ask the wiki maintainer* to delete that account, and blacklist their IP addr if possible (as feel good measures still make you feel good). [*] "Your name here" http://grass.gdf-hannover.de/wiki/Project_jobs#Wiki_manager argh, Hamish From glynn at gclements.plus.com Mon Feb 12 13:50:17 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Feb 12 13:50:23 2007 Subject: [GRASS-dev] Re: [GRASS-user] problems using r.proj with large data set In-Reply-To: <20070212133639.02a45a62.hamish_nospam@yahoo.com> References: <009801c71a20$2e223d60$3e40ae80@ace.uiuc.edu> <7746318.post@talk.nabble.com> <457882F8.2020001@o2.pl> <17784.51544.421727.643216@cerise.gclements.plus.com> <17797.60295.671067.744836@cerise.gclements.plus.com> <9E06EBB8-9577-4146-AA53-0FC27855EC6F@kyngchaos.com> <17867.1426.935411.652226@cerise.gclements.plus.com> <8D78CDF6-FD1C-47FC-AAA7-F34C815DB6A9@kyngchaos.com> <20070209130932.4f1f5cb7.hamish_nospam@yahoo.com> <17868.16797.736678.350911@cerise.gclements.plus.com> <20070212133639.02a45a62.hamish_nospam@yahoo.com> Message-ID: <17872.25225.998565.791315@cerise.gclements.plus.com> Hamish wrote: > > Actually, G__tempfile() probably shouldn't be called while the > > alternate environment is active, as it will create the temporary file > > in the location from the alternate environment (i.e. the source > > location), when you probably want it to be in the current location > > (according to $GISRC). > > So $ETC/clean_temp won't be run and we need to be extra sure that the > tempfile is removed when the program exits, either successfully or > unsuccessfully. No, we just need to be sure that the starting environment is selected before calling G__tempfile(), which is how r.proj.seg was fixed. > > There's still the general issue that any other functions which use > > G_mapset() may not behave as expected while an alternate environment > > is active. > > At least we are now aware of the problem, and as well we already know > well which cases invoke an alternate environment. And hopefully we can > move away from that sort of trick with time (ala Michael's georectifier). You can't avoid using alternate environments if a program needs to access another location. The simplest defensive strategy is to ensure that you leave the starting environment active by default. IOW, switch to the alternate environment immediately before each call which uses it, and switch back immediately afterwards. The problem with r.proj.seg arose primarily due to the structure of the original r.proj. Whereas the original readcell() function simply read the map into memory (and thus needed to operate in the alternate environment), the new readcell() copies it to a temporary file. Thus, G__tempfile() ended up being called in essentially the only place where the alternate environment was active. The rest of r.proj.seg operates in the starting environment. [Aside: my first attempt used a rowio-type strategy, but I discovered that you can't switch projections while you have maps open; hence the need to copy the map to a temporary file.] -- Glynn Clements From hamish_nospam at yahoo.com Mon Feb 12 13:56:22 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Feb 12 13:56:35 2007 Subject: [GRASS-dev] coastline for the grass usermap Message-ID: <20070213015622.0cd3d86f.hamish_nospam@yahoo.com> I notice the coastline for the GDF Hannover GRASS users' map is quite crude when you zoom in to city scale. The raster backdrop looks great. (I'm not sure who maintains that.) Here is a better worldwide vector coastline, licensed as GPL: http://www.ngdc.noaa.gov/mgg/shorelines/data/gshhs/version1.5/ It would be nice to use it! Hamish From andrea.antonello at gmail.com Mon Feb 12 13:58:40 2007 From: andrea.antonello at gmail.com (Andrea Antonello) Date: Mon Feb 12 13:58:49 2007 Subject: [GRASS-dev] GRASS - UDig projection definitions In-Reply-To: <20070213013716.08f3d9a5.hamish_nospam@yahoo.com> References: <20070213013716.08f3d9a5.hamish_nospam@yahoo.com> Message-ID: <45D06480.3070200@gmail.com> Hi developers, I'm trying to make udig speak the same language as GRASS, but I found one main issue, I'm not able to resolve. GRASS and UDig use different projection definitions. - in Grass the projection file is something like: name: Transverse Mercator proj: tmerc datum: rome40 towgs84: -225.000,-65.000,9.000 a: 6378388 es: 0.0067226700 lat_0: 0 lon_0: 9 k: 0.999600 x_0: 1500000 y_0: 0 no_defs: defined - whereas in UDig it is WKT: PROJCS["Monte Mario / Italy zone 1", GEOGCS["Monte Mario", DATUM["Monte_Mario", SPHEROID["International 1924", 6378388.0, 297.0, AUTHORITY["EPSG","7022"]], AUTHORITY["EPSG","6265"]], PRIMEM["Greenwich", 0.0, AUTHORITY["EPSG","8901"]], UNIT["degree", 0.017453292519943295], AXIS["Lon", EAST], AXIS["Lat", NORTH], AUTHORITY["EPSG","4265"]], PROJECTION["Transverse_Mercator"], PARAMETER["central_meridian", 9.0], PARAMETER["latitude_of_origin", 0.0], PARAMETER["scale_factor", 0.9996], PARAMETER["false_easting", 1500000.0], PARAMETER["false_northing", 0.0], UNIT["m", 1.0], AXIS["x", EAST], AXIS["y", NORTH], AUTHORITY["EPSG","3003"]] I'm no projection wizard, has anyone an idea about how I can go from one to the other and back in an easy way? Thanks for any help, Cheers, Andrea From mlennert at club.worldonline.be Mon Feb 12 14:10:03 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Mon Feb 12 14:07:39 2007 Subject: [GRASS-dev] GRASS - UDig projection definitions In-Reply-To: <45D06480.3070200@gmail.com> References: <20070213013716.08f3d9a5.hamish_nospam@yahoo.com> <45D06480.3070200@gmail.com> Message-ID: <45D0672B.80604@club.worldonline.be> On 12/02/07 13:58, Andrea Antonello wrote: > Hi developers, > I'm trying to make udig speak the same language as GRASS, but I found > one main issue, I'm not able to resolve. > > GRASS and UDig use different projection definitions. > - in Grass the projection file is something like: > name: Transverse Mercator > proj: tmerc > datum: rome40 > towgs84: -225.000,-65.000,9.000 > a: 6378388 > es: 0.0067226700 > lat_0: 0 > lon_0: 9 > k: 0.999600 > x_0: 1500000 > y_0: 0 > no_defs: defined > > - whereas in UDig it is WKT: > PROJCS["Monte Mario / Italy zone 1", > GEOGCS["Monte Mario", > DATUM["Monte_Mario", > SPHEROID["International 1924", 6378388.0, 297.0, > AUTHORITY["EPSG","7022"]], > AUTHORITY["EPSG","6265"]], > PRIMEM["Greenwich", 0.0, AUTHORITY["EPSG","8901"]], > UNIT["degree", 0.017453292519943295], > AXIS["Lon", EAST], > AXIS["Lat", NORTH], > AUTHORITY["EPSG","4265"]], > PROJECTION["Transverse_Mercator"], > PARAMETER["central_meridian", 9.0], > PARAMETER["latitude_of_origin", 0.0], > PARAMETER["scale_factor", 0.9996], > PARAMETER["false_easting", 1500000.0], > PARAMETER["false_northing", 0.0], > UNIT["m", 1.0], > AXIS["x", EAST], > AXIS["y", NORTH], > AUTHORITY["EPSG","3003"]] > > I'm no projection wizard, has anyone an idea about how I can go from one > to the other and back in an easy way? g.proj -w "Print projection information in WKT format" Moritz From glynn at gclements.plus.com Mon Feb 12 14:10:40 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Feb 12 14:10:47 2007 Subject: [GRASS-dev] WxPython front-end to ps.map In-Reply-To: <20070212134112.086eda54.hamish_nospam@yahoo.com> References: <20070207203925.649c2def.hamish_nospam@yahoo.com> <45CAECAD.7020505@club.worldonline.be> <17867.3613.858298.118086@cerise.gclements.plus.com> <200702081144.34725.dylan.beaudette@gmail.com> <17868.15569.809267.225649@cerise.gclements.plus.com> <20070212134112.086eda54.hamish_nospam@yahoo.com> Message-ID: <17872.26448.422916.237477@cerise.gclements.plus.com> Hamish wrote: > > My original preference for a new graphics API was to have d.* commands > > simply generate PostScript conforming to certain conventions. The > > resulting PostScript could then be drawn on screen (x11 driver), > > rendered to an image (PNG/PPM/BMP/etc drivers) or sent to a printer > > (either a native PostScript printer or via the ljet/PCL/etc drivers). > > > > Unfortunately, rendering vector maps using PostScript is between 1 and > > 2 orders of magnitude slower than using XDrawLine(), which is bad for > > interactive use. So we still need some kind of intermediate layer > > which provides a speed-before-quality option for drawing lines. > > What about adding a [E]PostScript display driver? Akin to the PNG > driver, vs. the x11 driver. It would primarily be intended for hardcopy > output, but could potentially be used for (slow) GUI protoypes. The raster graphics API is entirely unsuitable for a PostScript driver. The main problem is that everything operates using "pixel" coordinates, but PostScript's graphics model is based upon infinite resolution (the actual device resolution is an implementation detail). Certainly, something could be written which exposed a fake resolution to the application, however: 1. All coordinates would end up being snapped to the fake resolution grid. 2. Any raster data would be re-scaled client side, the rescaled data sent to the driver, then rescaled again by the PostScript implementation to the actual device resolution. 3. d.area renders filled areas itself (using G_plot_polygon) by sending a series of horizontal lines to the driver. The above points would all have an impact upon the choice of the fake resolution. A higher resolution would result in better output, but would result in #2 and #3 generating significantly more data; this will harm performance and generate huge PostScript files (if you're storing them, or sending them to a physical printer). A lower resolution would result in low quality output, which would be very noticable on >300dpi hardcopy. In practice, a PostScript driver based upon the current API wouldn't produce significantly better results than just using the PNG driver and embedding the image in a PostScript file. In short, we need a new graphics API; if it was only a matter of implementing a driver, I would have done it years ago. -- Glynn Clements From andrea.antonello at gmail.com Mon Feb 12 14:10:47 2007 From: andrea.antonello at gmail.com (Andrea Antonello) Date: Mon Feb 12 14:11:31 2007 Subject: [GRASS-dev] GRASS - UDig projection definitions In-Reply-To: <45D0672B.80604@club.worldonline.be> References: <20070213013716.08f3d9a5.hamish_nospam@yahoo.com> <45D06480.3070200@gmail.com> <45D0672B.80604@club.worldonline.be> Message-ID: <45D06757.8030009@gmail.com> Thanks Moritz, this also means that there is no easy way (something like parse that and that and then create the WTK), the proj pack has to be there, right? Andrea Moritz Lennert probaly wrote: > On 12/02/07 13:58, Andrea Antonello wrote: >> Hi developers, >> I'm trying to make udig speak the same language as GRASS, but I found >> one main issue, I'm not able to resolve. >> >> GRASS and UDig use different projection definitions. >> - in Grass the projection file is something like: >> name: Transverse Mercator >> proj: tmerc >> datum: rome40 >> towgs84: -225.000,-65.000,9.000 >> a: 6378388 >> es: 0.0067226700 >> lat_0: 0 >> lon_0: 9 >> k: 0.999600 >> x_0: 1500000 >> y_0: 0 >> no_defs: defined >> >> - whereas in UDig it is WKT: >> PROJCS["Monte Mario / Italy zone 1", >> GEOGCS["Monte Mario", >> DATUM["Monte_Mario", >> SPHEROID["International 1924", 6378388.0, 297.0, >> AUTHORITY["EPSG","7022"]], >> AUTHORITY["EPSG","6265"]], >> PRIMEM["Greenwich", 0.0, AUTHORITY["EPSG","8901"]], >> UNIT["degree", 0.017453292519943295], >> AXIS["Lon", EAST], >> AXIS["Lat", NORTH], >> AUTHORITY["EPSG","4265"]], >> PROJECTION["Transverse_Mercator"], >> PARAMETER["central_meridian", 9.0], >> PARAMETER["latitude_of_origin", 0.0], >> PARAMETER["scale_factor", 0.9996], >> PARAMETER["false_easting", 1500000.0], >> PARAMETER["false_northing", 0.0], >> UNIT["m", 1.0], >> AXIS["x", EAST], >> AXIS["y", NORTH], >> AUTHORITY["EPSG","3003"]] >> >> I'm no projection wizard, has anyone an idea about how I can go from one >> to the other and back in an easy way? > > > g.proj -w "Print projection information in WKT format" > > Moritz > From stephan.holl at intevation.de Mon Feb 12 14:13:59 2007 From: stephan.holl at intevation.de (Stephan Holl) Date: Mon Feb 12 14:14:03 2007 Subject: [GRASS-dev] coastline for the grass usermap In-Reply-To: <20070213015622.0cd3d86f.hamish_nospam@yahoo.com> References: <20070213015622.0cd3d86f.hamish_nospam@yahoo.com> Message-ID: <20070212141359.692d04bc@thoe.hq.intevation.de> Hello Hamish, Hamish , [20070213 - 01:56:22] > I notice the coastline for the GDF Hannover GRASS users' map is quite > crude when you zoom in to city scale. The raster backdrop looks great. > (I'm not sure who maintains that.) > > Here is a better worldwide vector coastline, licensed as GPL: > http://www.ngdc.noaa.gov/mgg/shorelines/data/gshhs/version1.5/ I have maintained this app for some time, but currently I have no access to the server anymore so I cannot apply your suggested dataset. Do you know a WMS-Server where this data is made available to the public? This would reduce the ammount of work which needs to be done to preprocess. > It would be nice to use it! I leave it this to the current maintainers at GDF for decision. Best Stephan -- Stephan Holl , http://intevation.de/~stephan Tel: +49 (0)541-33 50 8 32 | Intevation GmbH | AG Osnabr?ck - HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From glynn at gclements.plus.com Mon Feb 12 14:21:54 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Feb 12 14:21:57 2007 Subject: [GRASS-dev] [bug #5489] (grass) d.font error in GRASS6.2/6.3 In-Reply-To: <20070212134638.3a144f56.hamish_nospam@yahoo.com> References: <20070209094046.8B1711006CB@lists.intevation.de> <17868.46453.143635.880150@cerise.gclements.plus.com> <20070212134638.3a144f56.hamish_nospam@yahoo.com> Message-ID: <17872.27122.777962.718471@cerise.gclements.plus.com> Hamish wrote: > > This is why direct rendering has GRASS_FONT, GRASS_FT_FONT and > > GRASS_FT_ENCODING; there isn't any other way to set this state. > > Could you document these 3 in lib/init/variables.html ? OK; I've added the following:

List of selected GRASS environment variables for direct rendering

[ In addition to those which are understood by the PNG Driver, the following variables affect direct rendering. ]

GRASS_FONT
  specifies the font as either the name of a stroke font in $GISBASE/etc/fonts, the full path to a stroke font (which must begin with $GISBASE/etc/fonts/), the name of a FreeType font from $GISBASE/etc/freetypecap, or the full path to a FreeType font file.

GRASS_FT_FONT
  specifies a FreeType font as a full path to the font file. If both GRASS_FONT and GRASS_FT_FONT are specified, GRASS_FT_FONT takes precedence.

GRASS_FT_ENCODING
  the encoding to be assumed for text which is drawn using a freetype font; may be any encoding know to "iconv". -- Glynn Clements From mlennert at club.worldonline.be Mon Feb 12 14:31:22 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Mon Feb 12 14:28:58 2007 Subject: [GRASS-dev] WxPython front-end to ps.map In-Reply-To: References: Message-ID: <45D06C2A.3080704@club.worldonline.be> On 09/02/07 19:56, Michael Barton wrote: > Moritz, > > Sorry for the confusion. I'm thinking of how map layers are presented to > users in the layer control panel. It might be cleaner to have a single > "vector" layer button instead of "vector", "thematic map", and "thematic > chart" buttons. In the options panel for the vector layer, you could decide > whether this would display a single color vector map, thematic display of > the vector map, or a thematic chart of the vector map. In other words, there > would be a single control/options panel that would wrap d.vect, > d.vect.thematic, and d.vect.chart. > > Again, I'm not talking about what we should do with the modules, only how > they could be presented to a GUI user. However, if we have a different way > of rendering vectors (i.e., a rewrite of the vector display somehow), I > think it should include the thematic and chart mapping, rather than just the > simply vector display. > Sounds like an interesting idea. The only danger I see is that panels will be huge. Combining all options of d.vect, d.vect.thematic, and d.vect.chart into one single panel might make it quite confusing. Moritz > Michael > > > On 2/9/07 1:33 AM, "Moritz Lennert" wrote: > >> On 09/02/07 04:46, Michael Barton wrote: >> >>> Thematic maps and charts seem like they should be a vector option rather >>> than separate layers. This could be done with GUI code without needing to >>> combine the d.* modules. However, if we did true vector rendering for >>> primitives, we'd want the same quality in thematic maps and charts. >>> >>> I'm not sure if this makes any considered recoding any easier or not. But >>> the upshot is that vector primitives, thematic maps, and charts seem the >>> best candidates for some reworking of the C code for display. Most of the >>> other d.* effects can work with current code or be replaced by GUI generated >>> graphics if we want. As you point out, this is more work at the GUI coding >>> end. I'm not sure which will take more effort. >> >> I'm not sure I completely understand what you mean here, and as we are >> still (albeit slowly, I admit) working on a C replacement of >> d.vect.thematic, it would be good to know what we should take into account. >> >> I do have to agree with Glynn, though, in that we should try to not code >> two parallel and different ways of drawing things, one for the command >> line and one for the GUI. I am afraid that this would almost inevitably >> lead to inconsistencies and definitely to twice the work load trying to >> keep everything up to date. IMHO, GRASS's strength is its modularity and >> the GUI should be on top of that, not replace it. >> >> Moritz > > __________________________________________ > Michael Barton, Professor of Anthropology > School of Human Evolution & Social Change > Center for Social Dynamics and Complexity > Arizona State University > >