From tutey at o2.pl Thu Mar 1 00:05:12 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Thu Mar 1 00:05:16 2007 Subject: [GRASS-dev] Re: g.rename consolidation In-Reply-To: <17894.1133.67379.749992@cerise.gclements.plus.com> References: <45E5CE32.5020007@o2.pl> <17894.1133.67379.749992@cerise.gclements.plus.com> Message-ID: <45E60AA8.2040608@o2.pl> Glynn Clements wrote: > Maciej Sieczka wrote: > >> Michael Barton wrote: >>> TclTk has a nice progress bar capabilities. But it needs consistent >>> information to read. There is a progress bar built into the map display that >>> tracks display progress. For modules that output consistent progress >>> information, there is the green progress bar in the autogenerated dialog. >>> The holes are for modules that don't output progress information in a >>> consistent format and for scripts that tend not to output it at all. >> Is it possible to make the script output progress info in way tcl/tk >> GRASS GUI could use it? > if [ "$GRASS_MESSAGE_FORMAT" = "gui" ] ; then > echo "GRASS_INFO_PERCENT: $percent" >&2 > fi Thank you (I couldn't find this GRASS_INFO_PERCENT documented in variables.html). > It could get tricky if the script calls modules which output their own > percentages. > > I suppose that the script *could* process the commands' stderr, parse > the percentages and re-emit them to its own stderr, scaled according > to the proportion of the task that the command represents. Although, > I'm not expecting to see many scripts actually taking that approach. Just one (I hope ;) ) question more: could I somehow disable module's progress output alone, still letting it print it's ERRORs, ie. not sending both it's sdout and stderr to /dev/null? Maciek From dplsfn at yahoo.it Thu Mar 1 00:06:18 2007 From: dplsfn at yahoo.it (stefano de paoli) Date: Thu Mar 1 00:06:20 2007 Subject: [GRASS-dev] GRASS inefficiency and FFTW In-Reply-To: <17893.64630.368809.549431@cerise.gclements.plus.com> Message-ID: <812009.11946.qm@web25612.mail.ukl.yahoo.com> > > The problem is that we couldn't then use other > people's GPL code, as > we wouldn't be distributing the end result under the > GPL. > > Also, what does the "use within GRASS only" > restriction on the NR code > actually mean for a GPL'd project? If someone takes > the GRASS code and > starts modifying it, at what point does their > version cease to be > "GRASS"? I may be mistaken, but you would also have lost the right to use the GPL at all if the NR code remained in GRASS. Is that true? > -- > Glynn Clements > ___________________________________ L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html From hamish_nospam at yahoo.com Thu Mar 1 00:57:57 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Mar 1 00:58:12 2007 Subject: [GRASS-dev] GRASS inefficiency and FFTW In-Reply-To: <17893.64630.368809.549431@cerise.gclements.plus.com> References: <17891.37265.72229.80048@cerise.gclements.plus.com> <648984.27145.qm@web25605.mail.ukl.yahoo.com> <20070228205731.4b832019.hamish_nospam@yahoo.com> <17893.64630.368809.549431@cerise.gclements.plus.com> Message-ID: <20070301125757.25bd9e6d.hamish_nospam@yahoo.com> Glynn Clements wrote: > Also, what does the "use within GRASS only" restriction on the NR code > actually mean for a GPL'd project? If someone takes the GRASS code and > starts modifying it, at what point does their version cease to be > "GRASS"? presumably that permission was granted before GRASS went GPL and was still (for the most part) a single entity headed by CERL. H From hamish_nospam at yahoo.com Thu Mar 1 01:31:23 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Mar 1 01:31:27 2007 Subject: [GRASS-dev] Re: g.rename consolidation In-Reply-To: <45E60AA8.2040608@o2.pl> References: <45E5CE32.5020007@o2.pl> <17894.1133.67379.749992@cerise.gclements.plus.com> <45E60AA8.2040608@o2.pl> Message-ID: <20070301133123.2841933b.hamish_nospam@yahoo.com> Maciej Sieczka wrote: > Just one (I hope ;) ) question more: could I somehow disable module's > progress output alone, still letting it print it's ERRORs, ie. not > sending both it's sdout and stderr to /dev/null? that is what --quiet and GRASS_VERBOSE=0 is supposed to do. But migrating messages to obey that is of course a work in progress. Hamish From glynn at gclements.plus.com Thu Mar 1 03:40:48 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Mar 1 03:40:50 2007 Subject: [GRASS-dev] GRASS inefficiency and FFTW In-Reply-To: <812009.11946.qm@web25612.mail.ukl.yahoo.com> References: <17893.64630.368809.549431@cerise.gclements.plus.com> <812009.11946.qm@web25612.mail.ukl.yahoo.com> Message-ID: <17894.15664.47409.961926@cerise.gclements.plus.com> stefano de paoli wrote: > > The problem is that we couldn't then use other > > people's GPL code, as > > we wouldn't be distributing the end result under the > > GPL. > > > > Also, what does the "use within GRASS only" > > restriction on the NR code > > actually mean for a GPL'd project? If someone takes > > the GRASS code and > > starts modifying it, at what point does their > > version cease to be > > "GRASS"? > > I may be mistaken, but you would also have lost the > right to use the GPL at all if the NR code remained in > GRASS. > > Is that true? We could release our own code (and that inherited from CERL) under the GPL, but the licence for GRASS as a whole would be "GPL, except for the FFT code". Consequently, we would have needed specific permission to use any third-party code in GRASS; code which is only licensed under the GPL can't be used in a project whose licence is "GPL, except for ...". That would preclude the use of e.g. the Readline library. Before Qt was available under the GPL, it was quite common for Qt-based code to use a licence which allowed the code to be used under the terms of the GPL, and which also specifically permitted the distribution of binaries which were linked against Qt (which wouldn't have been legal had the code only been licensed under the GPL). However, that meant that all code had to be written anew, or be taken from projects which also used the "GPL+Qt" license; using plain GPL code wouldn't have been legal. -- Glynn Clements From glynn at gclements.plus.com Thu Mar 1 03:46:08 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Mar 1 03:46:09 2007 Subject: [GRASS-dev] Re: g.rename consolidation In-Reply-To: <20070301133123.2841933b.hamish_nospam@yahoo.com> References: <45E5CE32.5020007@o2.pl> <17894.1133.67379.749992@cerise.gclements.plus.com> <45E60AA8.2040608@o2.pl> <20070301133123.2841933b.hamish_nospam@yahoo.com> Message-ID: <17894.15984.548329.960441@cerise.gclements.plus.com> Hamish wrote: > > Just one (I hope ;) ) question more: could I somehow disable module's > > progress output alone, still letting it print it's ERRORs, ie. not > > sending both it's sdout and stderr to /dev/null? > > that is what --quiet and GRASS_VERBOSE=0 is supposed to do. But > migrating messages to obey that is of course a work in progress. That will disable all messages except warnings and errors. In retrospect, that may have been what Maciej was asking for, but I took "progress output" to mean the percentages and nothing else. -- Glynn Clements From glynn at gclements.plus.com Thu Mar 1 03:44:34 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Mar 1 03:46:25 2007 Subject: [GRASS-dev] Re: g.rename consolidation In-Reply-To: <45E60AA8.2040608@o2.pl> References: <45E5CE32.5020007@o2.pl> <17894.1133.67379.749992@cerise.gclements.plus.com> <45E60AA8.2040608@o2.pl> Message-ID: <17894.15890.964915.410863@cerise.gclements.plus.com> Maciej Sieczka wrote: > >>> TclTk has a nice progress bar capabilities. But it needs consistent > >>> information to read. There is a progress bar built into the map display that > >>> tracks display progress. For modules that output consistent progress > >>> information, there is the green progress bar in the autogenerated dialog. > >>> The holes are for modules that don't output progress information in a > >>> consistent format and for scripts that tend not to output it at all. > >> Is it possible to make the script output progress info in way tcl/tk > >> GRASS GUI could use it? > > > if [ "$GRASS_MESSAGE_FORMAT" = "gui" ] ; then > > echo "GRASS_INFO_PERCENT: $percent" >&2 > > fi > > Thank you (I couldn't find this GRASS_INFO_PERCENT documented in > variables.html). GRASS_INFO_PERCENT isn't a variable; it's part of the syntax used for progress output when modules are being run from a GUI. The default output (using backspace characters to overwrite the previous output) is awkward to parse, especially if any other output gets interleaved with the percentages. GRASS_MESSAGE_FORMAT is listed in variables.html, but it doesn't specify its precise semantics. > > It could get tricky if the script calls modules which output their own > > percentages. > > > > I suppose that the script *could* process the commands' stderr, parse > > the percentages and re-emit them to its own stderr, scaled according > > to the proportion of the task that the command represents. Although, > > I'm not expecting to see many scripts actually taking that approach. > > Just one (I hope ;) ) question more: could I somehow disable module's > progress output alone, still letting it print it's ERRORs, ie. not > sending both it's sdout and stderr to /dev/null? Currently, no. Supporting e.g. GRASS_MESSAGE_FORMAT=silent would be a useful enhancement. -- Glynn Clements From hamish_nospam at yahoo.com Thu Mar 1 05:31:12 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Mar 1 05:31:23 2007 Subject: [GRASS-dev] using G_parser() --script in the wild In-Reply-To: <17893.64348.200686.75406@cerise.gclements.plus.com> References: <20070227163125.42527d0e.hamish_nospam@yahoo.com> <17892.35477.374032.591612@cerise.gclements.plus.com> <20070228194549.6ec1829f.hamish_nospam@yahoo.com> <17893.64348.200686.75406@cerise.gclements.plus.com> Message-ID: <20070301173112.392357d6.hamish_nospam@yahoo.com> Glynn Clements wrote: > NULL and "" aren't the same thing. Modules which test whether an > optional (non-required) option was used normally test whether > "opt->answer == NULL". The only way to create this situation is to not > specify the option in the command line. You can't pass NULL as an > option value, and passing an empty value (i.e. "opt=") will result in > opt->answer not being equal to NULL. what are they equal to then? as all opt->answer are stored as strings regardless of TYPE_* setting, and C strings are null terminated, a string with nothing in it (opt="") becomes opt->answer[0]=='\0', right? Oh, I see now, it's a pointer and the mem address is no longer NULL even though the content found at that memory address is. slowly catching on, Hamish From grass-codei at wald.intevation.org Thu Mar 1 07:50:06 2007 From: grass-codei at wald.intevation.org (grass-codei@wald.intevation.org) Date: Thu Mar 1 07:50:09 2007 Subject: [GRASS-dev] [grass-code I][318] r.in.wms pretends to be MSIE5.5. Sod that! Message-ID: <20070301065006.97E84182D7BE@pyrosoma.intevation.org> code I item #318, was opened at 2007-03-01 19:50 Status: Open Priority: 3 Submitted By: Hamish Bowman (hamish) Assigned to: Nobody (None) Summary: r.in.wms pretends to be MSIE5.5. Sod that! Issue type: module bad feature Issue status: None GRASS version: CVS HEAD GRASS component: raster Operating system: all Operating system version: GRASS CVS checkout date, if applies (YYMMDD): Initial Comment: The wgetoptions= option in r.in.wms (and wms.download) adds: --user-agent=MSIE5.5 It doesn't help the cause any to pretend that alternatives to MSIE don't exist. I don't mind a mention in the help page to add that trick if the user comes across a brain-dead server which won't let them in, but by default we should be proud to use wget & FOSS! I think we should remove that from the scripts. Hamish ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=318&group_id=21 From bernhard at intevation.de Thu Mar 1 09:46:40 2007 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu Mar 1 09:46:55 2007 Subject: [GRASS-dev] [bug #5504] (grass) In-Reply-To: <45E5D213.5080902@o2.pl> References: <20070224221914.164F01006A2@lists.intevation.de> <20070226113908.46ffe2a2.hamish_nospam@yahoo.com> <45E5D213.5080902@o2.pl> Message-ID: <200703010946.44927.bernhard@intevation.de> On Wednesday 28 February 2007 20:03, Maciej Sieczka wrote: > Hamish wrote: > > It's time to stop allowing -new bugs- to be submitted -by email- to the > > old bug tracker. > > Several days ago I have already asked Bernhard if that's doable but he > still didn't get a reply from those who he asked :). > This is annoying-me again. Can you let us know what is the status? Thanks! Maciej, we switched this off on Tuesday and one of Intevation's admin has send an email to you on this day. Registered users with manipulation rights can still open issues, which I think is okay. We probably cannot change this anyway. So there is a remote chance that spammers hit the right address. Best, Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070301/d1f09f21/attachment.bin From neteler at itc.it Thu Mar 1 16:36:48 2007 From: neteler at itc.it (Markus Neteler) Date: Thu Mar 1 16:36:59 2007 Subject: [GRASS-dev] GRASS inefficiency and FFTW In-Reply-To: <20070301125757.25bd9e6d.hamish_nospam@yahoo.com> References: <17891.37265.72229.80048@cerise.gclements.plus.com> <648984.27145.qm@web25605.mail.ukl.yahoo.com> <20070228205731.4b832019.hamish_nospam@yahoo.com> <17893.64630.368809.549431@cerise.gclements.plus.com> <20070301125757.25bd9e6d.hamish_nospam@yahoo.com> Message-ID: <45E6F310.6060404@itc.it> Hamish wrote on 03/01/2007 12:57 AM: > Glynn Clements wrote: > >> Also, what does the "use within GRASS only" restriction on the NR code >> actually mean for a GPL'd project? If someone takes the GRASS code and >> starts modifying it, at what point does their version cease to be >> "GRASS"? >> > > presumably that permission was granted before GRASS went GPL Yes, as far as I remember it was granted in 1988. So 11 years earlier. markus > and was still (for the most part) a single entity headed by CERL. > > H From grass-bugs at intevation.de Thu Mar 1 17:21:08 2007 From: grass-bugs at intevation.de (Request Tracker) Date: Thu Mar 1 17:21:09 2007 Subject: [GRASS-dev] [bug #5510] (grass) [spam] - please ignore it; testing as msieczka; BT online Message-ID: <20070301162108.D8E7E1005B0@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5510 ------------------------------------------------------------------------- Subject: [spam] - please ignore it; testing as msieczka; BT online [spam] - please ignore it; testing as msieczka; BT online -------------------------------------------- Managed by Request Tracker From tutey at o2.pl Thu Mar 1 17:36:20 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Thu Mar 1 17:36:24 2007 Subject: [GRASS-dev] [bug #5504] (grass) In-Reply-To: <200703010946.44927.bernhard@intevation.de> References: <20070224221914.164F01006A2@lists.intevation.de> <20070226113908.46ffe2a2.hamish_nospam@yahoo.com> <45E5D213.5080902@o2.pl> <200703010946.44927.bernhard@intevation.de> Message-ID: <45E70104.3010809@o2.pl> Bernhard Reiter wrote: > On Wednesday 28 February 2007 20:03, Maciej Sieczka wrote: >> This is annoying-me again. Can you let us know what is the status? Thanks! > we switched this off on Tuesday and one of Intevation's admin > has send an email to you on this day. I didn't receive that email. I don't use a spam filter. It must have get lost in between somewhere. > Registered users with manipulation rights can still open issues, > which I think is okay. Perfect, thanks. > We probably cannot change this anyway. No need to. > So there is a remote chance that spammers hit the right address. Could you explain how exactly? Maciek From jachym.cepicky at gmail.com Thu Mar 1 18:43:03 2007 From: jachym.cepicky at gmail.com (=?ISO-8859-2?Q?J=E1chym_=C8epick=FD?=) Date: Thu Mar 1 18:43:04 2007 Subject: [GRASS-dev] ps.map consolidation Message-ID: Hi, I started to look into ps.map code and I found few issues, which should be IMHO solved, so the code looks a bit nicer and the usage is more consistent. It would be great, if somebody more skilled would post some comments to this topic, I will be very much thankful. 1) some instructions (raster, setcolor) do not need to end with "end" keyword, where others do. this should be IMHO consolidated, so that ALL instructions will need to end with "end" keyword. we should look into configuration file of mapserver for inspiration 2) I think, file session.c can be removed. I did not quite understand, what is this session management about, but it would make the code a bit simplier and short test showed, it is working also without it (and I found no other function, which wuold access functions from session.c) 3) some units are map units by default, where some are percent, some inches. It would be IMHO great, if the user would have allways to specify, which units she would like to use (without enything, it would be map units), example: text 30% 100% SPEARFISH SOILS MAP end text 3cm 10cm SPEARFISH SOILS MAP end text 30000.0 20000.04 SPEARFISH SOILS MAP end text 1in 1.5in SPEARFISH SOILS MAP end currently, only some instructions are supporting % 4) placenemnt should be allways specified with "where" keyword 5) text or other value should be allways specified with "value" keyword: text 650000 7365000 SPEARFISH LAND COVER end -> text where 650000 7365000 value SPEARFISH LAND COVER end 6) file (map) names should be allways specified with "name" keyword example: vlines streams end -> vlines name streams end this is all for now what do you think? thanks for your comments 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-coder at wald.intevation.org Thu Mar 1 19:43:01 2007 From: grass-coder at wald.intevation.org (grass-coder@wald.intevation.org) Date: Thu Mar 1 19:43:03 2007 Subject: [GRASS-dev] [grass-code R][319] v.distance: connect the output table= with the output vector= Message-ID: <20070301184301.B3DF318387BE@pyrosoma.intevation.org> code R item #319, was opened at 2007-03-01 19:43 Status: Open Priority: 3 Submitted By: Maciej Sieczka (msieczka) Assigned to: Nobody (None) Summary: v.distance: connect the output table= with the output vector= Issue status: None GRASS component: vector Operating system: all Operating system version: Initial Comment: Currently v.distance is able to output a lines vector where each line connects any 2 input points (-a output=), and it also can upload the required relation between each pair of points (upload=) into a table (column= table=). However, the output table and the vector are not connected. Which is too bad - if the two were a pair, it would be possible to extract certain lines from the output vector using SQL queries, based on the attribute uploaded to the table. That would make v.distance even more usefull. Maciek ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=188&aid=319&group_id=21 From mlennert at club.worldonline.be Thu Mar 1 20:23:18 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Thu Mar 1 20:20:36 2007 Subject: [GRASS-dev] ps.map consolidation In-Reply-To: References: Message-ID: <45E72826.5030206@club.worldonline.be> On 01/03/07 18:43, J?chym ?epick? wrote: > Hi, > I started to look into ps.map code and I found few issues, which > should be IMHO solved, so the code looks a bit nicer and the usage is > more consistent. > > It would be great, if somebody more skilled would post some comments > to this topic, I will be very much thankful. No idea about 2), but for the rest: +1 Moritz > > 1) some instructions (raster, setcolor) do not need to end with "end" > keyword, where others do. this should be IMHO consolidated, so that > ALL instructions will need to end with "end" keyword. we should look > into configuration file of mapserver for inspiration > > 2) I think, file session.c can be removed. I did not quite understand, > what is this session management about, but it would make the code a > bit simplier and short test showed, it is working also without it (and > I found no other function, which wuold access functions from > session.c) > > 3) some units are map units by default, where some are percent, some > inches. It would be IMHO great, if the user would have allways to > specify, which units she would like to use (without enything, it would > be map units), example: > > text 30% 100% SPEARFISH SOILS MAP > end > > text 3cm 10cm SPEARFISH SOILS MAP > end > > text 30000.0 20000.04 SPEARFISH SOILS MAP > end > > text 1in 1.5in SPEARFISH SOILS MAP > end > > currently, only some instructions are supporting % > > 4) placenemnt should be allways specified with "where" keyword > 5) text or other value should be allways specified with "value" keyword: > text 650000 7365000 SPEARFISH LAND COVER > end > -> > text > where 650000 7365000 > value SPEARFISH LAND COVER > end > > 6) file (map) names should be allways specified with "name" keyword > > example: > > vlines streams > end > -> > vlines > name streams > end > > this is all for now > > what do you think? > > thanks for your comments > > jachym From glynn at gclements.plus.com Thu Mar 1 22:54:51 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Mar 1 22:54:57 2007 Subject: [GRASS-dev] ps.map consolidation In-Reply-To: References: Message-ID: <17895.19371.41085.718811@cerise.gclements.plus.com> J-B?chym ?epick? wrote:-A > I started to look into ps.map code and I found few issues, which > should be IMHO solved, so the code looks a bit nicer and the usage is > more consistent. > > It would be great, if somebody more skilled would post some comments > to this topic, I will be very much thankful. > > 1) some instructions (raster, setcolor) do not need to end with "end" > keyword, where others do. More precisely, instructions which have options need "end", those which don't have options don't need "end". > this should be IMHO consolidated, so that > ALL instructions will need to end with "end" keyword. While this may be a reasonable idea, it will break existing ps.map scripts. The same goes for most of your other suggestions. If you're going to abandon compatibility, you may as well go all the way, rather than merely tinkering with the syntax and leaving the semantics intact. A better structure, IMHO, would be to execute commands as they are read from the file, rather than simply storing data then generating everything at the end. This would allow multiple items (maps etc) on a page. Most of the commands should simply dump their parameters (or the GRASS data to which they refer) to the output file, leaving as much of the implementation as possible in PostScript. This would allow customisation without needing to recompile anything. -- Glynn Clements From wolf+grass at bergenheim.net Thu Mar 1 23:54:03 2007 From: wolf+grass at bergenheim.net (Wolf Bergenheim) Date: Thu Mar 1 23:54:46 2007 Subject: [GRASS-dev] New feature (algorithm and / or module) to implent to GRASS (long) Message-ID: <45E7598B.7000309@bergenheim.net> Greetings GRASS developers, I'm attending a course in Spatial Data Algorithms (http://www.tkk.fi/Units/Cartography/courses/maa-123340/), and we are supposed to implement one algorithm or data structure we have talked about. I'd like to combine this work with something useful, that is I'd like to give whatever I implement to GRASS. Partially for altruistic reasons, partially because I think that coding within the GRASS environment will make debugging and testing a whole lot easier and more comfortable. Now I'd like to know which algorithm would you like me to implement. Here are some candidates: 1. Label position ================= One of the algorithms we learned about was "A generic Cartographic Labeling Algorithm" by Edmondson, Christensen, Marks and Shrieber published in Cartographica, Vol 33 No. 4, 1996 pp. 13-23. This algorithm of theirs is able to position labels so that they don't overlap and the labels are also placed in as good a place as possible. It can handle line-, point- and area labels. This module would not be a replacement to v.label rather an extension, but it would have to start out as a separate module (to make it possible to grade my work). My plan for this would be to output a label file just like v.label does. After I'm done for school I'd merge this code to be triggered by a flag in v.label. 2. Line generalization or smoothing =================================== A new module which would do line generalization with one of these algorithms *) Douglas-Peuker algorithm *) Reumann-Witkam algorithm *) Lang simplification algorithm *) Cromley's Hierarchical algorithm *) Boyle's forward-looking smoothing algorithm The most famous of these is the Douglas-Peuker algorithm. If you would like me to do this one please also indicate which algorithm you would be most interesting / useful for you. 3. A new simulation/optimization algorithm for least cost path ============================================================== A new module which would calculate the shortest path from a starting point to a destination. It would use Dijkstra's algorithm do find the shortest path in a weighted network. In other words it would treat a cost surface (generated by r.cost) as a network and then calculate the shortest path. This differs from r.drain in that r.drain is a local function, greedy algorithm, whereas this a focal algorithm, that is it takes not only it's immediate location into account, and finds a global shortest path. 4. Shortest path in free (vector) space (avoiding obstacles) ============================================================ This module would take as input a vector map with polygons. These polygons would be treated as obstacles. It would also take a starting and end point as input. It would output a vector map containing the shortest path in free space (this assumes an equal cost surface). There are 2 different ways to do this calculation: a) by building a "road network" with the help of building trapezoids from each corner point of the obstacles. OR b) by building a visibility graph and converting it into a weighted network and running Dijkstra's shortest path on it. ------------------------ If you want more elaboration or have questions on any of the above, please don't hesitate to ask (on or off list). I'd also like to hear any other comments you might have. The time-line for this project is that I will start coding at the latest on week 13 (most probably week 12), and the project will have a demo session on the 26th of April, and must be completed by the 10th of May. Best regards, --Wolf Bergenheim -- <:3 )---- Wolf Bergenheim ----( 8:> From twiens at interbaun.com Fri Mar 2 00:35:15 2007 From: twiens at interbaun.com (Trevor Wiens) Date: Fri Mar 2 00:30:58 2007 Subject: [GRASS-dev] New feature (algorithm and / or module) to implent to GRASS (long) In-Reply-To: <45E7598B.7000309@bergenheim.net> References: <45E7598B.7000309@bergenheim.net> Message-ID: <20070301163515.1a322104@localhost.localdomain> On Fri, 02 Mar 2007 00:54:03 +0200 Wolf Bergenheim wrote: > Greetings GRASS developers, > > I'm attending a course in Spatial Data Algorithms > (http://www.tkk.fi/Units/Cartography/courses/maa-123340/), and we are > supposed to implement one algorithm or data structure we have talked > about. I'd like to combine this work with something useful, that is I'd > like to give whatever I implement to GRASS. Partially for altruistic > reasons, partially because I think that coding within the GRASS > environment will make debugging and testing a whole lot easier and more > comfortable. Now I'd like to know which algorithm would you like me to > implement. Here are some candidates: Get marks and code for GRASS. What a wonderful idea. The options all sound interesting. My personal vote would be for label placement as I see cartography as a major weakness in GRASS and this would lay part of the foundation for better cartography in GRASS. My experience in most systems is that when it comes time for output hours can be wasted in label placement so an algorithm to get one 90% good on that would be a huge time saver for cartographic use. It would be very useful, if it can be written such that it could be used by either v.label, ps.map or perhaps a new interface in the future. In that regard label size in relation to a paper or view size will need to be taken into account. My other choices in order of preference are 4, 3, and 2. In regard to line smoothing I know little about it so I can't state a preference on algorithm and thus it is my last choice. I've not needed this functionality before so I've never researched it. Thanks T > > 1. Label position > ================= > One of the algorithms we learned about was "A generic Cartographic > Labeling Algorithm" by Edmondson, Christensen, Marks and Shrieber > published in Cartographica, Vol 33 No. 4, 1996 pp. 13-23. > > This algorithm of theirs is able to position labels so that they don't > overlap and the labels are also placed in as good a place as possible. > It can handle line-, point- and area labels. > > This module would not be a replacement to v.label rather an extension, > but it would have to start out as a separate module (to make it possible > to grade my work). My plan for this would be to output a label file just > like v.label does. After I'm done for school I'd merge this code to be > triggered by a flag in v.label. > > 2. Line generalization or smoothing > =================================== > A new module which would do line generalization with one of these algorithms > > *) Douglas-Peuker algorithm > *) Reumann-Witkam algorithm > *) Lang simplification algorithm > *) Cromley's Hierarchical algorithm > *) Boyle's forward-looking smoothing algorithm > > The most famous of these is the Douglas-Peuker algorithm. > > If you would like me to do this one please also indicate which algorithm > you would be most interesting / useful for you. > > 3. A new simulation/optimization algorithm for least cost path > ============================================================== > A new module which would calculate the shortest path from a starting > point to a destination. It would use Dijkstra's algorithm do find the > shortest path in a weighted network. In other words it would treat a > cost surface (generated by r.cost) as a network and then calculate the > shortest path. This differs from r.drain in that r.drain is a local > function, greedy algorithm, whereas this a focal algorithm, that is it > takes not only it's immediate location into account, and finds a global > shortest path. > > 4. Shortest path in free (vector) space (avoiding obstacles) > ============================================================ > This module would take as input a vector map with polygons. These > polygons would be treated as obstacles. It would also take a starting > and end point as input. It would output a vector map containing the > shortest path in free space (this assumes an equal cost surface). > There are 2 different ways to do this calculation: > > a) by building a "road network" with the help of building trapezoids > from each corner point of the obstacles. > OR > b) by building a visibility graph and converting it into a weighted > network and running Dijkstra's shortest path on it. > > ------------------------ > > If you want more elaboration or have questions on any of the above, > please don't hesitate to ask (on or off list). I'd also like to hear any > other comments you might have. > > The time-line for this project is that I will start coding at the latest > on week 13 (most probably week 12), and the project will have a demo > session on the 26th of April, and must be completed by the 10th of May. > > Best regards, > --Wolf Bergenheim > > -- > > <:3 )---- Wolf Bergenheim ----( 8:> > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev -- 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 hamish_nospam at yahoo.com Fri Mar 2 06:03:54 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Mar 2 06:04:02 2007 Subject: [GRASS-dev] ps.map consolidation In-Reply-To: References: Message-ID: <20070302180354.5b6fbb6f.hamish_nospam@yahoo.com> J?chym ?epick? wrote: > I started to look into ps.map code and I found few issues, which > should be IMHO solved, so the code looks a bit nicer and the usage is > more consistent. > > It would be great, if somebody more skilled would post some comments > to this topic, I will be very much thankful. > > 1) some instructions (raster, setcolor) do not need to end with "end" > keyword, where others do. this should be IMHO consolidated, so that > ALL instructions will need to end with "end" keyword. we should look > into configuration file of mapserver for inspiration Glynn answered: > More precisely, instructions which have options need "end", those > which don't have options don't need "end". The subinstruction code is never called (it doesn't exist), so the "end" is never considered. It wouldn't be too hard to have main.c skip over any extra "end"s in the control file, but that blurs the (obscure) logic. Jachym: > 2) I think, file session.c can be removed. I did not quite understand, > what is this session management about, but it would make the code a > bit simplier and short test showed, it is working also without it (and > I found no other function, which wuold access functions from > session.c) input() [input.c] calls add_to_session() [session.c] if PostScript level is >0 (???). the reject() fn in session.c is called in a few places. Perhaps this is all for storing input in a tmp file when entering commands in interactive mode or when input is piped from stdin?? It's a case where some comments in the code would have been nice. Looking way back to the GRASS 4.3 source code I see "session" is a KEYword in cmd/main.c (it's in 5.4 as well), but commented out. So it's probably a hold-over from p.map (where it isn't commented out), and safely removed. It's not mentioned in the inter/ versions or help pages, so I'm not sure if my guess for its purpose is correct. Regardless, rip away! > 3) some units are map units by default, where some are percent, some > inches. It would be IMHO great, if the user would have allways to > specify, which units she would like to use (without enything, it would > be map units), example: .. > currently, only some instructions are supporting % Yes, this can be annoying. This is wish # 3335 https://intevation.de/rt/webrt?serial_num=3335 For general purpose commands like placing text on the page I have tried to add placement by all three modes where I could. (or at least allow one of the comments/labels/text commands to get the job done using the reference system needed) There is another inconsistency in that some instructions refer to location on the page (usually in inches; eg legend, mapinfo), while other instructions refer to location in and around the map box (usually in percent or map coordinates; eg rectangle, text). Percentages greater or less than 0-100 are usually ok for placing text elsewhere on the page than in the map box (eg 115% height). So it is not random which commands have inches, and which have {percent or map coordinates}, it just seems like that. :) Presumably any GUI WYSIWYG tool could do all the units conversion math for you when creating the instructions file. (short pain for the GUI programmer, but then invisible) > 4) placenemnt should be allways specified with "where" keyword Careful, "where" is used for vector SQL queries too. > 5) text or other value should be allways specified with "value" > keyword: > 6) file (map) names should be allways specified with "name" keyword These are something that should wait for a full rewrite. Glynn: > While this may be a reasonable idea, it will break existing ps.map > scripts. The same goes for most of your other suggestions. > > If you're going to abandon compatibility, you may as well go all the > way, rather than merely tinkering with the syntax and leaving the > semantics intact. I agree. My plan was to have the new wxPython ps.map GUI worry about all the oddities in the ps.map controls and leave ps.map as it is. It may be odd, but it is fully functional and well tested and that is worth a lot. http://grass.gdf-hannover.de/wiki/GRASS_GUI#Cartography:_GUI_front_end_for_ps.map If you wish to reimplement ps.map, as Glynn says you are best to start over from the beginning and call it ps/ps.something_else. It would be a real pain to have to rewrite years of carefully constructed ps.map templates. Straight GUI -> PostScript, skip C? I understand that it is a pain for writing the GUI to have to deal with the weird ways of ps.map, and I support adding missing % placement to any instruction that currently only takes map coordinates (if any still exist). I'm not so sure about mixing inches with percent (of page), even though this is annonying. Then you mix percent of page vs percent of map box, which is even more confusing. Hamish ps - I found a nice 10 minute Python tutorial [for programmers of other languages] that covers the basics, http://grass.gdf-hannover.de/wiki/GRASS_and_Python#Programming From hamish_nospam at yahoo.com Fri Mar 2 06:40:14 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Mar 2 06:40:34 2007 Subject: [GRASS-dev] Re: g.rename consolidation In-Reply-To: <17894.15890.964915.410863@cerise.gclements.plus.com> References: <45E5CE32.5020007@o2.pl> <17894.1133.67379.749992@cerise.gclements.plus.com> <45E60AA8.2040608@o2.pl> <17894.15890.964915.410863@cerise.gclements.plus.com> Message-ID: <20070302184014.686e1f76.hamish_nospam@yahoo.com> Glynn Clements wrote: > > Just one (I hope ;) ) question more: could I somehow disable > > module's progress output alone, still letting it print it's ERRORs, > > ie. not sending both it's sdout and stderr to /dev/null? > > Currently, no. Supporting e.g. GRASS_MESSAGE_FORMAT=silent would be a > useful enhancement. this little patch adds GRASS_MESSAGE_FORMAT=silent to error.c, but not for G_percent() as then it would need a global variable. Better to just put another getenv("GRASS_MESSAGE_FORMAT") and strcmp(,"silent") in percent.c and clicker.c? Anywhere else? Hamish -------------- next part -------------- Index: include/gis.h =================================================================== RCS file: /home/grass/grassrepository/grass6/include/gis.h,v retrieving revision 1.39 diff -u -r1.39 gis.h --- include/gis.h 18 Dec 2006 11:24:48 -0000 1.39 +++ include/gis.h 2 Mar 2007 05:31:28 -0000 @@ -180,6 +180,7 @@ /* Message format */ #define G_INFO_FORMAT_STANDARD 0 /* GRASS_MESSAGE_FORMAT=standard or not defined */ #define G_INFO_FORMAT_GUI 1 /* GRASS_MESSAGE_FORMAT=gui */ +#define G_INFO_FORMAT_SILENT 2 /* GRASS_MESSAGE_FORMAT=silent */ /* Icon types */ #define G_ICON_CROSS 0 Index: lib/gis/error.c =================================================================== RCS file: /home/grass/grassrepository/grass6/lib/gis/error.c,v retrieving revision 1.15 diff -u -r1.15 error.c --- lib/gis/error.c 22 Feb 2007 10:18:53 -0000 1.15 +++ lib/gis/error.c 2 Mar 2007 05:31:28 -0000 @@ -282,7 +282,8 @@ while (print_word(stderr,&w,&len,lead)) ; - if ( (type != MSG) && isatty(fileno(stderr))) { /* Bell */ + if ( (type != MSG) && isatty(fileno(stderr)) + && (grass_info_format == G_INFO_FORMAT_STANDARD) ) { /* Bell */ fprintf(stderr,"\7"); fflush (stderr); if (!no_sleep) @@ -503,7 +504,9 @@ if ( fstr && G_strcasecmp(fstr,"gui") == 0 ) grass_info_format = G_INFO_FORMAT_GUI; - else + else if ( fstr && G_strcasecmp(fstr,"silent") == 0 ) + grass_info_format = G_INFO_FORMAT_SILENT; + else grass_info_format = G_INFO_FORMAT_STANDARD; } From glynn at gclements.plus.com Fri Mar 2 07:17:47 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Mar 2 07:17:52 2007 Subject: [GRASS-dev] ps.map consolidation In-Reply-To: <20070302180354.5b6fbb6f.hamish_nospam@yahoo.com> References: <20070302180354.5b6fbb6f.hamish_nospam@yahoo.com> Message-ID: <17895.49547.673794.309571@cerise.gclements.plus.com> Hamish wrote: > > 2) I think, file session.c can be removed. I did not quite understand, > > what is this session management about, but it would make the code a > > bit simplier and short test showed, it is working also without it (and > > I found no other function, which wuold access functions from > > session.c) > > input() [input.c] calls add_to_session() [session.c] if PostScript level > is >0 (???). The parameter name is "level", but it doesn't refer to the PostScript language level. -- Glynn Clements From glynn at gclements.plus.com Fri Mar 2 07:21:43 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Mar 2 07:21:44 2007 Subject: [GRASS-dev] Re: g.rename consolidation In-Reply-To: <20070302184014.686e1f76.hamish_nospam@yahoo.com> References: <45E5CE32.5020007@o2.pl> <17894.1133.67379.749992@cerise.gclements.plus.com> <45E60AA8.2040608@o2.pl> <17894.15890.964915.410863@cerise.gclements.plus.com> <20070302184014.686e1f76.hamish_nospam@yahoo.com> Message-ID: <17895.49783.91188.29346@cerise.gclements.plus.com> Hamish wrote: > > > Just one (I hope ;) ) question more: could I somehow disable > > > module's progress output alone, still letting it print it's ERRORs, > > > ie. not sending both it's sdout and stderr to /dev/null? > > > > Currently, no. Supporting e.g. GRASS_MESSAGE_FORMAT=silent would be a > > useful enhancement. > > this little patch adds GRASS_MESSAGE_FORMAT=silent to error.c, but not > for G_percent() as then it would need a global variable. Better to just > put another getenv("GRASS_MESSAGE_FORMAT") and strcmp(,"silent") in > percent.c and clicker.c? Anywhere else? G_percent2() already calls G_info_format(), so it should only need this: --- lib/gis/percent.c 9 Jan 2007 12:30:08 -0000 2.9 +++ lib/gis/percent.c 2 Mar 2007 06:20:47 -0000 @@ -102,7 +102,7 @@ : (int) (100 * n / d); /* be verbose only 1> */ - if (G_verbose() < 1) + if (format == G_INFO_FORMAT_SILENT || G_verbose() < 1) return 0; if (n <= 0 || n >= d || x > prev + s) -- Glynn Clements From glynn at gclements.plus.com Fri Mar 2 08:17:29 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Mar 2 08:17:31 2007 Subject: [GRASS-dev] Re: g.rename consolidation In-Reply-To: <20070302184014.686e1f76.hamish_nospam@yahoo.com> References: <45E5CE32.5020007@o2.pl> <17894.1133.67379.749992@cerise.gclements.plus.com> <45E60AA8.2040608@o2.pl> <17894.15890.964915.410863@cerise.gclements.plus.com> <20070302184014.686e1f76.hamish_nospam@yahoo.com> Message-ID: <17895.53129.132433.607491@cerise.gclements.plus.com> Hamish wrote: > Glynn Clements wrote: > this little patch adds GRASS_MESSAGE_FORMAT=silent to error.c, but not > for G_percent() as then it would need a global variable. Better to just > put another getenv("GRASS_MESSAGE_FORMAT") and strcmp(,"silent") in > percent.c and clicker.c? Anywhere else? > --- lib/gis/error.c 22 Feb 2007 10:18:53 -0000 1.15 > +++ lib/gis/error.c 2 Mar 2007 05:31:28 -0000 > @@ -282,7 +282,8 @@ > while (print_word(stderr,&w,&len,lead)) > ; > > - if ( (type != MSG) && isatty(fileno(stderr))) { /* Bell */ > + if ( (type != MSG) && isatty(fileno(stderr)) > + && (grass_info_format == G_INFO_FORMAT_STANDARD) ) { /* Bell */ This doesn't compile, as grass_info_format is local to G_info_format(). Fix: - && (grass_info_format == G_INFO_FORMAT_STANDARD) ) { /* Bell */ + && (G_info_format() == G_INFO_FORMAT_STANDARD) ) { /* Bell */ Although, technically it shouldn't be printing "\7" without checking the terminal's termcap/terminfo entry. [I'm not suggesting that it should actually do that; making libgis depend upon libtermcap/libtinfo/lib[n]curses would be overkill. Having the occasional ^G in the output is small fry compared to the string of ^H characters from G_percent().] -- Glynn Clements From dca.gis at gmail.com Fri Mar 2 08:59:39 2007 From: dca.gis at gmail.com (Daniel Calvelo) Date: Fri Mar 2 08:59:41 2007 Subject: [GRASS-dev] Re: gis.m, thematic layer: You must open a display monitor In-Reply-To: <1a486f560702130841t438bfd8cw3da47ca1e68e306e@mail.gmail.com> References: <45D1D7CE.7050003@club.worldonline.be> <1a486f560702130841t438bfd8cw3da47ca1e68e306e@mail.gmail.com> Message-ID: <1a486f560703012359u164d3ad6g148f98690d73580@mail.gmail.com> Sorry for the awful delay. I think the problems with d.mon select are resolved; please test. I also made the legend cuts work for ps.map and display managers. In CVS. Daniel. On 2/13/07, Daniel Calvelo wrote: > Hi Michael, Moritz. > > I'll look at it when I get home. That's in about 10 hours. > > Daniel. > > BTW did you try d.vect.thematic for >20 categories? Legends now do > have their nice cut in the middle. > > On 2/13/07, Moritz Lennert wrote: > > On 13/02/07 16:06, Michael Barton wrote: > > > There should be a flag to send output to the gis manager. This flag should > > > cause this conditional to be skipped. > > > > The flag is $GIS_FLAG_S: > > > > On line 860ff you have this: > > # reset rendering for GUI use > > if [ "$GIS_FLAG_S" -eq 1 ] ; then > > [...] > > d.mon select=$currmon > > [...] > > fi > > > > In my understanding, unless someone works in parallel with GIS Manager > > and x-mons, $currmon will be empty and this is where this error message > > comes from. > > > > Maybe it's just a problem of an unequal number of if and fi calls... > > > > But I don't have the time to go into the file in detail now...sorry. > > > > Moritz > > > > > > > > > > Michael > > > > > > > > > On 2/13/07 7:58 AM, "Moritz Lennert" wrote: > > > > > >> On 13/02/07 15:29, Michael Barton wrote: > > >>> I have no idea. Perhaps I'm imagining things, but I swear that I'm seeing a > > >>> LOT more of these messages recently--with their deleterious effects on > > >>> scripting. Hamish says they've been there all along. I'm suspecting that the > > >>> code for the message has existed, but they did not get parsed for some > > >>> reason. But that is just speculation. > > >> Well in this case, there is a change by Daniel dated Jan. 28 which might > > >> be linked: > > >> > > >> - Added quotes in occurences of 'if [ -z "$var" ]' > > >> > > >> But reverting back to no quotes gives the same error message. > > >> > > >> Looking at the logic, I don't actually understand how this worked > > >> before. As I said, IIUC the x-mon test seems to be done whether you are > > >> using GIS Manager or not. But under GIS Manager there should be no x-mon... > > >> > > >> Conditonalising the check as follows: > > >> > > >> if [ "$GIS_FLAG_S" -eq 0 ] ; then > > >> if [ -z "$currmon" ] ; then > > >> echo "" > > >> echo "*** You must open a display monitor ***" > > >> echo "" > > >> cleanup > > >> exit 2 > > >> fi > > >> fi > > >> > > >> makes the error message go away, but I get a new one: > > >> > > >> Usage: /usr/lib/grass/etc/mon.select monitor_name > > >> > > >> This time, however, the map and legend are displayed correctly (without > > >> the "fix" only the legend is displayed). I can get this second error > > >> message to go away by commenting line 862: > > >> > > >> # d.mon select=$currmon > > >> > > >> This comes from the fact that $currmon is empty in GIS Manager. Again, I > > >> don't understand why we have to deal with d.mon here if we are in the > > >> GIS Manager...and why this did not cause any problems before. > > >> > > >> Moritz > > >> > > >> > > >>> Michael > > >>> > > >>> > > >>> On 2/13/07 6:19 AM, "Moritz Lennert" wrote: > > >>> > > >>>> Michael, > > >>>> > > >>>> I am seeing a new error for d.vect.thematic. Trying to display a > > >>>> thematic layer fails with the message: *** You must open a display > > >>>> monitor *** > > >>>> > > >>>> I can reproduce this with any spearfish vector layer. > > >>>> > > >>>> The problem seems to be in lines 336-345 where it checks for the > > >>>> existance of an x-monitor. It seems to do this unconditionally, so even > > >>>> if you run it from the GIS Manager it still checks and fails if there is > > >>>> not monitor. > > >>>> > > >>>> I can't find anything recent in the commit logs that would explain this, > > >>>> so before trying to go deeper into it, I wanted to know if you had an > > >>>> idea why this is suddenly happening. > > >>>> > > >>>> Moritz > > >>> __________________________________________ > > >>> Michael Barton, Professor of Anthropology > > >>> School of Human Evolution & Social Change > > >>> Center for Social Dynamics & Complexity > > >>> Arizona State University > > >>> > > >>> phone: 480-965-6213 > > >>> fax: 480-965-7671 > > >>> www: http://www.public.asu.edu/~cmbarton > > >>> > > >>> > > > > > > __________________________________________ > > > 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 > > > > > > > > > > > > > -- > -- Daniel Calvelo Aros > -- -- Daniel Calvelo Aros From mlennert at club.worldonline.be Fri Mar 2 10:02:56 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Fri Mar 2 10:00:32 2007 Subject: [GRASS-dev] Re: gis.m, thematic layer: You must open a display monitor In-Reply-To: <1a486f560703012359u164d3ad6g148f98690d73580@mail.gmail.com> References: <45D1D7CE.7050003@club.worldonline.be> <1a486f560702130841t438bfd8cw3da47ca1e68e306e@mail.gmail.com> <1a486f560703012359u164d3ad6g148f98690d73580@mail.gmail.com> Message-ID: <45E7E840.6020803@club.worldonline.be> On 02/03/07 08:59, Daniel Calvelo wrote: > Sorry for the awful delay. I think the problems with d.mon select are > resolved; please test. I also made the legend cuts work for ps.map and > display managers. In CVS. I get the following error. The line format [G_msg "Legend for Map %d, %s"] $mon, $opt($id,1,map) seems to be the problem. Moritz expected integer but got "1," expected integer but got "1," while executing "format [G_msg "Legend for Map %d, %s"] $mon, $opt($id,1,map)" (procedure "GmThematic::tlegend" line 11) invoked from within "GmThematic::tlegend $mon $id" (procedure "GmThematic::display" line 72) invoked from within "GmThematic::display $node $mod" ("thematic" arm line 2) invoked from within "switch $type { group { GmGroup::display $node $mod } raster { GmRaster::display $node $mod } labels { GmLabels::disp..." (procedure "GmTree::display_node" line 7) invoked from within "GmTree::display_node $n $mod" (procedure "GmGroup::display" line 22) invoked from within "GmGroup::display "root" $mod" (procedure "MapCanvas::runprograms" line 64) invoked from within "MapCanvas::runprograms $mon [expr {$mymodified != 0}]" (procedure "MapCanvas::drawmap" line 38) invoked from within "MapCanvas::drawmap $mon" (procedure "MapCanvas::display_server" line 9) invoked from within "MapCanvas::display_server" ("after" script) > > Daniel. > > On 2/13/07, Daniel Calvelo wrote: >> Hi Michael, Moritz. >> >> I'll look at it when I get home. That's in about 10 hours. >> >> Daniel. >> >> BTW did you try d.vect.thematic for >20 categories? Legends now do >> have their nice cut in the middle. >> >> On 2/13/07, Moritz Lennert wrote: >> > On 13/02/07 16:06, Michael Barton wrote: >> > > There should be a flag to send output to the gis manager. This >> flag should >> > > cause this conditional to be skipped. >> > >> > The flag is $GIS_FLAG_S: >> > >> > On line 860ff you have this: >> > # reset rendering for GUI use >> > if [ "$GIS_FLAG_S" -eq 1 ] ; then >> > [...] >> > d.mon select=$currmon >> > [...] >> > fi >> > >> > In my understanding, unless someone works in parallel with GIS Manager >> > and x-mons, $currmon will be empty and this is where this error message >> > comes from. >> > >> > Maybe it's just a problem of an unequal number of if and fi calls... >> > >> > But I don't have the time to go into the file in detail now...sorry. >> > >> > Moritz >> > >> > >> > > >> > > Michael >> > > >> > > >> > > On 2/13/07 7:58 AM, "Moritz Lennert" >> wrote: >> > > >> > >> On 13/02/07 15:29, Michael Barton wrote: >> > >>> I have no idea. Perhaps I'm imagining things, but I swear that >> I'm seeing a >> > >>> LOT more of these messages recently--with their deleterious >> effects on >> > >>> scripting. Hamish says they've been there all along. I'm >> suspecting that the >> > >>> code for the message has existed, but they did not get parsed >> for some >> > >>> reason. But that is just speculation. >> > >> Well in this case, there is a change by Daniel dated Jan. 28 >> which might >> > >> be linked: >> > >> >> > >> - Added quotes in occurences of 'if [ -z "$var" ]' >> > >> >> > >> But reverting back to no quotes gives the same error message. >> > >> >> > >> Looking at the logic, I don't actually understand how this worked >> > >> before. As I said, IIUC the x-mon test seems to be done whether >> you are >> > >> using GIS Manager or not. But under GIS Manager there should be >> no x-mon... >> > >> >> > >> Conditonalising the check as follows: >> > >> >> > >> if [ "$GIS_FLAG_S" -eq 0 ] ; then >> > >> if [ -z "$currmon" ] ; then >> > >> echo "" >> > >> echo "*** You must open a display monitor ***" >> > >> echo "" >> > >> cleanup >> > >> exit 2 >> > >> fi >> > >> fi >> > >> >> > >> makes the error message go away, but I get a new one: >> > >> >> > >> Usage: /usr/lib/grass/etc/mon.select monitor_name >> > >> >> > >> This time, however, the map and legend are displayed correctly >> (without >> > >> the "fix" only the legend is displayed). I can get this second error >> > >> message to go away by commenting line 862: >> > >> >> > >> # d.mon select=$currmon >> > >> >> > >> This comes from the fact that $currmon is empty in GIS Manager. >> Again, I >> > >> don't understand why we have to deal with d.mon here if we are in >> the >> > >> GIS Manager...and why this did not cause any problems before. >> > >> >> > >> Moritz >> > >> >> > >> >> > >>> Michael >> > >>> >> > >>> >> > >>> On 2/13/07 6:19 AM, "Moritz Lennert" >> wrote: >> > >>> >> > >>>> Michael, >> > >>>> >> > >>>> I am seeing a new error for d.vect.thematic. Trying to display a >> > >>>> thematic layer fails with the message: *** You must open a display >> > >>>> monitor *** >> > >>>> >> > >>>> I can reproduce this with any spearfish vector layer. >> > >>>> >> > >>>> The problem seems to be in lines 336-345 where it checks for the >> > >>>> existance of an x-monitor. It seems to do this unconditionally, >> so even >> > >>>> if you run it from the GIS Manager it still checks and fails if >> there is >> > >>>> not monitor. >> > >>>> >> > >>>> I can't find anything recent in the commit logs that would >> explain this, >> > >>>> so before trying to go deeper into it, I wanted to know if you >> had an >> > >>>> idea why this is suddenly happening. >> > >>>> >> > >>>> Moritz >> > >>> __________________________________________ >> > >>> Michael Barton, Professor of Anthropology >> > >>> School of Human Evolution & Social Change >> > >>> Center for Social Dynamics & Complexity >> > >>> Arizona State University >> > >>> >> > >>> phone: 480-965-6213 >> > >>> fax: 480-965-7671 >> > >>> www: http://www.public.asu.edu/~cmbarton >> > >>> >> > >>> >> > > >> > > __________________________________________ >> > > 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 >> > > >> > > >> > >> > >> >> >> -- >> -- Daniel Calvelo Aros >> > > From maris.gis at gmail.com Fri Mar 2 10:42:15 2007 From: maris.gis at gmail.com (Maris Nartiss) Date: Fri Mar 2 10:42:17 2007 Subject: [GRASS-dev] Re: gis.m, thematic layer: You must open a display monitor In-Reply-To: <45E7E840.6020803@club.worldonline.be> References: <45D1D7CE.7050003@club.worldonline.be> <1a486f560702130841t438bfd8cw3da47ca1e68e306e@mail.gmail.com> <1a486f560703012359u164d3ad6g148f98690d73580@mail.gmail.com> <45E7E840.6020803@club.worldonline.be> Message-ID: <2b3d8c1c0703020142s5c37dedsd1b82711266261e8@mail.gmail.com> Sorry, copy-paste introduced typo by me. Attached patch should fix problem. Please, test and commit. Maris. 2007/3/2, Moritz Lennert : > On 02/03/07 08:59, Daniel Calvelo wrote: > > Sorry for the awful delay. I think the problems with d.mon select are > > resolved; please test. I also made the legend cuts work for ps.map and > > display managers. In CVS. > > I get the following error. The line > > format [G_msg "Legend for Map %d, %s"] $mon, $opt($id,1,map) > > seems to be the problem. > > > Moritz > > > expected integer but got "1," > expected integer but got "1," > while executing > "format [G_msg "Legend for Map %d, %s"] $mon, $opt($id,1,map)" > (procedure "GmThematic::tlegend" line 11) > invoked from within > "GmThematic::tlegend $mon $id" > (procedure "GmThematic::display" line 72) > invoked from within > "GmThematic::display $node $mod" > ("thematic" arm line 2) > invoked from within > "switch $type { > group { > GmGroup::display $node $mod > } > raster { > GmRaster::display $node $mod > } > labels { > GmLabels::disp..." > (procedure "GmTree::display_node" line 7) > invoked from within > "GmTree::display_node $n $mod" > (procedure "GmGroup::display" line 22) > invoked from within > "GmGroup::display "root" $mod" > (procedure "MapCanvas::runprograms" line 64) > invoked from within > "MapCanvas::runprograms $mon [expr {$mymodified != 0}]" > (procedure "MapCanvas::drawmap" line 38) > invoked from within > "MapCanvas::drawmap $mon" > (procedure "MapCanvas::display_server" line 9) > invoked from within > "MapCanvas::display_server" > ("after" script) > > -------------- next part -------------- A non-text attachment was scrubbed... Name: thematic.typo.patch Type: text/x-diff Size: 674 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070302/ffa23fee/thematic.typo-0001.bin From bernhard at intevation.de Fri Mar 2 10:57:51 2007 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri Mar 2 10:58:02 2007 Subject: [GRASS-dev] issue tracking, rt (was: [bug #5504] (grass)) In-Reply-To: <45E70104.3010809@o2.pl> References: <20070224221914.164F01006A2@lists.intevation.de> <200703010946.44927.bernhard@intevation.de> <45E70104.3010809@o2.pl> Message-ID: <200703021057.52816.bernhard@intevation.de> On Thursday 01 March 2007 17:36, Maciej Sieczka wrote: > Bernhard Reiter wrote: > > On Wednesday 28 February 2007 20:03, Maciej Sieczka wrote: > > we switched this off on Tuesday and one of Intevation's admin > > has send an email to you on this day. > > I didn't receive that email. I don't use a spam filter. It must have > get lost in between somewhere. > > > Registered users with manipulation rights can still open issues, > > which I think is okay. > > Perfect, thanks. > > > We probably cannot change this anyway. > > No need to. > > > So there is a remote chance that spammers hit the right address. > Could you explain how exactly? I suspect that if they use a forged from address from somebody that is a registered user, they can still send something to the tracker. I did not checked if this is a real attack vector. The chances for this a quite low compared to other spam hits, so I do not think we should spend much energy on it. Best, Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070302/0dace0b2/attachment.bin From mlennert at club.worldonline.be Fri Mar 2 11:20:37 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Fri Mar 2 11:17:54 2007 Subject: [GRASS-dev] Re: gis.m, thematic layer: You must open a display monitor In-Reply-To: <2b3d8c1c0703020142s5c37dedsd1b82711266261e8@mail.gmail.com> References: <45D1D7CE.7050003@club.worldonline.be> <1a486f560702130841t438bfd8cw3da47ca1e68e306e@mail.gmail.com> <1a486f560703012359u164d3ad6g148f98690d73580@mail.gmail.com> <45E7E840.6020803@club.worldonline.be> <2b3d8c1c0703020142s5c37dedsd1b82711266261e8@mail.gmail.com> Message-ID: <45E7FA75.3010905@club.worldonline.be> On 02/03/07 10:42, Maris Nartiss wrote: > Sorry, copy-paste introduced typo by me. Attached patch should fix > problem. Please, test and commit. Thanks, that was it. Committed to CVS. Moritz > > Maris. > > 2007/3/2, Moritz Lennert : >> On 02/03/07 08:59, Daniel Calvelo wrote: >> > Sorry for the awful delay. I think the problems with d.mon select are >> > resolved; please test. I also made the legend cuts work for ps.map and >> > display managers. In CVS. >> >> I get the following error. The line >> >> format [G_msg "Legend for Map %d, %s"] $mon, $opt($id,1,map) >> >> seems to be the problem. >> >> >> Moritz >> >> >> expected integer but got "1," >> expected integer but got "1," >> while executing >> "format [G_msg "Legend for Map %d, %s"] $mon, $opt($id,1,map)" >> (procedure "GmThematic::tlegend" line 11) >> invoked from within >> "GmThematic::tlegend $mon $id" >> (procedure "GmThematic::display" line 72) >> invoked from within >> "GmThematic::display $node $mod" >> ("thematic" arm line 2) >> invoked from within >> "switch $type { >> group { >> GmGroup::display $node $mod >> } >> raster { >> GmRaster::display $node $mod >> } >> labels { >> GmLabels::disp..." >> (procedure "GmTree::display_node" line 7) >> invoked from within >> "GmTree::display_node $n $mod" >> (procedure "GmGroup::display" line 22) >> invoked from within >> "GmGroup::display "root" $mod" >> (procedure "MapCanvas::runprograms" line 64) >> invoked from within >> "MapCanvas::runprograms $mon [expr {$mymodified != 0}]" >> (procedure "MapCanvas::drawmap" line 38) >> invoked from within >> "MapCanvas::drawmap $mon" >> (procedure "MapCanvas::display_server" line 9) >> invoked from within >> "MapCanvas::display_server" >> ("after" script) >> >> > > ------------------------------------------------------------------------ > > Index: gui/tcltk/gis.m/thematic.tcl > =================================================================== > RCS file: /home/grass/grassrepository/grass6/gui/tcltk/gis.m/thematic.tcl,v > retrieving revision 1.25 > diff -u -u -r1.25 thematic.tcl > --- gui/tcltk/gis.m/thematic.tcl 22 Feb 2007 15:45:29 -0000 1.25 > +++ gui/tcltk/gis.m/thematic.tcl 2 Mar 2007 09:39:41 -0000 > @@ -619,7 +619,7 @@ > > if { [winfo exists .tlegend($mon,$id)] } {return} > > - set legendtitle [format [G_msg "Legend for Map %d, %s"] $mon, $opt($id,1,map)] > + set legendtitle [format [G_msg "Legend for Map %d, %s"] $mon $opt($id,1,map)] > toplevel .tlegend($mon,$id) > wm title .tlegend($mon,$id) $legendtitle > From landa.martin at gmail.com Fri Mar 2 15:13:11 2007 From: landa.martin at gmail.com (Martin Landa) Date: Fri Mar 2 15:13:13 2007 Subject: [GRASS-dev] New feature (algorithm and / or module) to implent to GRASS (long) In-Reply-To: <45E7598B.7000309@bergenheim.net> References: <45E7598B.7000309@bergenheim.net> Message-ID: Hi, 2007/3/1, Wolf Bergenheim : [snip] > 1. Label position > ================= > One of the algorithms we learned about was "A generic Cartographic > Labeling Algorithm" by Edmondson, Christensen, Marks and Shrieber > published in Cartographica, Vol 33 No. 4, 1996 pp. 13-23. > > This algorithm of theirs is able to position labels so that they don't > overlap and the labels are also placed in as good a place as possible. > It can handle line-, point- and area labels. > > This module would not be a replacement to v.label rather an extension, > but it would have to start out as a separate module (to make it possible > to grade my work). My plan for this would be to output a label file just > like v.label does. After I'm done for school I'd merge this code to be > triggered by a flag in v.label. +1 [snip] Regards, Martin -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From jachym.cepicky at gmail.com Fri Mar 2 15:49:09 2007 From: jachym.cepicky at gmail.com (=?ISO-8859-2?Q?J=E1chym_=C8epick=FD?=) Date: Fri Mar 2 15:49:12 2007 Subject: [GRASS-dev] ps.map consolidation In-Reply-To: <20070302180354.5b6fbb6f.hamish_nospam@yahoo.com> References: <20070302180354.5b6fbb6f.hamish_nospam@yahoo.com> Message-ID: Thanks for the comments. I was suggesting this changes to make live of GUI coder easier :) another point: How to write GUI for ps.map, so it is usable for the user. Several approaches are possible: Drawing boxes for legend, measure, text and so on, so the user has at least idea about where and how the object will be placed on the paper. Another sollution would be, if we would copy the map display approach: render separate layer for each map instruction in the temporary file and put them together in the map display. User could than take a mouse and position each object interactively. We would need support of transparency for this... Does ps.map support creation of transparent files? Is the layer approach the one, we should use? Jachym 2007/3/2, Hamish : > J?chym ?epick? wrote: > > I started to look into ps.map code and I found few issues, which > > should be IMHO solved, so the code looks a bit nicer and the usage is > > more consistent. > > > > It would be great, if somebody more skilled would post some comments > > to this topic, I will be very much thankful. > > > > 1) some instructions (raster, setcolor) do not need to end with "end" > > keyword, where others do. this should be IMHO consolidated, so that > > ALL instructions will need to end with "end" keyword. we should look > > into configuration file of mapserver for inspiration > > Glynn answered: > > More precisely, instructions which have options need "end", those > > which don't have options don't need "end". > > The subinstruction code is never called (it doesn't exist), so the > "end" is never considered. It wouldn't be too hard to have main.c skip > over any extra "end"s in the control file, but that blurs the (obscure) > logic. > > Jachym: > > 2) I think, file session.c can be removed. I did not quite understand, > > what is this session management about, but it would make the code a > > bit simplier and short test showed, it is working also without it (and > > I found no other function, which wuold access functions from > > session.c) > > input() [input.c] calls add_to_session() [session.c] if PostScript level > is >0 (???). the reject() fn in session.c is called in a few places. > Perhaps this is all for storing input in a tmp file when entering > commands in interactive mode or when input is piped from stdin?? > It's a case where some comments in the code would have been nice. > > Looking way back to the GRASS 4.3 source code I see "session" is a > KEYword in cmd/main.c (it's in 5.4 as well), but commented out. So it's > probably a hold-over from p.map (where it isn't commented out), and > safely removed. It's not mentioned in the inter/ versions or help pages, > so I'm not sure if my guess for its purpose is correct. Regardless, rip > away! > > > > 3) some units are map units by default, where some are percent, some > > inches. It would be IMHO great, if the user would have allways to > > specify, which units she would like to use (without enything, it would > > be map units), example: > .. > > currently, only some instructions are supporting % > > Yes, this can be annoying. This is wish # 3335 > https://intevation.de/rt/webrt?serial_num=3335 > > For general purpose commands like placing text on the page I have tried > to add placement by all three modes where I could. (or at least allow > one of the comments/labels/text commands to get the job done using the > reference system needed) > > There is another inconsistency in that some instructions refer to > location on the page (usually in inches; eg legend, mapinfo), while > other instructions refer to location in and around the map box (usually > in percent or map coordinates; eg rectangle, text). Percentages greater > or less than 0-100 are usually ok for placing text elsewhere on the page > than in the map box (eg 115% height). > > So it is not random which commands have inches, and which have {percent > or map coordinates}, it just seems like that. :) > > Presumably any GUI WYSIWYG tool could do all the units conversion math > for you when creating the instructions file. (short pain for the GUI > programmer, but then invisible) > > > > 4) placenemnt should be allways specified with "where" keyword > > Careful, "where" is used for vector SQL queries too. > > > 5) text or other value should be allways specified with "value" > > keyword: > > 6) file (map) names should be allways specified with "name" keyword > > These are something that should wait for a full rewrite. > > > Glynn: > > While this may be a reasonable idea, it will break existing ps.map > > scripts. The same goes for most of your other suggestions. > > > > If you're going to abandon compatibility, you may as well go all the > > way, rather than merely tinkering with the syntax and leaving the > > semantics intact. > > I agree. My plan was to have the new wxPython ps.map GUI worry about all > the oddities in the ps.map controls and leave ps.map as it is. It may > be odd, but it is fully functional and well tested and that is worth a > lot. > > http://grass.gdf-hannover.de/wiki/GRASS_GUI#Cartography:_GUI_front_end_for_ps.map > > If you wish to reimplement ps.map, as Glynn says you are best to start > over from the beginning and call it ps/ps.something_else. It would be > a real pain to have to rewrite years of carefully constructed ps.map > templates. Straight GUI -> PostScript, skip C? > > I understand that it is a pain for writing the GUI to have to deal with > the weird ways of ps.map, and I support adding missing % placement to > any instruction that currently only takes map coordinates (if any still > exist). I'm not so sure about mixing inches with percent (of page), even > though this is annonying. Then you mix percent of page vs percent of map > box, which is even more confusing. > > > Hamish > > ps - I found a nice 10 minute Python tutorial [for programmers of other > languages] that covers the basics, > http://grass.gdf-hannover.de/wiki/GRASS_and_Python#Programming > -- Jachym Cepicky e-mail: jachym.cepicky gmail com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub From michael.barton at asu.edu Fri Mar 2 17:06:11 2007 From: michael.barton at asu.edu (Michael Barton) Date: Fri Mar 2 17:06:33 2007 Subject: [GRASS-dev] Re: gis.m, thematic layer: You must open a display monitor In-Reply-To: <45E7FA75.3010905@club.worldonline.be> Message-ID: Thanks much Moritz Michael On 3/2/07 3:20 AM, "Moritz Lennert" wrote: > On 02/03/07 10:42, Maris Nartiss wrote: >> Sorry, copy-paste introduced typo by me. Attached patch should fix >> problem. Please, test and commit. > > Thanks, that was it. > Committed to CVS. > > Moritz > >> >> Maris. >> >> 2007/3/2, Moritz Lennert : >>> On 02/03/07 08:59, Daniel Calvelo wrote: >>>> Sorry for the awful delay. I think the problems with d.mon select are >>>> resolved; please test. I also made the legend cuts work for ps.map and >>>> display managers. In CVS. >>> >>> I get the following error. The line >>> >>> format [G_msg "Legend for Map %d, %s"] $mon, $opt($id,1,map) >>> >>> seems to be the problem. >>> >>> >>> Moritz >>> >>> >>> expected integer but got "1," >>> expected integer but got "1," >>> while executing >>> "format [G_msg "Legend for Map %d, %s"] $mon, $opt($id,1,map)" >>> (procedure "GmThematic::tlegend" line 11) >>> invoked from within >>> "GmThematic::tlegend $mon $id" >>> (procedure "GmThematic::display" line 72) >>> invoked from within >>> "GmThematic::display $node $mod" >>> ("thematic" arm line 2) >>> invoked from within >>> "switch $type { >>> group { >>> GmGroup::display $node $mod >>> } >>> raster { >>> GmRaster::display $node $mod >>> } >>> labels { >>> GmLabels::disp..." >>> (procedure "GmTree::display_node" line 7) >>> invoked from within >>> "GmTree::display_node $n $mod" >>> (procedure "GmGroup::display" line 22) >>> invoked from within >>> "GmGroup::display "root" $mod" >>> (procedure "MapCanvas::runprograms" line 64) >>> invoked from within >>> "MapCanvas::runprograms $mon [expr {$mymodified != 0}]" >>> (procedure "MapCanvas::drawmap" line 38) >>> invoked from within >>> "MapCanvas::drawmap $mon" >>> (procedure "MapCanvas::display_server" line 9) >>> invoked from within >>> "MapCanvas::display_server" >>> ("after" script) >>> >>> >> >> ------------------------------------------------------------------------ >> >> Index: gui/tcltk/gis.m/thematic.tcl >> =================================================================== >> RCS file: /home/grass/grassrepository/grass6/gui/tcltk/gis.m/thematic.tcl,v >> retrieving revision 1.25 >> diff -u -u -r1.25 thematic.tcl >> --- gui/tcltk/gis.m/thematic.tcl 22 Feb 2007 15:45:29 -0000 1.25 >> +++ gui/tcltk/gis.m/thematic.tcl 2 Mar 2007 09:39:41 -0000 >> @@ -619,7 +619,7 @@ >> >> if { [winfo exists .tlegend($mon,$id)] } {return} >> >> - set legendtitle [format [G_msg "Legend for Map %d, %s"] $mon, >> $opt($id,1,map)] >> + set legendtitle [format [G_msg "Legend for Map %d, %s"] $mon >> $opt($id,1,map)] >> toplevel .tlegend($mon,$id) >> wm title .tlegend($mon,$id) $legendtitle >> > __________________________________________ 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 peter_7003 at yahoo.com Fri Mar 2 17:39:54 2007 From: peter_7003 at yahoo.com (Peter Fischer) Date: Fri Mar 2 17:39:57 2007 Subject: [GRASS-dev] GRASS general abilities Message-ID: <344534.66686.qm@web62015.mail.re1.yahoo.com> Hello, I have some general questions about what ones can do with GRASS and what not. I am not sure whether there is a viewer available to realize the following funtionality in conjunction with GRASS: I want to visualize realtime data (moving objects) over a map. Ideally it would be possible to have a perspective view of the map like Google Earth or World Wind. Furthermore, it would be nice to be able to select an object on the map (e.g. a building) and to show it from the side in 3D (using OpenGL or sth. like that) in a separate window. Therefore it should be possible to store such 3D information (e.g. of the buildings) in a way to allow to extract the 3D model (based on the coordinates on the map when it is selected) and to feed it into the 3D viewer. So here are my questions in more detail: Is it possible to 1. get the current camera view via asynchronous events every time the view changes? Or do I have to solve that with a polling mechanism? - Do you have some sample code doing this, preferably in python? 2. display moving overlays 3. display movements and directions of 3D Objects in realtime, e.g. 10 fps? 4. doing all this using a scripting language like python? 5. doing this using standard protocols like TCP/IP or HTTP? 6. platform independent (OSes Linux, MacOS, Windows)? 7. extend the funtionality via plugins? 8. licensing conditions, GPL or sth. like that and having to disclose my code? 9. support for special input hardware like spacemouse, joystick etc? 10. Is there an API? 11. What is the resolution for regions like Europe (meters/pixel)? - What is the best available and what does it cost? You would greatly help me in answering a part of if not all questions (which would be awesome!) since I try to figure out whether GRASS is suitable for a medium sized research project I am working on. So if anyone could answer, many thanks in advance and best greetings. --------------------------------- Don't be flakey. Get Yahoo! Mail for Mobile and always stay connected to friends. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070302/0214a8fa/attachment-0001.html From epatton at nrcan.gc.ca Fri Mar 2 19:48:34 2007 From: epatton at nrcan.gc.ca (Patton, Eric) Date: Fri Mar 2 19:48:38 2007 Subject: [GRASS-dev] New feature (algorithm and / or module) to implentto GRASS (long) In-Reply-To: <20070301163515.1a322104@localhost.localdomain> References: <45E7598B.7000309@bergenheim.net> <20070301163515.1a322104@localhost.localdomain> Message-ID: Wolf, I agree 100% with Trevor; label placement is critical for my work, and always had to be done in Arc to achieve the desired level of control. I don't have any preference amongst the other three options, as I never have need of this functionality in my work. Whatever your decision, thanks for offering to improve Grass functionality! Cheers, -- Eric Patton email: epatton@nrcan.gc.ca > -----Original Message----- > From: grass-dev-bounces@grass.itc.it > [mailto:grass-dev-bounces@grass.itc.it] On Behalf Of Trevor Wiens > Sent: Thursday, March 01, 2007 7:35 PM > To: Wolf Bergenheim > Cc: GRASS developers list > Subject: Re: [GRASS-dev] New feature (algorithm and / or > module) to implentto GRASS (long) > Get marks and code for GRASS. What a wonderful idea. > > The options all sound interesting. My personal vote would be > for label placement as I see cartography as a major weakness > in GRASS and this would lay part of the foundation for better > cartography in GRASS. My experience in most systems is that > when it comes time for output hours can be wasted in label > placement so an algorithm to get one 90% good on that would > be a huge time saver for cartographic use. It would be very > useful, if it can be written such that it could be used by > either v.label, ps.map or perhaps a new interface in the > future. In that regard label size in relation to a paper or > view size will need to be taken into account. > > My other choices in order of preference are 4, 3, and 2. In > regard to line smoothing I know little about it so I can't > state a preference on algorithm and thus it is my last > choice. I've not needed this functionality before so I've > never researched it. > > Thanks > > Trevor From glynn at gclements.plus.com Fri Mar 2 22:46:28 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Mar 2 22:46:34 2007 Subject: [GRASS-dev] ps.map consolidation In-Reply-To: References: <20070302180354.5b6fbb6f.hamish_nospam@yahoo.com> Message-ID: <17896.39732.895359.20874@cerise.gclements.plus.com> J-B?chym ?epick? wrote:-A > another point: How to write GUI for ps.map, so it is usable for the > user. Several approaches are possible: > > Drawing boxes for legend, measure, text and so on, so the user has at > least idea about where and how the object will be placed on the paper. > > Another sollution would be, if we would copy the map display approach: > render separate layer for each map instruction in the temporary file > and put them together in the map display. User could than take a mouse > and position each object interactively. > > We would need support of transparency for this... Does ps.map support > creation of transparent files? ps.map creates PostScript files. If you use Ghostscript's "pngalpha" driver, the resulting PNG file will have a transparent background. But then you would need to convert the PNG files to PPM/PGM (that's all that g.pnmcomp understands), and you would need to manually re-composite those files whenever the relative position changes. Personally, I don't see the point in a ps.map GUI; this task is better suited to general-purpose DTP software. -- Glynn Clements From roger at spinn.net Fri Mar 2 23:25:06 2007 From: roger at spinn.net (roger@spinn.net) Date: Fri Mar 2 23:25:42 2007 Subject: [GRASS-dev] ps.map consolidation In-Reply-To: <17896.39732.895359.20874@cerise.gclements.plus.com> References: <20070302180354.5b6fbb6f.hamish_nospam@yahoo.com> <17896.39732.895359.20874@cerise.gclements.plus.com> Message-ID: <200703022225.l22MP6Ws064520@smtp.spinn.net> I have a rudimentary GUI for ps.map written as a TCL/TK script. It works by reading the content of the monitor and using that content to construct a basic input file for ps.map. The GUI (which, as I said is pretty rudimentary) allows the user to view and edit instructions in the input file, to insert elements like eps files and to use options like line styles that aren't supported on the GRASS monitor. It uses xpdf a previewer. xpdf is fairly fast and has a remote server mode that allows the user to update the preview without restarting the viewer. It is distributed under the GNU public license by Glyph and Cog, LLC ; http://www.foolabs.com/xpdf/home.html The grass developers may not want to introduce a dependency on xpdf, but I encourage you to do something to give ps.map a friendlier front end. The benefit is tremendous. Having even a simple interactive ability to develop better graphics within the grass environment improved the quality of my products and decreased the time necessary to produce them. Roger Miller Glynn Clements writes: > > J-B?chym ?epick? wrote:-A > >> another point: How to write GUI for ps.map, so it is usable for the >> user. Several approaches are possible: >> >> Drawing boxes for legend, measure, text and so on, so the user has at >> least idea about where and how the object will be placed on the paper. >> >> Another sollution would be, if we would copy the map display approach: >> render separate layer for each map instruction in the temporary file >> and put them together in the map display. User could than take a mouse >> and position each object interactively. >> >> We would need support of transparency for this... Does ps.map support >> creation of transparent files? > > ps.map creates PostScript files. If you use Ghostscript's "pngalpha" > driver, the resulting PNG file will have a transparent background. But > then you would need to convert the PNG files to PPM/PGM (that's all > that g.pnmcomp understands), and you would need to manually > re-composite those files whenever the relative position changes. > > Personally, I don't see the point in a ps.map GUI; this task is better > suited to general-purpose DTP software. > > -- > Glynn Clements > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From michael.barton at asu.edu Sat Mar 3 07:41:52 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sat Mar 3 07:42:04 2007 Subject: [GRASS-dev] New feature (algorithm and / or module) to implent to GRASS (long) In-Reply-To: <20070301163515.1a322104@localhost.localdomain> Message-ID: I agree with Trevor about the #1 priority (i.e., labeling). I need to mull over the other options. Michael On 3/1/07 4:35 PM, "Trevor Wiens" wrote: > On Fri, 02 Mar 2007 00:54:03 +0200 > Wolf Bergenheim wrote: > >> Greetings GRASS developers, >> >> I'm attending a course in Spatial Data Algorithms >> (http://www.tkk.fi/Units/Cartography/courses/maa-123340/), and we are >> supposed to implement one algorithm or data structure we have talked >> about. I'd like to combine this work with something useful, that is I'd >> like to give whatever I implement to GRASS. Partially for altruistic >> reasons, partially because I think that coding within the GRASS >> environment will make debugging and testing a whole lot easier and more >> comfortable. Now I'd like to know which algorithm would you like me to >> implement. Here are some candidates: > > Get marks and code for GRASS. What a wonderful idea. > > The options all sound interesting. My personal vote would be for label > placement as I see cartography as a major weakness in GRASS and this > would lay part of the foundation for better cartography in GRASS. My > experience in most systems is that when it comes time for output > hours can be wasted in label placement so an algorithm to get one > 90% good on that would be a huge time saver for cartographic use. It > would be very useful, if it can be written such that it could be > used by either v.label, ps.map or perhaps a new interface in the > future. In that regard label size in relation to a paper or view size > will need to be taken into account. > > My other choices in order of preference are 4, 3, and 2. In regard to > line smoothing I know little about it so I can't state a preference on > algorithm and thus it is my last choice. I've not needed this > functionality before so I've never researched it. > > Thanks > > T >> >> 1. Label position >> ================= >> One of the algorithms we learned about was "A generic Cartographic >> Labeling Algorithm" by Edmondson, Christensen, Marks and Shrieber >> published in Cartographica, Vol 33 No. 4, 1996 pp. 13-23. >> >> This algorithm of theirs is able to position labels so that they don't >> overlap and the labels are also placed in as good a place as possible. >> It can handle line-, point- and area labels. >> >> This module would not be a replacement to v.label rather an extension, >> but it would have to start out as a separate module (to make it possible >> to grade my work). My plan for this would be to output a label file just >> like v.label does. After I'm done for school I'd merge this code to be >> triggered by a flag in v.label. >> >> 2. Line generalization or smoothing >> =================================== >> A new module which would do line generalization with one of these algorithms >> >> *) Douglas-Peuker algorithm >> *) Reumann-Witkam algorithm >> *) Lang simplification algorithm >> *) Cromley's Hierarchical algorithm >> *) Boyle's forward-looking smoothing algorithm >> >> The most famous of these is the Douglas-Peuker algorithm. >> >> If you would like me to do this one please also indicate which algorithm >> you would be most interesting / useful for you. >> >> 3. A new simulation/optimization algorithm for least cost path >> ============================================================== >> A new module which would calculate the shortest path from a starting >> point to a destination. It would use Dijkstra's algorithm do find the >> shortest path in a weighted network. In other words it would treat a >> cost surface (generated by r.cost) as a network and then calculate the >> shortest path. This differs from r.drain in that r.drain is a local >> function, greedy algorithm, whereas this a focal algorithm, that is it >> takes not only it's immediate location into account, and finds a global >> shortest path. >> >> 4. Shortest path in free (vector) space (avoiding obstacles) >> ============================================================ >> This module would take as input a vector map with polygons. These >> polygons would be treated as obstacles. It would also take a starting >> and end point as input. It would output a vector map containing the >> shortest path in free space (this assumes an equal cost surface). >> There are 2 different ways to do this calculation: >> >> a) by building a "road network" with the help of building trapezoids >> from each corner point of the obstacles. >> OR >> b) by building a visibility graph and converting it into a weighted >> network and running Dijkstra's shortest path on it. >> >> ------------------------ >> >> If you want more elaboration or have questions on any of the above, >> please don't hesitate to ask (on or off list). I'd also like to hear any >> other comments you might have. >> >> The time-line for this project is that I will start coding at the latest >> on week 13 (most probably week 12), and the project will have a demo >> session on the 26th of April, and must be completed by the 10th of May. >> >> Best regards, >> --Wolf Bergenheim >> >> -- >> >> <:3 )---- Wolf Bergenheim ----( 8:> >> >> _______________________________________________ >> 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 Sat Mar 3 07:42:58 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sat Mar 3 07:43:10 2007 Subject: [GRASS-dev] New feature (algorithm and / or module) to implent to GRASS (long) In-Reply-To: <45E7598B.7000309@bergenheim.net> Message-ID: My second choices after #1 would be (in ranked order) 3,2,4 Michael On 3/1/07 3:54 PM, "Wolf Bergenheim" wrote: > Greetings GRASS developers, > > I'm attending a course in Spatial Data Algorithms > (http://www.tkk.fi/Units/Cartography/courses/maa-123340/), and we are > supposed to implement one algorithm or data structure we have talked > about. I'd like to combine this work with something useful, that is I'd > like to give whatever I implement to GRASS. Partially for altruistic > reasons, partially because I think that coding within the GRASS > environment will make debugging and testing a whole lot easier and more > comfortable. Now I'd like to know which algorithm would you like me to > implement. Here are some candidates: > > 1. Label position > ================= > One of the algorithms we learned about was "A generic Cartographic > Labeling Algorithm" by Edmondson, Christensen, Marks and Shrieber > published in Cartographica, Vol 33 No. 4, 1996 pp. 13-23. > > This algorithm of theirs is able to position labels so that they don't > overlap and the labels are also placed in as good a place as possible. > It can handle line-, point- and area labels. > > This module would not be a replacement to v.label rather an extension, > but it would have to start out as a separate module (to make it possible > to grade my work). My plan for this would be to output a label file just > like v.label does. After I'm done for school I'd merge this code to be > triggered by a flag in v.label. > > 2. Line generalization or smoothing > =================================== > A new module which would do line generalization with one of these algorithms > > *) Douglas-Peuker algorithm > *) Reumann-Witkam algorithm > *) Lang simplification algorithm > *) Cromley's Hierarchical algorithm > *) Boyle's forward-looking smoothing algorithm > > The most famous of these is the Douglas-Peuker algorithm. > > If you would like me to do this one please also indicate which algorithm > you would be most interesting / useful for you. > > 3. A new simulation/optimization algorithm for least cost path > ============================================================== > A new module which would calculate the shortest path from a starting > point to a destination. It would use Dijkstra's algorithm do find the > shortest path in a weighted network. In other words it would treat a > cost surface (generated by r.cost) as a network and then calculate the > shortest path. This differs from r.drain in that r.drain is a local > function, greedy algorithm, whereas this a focal algorithm, that is it > takes not only it's immediate location into account, and finds a global > shortest path. > > 4. Shortest path in free (vector) space (avoiding obstacles) > ============================================================ > This module would take as input a vector map with polygons. These > polygons would be treated as obstacles. It would also take a starting > and end point as input. It would output a vector map containing the > shortest path in free space (this assumes an equal cost surface). > There are 2 different ways to do this calculation: > > a) by building a "road network" with the help of building trapezoids > from each corner point of the obstacles. > OR > b) by building a visibility graph and converting it into a weighted > network and running Dijkstra's shortest path on it. > > ------------------------ > > If you want more elaboration or have questions on any of the above, > please don't hesitate to ask (on or off list). I'd also like to hear any > other comments you might have. > > The time-line for this project is that I will start coding at the latest > on week 13 (most probably week 12), and the project will have a demo > session on the 26th of April, and must be completed by the 10th of May. > > Best regards, > --Wolf Bergenheim __________________________________________ 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 Sat Mar 3 11:09:00 2007 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Sat Mar 3 11:09:02 2007 Subject: [GRASS-dev] [bug #5263] (grass) r.to.vect: -v flag doesn't transfer cat values Message-ID: <20070303100900.7C1871005AD@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=5263 Request number 5263 was commented on by 'msieczka' (Maciek Sieczka). Responding to this message will send mail to the requestor. Request Tracker rt@intevation.de -------------------------------------------------------------- Cc: hamish_nospam@yahoo.com,grass-dev@grass.itc.it mlanda wrote (Wed, Feb 28 2007 16:57:04): > Attributes for lines are not ignored (fixed in CVS today). But the problem > with overlapping input raster cells of different value remains. Could be > called as the feature? Martin, After you enabled attribute transfer for feature=line, it shows there is bug there. Attributes are not transferred correctly from raster to vector lines. In spearfish, do: $ r.thin roads out=roads_thin $ r.to.vect input=roads_thin output=roads_thin_vect feature=line $ r.to.vect -v input=roads_thin output=roads_thin_vect_cat feature=line Display them all and take a closer look at the horizontal roads located near 599447(E) 4921873(N). Query the input raster roads_thin. As you can see the values of lines on the left and right should be 5 and 4, respectively. However, in roads_thin_vect there is only one line there, having value=4. In roads_thin_vect_cat on the other hand, there are 2 lines with cat=5 on the left and cat=4 on the right, but the line with cat=4 is about 740m too long. Maybe that's why it was never enabled, ?. Maciek -------------------------------------------- Managed by Request Tracker From grass-codei at wald.intevation.org Sat Mar 3 11:46:27 2007 From: grass-codei at wald.intevation.org (grass-codei@wald.intevation.org) Date: Sat Mar 3 11:46:30 2007 Subject: [GRASS-dev] [grass-code I][322] r.to.vect feature=lines: the output vector is moved half the resolution east off the input raster Message-ID: <20070303104627.66D8A182D7BD@pyrosoma.intevation.org> code I item #322, was opened at 2007-03-03 11:46 Status: Open Priority: 3 Submitted By: Maciej Sieczka (msieczka) Assigned to: Nobody (None) Summary: r.to.vect feature=lines: the output vector is moved half the resolution east off the input raster Issue type: module bug Issue status: None GRASS version: CVS HEAD GRASS component: raster Operating system: all Operating system version: GRASS CVS checkout date, if applies (YYMMDD): 070303 Initial Comment: In spearfish, r.in.gdal the attached lines.tif and run: $ g.region rast=lines -a $ r.to.vect input=lines output=lines_vect feature=line Display the raster and vector and see how vector is off the raster - like in the attached screendump off.png. It *seems* the problem is that the output vector is moved half the cell resolution east (this is visible on both the vertical and horizontal line). Maciek ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=322&group_id=21 From mlennert at club.worldonline.be Sat Mar 3 12:54:27 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Sat Mar 3 12:51:44 2007 Subject: [GRASS-dev] ps.map consolidation In-Reply-To: <200703022225.l22MP6Ws064520@smtp.spinn.net> References: <20070302180354.5b6fbb6f.hamish_nospam@yahoo.com> <17896.39732.895359.20874@cerise.gclements.plus.com> <200703022225.l22MP6Ws064520@smtp.spinn.net> Message-ID: <1241.85.10.67.87.1172922867.squirrel@geog-pc40.ulb.ac.be> On Fri, March 2, 2007 23:25, roger@spinn.net wrote: > > I have a rudimentary GUI for ps.map written as a TCL/TK script. It works > by > reading the content of the monitor and using that content to construct a > basic input file for ps.map. The GUI (which, as I said is pretty > rudimentary) allows the user to view and edit instructions in the input > file, to insert elements like eps files and to use options like line > styles > that aren't supported on the GRASS monitor. It uses xpdf a previewer. > xpdf > is fairly fast and has a remote server mode that allows the user to update > the preview without restarting the viewer. It is distributed under the > GNU > public license by Glyph and Cog, LLC ; > http://www.foolabs.com/xpdf/home.html Would you be willing to publish your script on the GRASS add-ons wiki (http://grass.gdf-hannover.de/wiki/GRASS_AddOns) ? Moritz > > The grass developers may not want to introduce a dependency on xpdf, but I > encourage you to do something to give ps.map a friendlier front end. The > benefit is tremendous. Having even a simple interactive ability to > develop > better graphics within the grass environment improved the quality of my > products and decreased the time necessary to produce them. > > > Roger Miller > > Glynn Clements writes: > >> >> J-B???chym ???epick??? wrote:-A >> >>> another point: How to write GUI for ps.map, so it is usable for the >>> user. Several approaches are possible: >>> >>> Drawing boxes for legend, measure, text and so on, so the user has at >>> least idea about where and how the object will be placed on the paper. >>> >>> Another sollution would be, if we would copy the map display approach: >>> render separate layer for each map instruction in the temporary file >>> and put them together in the map display. User could than take a mouse >>> and position each object interactively. >>> >>> We would need support of transparency for this... Does ps.map support >>> creation of transparent files? >> >> ps.map creates PostScript files. If you use Ghostscript's "pngalpha" >> driver, the resulting PNG file will have a transparent background. But >> then you would need to convert the PNG files to PPM/PGM (that's all >> that g.pnmcomp understands), and you would need to manually >> re-composite those files whenever the relative position changes. >> >> Personally, I don't see the point in a ps.map GUI; this task is better >> suited to general-purpose DTP software. >> >> -- >> Glynn Clements >> >> _______________________________________________ >> 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 neteler at itc.it Sat Mar 3 14:56:28 2007 From: neteler at itc.it (Markus Neteler) Date: Sat Mar 3 14:56:29 2007 Subject: [GRASS-dev] New feature (algorithm and / or module) to implent to GRASS (long) In-Reply-To: <45E7598B.7000309@bergenheim.net> References: <45E7598B.7000309@bergenheim.net> Message-ID: <20070303135628.GA2774@bartok.itc.it> Hi Wolf, indeed, a wonderful list of ideas - it's great to see this. Like the others I would opt for "label position" (you will gain most kudos like that in the GFOSS world :-) The DP generalization might be rather easily solved using the GMT/GSHHS code which probably needs "only" an update to match the GRASS vector structure. But labeling is a real problem for now. Good luck, Markus From michael.barton at asu.edu Sat Mar 3 16:25:17 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sat Mar 3 16:25:31 2007 Subject: [GRASS-dev] ps.map consolidation In-Reply-To: <200703022225.l22MP6Ws064520@smtp.spinn.net> Message-ID: In order to better create backgrounds in v.digit from the GUI, I added a new global variable, named "commandlist" to the TclTk code. Commandlist stores a TclTk list of the commands needed to create the current display. It is updated every time the display is updated. Thinking about it, I may need to index it by display, like many other variables. However, this could be used for a variety of other uses, including being parsed to create a ps.map command file. Michael On 3/2/07 3:25 PM, "roger@spinn.net" wrote: > > I have a rudimentary GUI for ps.map written as a TCL/TK script. It works by > reading the content of the monitor and using that content to construct a > basic input file for ps.map. The GUI (which, as I said is pretty > rudimentary) allows the user to view and edit instructions in the input > file, to insert elements like eps files and to use options like line styles > that aren't supported on the GRASS monitor. It uses xpdf a previewer. xpdf > is fairly fast and has a remote server mode that allows the user to update > the preview without restarting the viewer. It is distributed under the GNU > public license by Glyph and Cog, LLC ; http://www.foolabs.com/xpdf/home.html > > The grass developers may not want to introduce a dependency on xpdf, but I > encourage you to do something to give ps.map a friendlier front end. The > benefit is tremendous. Having even a simple interactive ability to develop > better graphics within the grass environment improved the quality of my > products and decreased the time necessary to produce them. > > > Roger Miller > > Glynn Clements writes: > >> >> J-B?chym ?epick? wrote:-A >> >>> another point: How to write GUI for ps.map, so it is usable for the >>> user. Several approaches are possible: >>> >>> Drawing boxes for legend, measure, text and so on, so the user has at >>> least idea about where and how the object will be placed on the paper. >>> >>> Another sollution would be, if we would copy the map display approach: >>> render separate layer for each map instruction in the temporary file >>> and put them together in the map display. User could than take a mouse >>> and position each object interactively. >>> >>> We would need support of transparency for this... Does ps.map support >>> creation of transparent files? >> >> ps.map creates PostScript files. If you use Ghostscript's "pngalpha" >> driver, the resulting PNG file will have a transparent background. But >> then you would need to convert the PNG files to PPM/PGM (that's all >> that g.pnmcomp understands), and you would need to manually >> re-composite those files whenever the relative position changes. >> >> Personally, I don't see the point in a ps.map GUI; this task is better >> suited to general-purpose DTP software. >> >> -- >> Glynn Clements >> >> _______________________________________________ >> 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 wolf+grass at bergenheim.net Sat Mar 3 21:48:54 2007 From: wolf+grass at bergenheim.net (Wolf Bergenheim) Date: Sat Mar 3 21:49:30 2007 Subject: [GRASS-dev] New feature (algorithm and / or module) to implent to GRASS (long) In-Reply-To: <20070303135628.GA2774@bartok.itc.it> References: <45E7598B.7000309@bergenheim.net> <20070303135628.GA2774@bartok.itc.it> Message-ID: <45E9DF36.1060701@bergenheim.net> Well, it seems that the label placement is what I'm going to implement for this course. It was also my number one preference. After I'm done I'll see about starting on another, or perhaps they could be ideas for the Google SoC? I have copies of those algorithms, so I'll be happy to shear them too (though they are public knowledge). The algorithms are not that complex, and so these could be an easy way to introduce people to the GRASS library. Anyway I'd like to thank you all on your comments and encouragement. :) --Wolf -- <:3 )---- Wolf Bergenheim ----( 8:> From rez at touchofmadness.com Sun Mar 4 01:34:25 2007 From: rez at touchofmadness.com (Brad Douglas) Date: Sun Mar 4 01:34:30 2007 Subject: [GRASS-dev] updates Message-ID: <1172968465.9266.299.camel@devel> A few changes in CVS: I updated v.to.rast to write labels for all use options except Z. I have also updated r.random to write history for output raster and vector. i.rgb.his/i.his.rgb were API upgraded and now use a little bit less memory. Please test if you get a chance. Not yet in CVS: I have i.fft working with the changes Glynn suggested for using native FFTW, but I need to work out what parts are needed and not needed as it still has a bit of an offset in the output images. I was hoping to get away without digging into the code. :-) -- Brad Douglas KB8UYR/6 Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From hamish_nospam at yahoo.com Sun Mar 4 01:53:21 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Sun Mar 4 01:53:27 2007 Subject: [GRASS-dev] issue tracking, rt (was: [bug #5504] (grass)) In-Reply-To: <200703021057.52816.bernhard@intevation.de> References: <20070224221914.164F01006A2@lists.intevation.de> <200703010946.44927.bernhard@intevation.de> <45E70104.3010809@o2.pl> <200703021057.52816.bernhard@intevation.de> Message-ID: <20070304135321.48b8f3f2.hamish_nospam@yahoo.com> Bernhard Reiter wrote: > On Thursday 01 March 2007 17:36, Maciej Sieczka wrote: > > Bernhard Reiter wrote: > > > On Wednesday 28 February 2007 20:03, Maciej Sieczka wrote: > > > > we switched this off on Tuesday and one of Intevation's admin > > > has send an email to you on this day. > > > > I didn't receive that email. I don't use a spam filter. It must have > > get lost in between somewhere. > > > > > Registered users with manipulation rights can still open issues, > > > which I think is okay. > > > > Perfect, thanks. > > > > > We probably cannot change this anyway. > > > > No need to. > > > > > So there is a remote chance that spammers hit the right address. > > Could you explain how exactly? > > I suspect that if they use a forged from address from somebody that is > a registered user, they can still send something to the tracker. I > did not checked if this is a real attack vector. The chances for this > a quite low compared to other spam hits, so I do not think we should > spend much energy on it. I'm not worried about it. It isn't worth their time. I notice that guests can not post comments on the web interface now, which means that only folks registed in the bug tracker can (ie devels). Not so good as regular bug reporters or freelancers without a login can no longer contribute to an old but still open bug report. ?, Hamish From neteler at itc.it Sun Mar 4 09:29:21 2007 From: neteler at itc.it (Markus Neteler) Date: Sun Mar 4 11:02:08 2007 Subject: [GRASS-dev] v.overlay: countries and oceans problem Message-ID: <20070304082921.GA4501@bartok.itc.it> Hi, I tried to add oceans to the world country map "admin98" from http://mappinghacks.com/data/admin98.zip in a latlong location by g.region n=90N s=90S w=180W e=180E res=0:05 -p v.in.region worldbox v.db.addtable worldbox col="area varchar(10)" v.db.update worldbox col=area val="world" v.overlay ain=admin98 bin=worldbox out=admin98_oceans op=or By this I was hoping to get - a box around the world - oceans as polygons Looking at the result, it isn't quite convincing: http://mpa.itc.it/markus/tmp/admin98_oceans_buggy.png At the west border there seems to be a boundary reaching 90N but the north boundary is missing. The polygon fill is rather strange (maybe not?). Any idea how to get the oceans as polygons into "admin98"? Markus From wolf+grass at bergenheim.net Sun Mar 4 11:30:50 2007 From: wolf+grass at bergenheim.net (Wolf Bergenheim) Date: Sun Mar 4 11:31:29 2007 Subject: [GRASS-dev] New feature (algorithm and / or module) to implent to GRASS (long) In-Reply-To: <45E9DF36.1060701@bergenheim.net> References: <45E7598B.7000309@bergenheim.net> <20070303135628.GA2774@bartok.itc.it> <45E9DF36.1060701@bergenheim.net> Message-ID: <45EA9FDA.90901@bergenheim.net> Hey list, Is it OK if I create a branch[1] in CVS in the vector directory for this? That way you all can also observe my progress, and I will have the safety of version control during this process, and it won't mess the rest of the build system. Another option would be that I would simply work in the main trunk of the CVS, since my work will only be localized to the module I'm working on. What are your thoughts? --Wolf [1] What is a branch? A branch is a separate line of development which will me to work concurrently with the CVS without messing with the main development branch. The subversion manual has a nice explanation on branches: http://svnbook.red-bean.com/en/1.1/svn-book.html#svn-ch-4-sect-1 On 03.03.2007 22:48, Wolf Bergenheim wrote: > Well, > > it seems that the label placement is what I'm going to implement for > this course. It was also my number one preference. After I'm done I'll > see about starting on another, or perhaps they could be ideas for the > Google SoC? I have copies of those algorithms, so I'll be happy to shear > them too (though they are public knowledge). The algorithms are not that > complex, and so these could be an easy way to introduce people to the > GRASS library. > > Anyway I'd like to thank you all on your comments and encouragement. :) > > --Wolf > -- <:3 )---- Wolf Bergenheim ----( 8:> From tlaronde at polynum.com Sun Mar 4 14:41:32 2007 From: tlaronde at polynum.com (tlaronde@polynum.com) Date: Sun Mar 4 14:38:26 2007 Subject: [GRASS-dev] [RFC] Glossary: GISDATABASE -> DATASTORE Message-ID: <20070304134132.GA1428@polynum.com> Hello, I plan to make the following changes in the variables names in KerGIS. Since we do share the same origin and since it will be suboptimal to have distinct naming schemes, I'd like to hear your reactions about the following choices. Thanks in advance. Glossary proposal for gis "database" naming scheme -------------------------------------------------- A database is an organized set of logically related data. A table is a set of instances of elements composed of a fixed number of sub-elements (fields). Historically, in CERL GRASS derived systems, GISDATABASE has been the name of the variable holding the value of the pathname to a directory where GRASS data is stored. There is absolutely no question whether some parts of the gis data stored are databases: there are. But this is not what is designated by GISDATABASE. The real database level is the LOCATION, where all the data is logically related at least by the REGION. The MAPSETs are the tables. Hence the use of GISDATABASE is misleading in several ways: 1) The directory is not a database (databases are sub-directories); 2) This is not _the_ GISDATABASE since there may be many ones (contrary to _the_ GISBASE where _this_ version of the gis system is put); 3) Since, for non geometrical attributes, other types of RDBMs are used, there is some confusion or at least some implicit assumptions about what a "database" is. Hence I propose to replace GISDATABASE by: DATASTORE. Not GISDATASTORE to avoid the assumption about the uniqueness (the GISBASE, but one of several DATASTORE; we are in the gis, so this shall be taken for granted; furthermore GISDATABASE is a gis environment variable, not a system host one [contrary to GISBASE]; so this make sense). The SQL terminology (even if the CERL GRASS databases [LOCATIONs] have nothing to do with SQL, but _are_ databases, I looked for "prior art"): catalog is not widely used, and, for me, does not hold the correct meaning: a catalog is the listing of what is in a store, not the store itself. The comparison with the SQL terminology, and a RDBM (PostgreSQL) can share some supplementary light (this is a naming comparison; it should not be pushed to far): SQL PostgreSQL GRASS/KerGIS ====================================================== cluster cluster cluster catalog database cluster DATASTORE schema database LOCATION object tables/views/routines MAPSET ====================================================== Note1: someone wrote that one of the "out of fashion" aspect of CERL GRASS derived systems was, with the use of not in the mood programming languages, the fact that the data is stored in a file hierarchy. Well that is exactly how PostgreSQL, for example, does it and I do not see why this should be plagued as a bad choice (for example allowing to dedicate some chunk of a disk with a size allowing backup [matching backup capabilities], and using Unix access permissions, or, if usable, ACLs to manage access). Note 2: in CERL GRASS, the gis environment variable LOCATION_NAME was used for the "location", while LOCATION was set to the full path. I have found that indeed, for users, LOCATION should be set to the location name, symetric with the use of MAPSET. The full pathname is only used in scripts, since the gis has dedicated functions to precisely find a name in its databases or tables (locations and mapsets). Any comments? -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C From glynn at gclements.plus.com Sun Mar 4 14:48:56 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Mar 4 14:49:05 2007 Subject: [GRASS-dev] New feature (algorithm and / or module) to implent to GRASS (long) In-Reply-To: <45EA9FDA.90901@bergenheim.net> References: <45E7598B.7000309@bergenheim.net> <20070303135628.GA2774@bartok.itc.it> <45E9DF36.1060701@bergenheim.net> <45EA9FDA.90901@bergenheim.net> Message-ID: <17898.52808.532942.580708@cerise.gclements.plus.com> Wolf Bergenheim wrote: > Is it OK if I create a branch[1] in CVS in the vector directory for > this? That way you all can also observe my progress, and I will have the > safety of version control during this process, and it won't mess the > rest of the build system. Another option would be that I would simply > work in the main trunk of the CVS, since my work will only be localized > to the module I'm working on. What are your thoughts? If all of your work will be in new files, just work on the trunk. A branch is only justified if you intend to make significant, incompatible changes to existing files. -- Glynn Clements From michael.barton at asu.edu Sun Mar 4 16:30:03 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sun Mar 4 16:30:12 2007 Subject: [GRASS-dev] Re: typo error in gis.m In-Reply-To: Message-ID: Fixed and in the cvs. Michael On 3/1/07 11:19 AM, "Patricio Antonio Toledo Pe?a" wrote: > v.delaunay __________________________________________ 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/20070304/ddbaf560/attachment.html From michael.barton at asu.edu Sun Mar 4 17:36:13 2007 From: michael.barton at asu.edu (Michael Barton) Date: Sun Mar 4 17:36:22 2007 Subject: [GRASS-dev] Re: OSX GRASS.app build news In-Reply-To: Message-ID: William, I tried out the new build system for Mac OS X and it worked great. AFAICT, the make install created a perfect GRASS.app This system will be excellent for compiling on the Mac OSX. With your framework build for the libraries, it make compiling reasonably accessible to even terminal averse Mac users. As usual, I had to go into /lib/proj and /gui/tcltk/d.m and individually run make in these folders. I don't understand why this is so, since both compiled fine from within the folders. I hope that someone with makefile experience can help you get these changes permanently into the GRASS cvs like the debian and rmp setups. Michael On 2/20/07 8:57 PM, "William Kyngesburye" wrote: > If you're not too busy and would like to test it, I submitted a set > of patches to the new tracker to add a Mac OS X app build to GRASS. > > Apply the patches to the corresponding files in the existing grass > source (you may want to save backups). Drop the macosx folder in the > top level of the source. > > Configure as you normally would, except set the prefix: > > --prefix=/Applications > > BUT don't make yet. Since the needed configure flag isn't available > yet (I don't know how to patch configure.in), you must manually > enable the app build. Edit platform.make and change the MACOSX_APP = > @MACOSX_APP@ line to: > > MACOSX_APP = 1 > > Now, when you make, the macosx folder will be built. The install > completes the process. By default, TclTk X11 is bundled in the > package. The bindist target (make bindist) might be preferable so > you don't overwrite an existing GRASS.app. Unlike the unix bindist > which tarballs the binary and includes an install script, the OSX app > bindist just packages the app like the install does and put it in the > GRASS source folder, then you can drag it to whereever you like > (considering the no-spaces-in-pathname rule). > > > Since the @MACOSX_APP@ bit in platform.make will force an app build, > if you want to disable the app build delete that part, so you get: > > MACOSX_APP = > > (or use the original platform.make.in and reconfigure) > > The other patches won't get in the way of a unix-style build. > > > It would be great if you could try this. If someone doesn't pick > this one up soon, maybe you know who to bug ^_^ > > ----- > William Kyngesburye > http://www.kyngchaos.com/ > > "We are at war with them. Neither in hatred nor revenge and with no > particular pleasure I shall kill every ___ I can until the war is > over. That is my duty." > > "Don't you even hate 'em?" > > "What good would it do if I did? If all the many millions of people > of the allied nations devoted an entire year exclusively to hating > the ____ it wouldn't kill one ___ nor shorten the war one day." > > "And it might give 'em all stomach ulcers." > > - Tarzan, on war > __________________________________________ 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 Mar 5 00:11:13 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Mar 5 00:11:21 2007 Subject: [GRASS-dev] [RFC] Glossary: GISDATABASE -> DATASTORE In-Reply-To: <20070304134132.GA1428@polynum.com> References: <20070304134132.GA1428@polynum.com> Message-ID: <20070305121113.28f944ae.hamish_nospam@yahoo.com> Thierry wrote: > Glossary proposal for gis "database" naming scheme .. > Hence I propose to replace GISDATABASE by: DATASTORE. DATASTORE is a fine suggestion, the best I've heard so far. See also email threads discussing the wording of the start-up mapset-picker menu. > Note 2: in CERL GRASS, the gis environment variable LOCATION_NAME was > used for the "location", while LOCATION was set to the full path. I > have found that indeed, for users, LOCATION should be set to the > location name, symetric with the use of MAPSET. The full pathname is > only used in scripts, since the gis has dedicated functions to > precisely find a name in its databases or tables (locations and > mapsets). Any comments? -- In GPL GRASS 6 LOCATION_NAME is still a GIS variable (stored in ~/.grassrc6 and not a shell variable*) and viewed/changed with the g.gisenv module. LOCATION_NAME is just the name, not the path. GISDBASE has the path. The shell variable $LOCATION has been abandoned, but a number of scripts do this to recreate it: (due to path of least modification after $LOCATION was dropped) eval `g.gisenv` : ${GISBASE?} ${GISDBASE?} ${LOCATION_NAME?} ${MAPSET?} LOCATION="$GISDBASE"/"$LOCATION_NAME"/"$MAPSET" [*] not a shell variable to allow child process (the GUI menus) to adjust variables which affect the parent, and thus new non-derivative sibling processes. [e.g. switch mapsets without exiting GRASS] Hamish From hamish_nospam at yahoo.com Mon Mar 5 02:50:14 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Mar 5 02:50:21 2007 Subject: [GRASS-dev] ps.map consolidation In-Reply-To: References: <20070302180354.5b6fbb6f.hamish_nospam@yahoo.com> Message-ID: <20070305145014.2b4ecedb.hamish_nospam@yahoo.com> J?chym ?epick? wrote: > I was suggesting this changes to make live of GUI coder easier :) I know, and feel your pain. > another point: How to write GUI for ps.map, so it is usable for the > user. Several approaches are possible: > > Drawing boxes for legend, measure, text and so on, so the user has at > least idea about where and how the object will be placed on the paper. > > Another sollution would be, if we would copy the map display approach: > render separate layer for each map instruction in the temporary file > and put them together in the map display. User could than take a mouse > and position each object interactively. some ideas here: http://grass.gdf-hannover.de/wiki/GRASS_GUI#Cartography:_GUI_front_end_for_ps.map My idea was to combine both ways, sort of like how QGIS is organized. blank preview page on the right side of the GUI (portrait or landscape) with solid black border for map box and colored dashed lines for the different text/legend boxes. To begin with have those drawn from map control placement settings, but in future you could drag those around to update the instructions settings (adjust box of currently selected instruction for overlap-proofing). In the far-future you would see low res preview instead of just rectangles. On the left 1/4 of the GUI would be an expandable map control tree with a few permanent entries (paper, scale, maploc). They might start with a "default" tick box selected [which would skip the instruction on output]) [-] paper type _____A4_[V] letter custom ... [ungreyed for custom] units ___inch_[V] Page Size height ______ width _______ Margin Size top _________ bottom ______ left ________ right _______ [+] scale [+] maploc then icons along the top for: (keep it simple, ~8 is enough) # rast # vects (areas, lines, points) # grids # scalebar # mapinfo # text labels When you click on an icon, a new "[+] raster map" gets added to the list, then as above. Right-click to select remove instruction. Some of those (rast, grid) need logic so you can only add them once. Then in a main window pulldown menu have all the mapping instructions, including the lesser used ones. Save As... would take the current tree settings and write a ps.map instructions file. In the top-left "File" menu have (greyed-out in prototype) Load command file, then these (working in prototype) output menu entries: * Save instructions file, Save As... [a ps.map file] * Save as PostScript file [run ps.map] * Save as PDF File (pstopdf? ps2pdf? GNU Ghostscript?) [run ps.map, work on PostScript tmp file] * Print [run ps.map, lpr PostScript tmp file] And of course a Help menu with "g.manual ps.gui", "g.manual ps.map", "About GUI", "About ps.map", "About GRASS". how does that sound? Hamish From dylan.beaudette at gmail.com Mon Mar 5 06:16:58 2007 From: dylan.beaudette at gmail.com (Dylan Beaudette) Date: Mon Mar 5 05:39:11 2007 Subject: [GRASS-dev] New feature (algorithm and / or module) to implent to GRASS (long) In-Reply-To: <45E9DF36.1060701@bergenheim.net> References: <45E7598B.7000309@bergenheim.net> <20070303135628.GA2774@bartok.itc.it> <45E9DF36.1060701@bergenheim.net> Message-ID: <200703042116.58383.dylan.beaudette@gmail.com> On Saturday 03 March 2007 12:48, Wolf Bergenheim wrote: > Well, > > it seems that the label placement is what I'm going to implement for > this course. It was also my number one preference. After I'm done I'll > see about starting on another, or perhaps they could be ideas for the > Google SoC? I have copies of those algorithms, so I'll be happy to shear > them too (though they are public knowledge). The algorithms are not that > complex, and so these could be an easy way to introduce people to the > GRASS library. > > Anyway I'd like to thank you all on your comments and encouragement. :) > > --Wolf This is great news Wolf! Once your label collision system is complete I think that it can be tied in nicely with the GRASS-GMT work that has been underway. Label placement in GMT is done feature-by-feature, so the output from your module should be a drop-in upgrade to the current use of centroids, etc. Cheers, Dylan -- Dylan Beaudette Soils and Biogeochemistry Graduate Group University of California at Davis 530.754.7341 From bernhard at intevation.de Mon Mar 5 11:56:26 2007 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon Mar 5 11:56:45 2007 Subject: [GRASS-dev] issue tracking, rt (was: [bug #5504] (grass)) In-Reply-To: <20070304135321.48b8f3f2.hamish_nospam@yahoo.com> References: <20070224221914.164F01006A2@lists.intevation.de> <200703021057.52816.bernhard@intevation.de> <20070304135321.48b8f3f2.hamish_nospam@yahoo.com> Message-ID: <200703051156.27445.bernhard@intevation.de> On Sunday 04 March 2007 01:53, Hamish wrote: > I notice that guests can not post comments on the web interface now, > which means that only folks registed in the bug tracker can (ie devels). > Not so good as regular bug reporters or freelancers without a login > can no longer contribute to an old but still open bug report. This seems to be the drawback switching off the rights for anonymous. Note that webspamming also happens. I have a quick glance on it to see if we can change this for the better. Otherwise I suggest we just stay with the current solution and have guest comment on the mailing lists where the spam protection is better. Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070305/c7dd1273/attachment.bin From glynn at gclements.plus.com Mon Mar 5 12:20:51 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Mar 5 12:20:56 2007 Subject: [GRASS-dev] Font changes Message-ID: <17899.64787.295100.441102@cerise.gclements.plus.com> I've modified the display driver library so that it reads the original stroke font files (hersh.oc? and *.hmp) directly; the files are no longer compiled into a binary form (this solves one of the outstanding issues with cross-compiling). Everything seems to work okay (and adding debug code to dump out the data from the driver essentially reproduces the original hersh.oc? data). However, there may be some issues which I've overlooked; e.g. I discovered that d.font was generating the list of allowed values for the font= options by listing the $GISBASE/fonts directory, so that had to be fixed. If anyone finds similar issues, let me know. -- Glynn Clements From glynn at gclements.plus.com Mon Mar 5 14:06:31 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Mar 5 14:06:33 2007 Subject: [GRASS-dev] portable.h elimination Message-ID: <17900.5591.692946.780300@cerise.gclements.plus.com> I've modified lib/vector/diglib to determine the byte ordering at run time, rather than generating the portable.h header file. The supplied test case passes. It might be useful to test it using dig files generated on an architecture with the opposite byte order (I have no way to test this). It might also be worth testing it on MinGW. -- Glynn Clements From jachym.cepicky at gmail.com Mon Mar 5 14:36:48 2007 From: jachym.cepicky at gmail.com (Jachym Cepicky) Date: Mon Mar 5 14:36:52 2007 Subject: [GRASS-dev] ps.map consolidation In-Reply-To: <20070305145014.2b4ecedb.hamish_nospam@yahoo.com> References: <20070302180354.5b6fbb6f.hamish_nospam@yahoo.com> <20070305145014.2b4ecedb.hamish_nospam@yahoo.com> Message-ID: hi, > > some ideas here: > http://grass.gdf-hannover.de/wiki/GRASS_GUI#Cartography:_GUI_front_end_for_ps.map > > > My idea was to combine both ways, sort of like how QGIS is organized. > blank preview page on the right side of the GUI (portrait or landscape) > with solid black border for map box and colored dashed lines for the > different text/legend boxes. To begin with have those drawn from map > control placement settings, but in future you could drag those around > to update the instructions settings (adjust box of currently selected > instruction for overlap-proofing). In the far-future you would see low > res preview instead of just rectangles. I see the problem in "guessing" the box sizes. e.g. you can place the legend box somewhere on the paper, but you can not tell, how wide and height the box will be. That is, why I was proposing to find a sollution, that each object of the map would be stored in separate layer, so it could be regenerated ones the user changes some properity. I did something, what you are proposing allready, some months ago: http://wwwold.fle.czu.cz/~jachym/img/grass/gpsmap-0.1.2.png but as I said, it was hard to determine the box dimensions.. I like the rest, you are writing, nice concept. Only the list of layers should be taken from current map display jachym > > On the left 1/4 of the GUI would be an expandable map control > tree with a few permanent entries (paper, scale, maploc). > They might start with a "default" tick box selected [which would skip > the instruction on output]) > > [-] paper > type _____A4_[V] > letter > custom > ... > [ungreyed for custom] > units ___inch_[V] > Page Size > height ______ > width _______ > Margin Size > top _________ > bottom ______ > left ________ > right _______ > [+] scale > [+] maploc > > then icons along the top for: (keep it simple, ~8 is enough) > > # rast > # vects (areas, lines, points) > # grids > # scalebar > # mapinfo > # text labels > > When you click on an icon, a new "[+] raster map" gets added to > the list, then as above. Right-click to select remove instruction. > Some of those (rast, grid) need logic so you can only add them once. > Then in a main window pulldown menu have all the mapping instructions, > including the lesser used ones. > > Save As... would take the current tree settings and write a ps.map > instructions file. > > In the top-left "File" menu have (greyed-out in prototype) Load command > file, then these (working in prototype) output menu entries: > * Save instructions file, Save As... [a ps.map file] > * Save as PostScript file [run ps.map] > * Save as PDF File (pstopdf? ps2pdf? GNU Ghostscript?) > [run ps.map, work on PostScript tmp file] > * Print [run ps.map, lpr PostScript tmp file] > > And of course a Help menu with "g.manual ps.gui", "g.manual ps.map", > "About GUI", "About ps.map", "About GRASS". > > > how does that sound? > > Hamish > -- 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 tlaronde at polynum.com Mon Mar 5 14:57:43 2007 From: tlaronde at polynum.com (tlaronde@polynum.com) Date: Mon Mar 5 14:54:53 2007 Subject: [GRASS-dev] [RFC] Glossary: GISDATABASE -> DATASTORE In-Reply-To: <20070305121113.28f944ae.hamish_nospam@yahoo.com> References: <20070304134132.GA1428@polynum.com> <20070305121113.28f944ae.hamish_nospam@yahoo.com> Message-ID: <20070305135743.GA1005@polynum.com> On Mon, Mar 05, 2007 at 12:11:13PM +1300, Hamish wrote: > Thierry wrote: > > Glossary proposal for gis "database" naming scheme > .. > > Hence I propose to replace GISDATABASE by: DATASTORE. > > DATASTORE is a fine suggestion, the best I've heard so far. See also > email threads discussing the wording of the start-up mapset-picker menu. Thanks for the feed-back, Hamish. I will give a look at the thread you are mentioning. > [about LOCATION_NAME and LOCATION] > > In GPL GRASS 6 LOCATION_NAME is still a GIS variable (stored in > ~/.grassrc6 and not a shell variable*) and viewed/changed with the > g.gisenv module. LOCATION_NAME is just the name, not the path. > GISDBASE has the path. > > The shell variable $LOCATION has been abandoned, but a number of scripts > do this to recreate it: (due to path of least modification after > $LOCATION was dropped) > > > eval `g.gisenv` > : ${GISBASE?} ${GISDBASE?} ${LOCATION_NAME?} ${MAPSET?} > LOCATION="$GISDBASE"/"$LOCATION_NAME"/"$MAPSET" For now in the published versions of KerGIS this is the same: LOCATION has been dropped. What I wanted to say is that, from an user point of view, he enters: g.gisenv MAPSET= but g.gisenv LOCATION_NAME= and this is a frequent error to do: g.gisenv LOCATION= And the user is right: there is a lack of symetry, and if we speak all along about a "location" (implied in the current DATASTORE), its name (and not its pathname) shall be set via LOCATION. Since to add implicit information to the sources, I do a lot of renaming (so that the organization of the sources, and the consistence of naming is, to some extent, self-explanatory), I have introduced in kergis sources the tools/ed directory where I put the correspondence between old name and new name like this (this works for C sources or scripts). For example in this case I will create a tools/ed/sh.ed (the format is : || |GISDBASE|GISDATADIR |GISDATADIR|GISDATABASE |GISDATABASE|DATASTORE [you see in this example that I did not find at first glance the correct name: GISDBASE GISDATADIR GISDBASE was to close to GISBASE so I wanted a more "at first sight" distinct name. But I thought that the data was not really a "database" GISDATADIR GISDATABASE Blunder: the data _is_ organized as a database since there are dedicated functions (GISLIB) to implement a policy and to organize the data. GISDATABASE DATASTORE Yes, databases, but not at the GISDATABASE level: below, at the location. And SQL and PostgreSQL other examples finally made the distinction more clear. ] Then I automatically generate an ed(1) script: g/GISDBASE/s/^GISDBASE$/GISDATADIR/ g/GISDBASE/s/^GISDBASE\([^a-zA-Z0-9_-]\)/GISDATADIR\1/ g/GISDBASE/s/\([^a-zA-Z0-9_-]\)GISDBASE$/\1GISDATADIR/ g/GISDBASE/s/\([^a-zA-Z0-9_-]\)GISDBASE\([^a-zA-Z0-9_-]\)/\1GISDATADIR\2/g g/GISDATADIR/s/^GISDATADIR$/GISDATABASE/ g/GISDATADIR/s/^GISDATADIR\([^a-zA-Z0-9_-]\)/GISDATABASE\1/ g/GISDATADIR/s/\([^a-zA-Z0-9_-]\)GISDATADIR$/\1GISDATABASE/ g/GISDATADIR/s/\([^a-zA-Z0-9_-]\)GISDATADIR\([^a-zA-Z0-9_-]\)/\1GISDATABASE\2/g g/GISDATABASE/s/^GISDATABASE$/DATASTORE/ g/GISDATABASE/s/^GISDATABASE\([^a-zA-Z0-9_-]\)/DATASTORE\1/ g/GISDATABASE/s/\([^a-zA-Z0-9_-]\)GISDATABASE$/\1DATASTORE/ g/GISDATABASE/s/\([^a-zA-Z0-9_-]\)GISDATABASE\([^a-zA-Z0-9_-]\)/\1DATASTORE\2/g w q that is applied on files selected. Just to say that "upgrading" is relatively easy. [In fact, to upgrade from CERL to KerGIS version d.d.d.d you will have to apply in order: sh.ed sh-1.0.0.0 ... {last sh.ed with version < target version}] > > [*] not a shell variable to allow child process (the GUI menus) to > adjust variables which affect the parent, and thus new non-derivative > sibling processes. [e.g. switch mapsets without exiting GRASS] That's another case where I think I will change a name. `.grassrc' or `.kergisrc' are misnamed. This is in fact a _session_. I will go with `.kergis_session'. The session is precisely what you are describing. To come back to the DATASTORE and to a comparison---that is useful for example in teaching---, the good thing is helping to find good ideas. In this case, KerGIS shall clearly (I don't know if GPL GRASS has already made this) implement: g.dump(8) g.restore(8) to dump a location in ascii, and to restore an ascii version of a location to the binary one. I use a lot CVS to store versions of the ascii gis files, and it will be a great archival/transfer even testing and debugging tool (to verify the basic functionnality of a fresh installation, g.restore spearfish for example). It is almost straightforward to do a shell script for that. But the devil is in the details: 1) I would like user kergis (the 'root' superuser of KerGIS) to be able to dump a whole DATASTORE. But individual permissions on directory might prevent this (kergis is not system root; sudo(1) may help in this case); 2) Some part of options found in pg_dump and pg_restore would be useful for CERL GRASS based GIS too, namely to dump in the ascii subdirectory, or to tar (pax) the files for archival or transfer. Once we put at light the rules underlying---and naming is one mean to do that---good suggestions and natural extensions come to mind :) And at the moment, at least KerGIS (GPL GRASS has perhaps made some progress already) is poor in administration tools. Cheers, -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C From tlaronde at polynum.com Mon Mar 5 15:37:42 2007 From: tlaronde at polynum.com (tlaronde@polynum.com) Date: Mon Mar 5 15:34:36 2007 Subject: [GRASS-dev] ps.map consolidation In-Reply-To: References: <20070302180354.5b6fbb6f.hamish_nospam@yahoo.com> <20070305145014.2b4ecedb.hamish_nospam@yahoo.com> Message-ID: <20070305143742.GA2428@polynum.com> Hello, On Mon, Mar 05, 2007 at 02:36:48PM +0100, Jachym Cepicky wrote: > hi, > > > > >some ideas here: > >http://grass.gdf-hannover.de/wiki/GRASS_GUI#Cartography:_GUI_front_end_for_ps.map > > > > > >My idea was to combine both ways, sort of like how QGIS is organized. > >blank preview page on the right side of the GUI (portrait or landscape) > >with solid black border for map box and colored dashed lines for the > >different text/legend boxes. To begin with have those drawn from map > >control placement settings, but in future you could drag those around > >to update the instructions settings (adjust box of currently selected > >instruction for overlap-proofing). In the far-future you would see low > >res preview instead of just rectangles. > > I see the problem in "guessing" the box sizes. e.g. you can place the > legend box somewhere on the paper, but you can not tell, how wide and > height the box will be. That is, why I was proposing to find a > sollution, that each object of the map would be stored in separate > layer, so it could be regenerated ones the user changes some > properity. Please see the message I sent named: Fonts (to be continued). Indeed, the problem is that the rendering (the kerning) done in PostScript exceeds the limited implementation of the rendering text engine in DRAWLIB (RASTERLIB in GPL GRASS). Actually, for example in TeX, when TeX composes a page, it does not deal with the glyphes (the actual drawing of the glyphes) but only with the metric file to know how to compose the bounding boxes. Only the driver put the drawing in the boxes to simplify. One "easy" solution would be to use MetaPOST to compose the label (but in a dedicated mode; it would be too heavy---and useless---for digitizing use) (using Adobe's T1 fonts in TeX), and to retrieve the bounding box information from the EPS file generated: 1) Generated a MetaPOST script from the label specification ; 2) Generate the EPS files with MetaPOST; 3) Retrieve the information about the bounding boxes and put this information in the label description (extending the format of the label files) then use this extra information to draw the bounding boxes. Another trick: create a glyph in the legacy font format with an unit box (1 x 1). Extend the command for the scale to allow separate X and Y scaling. Then use the text commands to draw (display) the glyph of the bounding box with correct X and Y scale, and angle. You're done. For the curious and the courageaous, plugging to some extent TeX in GRASS/KerGIS would lead to something that has simply no equivalent in the GIS world. Caveats: first step would probably be to translate WEB TeX and METAFONT to CWEB (Pascal to C) to allow more easy development of drivers. Pascal is definitively not my cup of tea. DRAWLIB to allow -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C From sieczka at biol.uni.wroc.pl Mon Mar 5 20:14:51 2007 From: sieczka at biol.uni.wroc.pl (Maciej Sieczka) Date: Mon Mar 5 20:14:57 2007 Subject: [GRASS-dev] X monitors display rasters half resolution off to the left Message-ID: <45EC6C2B.20607@biol.uni.wroc.pl> Hi, In Spearfish: $ g.region rast=landuse -a $ d.mon x0 $ d.rast landuse There is a black, vertical artifact line on the right edge of the monitor. $ d.zoom -> out It dissapears... $ d.zoom -> in, until cells are visible With some luck, you will see such artifact line on the right again - different colors. $ d.what.rast Query some left-most non-null cells. If you click their left side, you get null instead of the value you expect. Query the left half of a null cell on the right of some right-most non-null cell. Instead of null, you get the value you'd expect from that non-null cell. Seems like the raster is displayed half resolution off to the left, compared to d.what.rast query results. A recently introduced bug. This is propably the reason of the bug I reported as "r.to.vect feature=lines: the output vector is moved half the resolution east off the input raster" http://wald.intevation.org/tracker/index.php?func=detail&aid=322&group_id=21&atid=204 Maciek From soerengebbert at gmx.de Mon Mar 5 20:36:51 2007 From: soerengebbert at gmx.de (Soeren Gebbert) Date: Mon Mar 5 20:28:13 2007 Subject: [GRASS-dev] X monitors display rasters half resolution off to the left In-Reply-To: <45EC6C2B.20607@biol.uni.wroc.pl> References: <45EC6C2B.20607@biol.uni.wroc.pl> Message-ID: <200703052036.53100.soerengebbert@gmx.de> Hi, i can confirm this bug. http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/GRASS_display_bug.png soeren Am Montag, 5. M?rz 2007 20:14 schrieb Maciej Sieczka: > Hi, > > In Spearfish: > > $ g.region rast=landuse -a > $ d.mon x0 > $ d.rast landuse > > There is a black, vertical artifact line on the right edge of the monitor. > > $ d.zoom -> out > > It dissapears... > > $ d.zoom -> in, until cells are visible > > With some luck, you will see such artifact line on the right again - > different colors. > > $ d.what.rast > > Query some left-most non-null cells. If you click their left side, you > get null instead of the value you expect. > > Query the left half of a null cell on the right of some right-most > non-null cell. Instead of null, you get the value you'd expect from > that non-null cell. > > Seems like the raster is displayed half resolution off to the left, > compared to d.what.rast query results. A recently introduced bug. > > This is propably the reason of the bug I reported as "r.to.vect > feature=lines: the output vector is moved half the resolution east off > the input raster" > > http://wald.intevation.org/tracker/index.php?func=detail&aid=322&group_id=2 >1&atid=204 > > Maciek > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From grass-bugs at intevation.de Mon Mar 5 20:35:56 2007 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Mon Mar 5 20:35:57 2007 Subject: [GRASS-dev] [bug #5200] (grass) d.what.vect -f: WARNING: Color: can't set color 50331648 Message-ID: <20070305193556.872D31005B0@lists.intevation.de> Must have been fixed in CVS recently. The "can't set color" does not pop up anymore and the vector features flash nicely. Great. Maciek -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Mon Mar 5 21:08:37 2007 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Mon Mar 5 21:08:38 2007 Subject: [GRASS-dev] [bug #2741] (grass) NVIZ: fly through navigation controls broken Message-ID: <20070305200837.ADC391006A3@lists.intevation.de> this bug's URL: http://intevation.de/rt/webrt?serial_num=2741 Request number 2741 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,m.cuomo@acsys.it msieczka wrote (Tue, Nov 28 2006 23:26:44): > I need to look into how the xorg.conf's > > Option "Emulate3Buttons" "true" > > affect this issue (this is the default setting in all Linux distros I ever > tried). So I finally checked it. Yes, this is the culprit. For the flythrough NVIZ navigation mouse controls to work correctly one needs to set: Option "Emulate3Buttons" "false" in his X server config to prevent X server from interpretting the mouse left+right buttons as the middle button. "Emulate3Buttons" "true" is often set by deafult in various GNU/Linux distros. Is there a way for NVIZ to somehow ignore this? Maciek -------------------------------------------- Managed by Request Tracker From grass-bugs at intevation.de Mon Mar 5 21:14:24 2007 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Mon Mar 5 21:14:25 2007 Subject: [GRASS-dev] [bug #3069] (grass) r.mapcalc - warning/errorr amibiguity Message-ID: <20070305201424.1ECE81006A3@lists.intevation.de> r.mapcalc still prints this double information in case 2 same called rasters exit within the accesible mapsets, eg.: WARNING: 'cell/map' was found in more mapsets (also found in nic). ERROR: 'cell/map' was found in more mapsets (also found in nic). Moreover, in such case r.mapcalc exits with status 1. Could it be bad for scripts? Maciek -------------------------------------------- Managed by Request Tracker From tutey at o2.pl Mon Mar 5 21:23:13 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Mon Mar 5 21:23:17 2007 Subject: [GRASS-dev] GRASS inefficiency and FFTW In-Reply-To: <188c059d0702260006t373c6110lb09cf21448640d18@mail.gmail.com> References: <188c059d0702260006t373c6110lb09cf21448640d18@mail.gmail.com> Message-ID: <45EC7C31.8050404@o2.pl> Hi, Digging in the old RT I found a message from Glynn about the FFTW and r.surf.fractal, which you might be interested in: https://intevation.de/rt/webrt?serial_num=3098&display=History Best, Maciek From hamish_nospam at yahoo.com Mon Mar 5 23:15:35 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Mar 5 23:16:07 2007 Subject: [GRASS-dev] X monitors display rasters half resolution off to the left In-Reply-To: <45EC6C2B.20607@biol.uni.wroc.pl> References: <45EC6C2B.20607@biol.uni.wroc.pl> Message-ID: <20070306111535.326d7398.hamish_nospam@yahoo.com> Maciej Sieczka wrote: > In Spearfish: > > $ g.region rast=landuse -a > $ d.mon x0 > $ d.rast landuse > > There is a black, vertical artifact line on the right edge of the > monitor. I see it too, in 6.3cvs but not 6.2.1. drag the xmon to be twice as wide as it is tall to see the grey band clearly. Hamish From hamish_nospam at yahoo.com Mon Mar 5 23:38:51 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Mar 5 23:39:25 2007 Subject: [GRASS-dev] ps.map consolidation In-Reply-To: References: <20070302180354.5b6fbb6f.hamish_nospam@yahoo.com> <20070305145014.2b4ecedb.hamish_nospam@yahoo.com> Message-ID: <20070306113851.39b3cbe5.hamish_nospam@yahoo.com> Jachym Cepicky wrote: > > some ideas here: > > http://grass.gdf-hannover.de/wiki/GRASS_GUI#Cartography:_GUI_front_end_for_ps.map > > > > My idea was to combine both ways, sort of like how QGIS is > > organized. blank preview page on the right side of the GUI (portrait > > or landscape) with solid black border for map box and colored dashed > > lines for the different text/legend boxes. To begin with have those > > drawn from map control placement settings, but in future you could > > drag those around to update the instructions settings (adjust box of > > currently selected instruction for overlap-proofing). In the > > far-future you would see low res preview instead of just rectangles. > > I see the problem in "guessing" the box sizes. e.g. you can place the > legend box somewhere on the paper, but you can not tell, how wide and > height the box will be. That is, why I was proposing to find a > sollution, that each object of the map would be stored in separate > layer, so it could be regenerated ones the user changes some > properity. You don't have to guess the box sizes at all. The only tricky part is to recreate the scale-> map size calculation, which isn't so hard to do. (I was doing this by hand in the last month while fixing bugs #3096 and 5454) for things like legend box, we know the page size in inches, and the x,y offset in inches, and the height/width in inches (and can look up the defaults), so no guessing there either. some more work is needed for e.g. the scalebar which is places by its center not its top left corner. so just a bunch of 1-2-3-4 work, not guess work. ? > I did something, what you are proposing allready, some months ago: > http://wwwold.fle.czu.cz/~jachym/img/grass/gpsmap-0.1.2.png but as I > said, it was hard to determine the box dimensions.. ah yes, exactly. so not so much my idea at all. :) > I like the rest, you are writing, nice concept. Only the list of > layers should be taken from current map display I think that could be added in a future prototype, along with loading of a prior ps.map instructions file. It is nice, but not specifically needed to run the program. Hamish From hamish_nospam at yahoo.com Mon Mar 5 23:24:29 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Mar 5 23:39:41 2007 Subject: [GRASS-dev] [bug #3069] (grass) r.mapcalc - warning/errorr amibiguity In-Reply-To: <20070305201424.1ECE81006A3@lists.intevation.de> References: <20070305201424.1ECE81006A3@lists.intevation.de> Message-ID: <20070306112429.203104e3.hamish_nospam@yahoo.com> Maciek Sieczka via RT wrote: > > r.mapcalc still prints this double information in case 2 same called > rasters exit within the accesible mapsets, eg.: > > WARNING: 'cell/map' was found in more mapsets (also found in nic). > ERROR: 'cell/map' was found in more mapsets (also found in nic). > > Moreover, in such case r.mapcalc exits with status 1. Could it be bad > for scripts? (not commenting on the bug, just the symptoms) exit code of 1 is appropriate if the module exited with an ERROR. If the system found an ambiguity, it is better to stop with an error than pick the wrong map and potentially mess up the data without the user noticing. Hamish From neteler at itc.it Mon Mar 5 23:43:40 2007 From: neteler at itc.it (Markus Neteler) Date: Mon Mar 5 23:43:42 2007 Subject: [GRASS-dev] X monitors display rasters half resolution off to the left In-Reply-To: <20070306111535.326d7398.hamish_nospam@yahoo.com> References: <45EC6C2B.20607@biol.uni.wroc.pl> <20070306111535.326d7398.hamish_nospam@yahoo.com> Message-ID: <20070305224340.GA13443@bartok.itc.it> On Tue, Mar 06, 2007 at 11:15:35AM +1300, Hamish wrote: > Maciej Sieczka wrote: > > In Spearfish: > > > > $ g.region rast=landuse -a > > $ d.mon x0 > > $ d.rast landuse > > > > There is a black, vertical artifact line on the right edge of the > > monitor. > > I see it too, in 6.3cvs but not 6.2.1. > > drag the xmon to be twice as wide as it is tall to see the grey band > clearly. Could http://mpa.itc.it/markus/tmp/admin98_oceans_buggy.png be related to this (latlong)? I also tried to export the oceans only with v.overlay, the result looks strange (wrong polygon fill, too). Markus From hamish_nospam at yahoo.com Tue Mar 6 02:02:12 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Mar 6 02:02:19 2007 Subject: [GRASS-dev] [RFC] Glossary: GISDATABASE -> DATASTORE In-Reply-To: <20070305135743.GA1005@polynum.com> References: <20070304134132.GA1428@polynum.com> <20070305121113.28f944ae.hamish_nospam@yahoo.com> <20070305135743.GA1005@polynum.com> Message-ID: <20070306140212.181a45fe.hamish_nospam@yahoo.com> tlaronde@polynum.com wrote: > > g.gisenv MAPSET= > > but > g.gisenv LOCATION_NAME= > > and this is a frequent error to do: > > g.gisenv LOCATION= > > And the user is right: there is a lack of symetry, and if we speak all > along about a "location" (implied in the current DATASTORE), its name > (and not its pathname) shall be set via LOCATION. LOCATION makes more sense if doing it cleanly, but I believe it was named something different (_NAME) to limit bugs during the transition. There is always user confusion about shell variables vs. grass variables, to have two different things using the same name would have been bad. As this variable isn't typically seen by the user (it is handled by the g.mapset module in GRASS 6+), the extra _NAME part does more good than harm I think. Call it a historically beneficial wart. By GRASS 7 probably enough time has passed to rename it "LOCATION". > To come back to the DATASTORE and to a comparison---that is useful for > example in teaching---, the good thing is helping to find good ideas. > In this case, KerGIS shall clearly (I don't know if GPL GRASS has > already made this) implement: > > g.dump(8) > g.restore(8) > > to dump a location in ascii, and to restore an ascii version of a > location to the binary one. I use a lot CVS to store versions of the > ascii gis files, and it will be a great archival/transfer even testing > and debugging tool (to verify the basic functionnality of a fresh > installation, g.restore spearfish for example). is that just saving the projection settings & default region info found in PERMANENT/, or is it a full "tar czf spearfish.tgz spearfish/" ? r.out.ascii, v.out.ascii all maps? Hamish From glynn at gclements.plus.com Tue Mar 6 02:53:01 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Mar 6 02:53:05 2007 Subject: [GRASS-dev] [bug #2741] (grass) NVIZ: fly through navigation controls broken In-Reply-To: <20070305200837.ADC391006A3@lists.intevation.de> References: <20070305200837.ADC391006A3@lists.intevation.de> Message-ID: <17900.51581.213455.199426@cerise.gclements.plus.com> Maciek Sieczka via RT wrote: > this bug's URL: http://intevation.de/rt/webrt?serial_num=2741 > > Request number 2741 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,m.cuomo@acsys.it > > msieczka wrote (Tue, Nov 28 2006 23:26:44): > > > I need to look into how the xorg.conf's > > > > Option "Emulate3Buttons" "true" > > > > affect this issue (this is the default setting in all Linux distros I ever > > tried). > > So I finally checked it. Yes, this is the culprit. For the flythrough NVIZ > navigation mouse controls to work correctly one needs to set: > > Option "Emulate3Buttons" "false" > > in his X server config to prevent X server from interpretting the mouse > left+right buttons as the middle button. "Emulate3Buttons" "true" is often set > by deafult in various GNU/Linux distros. Is there a way for NVIZ to somehow > ignore this? No. The only option is to change the NVIZ bindings so that it doesn't require LMB+RMB to be pressed simultaneously. Incidentally, this combination is typically impossible with laptops which use a touchpad instead of a mouse; there's normally a key which can be pressed to make the touchpad generate RMB events instead of LMB, but you can't get both simultaneously. -- Glynn Clements From glynn at gclements.plus.com Tue Mar 6 03:06:20 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Mar 6 03:06:21 2007 Subject: [GRASS-dev] [bug #3069] (grass) r.mapcalc - warning/errorr amibiguity In-Reply-To: <20070305201424.1ECE81006A3@lists.intevation.de> References: <20070305201424.1ECE81006A3@lists.intevation.de> Message-ID: <17900.52380.109898.776650@cerise.gclements.plus.com> Maciek Sieczka via RT wrote: > r.mapcalc still prints this double information in case 2 same called rasters > exit within the accesible mapsets, eg.: > > WARNING: 'cell/map' was found in more mapsets (also found in nic). > ERROR: 'cell/map' was found in more mapsets (also found in nic). r.mapcalc uses G_set_error_routine() to install an error handler; the error handler calls G_fatal_error() regardless of the value of the "fatal" argument. I'll fix this. > Moreover, in such case r.mapcalc exits with status 1. Could it be bad for scripts? This is correct for an error. -- Glynn Clements From glynn at gclements.plus.com Tue Mar 6 03:21:30 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Mar 6 03:21:33 2007 Subject: [GRASS-dev] X monitors display rasters half resolution off to the left In-Reply-To: <45EC6C2B.20607@biol.uni.wroc.pl> References: <45EC6C2B.20607@biol.uni.wroc.pl> Message-ID: <17900.53290.589769.815960@cerise.gclements.plus.com> Maciej Sieczka wrote: > In Spearfish: > > $ g.region rast=landuse -a > $ d.mon x0 > $ d.rast landuse > > There is a black, vertical artifact line on the right edge of the monitor. Okay; I'm fairly sure that this was introduced with my changes to the display/raster libraries, specifically the addition and use of R_scaled_raster(). What I'm less of is whether I introduced a new off-by-one bug or fixed one which was being cancelled out by another bug elsewhere. In any case, I'll look into it now. -- Glynn Clements From tlaronde at polynum.com Tue Mar 6 04:00:53 2007 From: tlaronde at polynum.com (tlaronde@polynum.com) Date: Tue Mar 6 03:57:47 2007 Subject: [GRASS-dev] [RFC] Glossary: GISDATABASE -> DATASTORE In-Reply-To: <20070306140212.181a45fe.hamish_nospam@yahoo.com> References: <20070304134132.GA1428@polynum.com> <20070305121113.28f944ae.hamish_nospam@yahoo.com> <20070305135743.GA1005@polynum.com> <20070306140212.181a45fe.hamish_nospam@yahoo.com> Message-ID: <20070306030053.GA11048@polynum.com> On Tue, Mar 06, 2007 at 02:02:12PM +1300, Hamish wrote: > > > g.dump(8) > > g.restore(8) > > > > to dump a location in ascii, and to restore an ascii version of a > > location to the binary one. I use a lot CVS to store versions of the > > ascii gis files, and it will be a great archival/transfer even testing > > and debugging tool (to verify the basic functionnality of a fresh > > installation, g.restore spearfish for example). > > is that just saving the projection settings & default region info found > in PERMANENT/, or is it a full "tar czf spearfish.tgz spearfish/" ? > r.out.ascii, v.out.ascii all maps? Yes, as PostgreSQL pg_dump(8) and pg_restore(8), it will dump in ascii the binary files (raster, vector and other types if any) on all the MAPSETs in the LOCATION, and restore will rebuild everything (this means that not only the geometry in ascii is saved [case tar or pax], but this includes the cats, atts [or whatever they are called]; all the ascii (or text) files needed to restore a complete compiled (binary) version of the LOCATION). These text files are typically what has to be saved in a CVS. -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C From glynn at gclements.plus.com Tue Mar 6 05:47:35 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Mar 6 05:47:39 2007 Subject: [GRASS-dev] X monitors display rasters half resolution off to the left In-Reply-To: <17900.53290.589769.815960@cerise.gclements.plus.com> References: <45EC6C2B.20607@biol.uni.wroc.pl> <17900.53290.589769.815960@cerise.gclements.plus.com> Message-ID: <17900.62055.16994.394740@cerise.gclements.plus.com> Glynn Clements wrote: > Maciej Sieczka wrote: > > > In Spearfish: > > > > $ g.region rast=landuse -a > > $ d.mon x0 > > $ d.rast landuse > > > > There is a black, vertical artifact line on the right edge of the monitor. > > Okay; I'm fairly sure that this was introduced with my changes to the > display/raster libraries, specifically the addition and use of > R_scaled_raster(). > > What I'm less of is whether I introduced a new off-by-one bug or fixed > one which was being cancelled out by another bug elsewhere. The former. > In any case, I'll look into it now. Fixed in CVS, AFAICT. -- Glynn Clements From glynn at gclements.plus.com Tue Mar 6 06:03:43 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Mar 6 06:03:45 2007 Subject: [GRASS-dev] [RFC] Glossary: GISDATABASE -> DATASTORE In-Reply-To: <20070306140212.181a45fe.hamish_nospam@yahoo.com> References: <20070304134132.GA1428@polynum.com> <20070305121113.28f944ae.hamish_nospam@yahoo.com> <20070305135743.GA1005@polynum.com> <20070306140212.181a45fe.hamish_nospam@yahoo.com> Message-ID: <17900.63023.466343.41718@cerise.gclements.plus.com> Hamish wrote: > > g.gisenv MAPSET= > > > > but > > g.gisenv LOCATION_NAME= > > > > and this is a frequent error to do: > > > > g.gisenv LOCATION= > > > > And the user is right: there is a lack of symetry, and if we speak all > > along about a "location" (implied in the current DATASTORE), its name > > (and not its pathname) shall be set via LOCATION. > > LOCATION makes more sense if doing it cleanly, but I believe it was > named something different (_NAME) to limit bugs during the transition. > There is always user confusion about shell variables vs. grass > variables, And, it seems, some developer confusion about shell variables versus environment variables. Also, it doesn't help that the documentation used to refer to GRASS variables as environment variables. > to have two different things using the same name would have > been bad. > > As this variable isn't typically seen by the user (it is handled by the > g.mapset module in GRASS 6+), the extra _NAME part does more good than > harm I think. Call it a historically beneficial wart. > > By GRASS 7 probably enough time has passed to rename it "LOCATION". Actually, I'd say that enough time has already passed. We stopped exporting GRASS variables to the environment nearly 5 years ago: RCS file: /grassrepository/grass/src/general/g.gisenv/main.c,v revision 1.4 date: 2002/03/26 13:25:09; author: glynn; state: Exp; lines: +3 -3 branches: 1.4.2; Don't export GISDBASE, LOCATION_NAME, MAPSET, LOCATION to the environment Fix scripts to obtain settings from g.gisenv RCS file: /grassrepository/grass/src/general/init/init.sh,v revision 1.36 date: 2002/03/26 13:25:10; author: glynn; state: Exp; lines: +2 -8 branches: 1.36.2; Don't export GISDBASE, LOCATION_NAME, MAPSET, LOCATION to the environment Fix scripts to obtain settings from g.gisenv And the GRASS variable has been called LOCATION_NAME for at least as long as GRASS has been in CVS (1999-12-29). The main issue is that we would have to fix all of the shell scripts which use LOCATION as the path to the mapset directory and expect "eval `g.gisenv`" to store the location in LOCATION_NAME rather than in LOCATION. But that's equally true whether we change it now or later. -- Glynn Clements From hamish_nospam at yahoo.com Tue Mar 6 06:39:16 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Mar 6 06:40:10 2007 Subject: [GRASS-dev] [RFC] Glossary: GISDATABASE -> DATASTORE In-Reply-To: <17900.63023.466343.41718@cerise.gclements.plus.com> References: <20070304134132.GA1428@polynum.com> <20070305121113.28f944ae.hamish_nospam@yahoo.com> <20070305135743.GA1005@polynum.com> <20070306140212.181a45fe.hamish_nospam@yahoo.com> <17900.63023.466343.41718@cerise.gclements.plus.com> Message-ID: <20070306183916.4bcc93e1.hamish_nospam@yahoo.com> Glynn Clements wrote: > And the GRASS variable has been called LOCATION_NAME for at least as > long as GRASS has been in CVS (1999-12-29). > > The main issue is that we would have to fix all of the shell scripts > which use LOCATION as the path to the mapset directory and expect > "eval `g.gisenv`" to store the location in LOCATION_NAME rather than > in LOCATION. But that's equally true whether we change it now or > later. c.22 scripts and lib/init/init.sh grass63/scripts$ grep -rI LOCATION * | wc -l 83 grass63/scripts$ grep -rI LOCATION_NAME * | wc -l 53 grass63/scripts$ grep -rI LOCATION * | cut -f1 -d: | uniq d.rast.leg/d.rast.leg d.slide.show/d.slide.show g.mremove/g.mremove g.mremove/g.mremove1 i.image.mosaic/i.image.mosaic i.in.spotvgt/i.in.spotvgt i.oif/i.oif r.fillnulls/r.fillnulls r.in.srtm/r.in.srtm r.mask/r.mask r.plane/r.plane v.build.all/v.build.all v.convert.all/v.convert.all v.db.addtable/v.db.addtable v.db.reconnect.all/v.db.reconnect.all v.in.e00/v.in.e00 v.in.garmin/v.in.garmin v.in.gns/v.in.gns v.in.gpsbabel/v.in.gpsbabel v.in.mapgen/v.in.mapgen v.in.sites.all/v.in.sites.all v.report/v.report Hamish From mlennert at club.worldonline.be Tue Mar 6 09:45:01 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Tue Mar 6 09:42:16 2007 Subject: [GRASS-dev] [bug #3069] (grass) r.mapcalc - warning/errorr amibiguity In-Reply-To: <20070306112429.203104e3.hamish_nospam@yahoo.com> References: <20070305201424.1ECE81006A3@lists.intevation.de> <20070306112429.203104e3.hamish_nospam@yahoo.com> Message-ID: <45ED2A0D.4090403@club.worldonline.be> On 05/03/07 23:24, Hamish wrote: > Maciek Sieczka via RT wrote: >> r.mapcalc still prints this double information in case 2 same called >> rasters exit within the accesible mapsets, eg.: >> >> WARNING: 'cell/map' was found in more mapsets (also found in nic). As I've mentioned before somewhere, I find this message a bit confusing, especially the "also found in" which normally gives me the mapset I am in and want to use the map of (at least it does so when in mapset user1 of spearfish working on a local copy of a map which is also in PERMANENT). Couldn't this be changed so that it mentions the _other_ mapsets the map is in, and maybe mention which map is used by default (I know that in this case it stops with an error, but many other modules just emit this as a warning, leaving the user uninformed of which map was used) ? Moritz From tlaronde at polynum.com Tue Mar 6 10:27:36 2007 From: tlaronde at polynum.com (tlaronde@polynum.com) Date: Tue Mar 6 10:24:47 2007 Subject: [GRASS-dev] [RFC] Glossary: GISDATABASE -> DATASTORE In-Reply-To: <20070306183916.4bcc93e1.hamish_nospam@yahoo.com> References: <20070304134132.GA1428@polynum.com> <20070305121113.28f944ae.hamish_nospam@yahoo.com> <20070305135743.GA1005@polynum.com> <20070306140212.181a45fe.hamish_nospam@yahoo.com> <17900.63023.466343.41718@cerise.gclements.plus.com> <20070306183916.4bcc93e1.hamish_nospam@yahoo.com> Message-ID: <20070306092736.GA169@polynum.com> On Tue, Mar 06, 2007 at 06:39:16PM +1300, Hamish wrote: > > grass63/scripts$ grep -rI LOCATION * | wc -l > 83 > grass63/scripts$ grep -rI LOCATION_NAME * | wc -l > 53 > [..] Well, for the scripts (or the programs), this is not, whether for GRASS/KerGIS core programs or users' programs, a problem: ed(1) does the job easily. If the CHANGES are conspicuous, this will not come as a big surprise. But it should come with a major change in the version number (that's one of the reason why I have still not release an official 1.0: I want to make all the "dramatic" changes once, to keep the 1.x family relatively stable on the naming scheme at least). I think, if we reflect about the naming scheme (LOCATION is one element; DATASTORE is another etc.) we should try to bundle the name changes in one step. From a pedagogical and practical point of view, the benefits clearly exceed the cons. If the legacy is not consistent, it shall be changed. Cheers, -- Thierry Laronde (Alceste) http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C From wegmann at biozentrum.uni-wuerzburg.de Tue Mar 6 10:49:10 2007 From: wegmann at biozentrum.uni-wuerzburg.de (Martin Wegmann) Date: Tue Mar 6 10:48:50 2007 Subject: [GRASS-dev] Fwd: OSGeo: Call for articles Message-ID: <200703061049.12094.wegmann@biozentrum.uni-wuerzburg.de> ------ From: tylermitchell@shaw.ca Subject: Call for articles - OSGeo Newsletter Date: March 5, 2007 11:14:56 AM PST (CA) The OSGeo Newsletter development team invites you to contribute news, articles, event summaries, programming tutorials and more for the upcoming OSGeo News - Volume 1. There are several sections planned for the newsletter. General descriptions of each category can be found on the Newsletter wiki page [1]. Specific committed articles are listed on the Newsletter Volume 1 wiki page [2]. There has been already been a lot of interest to contribute articles and some sections are already quite full. You are welcome to propose an article for any section, but we are specifically looking for more articles in the following categories: * News - any particularly newsworthy items you would like to pass along * Event Reports - have a conference summary that you would like to share? * Topical Studies - introduce a theoretical topic that is of general interest * Programming Tutorials - serving as an introduction to coding an application or task * Interview - conduct an interview with someone in the community * Developer Announcements - brief summaries of what your project team has been doing recently and future outlook for the project To volunteer for an article add your name and article title to the Volume 1 wiki page in the appropriate category, along with contact information. Or join the Newsletter mailing list [3] and tell us about your idea. An editor will follow-up with you to arrange delivery and timing. Articles need to be delivered by March 23st. Length can vary depending on type of article and should be discussed with the editor for your category. If you want to contribute but a particular category is full (or you need more time), you are more than welcome to add yourself to the list of articles for the subsequent volume, Volume 2 [4]. We look forward to working with you on producing a great newsletter that is of interest to everyone in our communities and beyond. Sincerely, Tyler [1] Newsletter general wiki page: http://wiki.osgeo.org/index.php/ Newsletter [2] Newsletter Volume 1 wiki page: http://wiki.osgeo.org/index.php/ Newsletter_Volume_1 [3] Newsletter development mailing list: http://lists.osgeo.org/ mailman/listinfo/newsletter [4] Newsletter Volume 2 (future): http://wiki.osgeo.org/index.php/ Newsletter_Volume_2 From glynn at gclements.plus.com Tue Mar 6 11:45:28 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Mar 6 11:45:31 2007 Subject: [GRASS-dev] [bug #3069] (grass) r.mapcalc - warning/errorr amibiguity In-Reply-To: <45ED2A0D.4090403@club.worldonline.be> References: <20070305201424.1ECE81006A3@lists.intevation.de> <20070306112429.203104e3.hamish_nospam@yahoo.com> <45ED2A0D.4090403@club.worldonline.be> Message-ID: <17901.17992.96494.722986@cerise.gclements.plus.com> Moritz Lennert wrote: > >> r.mapcalc still prints this double information in case 2 same called > >> rasters exit within the accesible mapsets, eg.: > >> > >> WARNING: 'cell/map' was found in more mapsets (also found in nic). > > As I've mentioned before somewhere, I find this message a bit confusing, > especially the "also found in" which normally gives me the mapset I am > in and want to use the map of (at least it does so when in mapset user1 > of spearfish working on a local copy of a map which is also in PERMANENT). > > Couldn't this be changed so that it mentions the _other_ mapsets the map > is in, and maybe mention which map is used by default (I know that in > this case it stops with an error, but many other modules just emit this > as a warning, leaving the user uninformed of which map was used) ? I've changed it so that it identifies all of the mapsets involved, e.g.: $ r.resample in=fields out=fields Creating support files for fields... creating new cats file... $ r.mapcalc foo = fields WARNING: 'cell/fields' was found in more mapsets (also found in PERMANENT). WARNING: using 'fields@glynn'. -- Glynn Clements From mlennert at club.worldonline.be Tue Mar 6 11:59:45 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Tue Mar 6 11:57:00 2007 Subject: [GRASS-dev] [bug #3069] (grass) r.mapcalc - warning/errorr amibiguity In-Reply-To: <17901.17992.96494.722986@cerise.gclements.plus.com> References: <20070305201424.1ECE81006A3@lists.intevation.de> <20070306112429.203104e3.hamish_nospam@yahoo.com> <45ED2A0D.4090403@club.worldonline.be> <17901.17992.96494.722986@cerise.gclements.plus.com> Message-ID: <45ED49A1.5040002@club.worldonline.be> On 06/03/07 11:45, Glynn Clements wrote: > Moritz Lennert wrote: > >>>> r.mapcalc still prints this double information in case 2 same called >>>> rasters exit within the accesible mapsets, eg.: >>>> >>>> WARNING: 'cell/map' was found in more mapsets (also found in nic). >> As I've mentioned before somewhere, I find this message a bit confusing, >> especially the "also found in" which normally gives me the mapset I am >> in and want to use the map of (at least it does so when in mapset user1 >> of spearfish working on a local copy of a map which is also in PERMANENT). >> >> Couldn't this be changed so that it mentions the _other_ mapsets the map >> is in, and maybe mention which map is used by default (I know that in >> this case it stops with an error, but many other modules just emit this >> as a warning, leaving the user uninformed of which map was used) ? > > I've changed it so that it identifies all of the mapsets involved, > e.g.: > > $ r.resample in=fields out=fields > Creating support files for fields... > creating new cats file... > $ r.mapcalc foo = fields > WARNING: 'cell/fields' was found in more mapsets (also found in PERMANENT). > WARNING: using 'fields@glynn'. > Great, thanks ! Moritz From benjamin.ducke at ufg.uni-kiel.de Tue Mar 6 15:57:17 2007 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Tue Mar 6 15:42:47 2007 Subject: [GRASS-dev] VTK export for lat-long locations Message-ID: <45ED814D.6010209@ufg.uni-kiel.de> Hi everyone, I just tested r.out.vtk in a lat-long location and all I got when I loaded the VTK file in Paraview (2.6.0), was a single line of data projecting through the origin of the coordinate system. Does anyone have any experiences with VTK/Paraview and lat-long data? Thanks, Benjamin -- Benjamin Ducke, M.A. Arch?oinformatik (Archaeoinformation Science) Institut f?r Ur- und Fr?hgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universit?t zu Kiel Johanna-Mestorf-Stra?e 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg From soerengebbert at gmx.de Tue Mar 6 16:08:13 2007 From: soerengebbert at gmx.de (=?iso-8859-1?Q?=22S=F6ren_Gebbert=22?=) Date: Tue Mar 6 16:08:17 2007 Subject: Fwd: Re: [GRASS-dev] VTK export for lat-long locations Message-ID: <20070306150813.116740@gmx.net> -------- Original-Nachricht -------- Datum: Tue, 06 Mar 2007 16:06:18 +0100 Von: "S?ren Gebbert" An: Benjamin Ducke CC: Betreff: Re: [GRASS-dev] VTK export for lat-long locations Hi Benjamin, please dont use the vtk export modules with lat/lon projections. The vtk export modules in grass are not usable with lat/lon projections right now. I think i should put this info to the html docs. The lat/lon coordiantes are used to define the coordinates for each point. VTK interpret these coordinates as planimetric and not as lat/lon. This is not that bad for x,y coordinates, but for the height (z coordinate). Because if x and y lat/lon coordiantes are of type [54.001/34.002] and the height varies from 0m - 500m you will get a senseless result. I still dont know exactly how to implement a meaningful lat/lon ->planimetric coordinate transformation to get rid fo this behaviour. Any suggestions are welcome. Best regards Soeren -------- Original-Nachricht -------- Datum: Tue, 06 Mar 2007 15:57:17 +0100 Von: Benjamin Ducke An: GRASS devel CC: Betreff: [GRASS-dev] VTK export for lat-long locations > Hi everyone, > > I just tested r.out.vtk in a lat-long location and all I got when I > loaded the VTK file in Paraview (2.6.0), was a single line of data > projecting through the origin of the coordinate system. > > Does anyone have any experiences with VTK/Paraview and lat-long data? > > Thanks, > > Benjamin > > > -- > Benjamin Ducke, M.A. > Arch?oinformatik > (Archaeoinformation Science) > Institut f?r Ur- und Fr?hgeschichte > (Inst. of Prehistoric and Historic Archaeology) > Christian-Albrechts-Universit?t zu Kiel > Johanna-Mestorf-Stra?e 2-6 > D 24098 Kiel > Germany > > Tel.: ++49 (0)431 880-3378 / -3379 > Fax : ++49 (0)431 880-7300 > www.uni-kiel.de/ufg > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal f?r Modem und ISDN: http://www.gmx.net/de/go/smartsurfer From benjamin.ducke at ufg.uni-kiel.de Tue Mar 6 16:45:14 2007 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Tue Mar 6 16:30:42 2007 Subject: Fwd: Re: [GRASS-dev] VTK export for lat-long locations In-Reply-To: <20070306150813.116740@gmx.net> References: <20070306150813.116740@gmx.net> Message-ID: <45ED8C8A.2060400@ufg.uni-kiel.de> Wow, that explains the result I got! So I guess you need to know exactly how many meters a lat/long cell dimension is in the current projection, so you can scale the Z axis accordingly? Does this vary between cells? Does GRASS have a function to calculate metric lengths between two points in a lat-long system? If so, I guess you would need to take the the metric distance between corner points of a lat-long cell and use the value for Z axis scaling? S?ren Gebbert wrote: > -------- Original-Nachricht -------- > Datum: Tue, 06 Mar 2007 16:06:18 +0100 > Von: "S?ren Gebbert" > An: Benjamin Ducke > CC: > Betreff: Re: [GRASS-dev] VTK export for lat-long locations > > Hi Benjamin, > please dont use the vtk export modules with lat/lon projections. > The vtk export modules in grass are not > usable with lat/lon projections right now. > I think i should put this info to the html docs. > > The lat/lon coordiantes are used to define the coordinates for each point. > VTK interpret these coordinates as planimetric and not as lat/lon. > This is not that bad for x,y coordinates, but for the height (z coordinate). > Because if x and y lat/lon coordiantes are of type [54.001/34.002] and the > height varies from 0m - 500m you will get a senseless result. > > I still dont know exactly how to implement a meaningful > lat/lon ->planimetric coordinate transformation to get rid > fo this behaviour. > > Any suggestions are welcome. > > Best regards > Soeren > > > -------- Original-Nachricht -------- > Datum: Tue, 06 Mar 2007 15:57:17 +0100 > Von: Benjamin Ducke > An: GRASS devel > CC: > Betreff: [GRASS-dev] VTK export for lat-long locations > >> Hi everyone, >> >> I just tested r.out.vtk in a lat-long location and all I got when I >> loaded the VTK file in Paraview (2.6.0), was a single line of data >> projecting through the origin of the coordinate system. >> >> Does anyone have any experiences with VTK/Paraview and lat-long data? >> >> Thanks, >> >> Benjamin >> >> >> -- >> Benjamin Ducke, M.A. >> Arch?oinformatik >> (Archaeoinformation Science) >> Institut f?r Ur- und Fr?hgeschichte >> (Inst. of Prehistoric and Historic Archaeology) >> Christian-Albrechts-Universit?t zu Kiel >> Johanna-Mestorf-Stra?e 2-6 >> D 24098 Kiel >> Germany >> >> Tel.: ++49 (0)431 880-3378 / -3379 >> Fax : ++49 (0)431 880-7300 >> www.uni-kiel.de/ufg >> >> _______________________________________________ >> grass-dev mailing list >> grass-dev@grass.itc.it >> http://grass.itc.it/mailman/listinfo/grass-dev > -- Benjamin Ducke, M.A. Arch?oinformatik (Archaeoinformation Science) Institut f?r Ur- und Fr?hgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universit?t zu Kiel Johanna-Mestorf-Stra?e 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg From neteler at itc.it Tue Mar 6 16:43:07 2007 From: neteler at itc.it (Markus Neteler) Date: Tue Mar 6 16:43:08 2007 Subject: Fwd: Re: [GRASS-dev] VTK export for lat-long locations In-Reply-To: <45ED8C8A.2060400@ufg.uni-kiel.de> References: <20070306150813.116740@gmx.net> <45ED8C8A.2060400@ufg.uni-kiel.de> Message-ID: <45ED8C0B.9050901@itc.it> Benjamin Ducke wrote on 03/06/2007 04:45 PM: > Wow, that explains the result I got! > So I guess you need to know exactly how many meters a lat/long cell > dimension is in the current projection, so you can scale the Z axis > accordingly? > Does this vary between cells? Does GRASS have a function to calculate > metric lengths between two points in a lat-long system? In v.to.db we solved that problem some months ago. The function is Vect_line_geodesic_length() which is found in lib/vector/Vlib/line.c markus > If so, I guess > you would need to take the the metric distance between corner points of > a lat-long cell and use the value for Z axis scaling? > > S?ren Gebbert wrote: > >> -------- Original-Nachricht -------- >> Datum: Tue, 06 Mar 2007 16:06:18 +0100 >> Von: "S?ren Gebbert" >> An: Benjamin Ducke >> CC: >> Betreff: Re: [GRASS-dev] VTK export for lat-long locations >> >> Hi Benjamin, >> please dont use the vtk export modules with lat/lon projections. >> The vtk export modules in grass are not >> usable with lat/lon projections right now. >> I think i should put this info to the html docs. >> >> The lat/lon coordiantes are used to define the coordinates for each point. >> VTK interpret these coordinates as planimetric and not as lat/lon. >> This is not that bad for x,y coordinates, but for the height (z coordinate). >> Because if x and y lat/lon coordiantes are of type [54.001/34.002] and the >> height varies from 0m - 500m you will get a senseless result. >> >> I still dont know exactly how to implement a meaningful >> lat/lon ->planimetric coordinate transformation to get rid >> fo this behaviour. >> >> Any suggestions are welcome. >> >> Best regards >> Soeren >> >> >> -------- Original-Nachricht -------- >> Datum: Tue, 06 Mar 2007 15:57:17 +0100 >> Von: Benjamin Ducke >> An: GRASS devel >> CC: >> Betreff: [GRASS-dev] VTK export for lat-long locations >> >> >>> Hi everyone, >>> >>> I just tested r.out.vtk in a lat-long location and all I got when I >>> loaded the VTK file in Paraview (2.6.0), was a single line of data >>> projecting through the origin of the coordinate system. >>> >>> Does anyone have any experiences with VTK/Paraview and lat-long data? >>> >>> Thanks, >>> >>> Benjamin >>> >>> >>> -- >>> Benjamin Ducke, M.A. >>> Arch?oinformatik >>> (Archaeoinformation Science) >>> Institut f?r Ur- und Fr?hgeschichte >>> (Inst. of Prehistoric and Historic Archaeology) >>> Christian-Albrechts-Universit?t zu Kiel >>> Johanna-Mestorf-Stra?e 2-6 >>> D 24098 Kiel >>> Germany >>> >>> Tel.: ++49 (0)431 880-3378 / -3379 >>> Fax : ++49 (0)431 880-7300 >>> www.uni-kiel.de/ufg >>> >>> _______________________________________________ >>> grass-dev mailing list >>> grass-dev@grass.itc.it >>> http://grass.itc.it/mailman/listinfo/grass-dev >>> > > From soerengebbert at gmx.de Tue Mar 6 16:46:57 2007 From: soerengebbert at gmx.de (=?iso-8859-1?Q?=22S=F6ren_Gebbert=22?=) Date: Tue Mar 6 16:46:59 2007 Subject: Fwd: Re: [GRASS-dev] VTK export for lat-long locations In-Reply-To: <45ED8C8A.2060400@ufg.uni-kiel.de> References: <20070306150813.116740@gmx.net> <45ED8C8A.2060400@ufg.uni-kiel.de> Message-ID: <20070306154657.116710@gmx.net> Hi Benjamin, -------- Original-Nachricht -------- Datum: Tue, 06 Mar 2007 16:45:14 +0100 Von: Benjamin Ducke An: CC: grass-dev@grass.itc.it Betreff: Re: Fwd: Re: [GRASS-dev] VTK export for lat-long locations > Wow, that explains the result I got! > So I guess you need to know exactly how many meters a lat/long cell > dimension is in the current projection, so you can scale the Z axis > accordingly? Yes, thats the point. And i need to know where to start. > Does this vary between cells? Does GRASS have a function to calculate It changes with every raster row. > metric lengths between two points in a lat-long system? If so, I guess > you would need to take the the metric distance between corner points of > a lat-long cell and use the value for Z axis scaling? AFAIK these functions are implemented in grass (lib/gis/area* and stuff). The point is, im not very familiar with this kind of coordinate transformation, and even if i know the distance between each point, i dont know where to start with 0,0 in metric coordiantes. :/ Maybe im a bit dumb? Best regards Soeren > > S?ren Gebbert wrote: > > -------- Original-Nachricht -------- > > Datum: Tue, 06 Mar 2007 16:06:18 +0100 > > Von: "S?ren Gebbert" > > An: Benjamin Ducke > > CC: > > Betreff: Re: [GRASS-dev] VTK export for lat-long locations > > > > Hi Benjamin, > > please dont use the vtk export modules with lat/lon projections. > > The vtk export modules in grass are not > > usable with lat/lon projections right now. > > I think i should put this info to the html docs. > > > > The lat/lon coordiantes are used to define the coordinates for each > point. > > VTK interpret these coordinates as planimetric and not as lat/lon. > > This is not that bad for x,y coordinates, but for the height (z > coordinate). > > Because if x and y lat/lon coordiantes are of type [54.001/34.002] and > the > > height varies from 0m - 500m you will get a senseless result. > > > > I still dont know exactly how to implement a meaningful > > lat/lon ->planimetric coordinate transformation to get rid > > fo this behaviour. > > > > Any suggestions are welcome. > > > > Best regards > > Soeren > > > > > > -------- Original-Nachricht -------- > > Datum: Tue, 06 Mar 2007 15:57:17 +0100 > > Von: Benjamin Ducke > > An: GRASS devel > > CC: > > Betreff: [GRASS-dev] VTK export for lat-long locations > > > >> Hi everyone, > >> > >> I just tested r.out.vtk in a lat-long location and all I got when I > >> loaded the VTK file in Paraview (2.6.0), was a single line of data > >> projecting through the origin of the coordinate system. > >> > >> Does anyone have any experiences with VTK/Paraview and lat-long data? > >> > >> Thanks, > >> > >> Benjamin > >> > >> > >> -- > >> Benjamin Ducke, M.A. > >> Arch?oinformatik > >> (Archaeoinformation Science) > >> Institut f?r Ur- und Fr?hgeschichte > >> (Inst. of Prehistoric and Historic Archaeology) > >> Christian-Albrechts-Universit?t zu Kiel > >> Johanna-Mestorf-Stra?e 2-6 > >> D 24098 Kiel > >> Germany > >> > >> Tel.: ++49 (0)431 880-3378 / -3379 > >> Fax : ++49 (0)431 880-7300 > >> www.uni-kiel.de/ufg > >> > >> _______________________________________________ > >> grass-dev mailing list > >> grass-dev@grass.itc.it > >> http://grass.itc.it/mailman/listinfo/grass-dev > > > > -- > Benjamin Ducke, M.A. > Arch?oinformatik > (Archaeoinformation Science) > Institut f?r Ur- und Fr?hgeschichte > (Inst. of Prehistoric and Historic Archaeology) > Christian-Albrechts-Universit?t zu Kiel > Johanna-Mestorf-Stra?e 2-6 > D 24098 Kiel > Germany > > Tel.: ++49 (0)431 880-3378 / -3379 > Fax : ++49 (0)431 880-7300 > www.uni-kiel.de/ufg > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev -- "Feel free" - 5 GB Mailbox, 50 FreeSMS/Monat ... Jetzt GMX ProMail testen: www.gmx.net/de/go/mailfooter/promail-out From jachym.cepicky at gmail.com Tue Mar 6 16:47:13 2007 From: jachym.cepicky at gmail.com (Jachym Cepicky) Date: Tue Mar 6 16:47:17 2007 Subject: [GRASS-dev] grass location creation Message-ID: Hi, according to [1] I started to work on GRASS location Wizard. Since the topic is rather complex, I would like to share some ideas with you, before I go on it. I tryed to prepare sort of diagram with the wizard screens and how they could be organized [3] [4]. General idea is, that we offer to the user graphical version of standard grass location-creation process. It should be possible to define default bounding box coordinates based on list of states or georeferenced file. Thi diagram is not as transparent as I would like, sorry for this. If anybody would have some clear picture about how the wizard should be organized, please share your idea via mailing list or wiki page [1]. Jachym [1] http://grass.gdf-hannover.de/wiki/GRASS_Location_Wizard [2] http://les-ejk.cz/tmp/grassstartup.png [3] http://les-ejk.cz/tmp/wizard.png [4] http://les-ejk.cz/tmp/wizard.dia -- 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 benjamin.ducke at ufg.uni-kiel.de Tue Mar 6 17:50:41 2007 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Tue Mar 6 17:36:10 2007 Subject: Fwd: Re: [GRASS-dev] VTK export for lat-long locations In-Reply-To: <20070306154657.116710@gmx.net> References: <20070306150813.116740@gmx.net> <45ED8C8A.2060400@ufg.uni-kiel.de> <20070306154657.116710@gmx.net> Message-ID: <45ED9BE1.9060309@ufg.uni-kiel.de> OK, so as Markus has pointed out, we have the necessary funcs in lib/vector/Vlib/line.c. And as you pointed out, the basic scaling information changes with every raster row. I assume that you export a GRASS raster map in some loop construct where the outer loop goes through the rows in the GRASS map and the inner loop goes through the columns? Then the code could be something like this: intialize geodesic distance measures (?) for all rows in current map do get width of one cell (region east resolution) use Vect_line_geodesic_length() to get metric length cell for all columns in current row do scale z using current metric length output x,y,z to VTK file done done Did I overlook anything? S?ren Gebbert wrote: > Hi Benjamin, > -------- Original-Nachricht -------- > Datum: Tue, 06 Mar 2007 16:45:14 +0100 > Von: Benjamin Ducke > An: > CC: grass-dev@grass.itc.it > Betreff: Re: Fwd: Re: [GRASS-dev] VTK export for lat-long locations > >> Wow, that explains the result I got! >> So I guess you need to know exactly how many meters a lat/long cell >> dimension is in the current projection, so you can scale the Z axis >> accordingly? > > Yes, thats the point. And i need to know where to start. > >> Does this vary between cells? Does GRASS have a function to calculate > > It changes with every raster row. > >> metric lengths between two points in a lat-long system? If so, I guess >> you would need to take the the metric distance between corner points of >> a lat-long cell and use the value for Z axis scaling? > > AFAIK these functions are implemented in grass (lib/gis/area* and stuff). > > The point is, im not very familiar with this kind of coordinate transformation, and even if i know the distance between each point, > i dont know where to start with 0,0 in metric coordiantes. :/ > > Maybe im a bit dumb? > > Best regards > Soeren > >> S?ren Gebbert wrote: >>> -------- Original-Nachricht -------- >>> Datum: Tue, 06 Mar 2007 16:06:18 +0100 >>> Von: "S?ren Gebbert" >>> An: Benjamin Ducke >>> CC: >>> Betreff: Re: [GRASS-dev] VTK export for lat-long locations >>> >>> Hi Benjamin, >>> please dont use the vtk export modules with lat/lon projections. >>> The vtk export modules in grass are not >>> usable with lat/lon projections right now. >>> I think i should put this info to the html docs. >>> >>> The lat/lon coordiantes are used to define the coordinates for each >> point. >>> VTK interpret these coordinates as planimetric and not as lat/lon. >>> This is not that bad for x,y coordinates, but for the height (z >> coordinate). >>> Because if x and y lat/lon coordiantes are of type [54.001/34.002] and >> the >>> height varies from 0m - 500m you will get a senseless result. >>> >>> I still dont know exactly how to implement a meaningful >>> lat/lon ->planimetric coordinate transformation to get rid >>> fo this behaviour. >>> >>> Any suggestions are welcome. >>> >>> Best regards >>> Soeren >>> >>> >>> -------- Original-Nachricht -------- >>> Datum: Tue, 06 Mar 2007 15:57:17 +0100 >>> Von: Benjamin Ducke >>> An: GRASS devel >>> CC: >>> Betreff: [GRASS-dev] VTK export for lat-long locations >>> >>>> Hi everyone, >>>> >>>> I just tested r.out.vtk in a lat-long location and all I got when I >>>> loaded the VTK file in Paraview (2.6.0), was a single line of data >>>> projecting through the origin of the coordinate system. >>>> >>>> Does anyone have any experiences with VTK/Paraview and lat-long data? >>>> >>>> Thanks, >>>> >>>> Benjamin >>>> >>>> >>>> -- >>>> Benjamin Ducke, M.A. >>>> Arch?oinformatik >>>> (Archaeoinformation Science) >>>> Institut f?r Ur- und Fr?hgeschichte >>>> (Inst. of Prehistoric and Historic Archaeology) >>>> Christian-Albrechts-Universit?t zu Kiel >>>> Johanna-Mestorf-Stra?e 2-6 >>>> D 24098 Kiel >>>> Germany >>>> >>>> Tel.: ++49 (0)431 880-3378 / -3379 >>>> Fax : ++49 (0)431 880-7300 >>>> www.uni-kiel.de/ufg >>>> >>>> _______________________________________________ >>>> grass-dev mailing list >>>> grass-dev@grass.itc.it >>>> http://grass.itc.it/mailman/listinfo/grass-dev >> -- >> Benjamin Ducke, M.A. >> Arch?oinformatik >> (Archaeoinformation Science) >> Institut f?r Ur- und Fr?hgeschichte >> (Inst. of Prehistoric and Historic Archaeology) >> Christian-Albrechts-Universit?t zu Kiel >> Johanna-Mestorf-Stra?e 2-6 >> D 24098 Kiel >> Germany >> >> Tel.: ++49 (0)431 880-3378 / -3379 >> Fax : ++49 (0)431 880-7300 >> www.uni-kiel.de/ufg >> >> _______________________________________________ >> grass-dev mailing list >> grass-dev@grass.itc.it >> http://grass.itc.it/mailman/listinfo/grass-dev > -- Benjamin Ducke, M.A. Arch?oinformatik (Archaeoinformation Science) Institut f?r Ur- und Fr?hgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universit?t zu Kiel Johanna-Mestorf-Stra?e 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg From soerengebbert at gmx.de Tue Mar 6 19:00:26 2007 From: soerengebbert at gmx.de (=?iso-8859-1?Q?=22S=F6ren_Gebbert=22?=) Date: Tue Mar 6 19:00:27 2007 Subject: Fwd: Re: [GRASS-dev] VTK export for lat-long locations In-Reply-To: <45ED9BE1.9060309@ufg.uni-kiel.de> References: <20070306150813.116740@gmx.net> <45ED8C8A.2060400@ufg.uni-kiel.de> <20070306154657.116710@gmx.net> <45ED9BE1.9060309@ufg.uni-kiel.de> Message-ID: <20070306180026.116710@gmx.net> Hi Benjamin, -------- Original-Nachricht -------- Datum: Tue, 06 Mar 2007 17:50:41 +0100 Von: Benjamin Ducke An: GRASS devel CC: Betreff: Re: Fwd: Re: [GRASS-dev] VTK export for lat-long locations > OK, so as Markus has pointed out, we have the necessary funcs in > lib/vector/Vlib/line.c. Well, it uses the functions from lib/gis/distance.c and so should i. > And as you pointed out, the basic scaling information changes with every > raster row. > I assume that you export a GRASS raster map in some loop construct where > the outer loop goes through the rows in the GRASS map and the inner loop > goes through the columns? Yes. > Then the code could be something like this: > > > intialize geodesic distance measures (?) yes: G_begin_distance_calculations(); > > for all rows in current map do > > get width of one cell (region east resolution) > use Vect_line_geodesic_length() to get metric length cell length = G_geodesic_distance (x1, y1, x2, y2); > > for all columns in current row do > scale z using current metric length > output x,y,z to VTK file I dont think this is a good idea. It is a nice and easy approach indeed, but IMHO the length of the z height does not depend on the length of a line on the surface. So the z elevation is independend from the positon on the surface (i know the earth is not a perfect sphere ... ;) ), in this case the row number. The approach which i have in mind is to compute metric coordinates for each point (center of the cell) without scaling the z elevation. LL X,Y _______ ____ | | / \ | | --> / \ | | / \ |_______| /__________\ But the problem which i have is: VTK does not know the meaning of a world projection or a location like grass. So i do not know how to transfrom the position on the earth geoid in LL in a 3d space with x,y,z starting from 0,0,0. So which of the point is 0,0,0 if converted from lat/lon? The equator, the upper left cell, the lower right? I dont know. :/ I hope that i'm wrong and that there is a quite easy approach. eg: scaling the elevation with a fixed value? And my english is to bad, to explain my problem in a meaningful sense. Best regards Soeren btw.: The next problem which i have is the transformation of LL volume data into the x,y,z VTK format. In this case the size of one cell depends on the row and on the height. > done > done > > > Did I overlook anything? > > > > > S?ren Gebbert wrote: > > Hi Benjamin, > > -------- Original-Nachricht -------- > > Datum: Tue, 06 Mar 2007 16:45:14 +0100 > > Von: Benjamin Ducke > > An: > > CC: grass-dev@grass.itc.it > > Betreff: Re: Fwd: Re: [GRASS-dev] VTK export for lat-long locations > > > >> Wow, that explains the result I got! > >> So I guess you need to know exactly how many meters a lat/long cell > >> dimension is in the current projection, so you can scale the Z axis > >> accordingly? > > > > Yes, thats the point. And i need to know where to start. > > > >> Does this vary between cells? Does GRASS have a function to calculate > > > > It changes with every raster row. > > > >> metric lengths between two points in a lat-long system? If so, I guess > >> you would need to take the the metric distance between corner points of > >> a lat-long cell and use the value for Z axis scaling? > > > > AFAIK these functions are implemented in grass (lib/gis/area* and > stuff). > > > > The point is, im not very familiar with this kind of coordinate > transformation, and even if i know the distance between each point, > > i dont know where to start with 0,0 in metric coordiantes. :/ > > > > Maybe im a bit dumb? > > > > Best regards > > Soeren > > > >> S?ren Gebbert wrote: > >>> -------- Original-Nachricht -------- > >>> Datum: Tue, 06 Mar 2007 16:06:18 +0100 > >>> Von: "S?ren Gebbert" > >>> An: Benjamin Ducke > >>> CC: > >>> Betreff: Re: [GRASS-dev] VTK export for lat-long locations > >>> > >>> Hi Benjamin, > >>> please dont use the vtk export modules with lat/lon projections. > >>> The vtk export modules in grass are not > >>> usable with lat/lon projections right now. > >>> I think i should put this info to the html docs. > >>> > >>> The lat/lon coordiantes are used to define the coordinates for each > >> point. > >>> VTK interpret these coordinates as planimetric and not as lat/lon. > >>> This is not that bad for x,y coordinates, but for the height (z > >> coordinate). > >>> Because if x and y lat/lon coordiantes are of type [54.001/34.002] and > >> the > >>> height varies from 0m - 500m you will get a senseless result. > >>> > >>> I still dont know exactly how to implement a meaningful > >>> lat/lon ->planimetric coordinate transformation to get rid > >>> fo this behaviour. > >>> > >>> Any suggestions are welcome. > >>> > >>> Best regards > >>> Soeren > >>> > >>> > >>> -------- Original-Nachricht -------- > >>> Datum: Tue, 06 Mar 2007 15:57:17 +0100 > >>> Von: Benjamin Ducke > >>> An: GRASS devel > >>> CC: > >>> Betreff: [GRASS-dev] VTK export for lat-long locations > >>> > >>>> Hi everyone, > >>>> > >>>> I just tested r.out.vtk in a lat-long location and all I got when I > >>>> loaded the VTK file in Paraview (2.6.0), was a single line of data > >>>> projecting through the origin of the coordinate system. > >>>> > >>>> Does anyone have any experiences with VTK/Paraview and lat-long data? > >>>> > >>>> Thanks, > >>>> > >>>> Benjamin > >>>> > >>>> > >>>> -- > >>>> Benjamin Ducke, M.A. > >>>> Arch?oinformatik > >>>> (Archaeoinformation Science) > >>>> Institut f?r Ur- und Fr?hgeschichte > >>>> (Inst. of Prehistoric and Historic Archaeology) > >>>> Christian-Albrechts-Universit?t zu Kiel > >>>> Johanna-Mestorf-Stra?e 2-6 > >>>> D 24098 Kiel > >>>> Germany > >>>> > >>>> Tel.: ++49 (0)431 880-3378 / -3379 > >>>> Fax : ++49 (0)431 880-7300 > >>>> www.uni-kiel.de/ufg > >>>> > >>>> _______________________________________________ > >>>> grass-dev mailing list > >>>> grass-dev@grass.itc.it > >>>> http://grass.itc.it/mailman/listinfo/grass-dev > >> -- > >> Benjamin Ducke, M.A. > >> Arch?oinformatik > >> (Archaeoinformation Science) > >> Institut f?r Ur- und Fr?hgeschichte > >> (Inst. of Prehistoric and Historic Archaeology) > >> Christian-Albrechts-Universit?t zu Kiel > >> Johanna-Mestorf-Stra?e 2-6 > >> D 24098 Kiel > >> Germany > >> > >> Tel.: ++49 (0)431 880-3378 / -3379 > >> Fax : ++49 (0)431 880-7300 > >> www.uni-kiel.de/ufg > >> > >> _______________________________________________ > >> grass-dev mailing list > >> grass-dev@grass.itc.it > >> http://grass.itc.it/mailman/listinfo/grass-dev > > > > -- > Benjamin Ducke, M.A. > Arch?oinformatik > (Archaeoinformation Science) > Institut f?r Ur- und Fr?hgeschichte > (Inst. of Prehistoric and Historic Archaeology) > Christian-Albrechts-Universit?t zu Kiel > Johanna-Mestorf-Stra?e 2-6 > D 24098 Kiel > Germany > > Tel.: ++49 (0)431 880-3378 / -3379 > Fax : ++49 (0)431 880-7300 > www.uni-kiel.de/ufg > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: www.gmx.net/de/go/mailfooter/topmail-out From neteler at itc.it Tue Mar 6 19:00:39 2007 From: neteler at itc.it (Markus Neteler) Date: Tue Mar 6 19:00:41 2007 Subject: [GRASS-dev] Krovak datum now selectable Message-ID: <45EDAC47.60104@itc.it> Hi, I have activated the query for Krovak datum. A name mapping from/to "S_JTSK_Ferro", "Militar_Geographische_Institut", was missing in lib/proj/convert.c Now the datum dialog pops up when defining via EPSG code or g.proj: g.proj datum=-1 epsg=2065 --- 1 Used in whole hermannskogel region towgs84=653.000,-212.000,449.000 [...] Backported to 6.2-release branch, too. cheers Markus From tutey at o2.pl Tue Mar 6 19:11:53 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Tue Mar 6 19:11:58 2007 Subject: [GRASS-dev] X monitors display rasters half resolution off to the left In-Reply-To: <17900.62055.16994.394740@cerise.gclements.plus.com> References: <45EC6C2B.20607@biol.uni.wroc.pl> <17900.53290.589769.815960@cerise.gclements.plus.com> <17900.62055.16994.394740@cerise.gclements.plus.com> Message-ID: <45EDAEE9.5070000@o2.pl> Glynn Clements wrote: > Fixed in CVS, AFAICT. Thank you Glynn! Great job, as usual :). Maciek From grass-bugs at intevation.de Tue Mar 6 23:16:02 2007 From: grass-bugs at intevation.de (Maciek Sieczka via RT) Date: Tue Mar 6 23:16:03 2007 Subject: [GRASS-dev] [bug #3069] (grass) r.mapcalc - warning/errorr amibiguity Message-ID: <20070306221602.79EA810015A@lists.intevation.de> Works like a charm. Closing ticket. Maciek -------------------------------------------- Managed by Request Tracker From hamish_nospam at yahoo.com Tue Mar 6 23:48:16 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Mar 6 23:48:23 2007 Subject: Fwd: Re: [GRASS-dev] VTK export for lat-long locations In-Reply-To: <20070306180026.116710@gmx.net> References: <20070306150813.116740@gmx.net> <45ED8C8A.2060400@ufg.uni-kiel.de> <20070306154657.116710@gmx.net> <45ED9BE1.9060309@ufg.uni-kiel.de> <20070306180026.116710@gmx.net> Message-ID: <20070307114816.45480507.hamish_nospam@yahoo.com> S?ren Gebbert wrote: > I dont think this is a good idea. It is a nice and easy approach > indeed, but IMHO the length of the z height does not depend on > the length of a line on the surface. > So the z elevation is independend from the positon > on the surface (i know the earth is not a perfect sphere ... ;) ), > in this case the row number. the units of z are map dependent and not knowable by the system. for NVIZ + lat/lon, in the past I have used r.mapcalc to make a new map, [I've got a feeling this is no longer needed??] e.g. for a lat/lon map with z in meters: r.mapcalc "scaled_map = (map / 1850.0*60)" so x,y,z are all in degrees. I would not bother with reprojecting lat/lon into square cells, the user can to that with r.proj if they want. Just note that the output is in Plate Carr?e like GRASS renders for 2D. see also 'r.shaded.relief units='. Hamish From tutey at o2.pl Tue Mar 6 23:48:21 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Tue Mar 6 23:48:29 2007 Subject: [GRASS-dev] d.zoom inconsistency,? Message-ID: <45EDEFB5.3090500@o2.pl> Hi, Please look at the attached pictures. There is a raster on an X monitor (raster.png). Let's zoom-in with d.zoom as shown on the box_horiz_over.png. The result is 4 cells (zoom_horiz_over.png). Now let's zoom like on the box_vert_over.png. The result is 8 cells (zoom_vert_over.png). Shouldn't 4 cells be the result in both cases? If you don't see the logics in my question I can explain it :). It's the same in GRASS 6.2, so nothing newly introduced. Note that the gis.m zoom tool does both zooming variants the way it seems logical to me, ie. 4 cells is the result for both variants. Maciek -------------- next part -------------- A non-text attachment was scrubbed... Name: raster.png Type: image/png Size: 4463 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070306/00c7d32f/raster-0001.png -------------- next part -------------- A non-text attachment was scrubbed... Name: box_horiz_over.png Type: image/png Size: 4488 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070306/00c7d32f/box_horiz_over-0001.png -------------- next part -------------- A non-text attachment was scrubbed... Name: zoom_horiz_over.png Type: image/png Size: 6778 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070306/00c7d32f/zoom_horiz_over-0001.png -------------- next part -------------- A non-text attachment was scrubbed... Name: box_vert_over.png Type: image/png Size: 4501 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070306/00c7d32f/box_vert_over-0001.png -------------- next part -------------- A non-text attachment was scrubbed... Name: zoom_vert_over.png Type: image/png Size: 4434 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070306/00c7d32f/zoom_vert_over-0001.png From soerengebbert at gmx.de Wed Mar 7 00:24:44 2007 From: soerengebbert at gmx.de (Soeren Gebbert) Date: Wed Mar 7 00:16:10 2007 Subject: Fwd: Re: [GRASS-dev] VTK export for lat-long locations In-Reply-To: <20070307114816.45480507.hamish_nospam@yahoo.com> References: <20070306150813.116740@gmx.net> <20070306180026.116710@gmx.net> <20070307114816.45480507.hamish_nospam@yahoo.com> Message-ID: <200703070024.45396.soerengebbert@gmx.de> Am Dienstag, 6. M?rz 2007 23:48 schrieb Hamish: > S?ren Gebbert wrote: > > I dont think this is a good idea. It is a nice and easy approach > > indeed, but IMHO the length of the z height does not depend on > > the length of a line on the surface. > > So the z elevation is independend from the positon > > on the surface (i know the earth is not a perfect sphere ... ;) ), > > in this case the row number. > > the units of z are map dependent and not knowable by the system. > > for NVIZ + lat/lon, in the past I have used r.mapcalc to make a new > map, [I've got a feeling this is no longer needed??] > > e.g. for a lat/lon map with z in meters: > > r.mapcalc "scaled_map = (map / 1850.0*60)" > > so x,y,z are all in degrees. In this case r.out.vtk input=ll_map output=ll_map.vtk elevscale=0.000009009 will do the job. :) > > > I would not bother with reprojecting lat/lon into square cells, the user > can to that with r.proj if they want. Just note that the output is in > Plate Carr?e like GRASS renders for 2D. Ok, thanks. Soeren > > see also 'r.shaded.relief units='. > > > Hamish > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From woklist at kyngchaos.com Wed Mar 7 01:39:40 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Wed Mar 7 01:40:00 2007 Subject: [GRASS-dev] r.proj.seg disk space usage problem Message-ID: I had a chance today to try a VERY large raster with r.proj.seg. 2.7GB raster, 55000x47000 cells. The memory issue of r.proj have now been moved to a HD space issue. With 7.75GB free, it chokes at about 75% in the allocating memory stage, while free space slowly drops to zero, with an "Error writing segment file". It seems r.proj.seg, for its segmentation, creates an uncompressed copy of the whole raster on the HD (instead of in memory). I'm guessing this has something to do with random access speed in rasters? So I'm back to projecting pieces of the raster, but now so they fit in my disk free space, and patching them together. Disappointing, but if that's the way it must be, I can live with it. ----- William Kyngesburye http://www.kyngchaos.com/ "Mon Dieu! but they are all alike. Cheating, murdering, lying, fighting, and all for things that the beasts of the jungle would not deign to possess - money to purchase the effeminate pleasures of weaklings. And yet withal bound down by silly customs that make them slaves to their unhappy lot while firm in the belief that they be the lords of creation enjoying the only real pleasures of existence.... - the wisdom of Tarzan From hamish_nospam at yahoo.com Wed Mar 7 01:56:39 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Mar 7 01:56:48 2007 Subject: Fwd: Re: [GRASS-dev] VTK export for lat-long locations In-Reply-To: <200703070024.45396.soerengebbert@gmx.de> References: <20070306150813.116740@gmx.net> <20070306180026.116710@gmx.net> <20070307114816.45480507.hamish_nospam@yahoo.com> <200703070024.45396.soerengebbert@gmx.de> Message-ID: <20070307135639.620f5ea4.hamish_nospam@yahoo.com> Soeren Gebbert wrote: > > the units of z are map dependent and not knowable by the system. > > > > for NVIZ + lat/lon, in the past I have used r.mapcalc to make a new > > map, [I've got a feeling this is no longer needed??] > > > > e.g. for a lat/lon map with z in meters: > > > > r.mapcalc "scaled_map = (map / 1850.0*60)" > > > > so x,y,z are all in degrees. > > In this case > r.out.vtk input=ll_map output=ll_map.vtk elevscale=0.000009009 > will do the job. :) sorry, minor typo above, there is 1852m to the nautical mile, not 1850. elevscale=0.000009 and for feet: ( 1/(6076.1[2]*60) ) elevscale=0.000002742 Hamish From hamish_nospam at yahoo.com Wed Mar 7 02:18:53 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Mar 7 02:18:58 2007 Subject: [GRASS-dev] r.proj.seg disk space usage problem In-Reply-To: References: Message-ID: <20070307141853.12f63f0f.hamish_nospam@yahoo.com> William Kyngesburye wrote: > I had a chance today to try a VERY large raster with r.proj.seg. > 2.7GB raster, 55000x47000 cells. The memory issue of r.proj have now > been moved to a HD space issue. With 7.75GB free, it chokes at about > 75% in the allocating memory stage, while free space slowly drops to > zero, with an "Error writing segment file". > It seems r.proj.seg, for its segmentation, creates an uncompressed > copy of the whole raster on the HD (instead of in memory). I'm > guessing this has something to do with random access speed in rasters? > > So I'm back to projecting pieces of the raster, but now so they fit > in my disk free space, and patching them together. Disappointing, > but if that's the way it must be, I can live with it. did you pump the memory= option up to a few hundred MB smaller than your installed RAM? Hamish From hamish_nospam at yahoo.com Wed Mar 7 03:40:31 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Mar 7 03:41:41 2007 Subject: [GRASS-dev] grass location creation In-Reply-To: References: Message-ID: <20070307154031.2a51146c.hamish_nospam@yahoo.com> Jachym Cepicky wrote: > according to [1] I started to work on GRASS location Wizard. Since the > topic is rather complex, I would like to share some ideas with you, > before I go on it. > > I tryed to prepare sort of diagram with the wizard screens and how > they could be organized [3] [4]. General idea is, that we offer to the > user graphical version of standard grass location-creation process. It > should be possible to define default bounding box coordinates based on > list of states or georeferenced file. Thi diagram is not as > transparent as I would like, sorry for this. > > If anybody would have some clear picture about how the wizard should > be organized, please share your idea via mailing list or wiki page > [1]. > > Jachym > > [1] http://grass.gdf-hannover.de/wiki/GRASS_Location_Wizard > [2] http://les-ejk.cz/tmp/grassstartup.png > [3] http://les-ejk.cz/tmp/wizard.png > [4] http://les-ejk.cz/tmp/wizard.dia you might look at Radim's GRASS location/mapset creation wizard for QGIS for inspiration, http://article.gmane.org/gmane.comp.gis.grass.devel/9049 The screenshots listed there are no longer available (or at archive.org), but maybe you can find them somewhere else, or just try it in GIS 0.8? I think a big missing piece is (still) a non-interactive "save as default region" option for g.region. Currently there is no tool to do that outside of lib/init/set_data.c + lib/edit/edit_cellhd.c Hamish From woklist at kyngchaos.com Wed Mar 7 05:01:10 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Wed Mar 7 05:01:26 2007 Subject: [GRASS-dev] r.proj.seg disk space usage problem In-Reply-To: <20070307141853.12f63f0f.hamish_nospam@yahoo.com> References: <20070307141853.12f63f0f.hamish_nospam@yahoo.com> Message-ID: <3FCC71D0-12AC-488B-A186-E639080D4AC8@kyngchaos.com> On Mar 6, 2007, at 7:18 PM, Hamish wrote: > William Kyngesburye wrote: >> I had a chance today to try a VERY large raster with r.proj.seg. >> 2.7GB raster, 55000x47000 cells. The memory issue of r.proj have now >> been moved to a HD space issue. With 7.75GB free, it chokes at about >> 75% in the allocating memory stage, while free space slowly drops to >> zero, with an "Error writing segment file". >> It seems r.proj.seg, for its segmentation, creates an uncompressed >> copy of the whole raster on the HD (instead of in memory). I'm >> guessing this has something to do with random access speed in >> rasters? >> >> So I'm back to projecting pieces of the raster, but now so they fit >> in my disk free space, and patching them together. Disappointing, >> but if that's the way it must be, I can live with it. > > > did you pump the memory= option up to a few hundred MB smaller than > your > installed RAM? > I didn't try that. I'm not sure how that would help - that would give me 700MB, not a significant portion of the uncompressed raster. And it still needs to copy the raster to a temp file. From Glynn back on Feb 12: > 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. ... > [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.] ----- 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 glynn at gclements.plus.com Wed Mar 7 05:37:57 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Mar 7 05:38:01 2007 Subject: [GRASS-dev] d.zoom inconsistency,? In-Reply-To: <45EDEFB5.3090500@o2.pl> References: <45EDEFB5.3090500@o2.pl> Message-ID: <17902.16805.264683.400665@cerise.gclements.plus.com> Maciej Sieczka wrote: > Please look at the attached pictures. There is a raster on an X monitor > (raster.png). > > Let's zoom-in with d.zoom as shown on the box_horiz_over.png. The > result is 4 cells (zoom_horiz_over.png). > > Now let's zoom like on the box_vert_over.png. The result is 8 cells > (zoom_vert_over.png). > > Shouldn't 4 cells be the result in both cases? If you don't see the > logics in my question I can explain it :). I haven't gone into it with gdb yet, but the issue appears to be the following code in set_win() (display/d.zoom/set.c): td = ceil (north / nsr); tnorth = td * nsr; td = floor (south / nsr); tsouth = td * nsr; td = rint (east / ewr); teast = td * ewr; td = rint (west / ewr); twest = td * ewr; IOW, north is rounded up, south is rounded down, east and west are rounded to nearest. FWIW, I also consider this to be counter-intuitive; although there's no "right" approach, any approach which treats the horizontal and vertical axes differently is wrong, IMHO. Beyond that, rounding opposing edges in the same direction (i.e. rounding both up or rounding both down) also seems wrong. More useful approaches would be: 1. Round inwards, i.e. round west+south up, east+north down 2. Round outwards, i.e. round west+south down, east+north up 3. Always round to nearest. -- Glynn Clements From glynn at gclements.plus.com Wed Mar 7 06:22:49 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Mar 7 06:22:56 2007 Subject: Fwd: Re: [GRASS-dev] VTK export for lat-long locations In-Reply-To: <20070306150813.116740@gmx.net> References: <20070306150813.116740@gmx.net> Message-ID: <17902.19497.769116.476585@cerise.gclements.plus.com> "S?ren Gebbert" wrote: > please dont use the vtk export modules with lat/lon projections. > The vtk export modules in grass are not > usable with lat/lon projections right now. > I think i should put this info to the html docs. > > The lat/lon coordiantes are used to define the coordinates for each point. > VTK interpret these coordinates as planimetric and not as lat/lon. > This is not that bad for x,y coordinates, but for the height (z coordinate). > Because if x and y lat/lon coordiantes are of type [54.001/34.002] and the > height varies from 0m - 500m you will get a senseless result. > > I still dont know exactly how to implement a meaningful > lat/lon ->planimetric coordinate transformation to get rid > fo this behaviour. > > Any suggestions are welcome. In increasing order of complexity and accuracy: 1. Convert the lat/lon coordinates to radians then multiply by the radius of the earth (in whatever units the z values use). E.g. if the Z values are in metres, using the radius of 6378137m for the WGS ellipsoid gives a scale factor of pi/180*6378137 ~ 111320 [I've noticed Hamish' comment, which essentially suggests the inverse, i.e. scale the Z values by 1/111320 = 9e-6, so that everything is in degrees.] For a whole-earth map, this should be adequate; you will still get horizontal stretching as you move towards the poles, but no more so than is inherent with lat/lon. 2. As above, but scale the y coordinates by 111320 and the x coordinates by 111320*cos(lat), where lat is the mean latitude of your region. The main issue here is that, if the range of latitudes is significant, the choice of centre for the x scaling will make a difference to the shape of the projected data. 3. Pick an "appropriate" geographic projection and transform the coordinates into that projection. The choice of projection needs to be done manually, based upon the size, shape and location of your region, and the relative importance of various properties (equidistant, equal-area, conformal, etc). -- Glynn Clements From glynn at gclements.plus.com Wed Mar 7 06:38:16 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Mar 7 06:38:31 2007 Subject: [GRASS-dev] r.proj.seg disk space usage problem In-Reply-To: References: Message-ID: <17902.20424.219086.827306@cerise.gclements.plus.com> William Kyngesburye wrote: > I had a chance today to try a VERY large raster with r.proj.seg. > 2.7GB raster, 55000x47000 cells. The memory issue of r.proj have now > been moved to a HD space issue. With 7.75GB free, it chokes at about > 75% in the allocating memory stage, while free space slowly drops to > zero, with an "Error writing segment file". > > It seems r.proj.seg, for its segmentation, creates an uncompressed > copy of the whole raster on the HD (instead of in memory). Correct. 55000 * 47000 * 4 bytes/cell = 10,340,000,000 bytes (~10GB). > I'm guessing this has something to do with random access speed in > rasters? Correct. Re-projection involves accessing the source data in a non-linear fashion, so the data needs to be stored in a form which allows random access. [We could potentially do something else for the case of transformations with low levels of rotation and curvature, but I'm not sure whether the case of not having enough free disk space to hold one uncompressed map is sufficiently common to make it worthwhile.] > So I'm back to projecting pieces of the raster, but now so they fit > in my disk free space, and patching them together. Disappointing, > but if that's the way it must be, I can live with it. Buy a larger hard drive. 250GB IDE = ?43, 250GB SATA = ?46, so that extra 10GB equates to ~?5 worth of disk space. Which is a lot cheaper than another 10GB of RAM (which you would need for the same task using r.proj). -- Glynn Clements From glynn at gclements.plus.com Wed Mar 7 06:53:08 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Mar 7 06:53:14 2007 Subject: [GRASS-dev] r.proj.seg disk space usage problem In-Reply-To: <20070307141853.12f63f0f.hamish_nospam@yahoo.com> References: <20070307141853.12f63f0f.hamish_nospam@yahoo.com> Message-ID: <17902.21316.963211.897875@cerise.gclements.plus.com> Hamish wrote: > > I had a chance today to try a VERY large raster with r.proj.seg. > > 2.7GB raster, 55000x47000 cells. The memory issue of r.proj have now > > been moved to a HD space issue. With 7.75GB free, it chokes at about > > 75% in the allocating memory stage, while free space slowly drops to > > zero, with an "Error writing segment file". > > It seems r.proj.seg, for its segmentation, creates an uncompressed > > copy of the whole raster on the HD (instead of in memory). I'm > > guessing this has something to do with random access speed in rasters? > > > > So I'm back to projecting pieces of the raster, but now so they fit > > in my disk free space, and patching them together. Disappointing, > > but if that's the way it must be, I can live with it. > > did you pump the memory= option up to a few hundred MB smaller than your > installed RAM? That won't affect disk usage, unless he has enough RAM to hold the entire uncompressed map (~10GB in this case). You need to be able to hold the entire uncompressed map (4 bytes per cell) either in RAM or on disk. If it won't fit entirely in RAM, the entire map is stored on disk, and portions are copied to RAM as required. The portions which are in RAM are still kept on disk; there isn't any "swapping". You could conceivably use system swap as "RAM", but that would result in taking physical RAM from any other applications on the system. At best, the rest of the system is likely to become rather unresponsive in that kind of situation; at worst, r.proj.seg and the rest of the system will end up fighting it out for physical RAM, resulting in "thrashing". Also, that approach requires a 64-bit CPU and OS (in the sense of providing a 64-bit address space). A 32-bit address space limits you to no more than 4GB of "memory" (physical RAM, swap, mmap()d files etc) per process, and the maximum size of the heap will probably be significantly less than that 4GB. -- Glynn Clements From jachym.cepicky at gmail.com Wed Mar 7 08:13:52 2007 From: jachym.cepicky at gmail.com (Jachym Cepicky) Date: Wed Mar 7 08:14:26 2007 Subject: [GRASS-dev] grass location creation In-Reply-To: <20070307154031.2a51146c.hamish_nospam@yahoo.com> References: <20070307154031.2a51146c.hamish_nospam@yahoo.com> Message-ID: I have the QGIS version here ;-) g.region -s would be great... however - should it work from PERMANENT mapset only, or from any other mapset too? jachym 2007/3/7, Hamish : > Jachym Cepicky wrote: > > according to [1] I started to work on GRASS location Wizard. Since the > > topic is rather complex, I would like to share some ideas with you, > > before I go on it. > > > > I tryed to prepare sort of diagram with the wizard screens and how > > they could be organized [3] [4]. General idea is, that we offer to the > > user graphical version of standard grass location-creation process. It > > should be possible to define default bounding box coordinates based on > > list of states or georeferenced file. Thi diagram is not as > > transparent as I would like, sorry for this. > > > > If anybody would have some clear picture about how the wizard should > > be organized, please share your idea via mailing list or wiki page > > [1]. > > > > Jachym > > > > [1] http://grass.gdf-hannover.de/wiki/GRASS_Location_Wizard > > [2] http://les-ejk.cz/tmp/grassstartup.png > > [3] http://les-ejk.cz/tmp/wizard.png > > [4] http://les-ejk.cz/tmp/wizard.dia > > > you might look at Radim's GRASS location/mapset creation wizard for QGIS > for inspiration, > http://article.gmane.org/gmane.comp.gis.grass.devel/9049 > > The screenshots listed there are no longer available (or at archive.org), > but maybe you can find them somewhere else, or just try it in GIS 0.8? > > I think a big missing piece is (still) a non-interactive "save as > default region" option for g.region. Currently there is no tool to do > that outside of lib/init/set_data.c + lib/edit/edit_cellhd.c > > > Hamish > -- 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 Wed Mar 7 08:20:46 2007 From: neteler at itc.it (Markus Neteler) Date: Wed Mar 7 08:20:59 2007 Subject: [GRASS-dev] grass location creation In-Reply-To: References: <20070307154031.2a51146c.hamish_nospam@yahoo.com> Message-ID: <20070307072045.GB3148@bartok.itc.it> 2007/3/7, Hamish : >I think a big missing piece is (still) a non-interactive "save as >default region" option for g.region. Currently there is no tool to do >that outside of lib/init/set_data.c + lib/edit/edit_cellhd.c The code is in r.in.gdal - should not be so hard to add it to g.region. Markus From landa.martin at gmail.com Wed Mar 7 14:03:58 2007 From: landa.martin at gmail.com (Martin Landa) Date: Wed Mar 7 14:04:04 2007 Subject: [GRASS-dev] latlong problem Message-ID: Hi, there is a significant problem in LatLong location. Try the following: g.region n=80 s=-80 w=-170 e=170 res=1; v.in.region out=reg; g.region n=90 s=-90 w=-180 e=180 res=1; d.erase;d.vect reg [1] should be [2] I prepared a simple patch to fix this bug. I am not sure whether it is OK. Anyway testing "(east1 - east2) > 180" does not make sense to me... or am I wrong? Martin [1] http://gama.fsv.cvut.cz/~landa/.../grass/reg.png [2] http://gama.fsv.cvut.cz/~landa/.../grass/reg2.png -- Martin Landa * http://gama.fsv.cvut.cz/~landa * -------------- next part -------------- A non-text attachment was scrubbed... Name: plot.c.diff Type: application/octet-stream Size: 839 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070307/99936837/plot.c.obj From neteler at itc.it Wed Mar 7 14:53:28 2007 From: neteler at itc.it (Markus Neteler) Date: Wed Mar 7 14:53:29 2007 Subject: [GRASS-dev] latlong problem In-Reply-To: References: Message-ID: <20070307135327.GA3694@bartok.itc.it> On Wed, Mar 07, 2007 at 02:03:58PM +0100, Martin Landa wrote: > Hi, > > there is a significant problem in LatLong location. Try the following: > > g.region n=80 s=-80 w=-170 e=170 res=1; > v.in.region out=reg; > g.region n=90 s=-90 w=-180 e=180 res=1; > d.erase;d.vect reg > [1] should be [2] > > I prepared a simple patch to fix this bug. > > I am not sure whether it is OK. Anyway testing "(east1 - east2) > 180" > does not make sense to me... or am I wrong? > > Martin > > [1] http://gama.fsv.cvut.cz/~landa/.../grass/reg.png > [2] http://gama.fsv.cvut.cz/~landa/.../grass/reg2.png Great work, Martin! This patch cures the problem of http://mpa.itc.it/markus/tmp/admin98_oceans_buggy.png to http://mpa.itc.it/markus/tmp/admin98_oceans_fixed.png Unrelated bug (?): The boundary box at the East end isn't visible - is the display driver cutting off by 1 pixel from East? The region is 90N, 90S, 180W, 180E, Latlong WGS84. See admin98_oceans_fixed.png for illustration, generated with d.out.png. Markus From glynn at gclements.plus.com Wed Mar 7 15:03:32 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Mar 7 15:03:35 2007 Subject: [GRASS-dev] latlong problem In-Reply-To: References: Message-ID: <17902.50740.995954.315272@cerise.gclements.plus.com> Martin Landa wrote: > there is a significant problem in LatLong location. Try the following: > > g.region n=80 s=-80 w=-170 e=170 res=1; > v.in.region out=reg; > g.region n=90 s=-90 w=-180 e=180 res=1; > d.erase;d.vect reg > [1] should be [2] No, [1] is correct. Given two points at the same latitude, each 10 degrees either side of the 180th meridian, the line segment between them is deemed to be the one which subtends 20 degrees and crosses the 180th meridian, not the one which subtends 340 degrees and crosses the prime meridian. IOW, "shorter" has a higher priority than "doesn't cross the 180th meridian". > I prepared a simple patch to fix this bug. It isn't a bug. It may not produce your preferred result, but the behaviour is quite intentional. > I am not sure whether it is OK. Anyway testing "(east1 - east2) > 180" > does not make sense to me... or am I wrong? Longitudes are cyclic. This makes their behaviour rather counterintuitive, e.g.: 179 + 2 = -179 => -179 - 179 = 2 => -179 - 179 > 0 => -179 > 179 -- Glynn Clements From landa.martin at gmail.com Wed Mar 7 15:28:36 2007 From: landa.martin at gmail.com (Martin Landa) Date: Wed Mar 7 15:28:39 2007 Subject: [GRASS-dev] latlong problem In-Reply-To: <17902.50740.995954.315272@cerise.gclements.plus.com> References: <17902.50740.995954.315272@cerise.gclements.plus.com> Message-ID: Hi Glynn, 2007/3/7, Glynn Clements : > > there is a significant problem in LatLong location. Try the following: > > > > g.region n=80 s=-80 w=-170 e=170 res=1; > > v.in.region out=reg; > > g.region n=90 s=-90 w=-180 e=180 res=1; > > d.erase;d.vect reg > > [1] should be [2] > > No, [1] is correct. > > Given two points at the same latitude, each 10 degrees either side of > the 180th meridian, the line segment between them is deemed to be the > one which subtends 20 degrees and crosses the 180th meridian, not the > one which subtends 340 degrees and crosses the prime meridian. > > IOW, "shorter" has a higher priority than "doesn't cross the 180th > meridian". OK, then I understand. Anyway, the centroid should be placed inside the area. It is at least confusing. So the problem with "buggy" maps which Markus described still remains. Thanks for explanation. Martin -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From hmitaso at unity.ncsu.edu Wed Mar 7 18:02:06 2007 From: hmitaso at unity.ncsu.edu (Helena Mitasova) Date: Wed Mar 7 18:02:12 2007 Subject: [GRASS-dev] grass location creation In-Reply-To: References: <20070307154031.2a51146c.hamish_nospam@yahoo.com> Message-ID: <5628BB58-E8B6-4A09-BA88-C9EF350415F2@unity.ncsu.edu> On Mar 7, 2007, at 2:13 AM, Jachym Cepicky wrote: > I have the QGIS version here ;-) > > g.region -s would be great... > > however - should it work from PERMANENT mapset only, or from any other > mapset too? if you are talking about saving as default region it should work from PERMANENT mapset only as in GRASS you can change the files only in your current mapset and the default region is stored in PERMANENT. This would add an important missing piece - it was a real pain not to have it when I started to work with the spearfish replacement data set and I tried to work as a normal user (not editing the DEFAULT_WIND files) as my default regions we set to 1,1,1 for locations where I used the EPSG code. thanks for looking into it, Helena > > jachym > > 2007/3/7, Hamish : >> Jachym Cepicky wrote: >> > according to [1] I started to work on GRASS location Wizard. >> Since the >> > topic is rather complex, I would like to share some ideas with you, >> > before I go on it. >> > >> > I tryed to prepare sort of diagram with the wizard screens and how >> > they could be organized [3] [4]. General idea is, that we offer >> to the >> > user graphical version of standard grass location-creation >> process. It >> > should be possible to define default bounding box coordinates >> based on >> > list of states or georeferenced file. Thi diagram is not as >> > transparent as I would like, sorry for this. >> > >> > If anybody would have some clear picture about how the wizard >> should >> > be organized, please share your idea via mailing list or wiki page >> > [1]. >> > >> > Jachym >> > >> > [1] http://grass.gdf-hannover.de/wiki/GRASS_Location_Wizard >> > [2] http://les-ejk.cz/tmp/grassstartup.png >> > [3] http://les-ejk.cz/tmp/wizard.png >> > [4] http://les-ejk.cz/tmp/wizard.dia >> >> >> you might look at Radim's GRASS location/mapset creation wizard >> for QGIS >> for inspiration, >> http://article.gmane.org/gmane.comp.gis.grass.devel/9049 >> >> The screenshots listed there are no longer available (or at >> archive.org), >> but maybe you can find them somewhere else, or just try it in GIS >> 0.8? >> >> I think a big missing piece is (still) a non-interactive "save as >> default region" option for g.region. Currently there is no tool to do >> that outside of lib/init/set_data.c + lib/edit/edit_cellhd.c >> >> >> Hamish >> > > > -- > Jachym Cepicky > e-mail: jachym.cepicky gmail com > URL: http://les-ejk.cz > GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From glynn at gclements.plus.com Wed Mar 7 18:32:43 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Mar 7 18:32:46 2007 Subject: [GRASS-dev] latlong problem In-Reply-To: References: <17902.50740.995954.315272@cerise.gclements.plus.com> Message-ID: <17902.63291.23400.67190@cerise.gclements.plus.com> Martin Landa wrote: > Hi Glynn, > > 2007/3/7, Glynn Clements : > > > > there is a significant problem in LatLong location. Try the following: > > > > > > g.region n=80 s=-80 w=-170 e=170 res=1; > > > v.in.region out=reg; > > > g.region n=90 s=-90 w=-180 e=180 res=1; > > > d.erase;d.vect reg > > > [1] should be [2] > > > > No, [1] is correct. > > > > Given two points at the same latitude, each 10 degrees either side of > > the 180th meridian, the line segment between them is deemed to be the > > one which subtends 20 degrees and crosses the 180th meridian, not the > > one which subtends 340 degrees and crosses the prime meridian. > > > > IOW, "shorter" has a higher priority than "doesn't cross the 180th > > meridian". > > OK, then I understand. Anyway, the centroid should be placed inside > the area. It is at least confusing. Ah; I missed that part. Yes, the centroid should definitely lie inside the area (i.e. on the 180th meridian in this case). > So the problem with "buggy" maps which Markus described still remains. Personally, I'd be tempted to just treat the 180th meridian as a discontinuity (New Zealanders and Japanese would have to stick to using projected locations). I wouldn't be surprised if there are a *lot* of places in the code which ought to contain specific code to handle longitude wrapping but don't. [E.g. "d.vect ... render=c" doesn't handle it correctly. D_polygon_clip() does the clipping in geographic coordinates, before transforming the vertices to display coordinates. Most of the time, this is preferable, as you eliminate the conversion overhead for any points which are discarded by clipping.] Actually, this isn't a problem which can be "solved". What do you do if you *want* a polygon which spans 340? of longitude? How do you interpret a polygon which spans exactly 180?; which hemisphere does it cover? IOW, I don't think that we'll ever get this "right". -- Glynn Clements From neteler at itc.it Wed Mar 7 18:40:10 2007 From: neteler at itc.it (Markus Neteler) Date: Wed Mar 7 18:40:12 2007 Subject: [GRASS-dev] latlong problem In-Reply-To: <17902.63291.23400.67190@cerise.gclements.plus.com> References: <17902.50740.995954.315272@cerise.gclements.plus.com> <17902.63291.23400.67190@cerise.gclements.plus.com> Message-ID: <45EEF8FA.7040409@itc.it> Glynn Clements wrote on 03/07/2007 06:32 PM: > ... > Actually, this isn't a problem which can be "solved". What do you do > if you *want* a polygon which spans 340? of longitude? How do you > interpret a polygon which spans exactly 180?; which hemisphere does it > cover? > > IOW, I don't think that we'll ever get this "right". > Well, to me http://mpa.itc.it/markus/tmp/admin98_oceans_fixed.png looks much more reasonable than http://mpa.itc.it/markus/tmp/admin98_oceans_buggy.png Sorry for this stupid comment, but I still think that there is a problem. And in this case it is a perfect -180 .. 180deg map. The rendering is ok for 3/4th of the map but not the northern part (although there is a north boundary in the map, see "fixed" map example). Markus From soerengebbert at gmx.de Wed Mar 7 23:41:54 2007 From: soerengebbert at gmx.de (Soeren Gebbert) Date: Wed Mar 7 23:33:21 2007 Subject: Fwd: Re: [GRASS-dev] VTK export for lat-long locations In-Reply-To: <17902.19497.769116.476585@cerise.gclements.plus.com> References: <20070306150813.116740@gmx.net> <17902.19497.769116.476585@cerise.gclements.plus.com> Message-ID: <200703072341.54922.soerengebbert@gmx.de> Am Mittwoch, 7. M?rz 2007 06:22 schrieb Glynn Clements: > "S?ren Gebbert" wrote: > > please dont use the vtk export modules with lat/lon projections. > > The vtk export modules in grass are not > > usable with lat/lon projections right now. > > I think i should put this info to the html docs. > > > > The lat/lon coordiantes are used to define the coordinates for each > > point. VTK interpret these coordinates as planimetric and not as lat/lon. > > This is not that bad for x,y coordinates, but for the height (z > > coordinate). Because if x and y lat/lon coordiantes are of type > > [54.001/34.002] and the height varies from 0m - 500m you will get a > > senseless result. > > > > I still dont know exactly how to implement a meaningful > > lat/lon ->planimetric coordinate transformation to get rid > > fo this behaviour. > > > > Any suggestions are welcome. > > In increasing order of complexity and accuracy: > > 1. Convert the lat/lon coordinates to radians then multiply by the > radius of the earth (in whatever units the z values use). > > E.g. if the Z values are in metres, using the radius of 6378137m for > the WGS ellipsoid gives a scale factor of pi/180*6378137 ~ 111320 > > [I've noticed Hamish' comment, which essentially suggests the inverse, > i.e. scale the Z values by 1/111320 = 9e-6, so that everything is in > degrees.] > > For a whole-earth map, this should be adequate; you will still get > horizontal stretching as you move towards the poles, but no more so > than is inherent with lat/lon. > > 2. As above, but scale the y coordinates by 111320 and the x > coordinates by 111320*cos(lat), where lat is the mean latitude of your > region. The main issue here is that, if the range of latitudes is > significant, the choice of centre for the x scaling will make a > difference to the shape of the projected data. > > 3. Pick an "appropriate" geographic projection and transform the > coordinates into that projection. The choice of projection needs to be > done manually, based upon the size, shape and location of your region, > and the relative importance of various properties (equidistant, > equal-area, conformal, etc). Many thanks for this suggestions. I think i will implement the first and second approach. The third approach sounds to complex to be implemented in the vtk export modules. Maybe it will be easier for the user to reproject his data in a metric projection. Best regards Soeren From jachym.cepicky at gmail.com Wed Mar 7 23:33:57 2007 From: jachym.cepicky at gmail.com (Jachym Cepicky) Date: Wed Mar 7 23:34:00 2007 Subject: [GRASS-dev] grass location creation In-Reply-To: <20070307072045.GB3148@bartok.itc.it> References: <20070307154031.2a51146c.hamish_nospam@yahoo.com> <20070307072045.GB3148@bartok.itc.it> Message-ID: hi, patch for g.region is part of this email however, it does not work :-( I took the code from r.in.gdal (main.c arround lines 526-546), everything looks good.. but it does not work :-( Could anybody have a look at it? Thanks! Jachym 2007/3/7, Markus Neteler : > 2007/3/7, Hamish : > >I think a big missing piece is (still) a non-interactive "save as > >default region" option for g.region. Currently there is no tool to do > >that outside of lib/init/set_data.c + lib/edit/edit_cellhd.c > > The code is in r.in.gdal - should not be so hard to add it > to g.region. > > Markus > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > -- Jachym Cepicky e-mail: jachym.cepicky gmail com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub -------------- next part -------------- A non-text attachment was scrubbed... Name: g.region.patch Type: text/x-patch Size: 1381 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070307/355fc91a/g.region.bin From hamish_nospam at yahoo.com Thu Mar 8 02:21:13 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Mar 8 02:25:20 2007 Subject: [GRASS-dev] DBF SQL extract error w/ external vector map Message-ID: <20070308142113.1e409765.hamish_nospam@yahoo.com> Hi, 6.3cvs (1-2 days old), OGR linked shapefile (v.external), G63> v.extract in=admin98 out=antarctica98 \ where="ADMIN_NAME = 'Antarctica'" Load cats from the database (table = admin98, db = /home/hamish/grassdata/world_ll/PERMANENT/external). 1 cats loaded from the database Building topology ... 276 primitives registered Building areas: 100% 138 areas built 138 isles built Attaching islands: 100% Attaching centroids: 100% Topology was built. Number of nodes : 276 Number of primitives: 276 Number of points : 0 Number of lines : 0 Number of boundaries: 138 Number of centroids : 138 Number of areas : 138 Number of isles : 138 Writing attributes ... Layer 1 ERROR 1: SQL: Failed to identify field:0 DBMI-OGR driver error: Cannot select: select * from admin98 where 0 = 1 WARNING: Cannot open select cursor: 'select * from admin98 where 0 = 1' WARNING: Cannot copy table Done. The vector map is extracted ok, but the attr table isn't copied. | Number of dblinks: 0 ?, Hamish ps - general IPY interest of what happens in a "corner" case: pic of output v.proj'd into EPSG#3033 attached (LCC). blue crosses indicate +lat_1 and +lat_2 for the projection, centered on the Lambert Glacier (no relation) and Amery Ice Shelf. d.grid -g goes a bit nuts once you zoom out so far from the projection's region of purpose; v.proj held up pretty well except for directly across from +lon_0=70 (middle bottom). 180 lon break is there but easily cleaned with v.clean tool=rmsa PROJ4 values for EPSG Polar Stereographic epsg codes don't exist. -------------- next part -------------- A non-text attachment was scrubbed... Name: Amery.png Type: image/png Size: 15341 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070308/4352ad1e/Amery-0001.png From hamish_nospam at yahoo.com Thu Mar 8 02:48:14 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Mar 8 02:48:26 2007 Subject: [GRASS-dev] latlong problem In-Reply-To: <17902.63291.23400.67190@cerise.gclements.plus.com> References: <17902.50740.995954.315272@cerise.gclements.plus.com> <17902.63291.23400.67190@cerise.gclements.plus.com> Message-ID: <20070308144814.5b241d89.hamish_nospam@yahoo.com> Glynn Clements wrote: > Personally, I'd be tempted to just treat the 180th meridian as a > discontinuity (New Zealanders and Japanese would have to stick to > using projected locations). aw, come on Glynn. I could just as easily argue that folks in the UK should stick to using projected locations and GRASS enforce 0-360. It's no solution. > I wouldn't be surprised if there are a *lot* of places in the code > which ought to contain specific code to handle longitude wrapping but > don't. AFAICT, all the raster and region code is happy to use both +-180 and 0-360 lons; all the vector modules currently don't know or attempt to do anything about it; and as we see here the libgis vector code is a mixed lot. > [E.g. "d.vect ... render=c" doesn't handle it correctly. the one I noticed was: g.region n=90N s=90S w=-180 e=180 v.in.region world_box d.vect world_box > D_polygon_clip() does the clipping in geographic coordinates, before > transforming the vertices to display coordinates. Most of the time, > this is preferable, as you eliminate the conversion overhead for any > points which are discarded by clipping.] > > Actually, this isn't a problem which can be "solved". What do you do > if you *want* a polygon which spans 340? of longitude? How do you > interpret a polygon which spans exactly 180?; which hemisphere does it > cover? So centroid placement is crucial (you should at least be able to trust v.in.ascii form=standard). There are a number of tests for point-in- polygon which could be employed then. As for if the smaller or bigger polygon is "inside" (e.g. world ozone coverage vs hole) for GIS- generated polygons, I guess just keeping with the current mode of "pick the smaller area" is a good choice. Martin's v.in.region bug is that that rule is not consistent throughout the code? Polar lat/lon can also be a display issue (see prev email), but e.g. d.geodesic seems happy enough & reports seemingly correct distances from a lat/lon loc'n. > IOW, I don't think that we'll ever get this "right". Well, hopefully we can get the vector handling code "good enough" that we don't hear any complaints about it (like the region and raster code now). But of course it is much harder to get right than a simple if(a>b) cartesian math. Markus: > Well, to me > http://mpa.itc.it/markus/tmp/admin98_oceans_fixed.png > looks much more reasonable than > http://mpa.itc.it/markus/tmp/admin98_oceans_buggy.png > > Sorry for this stupid comment, but I still think that there is a > problem. And in this case it is a perfect -180 .. 180deg map. The > rendering is ok for 3/4th of the map but not the northern part > (although there is a north boundary in the map, see "fixed" map > example). There is a bug there, but probably we should be careful about "fixing" the problem in the wrong place (discl: I haven't actually looked). Hamish From hamish_nospam at yahoo.com Thu Mar 8 06:26:28 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Mar 8 06:26:45 2007 Subject: [GRASS-dev] using G_parser() --script in the wild In-Reply-To: <17893.64348.200686.75406@cerise.gclements.plus.com> References: <20070227163125.42527d0e.hamish_nospam@yahoo.com> <17892.35477.374032.591612@cerise.gclements.plus.com> <20070228194549.6ec1829f.hamish_nospam@yahoo.com> <17893.64348.200686.75406@cerise.gclements.plus.com> Message-ID: <20070308182628.7ce33b1a.hamish_nospam@yahoo.com> [wrapper script for d.path from the GUI with backdrop] ... > > build up an options string. If $opt1 is "", then the exec command > > just has an extra space in it. > > > > for example: > > > > optstring="" > > if [ "$GIS_FLAG_G" -eq 1 ] ; then > > optstring="$optstring -g" > > fi > > if [ -n "$GIS_OPT_MAP" ] ; then > > optstring="$optstring map=\"$GIS_OPT_MAP\"" > > fi > > exec d.path $optstring > > > > > > or if you think optstring="$optstring ..." is evil, > > It won't work with values which may contain spaces. If you wrap the > value in single quotes, it won't work with values which may contain > single quotes. > > > if [ "$GIS_FLAG_G" -eq 1 ] ; then > > gflag="-g" > > else > > gflag="" > > fi > > if [ -n "$GIS_OPT_AFCOL" ] ; then > > afcol="afcol=\"$GIS_OPT_AFCOL\"" > > else > > afcol="" > > fi > > [...] > > exec d.path $gflag $afcol [...] > > That works; it's just ugly. The fact that afcol, abcol and ncol need > special treatment stands out, and lead me to consider whether there's > a better solution. why do the column name options need special treatment? none of d.path's other options should contain spaces or special chars, so I don't think the quoting is critical. If I quote the column options on the exec line I get this error: if [ -n "$GIS_OPT_AFCOL" ] ; then opt_afcol="afcol=$GIS_OPT_AFCOL" else opt_afcol="" fi [...] exec d.path $flag_g $flag_b \ "$opt_map" "$opt_type" \ "$opt_alayer" "$opt_nlayer" \ "$opt_afcol" "$opt_abcol" "$opt_ncol" \ "$opt_color" "$opt_hcolor" "$opt_bgcolor" "Sorry <> is not a valid option", followed by G_usage(). presumably because "" makes argc++, but the last few argv are empty, and G_parser() loops through argc. similar: # invalid option error d.erase grey \ "" # no error d.erase grey\ "" anyway, any problems with the attached script? will column names require quoting? (e.g. column="Jane's Data") or is that illegal SQL? Hamish -------------- next part -------------- A non-text attachment was scrubbed... Name: d.path_wrapper.sh Type: text/x-sh Size: 4475 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070308/74101a53/d.path_wrapper.bin From glynn at gclements.plus.com Thu Mar 8 06:40:33 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Mar 8 06:40:35 2007 Subject: [GRASS-dev] grass location creation In-Reply-To: References: <20070307154031.2a51146c.hamish_nospam@yahoo.com> <20070307072045.GB3148@bartok.itc.it> Message-ID: <17903.41425.98141.80759@cerise.gclements.plus.com> Jachym Cepicky wrote: > patch for g.region is part of this email > > however, it does not work :-( I took the code from r.in.gdal (main.c > arround lines 526-546), everything looks good.. but it does not work > :-( > + if (flag.savedefault->answer) { > + char *location = G_location_path(); > + char *path = (char *) G_malloc(sizeof(location)+64); > + strcpy(path,location); > + strcat(path,"/PERMANENT/"); > + G__put_window( &window, path, "DEFAULT_WIND" ); > + } The second argument to G__put_window has to be an "element", i.e. a directory in the current mapset. r.in.gdal uses "../PERMANENT", which works because the element is simply concatenated onto the path to the mapset directory. I suggest that you adopt the same approach, i.e.: G__put_window( &window, "../PERMANENT", "DEFAULT_WIND" ); -- Glynn Clements From glynn at gclements.plus.com Thu Mar 8 07:43:10 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Mar 8 07:43:13 2007 Subject: [GRASS-dev] latlong problem In-Reply-To: <20070308144814.5b241d89.hamish_nospam@yahoo.com> References: <17902.50740.995954.315272@cerise.gclements.plus.com> <17902.63291.23400.67190@cerise.gclements.plus.com> <20070308144814.5b241d89.hamish_nospam@yahoo.com> Message-ID: <17903.45182.433825.555991@cerise.gclements.plus.com> Hamish wrote: > > Personally, I'd be tempted to just treat the 180th meridian as a > > discontinuity (New Zealanders and Japanese would have to stick to > > using projected locations). > > aw, come on Glynn. I could just as easily argue that folks in the UK > should stick to using projected locations and GRASS enforce 0-360. > It's no solution. No, the only *solution* is to write two versions of every piece of code which deals with coordinates. One version would use the rules of Euclidean geometry and would work with projected coordinates, the other would use the rules of non-Euclidean (specifically, elliptical) geometry and handle lat/lon coordinates. The problem arises when you try to use the same code (with a couple of minor tweaks) for both cases. So far as vector data is concerned, the simplest solution would be to ensure that wraparound never occurs within a single polygon (e.g. a triangle on the 180th meridian would be [(180,10),(170,0),(190,0)], and not [(180,10),(170,0),(-170,0)]. OTOH, that could create problems when edges are shared between polygons. It would probably mean that a whole-earth map would span more than 360?. Rendering regions crossing the 180th meridian would be problematic (well, you could just render the data twice, with a 360? offset). That still doesn't allow for polar regions; realistically, you would need to "cut" such regions so that the pole formed a vertex. -- Glynn Clements From glynn at gclements.plus.com Thu Mar 8 08:07:48 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Mar 8 08:07:51 2007 Subject: [GRASS-dev] using G_parser() --script in the wild In-Reply-To: <20070308182628.7ce33b1a.hamish_nospam@yahoo.com> References: <20070227163125.42527d0e.hamish_nospam@yahoo.com> <17892.35477.374032.591612@cerise.gclements.plus.com> <20070228194549.6ec1829f.hamish_nospam@yahoo.com> <17893.64348.200686.75406@cerise.gclements.plus.com> <20070308182628.7ce33b1a.hamish_nospam@yahoo.com> Message-ID: <17903.46660.811661.327919@cerise.gclements.plus.com> Hamish wrote: > > > if [ "$GIS_FLAG_G" -eq 1 ] ; then > > > gflag="-g" > > > else > > > gflag="" > > > fi > > > if [ -n "$GIS_OPT_AFCOL" ] ; then > > > afcol="afcol=\"$GIS_OPT_AFCOL\"" > > > else > > > afcol="" > > > fi > > > [...] > > > exec d.path $gflag $afcol [...] > > > > That works; it's just ugly. The fact that afcol, abcol and ncol need > > special treatment stands out, and lead me to consider whether there's > > a better solution. > > why do the column name options need special treatment? Because their default values are NULL pointers, which cannot be specified via the command line. For all of the other cases, we can specify the option along with its default value. > none of d.path's other options should contain spaces or special chars, > so I don't think the quoting is critical. Oh, we could treat all of the options the same as afcol= etc, but that's more code, and unnecessary. > If I quote the column options on the exec line I get this error: > > if [ -n "$GIS_OPT_AFCOL" ] ; then > opt_afcol="afcol=$GIS_OPT_AFCOL" > else > opt_afcol="" > fi > > [...] > > exec d.path $flag_g $flag_b \ > "$opt_map" "$opt_type" \ > "$opt_alayer" "$opt_nlayer" \ > "$opt_afcol" "$opt_abcol" "$opt_ncol" \ > "$opt_color" "$opt_hcolor" "$opt_bgcolor" > > > "Sorry <> is not a valid option", followed by G_usage(). A pointer to an empty string (i.e. with NUL as the first byte) isn't the same as a NULL pointer, and an empty string isn't a valid value for the "afcol=" option. The other options are either required or have a default value which isn't a NULL pointer. E.g. type= defaults to "line,boundary"; if the type= option isn't passed to the script, then: d.vect ... type=$GIS_OPT_TYPE has the same effect as simply not passing the type= option; both will result in type->answer pointing to "line,boundary". However, for options whose default value is a NULL pointer, using d.vect ... afcol= ... isn't the same as omitting it. Omitting it will result in afcol->answer being NULL, while "afcol=" with an empty value will result in afcol->answer pointing to an empty string. > anyway, any problems with the attached script? The changes will work, but aren't necessary; they just increase the size of the script without changing its behaviour. > will column names require quoting? (e.g. column="Jane's Data") > or is that illegal SQL? SQL column names are limited to alphanumerics and underscore. -- Glynn Clements From glynn at gclements.plus.com Thu Mar 8 08:23:56 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu Mar 8 08:24:59 2007 Subject: [GRASS-dev] latlong problem In-Reply-To: <17902.63291.23400.67190@cerise.gclements.plus.com> References: <17902.50740.995954.315272@cerise.gclements.plus.com> <17902.63291.23400.67190@cerise.gclements.plus.com> Message-ID: <17903.47628.652722.946724@cerise.gclements.plus.com> Glynn Clements wrote: > Actually, this isn't a problem which can be "solved". What do you do > if you *want* a polygon which spans 340? of longitude? How do you > interpret a polygon which spans exactly 180?; which hemisphere does it > cover? > > IOW, I don't think that we'll ever get this "right". BTW, people with far more resources than us manage to get this wrong: http://www.defensenews.com/story.php?F=2590456&C=america -- Glynn Clements From jachym.cepicky at gmail.com Thu Mar 8 08:26:57 2007 From: jachym.cepicky at gmail.com (Jachym Cepicky) Date: Thu Mar 8 08:27:00 2007 Subject: [GRASS-dev] grass location creation In-Reply-To: <17903.41425.98141.80759@cerise.gclements.plus.com> References: <20070307154031.2a51146c.hamish_nospam@yahoo.com> <20070307072045.GB3148@bartok.itc.it> <17903.41425.98141.80759@cerise.gclements.plus.com> Message-ID: Thanks, Glynn, worked perfect Patch commited jachym 2007/3/8, Glynn Clements : > > Jachym Cepicky wrote: > > > patch for g.region is part of this email > > > > however, it does not work :-( I took the code from r.in.gdal (main.c > > arround lines 526-546), everything looks good.. but it does not work > > :-( > > > + if (flag.savedefault->answer) { > > + char *location = G_location_path(); > > + char *path = (char *) G_malloc(sizeof(location)+64); > > + strcpy(path,location); > > + strcat(path,"/PERMANENT/"); > > + G__put_window( &window, path, "DEFAULT_WIND" ); > > + } > > The second argument to G__put_window has to be an "element", i.e. a > directory in the current mapset. r.in.gdal uses "../PERMANENT", which > works because the element is simply concatenated onto the path to the > mapset directory. > > I suggest that you adopt the same approach, i.e.: > > G__put_window( &window, "../PERMANENT", "DEFAULT_WIND" ); > > -- > Glynn Clements > -- Jachym Cepicky e-mail: jachym.cepicky gmail com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub From landa.martin at gmail.com Thu Mar 8 10:02:05 2007 From: landa.martin at gmail.com (Martin Landa) Date: Thu Mar 8 10:02:07 2007 Subject: [GRASS-dev] latlong problem In-Reply-To: <45EEF8FA.7040409@itc.it> References: <17902.50740.995954.315272@cerise.gclements.plus.com> <17902.63291.23400.67190@cerise.gclements.plus.com> <45EEF8FA.7040409@itc.it> Message-ID: Hi, just stupidly playing around;-) [1] d.erase;d.vect cs [2] d.erase;d.vect cs render=r [3] d.erase;d.vect cs render=d [4] d.erase;d.vect cs render=c -> [1] Antarctica buggy -> [2-4] OK I pan a bit: [5] the same (original [1]) [6] some areas are not filled ([2-4]) [1] http://gama.fsv.cvut.cz/~landa/.../grass/latlong-render/cs1.png [2] http://gama.fsv.cvut.cz/~landa/.../grass/latlong-render/cs2.png [3] http://gama.fsv.cvut.cz/~landa/.../grass/latlong-render/cs3.png [4] http://gama.fsv.cvut.cz/~landa/.../grass/latlong-render/cs4.png [5] http://gama.fsv.cvut.cz/~landa/.../grass/latlong-render/cs5.png [6] http://gama.fsv.cvut.cz/~landa/.../grass/latlong-render/cs6.png BTW with my patch render=g seems to work without any problem (also the lowest boundary of Antarctica is rendered, strangely). But it is not solving the problem. The problem should be fixed somewhere else (AFAIU Glynn's and Hamish's notes). Regards, Martin 2007/3/7, Markus Neteler : > Glynn Clements wrote on 03/07/2007 06:32 PM: > > ... > > Actually, this isn't a problem which can be "solved". What do you do > > if you *want* a polygon which spans 340? of longitude? How do you > > interpret a polygon which spans exactly 180?; which hemisphere does it > > cover? > > > > IOW, I don't think that we'll ever get this "right". > > > > Well, to me > http://mpa.itc.it/markus/tmp/admin98_oceans_fixed.png > looks much more reasonable than > http://mpa.itc.it/markus/tmp/admin98_oceans_buggy.png > > Sorry for this stupid comment, but I still think that there is a problem. > And in this case it is a perfect -180 .. 180deg map. The rendering is > ok for 3/4th of the map but not the northern part (although there > is a north boundary in the map, see "fixed" map example). > > 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 benjamin.ducke at ufg.uni-kiel.de Thu Mar 8 14:28:00 2007 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Thu Mar 8 14:13:29 2007 Subject: [GRASS-dev] GEM updates in CVS In-Reply-To: <20070307135327.GA3694@bartok.itc.it> References: <20070307135327.GA3694@bartok.itc.it> Message-ID: <45F00F60.9080707@ufg.uni-kiel.de> Hi, I just committed a number of changes to GEM in the CVS. Changes: - removed all interaction on the console to be consistent with GRASS command line tools behaviour. This means that users may now have to su before running GEM in order to install into a system-wide GRASS directory - removed/changed everything that was not POSIX compliant. GEM now compiles fine under MINGW32/MSYS, although I did not yet get a chance to test if it's working - the binary is now called gem6 instead of gem to avoid conflicts with the Ruby tool - added a few options - updated documentation This also required a minor tweak of the real-install action in the main GRASS Makefile so that it now picks up the 'gem6' binary from the 'gem' dir. Hope this comes in time for the 6.3 preview release. Can't wait to see that happen! Best, Benjamin Markus Neteler wrote: > On Wed, Mar 07, 2007 at 02:03:58PM +0100, Martin Landa wrote: >> Hi, >> >> there is a significant problem in LatLong location. Try the following: >> >> g.region n=80 s=-80 w=-170 e=170 res=1; >> v.in.region out=reg; >> g.region n=90 s=-90 w=-180 e=180 res=1; >> d.erase;d.vect reg >> [1] should be [2] >> >> I prepared a simple patch to fix this bug. >> >> I am not sure whether it is OK. Anyway testing "(east1 - east2) > 180" >> does not make sense to me... or am I wrong? >> >> Martin >> >> [1] http://gama.fsv.cvut.cz/~landa/.../grass/reg.png >> [2] http://gama.fsv.cvut.cz/~landa/.../grass/reg2.png > > Great work, Martin! > > This patch cures the problem of > http://mpa.itc.it/markus/tmp/admin98_oceans_buggy.png > to > http://mpa.itc.it/markus/tmp/admin98_oceans_fixed.png > > Unrelated bug (?): The boundary box at the East end isn't > visible - is the display driver cutting off by 1 pixel from > East? The region is 90N, 90S, 180W, 180E, Latlong WGS84. > See admin98_oceans_fixed.png for illustration, generated > with d.out.png. > > Markus > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > > -- Benjamin Ducke, M.A. Arch?oinformatik (Archaeoinformation Science) Institut f?r Ur- und Fr?hgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universit?t zu Kiel Johanna-Mestorf-Stra?e 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg From neteler at itc.it Thu Mar 8 14:40:44 2007 From: neteler at itc.it (Markus Neteler) Date: Thu Mar 8 14:40:45 2007 Subject: [GRASS-dev] latlong problem In-Reply-To: <17903.47628.652722.946724@cerise.gclements.plus.com> References: <17902.50740.995954.315272@cerise.gclements.plus.com> <17902.63291.23400.67190@cerise.gclements.plus.com> <17903.47628.652722.946724@cerise.gclements.plus.com> Message-ID: <45F0125C.6020709@itc.it> Glynn Clements wrote on 03/08/2007 08:23 AM: > Glynn Clements wrote: > > >> Actually, this isn't a problem which can be "solved". What do you do >> if you *want* a polygon which spans 340? of longitude? How do you >> interpret a polygon which spans exactly 180?; which hemisphere does it >> cover? >> >> IOW, I don't think that we'll ever get this "right". >> > > BTW, people with far more resources than us manage to get this wrong: > > http://www.defensenews.com/story.php?F=2590456&C=america > > "In less than 48 hours, F-22A contractor Lockheed Martin delivered a software fix. An F-22A at Nellis successfully flew with the updated software, Bergeson said. " We can still beat that :) Markus From neteler at itc.it Thu Mar 8 17:13:35 2007 From: neteler at itc.it (Markus Neteler) Date: Thu Mar 8 17:13:37 2007 Subject: [GRASS-dev] Scripts updated in GRASS 6.2-CVS rel branch Message-ID: <45F0362F.8080105@itc.it> Hi, I have backported a series of fixes in the directory scripts/ of GRASS 6.2-CVS release branch. We should get out 6.2.2 in the near future since we have accumulates a couple of important fixed there. Please make some tests to see if I broke anything by backporting changes. Markus From woklist at kyngchaos.com Thu Mar 8 18:06:56 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Thu Mar 8 18:07:13 2007 Subject: [GRASS-dev] init.sh OSX browser setting Message-ID: <2421047E-8C98-40FA-98E5-4A7D96CDD3F5@kyngchaos.com> [summary for list] Two problems with the way GRASS opens help files in OSX: Init.sh uses a plain 'open' as the default for the browser in Mac OS X. This will open help files in whatever application a user has their system set to open html files in. By default this is Safari, but it may not be a browser but a text editor (ie for those web programmers), and for viewing help that's not helpful. And, if a user wants a different browser for GRASS (and doesn't want to change their general system default browser), the normal unix executable way is not right, that is setting, say, /Applications/ Firefox.app/Contents/MacOS/Firefox. This opens the application, but if it's already running it opens another instance - not right on OSX. The way to handle these problems is to add options to the open command: open -a /path/to/app/package.app or: open -b app.signature This causes a problem in the scripts, since $GRASS_HTML_BROWSER is quoted everywhere - it tries to execute "open -a /path/to/app/ package.app" as the name of a program, not "open". So, I tried two ways to handle this. [/summary] So far I have (in init.sh): - alias method - doesn't work, command not found alias opengrasshelp='open -b com.apple.helpviewer' GRASS_HTML_BROSWER=opengrasshelp export GRASS_HTML_BROWSER Help button in GUI startup and help menu in GUI and in command dialogs: couldn't execute "opengrasshelp": no such file or directory or if I try to run 'opengrasshelp' from the GRASS prompt: bash: opengrasshelp: command not found - script method - an extra etc script html_browser_mac.sh opens the help file in the browser set in GRASS_HTML_BROWSER_MACOSX This works as a default browser: GRASS_HTML_BROWSER="$ETC/html_browser_mac.sh" GRASS_HTML_BROWSER_MACOSX="-b com.apple.helpviewer" export GRASS_HTML_BROWSER_MACOSX export GRASS_HTML_BROWSER This also works: GRASS_HTML_BROWSER_MACOSX="-b org.mozilla.firefox" But this opens the default system browser: GRASS_HTML_BROWSER_MACOSX="-a /Applications/Firefox.app" It opens the default browser when used in the Help menu and dialogs, BUT works correctly if typed at the GRASS prompt, like: > $GRASS_HTML_BROWSER_MACOSX /path/to/some/hemp/file.html I can use the browser signature method, and would prefer that - it's simpler for the user, and I can put tests in init.sh for common browsers so the user just needs to set GRASS_HTML_BROWSER to a name. But I don't know the signatures for any other browser than Safari and Firefox, so those would have to be filled in. I could force the signature method as the only method. Leave browsers that I know as above, but for other browsers the user would have to figure out their signatures. ----- William Kyngesburye http://www.kyngchaos.com/ First Pogril: Why is life like sticking your head in a bucket filled with hyena offal? Second Pogril: I don't know. Why IS life like sticking your head in a bucket filled with hyena offal? First Pogril: I don't know either. Wretched, isn't it? -HitchHiker's Guide to the Galaxy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070308/c3979ea0/attachment.html From benjamin.ducke at ufg.uni-kiel.de Thu Mar 8 19:30:03 2007 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Thu Mar 8 19:15:32 2007 Subject: [GRASS-dev] r.los and r.cva on win32 Message-ID: <45F0562B.9090506@ufg.uni-kiel.de> Hi, as those of you who followed the discussions on r.cva/r.los on the Win32 platform lately may remember that there is a problem in the r.los code that leads to segfaults on Win32 (mingw/msys). The general problem is that Linux has a pretty relaxed mem management: if memory is free'd and then accessed, it does not create a fatal conditition as long as that mem region was not changed in the meantime. Thus, programmers get away with a lot of unclean memory handling. On Win32, the mem manager seems to be more strict and this leads to segfaults in the same situation. Since there is a lot of demand for visibility analysis with GRASS, I decided to give r.los some testing with GDB and valgrind. This is what I could track the problem down to: pts_elim.c: line 103: in some freakish circumstance, CHECKED_PT is set to point to a a region that was previously free'd. The next attempt at accessing its data fields will crash the program. The free'ing is done by delete.c, lines 39 and 47. Obviously, there is a missing condition here, so that a point gets deleted from the processing list prematurely. If I comment out both G_free() statements, r.los finishes its job! However, this causes a nice big mem leak, of course (sth. like 12 bytes per cell within the considered radius) ... At this point, my brain gets fried, because I do not understand the logics behind r.los point data handling, how it builds the list of points to process and how it deletes them. If someone could figure this one out, or at least supply me with further hints, r.los and thus r.cva will be able to run on Win32, allowing us to include both in the next GRASS stable version. I am sure lots of people would appreciate it! Best, Benjamin -- Benjamin Ducke, M.A. Arch?oinformatik (Archaeoinformation Science) Institut f?r Ur- und Fr?hgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universit?t zu Kiel Johanna-Mestorf-Stra?e 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg From grass-codei at wald.intevation.org Thu Mar 8 19:57:44 2007 From: grass-codei at wald.intevation.org (grass-codei@wald.intevation.org) Date: Thu Mar 8 19:57:47 2007 Subject: [GRASS-dev] [grass-code I][323] grass63.bat installed on Linux Message-ID: <20070308185744.235D71839D03@pyrosoma.intevation.org> code I item #323, was opened at 2007-03-08 19:57 Status: Open Priority: 3 Submitted By: Maciej Sieczka (msieczka) Assigned to: Nobody (None) Summary: grass63.bat installed on Linux Issue type: other bug Issue status: None GRASS version: CVS HEAD GRASS component: install Operating system: Linux Operating system version: Ubuntu Dapper GRASS CVS checkout date, if applies (YYMMDD): 070308 Initial Comment: grass63.bat gets installed on Linux. I guess it should not, should it? Maciek ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=323&group_id=21 From grass-codei at wald.intevation.org Thu Mar 8 21:04:49 2007 From: grass-codei at wald.intevation.org (grass-codei@wald.intevation.org) Date: Thu Mar 8 21:04:52 2007 Subject: [GRASS-dev] [grass-code I][324] lwidth error Message-ID: <20070308200449.9BE291839D03@pyrosoma.intevation.org> code I item #324, was opened at 2007-03-08 21:04 Status: Open Priority: 3 Submitted By: Carlos D?vila (carluti) Assigned to: Nobody (None) Summary: lwidth error Issue type: None Issue status: None GRASS version: CVS HEAD GRASS component: vector Operating system: Linux Operating system version: debian testing GRASS CVS checkout date, if applies (YYMMDD): 070303 Initial Comment: In GIS Manager, if I have lines check box unchecked and then uncheck boundary check box next error appears: can't read "lwidth": no such variable can't read "lwidth": no such variable while executing "$leg create line $x1 $yc $x2 $yc -fill $opt($id,1,color) -width $lwidth" (procedure "GmVector::legend" line 58) invoked from within "GmVector::legend 2" invoked from within ".mainframe.frame.pw1.f1.frame.sw.sf.frame.fr.type.c invoke" ("uplevel" body line 1) invoked from within "uplevel #0 [list $w $cmd]" (procedure "tk::CheckRadioInvoke" line 3) invoked from within "tk::CheckRadioInvoke .mainframe.frame.pw1.f1.frame.sw.sf.frame.fr.type.c" (command bound to event) Same error happens in the opposite case: boundary check box is unchecked and then I uncheck lines check box and also when I uncheck area check box in a point vector map: can't read "lwidth": no such variable can't read "lwidth": no such variable while executing "$leg create line $x1 $yc $x2 $yc -fill $opt($id,1,color) -width $lwidth" (procedure "GmVector::legend" line 58) invoked from within "GmVector::legend 3" invoked from within ".mainframe.frame.pw1.f1.frame.sw.sf.frame.fr.type.e invoke" ("uplevel" body line 1) invoked from within "uplevel #0 [list $w $cmd]" (procedure "tk::CheckRadioInvoke" line 3) invoked from within "tk::CheckRadioInvoke .mainframe.frame.pw1.f1.frame.sw.sf.frame.fr.type.e" (command bound to event) ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=324&group_id=21 From hamish_nospam at yahoo.com Thu Mar 8 23:21:15 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Thu Mar 8 23:21:27 2007 Subject: [GRASS-dev] grass location creation In-Reply-To: <17903.41425.98141.80759@cerise.gclements.plus.com> References: <20070307154031.2a51146c.hamish_nospam@yahoo.com> <20070307072045.GB3148@bartok.itc.it> <17903.41425.98141.80759@cerise.gclements.plus.com> Message-ID: <20070309112115.349fe956.hamish_nospam@yahoo.com> Glynn Clements wrote: > > + if (flag.savedefault->answer) { > > + char *location = G_location_path(); > > + char *path = (char *) G_malloc(sizeof(location)+64); > > + strcpy(path,location); > > + strcat(path,"/PERMANENT/"); > > + G__put_window( &window, path, "DEFAULT_WIND" ); > > + } > > The second argument to G__put_window has to be an "element", i.e. a > directory in the current mapset. r.in.gdal uses "../PERMANENT", which > works because the element is simply concatenated onto the path to the > mapset directory. > > I suggest that you adopt the same approach, i.e.: > > G__put_window( &window, "../PERMANENT", "DEFAULT_WIND" ); as this should only be working if the current mapset is PERMANENT, could/should that be shortened to "."? G__put_window( &window, ".", "DEFAULT_WIND" ); Hamish From glynn at gclements.plus.com Fri Mar 9 03:52:15 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Mar 9 03:53:19 2007 Subject: [GRASS-dev] grass location creation In-Reply-To: <20070309112115.349fe956.hamish_nospam@yahoo.com> References: <20070307154031.2a51146c.hamish_nospam@yahoo.com> <20070307072045.GB3148@bartok.itc.it> <17903.41425.98141.80759@cerise.gclements.plus.com> <20070309112115.349fe956.hamish_nospam@yahoo.com> Message-ID: <17904.52191.652632.439057@cerise.gclements.plus.com> Hamish wrote: > > > + if (flag.savedefault->answer) { > > > + char *location = G_location_path(); > > > + char *path = (char *) G_malloc(sizeof(location)+64); > > > + strcpy(path,location); > > > + strcat(path,"/PERMANENT/"); > > > + G__put_window( &window, path, "DEFAULT_WIND" ); > > > + } > > > > The second argument to G__put_window has to be an "element", i.e. a > > directory in the current mapset. r.in.gdal uses "../PERMANENT", which > > works because the element is simply concatenated onto the path to the > > mapset directory. > > > > I suggest that you adopt the same approach, i.e.: > > > > G__put_window( &window, "../PERMANENT", "DEFAULT_WIND" ); > > as this should only be working if the current mapset is PERMANENT, > could/should that be shortened to "."? > > G__put_window( &window, ".", "DEFAULT_WIND" ); If it only needs to work in PERMANENT, use "". -- Glynn Clements From hamish_nospam at yahoo.com Fri Mar 9 04:49:12 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Fri Mar 9 04:49:19 2007 Subject: [GRASS-dev] Scripts updated in GRASS 6.2-CVS rel branch In-Reply-To: <45F0362F.8080105@itc.it> References: <45F0362F.8080105@itc.it> Message-ID: <20070309164912.3a204510.hamish_nospam@yahoo.com> Markus wrote: > We should get out 6.2.2 in the near future since we have accumulates a > couple of important fixed there. Q: should we violate the "important bug fixes only" rule and backport Michael's nice EPSG file startup search tool to the 6.2 branch? [just the TCL search tool, not the "g.proj -c epsg=" code] Hamish From paulk at ukshells.co.uk Fri Mar 9 04:54:06 2007 From: paulk at ukshells.co.uk (Paul D Kelly) Date: Fri Mar 9 04:54:10 2007 Subject: [GRASS-dev] grass location creation In-Reply-To: References: <20070307154031.2a51146c.hamish_nospam@yahoo.com> <20070307072045.GB3148@bartok.itc.it> <17903.41425.98141.80759@cerise.gclements.plus.com> Message-ID: On Thu, 8 Mar 2007, Jachym Cepicky wrote: > Thanks, Glynn, worked perfect > > Patch commited > > jachym > > 2007/3/8, Glynn Clements : >> >> Jachym Cepicky wrote: >> >> > patch for g.region is part of this email >> > >> > however, it does not work :-( I took the code from r.in.gdal (main.c >> > arround lines 526-546), everything looks good.. but it does not work >> > :-( >> >> > + if (flag.savedefault->answer) { >> > + char *location = G_location_path(); >> > + char *path = (char *) G_malloc(sizeof(location)+64); >> > + strcpy(path,location); >> > + strcat(path,"/PERMANENT/"); >> > + G__put_window( &window, path, "DEFAULT_WIND" ); >> > + } >> >> The second argument to G__put_window has to be an "element", i.e. a >> directory in the current mapset. r.in.gdal uses "../PERMANENT", which >> works because the element is simply concatenated onto the path to the >> mapset directory. >> >> I suggest that you adopt the same approach, i.e.: >> >> G__put_window( &window, "../PERMANENT", "DEFAULT_WIND" ); >> >> -- >> Glynn Clements >> > > > -- > Jachym Cepicky > e-mail: jachym.cepicky gmail com > URL: http://les-ejk.cz > GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > From paul-grass at stjohnspoint.co.uk Fri Mar 9 05:00:13 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Fri Mar 9 05:00:16 2007 Subject: [GRASS-dev] grass location creation In-Reply-To: References: <20070307154031.2a51146c.hamish_nospam@yahoo.com> <20070307072045.GB3148@bartok.itc.it> <17903.41425.98141.80759@cerise.gclements.plus.com> Message-ID: Hello Jachym On Thu, 8 Mar 2007, Jachym Cepicky wrote: > Thanks, Glynn, worked perfect > > Patch commited Is there a check that the mapset is PERMANENT? It should fail with an error if the new flag is specified and the mapset isn't PERMANENT, like I *think* g.proj -c without location= specified does and like I *think* Helena also suggested? This is really important functionality to have - good that we're finally getting round to adding it ;) Paul > > jachym > > 2007/3/8, Glynn Clements : >> >> Jachym Cepicky wrote: >> >> > patch for g.region is part of this email >> > >> > however, it does not work :-( I took the code from r.in.gdal (main.c >> > arround lines 526-546), everything looks good.. but it does not work >> > :-( >> >> > + if (flag.savedefault->answer) { >> > + char *location = G_location_path(); >> > + char *path = (char *) G_malloc(sizeof(location)+64); >> > + strcpy(path,location); >> > + strcat(path,"/PERMANENT/"); >> > + G__put_window( &window, path, "DEFAULT_WIND" ); >> > + } >> >> The second argument to G__put_window has to be an "element", i.e. a >> directory in the current mapset. r.in.gdal uses "../PERMANENT", which >> works because the element is simply concatenated onto the path to the >> mapset directory. >> >> I suggest that you adopt the same approach, i.e.: >> >> G__put_window( &window, "../PERMANENT", "DEFAULT_WIND" ); >> >> -- >> Glynn Clements >> > > > -- > Jachym Cepicky > e-mail: jachym.cepicky gmail com > URL: http://les-ejk.cz > GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > From glynn at gclements.plus.com Fri Mar 9 07:57:00 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Mar 9 07:57:03 2007 Subject: [GRASS-dev] latlong problem In-Reply-To: References: Message-ID: <17905.1340.68700.986412@cerise.gclements.plus.com> Martin Landa wrote: > there is a significant problem in LatLong location. Try the following: > > g.region n=80 s=-80 w=-170 e=170 res=1; > v.in.region out=reg; > g.region n=90 s=-90 w=-180 e=180 res=1; > d.erase;d.vect reg > [1] should be [2] > > I prepared a simple patch to fix this bug. > > I am not sure whether it is OK. Anyway testing "(east1 - east2) > 180" > does not make sense to me... or am I wrong? I've committed a change to v.in.region to add additional vertices if a lat/lon region is wider than 179?, so such regions shouldn't get turned inside-out by code which uses the "shortest route" maxim. Also, I've modified D_polygon_clip (used by "d.vect render=c") to handle longitude wrap. It doesn't handle polygons which contain a pole, but the other rendering methods don't handle that either (in fact, I doubt that many things *do* handle that case). OTOH, it should handle polygons which make multiple "orbits" (e.g. an "apple peel" spiral). -- Glynn Clements From benjamin.ducke at ufg.uni-kiel.de Fri Mar 9 09:18:58 2007 From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke) Date: Fri Mar 9 09:04:25 2007 Subject: [GRASS-dev] DBMI troubles on Win32 Message-ID: <45F11872.3060600@ufg.uni-kiel.de> Hi all, I am currently doing a lot of testing for GRASS 6.3. on the mingw/msys platform (the same that comes with QGIS). There seems to be a problem related to the DBMI protocol. Modules that access attribute data via the GRASS DBMI lib have a habit of hanging once in a while. I have seen this happen on half a dozen different machines with Win2000 and XP. An example is v.info -c. The module simply hangs and has to be killed and restarted until it does its work. The strange thing is that I cannot find any pattern here: sometimes dozens of runs show no problems at all and sometimes I have to restart a module several times until it starts running. Also, this seems to concern only the first DB access. I have a module here that does hundreds of DB accesses during each run. If the first one goes OK, all the others will be fine too ... I am using the latest 6.3 CVS sources for my tests. I am at a loss here. Can anyone confirm this problem? Thanks, Benjamin -- Benjamin Ducke, M.A. Arch?oinformatik (Archaeoinformation Science) Institut f?r Ur- und Fr?hgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universit?t zu Kiel Johanna-Mestorf-Stra?e 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg From landa.martin at gmail.com Fri Mar 9 09:07:18 2007 From: landa.martin at gmail.com (Martin Landa) Date: Fri Mar 9 09:07:21 2007 Subject: [GRASS-dev] latlong problem In-Reply-To: <17905.1340.68700.986412@cerise.gclements.plus.com> References: <17905.1340.68700.986412@cerise.gclements.plus.com> Message-ID: Glynn, 2007/3/9, Glynn Clements : > > Martin Landa wrote: > > > there is a significant problem in LatLong location. Try the following: > > > > g.region n=80 s=-80 w=-170 e=170 res=1; > > v.in.region out=reg; > > g.region n=90 s=-90 w=-180 e=180 res=1; > > d.erase;d.vect reg > > [1] should be [2] > > > > I prepared a simple patch to fix this bug. > > > > I am not sure whether it is OK. Anyway testing "(east1 - east2) > 180" > > does not make sense to me... or am I wrong? > > I've committed a change to v.in.region to add additional vertices if a > lat/lon region is wider than 179?, so such regions shouldn't get > turned inside-out by code which uses the "shortest route" maxim. > > Also, I've modified D_polygon_clip (used by "d.vect render=c") to > handle longitude wrap. It doesn't handle polygons which contain a > pole, but the other rendering methods don't handle that either (in > fact, I doubt that many things *do* handle that case). OTOH, it should > handle polygons which make multiple "orbits" (e.g. an "apple peel" > spiral). g.region n=90 s=-90 w=-180 e=180; v.in.region out=reg works well, thanks! Trying to display world map, the problem with Antarctica still remains, now it is not filled. Maybe "buggy" boundaries. Not sure. Just for comment, when I enable (east1 - east2) > 360, the area is filled correctly. In summary, render=g -> Antarctica filled wrongly render=r -> OK (don't d.zoom -p) render=d -> as render=r render=c -> now not filled The testing location is here if you are interested http://gama.fsv.cvut.cz/~landa/.../grass/latlong.tar.gz Martin > -- > Glynn Clements > -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From jachym.cepicky at gmail.com Fri Mar 9 09:09:31 2007 From: jachym.cepicky at gmail.com (Jachym Cepicky) Date: Fri Mar 9 09:09:33 2007 Subject: [GRASS-dev] grass location creation In-Reply-To: References: <20070307154031.2a51146c.hamish_nospam@yahoo.com> <20070307072045.GB3148@bartok.itc.it> <17903.41425.98141.80759@cerise.gclements.plus.com> Message-ID: Hi: general/g.region/cmd/main.c: 851 if (flag.savedefault->answer) 852 if (strcmp(G_mapset(),"PERMANENT") == 0) 853 G__put_window( &window, "../PERMANENT", "DEFAULT_WIND" ); 854 else 855 G_warning(_("You are not in mapset PERMANENT, default region -> remains untached")); is it sufficient? Jachym 2007/3/9, Paul Kelly : > Hello Jachym > > On Thu, 8 Mar 2007, Jachym Cepicky wrote: > > > Thanks, Glynn, worked perfect > > > > Patch commited > > Is there a check that the mapset is PERMANENT? It should fail with an > error if the new flag is specified and the mapset isn't PERMANENT, like I > *think* g.proj -c without location= specified does and like I *think* > Helena also suggested? > > This is really important functionality to have - good that we're finally > getting round to adding it ;) > > Paul > > > > > jachym > > > > 2007/3/8, Glynn Clements : > >> > >> Jachym Cepicky wrote: > >> > >> > patch for g.region is part of this email > >> > > >> > however, it does not work :-( I took the code from r.in.gdal (main.c > >> > arround lines 526-546), everything looks good.. but it does not work > >> > :-( > >> > >> > + if (flag.savedefault->answer) { > >> > + char *location = G_location_path(); > >> > + char *path = (char *) G_malloc(sizeof(location)+64); > >> > + strcpy(path,location); > >> > + strcat(path,"/PERMANENT/"); > >> > + G__put_window( &window, path, "DEFAULT_WIND" ); > >> > + } > >> > >> The second argument to G__put_window has to be an "element", i.e. a > >> directory in the current mapset. r.in.gdal uses "../PERMANENT", which > >> works because the element is simply concatenated onto the path to the > >> mapset directory. > >> > >> I suggest that you adopt the same approach, i.e.: > >> > >> G__put_window( &window, "../PERMANENT", "DEFAULT_WIND" ); > >> > >> -- > >> Glynn Clements > >> > > > > > > -- > > Jachym Cepicky > > e-mail: jachym.cepicky gmail com > > URL: http://les-ejk.cz > > GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub > > > > _______________________________________________ > > grass-dev mailing list > > grass-dev@grass.itc.it > > http://grass.itc.it/mailman/listinfo/grass-dev > > > -- Jachym Cepicky e-mail: jachym.cepicky gmail com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub From neteler at itc.it Fri Mar 9 09:19:57 2007 From: neteler at itc.it (Markus Neteler) Date: Fri Mar 9 09:20:19 2007 Subject: [GRASS-dev] Scripts updated in GRASS 6.2-CVS rel branch In-Reply-To: <20070309164912.3a204510.hamish_nospam@yahoo.com> References: <45F0362F.8080105@itc.it> <20070309164912.3a204510.hamish_nospam@yahoo.com> Message-ID: <45F118AD.1040009@itc.it> Hamish wrote on 03/09/2007 04:49 AM: > Markus wrote: > >> We should get out 6.2.2 in the near future since we have accumulates a >> couple of important fixed there. >> > > Q: should we violate the "important bug fixes only" rule and backport > Michael's nice EPSG file startup search tool to the 6.2 branch? > [just the TCL search tool, not the "g.proj -c epsg=" code] > +1 for violation (means: yes, please) AFAIK there is no 6.2 tutorial yet available, so that screenshots therein are not (yet) affected. Markus From glynn at gclements.plus.com Fri Mar 9 13:35:54 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Mar 9 13:35:58 2007 Subject: [GRASS-dev] latlong problem In-Reply-To: References: <17905.1340.68700.986412@cerise.gclements.plus.com> Message-ID: <17905.21674.406452.415111@cerise.gclements.plus.com> Martin Landa wrote: > > > there is a significant problem in LatLong location. Try the following: > > > > > > g.region n=80 s=-80 w=-170 e=170 res=1; > > > v.in.region out=reg; > > > g.region n=90 s=-90 w=-180 e=180 res=1; > > > d.erase;d.vect reg > > > [1] should be [2] > > > > > > I prepared a simple patch to fix this bug. > > > > > > I am not sure whether it is OK. Anyway testing "(east1 - east2) > 180" > > > does not make sense to me... or am I wrong? > > > > I've committed a change to v.in.region to add additional vertices if a > > lat/lon region is wider than 179?, so such regions shouldn't get > > turned inside-out by code which uses the "shortest route" maxim. > > > > Also, I've modified D_polygon_clip (used by "d.vect render=c") to > > handle longitude wrap. It doesn't handle polygons which contain a > > pole, but the other rendering methods don't handle that either (in > > fact, I doubt that many things *do* handle that case). OTOH, it should > > handle polygons which make multiple "orbits" (e.g. an "apple peel" > > spiral). > > g.region n=90 s=-90 w=-180 e=180; > v.in.region out=reg > > works well, thanks! > > Trying to display world map, the problem with Antarctica still > remains, now it is not filled. Maybe "buggy" boundaries. Not sure. > Just for comment, when I enable (east1 - east2) > 360, the area is > filled correctly. > > In summary, > > render=g -> Antarctica filled wrongly > render=r -> OK (don't d.zoom -p) > render=d -> as render=r > render=c -> now not filled The changes to handle longitude wrapping are likely to discard polygons which bound a pole. More precisely: the euclidify() function traverses the list of longitude values; if a value differs from the previous one by more than ?180?, it has the appropriate multiple of 360? added to it to bring it into range, so that all line segments span no more than 180?. If the gap between the first and last values exceeds 180?, the (presumed) polygon cannot be mapped to the Euclidean plane. One way to look at is: if you adjust the first point to fall within ?180? of the final point, you then have to adjust the second point to fall within ?180? of the first point, and so on, resulting in an infinite loop. Another way to look at it is that there is no way to cut the cylindrical lat/lon surface so that it forms a plane without breaking the polygon's boundary. > The testing location is here if you are interested > > http://gama.fsv.cvut.cz/~landa/.../grass/latlong.tar.gz I note that the largest polygon for Antarctica contains a "fix-up" segment between the vertices: 179.9999 -89.9999 -179.9999 -89.9999 If I suppress the "shortest path" maxim for segments where |lat|>89.9? (which will typically be fix-up for the pole), the polygon is considered closed. I also needed to coerce the initial values into the range -180? From glynn at gclements.plus.com Fri Mar 9 13:37:47 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Fri Mar 9 13:37:50 2007 Subject: [GRASS-dev] grass location creation In-Reply-To: References: <20070307154031.2a51146c.hamish_nospam@yahoo.com> <20070307072045.GB3148@bartok.itc.it> <17903.41425.98141.80759@cerise.gclements.plus.com> Message-ID: <17905.21787.662128.415201@cerise.gclements.plus.com> Jachym Cepicky wrote: > general/g.region/cmd/main.c: > > 851 if (flag.savedefault->answer) > 852 if (strcmp(G_mapset(),"PERMANENT") == 0) > 853 G__put_window( &window, "../PERMANENT", "DEFAULT_WIND" ); > 854 else > 855 G_warning(_("You are not in mapset PERMANENT, default region -> remains untached")); > > is it sufficient? 853 G__put_window( &window, "", "DEFAULT_WIND" ); If you're already in PERMANENT, there's no need for "../PERMANENT". Otherwise, fine. -- Glynn Clements From paul-grass at stjohnspoint.co.uk Fri Mar 9 13:42:50 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Fri Mar 9 13:42:53 2007 Subject: [GRASS-dev] grass location creation In-Reply-To: <17905.21787.662128.415201@cerise.gclements.plus.com> References: <20070307154031.2a51146c.hamish_nospam@yahoo.com> <20070307072045.GB3148@bartok.itc.it> <17903.41425.98141.80759@cerise.gclements.plus.com> <17905.21787.662128.415201@cerise.gclements.plus.com> Message-ID: On Fri, 9 Mar 2007, Glynn Clements wrote: > > Jachym Cepicky wrote: > >> general/g.region/cmd/main.c: >> >> 851 if (flag.savedefault->answer) >> 852 if (strcmp(G_mapset(),"PERMANENT") == 0) >> 853 G__put_window( &window, "../PERMANENT", "DEFAULT_WIND" ); >> 854 else >> 855 G_warning(_("You are not in mapset PERMANENT, default region -> remains untached")); >> >> is it sufficient? > > 853 G__put_window( &window, "", "DEFAULT_WIND" ); > > If you're already in PERMANENT, there's no need for "../PERMANENT". > > Otherwise, fine. Yes. My reason for the check was so users cannot overwrite the default region by accident just if they happen to own the PERMANENT mapset, without actually selecting it. Arguably it should be a fatal error rather than a warning but it's fine. Paul > > -- > Glynn Clements > From landa.martin at gmail.com Fri Mar 9 13:49:21 2007 From: landa.martin at gmail.com (Martin Landa) Date: Fri Mar 9 13:49:23 2007 Subject: [GRASS-dev] latlong problem In-Reply-To: <17905.21674.406452.415111@cerise.gclements.plus.com> References: <17905.1340.68700.986412@cerise.gclements.plus.com> <17905.21674.406452.415111@cerise.gclements.plus.com> Message-ID: Hi Glynn, 2007/3/9, Glynn Clements : > More precisely: the euclidify() function traverses the list of > longitude values; if a value differs from the previous one by more > than ?180?, it has the appropriate multiple of 360? added to it to > bring it into range, so that all line segments span no more than 180?. > > If the gap between the first and last values exceeds 180?, the > (presumed) polygon cannot be mapped to the Euclidean plane. > > One way to look at is: if you adjust the first point to fall within > ?180? of the final point, you then have to adjust the second point to > fall within ?180? of the first point, and so on, resulting in an > infinite loop. > > Another way to look at it is that there is no way to cut the > cylindrical lat/lon surface so that it forms a plane without breaking > the polygon's boundary. > > > The testing location is here if you are interested > > > > http://gama.fsv.cvut.cz/~landa/.../grass/latlong.tar.gz > > I note that the largest polygon for Antarctica contains a "fix-up" > segment between the vertices: > > 179.9999 -89.9999 > -179.9999 -89.9999 > > If I suppress the "shortest path" maxim for segments where |lat|>89.9? > (which will typically be fix-up for the pole), the polygon is > considered closed. > > I also needed to coerce the initial values into the range > -180? triangle. Essentially, the radii which (along with the -89.9999th > paralell) formed the cut were both being placed at the left-hand edge. > > With those two changes, Antarctica rendered correctly. Hopefully, > that's likely to be good enough for most practical purposes. Great!, with render=c seems to work. Thanks... Martin -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From jachym.cepicky at gmail.com Fri Mar 9 13:52:18 2007 From: jachym.cepicky at gmail.com (Jachym Cepicky) Date: Fri Mar 9 13:52:21 2007 Subject: [GRASS-dev] grass location creation In-Reply-To: <17905.21787.662128.415201@cerise.gclements.plus.com> References: <20070307154031.2a51146c.hamish_nospam@yahoo.com> <20070307072045.GB3148@bartok.itc.it> <17903.41425.98141.80759@cerise.gclements.plus.com> <17905.21787.662128.415201@cerise.gclements.plus.com> Message-ID: Ok, I also added brackets to make it a bit more safer for reading.. thanks jachym 2007/3/9, Glynn Clements : > > Jachym Cepicky wrote: > > > general/g.region/cmd/main.c: > > > > 851 if (flag.savedefault->answer) > > 852 if (strcmp(G_mapset(),"PERMANENT") == 0) > > 853 G__put_window( &window, "../PERMANENT", "DEFAULT_WIND" ); > > 854 else > > 855 G_warning(_("You are not in mapset PERMANENT, default region -> remains untached")); > > > > is it sufficient? > > 853 G__put_window( &window, "", "DEFAULT_WIND" ); > > If you're already in PERMANENT, there's no need for "../PERMANENT". > > Otherwise, fine. > > -- > Glynn Clements > -- Jachym Cepicky e-mail: jachym.cepicky gmail com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub From neteler at itc.it Fri Mar 9 15:51:43 2007 From: neteler at itc.it (Markus Neteler) Date: Fri Mar 9 15:51:44 2007 Subject: [GRASS-dev] latlong problem In-Reply-To: <45EEF8FA.7040409@itc.it> References: <17902.50740.995954.315272@cerise.gclements.plus.com> <17902.63291.23400.67190@cerise.gclements.plus.com> <45EEF8FA.7040409@itc.it> Message-ID: <45F1747F.7020907@itc.it> Markus Neteler wrote on 03/07/2007 06:40 PM: > Glynn Clements wrote on 03/07/2007 06:32 PM: > >> ... >> Actually, this isn't a problem which can be "solved". What do you do >> if you *want* a polygon which spans 340? of longitude? How do you >> interpret a polygon which spans exactly 180?; which hemisphere does it >> cover? >> >> IOW, I don't think that we'll ever get this "right". >> >> > > Well, to me > http://mpa.itc.it/markus/tmp/admin98_oceans_fixed.png > looks much more reasonable than > http://mpa.itc.it/markus/tmp/admin98_oceans_buggy.png > > Sorry for this stupid comment, but I still think that there is a problem. > And in this case it is a perfect -180 .. 180deg map. The rendering is > ok for 3/4th of the map but not the northern part (although there > is a north boundary in the map, see "fixed" map example). > Joy and happiness! After re-generating the oceans map (using the updated v.in.region), the rendering is correct now (using the standard renderer). Now it looks like http://mpa.itc.it/markus/tmp/admin98_oceans_fixed.png Thanks for the fixes, Glynn! Markus From landa.martin at gmail.com Fri Mar 9 15:54:03 2007 From: landa.martin at gmail.com (Martin Landa) Date: Fri Mar 9 15:54:09 2007 Subject: [GRASS-dev] G_str_to_sql() Message-ID: Hi all, trying to solve [1] I added new function G_str_to_sql() to string.c. Any objections? Just not sure in case I missed something. Martin [1] https://intevation.de/rt/webrt?serial_num=5463&refresh_req=true&transaction=0&do_req_give=true&do_req_give_to=mlanda; -- Martin Landa * http://gama.fsv.cvut.cz/~landa * -------------- next part -------------- A non-text attachment was scrubbed... Name: strings.c.diff Type: application/octet-stream Size: 833 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070309/ae5ed469/strings.c.obj From landa.martin at gmail.com Fri Mar 9 16:10:53 2007 From: landa.martin at gmail.com (Martin Landa) Date: Fri Mar 9 16:10:56 2007 Subject: [GRASS-dev] latlong problem In-Reply-To: References: <17905.1340.68700.986412@cerise.gclements.plus.com> <17905.21674.406452.415111@cerise.gclements.plus.com> Message-ID: Hi, 2007/3/9, Martin Landa : [snip] > > With those two changes, Antarctica rendered correctly. Hopefully, > > that's likely to be good enough for most practical purposes. > > Great!, with render=c seems to work. just note, I tried to add new vertex v.edit map=cs tool=break coords=0,-89.999 and default render methods works also. Not important, just following your notes;-) Martin > Thanks... > > Martin > > -- > Martin Landa * http://gama.fsv.cvut.cz/~landa * > -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From landa.martin at gmail.com Fri Mar 9 17:10:43 2007 From: landa.martin at gmail.com (Martin Landa) Date: Fri Mar 9 17:10:46 2007 Subject: [GRASS-dev] Re: [GRASS-CVS] martinl: grass6/vector/v.distance main.c, 1.36, 1.37 In-Reply-To: <45F075D0.3090206@o2.pl> References: <20070222171600.A88351006AD@lists.intevation.de> <45E7129A.40806@o2.pl> <45E896E7.1000108@o2.pl> <45F075D0.3090206@o2.pl> Message-ID: Hi, 2007/3/8, Maciej Sieczka : > Martin Landa wrote: > > Hi, > > > > right, should be fixed in CVS now. > > I had a moment to look into this again. The segfault is fixed - cool! > However I think another problem remains. In the command: > > $ v.distance from=points to=roads from_type=point to_type=line > from_layer=1 to_layer=1 dmax=-1 upload=cat column=road_cat to_column=cat > > the paramater to_column= is used while the upload=cat. In this case, an > error should propably crop out, since to_column= is reserved for > upload=to_attr only, and it should not be used without it. > > What do you think? Hmm, not sure, using to_column option & use!=to_attr should not affect the result (or?). So why to inform the user about that?;-) Martin -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From tutey at o2.pl Fri Mar 9 20:48:47 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Fri Mar 9 20:48:53 2007 Subject: [GRASS-dev] Re: [GRASS-CVS] martinl: grass6/vector/v.distance main.c, 1.36, 1.37 In-Reply-To: References: <20070222171600.A88351006AD@lists.intevation.de> <45E7129A.40806@o2.pl> <45E896E7.1000108@o2.pl> <45F075D0.3090206@o2.pl> Message-ID: <45F1BA1F.10809@o2.pl> Martin Landa wrote: > 2007/3/8, Maciej Sieczka : >> I had a moment to look into this again. The segfault is fixed - cool! >> However I think another problem remains. In the command: >> >> $ v.distance from=points to=roads from_type=point to_type=line >> from_layer=1 to_layer=1 dmax=-1 upload=cat column=road_cat to_column=cat >> >> the paramater to_column= is used while the upload=cat. In this case, an >> error should propably crop out, since to_column= is reserved for >> upload=to_attr only, and it should not be used without it. >> >> What do you think? > Hmm, not sure, using to_column option & use!=to_attr should not affect > the result (or?). I too *guess* it should not, propably (FWIW, it's upload=to_attr, not use=) . > So why to inform the user about that?;-) Since manual explicitely requires upload=to_attr for to_column= option and vice versa, the module behavior should follow this requirement. Moreover, since upload=to_attr without apropriate to_column= yields an error: ERROR: to_column option missing the to_column= without upload=to_attr should yield an error too, eg.: ERROR: use=to_attr required for option to_column but it does not. Not a great problem - you are right. But keeping the module's behavior sane and consistent would do no harm, and would help. Thanks for your interest anyway. You are doing Great Job sanitising and fixing GRASS. Thank you. Maciek From grass-codei at wald.intevation.org Fri Mar 9 21:47:36 2007 From: grass-codei at wald.intevation.org (grass-codei@wald.intevation.org) Date: Fri Mar 9 21:47:39 2007 Subject: [GRASS-dev] [grass-code I][328] v.in.ascii: skip= does not work Message-ID: <20070309204736.B66A41839D0C@pyrosoma.intevation.org> code I item #328, was opened at 2007-03-09 21:47 Status: Open Priority: 3 Submitted By: Maciej Sieczka (msieczka) Assigned to: Nobody (None) Summary: v.in.ascii: skip= does not work Issue type: module bug Issue status: None GRASS version: CVS HEAD GRASS component: vector Operating system: all Operating system version: GRASS CVS checkout date, if applies (YYMMDD): 070309 Initial Comment: Try this example: echo "a rubbish comment line L 5 1 591336 4927369 1224 594317 4925341 1292 599356 4925162 1469 602396 4926653 1235 607524 4925431 1216 1 321 " | v.in.ascii -n skip=1 out=line format=standard In spite of skip=1, the module yields and error: WARNING: Error reading ascii file: [a rubbish comment line] Another thing is that although the nature of the error is fatal, the module proceeds anyway and exits with status 0. An ERROR should be issued instead of WARNING, and v.in.ascii should exit immadietly with status 1. FWIW, the same information is formatted differently in GRASS 6.2.2 CVS: Error reading ascii file: [a rubbish comment line] (no trailing "WARNING:"). Besides this, the module still tries to continue it's work and exits with 0 in spite of failure, as in 6.3 CVS. Maciek ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=328&group_id=21 From grass-codei at wald.intevation.org Fri Mar 9 23:07:41 2007 From: grass-codei at wald.intevation.org (grass-codei@wald.intevation.org) Date: Fri Mar 9 23:07:43 2007 Subject: [GRASS-dev] [grass-code I][329] r.out.gdal: COMPRESS=JPEG yields "ERROR 1: JPEGSetupEncode:PhotometricInterpretation 3 not allowed for JPEG" Message-ID: <20070309220741.F302C1839D0C@pyrosoma.intevation.org> code I item #329, was opened at 2007-03-09 23:07 Status: Open Priority: 3 Submitted By: Maciej Sieczka (msieczka) Assigned to: Nobody (None) Summary: r.out.gdal: COMPRESS=JPEG yields "ERROR 1: JPEGSetupEncode:PhotometricInterpretation 3 not allowed for JPEG" Issue type: module bug Issue status: None GRASS version: CVS HEAD GRASS component: raster Operating system: all Operating system version: GRASS CVS checkout date, if applies (YYMMDD): 070308 Initial Comment: In spearfish: $ g.region rast=vegcover $ r.out.gdal input=vegcover format=GTiff type=Byte output=tmp/vegcover_jpg.tif createopt=COMPRESS=JPEG 100% ERROR 1: JPEGSetupEncode:PhotometricInterpretation 3 not allowed for JPEG ERROR 1: JPEGSetupEncode:PhotometricInterpretation 3 not allowed for JPEG ERROR 1: JPEGSetupEncode:PhotometricInterpretation 3 not allowed for JPEG ERROR 1: JPEGSetupEncode:PhotometricInterpretation 3 not allowed for JPEG Done! Maciek ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=204&aid=329&group_id=21 From twiens at interbaun.com Sat Mar 10 00:10:27 2007 From: twiens at interbaun.com (Trevor Wiens) Date: Sat Mar 10 00:05:42 2007 Subject: [GRASS-dev] Differential Buffering: Part II Message-ID: <20070309161027.093cd90a@localhost.localdomain> Well, I gave it some thought and decided I would try a vector based solution and made a modified version of v.buffer which accepts north, south, east, and west scale parameters that can be used either with a distance or a buffer column. The basic algorithm used a circle, and since a circle is in fact just a special case of an ellipse I modified the code to have an elliptical curve be calculated based on the four different scale parameters. Now the code works just like v.buffer then all scale factors are equal. However if there are big ranges in their values, I get splinters and I don't understand why. I've attached a small jpg for visual reference. FYI I copied some functions from Vlib buffer.c and needed to modify parallel_line to parallel_diff_line Vect_line_parallel to Vect_line_diff_parallel Vect_line_buffer to Vect_line_diff_buffer I also copied and left unmodified clean_parallel, point_in_buff, find_cross, vect Any suggestions as to why this is happening would be appreciated. I can post the code if needed. Thanks 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) -------------- next part -------------- A non-text attachment was scrubbed... Name: zingers.jpg Type: image/jpeg Size: 6282 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070309/800a866d/zingers-0001.jpg From hamish_nospam at yahoo.com Sat Mar 10 00:59:06 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Sat Mar 10 00:59:12 2007 Subject: [GRASS-dev] [grass-code I][328] v.in.ascii: skip= does not work In-Reply-To: <20070309204736.B66A41839D0C@pyrosoma.intevation.org> References: <20070309204736.B66A41839D0C@pyrosoma.intevation.org> Message-ID: <20070310125906.79a4fc77.hamish_nospam@yahoo.com> grass-codei@wald.intevation.org wrote: > code I item #328, was opened at 2007-03-09 21:47 .. > Summary: v.in.ascii: skip= does not work .. > Try this example: > > echo "a rubbish comment line > L 5 1 > 591336 4927369 1224 > 594317 4925341 1292 > 599356 4925162 1469 > 602396 4926653 1235 > 607524 4925431 1216 > 1 321 " | v.in.ascii -n skip=1 out=line format=standard > > In spite of skip=1, the module yields and error: > > WARNING: Error reading ascii file: [a rubbish comment line] skip= only works in points mode, it's there to skip over column headings in a .csv file. I'm not sure how it should work in combination with the -n flag for standard mode. In standard mode you need to start comment lines with a hash (#). > Another thing is that although the nature of the error is fatal, the > module proceeds anyway and exits with status 0. An ERROR should be > issued instead of WARNING, and v.in.ascii should exit immadietly with > status 1. a2b.c uses G_warning() and return 0 instead of G_fatal_error(). perhaps that is so it will load as much as it can, stop when it finds an error, and cleanly build and close the ok data before that in the vector map? the return 0 should probably be return 1 for starters. Hamish From hamish_nospam at yahoo.com Sat Mar 10 01:42:58 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Sat Mar 10 01:43:06 2007 Subject: [GRASS-dev] grass location creation In-Reply-To: References: <20070307154031.2a51146c.hamish_nospam@yahoo.com> <20070307072045.GB3148@bartok.itc.it> <17903.41425.98141.80759@cerise.gclements.plus.com> <17905.21787.662128.415201@cerise.gclements.plus.com> Message-ID: <20070310134258.39c3e37b.hamish_nospam@yahoo.com> Jachym Cepicky wrote: > G_warning(_("You are not in mapset PERMANENT, default region -> > remains untached")); "-> remains untached" to "has not been modified" or "You must be in the PERMANENT mapset to change the default region." ? Hamish From hamish_nospam at yahoo.com Sat Mar 10 02:04:09 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Sat Mar 10 02:04:15 2007 Subject: [GRASS-dev] Re: init.sh OSX browser setting In-Reply-To: <2421047E-8C98-40FA-98E5-4A7D96CDD3F5@kyngchaos.com> References: <2421047E-8C98-40FA-98E5-4A7D96CDD3F5@kyngchaos.com> Message-ID: <20070310140409.4493a2b1.hamish_nospam@yahoo.com> William Kyngesburye wrote: > Two problems with the way GRASS opens help files in OSX: > > Init.sh uses a plain 'open' as the default for the browser in Mac OS .. > The way to handle these problems is to add options to the open > command: > > open -a /path/to/app/package.app > or: > open -b app.signature > > This causes a problem in the scripts, since $GRASS_HTML_BROWSER is > quoted everywhere - it tries to execute "open -a /path/to/app/ > package.app" as the name of a program, not "open". So, I tried two > ways to handle this. .. > - alias method - doesn't work, command not found Probably aliases can be exported to child processes? Did you have any luck with using the built-in help browser? GRASS_HTML_BROWSER="/System/Library/CoreServices/Help Viewer.app/Contents/MacOS/Help Viewer" Hamish From woklist at kyngchaos.com Sat Mar 10 06:25:40 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Sat Mar 10 06:25:56 2007 Subject: [GRASS-dev] Re: init.sh OSX browser setting In-Reply-To: <20070310140409.4493a2b1.hamish_nospam@yahoo.com> References: <2421047E-8C98-40FA-98E5-4A7D96CDD3F5@kyngchaos.com> <20070310140409.4493a2b1.hamish_nospam@yahoo.com> Message-ID: On Mar 9, 2007, at 7:04 PM, Hamish wrote: >> - alias method - doesn't work, command not found >> > > Probably aliases can be exported to child processes? If you mean: alias opengrasshelp="open -b com.apple.helpviewer" export opengrasshelp that didn't work either - still command not found. > Did you have any luck with using the built-in help browser? > > GRASS_HTML_BROWSER="/System/Library/CoreServices/Help Viewer.app/ > Contents/MacOS/Help Viewer" Works great with a signature: open -b com.apple.helpviewer You don't want to do it direct as you have it, for the reason already stated (you get multiple instances of an application running). So, with the alias problem, it needs to be run with the script method. ----- William Kyngesburye http://www.kyngchaos.com/ "History is an illusion caused by the passage of time, and time is an illusion caused by the passage of history." - Hitchhiker's Guide to the Galaxy From glynn at gclements.plus.com Sat Mar 10 08:06:15 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat Mar 10 08:06:17 2007 Subject: [GRASS-dev] Re: init.sh OSX browser setting In-Reply-To: References: <2421047E-8C98-40FA-98E5-4A7D96CDD3F5@kyngchaos.com> <20070310140409.4493a2b1.hamish_nospam@yahoo.com> Message-ID: <17906.22759.141827.267444@cerise.gclements.plus.com> William Kyngesburye wrote: > >> - alias method - doesn't work, command not found > >> > > > > Probably aliases can be exported to child processes? > > If you mean: > > alias opengrasshelp="open -b com.apple.helpviewer" > export opengrasshelp > > that didn't work either - still command not found. I'm assuming that "can" was a typo; aliases are internal to the shell, and cannot be inherited by child processes. -- Glynn Clements From glynn at gclements.plus.com Sun Mar 11 18:38:47 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Mar 11 18:38:50 2007 Subject: [GRASS-dev] d.menu, d.ask Message-ID: <17908.16039.431289.828167@cerise.gclements.plus.com> Can d.menu, d.ask, and i.ask be removed? Nothing appears to use them (except each other; d.ask uses d.menu and i.ask). d.menu is one of the few users of D_popup(), which I'd like to remove. d.zoom used it, but only from yes() which isn't itself used, so I've removed that. d.rast.edit is the only other user; if d.menu is removed, D_popup can be moved into d.rast.edit until it is replaced. Apart from being an artifact of using libraster as a GUI toolkit, D_popup() is one of the few users of the R_panel_*() functions. The only other users are non-essential functionality in d.barscale and d.what.vect, i.ask (again), i.[v]points (which should be superseded by the gis.m georectifier) and i.ortho.photo (which has replaced v.digit as the primary obstacle to a decent graphics architecture). -- Glynn Clements From neteler at itc.it Sun Mar 11 19:35:44 2007 From: neteler at itc.it (Markus Neteler) Date: Sun Mar 11 19:35:45 2007 Subject: [GRASS-dev] r.li.*: write cmd history? Message-ID: <20070311183543.GA30090@bartok.itc.it> Hi, it would be great to add support for the command line history to the r.li.* modules. Essentially these 4 lines have to be added: struct History history; ... G_short_history(out, "raster", &history); G_command_history(&history); G_write_history(out, &history); I tried to modify r.li.daemon/worker.c accordingly but it doesn't help. Where should it be added instead? Markus From glynn at gclements.plus.com Sun Mar 11 20:10:05 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Mar 11 20:10:08 2007 Subject: [GRASS-dev] r.li.*: write cmd history? In-Reply-To: <20070311183543.GA30090@bartok.itc.it> References: <20070311183543.GA30090@bartok.itc.it> Message-ID: <17908.21517.778504.674118@cerise.gclements.plus.com> Markus Neteler wrote: > it would be great to add support for the command line > history to the r.li.* modules. Essentially these 4 lines > have to be added: > > struct History history; > ... > > G_short_history(out, "raster", &history); > G_command_history(&history); > G_write_history(out, &history); > > > I tried to modify > r.li.daemon/worker.c > accordingly but it doesn't help. Where should it be added > instead? AFAICT, in r.li.daemon/daemon.c; that's the only file which creates a new map (G_open_cell_new()). worker.c only opens existing maps. -- Glynn Clements From tutey at o2.pl Sun Mar 11 20:39:08 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Sun Mar 11 20:39:12 2007 Subject: [GRASS-dev] r.out.gdal: GeoTIFF colortable malformed? Message-ID: <45F45ADC.10608@o2.pl> Hi, GeoTIFFs exported with r.out.gdal appear blank in QGIS 0.8 [1]. I have reported that into QGIS bug tracker [1] supposing it was QGIS fault, but I was told that: "The tiff has a GRASS color table that is zero. See: $ gdalinfo vegcover.tif | grep COLOR" QGIS developers have hacked in a workaround for this issue. However, is there anything which could be done in r.out.gdal to fix it at it's roots? Or is a problem in GDAL maybe? Thanks for any hints. Maciek [1] https://svn.qgis.org/trac/ticket/643 From glynn at gclements.plus.com Sun Mar 11 21:48:46 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Sun Mar 11 21:48:48 2007 Subject: [GRASS-dev] r.out.gdal: GeoTIFF colortable malformed? In-Reply-To: <45F45ADC.10608@o2.pl> References: <45F45ADC.10608@o2.pl> Message-ID: <17908.27438.186590.457231@cerise.gclements.plus.com> Maciej Sieczka wrote: > Hi, > > GeoTIFFs exported with r.out.gdal appear blank in QGIS 0.8 [1]. I have > reported that into QGIS bug tracker [1] supposing it was QGIS fault, > but I was told that: > > "The tiff has a GRASS color table that is zero. See: $ gdalinfo > vegcover.tif | grep COLOR" > > QGIS developers have hacked in a workaround for this issue. However, is > there anything which could be done in r.out.gdal to fix it at it's > roots? Or is a problem in GDAL maybe? Thanks for any hints. Did you specify type=Byte or type=UInt16? The default for CELL maps is Int32, and a 2^32 entry palette isn't feasible. $ r.out.gdal vegcover format=GTiff output=vegcover.tif ERROR 6: SetColorTable() only supported for Byte or UInt16 bands in TIFF format. Done! [gdalinfo shows no colour table.] $ r.out.gdal vegcover format=GTiff output=vegcover.tif type=Byte Done! [gdalinfo shows a colour table.] Even with type=, the COLOR_TABLE_RULE* values are bogus; all entries have zero for start, end and intensities: COLOR_TABLE_RULES_COUNT=6 COLOR_TABLE_RULE_RGB_0=0.000000e+00 0.000000e+00 0 0 0 0 0 0 COLOR_TABLE_RULE_RGB_1=0.000000e+00 0.000000e+00 0 0 0 0 0 0 COLOR_TABLE_RULE_RGB_2=0.000000e+00 0.000000e+00 0 0 0 0 0 0 COLOR_TABLE_RULE_RGB_3=0.000000e+00 0.000000e+00 0 0 0 0 0 0 COLOR_TABLE_RULE_RGB_4=0.000000e+00 0.000000e+00 0 0 0 0 0 0 COLOR_TABLE_RULE_RGB_5=0.000000e+00 0.000000e+00 0 0 0 0 0 0 This is because: 1. vegcover doesn't use colour rules but a fixed palette: #0 first color 255 255 255 0 255 0 0 255 255 0 255 128 0 0 0 255 255 0 255 0 255 0 [spearfish57/PERMANENT/colr/vegcover] 2. r.out.gdal is using the maximum value as the number of rules (hence the COLOR_TABLE_RULES_COUNT=6) rather than the value returned by G_colors_count(). I've committed a fix for point #2, so vegcover.tif won't have COLOR_TABLE_RULES_COUNT or COLOR_TABLE_RULE_RGB_* tags. -- Glynn Clements From tutey at o2.pl Sun Mar 11 22:31:52 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Sun Mar 11 22:31:56 2007 Subject: [GRASS-dev] r.out.gdal: GeoTIFF colortable malformed? In-Reply-To: <17908.27438.186590.457231@cerise.gclements.plus.com> References: <45F45ADC.10608@o2.pl> <17908.27438.186590.457231@cerise.gclements.plus.com> Message-ID: <45F47548.2070104@o2.pl> Glynn Clements wrote: > Maciej Sieczka wrote: >> GeoTIFFs exported with r.out.gdal appear blank in QGIS 0.8 [1]. > Did you specify type=Byte or type=UInt16? On https://svn.qgis.org/trac/ticket/643 you can read it was: r.out.gdal input=vegcover format=GTiff type=Byte output=vegcover.tif > The default for CELL maps is > Int32, and a 2^32 entry palette isn't feasible. > > $ r.out.gdal vegcover format=GTiff output=vegcover.tif > ERROR 6: SetColorTable() only supported for Byte or UInt16 bands in TIFF format. > Done! > > [gdalinfo shows no colour table.] > > $ r.out.gdal vegcover format=GTiff output=vegcover.tif type=Byte > Done! > > [gdalinfo shows a colour table.] > > Even with type=, the COLOR_TABLE_RULE* values are bogus; all entries > have zero for start, end and intensities: > > COLOR_TABLE_RULES_COUNT=6 > COLOR_TABLE_RULE_RGB_0=0.000000e+00 0.000000e+00 0 0 0 0 0 0 > COLOR_TABLE_RULE_RGB_1=0.000000e+00 0.000000e+00 0 0 0 0 0 0 > COLOR_TABLE_RULE_RGB_2=0.000000e+00 0.000000e+00 0 0 0 0 0 0 > COLOR_TABLE_RULE_RGB_3=0.000000e+00 0.000000e+00 0 0 0 0 0 0 > COLOR_TABLE_RULE_RGB_4=0.000000e+00 0.000000e+00 0 0 0 0 0 0 > COLOR_TABLE_RULE_RGB_5=0.000000e+00 0.000000e+00 0 0 0 0 0 0 > > This is because: > > 1. vegcover doesn't use colour rules but a fixed palette: > > #0 first color > 255 255 255 > 0 > 255 0 0 > 255 255 0 > 255 128 0 > 0 0 255 > 255 0 255 > 0 255 0 > > [spearfish57/PERMANENT/colr/vegcover] > > 2. r.out.gdal is using the maximum value as the number of rules (hence > the COLOR_TABLE_RULES_COUNT=6) rather than the value returned by > G_colors_count(). > > I've committed a fix for point #2, so vegcover.tif won't have > COLOR_TABLE_RULES_COUNT or COLOR_TABLE_RULE_RGB_* tags. Thank you. I'll report back when I try the fixed version. Regards, Maciek From hamish_nospam at yahoo.com Sun Mar 11 23:08:03 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Sun Mar 11 23:08:11 2007 Subject: [GRASS-dev] Re: init.sh OSX browser setting In-Reply-To: <17906.22759.141827.267444@cerise.gclements.plus.com> References: <2421047E-8C98-40FA-98E5-4A7D96CDD3F5@kyngchaos.com> <20070310140409.4493a2b1.hamish_nospam@yahoo.com> <17906.22759.141827.267444@cerise.gclements.plus.com> Message-ID: <20070312110803.1a268524.hamish_nospam@yahoo.com> > William wrote: > > >> - alias method - doesn't work, command not found H: > > > Probably aliases can be exported to child processes? W: > > If you mean: > > > > alias opengrasshelp="open -b com.apple.helpviewer" > > export opengrasshelp > > > > that didn't work either - still command not found. G: > I'm assuming that "can" was a typo; aliases are internal to the shell, > and cannot be inherited by child processes. yes, I meant to say the opposite. so GRASS_HTML_BROWSER="opengrasshelp.sh" which contains: open -b com.apple.helpviewer "$1" and is placed somewhere in the PATH. ? Hamish From woklist at kyngchaos.com Sun Mar 11 23:51:54 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Sun Mar 11 23:52:12 2007 Subject: [GRASS-dev] Re: init.sh OSX browser setting In-Reply-To: <20070312110803.1a268524.hamish_nospam@yahoo.com> References: <2421047E-8C98-40FA-98E5-4A7D96CDD3F5@kyngchaos.com> <20070310140409.4493a2b1.hamish_nospam@yahoo.com> <17906.22759.141827.267444@cerise.gclements.plus.com> <20070312110803.1a268524.hamish_nospam@yahoo.com> Message-ID: <7792395A-15BC-4AC5-A298-54718773791C@kyngchaos.com> On Mar 11, 2007, at 5:08 PM, Hamish wrote: > G: >> I'm assuming that "can" was a typo; aliases are internal to the >> shell, >> and cannot be inherited by child processes. > > yes, I meant to say the opposite. > he he, being the shell dummy I am, I just blindly followed the wording as typed and tried it anyways... ----- William Kyngesburye http://www.kyngchaos.com/ [Trillian] What are you supposed to do WITH a maniacally depressed robot? [Marvin] You think you have problems? What are you supposed to do if you ARE a maniacally depressed robot? No, don't try and answer, I'm 50,000 times more intelligent than you and even I don't know the answer... - HitchHiker's Guide to the Galaxy From hamish_nospam at yahoo.com Mon Mar 12 00:18:01 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Mon Mar 12 00:18:10 2007 Subject: [GRASS-dev] r.li.*: write cmd history? In-Reply-To: <17908.21517.778504.674118@cerise.gclements.plus.com> References: <20070311183543.GA30090@bartok.itc.it> <17908.21517.778504.674118@cerise.gclements.plus.com> Message-ID: <20070312121801.5e3e0ec9.hamish_nospam@yahoo.com> > Markus Neteler wrote: > > it would be great to add support for the command line > > history to the r.li.* modules. Essentially these 4 lines > > have to be added: > > > > struct History history; > > ... > > > > G_short_history(out, "raster", &history); > > G_command_history(&history); > > G_write_history(out, &history); > > > > > > I tried to modify > > r.li.daemon/worker.c > > accordingly but it doesn't help. Where should it be added > > instead? Glynn: > AFAICT, in r.li.daemon/daemon.c; that's the only file which creates a > new map (G_open_cell_new()). worker.c only opens existing maps. note that you have to close the raster map before calling G_write_history() Hamish From warmerdam at pobox.com Mon Mar 12 06:53:45 2007 From: warmerdam at pobox.com (Frank Warmerdam) Date: Mon Mar 12 06:10:39 2007 Subject: [GRASS-dev] Google Summer of Code Message-ID: <45F4EAE9.60307@pobox.com> GRASS Folks, The GRASS Summer of Code ideas at: http://grass.gdf-hannover.de/wiki/GRASS_SoC_Ideas does not seem to include any mentors. For the application later today we need mentors for each project *including* google account information for them. It is best to edit this directly into the application at: http://wiki.osgeo.org/index.php/2007_Google_SoC_Application As I won't necessarily be making another pass through the project pages to find mentors. If there are no grass mentors, we will need to drop GRASS from the application as this is a requirement. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | President OSGeo, http://osgeo.org From neteler at itc.it Mon Mar 12 09:13:27 2007 From: neteler at itc.it (Markus Neteler) Date: Mon Mar 12 09:13:30 2007 Subject: [GRASS-dev] r.li.*: write cmd history? In-Reply-To: <17908.21517.778504.674118@cerise.gclements.plus.com> References: <20070311183543.GA30090@bartok.itc.it> <17908.21517.778504.674118@cerise.gclements.plus.com> Message-ID: <45F50BA7.7060809@itc.it> Glynn Clements wrote on 03/11/2007 08:10 PM: > Markus Neteler wrote: > > >> it would be great to add support for the command line >> history to the r.li.* modules. Essentially these 4 lines >> have to be added: >> >> struct History history; >> ... >> >> G_short_history(out, "raster", &history); >> G_command_history(&history); >> G_write_history(out, &history); >> >> >> I tried to modify >> r.li.daemon/worker.c >> accordingly but it doesn't help. Where should it be added >> instead? >> > > AFAICT, in r.li.daemon/daemon.c; that's the only file which creates a > new map (G_open_cell_new()). worker.c only opens existing maps. > > Thanks. Enhanced, submitted and works for all r.li.* modules. Markus From paul-grass at stjohnspoint.co.uk Mon Mar 12 12:06:44 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Mon Mar 12 12:07:01 2007 Subject: [GRASS-dev] Google Summer of Code In-Reply-To: <45F4EAE9.60307@pobox.com> References: <45F4EAE9.60307@pobox.com> Message-ID: Frank and everyone, I added a new project (line of sight analysis with a new algorithm - something I would do myself if I had the time) to the GRASS SoC page and added my name as a mentor directly to the OSGeo application. Some of the other potential GRASS projects seem a bit suspect - e.g. better implement PostGIS support? But IIRC we used to have this but it was removed because it was realised it was not a good idea? Also integrating OGR in vector library? This doesn't seem to make sense as it is already substantially done. They would need more detail there or else should be removed, IMHO. Paul On Mon, 12 Mar 2007, Frank Warmerdam wrote: > > GRASS Folks, > > The GRASS Summer of Code ideas at: > http://grass.gdf-hannover.de/wiki/GRASS_SoC_Ideas > > does not seem to include any mentors. For the application later today we > need mentors for each project *including* google account information for > them. > It is best to edit this directly into the application at: > > http://wiki.osgeo.org/index.php/2007_Google_SoC_Application > > As I won't necessarily be making another pass through the project pages to > find mentors. > > If there are no grass mentors, we will need to drop GRASS from the > application > as this is a requirement. > > Best regards, > -- > ---------------------------------------+-------------------------------------- > I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com > light and sound - activate the windows | http://pobox.com/~warmerdam > and watch the world go round - Rush | President OSGeo, http://osgeo.org > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > From wolf+grass at bergenheim.net Mon Mar 12 13:04:29 2007 From: wolf+grass at bergenheim.net (Wolf Bergenheim) Date: Mon Mar 12 13:05:12 2007 Subject: [GRASS-dev] Google Summer of Code In-Reply-To: References: <45F4EAE9.60307@pobox.com> Message-ID: <45F541CD.3040305@bergenheim.net> Inspired by Paul I added three more projects (generalization and shortest path (1 raster and 1 vector). --Wolf On 12.03.2007 13:06, Paul Kelly wrote: > Frank and everyone, > I added a new project (line of sight analysis with a new algorithm - > something I would do myself if I had the time) to the GRASS SoC page and > added my name as a mentor directly to the OSGeo application. > -- <:3 )---- Wolf Bergenheim ----( 8:> From warmerdam at pobox.com Mon Mar 12 15:47:32 2007 From: warmerdam at pobox.com (Frank Warmerdam) Date: Mon Mar 12 15:47:10 2007 Subject: [GRASS-dev] Google Summer of Code In-Reply-To: References: <45F4EAE9.60307@pobox.com> Message-ID: <45F56804.8050003@pobox.com> Paul Kelly wrote: > Frank and everyone, > I added a new project (line of sight analysis with a new algorithm - > something I would do myself if I had the time) to the GRASS SoC page and > added my name as a mentor directly to the OSGeo application. Paul, Thanks > Some of the other potential GRASS projects seem a bit suspect - e.g. > better implement PostGIS support? But IIRC we used to have this but it > was removed because it was realised it was not a good idea? Also > integrating OGR in vector library? This doesn't seem to make sense as it > is already substantially done. They would need more detail there or else > should be removed, IMHO. For the actual application I just submit a pointer to the ideas list, and so there is still a couple days to clean up the ideas list. I would strongly encourage the GRASS PSC to quickly pare down the ideas list to a short list that is considered sensible, of suitable complexity for an undergraduate student to complete in a summer, and that can be documented adequately that a student could prepare a proposal based on it. I am concerned that Google may not select OSGeo as a participating organization if the ideas list offered by the different projects show no coherency. I must appologise for the limited direction and support I have provided to projects on this SoC activity. It is quite new to me as well. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | President OSGeo, http://osgeo.org From glynn at gclements.plus.com Mon Mar 12 17:34:12 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Mar 12 17:34:17 2007 Subject: [GRASS-dev] d.rast.edit replacement candidate Message-ID: <17909.33028.405777.835087@cerise.gclements.plus.com> I'm looking into replacing d.rast.edit with a Tcl/Tk program. I've committed a "first draft" in scripts/d.rast.edit. Currently, it doesn't do everything which the existing d.rast.edit does. Primarily, it doesn't offer the option to run d.zoom in the middle of an editing session. OTOH, you aren't restricted by having to select a small region so that the cells are large enough to select; the cells are never smaller than 12x12 pixels. Also, I haven't added the option to display slope arrows; I'm not entirely sure whether that's actually useful, but I can add it easily enough if it is. Probably the main limitation at present is that it won't show the correct colours for any modified cells with values which aren't in the original map (there doesn't appear to be any way to determine the colour for a given category value from outside a C program). Any comments (or bug reports) would be appreciated. -- Glynn Clements From peter_7003 at yahoo.com Mon Mar 12 19:08:14 2007 From: peter_7003 at yahoo.com (Peter Fischer) Date: Mon Mar 12 19:08:17 2007 Subject: [GRASS-dev] Modularity of GRASS GIS. Message-ID: <712214.88674.qm@web62007.mail.re1.yahoo.com> Hello, I have a question: With GRASS GIS, is it possible to have one database with the mapdata and multiple viewers, reading from that database independently from each other via a network connection? Furthermore, would it then be possible to display realtime 3D data (i.e. 4D ;) on the multiple views? How fast the realtime diplay is? You would greatly help me with an answer, best regards and till soon, Peter. --------------------------------- It's here! Your new message! Get new email alerts with the free Yahoo! Toolbar. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070312/d15e7eb7/attachment.html From paul-grass at stjohnspoint.co.uk Mon Mar 12 20:33:44 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Mon Mar 12 20:33:48 2007 Subject: [GRASS-dev] d.rast.edit replacement candidate In-Reply-To: <17909.33028.405777.835087@cerise.gclements.plus.com> References: <17909.33028.405777.835087@cerise.gclements.plus.com> Message-ID: I tried running it on Windows - looks neat enough. A few comments: Couldn't get it running directly: as far as I can see the exec "$GRASS_WISH" "$0" "$@" syntax is having problems with confused Msys/Windows paths or something. Hard to get to the bottom of. But running g.parser directly on the script file works OK. I came across the problem with r.out.ppm always returning an error code but I see you've already fixed that in CVS. Does that mean nobody had ever tried running it from Tcl before? The 2>@stderr syntax doesn't work on Windows and when I changed it to 2>NUL: everything ran OK. Noticed a bug: can only save the output map once - the second and subsequent times I get a broken pipe error - caused by error message from r.in.ascii about over-writing the file - possibly call it with --overwrite option? I guess if there was a pre-existing map it will have been checked at the time the script was started, so d.rast.edit will only be over-writing what it itself created. Also it would be good if there was some way it could determine if the region was too large and abandon startup instead of using up lots of memory and taking a long time to do nothing. Maybe you could calculate something from the width of the black lines between the cells and the size of the canvas in pixels, and determine when there would be so many cells that the lines between them would merge together, and refuse to run then? I suppose you would need to provide an option then for people with huge monitors and high-spec PCs - maybe it could read the initial screen size from the environment variables for the monitor size or something. Also: title bar currently says d.rast, not d.rast.edit. Paul On Mon, 12 Mar 2007, Glynn Clements wrote: > > I'm looking into replacing d.rast.edit with a Tcl/Tk program. > > I've committed a "first draft" in scripts/d.rast.edit. Currently, it > doesn't do everything which the existing d.rast.edit does. > > Primarily, it doesn't offer the option to run d.zoom in the middle of > an editing session. OTOH, you aren't restricted by having to select a > small region so that the cells are large enough to select; the cells > are never smaller than 12x12 pixels. > > Also, I haven't added the option to display slope arrows; I'm not > entirely sure whether that's actually useful, but I can add it easily > enough if it is. > > Probably the main limitation at present is that it won't show the > correct colours for any modified cells with values which aren't in the > original map (there doesn't appear to be any way to determine the > colour for a given category value from outside a C program). > > Any comments (or bug reports) would be appreciated. > > -- > Glynn Clements > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev > From glynn at gclements.plus.com Mon Mar 12 22:03:07 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Mon Mar 12 22:03:09 2007 Subject: [GRASS-dev] d.rast.edit replacement candidate In-Reply-To: References: <17909.33028.405777.835087@cerise.gclements.plus.com> Message-ID: <17909.49163.232740.934130@cerise.gclements.plus.com> Paul Kelly wrote: > I tried running it on Windows - looks neat enough. A few comments: > Couldn't get it running directly: as far as I can see the > exec "$GRASS_WISH" "$0" "$@" syntax is having problems with confused > Msys/Windows paths or something. Hard to get to the bottom of. Hmm. I could add a front-end shell script which does the g.parser stuff then explicitly invokes $GRASS_WISH on the Tcl script. > But running g.parser directly on the script file works OK. I came across > the problem with r.out.ppm always returning an error code but I see you've > already fixed that in CVS. Does that mean nobody had ever tried running > it from Tcl before? I presume so. > The 2>@stderr syntax doesn't work on Windows and when I changed it to > 2>NUL: everything ran OK. > > Noticed a bug: can only save the output map once - the second and > subsequent times I get a broken pipe error - caused by error message from > r.in.ascii about over-writing the file - possibly call it with --overwrite > option? I guess if there was a pre-existing map it will have been checked > at the time the script was started, so d.rast.edit will only be > over-writing what it itself created. I originally figured that if you run the d.rast.edit script with --o, it would set GRASS_OVERWRITE, and if you didn't use --o, you would want overwrite to fail. I didn't allow for saving it twice. I'll change it to explicitly use --o when calling r.in.ascii. > Also it would be good if there was some way it could determine if the > region was too large and abandon startup instead of using up lots of > memory and taking a long time to do nothing. Maybe you could calculate > something from the width of the black lines between the cells and the size > of the canvas in pixels, and determine when there would be so many cells > that the lines between them would merge together, and refuse to run then? > I suppose you would need to provide an option then for people with huge > monitors and high-spec PCs - maybe it could read the initial screen size > from the environment variables for the monitor size or something. The cells will never be any smaller than 12x12; it will enlarge the view if necessary (hence the scrollbars). However, it might take a long time to start up if you have a lot of cells. FWIW, spearfish at 100m resolution (190x143 = 27170 cells) takes 7 seconds to start up on a P3/800. I would expect it to take over a minute at the default 30m resolution (634x477 = 302418 cells). Obviously, using it on high-resolution data isn't going to be practical. Choosing a "sane" limit is hard, given the range of hardware. Ultimately, the user can always kill it with Ctrl-C if it takes too long. It might be worth adding a progress bar to give the user some advance warning. > Also: title bar currently says d.rast, not d.rast.edit. Presumably, the Windows Tcl/Tk treats ".edit" as the executable's extension and omits it as it would ".exe". I'll add a "wm title ...". I'll also replace the hard-coded canvas width/height and cell size with options. -- Glynn Clements From rez at touchofmadness.com Tue Mar 13 04:09:30 2007 From: rez at touchofmadness.com (Brad Douglas) Date: Tue Mar 13 04:09:35 2007 Subject: [GRASS-dev] d.menu, d.ask In-Reply-To: <17908.16039.431289.828167@cerise.gclements.plus.com> References: <17908.16039.431289.828167@cerise.gclements.plus.com> Message-ID: <1173755370.15656.143.camel@devel> On Sun, 2007-03-11 at 17:38 +0000, Glynn Clements wrote: > Can d.menu, d.ask, and i.ask be removed? Nothing appears to use them > (except each other; d.ask uses d.menu and i.ask). I moved the few imagery modules that used it away from i.ask awhile ago. I believe it only exists for legacy/add-on purposes. > Apart from being an artifact of using libraster as a GUI toolkit, > D_popup() is one of the few users of the R_panel_*() functions. The > only other users are non-essential functionality in d.barscale and > d.what.vect, i.ask (again), i.[v]points (which should be superseded by > the gis.m georectifier) and i.ortho.photo (which has replaced v.digit > as the primary obstacle to a decent graphics architecture). IIRC, i.[v]points are hanging around because they haven't been incorporated into i.ortho.photo. Maybe keep them in the tree, modify the top level TODO, but remove them from the Makefile until they get integrated? I know it already exists in the TODO, but it would be nice to note why they no longer work. I'm well on my way to doing this, but my implementation makes use of BLAS/LAPACK. Maybe this won't be such an issue anymore, now that I've managed to get BLAS/LAPACK working correctly with gcc4+. However, other issues remain. I can tackle some of these problems if there is someone else willing to help with the GUI coding (I don't know my way around Tcl/Python as well as I should). -- Brad Douglas KB8UYR/6 Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From hamish_nospam at yahoo.com Tue Mar 13 06:59:12 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Tue Mar 13 06:59:21 2007 Subject: [GRASS-dev] d.menu, d.ask In-Reply-To: <17908.16039.431289.828167@cerise.gclements.plus.com> References: <17908.16039.431289.828167@cerise.gclements.plus.com> Message-ID: <20070313185912.2972b68b.hamish_nospam@yahoo.com> Glynn Clements wrote: > Can d.menu, d.ask, and i.ask be removed? Nothing appears to use them > (except each other; d.ask uses d.menu and i.ask). While I agree that they* should be removed in time, they shouldn't be removed during the 6.x line. Nothing in GRASS may use them (except each other), but that is not to say that there isn't some user app out there using them. While I don't need d.menu in my work, I've always found it to be very interesting to play with. [*] + i.[v]points + xterm based libedit stuff Two ways out without grinding useful development to a halt- a) Is there a way to isolate the needed code in lib_ancient or somewhere and conditionalize that so it+modules doesn't get built if ./config --without-x? b) We start on GRASS 7.x. IMO we should decide on if we want to use a wxPython GUI or Tcl GUI for GRASS 6.4 before we decide to start that, and do the raster format dir rearangement as the first task. I presume the low-level raster format change can happen later, just use different element names for the new format ($MAPSET/raster/$MAPNAME/element). > Apart from being an artifact of using libraster as a GUI toolkit, > D_popup() is one of the few users of the R_panel_*() functions. The > only other users are non-essential functionality in d.barscale I'm a big fan of the 'd.barscale -m' try-before-you-buy functionality; In fact I've always meant to port that to d.text.* and d.legend, but so far haven't found the time. It would be slower, but some form of 100% panel swap or overlay might work as a way to keep the functionality while removing R_panel_() ? > and d.what.vect, i.ask (again), i.[v]points (which should be > superseded by the gis.m georectifier) and i.ortho.photo (which has > replaced v.digit as the primary obstacle to a decent graphics > architecture). i.[v]points remains my prefered georectifying tool, and there is still functionality that is not present in the Tcl version. Again, yes tag it as end-of-line; but don't remove it during 6.x. > TCL d.rast.edit I look forward to trying it out. Overlay numbers are needed; arrows aren't critical; updated colors would be nice. thanks, Hamish From glynn at gclements.plus.com Tue Mar 13 13:52:34 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Mar 13 13:52:45 2007 Subject: [GRASS-dev] d.menu, d.ask In-Reply-To: <20070313185912.2972b68b.hamish_nospam@yahoo.com> References: <17908.16039.431289.828167@cerise.gclements.plus.com> <20070313185912.2972b68b.hamish_nospam@yahoo.com> Message-ID: <17910.40594.425581.580790@cerise.gclements.plus.com> Hamish wrote: > > Can d.menu, d.ask, and i.ask be removed? Nothing appears to use them > > (except each other; d.ask uses d.menu and i.ask). > > While I agree that they* should be removed in time, they shouldn't be > removed during the 6.x line. Nothing in GRASS may use them (except each > other), but that is not to say that there isn't some user app out there > using them. While I don't need d.menu in my work, I've always found it > to be very interesting to play with. > > [*] + i.[v]points + xterm based libedit stuff > > Two ways out without grinding useful development to a halt- > > a) Is there a way to isolate the needed code in lib_ancient or somewhere > and conditionalize that so it+modules doesn't get built if > ./config --without-x? Either the panel stuff can be removed from the drivers, or it can't. If it's removed, anything which tries to use it will fail. > > Apart from being an artifact of using libraster as a GUI toolkit, > > D_popup() is one of the few users of the R_panel_*() functions. The > > only other users are non-essential functionality in d.barscale > > I'm a big fan of the 'd.barscale -m' try-before-you-buy functionality; > In fact I've always meant to port that to d.text.* and d.legend, but so > far haven't found the time. It would be slower, but some form of 100% > panel swap or overlay might work as a way to keep the functionality > while removing R_panel_() ? Interaction belongs in the GUI, not in modules. The panel stuff has fewer users than R_get_location_*, so getting to the point where it can be removed is less work. > > and d.what.vect, i.ask (again), i.[v]points (which should be > > superseded by the gis.m georectifier) and i.ortho.photo (which has > > replaced v.digit as the primary obstacle to a decent graphics > > architecture). > > i.[v]points remains my prefered georectifying tool, and there is still > functionality that is not present in the Tcl version. In which case, the functionality needs to be added to the Tcl version. > Again, yes tag it > as end-of-line; but don't remove it during 6.x. Is there an expected timeline for 7.x? If so, does that signify a point at which fundamental changes to the graphics architecture can commence? If not, i.e. if i.ortho.photo *has* to continue to work until such time that someone sees fit to write an alternative (if that ever happens), then the graphics architecture will forever be limited to a Tek4105 emulation, and I may as well give up now. IMHO, I don't think that we can wait forever for decent graphics. The biggest danger is that the "you can't remove that because someone still uses it" problem will end up solving itself when no-one actually uses GRASS any more. I'd prefer people to set achievable goals than to insist on having everything and ending up with nothing. > > TCL d.rast.edit > > I look forward to trying it out. Overlay numbers are needed; The category number for the cell under the pointer is displayed in the status bar, but if the category numbers *need* to be overlayed (bear in mind that these may be several digits long, which means that you need very large cells), I can add that. > arrows aren't critical; It isn't whether they're critical. If they're even *useful*, I can add them easily enough (although it would be preferable if the aspect map was given as a command-line option, otherwise I need to add a map browser). > updated colors would be nice. Right now, there doesn't appear to be any simple way to determine the colour for a specific category from outside of C. The Tcl/Tk d.rast.edit gets the categories for the map being edited from r.out.ascii, and the colours from r.out.ppm. Thus, it knows the colour for each category (or FP value) which actually occurs in the original map. If you decide to set a cell to a category which wasn't already in use, it has no idea what colour it should be, and (AFAICT) no simpler way to find out than: $ r.mapcalc "$tempmap = $newval" $ r.colors $tempmap rast=$inmap $ r.out.ppm $tempmap out=$tempfile $ g.remove rast=$tempmap % image create photo tempimg -file $tempfile % set rgb [tempimg get 0 0] % image delete tempimg % file delete $tempfile Which is incredibly inefficient (and possibly error-prone). Right now, if it doesn't know the correct colour, it uses white. The edited map has its colour table copied from the original map, so they will show up correctly in the final map, just not in the editor. -- Glynn Clements From landa.martin at gmail.com Tue Mar 13 14:05:29 2007 From: landa.martin at gmail.com (Martin Landa) Date: Tue Mar 13 14:05:33 2007 Subject: [GRASS-dev] d.menu, d.ask In-Reply-To: <17910.40594.425581.580790@cerise.gclements.plus.com> References: <17908.16039.431289.828167@cerise.gclements.plus.com> <20070313185912.2972b68b.hamish_nospam@yahoo.com> <17910.40594.425581.580790@cerise.gclements.plus.com> Message-ID: Hi, 2007/3/13, Glynn Clements : [snip] > Is there an expected timeline for 7.x? If so, does that signify a > point at which fundamental changes to the graphics architecture can > commence? no exact timeline exists AFAIK. There is plan to migrate to SVN in connection to GRASS7. I hope it will be done soon. Martin -- Martin Landa * http://gama.fsv.cvut.cz/~landa * From glynn at gclements.plus.com Tue Mar 13 14:16:10 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Mar 13 14:16:17 2007 Subject: [GRASS-dev] d.rast.edit replacement candidate In-Reply-To: <17909.49163.232740.934130@cerise.gclements.plus.com> References: <17909.33028.405777.835087@cerise.gclements.plus.com> <17909.49163.232740.934130@cerise.gclements.plus.com> Message-ID: <17910.42010.261771.416560@cerise.gclements.plus.com> Glynn Clements wrote: > > Also it would be good if there was some way it could determine if the > > region was too large and abandon startup instead of using up lots of > > memory and taking a long time to do nothing. Maybe you could calculate > > something from the width of the black lines between the cells and the size > > of the canvas in pixels, and determine when there would be so many cells > > that the lines between them would merge together, and refuse to run then? > > I suppose you would need to provide an option then for people with huge > > monitors and high-spec PCs - maybe it could read the initial screen size > > from the environment variables for the monitor size or something. > > The cells will never be any smaller than 12x12; it will enlarge the > view if necessary (hence the scrollbars). However, it might take a > long time to start up if you have a lot of cells. > > FWIW, spearfish at 100m resolution (190x143 = 27170 cells) takes 7 > seconds to start up on a P3/800. I would expect it to take over a > minute at the default 30m resolution (634x477 = 302418 cells). > Obviously, using it on high-resolution data isn't going to be > practical. > > Choosing a "sane" limit is hard, given the range of hardware. > Ultimately, the user can always kill it with Ctrl-C if it takes too > long. It might be worth adding a progress bar to give the user some > advance warning. If editing large maps is desirable, another option is to use a scaled image rather than drawing each cell as a polygon. However, you still need the array of category values, and Tcl's arrays aren't exactly efficient; they're associative arrays, with both the key (i.e. the coordinate pair) and value stored as strings, so memory consumption will always be much worse than the 4/8 bytes per cell you would have in C. Ultimately, the question is whether the ability to operate upon large regions is useful. If it is, I'm going to need to look at other approaches, e.g.: 1. Operating upon smaller subregions, with the user having to explicitly pan around the region. 2. Avoid reading the cell values altogether. That would eliminate the ability to continuously show the value under the pointer; instead, you would have to explicitly query cell values (d.rast.edit would use r.what for this). This would eliminate the need for explicit panning, but also eliminate the ability to overlay arrows or cell values; a Tk canvas can handle a 1000x1000 image easily enough, but it can't easily handle a million text items (overlayed numerical values) or line items (overlayed arrows) 3. Export the cell values to a raw binary file using r.out.bin, and perform random lookups on this file from Tcl. This might be fast enough to all continous display of cell values, but still doesn't allow for any overlays. -- Glynn Clements From glynn at gclements.plus.com Tue Mar 13 14:32:07 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Mar 13 14:32:09 2007 Subject: [GRASS-dev] d.rast.edit replacement candidate In-Reply-To: <17910.42010.261771.416560@cerise.gclements.plus.com> References: <17909.33028.405777.835087@cerise.gclements.plus.com> <17909.49163.232740.934130@cerise.gclements.plus.com> <17910.42010.261771.416560@cerise.gclements.plus.com> Message-ID: <17910.42967.424367.530971@cerise.gclements.plus.com> Glynn Clements wrote: > If editing large maps is desirable, another option is to use a scaled > image rather than drawing each cell as a polygon. Actually, that doesn't help much; I forgot that the Tk canvas doesn't allow images to be scaled, and scaling the image itself increases memory consumption proportionally, making it potentially worse than using a polygon per cell. -- Glynn Clements From cheg01 at comcast.net Tue Mar 13 15:40:58 2007 From: cheg01 at comcast.net (cheg01@comcast.net) Date: Tue Mar 13 15:41:02 2007 Subject: [GRASS-dev] McAfee Security Center 7.2 breaks mon.select Message-ID: <031320071440.22706.45F6B7FA0000AB6E000058B22206424413CECF090A080C@comcast.net> I am running grass 6.2.1 on Cygwin/Windows XP. Everything was fine while I was running Norton Antivirus but ithen I installed the newest McAfee security suite and 'd.mon' stopped working. 'mon.start' works to create the window but XDRIVER.exe hangs on 'mon.select' and will not accept connections. I get the following error message: Socket is already in use or not accepting connections Use d.mon to select a monitor Problem selecting x0 The mon window cannot be closed until the parent window is closed. Same thing happens on Grass 5.4. Any suggestions? Can anyone give me a brief description of how the monitor socket creation and selection works so I can take this up with McAfee? I thought it might be using some specific ports that are blocked but I don't know where to start. From neteler at itc.it Tue Mar 13 15:43:29 2007 From: neteler at itc.it (Markus Neteler) Date: Tue Mar 13 15:43:31 2007 Subject: GRASS SVN migration - was Re: [GRASS-dev] d.menu, d.ask In-Reply-To: References: <17908.16039.431289.828167@cerise.gclements.plus.com> <20070313185912.2972b68b.hamish_nospam@yahoo.com> <17910.40594.425581.580790@cerise.gclements.plus.com> Message-ID: <45F6B891.6090900@itc.it> Martin Landa wrote on 03/13/2007 02:05 PM: > Hi, > > 2007/3/13, Glynn Clements : > [snip] >> Is there an expected timeline for 7.x? If so, does that signify a >> point at which fundamental changes to the graphics architecture can >> commence? > > no exact timeline exists AFAIK. There is plan to migrate to SVN in > connection to GRASS7. I hope it will be done soon. > > Martin Bernhard, we would like to do the SVN migration rather sooner than later. We offer to play with a full snapshot of the CVS repository here locally (kindly receiving a copy from you) and try to migrate it here at IRST in a local server to see how it works for branches etc. Then we'll report back and give suggestions for the real migration (which could be on "wald" or, if that's not possible, some OSGeo infrastructure). Since the bugtracker is already running on "wald" and svn also there, it might be natural to keep the GRASS source code there, too, for the time being. Please let us know if you could package the CVS repository server-side into a tarball. Thanks, Markus From bernhard at intevation.de Tue Mar 13 15:59:32 2007 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue Mar 13 15:59:39 2007 Subject: GRASS SVN migration - was Re: [GRASS-dev] d.menu, d.ask In-Reply-To: <45F6B891.6090900@itc.it> References: <17908.16039.431289.828167@cerise.gclements.plus.com> <45F6B891.6090900@itc.it> Message-ID: <200703131559.33835.bernhard@intevation.de> On Tuesday 13 March 2007 15:43, Markus Neteler wrote: > Martin Landa wrote on 03/13/2007 02:05 PM: > > no exact timeline exists AFAIK. There is plan to migrate to SVN in > > connection to GRASS7. I hope it will be done soon. > we would like to do the SVN migration rather sooner than later. Fine. I think wald is ready for this in principle. > We offer to play with a full snapshot of the CVS repository here locally > (kindly receiving a copy from you) and try to migrate it here at IRST > in a local server to see how it works for branches etc. > > Then we'll report back and give suggestions for the real migration This would be helpful of course, we did some scripting here for the last few migrations we did, so we do have some experience. (Maybe Bernhard H. or Thomas have some pointers.) > Please let us know if you could package the CVS repository server-side into > a tarball. Sure we could pack it up. All modules would be 585 MByte. Can you send my your OpenPGP key, we could place it on an access controlled area so you can download and send you the link. Best, Bernhard -- Managing Director - Owner: www.intevation.net (Free Software Company) Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com. Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070313/e86b27be/attachment.bin From glynn at gclements.plus.com Tue Mar 13 17:04:11 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Mar 13 17:04:17 2007 Subject: [GRASS-dev] McAfee Security Center 7.2 breaks mon.select In-Reply-To: <031320071440.22706.45F6B7FA0000AB6E000058B22206424413CECF090A080C@comcast.net> References: <031320071440.22706.45F6B7FA0000AB6E000058B22206424413CECF090A080C@comcast.net> Message-ID: <17910.52091.139479.296898@cerise.gclements.plus.com> cheg01@comcast.net wrote: > I am running grass 6.2.1 on Cygwin/Windows XP. Everything was fine > while I was running Norton Antivirus but ithen I installed the newest > McAfee security suite and 'd.mon' stopped working. 'mon.start' works > to create the window but XDRIVER.exe hangs on 'mon.select' and will > not accept connections. I get the following error message: > > Socket is already in use or not accepting connections > Use d.mon to select a monitor > Problem selecting x0 > > The mon window cannot be closed until the parent window is closed. > Same thing happens on Grass 5.4. Any suggestions? Can anyone give me a > brief description of how the monitor socket creation and selection > works so I can take this up with McAfee? I thought it might be using > some specific ports that are blocked but I don't know where to start. Display modules connect to a monitor via a Unix-domain (AF_UNIX) socket in the session directory (/tmp/grass6--pid in 6.x). Windows doesn't have Unix-domain sockets, so Cygwin emulates them using TCP sockets, with arbitrarily-chosen port numbers. Firewall software can interfere with this; e.g. Zone Alarm will display a confirmation dialog for XDRIVER and for each program which tries to connect to it. When you start a monitor with "d.mon start=", the first client will be mon.select (unless you use -s). If you're having problems with mon.select, it's likely that other d.* programs will have the same problems. Also, some security software may not like Cygwin, as it does "odd" stuff to emulate Unix fork/exec, some of which might be considered suspicious. However, searching on the Cygwin mailing list tends to come up with lots of references to McAfee, usually in close proximity to phrases such as "buggy device driver". At least, there are enough hits with generic "ensure that you don't have McAfee installed" advice that it's likely to be a lot of effort to hunt through them all in order to find out what the exact problems are. -- Glynn Clements From michael.barton at asu.edu Tue Mar 13 17:32:26 2007 From: michael.barton at asu.edu (Michael Barton) Date: Tue Mar 13 17:32:34 2007 Subject: [GRASS-dev] d.menu, d.ask In-Reply-To: <20070313185912.2972b68b.hamish_nospam@yahoo.com> Message-ID: Just a couple of comments. First, THANKS very much Glynn for working on this. On 3/12/07 10:59 PM, "Hamish" wrote: > b) We start on GRASS 7.x. IMO we should decide on if we want to use a > wxPython GUI or Tcl GUI for GRASS 6.4 before we decide to start that, > and do the raster format dir rearangement as the first task. I presume > the low-level raster format change can happen later, just use different > element names for the new format ($MAPSET/raster/$MAPNAME/element). > This is a good point. The wxPython GUI is coming along very well, thanks to the efforts of J?chym and Martin. I've finally been able to rejoin the development. With 3 (or more???) of us working on it, it should move along at a nice pace. > >> Apart from being an artifact of using libraster as a GUI toolkit, >> D_popup() is one of the few users of the R_panel_*() functions. The >> only other users are non-essential functionality in d.barscale > > I'm a big fan of the 'd.barscale -m' try-before-you-buy functionality; > In fact I've always meant to port that to d.text.* and d.legend, but so > far haven't found the time. It would be slower, but some form of 100% > panel swap or overlay might work as a way to keep the functionality > while removing R_panel_() ? I've already implemented the TclTk equivalent of -m for d.barscale, d.text, and d.legend in the current GUI. (At least it works for me and my students). 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 tutey at o2.pl Tue Mar 13 21:06:18 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Tue Mar 13 21:06:21 2007 Subject: [GRASS-dev] v.breach and v.line.center GRASS addons Message-ID: <45F7043A.7020600@o2.pl> Hi I have submitted 2 new scripts for GRASS 6.x to GRASS WIKI http://grass.gdf-hannover.de/wiki/GRASS_AddOns: v.line.center creates a points vector map with each point located in the middle of the length of one input vector line. v.breach creates vector maps of lines and points of continously lowering elevation down the input watercourses, based on the input raster DEM. v.line.center is a simple self-explanatory tool. v.breach is more complex. It is similar to r.carve -n, with the following differences: 1. It takes the direction of input vector lines into account; which means it is less prone to artifacts in the input DEM but more demanding to input watercourses. As a result you can breach DEM even against the slope, if that's needed ;). 2. It does not breach the DEM itself, but outputs vector points which have the breached elevation attribute stored in the table. These points can be used as additional data for interpolating more hydrologicaly sound DEM from scratch, or rasterized and burned into the input DEM manually (v.to.rast, r.mapcalc). 3. It also outputs vector lines, which are the input vector watercourses segmented one segment per each DEM cell through which a given input watercourse flows. Those segments have the breached elevation attribute same as the output vector points. I needed such output for my work. Maybe it will be of some use for others. 4. It is way slower than r.carve. Shell (I have got rid of bashisms I hope) + Awk + standard UNIX tools. See the v.breach manual for more details. Maciek From tutey at o2.pl Tue Mar 13 21:56:02 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Tue Mar 13 21:56:08 2007 Subject: [GRASS-dev] make install fails with 6.3 CVS Message-ID: <45F70FE2.4030403@o2.pl> Hi, Current 6.3 CVS builds fine, but on make install a bunch of: tar: path/to/file: file changed as we read it is issued (full log of make install is attached). Also some strange 'NONE' subdir is created in the source dir. BTW talking of make install: grass63.bat installed on Linux http://wald.intevation.org/tracker/index.php?func=detail&aid=323&group_id=21&atid=204 6.2.2 CVS installs fine. Maciek -------------- next part -------------- A non-text attachment was scrubbed... Name: log.makeinstall.bz2 Type: application/x-bzip Size: 2268 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070313/b674fe87/log.makeinstall.bin From mlennert at club.worldonline.be Tue Mar 13 22:13:38 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Tue Mar 13 22:10:49 2007 Subject: [GRASS-dev] make install fails with 6.3 CVS In-Reply-To: <45F70FE2.4030403@o2.pl> References: <45F70FE2.4030403@o2.pl> Message-ID: <1600.85.10.71.67.1173820418.squirrel@geog-pc40.ulb.ac.be> On Tue, March 13, 2007 21:56, Maciej Sieczka wrote: > BTW talking of make install: grass63.bat installed on Linux > http://wald.intevation.org/tracker/index.php?func=detail&aid=323&group_id=21&atid=204 > To solve that, we would need to conditionalise lines 240 and 241 of the Makefile in the root directory, but I don't know how to do that. Moritz From glynn at gclements.plus.com Tue Mar 13 22:12:04 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Tue Mar 13 22:12:06 2007 Subject: [GRASS-dev] d.menu, d.ask In-Reply-To: References: <20070313185912.2972b68b.hamish_nospam@yahoo.com> Message-ID: <17911.5028.813207.357576@cerise.gclements.plus.com> Michael Barton wrote: > The wxPython GUI is coming along very well, thanks to > the efforts of J?chym and Martin. I've finally been able to rejoin the > development. With 3 (or more???) of us working on it, it should move along > at a nice pace. So, how does one try this out? -- Glynn Clements From mlennert at club.worldonline.be Tue Mar 13 22:44:49 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Tue Mar 13 22:41:59 2007 Subject: [GRASS-dev] portable.h elimination In-Reply-To: <17900.5591.692946.780300@cerise.gclements.plus.com> References: <17900.5591.692946.780300@cerise.gclements.plus.com> Message-ID: <1766.85.10.71.67.1173822289.squirrel@geog-pc40.ulb.ac.be> On Mon, March 5, 2007 14:06, Glynn Clements wrote: > > I've modified lib/vector/diglib to determine the byte ordering at run > time, rather than generating the portable.h header file. > > The supplied test case passes. It might be useful to test it using dig > files generated on an architecture with the opposite byte order (I > have no way to test this). It might also be worth testing it on MinGW. How should I test ? Moritz From mlennert at club.worldonline.be Tue Mar 13 22:47:55 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Tue Mar 13 22:45:05 2007 Subject: [GRASS-dev] DBMI troubles on Win32 In-Reply-To: <45F11872.3060600@ufg.uni-kiel.de> References: <45F11872.3060600@ufg.uni-kiel.de> Message-ID: <1784.85.10.71.67.1173822475.squirrel@geog-pc40.ulb.ac.be> On Fri, March 9, 2007 09:18, Benjamin Ducke wrote: > Hi all, > > I am currently doing a lot of testing for GRASS 6.3. on the mingw/msys > platform (the same that comes with QGIS). > > There seems to be a problem related to the DBMI protocol. Modules that > access attribute data via the GRASS DBMI lib have a habit of hanging > once in a while. I have seen this happen on half a dozen different > machines with Win2000 and XP. > > An example is v.info -c. The module simply hangs and has to be killed > and restarted until it does its work. > The strange thing is that I cannot find any pattern here: sometimes > dozens of runs show no problems at all and sometimes I have to restart a > module several times until it starts running. > Also, this seems to concern only the first DB access. I have a module > here that does hundreds of DB accesses during each run. If the first one > goes OK, all the others will be fine too ... > > I am using the latest 6.3 CVS sources for my tests. > > I am at a loss here. Can anyone confirm this problem? I can't with the native winGRASS (not QGIS), at least not using v.info -c as a test case within spearfish. But there tables are very small. Which type of files did you try this on ? Moritz From paul-grass at stjohnspoint.co.uk Tue Mar 13 23:08:59 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Tue Mar 13 23:09:02 2007 Subject: [GRASS-dev] portable.h elimination In-Reply-To: <1766.85.10.71.67.1173822289.squirrel@geog-pc40.ulb.ac.be> References: <17900.5591.692946.780300@cerise.gclements.plus.com> <1766.85.10.71.67.1173822289.squirrel@geog-pc40.ulb.ac.be> Message-ID: On Tue, 13 Mar 2007, Moritz Lennert wrote: > On Mon, March 5, 2007 14:06, Glynn Clements wrote: >> >> I've modified lib/vector/diglib to determine the byte ordering at run >> time, rather than generating the portable.h header file. >> >> The supplied test case passes. It might be useful to test it using dig >> files generated on an architecture with the opposite byte order (I >> have no way to test this). It might also be worth testing it on MinGW. > > How should I test ? Thanks for reminding me about this Moritz - I'd looked at it both quite a while ago and more recently after Glynn posted about the portable.h changes. I don't think there's any change on MinGW - the portable test in the lib/vector/diglib Makefile always failed anyway - presumably that's why it was conditionalised on not running on MinGW. If it is forced to run anyway, I get the following output: ==============TEST============= gcc -L/c/grass/grass6/dist.i686-pc-mingw32/lib -Wl,--export-dynamic,--enable-runtime-pseudo-reloc -L/c/grass/forgrass/lib -I/c/grass/forgrass/include -g -O2 -I/c/grass/forgrass/include -I/c/grass/forgrass/include -I/c/grass/grass6/dist.i686-pc-mingw32/include -o OBJ.i686-pc-mingw32/test test.c -lgrass_dig2 -lgrass_gis -lgrass_datetime -lxdr -liberty -lws2_32 -lz -lgrass_rtree -lgrass_rtree \ -lgrass_gis -lgrass_datetime -lxdr -liberty -lws2_32 -lz -lgrass_datetime -lxdr -liberty -lws2_32 -lz cd OBJ.i686-pc-mingw32; PATH=".:/bin:/mingw/bin:/mingw/lib:/c/grass/forgrass/bin:/c/grass/forgrass/lib:/c/tcl/bin:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:/c/Program Files/QuickTime/QTSystem/:/c/grass/forgrass/bin:/c/grass/forgrass/lib:/c/tcl/bin:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:/c/Program Files/QuickTime/QTSystem/:/c/jed09916/bin:/c/grass/grass6/dist.i686-pc-mingw32/lib" ./test; diff ./test.tmp ../test.ok ERROR in read/write portable double, byte_order = 0 Written: -1.3332999999999999e+0003E Read : -1.7976931348623157e+3083E ERROR in read/write portable double, byte_order = 0 Written: -2.2250738585072014e-3083E Read : -1.7976931348623157e+3083E ERROR in read/write portable double, byte_order = 0 Written: 0.0000000000000000e+0003E Read : -1.7976931348623157e+3083E ERROR in read/write portable double, byte_order = 0 Written: 2.2250738585072014e-3083E Read : -1.7976931348623157e+3083E ERROR in read/write portable double, byte_order = 0 Written: 1.3332999999999999e+0003E Read : -1.7976931348623157e+3083E ERROR in read/write portable double, byte_order = 0 Written: 1.7976931348623157e+3083E Read : -1.7976931348623157e+3083E ERROR in read/write portable float, byte_order = 0 Written: -3.40282347e+0383E Read : -1.#QNAN000e+0003E ERROR in read/write portable float, byte_order = 0 Written: -1.33329999e+0003E Read : -1.#QNAN000e+0003E ERROR in read/write portable float, byte_order = 0 Written: -1.17549435e-0383E Read : -1.#QNAN000e+0003E ERROR in read/write portable float, byte_order = 0 Written: 0.00000000e+0003E Read : -1.#QNAN000e+0003E ERROR in read/write portable float, byte_order = 0 Written: 1.17549435e-0383E Read : -1.#QNAN000e+0003E ERROR in read/write portable float, byte_order = 0 Written: 1.33329999e+0003E Read : -1.#QNAN000e+0003E ERROR in read/write portable float, byte_order = 0 Written: 3.40282347e+0383E Read : -1.#QNAN000e+0003E ERROR in read/write portable long, byte_order = 0 Written: -2147483647 Read : -1048577 ERROR in read/write portable long, byte_order = 0 Written: -123456789 Read : -1048577 ERROR in read/write portable long, byte_order = 0 Written: 0 Read : -1048577 ERROR in read/write portable long, byte_order = 0 Written: 123456789 Read : -1048577 ERROR in read/write portable long, byte_order = 0 Written: 2147483647 Read : -1048577 ERROR in read/write portable int, byte_order = 0 Written: -2147483647 Read : -1048577 ERROR in read/write portable int, byte_order = 0 Written: -123456789 Read : -1048577 ERROR in read/write portable int, byte_order = 0 Written: 0 Read : -1048577 ERROR in read/write portable int, byte_order = 0 Written: 123456789 Read : -1048577 ERROR in read/write portable int, byte_order = 0 Written: 2147483647 Read : -1048577 ERROR in read/write portable short, byte_order = 0 Written: -32768 Read : -17 ERROR in read/write portable short, byte_order = 0 Written: -12345 Read : -17 ERROR in read/write portable short, byte_order = 0 Written: 0 Read : -17 ERROR in read/write portable short, byte_order = 0 Written: 12345 Read : -17 ERROR in read/write portable short, byte_order = 0 Written: 32767 Read : -17 ERROR in read/write portable char, byte_order = 0 Written: -128 Read : -1 ERROR in read/write portable char, byte_order = 0 Written: -123 Read : -1 ERROR in read/write portable char, byte_order = 0 Written: 0 Read : -1 ERROR in read/write portable char, byte_order = 0 Written: 123 Read : -1 ERROR in read/write portable char, byte_order = 0 Written: 127 Read : -1 ERROR in read/write portable double, byte_order = 1 Written: -1.7976931348623157e+3083E Read : -1.#QNAN00000000000e+0003E ERROR in read/write portable double, byte_order = 1 Written: -1.3332999999999999e+0003E Read : -1.#QNAN00000000000e+0003E ERROR in read/write portable double, byte_order = 1 Written: -2.2250738585072014e-3083E Read : -1.#QNAN00000000000e+0003E ERROR in read/write portable double, byte_order = 1 Written: 0.0000000000000000e+0003E Read : -1.#QNAN00000000000e+0003E ERROR in read/write portable double, byte_order = 1 Written: 2.2250738585072014e-3083E Read : -1.#QNAN00000000000e+0003E ERROR in read/write portable double, byte_order = 1 Written: 1.3332999999999999e+0003E Read : -1.#QNAN00000000000e+0003E ERROR in read/write portable double, byte_order = 1 Written: 1.7976931348623157e+3083E Read : -1.#QNAN00000000000e+0003E ERROR in read/write portable float, byte_order = 1 Written: -3.40282347e+0383E Read : -1.#QNAN000e+0003E ERROR in read/write portable float, byte_order = 1 Written: -1.33329999e+0003E Read : -1.#QNAN000e+0003E ERROR in read/write portable float, byte_order = 1 Written: -1.17549435e-0383E Read : -1.#QNAN000e+0003E ERROR in read/write portable float, byte_order = 1 Written: 0.00000000e+0003E Read : -1.#QNAN000e+0003E ERROR in read/write portable float, byte_order = 1 Written: 1.17549435e-0383E Read : -1.#QNAN000e+0003E ERROR in read/write portable float, byte_order = 1 Written: 1.33329999e+0003E Read : -1.#QNAN000e+0003E ERROR in read/write portable float, byte_order = 1 Written: 3.40282347e+0383E Read : -1.#QNAN000e+0003E ERROR in read/write portable long, byte_order = 1 Written: -2147483647 Read : -4097 ERROR in read/write portable long, byte_order = 1 Written: -123456789 Read : -4097 ERROR in read/write portable long, byte_order = 1 Written: 0 Read : -4097 ERROR in read/write portable long, byte_order = 1 Written: 123456789 Read : -4097 ERROR in read/write portable long, byte_order = 1 Written: 2147483647 Read : -4097 ERROR in read/write portable int, byte_order = 1 Written: -2147483647 Read : -4097 ERROR in read/write portable int, byte_order = 1 Written: -123456789 Read : -4097 ERROR in read/write portable int, byte_order = 1 Written: 0 Read : -4097 ERROR in read/write portable int, byte_order = 1 Written: 123456789 Read : -4097 ERROR in read/write portable int, byte_order = 1 Written: 2147483647 Read : -4097 ERROR in read/write portable short, byte_order = 1 Written: -32768 Read : -4097 ERROR in read/write portable short, byte_order = 1 Written: -12345 Read : -4097 ERROR in read/write portable short, byte_order = 1 Written: 0 Read : -4097 ERROR in read/write portable short, byte_order = 1 Written: 12345 Read : -4097 ERROR in read/write portable short, byte_order = 1 Written: 32767 Read : -4097 ERROR in read/write portable char, byte_order = 1 Written: -128 Read : -1 ERROR in read/write portable char, byte_order = 1 Written: -123 Read : -1 ERROR in read/write portable char, byte_order = 1 Written: 0 Read : -1 ERROR in read/write portable char, byte_order = 1 Written: 123 Read : -1 ERROR in read/write portable char, byte_order = 1 Written: 127 Read : -1 Binary files ./test.tmp and ../test.ok differ make: *** [OBJ.i686-pc-mingw32/test] Error 1 For some reason (can't quite remember why) I changed test.c in the past to try and get this to work. ISTR someone suggested somewhere extra seeks were needed on Windows. This is what I changed: --- test.c.orig Tue Mar 6 12:05:41 2007 +++ test.c.pk Fri Dec 15 10:55:33 2006 @@ -62,6 +62,7 @@ for (j=0; j < 7; j++) { fprintf (fp.file, "double "); + dig_fseek (&fp, 0, SEEK_CUR); dig__fwrite_port_D ( &(td[j]), 1, &fp); dig_fseek (&fp, -(PORT_DOUBLE), SEEK_CUR); dig__fread_port_D (&db, 1, &fp); @@ -76,6 +77,7 @@ for (j=0; j < 7; j++) { fprintf (fp.file, "float "); + dig_fseek (&fp, 0, SEEK_CUR); dig__fwrite_port_F ( &(tf[j]), 1, &fp); dig_fseek (&fp, -(PORT_FLOAT), SEEK_CUR); dig__fread_port_F (&fb, 1, &fp); @@ -91,6 +93,7 @@ for (j=0; j < 5; j++) { fprintf (fp.file, "long "); + dig_fseek (&fp, 0, SEEK_CUR); dig__fwrite_port_L ( &(tl[j]), 1, &fp); dig_fseek (&fp, -(PORT_LONG), SEEK_CUR); dig__fread_port_L (&lb, 1, &fp); @@ -106,6 +109,7 @@ for (j=0; j < 5; j++) { fprintf (fp.file, "int "); + dig_fseek (&fp, 0, SEEK_CUR); dig__fwrite_port_I ( &(ti[j]), 1, &fp); dig_fseek (&fp, -(PORT_INT), SEEK_CUR); dig__fread_port_I (&ib, 1, &fp); @@ -121,6 +125,7 @@ for (j=0; j < 5; j++) { fprintf (fp.file, "short "); + dig_fseek (&fp, 0, SEEK_CUR); dig__fwrite_port_S ( &(ts[j]), 1, &fp); dig_fseek (&fp, -(PORT_SHORT), SEEK_CUR); dig__fread_port_S (&sb, 1, &fp); @@ -135,6 +140,7 @@ for (j=0; j < 5; j++) { fprintf (fp.file, "char "); + dig_fseek (&fp, 0, SEEK_CUR); dig__fwrite_port_C ( &(tc[j]), 1, &fp); dig_fseek (&fp, -(PORT_CHAR), SEEK_CUR); dig__fread_port_C (&cb, 1, &fp); And with that the output from the test is now: ==============TEST============= gcc -L/c/grass/grass6/dist.i686-pc-mingw32/lib -Wl,--export-dynamic,--enable-runtime-pseudo-reloc -L/c/grass/forgrass/lib -I/c/grass/forgrass/include -g -O2 -I/c/grass/forgrass/include -I/c/grass/forgrass/include -I/c/grass/grass6/dist.i686-pc-mingw32/include -o OBJ.i686-pc-mingw32/test test.c -lgrass_dig2 -lgrass_gis -lgrass_datetime -lxdr -liberty -lws2_32 -lz -lgrass_rtree -lgrass_rtree \ -lgrass_gis -lgrass_datetime -lxdr -liberty -lws2_32 -lz -lgrass_datetime -lxdr -liberty -lws2_32 -lz cd OBJ.i686-pc-mingw32; PATH=".:/bin:/mingw/bin:/mingw/lib:/c/grass/forgrass/bin:/c/grass/forgrass/lib:/c/tcl/bin:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:/c/Program Files/QuickTime/QTSystem/:/c/grass/forgrass/bin:/c/grass/forgrass/lib:/c/tcl/bin:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:/c/Program Files/QuickTime/QTSystem/:/c/jed09916/bin:/c/grass/grass6/dist.i686-pc-mingw32/lib" ./test; diff ./test.tmp ../test.ok Binary files ./test.tmp and ../test.ok differ make: *** [OBJ.i686-pc-mingw32/test] Error 1 i.e. the test files are still different, but it doesn't have lots of errors while running. I have no idea if/how that is significant! Paul From mlennert at club.worldonline.be Tue Mar 13 23:12:25 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Tue Mar 13 23:09:35 2007 Subject: [GRASS-dev] testing native winGRASS Message-ID: <2738.85.10.71.67.1173823945.squirrel@geog-pc40.ulb.ac.be> Hello, I have finally started going through the GDF GRASS 6.0 manual and test all commands mentioned there in the current CVS winGRASS. A first round of results is attached. If the telegraphic style is not clear enough, let me know. I will post more as I go along. And let me try once again: I think it might be good to try to increase the number of pre-alpha testers, and I think there might be some candidates among the many that post winGRASS questions on the wingrass mailing list. Aren't we at the point where we can replace the link to Huidae's binaries with a link to the current version, clearly indicating that this is pre-alpha and only to be used by people who want to help us ? Moritz -------------- next part -------------- Testing WinGRASS: 1) Create location with projection values: location created but mapset (other than PERMANENT) invalid 2) v.out.ogr (GUI) crashes on export of vector file / runs endlessly (or for very long time); on command line v.out.ogr landcover => stops at 73% 3) v.in.ogr: cannot open datasource c:/grassdata/, but c:/grassdata works; topology building output in gui truncated; v.out.ogr landcover -> v.in.ogr lancover fails: 0 features imported 4) r.out.gdal seems to work; but r.out.gdal geotiff, uint16 -> r.in.gdal (very slow !) -> d.rast runs endlessly, without anything showing up in the map display 5) generally, output to gis.m output seems truncated; ex: r.in.gdal ends with "Proceding with import" 6) d.his: Die Syntax f?r den Dateinamen, Verzeichnisnamen oder die Datentr?gerbezeichnung ist falsch [= Wrong syntax for filename, directory name or drive]. -- d.histogram: ERROR running r.stats 7) r.stats crashes gis.m if "one cell per line" option is checked => general problem with output to "Output" window: line buffering ? 8) v.out.ascii bugsites -> v.in.ascii works; but v.in.ascii: progress bar in "Output" stuck at +/- 50%, although module finishes 9) Warning: c:/grass/grass-6.3.cvs/etc/freetypecap: No FreeType definition file From paul-grass at stjohnspoint.co.uk Tue Mar 13 23:34:24 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Tue Mar 13 23:34:26 2007 Subject: [GRASS-dev] Re: testing native winGRASS In-Reply-To: <2738.85.10.71.67.1173823945.squirrel@geog-pc40.ulb.ac.be> References: <2738.85.10.71.67.1173823945.squirrel@geog-pc40.ulb.ac.be> Message-ID: Hello Moritz On Tue, 13 Mar 2007, Moritz Lennert wrote: > 1) Create location with projection values: location created but mapset > (other than PERMANENT) invalid Could you try the patch below for lib/gis/getl.c and see if GRASS can then handle the newly created location? I think the problem is the created location contains Windows line endings in some of the files and other GRASS functions can't handle them. G_getl2() handles Windows line endings whereas G_getl() does not. I have a hunch this may apply in many places. Index: getl.c =================================================================== RCS file: /home/grass/grassrepository/grass6/lib/gis/getl.c,v retrieving revision 2.6 diff -u -r2.6 getl.c --- getl.c 12 Nov 2006 04:05:02 -0000 2.6 +++ getl.c 13 Mar 2007 22:31:02 -0000 @@ -16,6 +16,8 @@ int G_getl ( char *buf, int n, FILE *fd) { + return G_getl2 ( buf, n, fd ); + /* if (!fgets (buf, n, fd)) return 0; @@ -24,6 +26,7 @@ *buf = 0; return 1; + */ } From tutey at o2.pl Tue Mar 13 23:36:41 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Tue Mar 13 23:36:45 2007 Subject: [GRASS-dev] testing native winGRASS In-Reply-To: <2738.85.10.71.67.1173823945.squirrel@geog-pc40.ulb.ac.be> References: <2738.85.10.71.67.1173823945.squirrel@geog-pc40.ulb.ac.be> Message-ID: <45F72779.1060007@o2.pl> Moritz Lennert wrote: > Hello, > > I have finally started going through the GDF GRASS 6.0 manual and test all > commands mentioned there in the current CVS winGRASS. A first round of > results is attached. Moritz I *guess* the failures you mention, when a module prints many lines to tcl/tk GUI output, might be related to: https://intevation.de/rt/webrt?serial_num=4487 https://intevation.de/rt/webrt?serial_num=2937 Glynn offers some explanations in his last post in the https://intevation.de/rt/webrt?serial_num=2937. I hope this is some help. Best, Maciek From michael.barton at asu.edu Wed Mar 14 00:47:43 2007 From: michael.barton at asu.edu (Michael Barton) Date: Wed Mar 14 00:47:56 2007 Subject: [GRASS-dev] d.menu, d.ask In-Reply-To: <17911.5028.813207.357576@cerise.gclements.plus.com> Message-ID: Glynn, You can down load it from the GRASS Addons svn server Most of the files need to go into $GISBASE/etc/wx. If you want to try the gis_set.py replacement or the wizard, you'll need to put them into $GISBASE/etc and edit init.sh (the one on the server does not work as is, but is partly edited to work). >From the grass command line start it up with $GISBASE/etc/wx/gism2.py (this will probably change to just gism.py in a day or so). I've attached a screenshot of the GIS Manager window version that I just committed to give some idea. Michael On 3/13/07 2:12 PM, "Glynn Clements" wrote: > > Michael Barton wrote: > >> The wxPython GUI is coming along very well, thanks to >> the efforts of J?chym and Martin. I've finally been able to rejoin the >> development. With 3 (or more???) of us working on it, it should move along >> at a nice pace. > > So, how does one try this out? __________________________________________ 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 -------------- A non-text attachment was scrubbed... Name: wxgrass1.jpeg Type: application/octet-stream Size: 23871 bytes Desc: not available Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070313/a8c75a50/wxgrass1-0001.obj From dylan.beaudette at gmail.com Wed Mar 14 02:46:42 2007 From: dylan.beaudette at gmail.com (Dylan Beaudette) Date: Wed Mar 14 02:46:05 2007 Subject: [GRASS-dev] v.breach and v.line.center GRASS addons In-Reply-To: <45F7043A.7020600@o2.pl> References: <45F7043A.7020600@o2.pl> Message-ID: <200703131846.42166.dylan.beaudette@gmail.com> Great work Maciej! On Tuesday 13 March 2007 13:06, Maciej Sieczka wrote: > Hi > > I have submitted 2 new scripts for GRASS 6.x to GRASS WIKI > http://grass.gdf-hannover.de/wiki/GRASS_AddOns: > > v.line.center creates a points vector map with each point located in > the middle of the length of one input vector line. So this script locates a line's midpoint, and puts a new point there? Does this point have the same attributes as the line which was used as the input? > v.breach creates vector maps of lines and points of continously > lowering elevation down the input watercourses, based on the input > raster DEM. > > > > v.line.center is a simple self-explanatory tool. > > v.breach is more complex. It is similar to r.carve -n, with the > following differences: > > 1. It takes the direction of input vector lines into account; which > means it is less prone to artifacts in the input DEM but more demanding > to input watercourses. As a result you can breach DEM even against the > slope, if that's needed ;). cool. any examples yet? > 2. It does not breach the DEM itself, but outputs vector points which > have the breached elevation attribute stored in the table. These points > can be used as additional data for interpolating more hydrologicaly > sound DEM from scratch, or rasterized and burned into the input DEM > manually (v.to.rast, r.mapcalc). > > 3. It also outputs vector lines, which are the input vector > watercourses segmented one segment per each DEM cell through which a > given input watercourse flows. Those segments have the breached > elevation attribute same as the output vector points. I needed such > output for my work. Maybe it will be of some use for others. > > 4. It is way slower than r.carve. Shell (I have got rid of bashisms I > hope) + Awk + standard UNIX tools. > > See the v.breach manual for more details. > > Maciek > Did this approach allow you to use RST in complex terrain with drainage enforcement- to create a better DEM than was previously possible? I recall severall discussions pertaining to the creation of DEM from difficult input points, specifically with the RST interpolator. Looking forward to trying these new modules soon, -- Dylan Beaudette Soils and Biogeochemistry Graduate Group University of California at Davis 530.754.7341 From hamish_nospam at yahoo.com Wed Mar 14 03:29:56 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Mar 14 03:30:12 2007 Subject: [GRASS-dev] Re: [GRASS-user] Compiling grass 6.2.1: i.class error In-Reply-To: <17910.53187.37429.30986@cerise.gclements.plus.com> References: <17900.51141.833484.448599@cerise.gclements.plus.com> <17905.41116.200524.360228@cerise.gclements.plus.com> <17910.53187.37429.30986@cerise.gclements.plus.com> Message-ID: <20070314152956.44294ac0.hamish_nospam@yahoo.com> Glynn Clements wrote: > Every other --without-* switch should work without requiring > additional effort from the user, but curses is currently sufficiently > ingrained that making --without-curses work nicely is too much effort > for a relatively obscure usage case. ./configure --help ... --with-glw support GLw functionality (default: no) ... --with-glw-includes=DIRS GLw include files are in DIRS --with-glw-libs=DIRS GLw library files are in DIRS Is GLw still relevant? If not, let's remove it. Hamish From rez at touchofmadness.com Wed Mar 14 04:47:28 2007 From: rez at touchofmadness.com (Brad Douglas) Date: Wed Mar 14 04:47:49 2007 Subject: [GRASS-dev] Re: [GRASS-user] Compiling grass 6.2.1: i.class error In-Reply-To: <20070314152956.44294ac0.hamish_nospam@yahoo.com> References: <17900.51141.833484.448599@cerise.gclements.plus.com> <17905.41116.200524.360228@cerise.gclements.plus.com> <17910.53187.37429.30986@cerise.gclements.plus.com> <20070314152956.44294ac0.hamish_nospam@yahoo.com> Message-ID: <1173844048.28983.71.camel@devel> On Wed, 2007-03-14 at 15:29 +1300, Hamish wrote: > Glynn Clements wrote: > > Every other --without-* switch should work without requiring > > additional effort from the user, but curses is currently sufficiently > > ingrained that making --without-curses work nicely is too much effort > > for a relatively obscure usage case. > > ./configure --help > ... > --with-glw support GLw functionality (default: no) > ... > --with-glw-includes=DIRS > GLw include files are in DIRS > --with-glw-libs=DIRS GLw library files are in DIRS > > > Is GLw still relevant? If not, let's remove it. Can we add --with-motif* to the list? And --with-readline* for good measure? -- Brad Douglas KB8UYR/6 Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From hamish_nospam at yahoo.com Wed Mar 14 08:02:18 2007 From: hamish_nospam at yahoo.com (Hamish) Date: Wed Mar 14 08:02:30 2007 Subject: [GRASS-dev] GRASS 7 timeline [was: d.menu, d.ask] In-Reply-To: <17910.40594.425581.580790@cerise.gclements.plus.com> References: <17908.16039.431289.828167@cerise.gclements.plus.com> <20070313185912.2972b68b.hamish_nospam@yahoo.com> <17910.40594.425581.580790@cerise.gclements.plus.com> Message-ID: <20070314200218.1c79ba08.hamish_nospam@yahoo.com> Glynn Clements wrote: > Is there an expected timeline for 7.x? That is entirely up to the fine folks on this list; I would guess that when the time comes, we know & we do it. Maybe then is now? I would not object to it happening as soon as the SVN server is up and running. (no technical reason for that, just a nice time for it to happen) my wishes for the GRASS 7.0.0 release * native MS windows fully stable and equal - worthy of a major point release, if simply for the PR value * wxPython fully implemented for all GUIs - no or minimal Tcl, for a consistent user experience keep Tcl as non-default, optional "oldgui" ??? (answer that later) * no more interactive d.*, xterm GUIs, etc * centralized $MAPSET/raster/$MAPNAME/element * more? - would a new raster format mean a new major point? or ok as long as lib fns were backwards compatible with the old format? too much to ask to support both? or r.convert module, like G6's v.convert? the raster format changes could mean a time of dual branch development like we had for Radim+Markus working on 5.1/5.7/6 and most everyone else working on 5.0/5.4. Markus may have some stern words about that. ;) > If so, does that signify a point at which fundamental changes to the > graphics architecture can commence? I guess we could restate the question as do we want/need a GRASS 6.4 stable release, or should we continue in devel mode all the way to 7.0? (FWIW, I see no current need for a stable 6.4*, but 6.3.0 would be a nice milestone once winGrass is usable. If no 6.4 is planned, then there is no need for a new SVN branch for 7.0 devel, we just continue with 6.3. If there is demand for a 6.4.0, we start a 6.5 branch in SVN and cull away) [*] r.li could be safely backported to 6.2? Tcl GUI updates less so but we shouldn't abandon them. I guess they will be the day-to-day GUI during wxPython devel, so post 6.2 Tcl GUI work wouldn't be for nothing. ?? The 6.x problem is not with fundamental changes to the underlying architecture, that is wide open during a development minor version, and AFAIAC go for it. The issue is changing the user interface to the extent that scripts/ books/ tutorials/ training/ data for "GRASS 6" no longer works with "GRASS 6". So we are free to "get our ducks in a row" now, and we should do that, we just have to make an effort to minimize user pain as we go. When it is apparent that we have reached the point where the effort to maintain backwards compatibility is a big time+energy sink, we trigger the start of GRASS 7 development, without regret. > If not, i.e. if i.ortho.photo *has* to continue to work until such > time that someone sees fit to write an alternative (if that ever > happens), then the graphics architecture will forever be limited to a > Tek4105 emulation, and I may as well give up now. I think we can, today, clearly make a list of things that will not be in GRASS 7. Firstly a list of lib fn families, and secondly a list of modules. Presumably replacements GUIs for missing modules will come on-line in proportion to the demand for module's functionality. > IMHO, I don't think that we can wait forever for decent graphics. The > biggest danger is that the "you can't remove that because someone > still uses it" problem will end up solving itself when no-one actually > uses GRASS any more. I'd prefer people to set achievable goals than to > insist on having everything and ending up with nothing. We just have to call it GRASS 7. As that is just a number it is simple to change. No need to artificially slow down development to keep 6.x alive. e.g. People with need for GRASS 5.4 can still use that if they want, without loss of functionality, new devel switching to GRASS 6 hasn't changed that. And GRASS 7 devel won't hurt those who still want to use GRASS 6. So no worries. Hamish From grass-codep at wald.intevation.org Wed Mar 14 11:28:47 2007 From: grass-codep at wald.intevation.org (grass-codep@wald.intevation.org) Date: Wed Mar 14 11:28:53 2007 Subject: [GRASS-dev] [grass-code P][334] get rid of G_site_*() in v.hull Message-ID: <20070314102847.5F7E21839D34@pyrosoma.intevation.org> code P item #334, was opened at 2007-03-14 11:28 Status: Open Priority: 3 Submitted By: Martin Landa (martinl) Assigned to: Martin Landa (martinl) Summary: get rid of G_site_*() in v.hull Patch status: None Patch type: None GRASS component: vector GRASS version: CVS HEAD GRASS CVS checkout date, if applies (YYMMDD): Initial Comment: Hi, the attached patch removes sites.h dependency in v.hull modules. If there is no objections I will commit the patch to CVS. Martin ---------------------------------------------------------------------- You can respond by visiting: http://wald.intevation.org/tracker/?func=detail&atid=205&aid=334&group_id=21 From glynn at gclements.plus.com Wed Mar 14 12:36:41 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Mar 14 12:36:43 2007 Subject: [GRASS-dev] make install fails with 6.3 CVS In-Reply-To: <45F70FE2.4030403@o2.pl> References: <45F70FE2.4030403@o2.pl> Message-ID: <17911.56905.408416.308290@cerise.gclements.plus.com> Maciej Sieczka wrote: > Current 6.3 CVS builds fine, but on make install a bunch of: > > tar: path/to/file: file changed as we read it > > is issued (full log of make install is attached). > > Also some strange 'NONE' subdir is created in the source dir. I can't reproduce either of these symptoms. -- Glynn Clements From glynn at gclements.plus.com Wed Mar 14 12:45:33 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Mar 14 12:45:35 2007 Subject: [GRASS-dev] make install fails with 6.3 CVS In-Reply-To: <45F70FE2.4030403@o2.pl> References: <45F70FE2.4030403@o2.pl> Message-ID: <17911.57437.443171.114588@cerise.gclements.plus.com> Maciej Sieczka wrote: > Current 6.3 CVS builds fine, but on make install a bunch of: > > tar: path/to/file: file changed as we read it > > is issued (full log of make install is attached). > > Also some strange 'NONE' subdir is created in the source dir. Ignore my previous message; I didn't see the attached log file. INST_DIR is getting set to NONE/grass-6.3.cvs, which implies that $prefix is NONE at the point that it's being evaluated. This is a result of recent configure changes related to building a MacOSX App. I didn't notice it before because I normally build with --prefix=/opt. I'm guessing that if you don't specify --prefix, the configure script isn't substituting the default prefix until after we've used it. I just need to quote ${prefix} so that it doesn't get substituted. -- Glynn Clements From benjamin.ducke at ufg.uni-kiel.de Wed Mar 14 12:56:30 2007 From: benjamin.ducke at ufg.uni-kiel.de (benjamin.ducke@ufg.uni-kiel.de) Date: Wed Mar 14 12:56:33 2007 Subject: [GRASS-dev] DBMI troubles on Win32 Message-ID: <1534.155.207.69.214.1173873390.squirrel@webmail.mail.uni-kiel.de> I have tried a GRASS vector map linked to a DFB table. My test data set also is very small and simple. I keep running v.info -c on it and after about 10-15 runs it usually freezes and I have to CTRL+C it. I will do some more testing using breakpoints to see which one of the dbmilib functions is causing this. Strange ... > On Fri, March 9, 2007 09:18, Benjamin Ducke wrote: >> Hi all, >> >> I am currently doing a lot of testing for GRASS 6.3. on the mingw/msys platform (the same that comes with QGIS). >> >> There seems to be a problem related to the DBMI protocol. Modules that access attribute data via the GRASS DBMI lib have a habit of hanging once in a while. I have seen this happen on half a dozen different machines with Win2000 and XP. >> >> An example is v.info -c. The module simply hangs and has to be killed and restarted until it does its work. >> The strange thing is that I cannot find any pattern here: sometimes dozens of runs show no problems at all and sometimes I have to restart a module several times until it starts running. >> Also, this seems to concern only the first DB access. I have a module here that does hundreds of DB accesses during each run. If the first one goes OK, all the others will be fine too ... >> >> I am using the latest 6.3 CVS sources for my tests. >> >> I am at a loss here. Can anyone confirm this problem? > > I can't with the native winGRASS (not QGIS), at least not using v.info -c as a test case within spearfish. But there tables are very small. Which type of files did you try this on ? > > Moritz > > > From glynn at gclements.plus.com Wed Mar 14 12:59:30 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Mar 14 12:59:35 2007 Subject: [GRASS-dev] portable.h elimination In-Reply-To: References: <17900.5591.692946.780300@cerise.gclements.plus.com> <1766.85.10.71.67.1173822289.squirrel@geog-pc40.ulb.ac.be> Message-ID: <17911.58274.497136.710817@cerise.gclements.plus.com> Paul Kelly wrote: > >> I've modified lib/vector/diglib to determine the byte ordering at run > >> time, rather than generating the portable.h header file. > >> > >> The supplied test case passes. It might be useful to test it using dig > >> files generated on an architecture with the opposite byte order (I > >> have no way to test this). It might also be worth testing it on MinGW. > > > > How should I test ? > > Thanks for reminding me about this Moritz - I'd looked at it both quite a > while ago and more recently after Glynn posted about the portable.h > changes. I don't think there's any change on MinGW - the portable test in > the lib/vector/diglib Makefile always failed anyway - presumably that's > why it was conditionalised on not running on MinGW. If it is forced to run > anyway, I get the following output: > For some reason (can't quite remember why) I changed test.c in the past to > try and get this to work. ISTR someone suggested somewhere extra seeks > were needed on Windows. You need to seek when switching between reading and writing. Windows' FILE structure only has a single buffer (rather than separate read/write buffers), so you need to force it to flush/discard any buffered data. > This is what I changed: Can you commit those, please. > And with that the output from the test is now: > > ==============TEST============= > gcc -L/c/grass/grass6/dist.i686-pc-mingw32/lib -Wl,--export-dynamic,--enable-runtime-pseudo-reloc -L/c/grass/forgrass/lib -I/c/grass/forgrass/include -g -O2 -I/c/grass/forgrass/include -I/c/grass/forgrass/include -I/c/grass/grass6/dist.i686-pc-mingw32/include -o OBJ.i686-pc-mingw32/test test.c -lgrass_dig2 -lgrass_gis -lgrass_datetime -lxdr -liberty -lws2_32 -lz -lgrass_rtree -lgrass_rtree \ > -lgrass_gis -lgrass_datetime -lxdr -liberty -lws2_32 -lz -lgrass_datetime -lxdr -liberty -lws2_32 -lz > cd OBJ.i686-pc-mingw32; PATH=".:/bin:/mingw/bin:/mingw/lib:/c/grass/forgrass/bin:/c/grass/forgrass/lib:/c/tcl/bin:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:/c/Program Files/QuickTime/QTSystem/:/c/grass/forgrass/bin:/c/grass/forgrass/lib:/c/tcl/bin:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:/c/Program Files/QuickTime/QTSystem/:/c/jed09916/bin:/c/grass/grass6/dist.i686-pc-mingw32/lib" ./test; diff ./test.tmp ../test.ok > Binary files ./test.tmp and ../test.ok differ > make: *** [OBJ.i686-pc-mingw32/test] Error 1 > > i.e. the test files are still different, but it doesn't have lots of > errors while running. I have no idea if/how that is significant! The stream of errors indicates that what was read back doesn't match what was written, i.e. a problem with low-level I/O. The "diff" failure indicates that what was written wasn't what was expected. This could be a text/binary issue (I don't see $(FMODE_OBJ) in the link command); it could even be due to differences in floating-point rounding (even if only the lowest bit of a double is wrong, the test will still fail). If adding $(FMODE_OBJ) to the test doesn't work, convert test.tmp and test.ok to hex (with "od -t x ...") and compare the hex dumps. -- Glynn Clements From glynn at gclements.plus.com Wed Mar 14 13:03:10 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Mar 14 13:03:12 2007 Subject: [GRASS-dev] portable.h elimination In-Reply-To: <1766.85.10.71.67.1173822289.squirrel@geog-pc40.ulb.ac.be> References: <17900.5591.692946.780300@cerise.gclements.plus.com> <1766.85.10.71.67.1173822289.squirrel@geog-pc40.ulb.ac.be> Message-ID: <17911.58494.7756.133128@cerise.gclements.plus.com> Moritz Lennert wrote: > > I've modified lib/vector/diglib to determine the byte ordering at run > > time, rather than generating the portable.h header file. > > > > The supplied test case passes. It might be useful to test it using dig > > files generated on an architecture with the opposite byte order (I > > have no way to test this). It might also be worth testing it on MinGW. > > How should I test ? Try using the vector commands on existing vector maps, and creating some new vector maps. -- Glynn Clements From glynn at gclements.plus.com Wed Mar 14 13:10:17 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Mar 14 13:10:19 2007 Subject: [GRASS-dev] Re: [GRASS-user] Compiling grass 6.2.1: i.class error In-Reply-To: <20070314152956.44294ac0.hamish_nospam@yahoo.com> References: <17900.51141.833484.448599@cerise.gclements.plus.com> <17905.41116.200524.360228@cerise.gclements.plus.com> <17910.53187.37429.30986@cerise.gclements.plus.com> <20070314152956.44294ac0.hamish_nospam@yahoo.com> Message-ID: <17911.58921.371031.22517@cerise.gclements.plus.com> Hamish wrote: > > Every other --without-* switch should work without requiring > > additional effort from the user, but curses is currently sufficiently > > ingrained that making --without-curses work nicely is too much effort > > for a relatively obscure usage case. > > ./configure --help > ... > --with-glw support GLw functionality (default: no) > ... > --with-glw-includes=DIRS > GLw include files are in DIRS > --with-glw-libs=DIRS GLw library files are in DIRS > > > Is GLw still relevant? Only for r3.showdspf; it's no longer compiled by default (you need to explicitly run "make -C raster3d/r3.showdspf" to build it), but it's still in the source tree. > If not, let's remove it. Only if you are also going to remove raster3d/r3.showdspf. There's no point having the r3.showdspf code in CVS if configure doesn't define the variables which it requires. -- Glynn Clements From glynn at gclements.plus.com Wed Mar 14 13:11:30 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Mar 14 13:11:32 2007 Subject: [GRASS-dev] Re: [GRASS-user] Compiling grass 6.2.1: i.class error In-Reply-To: <1173844048.28983.71.camel@devel> References: <17900.51141.833484.448599@cerise.gclements.plus.com> <17905.41116.200524.360228@cerise.gclements.plus.com> <17910.53187.37429.30986@cerise.gclements.plus.com> <20070314152956.44294ac0.hamish_nospam@yahoo.com> <1173844048.28983.71.camel@devel> Message-ID: <17911.58994.858868.462335@cerise.gclements.plus.com> Brad Douglas wrote: > > > Every other --without-* switch should work without requiring > > > additional effort from the user, but curses is currently sufficiently > > > ingrained that making --without-curses work nicely is too much effort > > > for a relatively obscure usage case. > > > > ./configure --help > > ... > > --with-glw support GLw functionality (default: no) > > ... > > --with-glw-includes=DIRS > > GLw include files are in DIRS > > --with-glw-libs=DIRS GLw library files are in DIRS > > > > > > Is GLw still relevant? If not, let's remove it. > > Can we add --with-motif* to the list? It's used by xganim, which is still compiled if you use --with-motif. > And --with-readline* for good measure? Why? Some people seem to want that functionality in r.mapcalc. -- Glynn Clements From glynn at gclements.plus.com Wed Mar 14 13:40:33 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Mar 14 13:40:37 2007 Subject: [GRASS-dev] GRASS 7 timeline [was: d.menu, d.ask] In-Reply-To: <20070314200218.1c79ba08.hamish_nospam@yahoo.com> References: <17908.16039.431289.828167@cerise.gclements.plus.com> <20070313185912.2972b68b.hamish_nospam@yahoo.com> <17910.40594.425581.580790@cerise.gclements.plus.com> <20070314200218.1c79ba08.hamish_nospam@yahoo.com> Message-ID: <17911.60737.998513.401787@cerise.gclements.plus.com> Hamish wrote: > That is entirely up to the fine folks on this list; I would guess that > when the time comes, we know & we do it. Maybe then is now? I would not > object to it happening as soon as the SVN server is up and running. (no > technical reason for that, just a nice time for it to happen) > > my wishes for the GRASS 7.0.0 release > * native MS windows fully stable and equal For the native Windows version to be fully "equal", monitors need to be made to work. Even if we ditched all of the programs which require a monitor (e.g. i.ortho.photo), so long as d.* commands can be used with a monitor, the absence of monitors will make Windows less than equal. > * no more interactive d.*, xterm GUIs, etc By "interactive d.*", are you talking solely of the use of the mouse, or about the ability to use them with monitors rather than within gis.m? In any case, saying "no more interactive d.*" for 7.0.0 stable and (in your previous message) means that's going to be a long way off. And a lot of the changes to the graphics architecture cannot even *start* until the R_get_location_with_* cruft is ditched. Once that does happen, the graphics architecture is going to become highly unstable. IOW, a new graphics architecture remains almost as far away now as it does when it was first discussed a few years back. > * centralized $MAPSET/raster/$MAPNAME/element > * more? > - would a new raster format mean a new major point? or ok as long > as lib fns were backwards compatible with the old format? too much > to ask to support both? or r.convert module, like G6's v.convert? Your wish list is too long. Given the glacial pace of GRASS development, a version with all of these features won't be ready within the next decade. > > If so, does that signify a point at which fundamental changes to the > > graphics architecture can commence? > > I guess we could restate the question as do we want/need a GRASS 6.4 > stable release, or should we continue in devel mode all the way to 7.0? > > (FWIW, I see no current need for a stable 6.4*, but 6.3.0 would be a > nice milestone once winGrass is usable. If no 6.4 is planned, then there > is no need for a new SVN branch for 7.0 devel, we just continue with > 6.3. If there is demand for a 6.4.0, we start a 6.5 branch in SVN and > cull away) > > [*] r.li could be safely backported to 6.2? Tcl GUI updates less so but > we shouldn't abandon them. I guess they will be the day-to-day GUI > during wxPython devel, so post 6.2 Tcl GUI work wouldn't be for nothing. > ?? > > The 6.x problem is not with fundamental changes to the underlying > architecture, that is wide open during a development minor version, and > AFAIAC go for it. The issue is changing the user interface to the > extent that scripts/ books/ tutorials/ training/ data for "GRASS 6" no > longer works with "GRASS 6". So we are free to "get our ducks in a row" > now, and we should do that, we just have to make an effort to minimize > user pain as we go. You can't make *fundamental* architectural changes without some of that "leaking" into user-visible changes. > When it is apparent that we have reached the point where the effort to > maintain backwards compatibility is a big time+energy sink, we trigger > the start of GRASS 7 development, without regret. The effor to maintain backwards compatibility has *always* been a big time and energy sink. With regard to the graphics architecture, the need to support standalone display drivers is by far the biggest obstacle. If the raster/display libraries were simply rendering libraries (like e.g. GD), any changes or enhancements would only require 1/10th as much effort. > > If not, i.e. if i.ortho.photo *has* to continue to work until such > > time that someone sees fit to write an alternative (if that ever > > happens), then the graphics architecture will forever be limited to a > > Tek4105 emulation, and I may as well give up now. > > I think we can, today, clearly make a list of things that will not be in > GRASS 7. Firstly a list of lib fn families, and secondly a list of > modules. Presumably replacements GUIs for missing modules will come > on-line in proportion to the demand for module's functionality. However, the billion-dollar question is this: if a module *doesn't* get re-implemented in a reasonable time-frame, can it be dropped, or does it continue to block progress indefinitely? It seems that certain modules are considered too important to drop, but not important enough for anyone to actually re-implement them. [Yes, I'm thinking primarily about i.ortho.photo; the other stuff I could do myself if necessary.] > > IMHO, I don't think that we can wait forever for decent graphics. The > > biggest danger is that the "you can't remove that because someone > > still uses it" problem will end up solving itself when no-one actually > > uses GRASS any more. I'd prefer people to set achievable goals than to > > insist on having everything and ending up with nothing. > > We just have to call it GRASS 7. As that is just a number it is simple to > change. No need to artificially slow down development to keep 6.x alive. > e.g. People with need for GRASS 5.4 can still use that if they want, > without loss of functionality, new devel switching to GRASS 6 hasn't > changed that. Hmm. Anyone using 5.4 can't share vector data with anyone using 6.x. Also, any bug fixes to 6.x won't get back-ported to 5.4. The same will be true once work starts on 7.x. > And GRASS 7 devel won't hurt those who still want to use > GRASS 6. So no worries. That's fine so long as there aren't any major problems with 6.x. Once you start making changes which affect a lot of code, back-porting fixes ceases to become viable. -- Glynn Clements From glynn at gclements.plus.com Wed Mar 14 13:48:18 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Mar 14 13:48:31 2007 Subject: [GRASS-dev] d.menu, d.ask In-Reply-To: References: <17911.5028.813207.357576@cerise.gclements.plus.com> Message-ID: <17911.61202.268293.361881@cerise.gclements.plus.com> Michael Barton wrote: > You can down load it from the GRASS Addons svn server > grassaddons_gui_> I already got the code with: svn co https://grasssvn.itc.it/svn/grassaddons/trunk/grassaddons/gui But I just got a bunch of files with no clue what to do with them. > Most of the files need to go into $GISBASE/etc/wx. If you want to try the > gis_set.py replacement or the wizard, you'll need to put them into > $GISBASE/etc and edit init.sh (the one on the server does not work as is, > but is partly edited to work). Making it more straightforward to use should be a priority. If necessary, move it out of SVN and into the main CVS repository. > From the grass command line start it up with $GISBASE/etc/wx/gism2.py (this > will probably change to just gism.py in a day or so). $ $GISBASE/etc/wx/gism2.py bash: /opt/grass-6.3.cvs/etc/wx/gism2.py: Permission denied $ chmod +x $GISBASE/etc/wx/gism2.py $ $GISBASE/etc/wx/gism2.py Traceback (most recent call last): File "/opt/grass-6.3.cvs/etc/wx/gism2.py", line 5, in ? import wx.lib.customtreectrl as CT ImportError: No module named customtreectrl Presumably I need a specific version of wxWidgets or wxPython? -- Glynn Clements From neteler at itc.it Wed Mar 14 14:19:01 2007 From: neteler at itc.it (Markus Neteler) Date: Wed Mar 14 14:19:05 2007 Subject: [GRASS-dev] GRASS 7 timeline In-Reply-To: <20070314200218.1c79ba08.hamish_nospam@yahoo.com> References: <17908.16039.431289.828167@cerise.gclements.plus.com> <20070313185912.2972b68b.hamish_nospam@yahoo.com> <17910.40594.425581.580790@cerise.gclements.plus.com> <20070314200218.1c79ba08.hamish_nospam@yahoo.com> Message-ID: <20070314131901.GB25749@bartok.itc.it> [merging in Glynn's answer at bottom] On Wed, Mar 14, 2007 at 08:02:18PM +1300, Hamish wrote: > Glynn Clements wrote: > > Is there an expected timeline for 7.x? > > That is entirely up to the fine folks on this list; I would guess that > when the time comes, we know & we do it. Maybe then is now? I would not > object to it happening as soon as the SVN server is up and running. (no > technical reason for that, just a nice time for it to happen) We can seriously think about it once the migration to SVN is done. > my wishes for the GRASS 7.0.0 release > * native MS windows fully stable and equal > - worthy of a major point release, if simply for the PR value I hope to see major MS-Windows support already in 6.3.0! At least we were telling so for some months... and not too much seems to be missing. > * wxPython fully implemented for all GUIs > - no or minimal Tcl, for a consistent user experience > keep Tcl as non-default, optional "oldgui" ??? (answer that later) > * no more interactive d.*, xterm GUIs, etc > * centralized $MAPSET/raster/$MAPNAME/element > * more? > - would a new raster format mean a new major point? or ok as long > as lib fns were backwards compatible with the old format? too much > to ask to support both? or r.convert module, like G6's v.convert? New raster format definitely deserved a major version number. > the raster format changes could mean a time of dual branch development > like we had for Radim+Markus working on 5.1/5.7/6 and most everyone else > working on 5.0/5.4. Markus may have some stern words about that. ;) A period of dual branch development won't be avoidable. Maybe SVN is helpful in this regard. > > If so, does that signify a point at which fundamental changes to the > > graphics architecture can commence? > > I guess we could restate the question as do we want/need a GRASS 6.4 > stable release, or should we continue in devel mode all the way to 7.0? I don't see a reason why not having a 6.4 stable release. > (FWIW, I see no current need for a stable 6.4*, but 6.3.0 would be a > nice milestone once winGrass is usable. Right. Basically the winGRASS port completion (say, that relevant modules and startup are working) is holding 6.3.0 now. > If no 6.4 is planned, then there > is no need for a new SVN branch for 7.0 devel, we just continue with > 6.3. If there is demand for a 6.4.0, we start a 6.5 branch in SVN and > cull away) In order to maintain the history, we have to move the entire CVS to SVN first. Means, that 6.3.0 could come from SVN if the winGRASS port completion takes more months (hopefully not). > [*] r.li could be safely backported to 6.2? I highly recommend to do testing of r.li.* first. I have fixed a few tons of issues and added some test script to raster/r.li/TODO based on spearfish. I get all sort of suspect results (see there)! > Tcl GUI updates less so but > we shouldn't abandon them. I guess they will be the day-to-day GUI > during wxPython devel, so post 6.2 Tcl GUI work wouldn't be for nothing. > ?? at least 'd.m' seems to be unmaintained and probably almost unused. > The 6.x problem is not with fundamental changes to the underlying > architecture, that is wide open during a development minor version, and > AFAIAC go for it. The issue is changing the user interface to the > extent that scripts/ books/ tutorials/ training/ data for "GRASS 6" no > longer works with "GRASS 6". So we are free to "get our ducks in a row" > now, and we should do that, we just have to make an effort to minimize > user pain as we go. > > When it is apparent that we have reached the point where the effort to > maintain backwards compatibility is a big time+energy sink, we trigger > the start of GRASS 7 development, without regret. > > > > If not, i.e. if i.ortho.photo *has* to continue to work until such > > time that someone sees fit to write an alternative (if that ever > > happens), then the graphics architecture will forever be limited to a > > Tek4105 emulation, and I may as well give up now. I think that it is our policy to not discontinue modules in a release cycle. So i.ortho.photo should remain in 6.x. Brad has proposed a series of improvements to i.ortho.photo and AFAIK already implemented most of them. Why don't we take a look at these? > I think we can, today, clearly make a list of things that will not be in > GRASS 7. Firstly a list of lib fn families, and secondly a list of > modules. Presumably replacements GUIs for missing modules will come > on-line in proportion to the demand for module's functionality. This list should go into the Wiki, here it's quickly getting lost. > > IMHO, I don't think that we can wait forever for decent graphics. The > > biggest danger is that the "you can't remove that because someone > > still uses it" problem will end up solving itself when no-one actually > > uses GRASS any more. I'd prefer people to set achievable goals than to > > insist on having everything and ending up with nothing. > > We just have to call it GRASS 7. Agreed. Just start it. But call it GRASS 7. Following gravity law, folks will migrate over (as it did for the 5.x -> 5.7 -> 6.0 path). > As that is just a number it is simple to > change. No need to artificially slow down development to keep 6.x alive. > e.g. People with need for GRASS 5.4 can still use that if they want, > without loss of functionality, new devel switching to GRASS 6 hasn't > changed that. And GRASS 7 devel won't hurt those who still want to use > GRASS 6. So no worries. Other example: We are updating our book to GRASS 6.3. So it would only partially work with GRASS 7 once it is there. But that will take time. There will be necessarily overlap between 6.x and 7.x development. ####### On Wed, Mar 14, 2007 at 12:40:33PM +0000, Glynn Clements wrote: > However, the billion-dollar question is this: if a module *doesn't* > get re-implemented in a reasonable time-frame, can it be dropped, or > does it continue to block progress indefinitely? It may block progress in the current release but not in a higher version number. So, i.ortho.photo should not be dropped from 6.x but could be for 7.x. > It seems that certain modules are considered too important to drop, > but not important enough for anyone to actually re-implement them. concerning i.ortho.photo: - besides "important" there can be also a knowledge gap, i.e. that nobody of the *current* team is *able* to implement it again - Brad proposed a series of improvements: http://grass.itc.it/pipermail/grass-dev/2006-December/028073.html I suggest to revisit this. Markus From neteler at itc.it Wed Mar 14 14:25:59 2007 From: neteler at itc.it (Markus Neteler) Date: Wed Mar 14 14:26:02 2007 Subject: [GRASS-dev] d.menu, d.ask In-Reply-To: <17911.61202.268293.361881@cerise.gclements.plus.com> References: <17911.5028.813207.357576@cerise.gclements.plus.com> <17911.61202.268293.361881@cerise.gclements.plus.com> Message-ID: <20070314132558.GC25749@bartok.itc.it> On Wed, Mar 14, 2007 at 12:48:18PM +0000, Glynn Clements wrote: > Michael Barton wrote: > > > You can down load it from the GRASS Addons svn server > > > grassaddons_gui_> > > I already got the code with: > > svn co https://grasssvn.itc.it/svn/grassaddons/trunk/grassaddons/gui > > But I just got a bunch of files with no clue what to do with them. Michael, Jachym, please add a Makefile there to simplify installation. Also a README explaining the minimum requirements and, if possible, hints where to get things like CustomTreeCtrl and how to get it into a standard python installation. thanks Markus From paul-grass at stjohnspoint.co.uk Wed Mar 14 14:42:01 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Wed Mar 14 14:42:04 2007 Subject: [GRASS-dev] portable.h elimination In-Reply-To: <17911.58274.497136.710817@cerise.gclements.plus.com> References: <17900.5591.692946.780300@cerise.gclements.plus.com> <1766.85.10.71.67.1173822289.squirrel@geog-pc40.ulb.ac.be> <17911.58274.497136.710817@cerise.gclements.plus.com> Message-ID: On Wed, 14 Mar 2007, Glynn Clements wrote: > > Paul Kelly wrote: > >> For some reason (can't quite remember why) I changed test.c in the past to >> try and get this to work. ISTR someone suggested somewhere extra seeks >> were needed on Windows. > > You need to seek when switching between reading and writing. Windows' > FILE structure only has a single buffer (rather than separate > read/write buffers), so you need to force it to flush/discard any > buffered data. Do you think extra seeks need added anywhere else in the library, or is it just this test program that is affected? >> This is what I changed: > > Can you commit those, please. > >> And with that the output from the test is now: >> >> ==============TEST============= >> gcc -L/c/grass/grass6/dist.i686-pc-mingw32/lib -Wl,--export-dynamic,--enable-runtime-pseudo-reloc -L/c/grass/forgrass/lib -I/c/grass/forgrass/include -g -O2 -I/c/grass/forgrass/include -I/c/grass/forgrass/include -I/c/grass/grass6/dist.i686-pc-mingw32/include -o OBJ.i686-pc-mingw32/test test.c -lgrass_dig2 -lgrass_gis -lgrass_datetime -lxdr -liberty -lws2_32 -lz -lgrass_rtree -lgrass_rtree \ >> -lgrass_gis -lgrass_datetime -lxdr -liberty -lws2_32 -lz -lgrass_datetime -lxdr -liberty -lws2_32 -lz >> cd OBJ.i686-pc-mingw32; PATH=".:/bin:/mingw/bin:/mingw/lib:/c/grass/forgrass/bin:/c/grass/forgrass/lib:/c/tcl/bin:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:/c/Program Files/QuickTime/QTSystem/:/c/grass/forgrass/bin:/c/grass/forgrass/lib:/c/tcl/bin:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:/c/Program Files/QuickTime/QTSystem/:/c/jed09916/bin:/c/grass/grass6/dist.i686-pc-mingw32/lib" ./test; diff ./test.tmp ../test.ok >> Binary files ./test.tmp and ../test.ok differ >> make: *** [OBJ.i686-pc-mingw32/test] Error 1 >> >> i.e. the test files are still different, but it doesn't have lots of >> errors while running. I have no idea if/how that is significant! > > The stream of errors indicates that what was read back doesn't match > what was written, i.e. a problem with low-level I/O. > > The "diff" failure indicates that what was written wasn't what was > expected. This could be a text/binary issue (I don't see $(FMODE_OBJ) > in the link command); it could even be due to differences in > floating-point rounding (even if only the lowest bit of a double is > wrong, the test will still fail). None of those - it was just that I had put the dig_fseek() call in too late - it should have been before the call to fprintf(). With it before fprintf(), now everything works even without bothering about $(FMODE_OBJ) so I have committed the changes to CVS and enabled the test for MinGW in the Makefile. Paul From neteler at itc.it Wed Mar 14 14:54:20 2007 From: neteler at itc.it (Markus Neteler) Date: Wed Mar 14 14:54:22 2007 Subject: [GRASS-dev] make d.zoom aware of d.his wish Message-ID: <20070314135419.GA30217@bartok.itc.it> Hi, when only doing d.his, the d.zoom command doesn't find the maps and pops up the GUI. Would it be possible to change d.zoom accordingly? Or, maybe easier, d.his should advertise the raster maps which were used, to the driver? GRASS 6.3.cvs (nc_spm_02):~ > d.his h=elevation i=elevation_shade GRASS 6.3.cvs (nc_spm_02):~ > d.frame -l frame: full_screen rast: vect: commands: d.erase color=white d.his h_map="elevation" i_map="elevation_shade" I guess that 'rast:' needs to be populated somehow by d.his. Markus From mlennert at club.worldonline.be Wed Mar 14 14:58:36 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Wed Mar 14 14:56:01 2007 Subject: [GRASS-dev] GRASS 7 timeline In-Reply-To: <20070314131901.GB25749@bartok.itc.it> References: <17908.16039.431289.828167@cerise.gclements.plus.com> <20070313185912.2972b68b.hamish_nospam@yahoo.com> <17910.40594.425581.580790@cerise.gclements.plus.com> <20070314200218.1c79ba08.hamish_nospam@yahoo.com> <20070314131901.GB25749@bartok.itc.it> Message-ID: <45F7FF8C.9070104@club.worldonline.be> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 14/03/07 14:19, Markus Neteler wrote: > [merging in Glynn's answer at bottom] > > On Wed, Mar 14, 2007 at 08:02:18PM +1300, Hamish wrote: >> Glynn Clements wrote: >>> Is there an expected timeline for 7.x? >> That is entirely up to the fine folks on this list; I would guess that >> when the time comes, we know & we do it. Maybe then is now? I would not >> object to it happening as soon as the SVN server is up and running. (no >> technical reason for that, just a nice time for it to happen) > > We can seriously think about it once the migration to SVN is > done. > >> my wishes for the GRASS 7.0.0 release >> * native MS windows fully stable and equal >> - worthy of a major point release, if simply for the PR value > > I hope to see major MS-Windows support already in 6.3.0! > At least we were telling so for some months... and not too > much seems to be missing. Well, at this stage Paul and I (whenever work and kids leave me some time) seem to be the only ones actually working on this. If this is such a priority, then more people need to become involved, at least for testing. I have only started a more systematic test drive and have already come up with a whole series of issues (of which some might not be winGRASS related). And this is only using some very basic import/export and display modules... Maybe we should make daily/weekly binary snapshots available so that every person on this list that has access to a windows machine can try to reproduce the last three tasks they did in GNU/Linux, Cygwin or Mac OSX with the native version ? Moritz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF9/+MMiPFf/8qzFYRAtgKAJ9v33qZMWpcPSH7jlzXGg5bch+aegCeMyPc ogZIk22KyaZ+hW3lEf3owYA= =ykoY -----END PGP SIGNATURE----- From mlennert at club.worldonline.be Wed Mar 14 15:17:14 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Wed Mar 14 15:14:30 2007 Subject: [GRASS-dev] GRASS 7 timeline [was: d.menu, d.ask] In-Reply-To: <17911.60737.998513.401787@cerise.gclements.plus.com> References: <17908.16039.431289.828167@cerise.gclements.plus.com> <20070313185912.2972b68b.hamish_nospam@yahoo.com> <17910.40594.425581.580790@cerise.gclements.plus.com> <20070314200218.1c79ba08.hamish_nospam@yahoo.com> <17911.60737.998513.401787@cerise.gclements.plus.com> Message-ID: <45F803EA.5090605@club.worldonline.be> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 14/03/07 13:40, Glynn Clements wrote: > Hamish wrote: > >> That is entirely up to the fine folks on this list; I would guess that >> when the time comes, we know & we do it. Maybe then is now? I would not >> object to it happening as soon as the SVN server is up and running. (no >> technical reason for that, just a nice time for it to happen) >> >> my wishes for the GRASS 7.0.0 release >> * native MS windows fully stable and equal > > For the native Windows version to be fully "equal", monitors need to > be made to work. Even if we ditched all of the programs which require > a monitor (e.g. i.ortho.photo), so long as d.* commands can be used > with a monitor, the absence of monitors will make Windows less than > equal. I would plead for accepting less than equal and not spend much time trying to make monitors work. Moritz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF+APqMiPFf/8qzFYRAoYqAJ9mfXYyGddIXE4adHrADY9QmBR9uQCeJAhc uurWdFT4O7TKoQmLSHgp40Y= =Ugvn -----END PGP SIGNATURE----- From mlennert at club.worldonline.be Wed Mar 14 15:20:18 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Wed Mar 14 15:17:35 2007 Subject: [GRASS-dev] [Fwd: [winGRASS] Re: Can't create new maps or open native winGRASS] Message-ID: <45F804A2.7010206@club.worldonline.be> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It is mails as the one below which make me think that we should publish binaries of the current version of winGRASS which are way better then the one we advertise now (i.e. Huidae's). Moritz - -------- Original Message -------- Subject: [winGRASS] Re: Can't create new maps or open native winGRASS Date: Mon, 12 Mar 2007 17:59:37 +0000 From: Amanda Wintcher Reply-To: arwintcher@juno.com To: wingrass@grass.itc.it References: <45CCBCD1.4010905@juno.com> In case it helps someone else, I seem to have fixed at least part of the problem. In the grass.bat file, the path was pointing to the wrong place for PostgreSQL (I have 8.2 installed, but the original was set to 8.1). So I changed: set PATH=%PATH%;C:\Program Files\PostgreSQL\8.1\bin to set PATH=%PATH%;C:\Program Files\PostgreSQL\8.2\bin. Which seems to have been the culprit. It would appear to work now--I just have to figure out what I am doing! Amanda Wintcher wrote: > I followed the installation instructions at > > http://geni.ath.cx/grass.html#toc2 > > and have edited the bat file as instructed elsewhere. > > I can get as far as the startup window, where it asks which mapset you > want to open or create. Although I have spearfish60 in the right place, > and it recognizes this, when I select it and go to "enter GRASS" the > following happens: > > 1. it starts to open and I get a nice startup screen > 2. an "error in startup script" window opens, which begins: > can't read "parts(n)": no such variable while executing > "MapCanvas::zoom_new $mon $parts(n) $parts(s) $parts(e) $parts(w) > $parts(nsres) $parts(ewres)" (see screenshot for the rest) > > In the cmd window it says: > > WARNING: Attention! > WARNING: Locking is not supported on Windows! > > and then it goes back to the "Welcome to GRASS 6.3.cvs" prompt. > > I hit "OK" the error window, and the whole thing shuts down. > > I've never installed Cygwin, so I don't think that is the problem. I > don't know anything about coding, scripting, etc. so if I need to change > something please explain it very slowly--that is, what file do I look > at, and what do I use to open and edit it (e.g. notepad). > > I installed qGIS as well with the idea that it would act as a front end > for GRASS, and the GRASS tools plugin seems to work just fine. > > Thanks for your help. > > Amanda > > ------------------------------------------------------------------------ > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF+ASiMiPFf/8qzFYRApWPAJ471G9DBivgADOq/MjGL5SufBnOhgCggnaj QR/8juNCGwT/SlGE93kY3I4= =KwxZ -----END PGP SIGNATURE----- -------------- next part -------------- _______________________________________________ winGRASS mailing list winGRASS@grass.itc.it http://grass.itc.it/mailman/listinfo/wingrass From mlennert at club.worldonline.be Wed Mar 14 15:24:04 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Wed Mar 14 15:21:20 2007 Subject: [GRASS-dev] testing native winGRASS In-Reply-To: <45F72779.1060007@o2.pl> References: <2738.85.10.71.67.1173823945.squirrel@geog-pc40.ulb.ac.be> <45F72779.1060007@o2.pl> Message-ID: <45F80584.60608@club.worldonline.be> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 13/03/07 23:36, Maciej Sieczka wrote: > Moritz Lennert wrote: >> Hello, >> >> I have finally started going through the GDF GRASS 6.0 manual and test all >> commands mentioned there in the current CVS winGRASS. A first round of >> results is attached. > > Moritz > > I *guess* the failures you mention, when a module prints many lines to > tcl/tk GUI output, might be related to: > > https://intevation.de/rt/webrt?serial_num=4487 > https://intevation.de/rt/webrt?serial_num=2937 > > Glynn offers some explanations in his last post in the > https://intevation.de/rt/webrt?serial_num=2937. Yes, this seems related. So, a probably general tcl problem, not a win problem... Moritz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF+AWEMiPFf/8qzFYRApcnAJ9n5pQ7U1f0MDWpGplKuK8E5flTmwCeJyic x+VuM/Q0H6FqnILHKtAcczk= =/jdA -----END PGP SIGNATURE----- From mlennert at club.worldonline.be Wed Mar 14 15:29:16 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Wed Mar 14 15:26:29 2007 Subject: [GRASS-dev] Re: testing native winGRASS In-Reply-To: References: <2738.85.10.71.67.1173823945.squirrel@geog-pc40.ulb.ac.be> Message-ID: <45F806BC.6060804@club.worldonline.be> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 13/03/07 23:34, Paul Kelly wrote: > Hello Moritz > > On Tue, 13 Mar 2007, Moritz Lennert wrote: > >> 1) Create location with projection values: location created but mapset >> (other than PERMANENT) invalid > > Could you try the patch below for lib/gis/getl.c and see if GRASS can > then handle the newly created location? I think the problem is the > created location contains Windows line endings in some of the files and > other GRASS functions can't handle them. G_getl2() handles Windows line > endings whereas G_getl() does not. I have a hunch this may apply in many > places. I will try this tonight, but just to make clear what is going wrong: creating the location works and there is a valid PERMANENT mapset created whatever I do, but if (in the console window where you enter the name of the new location) I give a mapset name other than PERMANENT, this mapset is then created (together with PERMANENT), but when I try to enter it, I get an "invalid mapset" error, which is understandable since the mapset directory is empty except for a dbf directory (IIRC). Moritz > > Index: getl.c > =================================================================== > RCS file: /home/grass/grassrepository/grass6/lib/gis/getl.c,v > retrieving revision 2.6 > diff -u -r2.6 getl.c > --- getl.c 12 Nov 2006 04:05:02 -0000 2.6 > +++ getl.c 13 Mar 2007 22:31:02 -0000 > @@ -16,6 +16,8 @@ > > int G_getl ( char *buf, int n, FILE *fd) > { > + return G_getl2 ( buf, n, fd ); > + /* > if (!fgets (buf, n, fd)) > return 0; > > @@ -24,6 +26,7 @@ > *buf = 0; > > return 1; > + */ > } > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF+Aa8MiPFf/8qzFYRAl18AKCXOhyMDJMOAOQMdbI2D8T0xI98lQCfbhuD 3mPFzCfqifeyRuJob7BEUWs= =uGoV -----END PGP SIGNATURE----- From paul-grass at stjohnspoint.co.uk Wed Mar 14 15:48:35 2007 From: paul-grass at stjohnspoint.co.uk (Paul Kelly) Date: Wed Mar 14 15:48:37 2007 Subject: [GRASS-dev] Re: testing native winGRASS In-Reply-To: <45F806BC.6060804@club.worldonline.be> References: <2738.85.10.71.67.1173823945.squirrel@geog-pc40.ulb.ac.be> <45F806BC.6060804@club.worldonline.be> Message-ID: On Wed, 14 Mar 2007, Moritz Lennert wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 13/03/07 23:34, Paul Kelly wrote: >> Hello Moritz >> >> On Tue, 13 Mar 2007, Moritz Lennert wrote: >> >>> 1) Create location with projection values: location created but mapset >>> (other than PERMANENT) invalid >> >> Could you try the patch below for lib/gis/getl.c and see if GRASS can >> then handle the newly created location? I think the problem is the >> created location contains Windows line endings in some of the files and >> other GRASS functions can't handle them. G_getl2() handles Windows line >> endings whereas G_getl() does not. I have a hunch this may apply in many >> places. > > I will try this tonight, but just to make clear what is going wrong: > creating the location works and there is a valid PERMANENT mapset > created whatever I do, but if (in the console window where you enter the > name of the new location) I give a mapset name other than PERMANENT, > this mapset is then created (together with PERMANENT), but when I try to > enter it, I get an "invalid mapset" error, which is understandable since > the mapset directory is empty except for a dbf directory (IIRC). Ah OK. I believe the problem is this in lib/init/mke_mapset.c: /* give the mapset a default window for the entire location */ sprintf(buffer,"cat '%s'/PERMANENT/DEFAULT_WIND > '%s'/'%s'/WIND", location, location, mapset) ; system(buffer) ; but at the minute my mind has gone blank as to the portable way to replace that. I general audit of calls to system() would have caught that if we're able to get round to doing it I suppose. Paul From michael.barton at asu.edu Wed Mar 14 15:50:08 2007 From: michael.barton at asu.edu (Michael Barton) Date: Wed Mar 14 15:50:17 2007 Subject: [GRASS-dev] d.menu, d.ask In-Reply-To: <17911.61202.268293.361881@cerise.gclements.plus.com> Message-ID: On 3/14/07 5:48 AM, "Glynn Clements" wrote: > $ $GISBASE/etc/wx/gism2.py > bash: /opt/grass-6.3.cvs/etc/wx/gism2.py: Permission denied > $ chmod +x $GISBASE/etc/wx/gism2.py > $ $GISBASE/etc/wx/gism2.py > Traceback (most recent call last): > File "/opt/grass-6.3.cvs/etc/wx/gism2.py", line 5, in ? > import wx.lib.customtreectrl as CT > ImportError: No module named customtreectrl > > Presumably I need a specific version of wxWidgets or wxPython? > Glynn, Because the Python/wxPython versions will tend to become defacto 'frozen' as soon as many people start to use this, we're trying to do initial development with the most current stable versions of both. This is currently Python 2.5 and wxPython 2.8.1.1 OTOH, customtreectrl is available as a separate download somewhere (Andrea Gavena is the author I think), released in early 2006. Similarly, the notebook control that we're using (FlatNotebook) was released in October 2006. Both are now included in the main wxPython distribution and provide nice functionality over the older tree and notebook controls that is especially useful in the GRASS context. With respect to installation, I think that J?chym or Martin is planning to produce a regular Python package as soon as we have something that works. About 6 months ago, the GUI actually displayed maps in the Python canvas (to show that it would indeed work). Since that time, the code has undergone significant restructuring and refactoring. In the process, the ability to actually display something has been broken AFAICT. But we're getting close to putting the pieces back together and have some real functionality again. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From michael.barton at asu.edu Wed Mar 14 15:58:22 2007 From: michael.barton at asu.edu (Michael Barton) Date: Wed Mar 14 15:58:30 2007 Subject: [GRASS-dev] GRASS 7 timeline [was: d.menu, d.ask] In-Reply-To: <20070314200218.1c79ba08.hamish_nospam@yahoo.com> Message-ID: This sounds very reasonable in overall approach. Michael On 3/14/07 12:02 AM, "Hamish" wrote: > Glynn Clements wrote: >> Is there an expected timeline for 7.x? > > That is entirely up to the fine folks on this list; I would guess that > when the time comes, we know & we do it. Maybe then is now? I would not > object to it happening as soon as the SVN server is up and running. (no > technical reason for that, just a nice time for it to happen) > > my wishes for the GRASS 7.0.0 release > * native MS windows fully stable and equal > - worthy of a major point release, if simply for the PR value > * wxPython fully implemented for all GUIs > - no or minimal Tcl, for a consistent user experience > keep Tcl as non-default, optional "oldgui" ??? (answer that later) > * no more interactive d.*, xterm GUIs, etc > * centralized $MAPSET/raster/$MAPNAME/element > * more? > - would a new raster format mean a new major point? or ok as long > as lib fns were backwards compatible with the old format? too much > to ask to support both? or r.convert module, like G6's v.convert? > > the raster format changes could mean a time of dual branch development > like we had for Radim+Markus working on 5.1/5.7/6 and most everyone else > working on 5.0/5.4. Markus may have some stern words about that. ;) > > >> If so, does that signify a point at which fundamental changes to the >> graphics architecture can commence? > > I guess we could restate the question as do we want/need a GRASS 6.4 > stable release, or should we continue in devel mode all the way to 7.0? > > (FWIW, I see no current need for a stable 6.4*, but 6.3.0 would be a > nice milestone once winGrass is usable. If no 6.4 is planned, then there > is no need for a new SVN branch for 7.0 devel, we just continue with > 6.3. If there is demand for a 6.4.0, we start a 6.5 branch in SVN and > cull away) > > [*] r.li could be safely backported to 6.2? Tcl GUI updates less so but > we shouldn't abandon them. I guess they will be the day-to-day GUI > during wxPython devel, so post 6.2 Tcl GUI work wouldn't be for nothing. > ?? > > The 6.x problem is not with fundamental changes to the underlying > architecture, that is wide open during a development minor version, and > AFAIAC go for it. The issue is changing the user interface to the > extent that scripts/ books/ tutorials/ training/ data for "GRASS 6" no > longer works with "GRASS 6". So we are free to "get our ducks in a row" > now, and we should do that, we just have to make an effort to minimize > user pain as we go. > > When it is apparent that we have reached the point where the effort to > maintain backwards compatibility is a big time+energy sink, we trigger > the start of GRASS 7 development, without regret. > > >> If not, i.e. if i.ortho.photo *has* to continue to work until such >> time that someone sees fit to write an alternative (if that ever >> happens), then the graphics architecture will forever be limited to a >> Tek4105 emulation, and I may as well give up now. > > I think we can, today, clearly make a list of things that will not be in > GRASS 7. Firstly a list of lib fn families, and secondly a list of > modules. Presumably replacements GUIs for missing modules will come > on-line in proportion to the demand for module's functionality. > > >> IMHO, I don't think that we can wait forever for decent graphics. The >> biggest danger is that the "you can't remove that because someone >> still uses it" problem will end up solving itself when no-one actually >> uses GRASS any more. I'd prefer people to set achievable goals than to >> insist on having everything and ending up with nothing. > > We just have to call it GRASS 7. As that is just a number it is simple to > change. No need to artificially slow down development to keep 6.x alive. > e.g. People with need for GRASS 5.4 can still use that if they want, > without loss of functionality, new devel switching to GRASS 6 hasn't > changed that. And GRASS 7 devel won't hurt those who still want to use > GRASS 6. So no worries. > > > > Hamish > > __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From mlennert at club.worldonline.be Wed Mar 14 16:31:37 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Wed Mar 14 16:28:50 2007 Subject: [GRASS-dev] Re: testing native winGRASS In-Reply-To: References: <2738.85.10.71.67.1173823945.squirrel@geog-pc40.ulb.ac.be> <45F806BC.6060804@club.worldonline.be> Message-ID: <45F81559.6010403@club.worldonline.be> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 14/03/07 15:48, Paul Kelly wrote: > On Wed, 14 Mar 2007, Moritz Lennert wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 13/03/07 23:34, Paul Kelly wrote: >>> Hello Moritz >>> >>> On Tue, 13 Mar 2007, Moritz Lennert wrote: >>> >>>> 1) Create location with projection values: location created but mapset >>>> (other than PERMANENT) invalid >>> >>> Could you try the patch below for lib/gis/getl.c and see if GRASS can >>> then handle the newly created location? I think the problem is the >>> created location contains Windows line endings in some of the files and >>> other GRASS functions can't handle them. G_getl2() handles Windows line >>> endings whereas G_getl() does not. I have a hunch this may apply in many >>> places. >> >> I will try this tonight, but just to make clear what is going wrong: >> creating the location works and there is a valid PERMANENT mapset >> created whatever I do, but if (in the console window where you enter the >> name of the new location) I give a mapset name other than PERMANENT, >> this mapset is then created (together with PERMANENT), but when I try to >> enter it, I get an "invalid mapset" error, which is understandable since >> the mapset directory is empty except for a dbf directory (IIRC). > > Ah OK. I believe the problem is this in lib/init/mke_mapset.c: > > /* give the mapset a default window for the entire location */ > sprintf(buffer,"cat '%s'/PERMANENT/DEFAULT_WIND > '%s'/'%s'/WIND", > location, location, mapset) ; > system(buffer) ; Glynn has taught me about the rename() and remove() function, but I haven't come upon a copy() function, yet... Probably some combination of fscanf & fwrite... Or getc & putc : http://www.java2s.com/Code/C/File/Copyafile.htm If it really doesn't exist, shouldn't we implement G_fcopy() or something like that. Possibly in lib/gis/copy.c ? > > but at the minute my mind has gone blank as to the portable way to > replace that. I general audit of calls to system() would have caught > that if we're able to get round to doing it I suppose. This might be priority to my testing via the GDF GRASS Tutorial, so I'll try to do that first. Should all system calls be replaced by G_system ? Should any system / G_sytem calls be avoided ? Or should we check which system() calls use functions which might not exist in Windows ? Moritz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF+BVZMiPFf/8qzFYRAq90AJ9Rsy9ML9EfO2bLNNX7LSonQVIPFQCePXT4 AswvK5NfCrCv3kDLRCJp8Lg= =4voq -----END PGP SIGNATURE----- From neteler at itc.it Wed Mar 14 17:23:13 2007 From: neteler at itc.it (Markus Neteler) Date: Wed Mar 14 17:23:15 2007 Subject: [GRASS-dev] GRASS 7 timeline In-Reply-To: <45F7FF8C.9070104@club.worldonline.be> References: <17908.16039.431289.828167@cerise.gclements.plus.com> <20070313185912.2972b68b.hamish_nospam@yahoo.com> <17910.40594.425581.580790@cerise.gclements.plus.com> <20070314200218.1c79ba08.hamish_nospam@yahoo.com> <20070314131901.GB25749@bartok.itc.it> <45F7FF8C.9070104@club.worldonline.be> Message-ID: <20070314162313.GE31873@bartok.itc.it> On Wed, Mar 14, 2007 at 02:58:36PM +0100, Moritz Lennert wrote: > On 14/03/07 14:19, Markus Neteler wrote: > > I hope to see major MS-Windows support already in 6.3.0! > > At least we were telling so for some months... and not too > > much seems to be missing. > > Well, at this stage Paul and I (whenever work and kids leave me some > time) seem to be the only ones actually working on this. If this is such > a priority, then more people need to become involved, at least for testing. I am sure that more people are willing to test, but most of them won't be able to compile it from scratch. > I have only started a more systematic test drive and have already come > up with a whole series of issues (of which some might not be winGRASS > related). And this is only using some very basic import/export and > display modules... > > Maybe we should make daily/weekly binary snapshots available so that > every person on this list that has access to a windows machine can try > to reproduce the last three tasks they did in GNU/Linux, Cygwin or Mac > OSX with the native version ? This would be great. Markus From glynn at gclements.plus.com Wed Mar 14 18:07:14 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Mar 14 18:07:16 2007 Subject: [GRASS-dev] portable.h elimination In-Reply-To: References: <17900.5591.692946.780300@cerise.gclements.plus.com> <1766.85.10.71.67.1173822289.squirrel@geog-pc40.ulb.ac.be> <17911.58274.497136.710817@cerise.gclements.plus.com> Message-ID: <17912.11202.24603.634946@cerise.gclements.plus.com> Paul Kelly wrote: > >> For some reason (can't quite remember why) I changed test.c in the past to > >> try and get this to work. ISTR someone suggested somewhere extra seeks > >> were needed on Windows. > > > > You need to seek when switching between reading and writing. Windows' > > FILE structure only has a single buffer (rather than separate > > read/write buffers), so you need to force it to flush/discard any > > buffered data. > > Do you think extra seeks need added anywhere else in the library, or is it > just this test program that is affected? I would think that most uses of the diglib I/O use either read-only or write-only streams, so shouldn't be affected. And programs which do both will normally follow a pattern of seeking followed by a sequence of reads or a sequence of writes. Writing something then reading whatever happens to follow what you've just written seems unlikely. Reading then writing seems more likely. Also, this isn't specific to the diglib I/O, but anything using ANSI stdio. > > The "diff" failure indicates that what was written wasn't what was > > expected. This could be a text/binary issue (I don't see $(FMODE_OBJ) > > in the link command); it could even be due to differences in > > floating-point rounding (even if only the lowest bit of a double is > > wrong, the test will still fail). > > None of those - it was just that I had put the dig_fseek() call in too > late - it should have been before the call to fprintf(). With it before > fprintf(), now everything works even without bothering about $(FMODE_OBJ) > so I have committed the changes to CVS and enabled the test for MinGW in > the Makefile. I've noticed that test.ok doesn't include any '\n' characters, so EOL conversions won't affect the test case. But, in general, every program needs to link against $(FMODE_OBJ). Those which use the cmd/inter/etc targets from Module.make are automatically covered, but anything with an explicit linking command needs to handle this manually. It might be worth adding a make function for linking executables to e.g. Rules.make, so that we don't have to deal with this issue (and similar issues) in dozens of individual Makefiles. There are quite a lot of programs which aren't built with the standard cmd/inter/etc targets. -- Glynn Clements From glynn at gclements.plus.com Wed Mar 14 18:15:15 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Mar 14 18:15:17 2007 Subject: [GRASS-dev] make d.zoom aware of d.his wish In-Reply-To: <20070314135419.GA30217@bartok.itc.it> References: <20070314135419.GA30217@bartok.itc.it> Message-ID: <17912.11683.188475.326400@cerise.gclements.plus.com> Markus Neteler wrote: > when only doing d.his, the d.zoom command doesn't > find the maps and pops up the GUI. Would it be possible to > change d.zoom accordingly? Or, maybe easier, d.his > should advertise the raster maps which were used, > to the driver? > > GRASS 6.3.cvs (nc_spm_02):~ > d.his h=elevation i=elevation_shade > GRASS 6.3.cvs (nc_spm_02):~ > d.frame -l > frame: full_screen > rast: > vect: > commands: > d.erase color=white > d.his h_map="elevation" i_map="elevation_shade" > > I guess that 'rast:' needs to be populated somehow by d.his. d.zoom should use the commands: list. Trying to segregate everything into raster/vector simply doesn't work. d.rgb fails similarly, and there are almost certainly other cases. Also, all vector maps are redrawn with "d.vect map=", ignoring the 25 options and 3 flags which may have been used when originally drawing the map. At least d.rast only has 3 options and 2 flags (which are similarly ignored). -- Glynn Clements From glynn at gclements.plus.com Wed Mar 14 18:16:43 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Mar 14 18:16:54 2007 Subject: [GRASS-dev] [Fwd: [winGRASS] Re: Can't create new maps or open native winGRASS] In-Reply-To: <45F804A2.7010206@club.worldonline.be> References: <45F804A2.7010206@club.worldonline.be> Message-ID: <17912.11771.4099.679042@cerise.gclements.plus.com> Moritz Lennert wrote: > It is mails as the one below which make me think that we should publish > binaries of the current version of winGRASS which are way better then > the one we advertise now (i.e. Huidae's). Agreed; I didn't realise that the download page still pointed to that version. -- Glynn Clements From glynn at gclements.plus.com Wed Mar 14 18:36:05 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Mar 14 18:36:10 2007 Subject: [GRASS-dev] GRASS 7 timeline In-Reply-To: <20070314131901.GB25749@bartok.itc.it> References: <17908.16039.431289.828167@cerise.gclements.plus.com> <20070313185912.2972b68b.hamish_nospam@yahoo.com> <17910.40594.425581.580790@cerise.gclements.plus.com> <20070314200218.1c79ba08.hamish_nospam@yahoo.com> <20070314131901.GB25749@bartok.itc.it> Message-ID: <17912.12933.57372.799028@cerise.gclements.plus.com> Markus Neteler wrote: > > my wishes for the GRASS 7.0.0 release > > * native MS windows fully stable and equal > > - worthy of a major point release, if simply for the PR value > > I hope to see major MS-Windows support already in 6.3.0! > At least we were telling so for some months... and not too > much seems to be missing. There's a difference between "support" and "fully ... equal". Monitors don't work, and several programs won't work without them. OTOH, I've just modified v.digit not to require the form library (which doesn't work on native Windows), so hopefully that should work now (or, at least, soon; it needs testing first). > > If no 6.4 is planned, then there > > is no need for a new SVN branch for 7.0 devel, we just continue with > > 6.3. If there is demand for a 6.4.0, we start a 6.5 branch in SVN and > > cull away) > > In order to maintain the history, we have to move the entire CVS to > SVN first. Means, that 6.3.0 could come from SVN if the winGRASS port > completion takes more months (hopefully not). That depends upon how "completion" is defined. Most of the critical functionality is available, assuming that you can accept gis.m as a substitute for using d.* with monitors, but there are plenty of dark corners with some rather hard-to-port code (mostly in the imagery directory). > > > If not, i.e. if i.ortho.photo *has* to continue to work until such > > > time that someone sees fit to write an alternative (if that ever > > > happens), then the graphics architecture will forever be limited to a > > > Tek4105 emulation, and I may as well give up now. > > I think that it is our policy to not discontinue modules in a release > cycle. So i.ortho.photo should remain in 6.x. Right; but any significant changes to the graphics architecture are essentially stalled in the meantime. > Brad has proposed a series of improvements to i.ortho.photo and AFAIK > already implemented most of them. Why don't we take a look at these? The i.ortho.photo issue is that it requires a monitor. Changing that involves a significant re-write (i.e. separate the functionality from the interface, and re-implement the interface in Tcl/Tk or wxPython). AIUI, Brad was planning on doing this to i.class first, as it needs essentially the same treatment, and i.class is a signficantly simpler program than i.ortho.photo. The i.class changes haven't happened yet, so having the i.ortho.photo re-write completed is still a way off. > > I think we can, today, clearly make a list of things that will not be in > > GRASS 7. Firstly a list of lib fn families, and secondly a list of > > modules. Presumably replacements GUIs for missing modules will come > > on-line in proportion to the demand for module's functionality. > > This list should go into the Wiki, here it's quickly getting lost. You can get the list of "problem" modules from the SQL database generated by tools/sql.sh: grass=> SELECT DISTINCT program FROM prog_imp WHERE symbol LIKE 'R\\_get\\_location%' ; program --------------------- bin/d.barscale bin/d.extract bin/d.geodesic bin/d.legend bin/d.measure bin/d.nviz bin/d.path bin/d.profile bin/d.rast.edit bin/d.rhumbline bin/d.text.freetype bin/d.text.new bin/d.what.rast bin/d.what.vect bin/d.where bin/d.zoom bin/i.class bin/i.points bin/i.vpoints bin/r.digit bin/r.le.setup bin/r.profile etc/i.ask etc/photo.2image etc/photo.2target (25 rows) Some of these only make minor use of the mouse (e.g. "d.barscale -m"), in which case you only lose the mouse-specific functionality without a monitor. Others (i.*, d.rast.edit, r.digit) need a major re-write. -- Glynn Clements From glynn at gclements.plus.com Wed Mar 14 18:47:40 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Mar 14 18:47:56 2007 Subject: [GRASS-dev] Re: testing native winGRASS In-Reply-To: <45F81559.6010403@club.worldonline.be> References: <2738.85.10.71.67.1173823945.squirrel@geog-pc40.ulb.ac.be> <45F806BC.6060804@club.worldonline.be> <45F81559.6010403@club.worldonline.be> Message-ID: <17912.13628.139157.395247@cerise.gclements.plus.com> Moritz Lennert wrote: > >>>> 1) Create location with projection values: location created but mapset > >>>> (other than PERMANENT) invalid > >>> > >>> Could you try the patch below for lib/gis/getl.c and see if GRASS can > >>> then handle the newly created location? I think the problem is the > >>> created location contains Windows line endings in some of the files and > >>> other GRASS functions can't handle them. G_getl2() handles Windows line > >>> endings whereas G_getl() does not. I have a hunch this may apply in many > >>> places. > >> > >> I will try this tonight, but just to make clear what is going wrong: > >> creating the location works and there is a valid PERMANENT mapset > >> created whatever I do, but if (in the console window where you enter the > >> name of the new location) I give a mapset name other than PERMANENT, > >> this mapset is then created (together with PERMANENT), but when I try to > >> enter it, I get an "invalid mapset" error, which is understandable since > >> the mapset directory is empty except for a dbf directory (IIRC). > > > > Ah OK. I believe the problem is this in lib/init/mke_mapset.c: > > > > /* give the mapset a default window for the entire location */ > > sprintf(buffer,"cat '%s'/PERMANENT/DEFAULT_WIND > '%s'/'%s'/WIND", > > location, location, mapset) ; > > system(buffer) ; > > Glynn has taught me about the rename() and remove() function, but I > haven't come upon a copy() function, yet... There isn't one. There isn't even a universal definition of "copying" a file (e.g., what happens if the target already exists, does copying a symlink create a symlink or a copy of the file it points to, etc). > Probably some combination of fscanf & fwrite... > Or getc & putc : http://www.java2s.com/Code/C/File/Copyafile.htm > > If it really doesn't exist, shouldn't we implement G_fcopy() or > something like that. Possibly in lib/gis/copy.c ? That could be a useful addition. But in the case of copying PERMANENT/DEFAULT_WIND to /WIND file, I'd suggest trying either G_get_default_window() and G_put_window() or G__get_window() and G__put_window() first. > > but at the minute my mind has gone blank as to the portable way to > > replace that. I general audit of calls to system() would have caught > > that if we're able to get round to doing it I suppose. > > This might be priority to my testing via the GDF GRASS Tutorial, so I'll > try to do that first. > > Should all system calls be replaced by G_system ? Should any system / > G_sytem calls be avoided ? Or should we check which system() calls use > functions which might not exist in Windows ? Avoid system() and G_system() equally. G_system() is almost identical to system(), except that it appears to work around a signal handling bug in some ancient system() implementations. Ditto for G_popen(). If you need to invoke an external program, G_spawn() or G_spawn_ex() are preferable (although G_spawn_ex() hasn't been ported to Windows, and hasn't really been tested). The advantage of the spawn.c functions is that they don't involve a shell, so you don't have any issues regarding quoting arguments. But the only external programs which should be spawned are those which are part of GRASS or were specified by the user. Anything else is unlikely to exist on all platforms. -- Glynn Clements From mlennert at club.worldonline.be Wed Mar 14 18:52:58 2007 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Wed Mar 14 18:50:07 2007 Subject: [GRASS-dev] GRASS 7 timeline In-Reply-To: <17912.12933.57372.799028@cerise.gclements.plus.com> References: <17908.16039.431289.828167@cerise.gclements.plus.com> <20070313185912.2972b68b.hamish_nospam@yahoo.com> <17910.40594.425581.580790@cerise.gclements.plus.com> <20070314200218.1c79ba08.hamish_nospam@yahoo.com> <20070314131901.GB25749@bartok.itc.it> <17912.12933.57372.799028@cerise.gclements.plus.com> Message-ID: <45F8367A.1030809@club.worldonline.be> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 14/03/07 18:36, Glynn Clements wrote: > Markus Neteler wrote: > >>> my wishes for the GRASS 7.0.0 release >>> * native MS windows fully stable and equal >>> - worthy of a major point release, if simply for the PR value >> I hope to see major MS-Windows support already in 6.3.0! >> At least we were telling so for some months... and not too >> much seems to be missing. > > There's a difference between "support" and "fully ... equal". > > Monitors don't work, and several programs won't work without them. > > OTOH, I've just modified v.digit not to require the form library > (which doesn't work on native Windows), so hopefully that should work > now (or, at least, soon; it needs testing first). I've done some superficial testing which did not show any problems. But I agree that it needs _more_ testing ;-) Moritz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF+DZ6MiPFf/8qzFYRAr3HAKCAggKQxve1Q5Mt7AUN8a3DQECFxwCgmE73 1LPQSm0cyDrnnHgdqt2TwhQ= =a2B1 -----END PGP SIGNATURE----- From tutey at o2.pl Wed Mar 14 18:59:30 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Wed Mar 14 18:59:33 2007 Subject: [GRASS-dev] make install fails with 6.3 CVS In-Reply-To: <17911.57437.443171.114588@cerise.gclements.plus.com> References: <45F70FE2.4030403@o2.pl> <17911.57437.443171.114588@cerise.gclements.plus.com> Message-ID: <45F83802.5030107@o2.pl> Glynn Clements wrote: > Maciej Sieczka wrote: > >> Current 6.3 CVS builds fine, but on make install a bunch of: >> >> tar: path/to/file: file changed as we read it >> >> is issued (full log of make install is attached). > I'm guessing that if you don't specify --prefix, the configure script > isn't substituting the default prefix until after we've used it. I > just need to quote ${prefix} so that it doesn't get substituted. You fixed it. Thanks. Maciek From glynn at gclements.plus.com Wed Mar 14 19:02:32 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Mar 14 19:02:34 2007 Subject: [GRASS-dev] v.digit update Message-ID: <17912.14520.866555.60372@cerise.gclements.plus.com> I've modified v.digit so that it no longer requires the form library (by incorporating the form code directly into v.digit). Let me know if there are any problems. With this change, it should be fully functional on native Windows (the standalone form utility doesn't work there). -- Glynn Clements From tutey at o2.pl Wed Mar 14 19:10:05 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Wed Mar 14 19:10:10 2007 Subject: [GRASS-dev] Re: [GRASS-user] Re: grassuser Digest, Vol 11, Issue 18 In-Reply-To: <1173861250.3888.3.camel@linux-a46z.site> References: <200703140446.l2E4k0ra000476@grass.itc.it> <1173861250.3888.3.camel@linux-a46z.site> Message-ID: <45F83A7D.2080100@o2.pl> Jorge Echeverri wrote: > Hi Maciek, > > I got the right tip already. This error message was caused by a blank > line at the end of the file. That's why despite of the error the data > were read correctly. This is cool. Still, there is a bug in v.in.ascii in 6.2.x that using -n switch has no effect. v.in.ascii in 6.2.x behaves kind of like if -n was always set, thus any garbage in the header is ignored automaticaly. In 6.3 however, if you have garbage in the header section, you must use -n. Otherwise v.in.ascii quits with an error, which is correct bahaviour and 6.2 be should be fixed in this regard. I really have checked this. Please read my comment dated 2007-03-13 20:07 on http://wald.intevation.org/tracker/index.php?func=detail&aid=328&group_id=21&atid=204 Maciek From michael.barton at asu.edu Wed Mar 14 19:16:32 2007 From: michael.barton at asu.edu (Michael Barton) Date: Wed Mar 14 19:16:59 2007 Subject: [GRASS-dev] GRASS 7 timeline In-Reply-To: <17912.12933.57372.799028@cerise.gclements.plus.com> Message-ID: This is actually pretty good news from one viewpoint. All the commands below now have all or most of their interactive functionality replicated in TckTk except for bin/d.path bin/d.rast.edit (you are fixing now) bin/i.class (a work around is to create training areas in v.digit) bin/r.digit (a pretty primitive module anyway; v.digit+v.to.rast is better) bin/r.le.setup (becoming replaced by r.li) etc/photo.2image etc/photo.2target Michael On 3/14/07 10:36 AM, "Glynn Clements" wrote: > grass=> SELECT DISTINCT program FROM prog_imp WHERE symbol LIKE > 'R\\_get\\_location%' ; > program > --------------------- > bin/d.barscale > bin/d.extract > bin/d.geodesic > bin/d.legend > bin/d.measure > bin/d.nviz > bin/d.path > bin/d.profile > bin/d.rast.edit > bin/d.rhumbline > bin/d.text.freetype > bin/d.text.new > bin/d.what.rast > bin/d.what.vect > bin/d.where > bin/d.zoom > bin/i.class > bin/i.points > bin/i.vpoints > bin/r.digit > bin/r.le.setup > bin/r.profile > etc/i.ask > etc/photo.2image > etc/photo.2target > (25 rows) > > Some of these only make minor use of the mouse (e.g. "d.barscale -m"), > in which case you only lose the mouse-specific functionality without a > monitor. Others (i.*, d.rast.edit, r.digit) need a major re-write. __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton From tutey at o2.pl Wed Mar 14 19:29:46 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Wed Mar 14 19:29:49 2007 Subject: [GRASS-dev] v.breach and v.line.center GRASS addons In-Reply-To: <200703131846.42166.dylan.beaudette@gmail.com> References: <45F7043A.7020600@o2.pl> <200703131846.42166.dylan.beaudette@gmail.com> Message-ID: <45F83F1A.80608@o2.pl> Dylan Beaudette wrote: > Great work Maciej! > > On Tuesday 13 March 2007 13:06, Maciej Sieczka wrote: >> Hi >> >> I have submitted 2 new scripts for GRASS 6.x to GRASS WIKI >> http://grass.gdf-hannover.de/wiki/GRASS_AddOns: >> >> v.line.center creates a points vector map with each point located in >> the middle of the length of one input vector line. > > So this script locates a line's midpoint, and puts a new point there? Yes. > Does this point have the same attributes as the line which was used as the input? It does not copy the attributes (I didn't need that and had no time for that), but it preserves the category numbers. And since there is one output point per one input line, you can use the db.copy and v.db.connect to attach a table of the input vector to it. Any layer can be used for input. But due to v.segment, the output will always be in layer 1. I guess v.category option=chlayer could help here, if needed. There is a brief manpage provided with the script. >> v.breach creates vector maps of lines and points of continously >> lowering elevation down the input watercourses, based on the input >> raster DEM. >> >> >> >> v.line.center is a simple self-explanatory tool. >> >> v.breach is more complex. It is similar to r.carve -n, with the >> following differences: >> >> 1. It takes the direction of input vector lines into account; which >> means it is less prone to artifacts in the input DEM but more demanding >> to input watercourses. As a result you can breach DEM even against the >> slope, if that's needed ;). > > cool. any examples yet? Nope. I have tested it and it worked. Let me know in case of any problems. >> 2. It does not breach the DEM itself, but outputs vector points which >> have the breached elevation attribute stored in the table. These points >> can be used as additional data for interpolating more hydrologicaly >> sound DEM from scratch, or rasterized and burned into the input DEM >> manually (v.to.rast, r.mapcalc). >> >> 3. It also outputs vector lines, which are the input vector >> watercourses segmented one segment per each DEM cell through which a >> given input watercourse flows. Those segments have the breached >> elevation attribute same as the output vector points. I needed such >> output for my work. Maybe it will be of some use for others. >> >> 4. It is way slower than r.carve. Shell (I have got rid of bashisms I >> hope) + Awk + standard UNIX tools. >> >> See the v.breach manual for more details. > Did this approach allow you to use RST in complex terrain with drainage > enforcement- to create a better DEM than was previously possible? I recall > severall discussions pertaining to the creation of DEM from difficult input > points, specifically with the RST interpolator. I haven't tried it with RST interpolator. > Looking forward to trying these new modules soon, Cheers! Please drop me line how it went. A note which I forgot to add previously: v.breach is EXTREMELY verbose. I did not have time for testing how the silent flag and GRASS variables for verbosity control would affect the module performance in GRASS 6.2.1. I seem to remember that not all the verbosity control measures are available inb 6.2.1 which are 6.3 (I use 6.3 in my daily work). I will be grateful for suggestions which of the verbosity control stuff I could use in v.breach not to break it for 6.2.1, or if there is actaully nothing to be affraid of. Maciek From glynn at gclements.plus.com Wed Mar 14 19:49:31 2007 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed Mar 14 19:49:34 2007 Subject: [GRASS-dev] d.menu, d.ask In-Reply-To: <17910.40594.425581.580790@cerise.gclements.plus.com> References: <17908.16039.431289.828167@cerise.gclements.plus.com> <20070313185912.2972b68b.hamish_nospam@yahoo.com> <17910.40594.425581.580790@cerise.gclements.plus.com> Message-ID: <17912.17339.838902.2555@cerise.gclements.plus.com> Glynn Clements wrote: > > arrows aren't critical; > > It isn't whether they're critical. If they're even *useful*, I can add > them easily enough (although it would be preferable if the aspect map > was given as a command-line option, otherwise I need to add a map > browser). I've done this (the fact that the Tk canvas' line objects have a -arrow option made it quite simple). > > updated colors would be nice. > > Right now, there doesn't appear to be any simple way to determine the > colour for a specific category from outside of C. > > The Tcl/Tk d.rast.edit gets the categories for the map being edited > from r.out.ascii, and the colours from r.out.ppm. Thus, it knows the > colour for each category (or FP value) which actually occurs in the > original map. > > If you decide to set a cell to a category which wasn't already in use, > it has no idea what colour it should be, and (AFAICT) no simpler way > to find out than: > > $ r.mapcalc "$tempmap = $newval" > $ r.colors $tempmap rast=$inmap > $ r.out.ppm $tempmap out=$tempfile > $ g.remove rast=$tempmap > > % image create photo tempimg -file $tempfile > % set rgb [tempimg get 0 0] > % image delete tempimg > % file delete $tempfile > > Which is incredibly inefficient (and possibly error-prone). In spite of that, I've added the above (with the enhancement that it sets the region to 1x1 first), so previously-unused category should also show the correct colour. The major outstanding issue is whether d.rast.edit needs to be able to pan around the map while it's running, or whether it's sufficient to use a sequence of d.rast.edit commands interleaved with d.zoom or g.region commands. -- Glynn Clements From twiens at interbaun.com Wed Mar 14 21:00:59 2007 From: twiens at interbaun.com (Trevor Wiens) Date: Wed Mar 14 20:55:56 2007 Subject: [GRASS-dev] New directional buffering module or modified v.buffer Message-ID: <20070314140059.2fdc9a8f@localhost.localdomain> I posted a question some time ago about directional or differential buffering. I've managed to resolve my bugs and am now unsure what is the best way to incorporate this code back into GRASS. I assume it is desirable as I assume others may find it useful from time to time. Largely what I did is modify v.buffer to work with an ellipse rather than a circle for buffering (you will recall that a circle is actually just a special case of an ellipse), so that amount of code changed is minimal. I did however have to replicate some of the code in Vlib/buffer.c to achieve this. I know that for actual incorporation, this is a bad thing. In terms of interface, the scale attribute has been replaced with nscale, sscale, escale, and wscale for north, south .... If the scale values are all the same (eg 1.0) then it gives the same result as v.buffer does now. But when they are different it uses the angle from the source line in the formula of an ellipse to calculate distance using the two appropriate cardinal scale values. Now I could create separate versions of the needed functions in buffer.c or create a single modified version. In this case v.buffer would simply be modified and no new module would need to be created. I could however create a separate module called for example v.buffer.ellipsoid. My guess is that we don't really want the code base to grow without good reason, so it is probably best to modify the existing routines. Since I don't really like messing with Vlib, I can write my modifications such that if the scale values are all the same, the original code is executed, just in case there is something odd that I've not found in my testing. Now I seem to have messed up my CVS access so once I get things in condition to commit, I'll need someone to do it on my behalf. 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 rez at touchofmadness.com Wed Mar 14 21:01:48 2007 From: rez at touchofmadness.com (Brad Douglas) Date: Wed Mar 14 21:01:56 2007 Subject: [GRASS-dev] Re: [GRASS-user] Compiling grass 6.2.1: i.class error In-Reply-To: <17911.58994.858868.462335@cerise.gclements.plus.com> References: <17900.51141.833484.448599@cerise.gclements.plus.com> <17905.41116.200524.360228@cerise.gclements.plus.com> <17910.53187.37429.30986@cerise.gclements.plus.com> <20070314152956.44294ac0.hamish_nospam@yahoo.com> <1173844048.28983.71.camel@devel> <17911.58994.858868.462335@cerise.gclements.plus.com> Message-ID: <1173902508.28983.90.camel@devel> On Wed, 2007-03-14 at 12:11 +0000, Glynn Clements wrote: > Brad Douglas wrote: > > > > > Every other --without-* switch should work without requiring > > > > additional effort from the user, but curses is currently sufficiently > > > > ingrained that making --without-curses work nicely is too much effort > > > > for a relatively obscure usage case. > > > > > > ./configure --help > > > ... > > > --with-glw support GLw functionality (default: no) > > > ... > > > --with-glw-includes=DIRS > > > GLw include files are in DIRS > > > --with-glw-libs=DIRS GLw library files are in DIRS > > > > > > > > > Is GLw still relevant? If not, let's remove it. > > > > Can we add --with-motif* to the list? > > It's used by xganim, which is still compiled if you use --with-motif. I was under the impression that xganim would be going away. > > And --with-readline* for good measure? > > Why? Some people seem to want that functionality in r.mapcalc. I don't recall any significant replies when you asked about it awhile ago other than me mentioning that I have used it before (but was not necessary). I could be wrong. -- Brad Douglas KB8UYR/6 Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 From dylan.beaudette at gmail.com Wed Mar 14 21:55:15 2007 From: dylan.beaudette at gmail.com (Dylan Beaudette) Date: Wed Mar 14 21:54:35 2007 Subject: [GRASS-dev] New directional buffering module or modified v.buffer In-Reply-To: <20070314140059.2fdc9a8f@localhost.localdomain> References: <20070314140059.2fdc9a8f@localhost.localdomain> Message-ID: <200703141355.15467.dylan.beaudette@gmail.com> On Wednesday 14 March 2007 13:00, Trevor Wiens wrote: > I posted a question some time ago about directional or differential > buffering. I've managed to resolve my bugs and am now unsure what is the > best way to incorporate this code back into GRASS. I assume it is > desirable as I assume others may find it useful from time to time. Hi Trevor. Can you elaborate on what was causing the 'spikes' in your previously posted version? > Largely what I did is modify v.buffer to work with an ellipse rather > than a circle for buffering (you will recall that a circle is actually > just a special case of an ellipse), so that amount of code changed is > minimal. I did however have to replicate some of the code in > Vlib/buffer.c to achieve this. I know that for actual incorporation, > this is a bad thing. > > In terms of interface, the scale attribute has been replaced with > nscale, sscale, escale, and wscale for north, south .... If the scale > values are all the same (eg 1.0) then it gives the same result as > v.buffer does now. But when they are different it uses the angle from > the source line in the formula of an ellipse to calculate distance using > the two appropriate cardinal scale values. > > Now I could create separate versions of the needed functions in > buffer.c or create a single modified version. In this case v.buffer > would simply be modified and no new module would need to be created. I > could however create a separate module called for example > v.buffer.ellipsoid. > > My guess is that we don't really want the code base to grow > without good reason, so it is probably best to modify the > existing routines. Since I don't really like messing with Vlib, I can > write my modifications such that if the scale values are all the same, > the original code is executed, just in case there is something odd that > I've not found in my testing. Although I am not a developer, it seems that modifying the buffer.c functions (pending thorough testing) would be the best long-term strategy. These extensions to simple GIS functionality are a great asset to GRASS. > Now I seem to have messed up my CVS access so once I get things in > condition to commit, I'll need someone to do it on my behalf. > > T cheers, -- Dylan Beaudette Soils and Biogeochemistry Graduate Group University of California at Davis 530.754.7341 From hmitaso at unity.ncsu.edu Wed Mar 14 22:29:00 2007 From: hmitaso at unity.ncsu.edu (Helena Mitasova) Date: Wed Mar 14 22:29:10 2007 Subject: [GRASS-dev] Re: [GRASS-user] Compiling grass 6.2.1: i.class error In-Reply-To: <1173902508.28983.90.camel@devel> References: <17900.51141.833484.448599@cerise.gclements.plus.com> <17905.41116.200524.360228@cerise.gclements.plus.com> <17910.53187.37429.30986@cerise.gclements.plus.com> <20070314152956.44294ac0.hamish_nospam@yahoo.com> <1173844048.28983.71.camel@devel> <17911.58994.858868.462335@cerise.gclements.plus.com> <1173902508.28983.90.camel@devel> Message-ID: <27F73CDC-AC4E-4698-B9E6-510B40414BE3@unity.ncsu.edu> Helena Mitasova Dept. of Marine, Earth and Atm. Sciences 1125 Jordan Hall, NCSU Box 8208, Raleigh NC 27695 http://skagit.meas.ncsu.edu/~helena/ On Mar 14, 2007, at 4:01 PM, Brad Douglas wrote: > On Wed, 2007-03-14 at 12:11 +0000, Glynn Clements wrote: >> Brad Douglas wrote: >> >>>>> Every other --without-* switch should work without requiring >>>>> additional effort from the user, but curses is currently >>>>> sufficiently >>>>> ingrained that making --without-curses work nicely is too much >>>>> effort >>>>> for a relatively obscure usage case. >>>> >>>> ./configure --help >>>> ... >>>> --with-glw support GLw functionality (default: no) >>>> ... >>>> --with-glw-includes=DIRS >>>> GLw include files are in DIRS >>>> --with-glw-libs=DIRS GLw library files are in DIRS >>>> >>>> >>>> Is GLw still relevant? If not, let's remove it. >>> >>> Can we add --with-motif* to the list? >> >> It's used by xganim, which is still compiled if you use --with-motif. > > I was under the impression that xganim would be going away. PLEASE, PLEASE do not remove xganim before there is an equaly easy to use, fast replacement. I don't know about any other other tool for visually analyzing outputs of dynamic models (easily 20-50 rasters), especially when you are looking for a problem in data or algorithm. Same for r.digit - it provides a simple and fast tool to create for example raster mask and similar tasks - that is much simpler than doing v.digit and v.to.rast. We have already removed site format making some tasks that were easy to do much more difficult or even impossible, without making sure that the new vector format offers the same capabilities so let us not repeat the same mistake, Helena > >>> And --with-readline* for good measure? >> >> Why? Some people seem to want that functionality in r.mapcalc. > > I don't recall any significant replies when you asked about it awhile > ago other than me mentioning that I have used it before (but was not > necessary). I could be wrong. > > > -- > Brad Douglas KB8UYR/6 > Address: 37.493,-121.924 / WGS84 National Map Corps #TNMC-3785 > > _______________________________________________ > grass-dev mailing list > grass-dev@grass.itc.it > http://grass.itc.it/mailman/listinfo/grass-dev From tutey at o2.pl Wed Mar 14 22:30:13 2007 From: tutey at o2.pl (Maciej Sieczka) Date: Wed Mar 14 22:30:17 2007 Subject: [GRASS-dev] New directional buffering module or modified v.buffer In-Reply-To: <20070314140059.2fdc9a8f@localhost.localdomain> References: <20070314140059.2fdc9a8f@localhost.localdomain> Message-ID: <45F86965.4050105@o2.pl> Trevor Wiens wrote: > I posted a question some time ago about directional or differential > buffering. I've managed to resolve my bugs and am now unsure what is the > best way to incorporate this code back into GRASS. I assume it is > desirable as I assume others may find it useful from time to time. Trevor, Sure, sounds interesting! I'm also hoping that your v.buffer modification will not suffer from the bug v.buffer does. Can you try creating a vector in a following way, $ 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 reproduce the following 2 commands with v.buffer.ellipsoid: $ v.buffer ditch_1205 out=ditch_1205_b1 type=area buffer=1 $ v.buffer ditch_1205 out=ditch_1205_b4 type=area buffer=4 and let us know if the resulting buffers are OK? Most folks who tried it (actually, everyone who reported, besides Hamish) confirmed the output of v.buffer was bad. If v.buffer.ellipsoid has this problem fixed, it would be great news and I'd say that it should replace v.buffer then, if possible. Cheers Maciek From twiens at interbaun.com Wed Mar 14 23:11:43 2007 From: twiens at interbaun.com (Trevor Wiens) Date: Wed Mar 14 23:06:40 2007 Subject: [GRASS-dev] New directional buffering module or modified v.buffer In-Reply-To: <200703141355.15467.dylan.beaudette@gmail.com> References: <20070314140059.2fdc9a8f@localhost.localdomain> <200703141355.15467.dylan.beaudette@gmail.com> Message-ID: <20070314161143.0609603b@localhost.localdomain> On Wed, 14 Mar 2007 13:55:15 -0700 Dylan Beaudette wrote: > On Wednesday 14 March 2007 13:00, Trevor Wiens wrote: > > I posted a question some time ago about directional or differential > > buffering. I've managed to resolve my bugs and am now unsure what is the > > best way to incorporate this code back into GRASS. I assume it is > > desirable as I assume others may find it useful from time to time. > > Hi Trevor. Can you elaborate on what was causing the 'spikes' in your > previously posted version? > There were two problems, one related to a sign issue in my own code. The second related to inserting segments to round corners when there is a change in direction. The buffer.c Vect_line_buffer code inserts an additional point and then re-inserts the starting point to close the polygon. I wasn't able to grok its location calculation so by simply commenting out the problem went away. It doesn't appear to cause any problems when inspecting the results visually. 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 twiens at interbaun.com Wed Mar 14 23:15:45 2007 From: twiens at interbaun.com (Trevor Wiens) Date: Wed Mar 14 23:10:42 2007 Subject: [GRASS-dev] New directional buffering module or modified v.buffer In-Reply-To: <45F86965.4050105@o2.pl> References: <20070314140059.2fdc9a8f@localhost.localdomain> <45F86965.4050105@o2.pl> Message-ID: <20070314161545.20d28f6b@localhost.localdomain> On Wed, 14 Mar 2007 22:30:13 +0100 Maciej Sieczka wrote: --- snip --- > and let us know if the resulting buffers are OK? Most folks who tried > it (actually, everyone who reported, besides Hamish) confirmed the > output of v.buffer was bad. If v.buffer.ellipsoid has this problem > fixed, it would be great news and I'd say that it should replace > v.buffer then, if possible. Well, it reproduces probably the same error that others are seeing. After fiddling with this code for a couple of days I think I can identify where the problems are, but will have to invest some time in thinking about how to solve it. My quick assessment is as follows. On the west side, the bump is a function of creating a semicircle to round the corner because there is a new line segment. Unfortunately because there was no change in direction, this semi-circle should not have been created. On the south, the opposite direction is a function of angle of the line being misread as to which is the inside and the outside. The north end problem is the same problem. Well, I guess I need to solve these problems before committing changes to v.buffer. I take it that the general feeling is that enhancing v.buffer is better than adding another module. This may take a few days. I'll keep you posted. 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 woklist at kyngchaos.com Wed Mar 14 23:13:41 2007 From: woklist at kyngchaos.com (William Kyngesburye) Date: Wed Mar 14 23:13:47 2007 Subject: [GRASS-dev] New Mac OS X application build option Message-ID: Finally got the Mac OS X build option into CVS, with a little configure/makefile help from Glynn. To build GRASS as a Mac OS X application (exactly like my binaries, if anyone has used those), add these options to your configure command: --prefix=/Applications --enable-macosx-app Since the default prefix is /usr/local and it's nearly impossible to have multiple conditional default prefixes in configure, you should set the prefix as above. It's tested with OSX 10.4 and the latest Xcode. It should work on 10.3, but it would be good to have verification of this if anyone cares to try it. Enjoy! ----- 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 tr