RE: [GRASS-dev] r.report seg faults on page widths 28 chars
I can't think of any use for having page widths that narrow, but shouldn't the module trap out of bounds values? I can file this on trac if anyone thinks it's worth the trouble. Please file a report. -- Glynn Clements gl...@gclements.plus.com Done: http://trac.osgeo.org/grass/ticket/970 ~ Eric. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] r.report seg faults on page widths 28 chars
I don't know if this is worth filing a bug report for, so I'll check here first. r.report seg faults if the page width parameter is set to values 27 and less; a page width of 28 seems to invoke an infinite loop. I can't think of any use for having page widths that narrow, but shouldn't the module trap out of bounds values? I can file this on trac if anyone thinks it's worth the trouble. -- Eric Patton ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
RE: [GRASS-dev] r.report seg faults on page widths 28 chars
Eric wrote: I don't know if this is worth filing a bug report for, so I'll check here first. r.report seg faults sure that's bug worthy, a segfault is a segfault. they shouldn't happen under normal circumstances. if the page width parameter is set to values 27 and less; a page width of 28 seems to invoke an infinite loop. seems to be map dependent. for spearfish fields the min seems to be pw=7,8. Done as ticket #970, thanks. ~ Eric. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
RE: [GRASS-dev] r.out.gdal -f flag clarification
I guess the documentation as well as the warning and error messages could do with some improvement/clarification? Markus M Done in develbranch_6 and trunk. -- Eric Patton ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] r.out.gdal -f flag clarification
Hi, I trying to decipher the meaning of the description of the r.out.gdal -f flag. Currently, it reads: Force raster export also if data loss may occur I take it it should read Force raster export (note: data loss may occur) ? -- Eric Patton Technologist, Geo-Spatial Data Services Natural Resources Canada Geological Survey of Canada (Atlantic) Bedford Institute of Oceanography 1 Challenger Drive (P.O. Box 106) Dartmouth, Nova Scotia, B2Y 4A2 Telephone: (902) 426-7732 Facsimile: (902) 426-4104 Email: epat...@nrcan.gc.ca ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
RE: [GRASS-dev] r.out.gdal -f flag clarification
Markus M: I guess the documentation as well as the warning and error messages could do with some improvement/clarification? Thanks for the info. I'll update the docs a little later today. Cheers, -- Eric ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Reverting svn submission
I'm trying to revert r40901, an update to the description of the -f flag in trunk/raster/r.out.gdal/main.c: svn merge -c -40901 https://svn.osgeo.org/grass/grass/trunk/ but I think I neglected to append the extra directories raster/r.out.gdal/main.c to the end of the above command; can someone verify if I screwed something up? What is the correct revert command? Sorry for the trouble, -- Eric Patton ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Documents Manager position available
Grass users: I'm sorry to report I must step down as the Grass documents manager. I am being reassigned to a new position within my organization, and much of my work will be non-GIS related, unfortunately. I'm sorry I was not able to contribute more updates than I have. I would, however, like to keep my svn commit privileges, with the PSC's permission, to be able to commit occasional updates from time to time. I will still need to use GIS for some work, and if I come across any Grass documentation errors, I would like to be able to commit fixes for these. Thanks and regards, -- Eric Patton Technologist, Geo-Spatial Data Services Natural Resources Canada Geological Survey of Canada (Atlantic) Bedford Institute of Oceanography 1 Challenger Drive (P.O. Box 106) Dartmouth, Nova Scotia, B2Y 4A2 Telephone: (902) 426-7732 Facsimile: (902) 426-4104 Email: epat...@nrcan.gc.ca ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
RE: [GRASS-dev] haxby color rules
-Original Message- any thoughts on adding the haxby color rules into the main-tree? it's yet-another elevation variant, but I think a rather nice one. https://trac.osgeo.org/grass/browser/grass-addons/raster/r.colors.tool s/palettes/haxby.gcolors Hamish Yes, please do add it. We use this color ramp all the time for multibeam bathy. It's less saturated and avoids the primary colors. Seabed topography tends to get lost in the deep reds and purples. -- Eric Patton ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
RE: [GRASS-dev] contributing documentation
Hi Tim, (sorry if this gets double-posted - my mailbox was full the first time I sent it) Here's a link to creating patches for submission to svn: http://grass.osgeo.org/wiki/Patches You can send documentation patches to myself, or, if you would like to contribute on a more permanent basis, ask the Grass PSC for svn repository write privileges (we can always use more volunteers). The wiki seems to be the place for more in-depth explanations, examples, and how-tos, and the manuals tend to be a bit more succinct, but there's no hard and fast rules. If something is unclear in the manuals, then the text should definitely go there. Cheers, -- Eric Patton -Original Message- From: grass-dev-boun...@lists.osgeo.org on behalf of Tim Michelsen Sent: Thu 12/10/2009 8:13 PM To: grass-dev@lists.osgeo.org Subject: [GRASS-dev] contributing documentation Hello, what's the best way to provide patches to GRASS documentation like small and more verbose explanations? Where do you draw the limit between simple FAQ items for the wiki and how would an item qualify for the manual pages? Regards, Timmie ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
RE: [GRASS-dev] Programming in GRASS
I use XEmacs. I suppose it could count as an IDE, although it's more of an IEE: Integrated Everything Environment. Apart from editing source files and Makefiles, it has facilities for running the compiler, parsing the error messages, and locating an error in the source code. It also has interfaces to GDB and to several revision-control systems. Also, viewers for manual pages, Info files and HTML files. Yes, this is all well and good, but can it brew a cup of coffee? That is a real consideration here ;^) Although I do a lot of prgramming per se, I do a ton of script editing with vim, and I know the editor has a ton of features for programmers; it might be worth checking out. P.S. Mostly, I only mentioned vim because Glynn brought up XEmacs. Zing! Flame shields on, and have a good Easter weekend everyone ;^) ~ Eric. About the only feature of typical IDEs which is missing is a GUI front-end for managing the file hierarchy. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
RE: [GRASS-dev] Programming in GRASS
Yes, this is all well and good, but can it brew a cup of coffee? That is a real consideration here ;^) Although I do a lot of prgramming per se, I do a ton of script editing with vim, and I know the editor has a ton of features for programmers; it might be worth checking out. Whoops - No I do NOT do a lot of programming - maybe I should be brewing a pot of coffee. Promising not to post anymore today, ~ Eric. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Test
Another test, disregard... ~ Eric. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
RE: [GRASS-dev] Re: [GRASS-user] How choosing the colors of an importedmap
FYI, I just committed a new interactive color management module to the wxPython GUI code this weekend (in both develbranch_6 [GRASS 6.4] and trunk [GRASS 7]). It allows you to set colors for rasters by entering cat values or percents and clicking a color chooser button. There is a preview window that allows you to fine tune your color table. Cool, very nice! I gave it a try in 6.4, seems to work great! Thanks for this feature, ~ Eric. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] RE: [GRASS GIS] #137: wxgrass: Error in profile tool
just recompile GRASS7 from the scratch (make distclean first), somehow you are using old version of GIS library. Martin Hmm...but this error occurs after I checked out the entire grass_trunk from svn again and recompiled from scratch. ~ Eric. winmail.dat___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Question on r.grow 'metrics' parameters
I was wondering if anyone could describe, or point me to a link of, the various r.grow metrics parameter definitions: euclidian, maximum, and manhattan. Also, are the comments regarding how r.grow decides how to grow between two equally eligible cells here (http://www.nabble.com/-GRASSLIST%3A7611--r.grow-to8629593.html#a8629593) still valid? I would like to add this information to the docs, and AFAICS, main.c hasn't changed much since Glynn's last edit 21505 back in late November, 2006. Thanks, ~ Eric. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] RE: [GRASS-user] Small tcltk fonts used in gis.m gui
Patton, Eric wrote: I'm pretty sure something strange happened between my upgrade from Ubuntu 7.10 to 8.04, but all applications that I use (there's not too many) that use tcl/tk as the gui toolkit have really small fonts being used. This probably indicates that it is confused about the scale factor to convert between points and pixels. It may be that your monitor is reporting bogus physical dimensions via EDID. Or it may be that you have some existing configuration settings based upon the historical default of 75 DPI and those settings are producing undesirable results when your system uses your monitor's actual resolution. Does anyone know how I can re-configure the global font sizes used in tcl/tk? Tk reads ~/.Xdefaults, and uses any *font: ... setting found there. However, gis.m overrides that setting with: fontcreate default -family Helvetica -size -12 ... option add *font default It's easy enough to do a global find and replace on the relevant tcl files, and to edit my ~/.Xdefaults; is there anything else I should do to ensure the edits remain permanently? I have no idea where it gets this information from (or if it's just hard-coded to 75 DPI). Tk 8.4 doesn't call DisplayWidthMM or DisplayHeightMM, which is the normal way to determine the physical screen resolution. However, the list of changes for Tk 8.5 suggest that the font rendering has been replaced. Hopefully an update to 8.5 will solve the problem. Thanks for the hints; ~ Eric. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
RE: [GRASS-dev] GSoC, Reimplementing v.buffer and adding features
Rosen, The v.buffer module has had problems for a few years now; your contributions will be most welcome indeed. Best of luck, ~ Eric. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
RE: [GRASS-dev] wxgrass: Error in profile tool
Do you have numpy installed? It is needed for the profile tool. Michael Yes, I have packages python-numpy and python-numpy-dev installed, versions 1.0.3. I also have packages python-numeric and python-numarray installed, if that matters. ~ Eric. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] RE: [GRASS GIS] #130: wxgrass: Remember the position of gui windows on Grass exit
that's strange, see the attached screenshot. You can save default window dimension here, also workspace file now contains information about windows layout (can be suppressed in 'Workspace' tab in GUI preferences dialog, e.g. The problem was that I had an alias in my .bash_aliases file for g6 which is shorthand for 'grass63'. After the subversion repo had been tagged for the 6.3 release, trunk became grass6.4.svn, and I forgot to update my alias to point to the new grass installtion. I can confirm the workspace windows all line up to their previous positions. Thanks very much! ~ Eric. winmail.dat___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
RE: [GRASS-dev] 6.3.0 is out! please prepare binaries...
anayone, who could help me with debian patches system? jachym What's required? I'm a complete noob when it comes to this, but I'm running basically bleeding edge everything on grass-6.3.svn, Ubuntu 7.10 64-bit. ~ Eric. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] wxgrass: Error in profile tool
Using today's svn... When using the wxgrass profile tool, the following error is encountered when I click on the 'Draw Profile' button after I have created a transect to profile: Traceback (most recent call last): File /usr/local/grass-6.4.svn/etc/wxpython/gui_modules/pr ofile.py, line 427, in CreateProfile self.DrawPlot() File /usr/local/grass-6.4.svn/etc/wxpython/gui_modules/pr ofile.py, line 447, in DrawPlot legend=' '+self.plegend1) File /usr/lib/python2.5/site- packages/wx-2.8-gtk2-unicode/wx/lib/plot.py, line 224, in __init__ PolyPoints.__init__(self, points, attr) File /usr/lib/python2.5/site- packages/wx-2.8-gtk2-unicode/wx/lib/plot.py, line 124, in __init__ self._points = _Numeric.array(points).astype(_Numeric.Float64) File /usr/lib/python2.5/site- packages/numarray/numarraycore.py, line 417, in array return fromlist(sequence,type,shape) File /usr/lib/python2.5/site- packages/numarray/numarraycore.py, line 252, in fromlist highest_type = _maxtype(seq) File /usr/lib/python2.5/site- packages/numarray/numarraycore.py, line 131, in _maxtype return PyLevel2Type[_numarray._maxtype(args)] TypeError : Expecting a python numeric type, got something else. I have ensured that the computational region has been set to that of the map display before digitizing the profile transect. ~ Eric. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
RE: [GRASS-dev] wxgrass: Error in profile tool
Using today's svn... When using the wxgrass profile tool, the following error is encountered when I click on the 'Draw Profile' button after I have created a transect to profile: Also printed to the bash terminal is the message: GRASS_INFO_WARNING(17752,1): Endpoint coordinates are outside of current region settings GRASS_INFO_END(17752,1) Despite the fact that the transect endpoints are well within the limits of the computational region (see ftp://agc.bio.ns.ca/outgoing/Patton/Grass/Profile.png) ~ Eric. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Question about automatic positioning of gui windows in wxgrass
Hi, I thought I'd ask here first before submitting a request: is it possible for wxgrass to remember the position of the respective gui windows on exiting, so that they align to their former positions on Grass startup? As I recall, this has been a long-sought feature of Grass, from myself and others. I can't seem to find the exact thread in the ML at the moment. ~ Eric. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Problem removing mapsets in g.mapset
I can't seem to remove mapsets in g.mapsets using the new removemapset parameter. Ex: $ g.mapsets -p ED_Legacy_Data PERMANENT 2007006 $ g.mapsets rem=2007006 $ g.mapsets -p ED_Legacy_Data PERMANENT 2007006 g.list is still fetching raster map names from the removed mapset as well: $ g.list rast -- raster files available in mapset ED_Legacy_Data: snip raster files available in mapset PERMANENT: snip raster files available in mapset 2007006: (all rasters follow) ~ Eric. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] RE: [GRASS-user] Problem removing mapsets in g.mapset
should be fixed now http://trac.osgeo.org/grass/changeset/30939 Martin Hi, yes I just tested it, works great. Thanks, ~ Eric. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
RE: [GRASS-dev] Re: [GRASS GIS] #100: v.surf.rst also crashes on MacOS X
On Thu, Mar 20, 2008 at 3:11 AM, GRASS GIS [EMAIL PROTECTED] wrote: You are misunderstanding what r.resamp.interp does. It does not fill null areas (like e.g. r.surf.idw or r.fillnulls). It resamples a map, calculating cell values by interpolating between the neighbouring cells, all of which must be non-null in order to get a non-null result. Markus: At this point we should improve the documentation: Current: EMr.resamp.interp/EM fills a grid cell (raster) matrix with interpolated values generated from a set of input layer data points. New: ? How about this: r.resamp.interp resamples an input raster map by interpolating between the neighboring cells via one of nearest neighbor, bilinear, or cubic resampling algorithms. All cells present in the neighborhood of the input raster cell must be non-null to generate a non-null cell in the output raster map. ? ~ Eric. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
RE: [GRASS-dev] Re: [GRASS GIS] #7: Location wizard: should predefine DB connection for new location
Eric: Thanks for the pointer. I'll hardcode my database paths for now. Hamish: see the db.connect help page example for DBF (I usually just cut and paste that to the command line when needed). It accepts variable LOCATION, MAPSET, you don't need to hardcode it. (Be sure to keep the path with $VARIABLES in single quotes!) Should each of $GISDABSE, $LOCATION_NAME, and $MAPSET have populated values on location startup? These variables always remain blank for each location that I try: ~ echo $GISDBASE ~ echo $LOCATION_NAME ~ echo $MAPSET ~ are these variables only available from the shell if I export `g.gisenv` or eval `g.gisenv` first? ~ Eric. winmail.dat___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Can't connect to osgeo.org today
Has anyone had success synching their source code to the repositories on osgeo.org today? I can't update my source, nor connect to osgeo.org via the main website either. ~ Eric. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
RE: [GRASS-dev] Update to r.out.gdal
Markus, Changeset 30450 should have been identical to changeset 30449; the only change I intended to make was to improve the wording of the warning message in trunk/raster/r.out.gdal/main.c line 323 and 328; the backport to grass63_branch should have had only these two changes. I don't know how all those other diffs found their way in the commit, as I have never edited any other source code in that file. So changeset 30450 should be reverted. ~ Eric. -Original Message- From: [EMAIL PROTECTED] on behalf of Markus Neteler Sent: Tue 3/4/2008 6:13 PM To: Patton, Eric Cc: grass-dev@lists.osgeo.org Subject: Re: [GRASS-dev] Update to r.out.gdal Eric, please tell us the commit(s) from http://trac.osgeo.org/grass/timeline to better understand it. Markus On Mon, Mar 3, 2008 at 7:11 PM, Patton, Eric [EMAIL PROTECTED] wrote: Hi, I just committed a warning message change in TRUNK, but I think some un-backported changes were also committed to grass63_release inadvertently during my commit. Can someone confirm that everything is ok? Sorry for the headache. I think I failed to sync my grass63_release source with the svn repo before committing. My submission incorporates Martin's edits from changeset 29556 as well, if I'm not mistaken. What's the proper svn magic for cases like these? ~ Eric. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev -- Open Source Geospatial Foundation http://www.osgeo.org/ http://www.grassbook.org/ ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
RE: [GRASS-dev] Re: m.distance / SWIG-Python interface + passingpointers with SWIG [was: d.measure w/ bearing]
This means that for the specific issue at hand, i.e. d.measure with bearing, I strongly plead for adding the possibility of giving start / end coordinates as parameters to the module. This would then allow other uses beyond the wxgrass gui such as web apps, shell scripts, etc. As I have mentioned before, I am afraid that slowly but surely the wxgrass gui will multiply functionality which is only available via the gui, but should, in my eyes, also be available from the command line. I'm thinking of things like profiling, measuring, etc. Moritz I agree; the ability to use and script modules on the command line is a key feature that I rely on. GUI lock-in of certain features would really be frustrating. ~ Eric. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
RE: [GRASS-dev] [GRASS GIS] #79: gis.m: Raster Legend text selectionbutton gives error
Eric, What do you mean by text selection button: legend text font, text color, or something else? I meant the button labeled 'legend text font'. Sorry about that. ~ Eric. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Update to r.out.gdal
Hi, I just committed a warning message change in TRUNK, but I think some un-backported changes were also committed to grass63_release inadvertently during my commit. Can someone confirm that everything is ok? Sorry for the headache. ~ Eric. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
RE: [GRASS-dev] Update to r.out.gdal
Hi, I just committed a warning message change in TRUNK, but I think some un-backported changes were also committed to grass63_release inadvertently during my commit. Can someone confirm that everything is ok? Sorry for the headache. I think I failed to sync my grass63_release source with the svn repo before committing. My submission incorporates Martin's edits from changeset 29556 as well, if I'm not mistaken. What's the proper svn magic for cases like these? ~ Eric. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
RE: [GRASS-dev] r.out.gdal Gtiff output does not preserve color tables
can you zoom a little bit so that the region is smaller than the raster and then export with r.out.gdal to see whether it is still black? Are you also getting warning about nulls in the data even if there are none? I think there is a bug in the program (and it also does not let you set the number of decimal digits so it produces numbers with large number of digits that are useless). thanks, Helena Helena, Zooming in to a smaller region than the raster doesn't change the results. I do get warnings about nulls, but it seems to make sense given the shape of the data I'm working with relative to the region. I exported a series of tiffs using r.out.gdal today, using type=Byte and type=UInt16. ArcGIS 9.2 was able to load the UInt16 tiffs, although very, very slowly. The elevation.10m raster from Spearfish took about 2 minutes to load, and it was only 5.6MB in size. The long loading time was due to the enormous size of the color table: 65,536 (2^16) colors. I can't imagine how long it would take Arc to load a 200MB tiff with this many colors. It would probably crash. All of the Byte tiffs were red. A look at the color table in Arc showed that all of the 255 colors were a repeating pattern of white-to-red (i.e., 0-31, 32-63, etc.), with no green or blue colors. I've never had a problem with the output from r.out.tiff, using it for 6 years now. I can view these tiffs in every image viewer and GIS on both Linux and Windows. I imagine the reason for this is the relatively simplified color tables in r.out.tiff tiffs? I would be great if there was a way to get georeferencing information installed in the headers of tiffs created from r.out.tiff. The output from r.out.gdal seems to be either way too detailed, or not mapped properly into a 255 color space. Has anyone had success using the type=Byte in r.out.gdal to get consistently good output for use in other GIS? ~ Eric. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] r.out.gdal Gtiff output does not preserve color tables
I'm using today's Grass 6.3.svn source, gdal 1.5.0. $ gdalinfo --formats | grep GRASS GRASS (ro): GRASS Database Rasters (5.7+) In Spearfish60: $ r.info -t elevation.10m datatype=DCELL $ g.region rast=elevation.10m -p projection: 1 (UTM) zone: 13 datum: nad27 ellipsoid: clark66 north: 4928000 south: 4914020 west: 590010 east: 609000 nsres: 10 ewres: 10 rows: 1398 cols: 1899 cells: 2654802 The following commands all produce tiffs that display completely black in off-the-shelf image viewers in Ubuntu 7.10: (Eye of Gnome 2.20.1, GIMP 2.4.4) $ r.out.gdal input=elevation.10m output=elevation.10m.tif type=Byte $ r.out.gdal input=elevation.10m output=elevation.10m.tif type=Byte createopt=INTERLEAVE=PIXEL $ r.out.gdal input=elevation.10m output=elevation.10m.tif type=Byte createopt=INTERLEAVE=PIXEL,PROFILE=GeoTIFF $ r.out.gdal input=elevation.10m output=elevation.10m.tif type=Byte createopt=INTERLEAVE=PIXEL,PROFILE=BASELINE These commands give a completely blank raster in the same image viewers: $ r.out.gdal input=elevation.10m output=elevation.10m.tif type=UInt16 $ r.out.gdal input=elevation.10m output=elevation.10m.tif type=UInt16 createopt=INTERLEAVE=PIXEL $ r.out.gdal input=elevation.10m output=elevation.10m.tif type=UInt16 createopt=INTERLEAVE=PIXEL,PROFILE=GeoTIFF $ r.out.gdal input=elevation.10m output=elevation.10m.tif type=UInt16 createopt=INTERLEAVE=PIXEL,PROFILE=BASELINE According to r.out.gdal manual, the type= parameter should be set to either Byte or UInt16 to preserve the color table. I can't get either type to output anything useful. Using any other type causes r.out.gdal to complain that the color tables won't be preserved. What am I missing here? Even the example from the r.out.gdal manual page produces an error and a tiff that does not display anything: $ r.out.gdal in=elevation.10m out=ned_elev10m.tif type=Float64 createopt=INTERLEAVE=PIXEL,TFW=YES Exporting to GDAL data type: Float64 ERROR 6: SetColorTable() only supported for Byte or UInt16 bands in TIFF format. 100% r.out.gdal complete. Is a tiff without a color table even useful? I'd settle for a lossy, interpolated color table. Normally I would just use r.out.tiff as a workaround, but I think this module ought to output georeferenced tiffs with sane color tables. In any case, I can't use the tiff-with-worldfile workaround; I need geotiffs with the projection info written into the header - *with* a color table. ~ Eric. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
RE: [GRASS-dev] Manpage HTML markup consistency
Glynn mentioned DocBook as a possible future doc format...what about XML? Are there any advantages to ever using that format, or is it pretty much the same as using HTML? If we ever wanted to move to XML, or at least make it easier to migrate to it, all html tags would have to be lowercased, as I believe XML expects it. I've written a small sed script to do this already, but I didn't want to modify all 300+ docs and do a massive svn commit if there's no point. ~ Eric. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
RE: [GRASS-dev] Manpage HTML markup consistency
I've changed SUBMITTING_DOCS, adding the new guidelines for tags that I posted(em,b,i). I haven't removed any of the recommended tags, until the dust settles on the discussion. ~ Eric. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Manpage HTML markup consistency
Is there any preferred way for using html markup for tagging module names, parameter names, and flags in the document html pages? From what I have seen, b, em, and i (or some combination thereof) have been variously used to highlight module names, flags and parameters. Although flags seem to be more consistently boldfaced than anything else. For the sake of consistency between pages, and for a common look, I would like to adhere to a common rationale for using html markup on these descriptors. My own preference is to just boldface flags and parameter names; that seems to make them stand out better when scanning quickly through the page, more so than emphasis. Feedback welcome, ~ Eric. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
RE: [GRASS-dev] Manpage HTML markup consistency
Hamish: The common usage has been: module names em flags and option names b (inline text; not within pre code) shell commands, names, etc tt (inline text; don't overuse) emphasized phrase i (inline text; use instead of bolding the sentence) code: div class=codepre ... /pre/div once formalized... - SUBMITTING_DOCS I expect there are many dead links to non-ported GRASS 5 modules and many help pages may talk of obsolete interactive mode. Ok, I won't use up any more bandwidth about it; if no one objects, I'll change SUBMITTING_DOCS to use: em tags for module names b for flags and parameter names shell commands, names, etc tt emphasized phrase i alphabetized SEE ALSO I've been removing obsolete references to the old interactive mode from the docs as I encounter them. Thanks for the feedback, ~ Eric. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
RE: [GRASS-dev] Re: [GRASS-user] V.extrude... confused
some examples are there, only thing, which is missing is link to nviz manual page. I've added the missing link to main nviz html page in TRUNK and grass63_release branch. ~ Eric. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] RE: [GRASS-user] MASK seems to be ignored
sure not to do with the problem I had: http://www.nabble.com/MASK-does-not-do-it%27s-work-%28-% 29-with-r.mapcalc-td14407246.html#a14407246 I tried Glynn's method mentioned in that thread, specifically: r.mapcalc MASK = '!isnull(MAP)' which worked. Checking the range of the raster I used for a mask in my r.mask command, it was 0-32767; so shouldn't r.mask in=MAP also create a mask where any non-null cell in the input raster exists? Here's the output from r.info for the mask I created using r.mask: $ r.info MASK ++ | Layer:MASK Date: Tue Feb 5 11:53:33 2008| | Mapset: PERMANENT Login of Creator: epatton | | Location: Charlottetown| | DataBase: /home/epatton/Projects | | Title:Reclass of EC_Charlottetown_Bathy_March_2007_1m_fill_shade_comb | | Timestamp: none| || || | Type of Map: reclass Number of Categories: 1 | | Data Type:CELL | | Rows: 999| | Columns: 1220 | | Total Cells: 1218780| |Projection: UTM (zone 20) | |N:5119638S:5118639 Res: 1 | |E: 491266W: 490046 Res: 1 | | Range of data:min = 1 max = 1 | || | Data Source: | |Reclassified map based on: | | Map [EC_Charlottetown_Bathy_March_2007_1m_fill_shade_comb] in mapset | || | Data Description:| |NT] | || | Comments:| |T] | || || | Reclassification of [EC_Charlottetown_Bathy_March_2007_1m_fill_shade_com | || | CategoryOriginal categories| || | 1 0-32737| ++ ~ Eric. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] MASK seems to be ignored
Hi, I'm having problems getting a MASK to actually mask anything. $ r.mask in=Diff_Nov2007_Oct2007_1m MASK created. All subsequent raster operations will be limited to MASK area Removing or renaming raster file named MASK will restore raster operations to normal [Raster MASK present] Yet all refreshes of the gis.m map display window do not clip the display extents based on the new mask(see attached png). In the screenshot, the mask is the pink raster, and underneath it is another raster in my mapset. Shouldn't the underlying raster's display be clipped to that of the mask? Using r.mapcalc while the mask exists also doesn't seem to obey the extents of the mask, i.e.: r.mapcalc test = 'Diff_Oct2007_Mar2007_1m' This creates the raster 'test' with data extents that match Diff_Oct2007_Mar2007_1m, not the mask's boundaries. I'm using svn-trunk compiled from today's source. ~ Eric. attachment: Mask.png___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
RE: [GRASS-dev] MASK seems to be ignored
The way I understand it is that a MASK will affect all subsequent *read* operations for processing a raster map. That is... r.mapcalc 'newmap=oldmap' ...will just produce an unaltered copy of oldmap without a MASK; with a MASK it will produce a copy of oldmap only in the area of MASK. MASK will not affect the display. It is for map processing. Michael It seems that the current mask does affect the display, though. I've placed three screenshots on ftp://gsca.nrcan.gc.ca/outgoing/Patton. The 'Before' image is the full extent of my input raster; I zoomed into a small region in the display, set the region to that of the display extent, and created a mask using r.mapcalc !isnull(MAP). I then zoomed back to my original display extent, set the region back to that of the display, and redrew the display, the output of which is the 'After' image. The display is being clipped by the current mask. ~ Eric. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] RE: [GRASS GIS] #19: Support for multiple 'percentile' arguments in r.univar
'Percentile' parameter can be now multiple (also for r3.univar).
http://trac.osgeo.org/grass/changeset/29848
E.g.
{{{
r.univar elevation.dem -e per=70,90
...
1st quartile: 1200
median (odd number of cells): 1316
3rd quartile: 1488
70th percentile: 1447
90th percentile: 1621
}}}
Martin
Very Cool, thanks, Martin! I'll have to check this out today.
~ Eric.
winmail.dat___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
RE: [GRASS-dev] Descriptions for r.colors color rules
Helena: curvature is for terrain curvatures (based on the color table that you get for curvatures from v.surf.rst and r.slope.aspect), something like this http://skagit.meas.ncsu.edu/~helena/wrriwork/lakewh/honpc.jpg http://www.grassbook.org/gallery/chapters/s060806f010_pcurv.jpg http://www.grassbook.org/gallery/chapters/s0609f020_topoanal.jpg negative values are blues, positive values are yellow to red (I will double check that to make sure). Generally it is useful for maps that have both positive and negative values. Hamish: see also r.colors.stddev from the wiki addons page. To me it is a very interesting module for setting color tables for difference maps etc. Neat, I'll have to check this one out. Helena: I don't know about evi, Hamish: It is enhanced vegetation index from eg MODIS data like NDVI. see http://earthobservatory.nasa.gov/Library/MeasuringVegetation/ Thanks to all for the info; I've updated the color rules list and added some descriptions. I've been having trouble with svn today (see my other thread from today), but the commit seems to have made it through on Trac. ~ Eric. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
RE: [GRASS-dev] GRASS-dev] New 'About Grass' and 'About System' errorsin gis.m
Thanks, Michael. Much appreciated. ~ Eric. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Case of description.html tags?
Does it matter whether or not the html tags in the description.html files are upper or lower case? I've read that The W3C recommends lowercase tags in their HTML 4 recommendation, and XHTML (the next generation HTML) demands lowercase tags. And if we're trying to standardize the docs anyway, it might not be a bad idea. Some reasons for using lowercase tage are given here: http://www.htmlbasictutor.ca/html-tag-attributes.htm If I'm editing many of the docs anyway, I can make the case changes as I make content-related edits. I could probably also write a script to take care of it in one go. ~ Eric. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] r.volume 'data' parameter
Just looking at r.volume today...the 'data' parameter is a pretty unconventional name for a Grass raster program. Wouldn't a rename to 'input' or 'map' be more in keeping with other raster modules? I didn't want to modify the source in case there was a good reason for it being called 'data'. ~ Eric. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
RE: [GRASS-dev] r.volume 'data' parameter
Just looking at r.volume today...the 'data' parameter is a pretty unconventional name for a Grass raster program. Wouldn't a rename to 'input' or 'map' be more in keeping with other raster modules? I didn't want to modify the source in case there was a good reason for it being called 'data'. I guess, these kind of changes cannot be done in grass6 because of backward compatability, need to wait for grass7. Martin Thanks, I've placed a note about it on the Grass7 ideas collection on the wiki: http://grass.gdf-hannover.de/wiki/GRASS_7_ideas_collection ~ Eric. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
RE: [GRASS-dev] [grass-code I][566] g.rename fails to rename maps
It's in manage: http://trac.osgeo.org/grass/browser/grass/trunk/general/manage/cmd Moritz Thanks for the pointer. Is it still a bug, though? Can anyone confirm? ~ Eric. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
RE: [GRASS-dev] things to do before the 6.3.0 release
I have a question about general committing practices. Should all commits be applied against HEAD only, or should each author see to it that commits are backported to release branches as well? Thanks, ~ Eric. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
RE: [GRASS-dev] slow access to osgeo svn
You can easily reach IRC with zero installation through this Web client: http://irc.telascience.org/cgi-bin/irc.cgi - select reasonable nick name - select #osgeo Then they can check immediately what's going on. Markus A lot of irc protocols are blocked or forbidden behind corporate/government firewalls for some of us (big brother is always watching), so that isn't always an option. ~ Eric. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
RE: [GRASS-dev] [grass-code I][557] v.overlay: should not allow columnnames of length 10 in dbf
From: [EMAIL PROTECTED] on behalf of Maciej Sieczka Off-list we have narrowed the problem down. Summary: The cuplrit is a bug in v.overlay that it creates DBF tables with column names longer than 10. To reproduce please download the sample location [1], enter PERMANENT and do: snip Confirmed. The last one's name is longer than 10, thus any GRASS command will ignore it at input, leading to corrupted output table. It's v.overlay's fault that it created a bad table. Another thing: could/should GRASS commands handle DBF column names longer than 10 in DBF table for reading? How is it possible to write a dbf column name longer than 10 characters? Through postgres, maybe? I thought the column names were always truncated at 10 chars. Maybe it would be better to fix v.* modules to catch cases where an attempt is made to write column names longer than 10 chars? ~ Eric. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
RE: [GRASS-dev] [grass-doc I][564] Typos in man i.smap
Submitted By: Nikos Alexandris (nikosa) Initial Comment: 1. In the description of the -q flag... Run quietly, without printing messages about program progress. Without this flag, messages will be printed (tostderr ) as the program progresses. * This should be stdout or not (...sorry if I am not familiar with all coding terms!) ? 2. In the NOTES [...] It works by segmenting the image at various scales or resolutions and using thecoursescale segmentations... * This should be coarse I'm not sure the part about printing to stderr is an error; I'll leave that issue for someone a little more knowledgeable to comment on. Typo fixed in 6.3.svn. ~ Eric. winmail.dat___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
