Re: r.external - was: Re: [GRASS-dev] some questions about future development
On Thu, 21 Aug 2008, Paul Kelly wrote: On Thu, 21 Aug 2008, Glynn Clements wrote: Paul Kelly wrote: AFAICT, the only core GDAL dependencies are the OSR stuff in lib/proj and g.proj, and the vector library's support for v.external. In which case, it really ought to be possible to get a usable version of GRASS with no GDAL dependency in any of the libraries or core modules (e.g. g.proj, g.region). It used to be possible to compile g.proj without GDAL support, and use it only for reporting on the projection information and verifying datum information, but I removed all the conditional stuff for that when GDAL became a non-optional dependency. Could be put back in I suppose. That would be useful. I'll get on to it but it won't be before the end of the weekend I'd say. I've committed some changes to SVN trunk now to allow g.proj to compile with reduced functionality if HAVE_OGR is not defined. Also, is there any fundamental obstacle to being able to set the projection information using PROJ parameters without going via OSR? Given that GRASS uses PROJ for the actual projection, it shouldn't actually need anything other than PROJ parameters. g.setproj doesn't use any lib/proj functions except GPJ_ask_datum_params() (which no longer exists). The main issue is the short ellipsoid names, which can be quite different. I believe the GRASS ellipse.table pre-dates the integration of PROJ into GRASS in the early 1990s. OSR understands the PROJ ellipsoid names, so at present it is used to get the underlying ellipsoid dimensions, which are then matched against the GRASS ellipse.table to find the corresponding GRASS ellipsoid name. I suppose we could add a list of GRASS ellipsoid names and PROJ equivalents somewhere as a way around this. Datum names would also be a problem, but a very small one as PROJ only supports 10 named datums. One of these is not in GRASS and could be added, 5 of the others have exactly the same short name, and the other 4 differ only in the case of the letters (PROJ- upper case, GRASS- lower case). So if an additional field was added to ellipse.table with a PROJ-compatible name, datum GGRS87 was added to GRASS, and PROJ datum names were converted to lower case before being imported into GRASS, it should be possible to write an OSR-independent function in lib/proj/convert.c to convert from PROJ to GRASS format (the OSR-dependent parts of lib/proj are already conditionalised on HAVE_OGR; there would be no problem in adding more functions outside of that). Been thinking about this a bit more and a more fundamental problem than the ellipsoid and datum names is the lack of validation of the PROJ.4 parameters that would be possible. All g.proj could do would be to pass the parameters into the PROJ_INFO and PROJ_UNITS unchanged and any problems would only show up when they were used for reprojection. I'm not sure how good the error checking is there as it assumes that the PROJ_INFO and PROJ_UNITS are valid. g.setproj always creates a valid file because it composes the parameters from a set list. g.proj currently uses OGR to parse and validate the PROJ parameters before converting them to a PROJ_INFO and PROJ_UNITS. So I feel that modifying g.proj to read a set of PROJ parameters and pass them directly into PROJ_INFO and PROJ_UNITS would lose a piece of functionality, i.e. validating the co-ordinate system. And it still would be complicated. At the minute I think it needs a bit more thought or discussion. Paul ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: r.external - was: Re: [GRASS-dev] some questions about future development
Paul Kelly wrote: Also, is there any fundamental obstacle to being able to set the projection information using PROJ parameters without going via OSR? Been thinking about this a bit more and a more fundamental problem than the ellipsoid and datum names is the lack of validation of the PROJ.4 parameters that would be possible. All g.proj could do would be to pass the parameters into the PROJ_INFO and PROJ_UNITS unchanged and any problems would only show up when they were used for reprojection. I'm not sure how good the error checking is there as it assumes that the PROJ_INFO and PROJ_UNITS are valid. g.setproj always creates a valid file because it composes the parameters from a set list. So, it looks like I need to cannibalise g.setproj so that there is still a way to set projection parameters in the absence of OSR. -- Glynn Clements [EMAIL PROTECTED] ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: r.external - was: Re: [GRASS-dev] some questions about future development
Paul Kelly wrote: AFAICT, the only core GDAL dependencies are the OSR stuff in lib/proj and g.proj, and the vector library's support for v.external. In which case, it really ought to be possible to get a usable version of GRASS with no GDAL dependency in any of the libraries or core modules (e.g. g.proj, g.region). It used to be possible to compile g.proj without GDAL support, and use it only for reporting on the projection information and verifying datum information, but I removed all the conditional stuff for that when GDAL became a non-optional dependency. Could be put back in I suppose. That would be useful. Also, is there any fundamental obstacle to being able to set the projection information using PROJ parameters without going via OSR? Given that GRASS uses PROJ for the actual projection, it shouldn't actually need anything other than PROJ parameters. g.setproj doesn't use any lib/proj functions except GPJ_ask_datum_params() (which no longer exists). -- Glynn Clements [EMAIL PROTECTED] ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: r.external - was: Re: [GRASS-dev] some questions about future development
On Thu, 21 Aug 2008, Glynn Clements wrote: Paul Kelly wrote: AFAICT, the only core GDAL dependencies are the OSR stuff in lib/proj and g.proj, and the vector library's support for v.external. In which case, it really ought to be possible to get a usable version of GRASS with no GDAL dependency in any of the libraries or core modules (e.g. g.proj, g.region). It used to be possible to compile g.proj without GDAL support, and use it only for reporting on the projection information and verifying datum information, but I removed all the conditional stuff for that when GDAL became a non-optional dependency. Could be put back in I suppose. That would be useful. I'll get on to it but it won't be before the end of the weekend I'd say. Also, is there any fundamental obstacle to being able to set the projection information using PROJ parameters without going via OSR? Given that GRASS uses PROJ for the actual projection, it shouldn't actually need anything other than PROJ parameters. g.setproj doesn't use any lib/proj functions except GPJ_ask_datum_params() (which no longer exists). The main issue is the short ellipsoid names, which can be quite different. I believe the GRASS ellipse.table pre-dates the integration of PROJ into GRASS in the early 1990s. OSR understands the PROJ ellipsoid names, so at present it is used to get the underlying ellipsoid dimensions, which are then matched against the GRASS ellipse.table to find the corresponding GRASS ellipsoid name. I suppose we could add a list of GRASS ellipsoid names and PROJ equivalents somewhere as a way around this. Datum names would also be a problem, but a very small one as PROJ only supports 10 named datums. One of these is not in GRASS and could be added, 5 of the others have exactly the same short name, and the other 4 differ only in the case of the letters (PROJ- upper case, GRASS- lower case). So if an additional field was added to ellipse.table with a PROJ-compatible name, datum GGRS87 was added to GRASS, and PROJ datum names were converted to lower case before being imported into GRASS, it should be possible to write an OSR-independent function in lib/proj/convert.c to convert from PROJ to GRASS format (the OSR-dependent parts of lib/proj are already conditionalised on HAVE_OGR; there would be no problem in adding more functions outside of that). Paul ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: r.external - was: Re: [GRASS-dev] some questions about future development
Markus Neteler wrote: Null support is missing (r.external records any null value reported by GDAL, but G_get_raster_row() etc ignore it; I suspect that it will treat zero as null due to the absence of a null file). Null support has been added. I have now tested (in my local 6.4 backport) a shaded terrain map (GeoTIFF). The 0 pixels are registered as NULL pixels, leading to white areas instead of black in case of cast terrain shadow. So I confirm that zero is treated as NULL now. Could the GDAL Null value be used instead? Null support was added in r32924, and seems to work. Ha - I missed to backport this one. Excellent, it now works fine in my local backport, too. So: any objections to submit this new feature/module? Is it really wise to include it in 6.4? At a minimum, we should probably add some more checks so that versions built without this feature fail more gracefully (i.e. produce a more useful error message). -- Glynn Clements [EMAIL PROTECTED] ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] some questions about future development
Glynn Clements pisze: Markus Neteler wrote: BTW, a r.external would be a great addition. Yes, see: http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_5_4/gips/gip-0002.txt Still not implemented... next GSoC project? It's not that much work. I have attached a first draft patch which adds the essential support to lib/gis. It has only been minimally tested, but seems to work. To test: 1. Copy a raster map. 2. Export it to an image at its native resolution. 3. Create a cell_misc/name/gdal file consisting of two lines: the filename followed by the band number. 4. Edit the cellhd/name file so that compressed is 0, and (if it's a CELL map) format is 3. 5. Run r.support -s name to update the range. Tomorrow, I'll look into creating an r.external module, adding null support, etc. Great! Finally there would be no need to import rasters if they are to be used only as a backdrop for digitising. If the external GeoTIFF has overviews, will r.external support them? Will they speed up such map's display in GRASS? Maciek -- Maciej Sieczka www.sieczka.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] some questions about future development
Glynn Clements wrote: BTW, a r.external would be a great addition. Yes, see: http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_5_4/gips/gip-0002.txt Still not implemented... next GSoC project? It's not that much work. I have attached a first draft patch which adds the essential support to lib/gis. It has only been minimally tested, but seems to work. To test: 1. Copy a raster map. 2. Export it to an image at its native resolution. 3. Create a cell_misc/name/gdal file consisting of two lines: the filename followed by the band number. 4. Edit the cellhd/name file so that compressed is 0, and (if it's a CELL map) format is 3. 5. Run r.support -s name to update the range. Tomorrow, I'll look into creating an r.external module, adding null support, etc. Okay, done (well, enough to try it out without having to manually hack the files; null support is absent). At present, r.external is built automatically, but the code to read linked maps is conditionalised upon GDAL_LINK, so you need to build with make GDAL_LINK=1. If you forget that part, r.external will work, but attempting to read the map will fail (the cell/fcell files are zero-length). $ r.external help Description: Link GDAL supported raster file to a binary raster map layer. Keywords: raster, import Usage: r.external [-oef] [input=name] [output=name] [band=value] [title=phrase] [--overwrite] [--verbose] [--quiet] Flags: -o Override projection (use location's projection) -e Extend location extents based on new dataset -f List supported formats and exit --o Allow output files to overwrite existing files --v Verbose module output --q Quiet module output Parameters: input Raster file to be linked output Name for output raster map band Band to select default: 1 title Title for resultant raster map Much of the code was salvaged from r.in.gdal, along with some of the behaviour. E.g. if you link a non-georeferenced file into a georeferenced (non-X/Y) location, you'll get an error about the projection mismatch unless you also use -o. The range, colour table and any geo-referencing information are taken from the original data. A title can be given with title=, and an auto-generated history (G_short_history(), G_command_history()) is added. No histogram is generated (use r.support -s if you want one). I daresay that something this fundamental will need significant testing. Known issues at present: Null support is missing (r.external records any null value reported by GDAL, but G_get_raster_row() etc ignore it; I suspect that it will treat zero as null due to the absence of a null file). The code which retrieves the range tells GDAL that approximate values will suffice (requiring exact values requires reading the entire map, in which case you may as well just use r.in.gdal). No attempt is made to detect any changes to the underlying file. I don't even know if this is possible, given that the details of which files make up a GDAL data source are known only unto GDAL. The input= parameter is stored verbatim. If this is a file (rather than some non-file data source), you probably want to ensure that it's an absolute pathname, otherwise the map will cease to work if you change directory. Actually, the input= option is tagged as old_file, so non-file data sources won't work. If the original data is GDT_UInt32, it's still treated as a CELL map, even though CELL is signed. If the input has values above 2^32-1, they will wrap. GDT_UInt16 should work correctly, though. Complex types aren't supported. The r.in.gdal source implies that AVHRR data needs to be flipped top-to-bottom; this isn't implemented. -- Glynn Clements [EMAIL PROTECTED] ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
r.external - was: Re: [GRASS-dev] some questions about future development
Glynn, this is excellent! Thanks so much. I have tested it but no success yet: On Wed, Aug 20, 2008 at 1:46 PM, Glynn Clements [EMAIL PROTECTED] wrote: Glynn Clements wrote: BTW, a r.external would be a great addition. It's not that much work. ... Tomorrow, I'll look into creating an r.external module, adding null support, etc. Okay, done (well, enough to try it out without having to manually hack the files; null support is absent). [for my convenience I have copied it over to GRASS 6.4.svn locally] GRASS 6.4.svn (pat):~ gdalinfo /geodata2_originals_raid5/pat_OFD_RGB_IT2006_GB/060100.tif Driver: GTiff/GeoTIFF Files: /geodata2_originals_raid5/pat_OFD_RGB_IT2006_GB/060100.tif Size is 13440, 11760 Coordinate System is: PROJCS[Monte Mario / Italy zone 1, GEOGCS[Monte Mario, DATUM[Monte_Mario, SPHEROID[International 1924,6378388,297.00014, AUTHORITY[EPSG,7022]], AUTHORITY[EPSG,6265]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433], AUTHORITY[EPSG,4265]], PROJECTION[Transverse_Mercator], PARAMETER[latitude_of_origin,0], PARAMETER[central_meridian,9], PARAMETER[scale_factor,0.9996], PARAMETER[false_easting,150], PARAMETER[false_northing,0], UNIT[metre,1, AUTHORITY[EPSG,9001]], AUTHORITY[EPSG,3003]] Origin = (1660920.000,5107440.000) Pixel Size = (0.500,-0.500) Metadata: AREA_OR_POINT=Area TIFFTAG_SOFTWARE=Adobe Photoshop CS2 Macintosh TIFFTAG_DATETIME=2007:03:01 06:12:15 TIFFTAG_XRESOLUTION=72 TIFFTAG_YRESOLUTION=72 TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch) Image Structure Metadata: INTERLEAVE=PIXEL Corner Coordinates: Upper Left ( 1660920.000, 5107440.000) ( 11d 4'54.85E, 46d 6'2.53N) Lower Left ( 1660920.000, 5101560.000) ( 11d 4'47.69E, 46d 2'52.14N) Upper Right ( 1667640.000, 5107440.000) ( 11d10'7.61E, 46d 5'56.71N) Lower Right ( 1667640.000, 5101560.000) ( 11d10'0.15E, 46d 2'46.33N) Center ( 1664280.000, 5104500.000) ( 11d 7'27.57E, 46d 4'24.46N) Band 1 Block=13440x1 Type=Byte, ColorInterp=Red Overviews: 6720x5880, 3360x2940, 1680x1470, 840x735, 420x368, 210x184 Band 2 Block=13440x1 Type=Byte, ColorInterp=Green Overviews: 6720x5880, 3360x2940, 1680x1470, 840x735, 420x368, 210x184 Band 3 Block=13440x1 Type=Byte, ColorInterp=Blue Overviews: 6720x5880, 3360x2940, 1680x1470, 840x735, 420x368, 210x184 GRASS 6.4.svn (pat):~ r.external /geodata2_originals_raid5/pat_OFD_RGB_IT2006_GB/060100.tif out=ortho_trento Projection of input dataset and current location appear to match ortho_trento created r.external complete. GRASS 6.4.svn (pat):~ g.region rast=ortho_trento -p projection: 99 (Transverse Mercator) zone: 0 datum: rome40 ellipsoid: international north: 5107440 south: 5101560 west: 1660920 east: 1667640 nsres: 0.5 ewres: 0.5 rows: 11760 cols: 13440 cells: 158054400 GRASS 6.4.svn (pat):~ d.rast ortho_trento WARNING: Error reading map [EMAIL PROTECTED], row 0 100% r.info -r ortho_trento WARNING: category support for [ortho_trento] in mapset [PERMANENT] missing min=NULL max=NULL GRASS 6.4.svn (pat):~ r.support ortho_trento Edit header for [ortho_trento]? (y/n) [n] Update the statistics (histogram, range) for [ortho_trento]? (y/n) [n] y Updating statistics for [ortho_trento] WARNING: Error reading map [EMAIL PROTECTED], row 0 WARNING: Histogram for [ortho_trento in PERMANENT] missing (run r.support) Edit the category file for [ortho_trento]? (y/n) [n] Create/Update the color table for [ortho_trento]? (y/n) [n] Edit the history file for [ortho_trento]? (y/n) [n] The null file for [ortho_trento] may indicate that some cells contain no data. If the null file for [ortho_trento] doesn't exist, zero cells in it are treated by GRASS application programs as no data. Do you want to create/reset the null file for [ortho_trento] so that null cell values are considered valid data? (y/n) [n] Do you want to delete the null file for [ortho_trento] (all zero cells will then be considered no data)? (y/n) [n] GRASS 6.4.svn (pat):~ ls -la grassdata/pat/PERMANENT/cell_misc/ortho_trento/ total 86 drwxrwxr-x 2 neteler neteler 1024 2008-08-20 13:49 . drwx---r-x 8 neteler neteler 84992 2008-08-20 13:49 .. -rw-rw-r-- 1 neteler neteler92 2008-08-20 13:49 gdal -rw-rw-r-- 1 neteler neteler 0 2008-08-20 13:49 range GRASS 6.4.svn (pat):~ cat grassdata/pat/PERMANENT/cell_misc/ortho_trento/gdal file: /geodata2_originals_raid5/pat_OFD_RGB_IT2006_GB/060100.tif band: 1 null: none type: 1 GRASS 6.4.svn (pat):~ cat grassdata/pat/PERMANENT/cellhd/ortho_trento proj: 99 zone: 0 north: 5107440 south: 5101560 east: 1667640 west: 1660920 cols: 13440 rows: 11760 e-w resol: 0.5 n-s resol: 0.5 format: 0 compressed: 0 The same happens with a GeoTIFF without overviews.. And the same happens in GRASS
Re: r.external - was: Re: [GRASS-dev] some questions about future development
Markus Neteler wrote: this is excellent! Thanks so much. I have tested it but no success yet: Tomorrow, I'll look into creating an r.external module, adding null support, etc. Okay, done (well, enough to try it out without having to manually hack the files; null support is absent). [for my convenience I have copied it over to GRASS 6.4.svn locally] Copied what over? r.external won't work unless the corresponding lib/gis changes have also been incorporated, and lib/gis was built with GDAL_LINK=1: At present, r.external is built automatically, but the code to read linked maps is conditionalised upon GDAL_LINK, so you need to build with make GDAL_LINK=1. If you forget that part, r.external will work, but attempting to read the map will fail (the cell/fcell files are zero-length). Your errors are consistent with lib/gis not having the necessary support. Does: nm $GISBASE/lib/libgrass_gis.so | fgrep gdal produce any output? There should be at least: T G_close_gdal_link T G_get_gdal_link t gdal_values_double t gdal_values_float t gdal_values_int t read_data_gdal -- Glynn Clements [EMAIL PROTECTED] ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] some questions about future development
Glynn Clements wrote: Known issues at present: Null support is missing (r.external records any null value reported by GDAL, but G_get_raster_row() etc ignore it; I suspect that it will treat zero as null due to the absence of a null file). Null support has been added. The code which retrieves the range tells GDAL that approximate values will suffice (requiring exact values requires reading the entire map, in which case you may as well just use r.in.gdal). r.external now has a -r flag to tell GDAL to compute the exact range rather than an approximation. -- Glynn Clements [EMAIL PROTECTED] ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: r.external - was: Re: [GRASS-dev] some questions about future development
On Wed, Aug 20, 2008 at 3:46 PM, Glynn Clements [EMAIL PROTECTED] wrote: Markus Neteler wrote: this is excellent! Thanks so much. I have tested it but no success yet: Tomorrow, I'll look into creating an r.external module, adding null support, etc. Okay, done (well, enough to try it out without having to manually hack the files; null support is absent). [for my convenience I have copied it over to GRASS 6.4.svn locally] Copied what over? r.external won't work unless the corresponding lib/gis changes have also been incorporated, and lib/gis was built with GDAL_LINK=1: At present, r.external is built automatically, but the code to read linked maps is conditionalised upon GDAL_LINK, so you need to build with make GDAL_LINK=1. If you forget that part, r.external will work, but attempting to read the map will fail (the cell/fcell files are zero-length). Bingo. I overlooked the GDAL_LINK thing. Your errors are consistent with lib/gis not having the necessary support. Right. Now r.stats works! Will try to (locally) backport to 6.4 now (for monitor tests). Thanks again, Markus PS: Small issue: gcc -I/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include -g -Wall -fno-common -mtune=nocona -m64 -minline-all-stringops-fPIC -D_FILE_OFFSET_BITS=64 -DGDAL_LINK -DPACKAGE=\grasslibs\ -I/usr/local/include -I/usr/local/include -I/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include -o OBJ.x86_64-unknown-linux-gnu/quant.o -c quant.c quant.c:293:1: warning: MIN redefined In file included from /usr/local/include/gdal.h:40, from /home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include/grass/gis.h:32, from quant.c:286: /usr/local/include/cpl_port.h:257:1: warning: this is the location of the previous definition quant.c:294:1: warning: MAX redefined /usr/local/include/cpl_port.h:258:1: warning: this is the location of the previous definition ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: r.external - was: Re: [GRASS-dev] some questions about future development
On Wed, Aug 20, 2008 at 5:34 PM, Markus Neteler [EMAIL PROTECTED] wrote: On Wed, Aug 20, 2008 at 3:46 PM, Glynn Clements [EMAIL PROTECTED] wrote: Markus Neteler wrote: ... Copied what over? r.external won't work unless the corresponding lib/gis changes have also been incorporated, and lib/gis was built with GDAL_LINK=1: I have now backported all to GRASS 6.4.svn (locally) including the fixes of the last 2 hours (MAX etc fixes). ... Now r.stats works! Will try to (locally) backport to 6.4 now (for monitor tests). Done. COOL STUFF. I linked a GeoTIFF RGB orthophoto (600MB) and d.rgb works sufficiently fast. Any objections that I submit the backport? I assume that later the GDAL_LINK condition will become default? Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] some questions about future development
Michael: I haven't calculated the size of the wxPython code base, but when I checked about a year ago, the TclTk code took up over 18,000 lines of code. The many C modules are what makes GRASS 'work' and Martin: Python code: more them 37,000 lines C++ code: almost 30,000 lines very roughly, just `wc -l`. Hamish: better to use sloccount: http://article.gmane.org/gmane.comp.gis.grass.devel/24729/ (6 months ago) http://article.gmane.org/gmane.comp.gis.grass.devel/4498/ (4 yrs today) also see Ohloh counts: http://www.ohloh.net/projects/grass_gis/analyses/latest Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] some questions about future development
See my suggested enhancements for vector querying (dev mail archives of a couple weeks back and in TRAC). It would make such highlighting much easier. Michael C. Michael Barton, Professor of Anthropology Director of Graduate Studies School of Human Evolution Social Change Center for Social Dynamics Complexity Arizona State University Phone: 480-965-6262 Fax: 480-965-7671 www: www.public.asu.edu/~cmbarton On Aug 19, 2008, at 1:10 AM, Hamish wrote: 2 - geometry highlighting: when selecting features from the attributes table (wxGUI), it would be nice to make the geometries highlighted in the map window... See next section. Martin: in my TODO for next week ;-) see also 'd.what.vect -f' with xmons Michael: I haven't calculated the size of the wxPython code base, but when I checked about a year ago, the TclTk code took up over 18,000 lines of code. The many C modules are what makes GRASS 'work' and Python code: more them 37,000 lines C++ code: almost 30,000 lines very roughly, just `wc -l`. better to use sloccount: http://article.gmane.org/gmane.comp.gis.grass.devel/24729/ (6 months ago) http://article.gmane.org/gmane.comp.gis.grass.devel/4498/ (4 yrs today) Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] some questions about future development
On Mon, Aug 18, 2008 at 10:30 AM, Paolo Cavallini [EMAIL PROTECTED] wrote: ... BTW, a r.external would be a great addition. Yes, see: http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_5_4/gips/gip-0002.txt Still not implemented... next GSoC project? Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] some questions about future development
Markus Neteler wrote:
BTW, a r.external would be a great addition.
Yes, see:
http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_5_4/gips/gip-0002.txt
Still not implemented... next GSoC project?
It's not that much work.
I have attached a first draft patch which adds the essential support
to lib/gis. It has only been minimally tested, but seems to work.
To test:
1. Copy a raster map.
2. Export it to an image at its native resolution.
3. Create a cell_misc/name/gdal file consisting of two lines: the
filename followed by the band number.
4. Edit the cellhd/name file so that compressed is 0, and (if it's
a CELL map) format is 3.
5. Run r.support -s name to update the range.
Tomorrow, I'll look into creating an r.external module, adding null
support, etc.
--
Glynn Clements [EMAIL PROTECTED]
Index: lib/gis/opencell.c
===
--- lib/gis/opencell.c (revision 32899)
+++ lib/gis/opencell.c (working copy)
@@ -159,6 +159,9 @@
RASTER_MAP_TYPE MAP_TYPE;
struct Reclass reclass;
char xname[GNAME_MAX], xmapset[GMAPSET_MAX];
+#ifdef GDAL_LINK
+struct GDAL_link *gdal;
+#endif
/* make sure window is set*/
G__init_window();
@@ -252,6 +255,13 @@
MAP_NBYTES = CELL_nbytes;
}
+#ifdef GDAL_LINK
+gdal = G_get_gdal_link(name, mapset);
+if (gdal)
+ /* dummy descriptor to reserve the fileinfo slot */
+ fd = open(/dev/null, O_RDONLY);
+else
+#endif
/* now actually open file for reading */
fd = G_open_old(cell_dir, r_name, r_mapset);
if (fd 0)
@@ -287,6 +297,11 @@
if ((fcb-reclass_flag = reclass_flag))
G_copy(fcb-reclass, reclass, sizeof(reclass));
+#ifdef GDAL_LINK
+if (gdal)
+ fcb-gdal = gdal;
+else
+#endif
/* check for compressed data format, making initial reads if necessary */
if (G__check_format(fd) 0) {
close(fd); /* warning issued by check_format() */
Index: lib/gis/G.h
===
--- lib/gis/G.h (revision 32899)
+++ lib/gis/G.h (working copy)
@@ -44,6 +44,9 @@
unsigned char *null_work_buf; /* data buffer for reading null rows
*/
int min_null_row; /* Minimum row null row number in memory */
struct Quant quant;
+#ifdef GDAL_LINK
+struct GDAL_link *gdal;
+#endif
};
struct G__ /* Structure of library globals */
Index: lib/gis/get_row.c
===
--- lib/gis/get_row.c (revision 32899)
+++ lib/gis/get_row.c (working copy)
@@ -198,12 +198,35 @@
/*--*/
+#ifdef GDAL_LINK
+static int read_data_gdal(int fd, int row, unsigned char *data_buf, int
*nbytes)
+{
+struct fileinfo *fcb = G__.fileinfo[fd];
+CPLErr err;
+
+*nbytes = fcb-nbytes;
+
+err = GDALRasterIO(
+ fcb-gdal-band, GF_Read, 0, row, fcb-cellhd.cols, 1, data_buf,
+ fcb-cellhd.cols, 1, fcb-gdal-type, 0, 0);
+
+return err == CE_None ? 0 : -1;
+}
+#endif
+
+/*--*/
+
/* Actually read a row of data in */
static int read_data(int fd, int row, unsigned char *data_buf, int *nbytes)
{
struct fileinfo *fcb = G__.fileinfo[fd];
+#ifdef GDAL_LINK
+if (fcb-gdal)
+ return read_data_gdal(fd, row, data_buf, nbytes);
+#endif
+
if (!fcb-cellhd.compressed)
return read_data_uncompressed(fd, row, data_buf, nbytes);
@@ -352,6 +375,36 @@
/*--*/
+static void cell_values_raw(const unsigned char *data,
+ const COLUMN_MAPPING *cmap, int nbytes,
+ void *cell, int n)
+{
+unsigned char *c = cell;
+const unsigned char *d;
+COLUMN_MAPPING cmapold = 0;
+int i;
+
+for (i = 0; i n; i++) {
+ if (!cmap[i]) {
+ memset(c + i*nbytes, 0, nbytes);
+ continue;
+ }
+
+ if (cmap[i] == cmapold) {
+ memcpy(c + i*nbytes, c + (i-1)*nbytes, nbytes);
+ continue;
+ }
+
+ d = data + (cmap[i] - 1) * nbytes;
+
+ memcpy(c + i*nbytes, d, nbytes);
+
+ cmapold = cmap[i];
+}
+}
+
+/*--*/
+
/* transfer_to_cell_XY takes bytes from fcb-data, converts these bytes with
the appropriate procedure (e.g. XDR or byte reordering) into type X
values which are put into array G__.work_buf.
@@ -370,6 +423,11 @@
cell_values_int, cell_values_float, cell_values_double};
struct fileinfo *fcb = G__.fileinfo[fd];
+#ifdef GDAL_LINK
+if (fcb-gdal)
+ cell_values_raw(fcb-data, fcb-col_map, fcb-cur_nbytes, cell,
G__.window.cols);
+else
+#endif
(cell_values_type[fcb-map_type]) (fd,
[GRASS-dev] some questions about future development
Hi to everyone. In the last period I've been working a lot with GRASS for my daily job, and it permitted me to develop a series of wishes for the future... I will share them in the GRASS 7 ideas collection but I would like to ask some questions before: VECTORS 1 - OGR datasources: one important GIS functionality in daily work is the possibility to access shapefiles, and other simple feature datas (PostGIS, Oracle Spatial, etc.) directly, without having to import them and/or building the topology. Many times these datas are simply used for visualization (geometries and attributes), or table attributes management... I've seen it is already in the Radim's TODO list [1]. Is it a priority in GRASS 7 development, or it is left as a minor enhancement? 2 - geometry highlighting: when selecting features from the attributes table (wxGUI), it would be nice to make the geometries highlighted in the map window... See next section. 3 - vectors/thematic vectors: it happens only in GRASS that these two are separated. Wouldn't be better to merge into a single display command with thmatic styiling as options? MAP CANVAS the user experience with the maps should be enhanced: 1 - when zooming, incremental resolution would be nice (pyramids for rasters?) 2 - when panning, only the new areas should be added (a sort of tiling) 3 - geometry selection (like with identify tools, or polygonal selection tools) -view selected features inside the table attributes, and viceversa I know it is quite distant from the actual display architecture, but it would be an important improvement from my point of view... Do you think it will be feasible considering the rodmap you've planned? Ok, it's enough for now. I would have many other proposals, but I will share them in the future :) Giovanni [1] http://freegis.org/cgi-bin/viewcvs.cgi/grass6/doc/vector/TODO?rev=HEADcontent-type=text/vnd.viewcvs-markup ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] some questions about future development
G. Allegri ha scritto: 1 - OGR datasources: one important GIS functionality in daily work is the possibility to access shapefiles, and other simple feature datas (PostGIS, Oracle Spatial, etc.) directly, without having to import them and/or building the topology. Many times these datas are simply used for visualization (geometries and attributes), or table attributes management... I've seen it is already in the Radim's TODO list [1]. Is it a priority in GRASS 7 development, or it is left as a minor enhancement? v.external? http://grass.itc.it/grass62/manuals/html62_user/v.external.html BTW, a r.external would be a great addition. All the best. pc -- Paolo Cavallini, see: * http://www.faunalia.it/pc * ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] some questions about future development
v.external? http://grass.itc.it/grass62/manuals/html62_user/v.external.html BTW, a r.external would be a great addition. Hi Paolo, I know v.external, but It's still a bit far from what the user experience is in, let's say, Qgis/uDig/gvSIG/etc. The main restriction is that it's read-only. It would be an important improvement having (at least) attributes and table management for shapefiles. The pseudo-topoligy building is too slow for what this feature is for: not allowing spatial operations, or any other geoprocessing, but just visualization and attributes management... I would expect something like Add datasource and (in wxGUI) having it displayed in the Layer Manager. Just ideas... I know it's not so simple :) ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] some questions about future development
On Aug 18, 2008, at 1:25 AM, [EMAIL PROTECTED] wrote: Date: Mon, 18 Aug 2008 10:25:30 +0200 From: G. Allegri [EMAIL PROTECTED] Subject: [GRASS-dev] some questions about future development To: GRASS developers list grass-dev@lists.osgeo.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 Hi to everyone. In the last period I've been working a lot with GRASS for my daily job, and it permitted me to develop a series of wishes for the future... I will share them in the GRASS 7 ideas collection but I would like to ask some questions before: VECTORS 1 - OGR datasources: one important GIS functionality in daily work is the possibility to access shapefiles, and other simple feature datas (PostGIS, Oracle Spatial, etc.) directly, without having to import them and/or building the topology. Many times these datas are simply used for visualization (geometries and attributes), or table attributes management... I've seen it is already in the Radim's TODO list [1]. Is it a priority in GRASS 7 development, or it is left as a minor enhancement? 2 - geometry highlighting: when selecting features from the attributes table (wxGUI), it would be nice to make the geometries highlighted in the map window... See next section. 3 - vectors/thematic vectors: it happens only in GRASS that these two are separated. Wouldn't be better to merge into a single display command with thmatic styiling as options? MAP CANVAS the user experience with the maps should be enhanced: 1 - when zooming, incremental resolution would be nice (pyramids for rasters?) 2 - when panning, only the new areas should be added (a sort of tiling) 3 - geometry selection (like with identify tools, or polygonal selection tools) -view selected features inside the table attributes, and viceversa I know it is quite distant from the actual display architecture, but it would be an important improvement from my point of view... Do you think it will be feasible considering the rodmap you've planned? Ok, it's enough for now. I would have many other proposals, but I will share them in the future :) Just a note to the development team. Except for #1, these are all GUI/ interface issues. I haven't calculated the size of the wxPython code base, but when I checked about a year ago, the TclTk code took up over 18,000 lines of code. The many C modules are what makes GRASS 'work' and makes it a powerful spatial data management and analysis tool. But the GUI is the 'face' that most people see and work with on a daily basis. Glynn's rewrite of the display architecture will have an important effect on the way the GUI connects with modules. But there is still an awful lot of wxPython code to enhance, maintain, and still to write. So if any of you would like to try your hand at Python and wxPython, we'd welcome another volunteer or two to the GUI development team. Michael ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] some questions about future development
Hi, 2008/8/18 Michael Barton [EMAIL PROTECTED]: 2 - geometry highlighting: when selecting features from the attributes table (wxGUI), it would be nice to make the geometries highlighted in the map window... See next section. in my TODO for next week ;-) Just a note to the development team. Except for #1, these are all GUI/interface issues. I haven't calculated the size of the wxPython code base, but when I checked about a year ago, the TclTk code took up over 18,000 lines of code. The many C modules are what makes GRASS 'work' and Python code: more them 37,000 lines C++ code: almost 30,000 lines very roughly, just `wc -l`. makes it a powerful spatial data management and analysis tool. But the GUI is the 'face' that most people see and work with on a daily basis. Glynn's rewrite of the display architecture will have an important effect on the way the GUI connects with modules. But there is still an awful lot of wxPython code to enhance, maintain, and still to write. So if any of you would like to try your hand at Python and wxPython, we'd welcome another volunteer or two to the GUI development team. definitely we need more people to contribute not only in wxGUI development but especially for GRASS7 core changes... Martin -- Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa * ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] some questions about future development
Hi, 2008/8/18 Martin Landa [EMAIL PROTECTED]: [...] C++ code: almost 30,000 lines sorry, I forgot to exclude cpp file generated by swig, then C++ code: about 5,000 lines Time for my towel;-) Martin -- Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa * ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
