<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">A few comments below.<div><br><div apple-content-edited="true"> </div><br><div><div>On Oct 6, 2008, at 1:49 AM, <<a href="mailto:grass-dev-request@lists.osgeo.org">grass-dev-request@lists.osgeo.org</a>> <<a href="mailto:grass-dev-request@lists.osgeo.org">grass-dev-request@lists.osgeo.org</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: 'Lucida Grande'; font-size: 10px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; ">Date: Mon, 6 Oct 2008 06:34:41 +0100<br>From: Glynn Clements <<a href="mailto:glynn@gclements.plus.com">glynn@gclements.plus.com</a>><br>Subject: Re: [GRASS-dev] porting r.in.wms to python<br>To:<span class="Apple-converted-space"> </span><a href="mailto:hamish_b@yahoo.com">hamish_b@yahoo.com</a><br>Cc: grass-dev <<a href="mailto:grass-dev@lists.osgeo.org">grass-dev@lists.osgeo.org</a>><br>Message-ID: <<a href="mailto:18665.41841.122863.646844@cerise.gclements.plus.com">18665.41841.122863.646844@cerise.gclements.plus.com</a>><br>Content-Type: text/plain; charset=us-ascii<br><br><br>Hamish wrote:<br><br>> > > I was planning on leaving those until last ;)<br>> ><br>> > Well, I'm now planning on just leaving them, period ;)<br>> ><br>> > Here's the current status on conversion of scripts to<br>> > Python:<br>> ><br>> > The following scripts are disabled, and haven't been converted:<br>> ><br>> > d.out.gpsdrive (d.mon)<br>><br>> (me)<br>> like the very useful d.out.file module, it dumps current (composed) map<br>> display to the PNG driver via d.save. I suppose replacing this will<br>> be a clone/modification of how d.out.file's functionality has been<br>> replicated.<br><br>IOW, it needs to be built into the GUI; now that monitors no longer<br>exist, nothing else has any notion of a "current" map.</span></blockquote><div><br></div><div>It already exists in the GUI. It exists in the TclTk GUI too. If additional output formats are needed they can be added.</div><br><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: 'Lucida Grande'; font-size: 10px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><br><br>> > d.rast.leg (d.frame)<br>><br>> (any thoughts Markus?)<br>><br>> perhaps replaced by some wxGUI "load cartographic template" tool?<br>> (users could contribute their own etc..)<br><br>Note that it is possible to set a drawing frame by setting<br>GRASS_FRAME=t,b,l,r (see d.polar for an example).<br><br>Actually, this should be salvageable without too much effort. I just<br>saw the d.frame calls and didn't look much further.</span></blockquote><div><br></div><div>Could this be wrapped into ps.map? If I remember, this simply puts a raster on the screen in one frame, a title in another, and a legend in a third. Doing this in the wxPython canvas is doable, but I wonder if a script is the best way to go with it. That is, building it into a wxPython class in the display module seems to make more sense. An alternative is to have a script combine a raster, title, and legend in an output graphic file (png, pdf, or something). This could be done more easily.</div><br><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: 'Lucida Grande'; font-size: 10px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><br><br>> > i.spectral (d.mon, d.where)<br>><br>> It would be very easy to add a coord=x,y[,x2,y2,...] option to feed<br>> r.what instead of using d.where. The d.mon check is just to ensure<br>> that d.where will work.<br><br>That sounds simple enough.<br><br>> More work would be to replace gnuplot with d.graph or whatever, like<br>> is done for d.polar.<br><br>Is d.linegraph suitable?</span></blockquote><div><br></div><div>There is a simple graphing module that comes with wxPython that is much more sophisticated than d.linegraph--which still assumes an xterm (although it can output to a graphic file I suppose). However, I suggested that matplotlib might be quite suitable for this kind of task. It is a free, pure Python library that can do very sophisticated graphing very easily. It can be 1) wrapped into the GUI display, 2) set to create it's own simple display in a couple of GUI toolkits, or 2) set to output to a graphic file. It is scriptable. I submitted a couple of test scripts to show how this might be accomplished. </div><br><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: 'Lucida Grande'; font-size: 10px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><br><br>> > These:<br>> > r.in.wms/r.in.wms<br>> > r.tileset/r.tileset<br>><br>> I think it is ok for the replacement version to depend on GDAL > 1.5.0.<br>> A first step will be adding XML+GDAL option to the bash/sh version<br>> for testing of that method.<br><br>It might be simpler to just start from scratch in Python.<br><br>> > v.in.gpsbabel/v.in.gpsbabel<br>> > v.in.garmin/v.in.garmin<br>><br>> Certainly v.in.gpsbabel should survive in some form. v.in.garmin is<br>> useful as the gpsbabel garmin filter does not pass through all fields.<br>><br>> the XML stuff in v.in.gpsbabel is in desperate need of a python<br>> replacement, otherwise it shouldn't be /too/ different from v.in.mapgen.<br><br>Right. v.in.mapgen was another one that I was going to leave, but I<br>ended up downloading some sample files. That made it much easier to<br>see what the code was trying to do.<br><br>> > are too complex to replace using "rote" conversion (i.e. simply<br>> > replacing each chunk of code with equivalent Python code).<br>><br>> > The above scripts really need to be rewritten by someone<br>> > who understands the overall purpose of the script.<br>><br>> For v.in.gps I guess that means me, but my python+xml is rather weak.<br><br>The Python documentation has an example at:<br><br><a href="http://docs.python.org/library/xml.dom.minidom.html">http://docs.python.org/library/xml.dom.minidom.html</a><br><br>Or I can write the code to parse the XML if you can explain the<br>overall structure. It's just that trying to deduce the data structure<br>from a sequence of grep/head/tail/cut commands is rather mind-numbing.<br><br>> For a Python version r.in.wms, I defer the larger project to someone<br>> else, but can try to add GDAL support to the existing sh/bash version<br>> to demonstrate/verify the method.<br><br>That probably isn't much help. It would probably be more useful to<br>simply describe the process and provide some example URLs. I find<br>English much easier to read than bash/grep/head/tail/cut/awk/sed.<br><br>> [...]<br>> etc/gui/scripts/d.colors.sh<br>> etc/gui/scripts/d.path.sh<br>> etc/gui/scripts/r.colors.rules<br>> etc/gui/scripts/r.reclass.file<br>> etc/gui/scripts/r.reclass.rules<br>> etc/gui/scripts/r.recode.file<br>> etc/gui/scripts/r.recode.rules<br>><br>> these are all there as wrapper code between the GUI and command line<br>> modules, usually WRT piping info from stdin. All should be replaced by<br>> integrated wxGUI wizards not simply python scripts AFAICT.<br><br>Right. The various *.rules scripts plus d.colors.sh invoke xterm,<br>while the *.file versions just redirect stdin from a file (to<br>compensate for the lack of a file= option).</span></blockquote><div><br></div><div>These are unneeded I think.</div><br><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: 'Lucida Grande'; font-size: 10px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><br><br>So, r.reclass and r.recode each need a file= (G_OPT_F_INPUT) option.</span></blockquote><div><br></div><div>I thought this was already done.</div><br><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: 'Lucida Grande'; font-size: 10px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><br><br>d.path.sh combines d.vect and d.path. The d.vect step was necessary<br>when d.path used the mouse to obtain the coordinates, so that the user<br>could see what they were supposed to be clicking on. That's no longer<br>applicable.<br><br>> etc/gui/scripts/r.support.sh was partially needed because<br>> 1) non-interactive version did not in the past support all interactive<br>> functionality, and<br>> 2) interactive version weirdly exits prematurely when called directly<br>> from Tcl/Tk.<br><br>More generally, is there any intention to fix up gis.m with regard to<br>the various changes in 7.0, or are we going to abandon it and rely<br>upon wxgui instead?<br></span></blockquote><br></div><div>The TclTk GUI is set to be abandoned in GRASS 7. It will continue to live in the GRASS 6 series.</div><div><br></div><div>Michael</div><br></div></body></html>