[GRASS-user] How much training areas is enough?
Hi,
In doing remote sensing classification, we are advised that more
training areas is best, but how much really? There must be a threshold
where it is pointless to add more since it will not contribute
significantly to the classifcation process.
I would like to ask what are the standards/best practices in defining
and limiting training areas for classification in GRASS. Some
literature would advise 100 pixels per infomation class. Are there standards?
For example, I have an image composed of {x} number bands of
approximately {y} hectares that I need to classify to {z} classes.
How much training area should be sufficient?
Any ideas?
cheers,
maning
--
|-|--|
| __.-._ |Ohhh. Great warrior. Wars not make one great. -Yoda |
| '-._7' |Freedom is still the most radical idea of all -N.Branden|
| /'.-c |Linux registered user #402901, http://counter.li.org/ |
| | /T |http://esambale.wikispaces.com|
| _)_/LI
|-|--|
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Open Source Remote Sensing at AGU
Posted on behalf of H. Mitasova / D. Pilant -- Dear Open Source Remote Sensing and Geospatial Colleagues, Please consider submitting an abstract for this open source remote sensing session at the American Geophysical Union (AGU) Meeting December 15-19, 2008 in San Francisco. It will be a great opportunity to promote and learn about open source remote sensing in a vibrant international earth science community (estimated 15,000 attendees). Session Name: IN24: Open Source Remote Sensing for Environmental Mapping and Analysis Session URL: http://www.agu.org/meetings/fm08/? content=searchshow=detailsessid=586 AGU Abstract Submission URL: http://www.agu.org/meetings/fm08/ (Please reference session IN24, and note the abstract submission deadline: September 10, 2008) Session Abstract: Anthropogenic and natural pressures on ecosystems and environments threaten human and ecological health at many levels. Remote sensing analysis of aerial photography and satellite imagery provides views of the environment necessary for sound environmental stewardship. Unprecedented amounts of earth imagery are now available on our desktops through data portals and virtual earths, and many open source geographic information system (GIS) applications are available. However, there is a great need for free or low cost, easy to use remote sensing software tools to help non-geospatial-experts make better use of these image resources to enhance environmental mapping and analysis. The goal of this session is to highlight open source remote sensing tools and applications in environmental analysis. How are open source remote sensing tools being used in environmental analysis (e.g., land cover mapping; change detection; disaster recovery; habitat analysis; impervious surface mapping)? Are remote sensing mapping algorithms incorporated in virtual earths to expand their analytical capability? Can we develop easy to use open source decision support tools to help guide environmental decision making at the national, regional, local and citizen levels? How can we better harness the observations of citizens informed about their local environments in a geospatially- enabled manner? Thank you for your kind attention, and please forward this announcement to any interested colleagues. Sincerely, Drew Pilant, Ph.D. US Environmental Protection Agency Office of Research and Development Landscape Characterization Branch tel: 919.541.0648 fax: 919.541.9420 [EMAIL PROTECTED] ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Novice Query: Grass63, Cygwin on Windows startup errors, Error setting region (Problem with g.region: child process exited abnormally)
Katie Urey A reinstall of cygwin and grass63 seemed the best route. And, now all sorts of grass63 windows open just fine. great. My hunch (not proven) is that I had skipped this step in the install. It might help future installers if the source of #3 and #5 steps is clarified. For installation of Cygwin, see http://geni.ath.cx/grass.html#toc5. These instructions can be used, but at step #3 use http://grass.ibiblio.org/grass62/binary/mswindows/ (or a local mirror http://grass.ibiblio.org/mirrors.php) instead of http://geni.ath.cx/grass. Also, in step #5 the version is 6.2.2-1 instead of 6.0.cvs-1, and there's no grass.bat script. I would note that the README.html on the website at http://grass.osgeo.org/grass62/binary/mswindows/ has not picked up SVN updates since January. (version is 6.2.2-1 above) http://trac.osgeo.org/grass/log/grass-web/trunk/grass62/binary/mswindows/README.html In the GRASS 6.3 cygwin install page that is updated, but probably not much clearer. Any suggestions for improved text? Now, with spearfish data installed, there's much to learn. And, more documentation to read. don't forget the search the wiki and reading the GRASS book is probably very helpful. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Novice Query: Grass63, Cygwin on Windows startup errors, Error setting region (Problem with g.region: child process exited abnormally)
On Tue, Sep 2, 2008 at 10:20 PM, Hamish [EMAIL PROTECTED] wrote: Katie Urey A reinstall of cygwin and grass63 seemed the best route. And, now all sorts of grass63 windows open just fine. great. My hunch (not proven) is that I had skipped this step in the install. It might help future installers if the source of #3 and #5 steps is clarified. For installation of Cygwin, see http://geni.ath.cx/grass.html#toc5. These instructions can be used, but at step #3 use http://grass.ibiblio.org/grass62/binary/mswindows/ (or a local mirror http://grass.ibiblio.org/mirrors.php) instead of http://geni.ath.cx/grass. Also, in step #5 the version is 6.2.2-1 instead of 6.0.cvs-1, and there's no grass.bat script. I would note that the README.html on the website at http://grass.osgeo.org/grass62/binary/mswindows/ has not picked up SVN updates since January. (version is 6.2.2-1 above) http://trac.osgeo.org/grass/log/grass-web/trunk/grass62/binary/mswindows/README.html Good observation! There was a leftover index.html in that directory which won the race against README.html. Now removed and it works: http://grass.osgeo.org/grass62/binary/mswindows/ Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] get modified date for raster layer
Hello all, I've got over 14k rasters in several mapsets that I need to store modified date in a db for tracking purposes. I've got the storage and retrieval worked out, but I don't see an clean (easy) way to get the modified date via a python script. So far I've come up with: - parse it out of r.info - get the modified date in the cellhd folder using os.stat The problems with these approaches: r.info - requires parsing, and I need to reformat the date in a way that's easily comparable. I'd prefer not to rely on parsing anyway. Would be nice to have shell script output option. os.stat (python) - has a nice date integer format, but it requires that I have the full path to the cellhd folder. Database and location are easy via g.gisenv, but getting the mapset on an individual layer basis isn't completely straightforward. I can use use g.mlist -m rast pattern=filename, but that essentially greps it out of a full list. Is there a more efficient way of getting the modified date of a raster layer? If not, getting the full path instead? Thanks, Jamie Adams ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] get modified date for raster layer
Jamie Adams [EMAIL PROTECTED] I've got over 14k rasters in several mapsets that I need to store modified date in a db for tracking purposes. I've got the storage and retrieval worked out, but I don't see an clean (easy) way to get the modified date via a python script. Is there a more efficient way of getting the modified date of a raster layer? If not, getting the full path instead? MAP=roads eval `g.findfile element=hist file=$MAP` head -n 1 $file It's stored as a text string; what you see is what you get. see also r.timestamp, but that is for map metadata not file creation timestamp. os.stat (python) - has a nice date integer format, but it requires that I have the full path to the cellhd folder. use g.findfile for that. Database and location are easy via g.gisenv, but getting the mapset on an individual layer basis isn't completely straightforward. I can use use g.mlist -m rast pattern=filename, but that essentially greps it out of a full list. I don't fully understand what you mean by those two. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] get modified date for raster layer
On Tue, Sep 2, 2008 at 6:42 PM, Hamish [EMAIL PROTECTED] wrote: Jamie Adams [EMAIL PROTECTED] I've got over 14k rasters in several mapsets that I need to store modified date in a db for tracking purposes. I've got the storage and retrieval worked out, but I don't see an clean (easy) way to get the modified date via a python script. Is there a more efficient way of getting the modified date of a raster layer? If not, getting the full path instead? MAP=roads eval `g.findfile element=hist file=$MAP` head -n 1 $file It's stored as a text string; what you see is what you get. see also r.timestamp, but that is for map metadata not file creation timestamp. os.stat (python) - has a nice date integer format, but it requires that I have the full path to the cellhd folder. use g.findfile for that. Ah okay, I never really understood that command. g.findfile element=cell file=filename | grep ^file returns what I need. Database and location are easy via g.gisenv, but getting the mapset on an individual layer basis isn't completely straightforward. I can use use g.mlist -m rast pattern=filename, but that essentially greps it out of a full list. I don't fully understand what you mean by those two. Yeah, it's a bit tough to explain with my processing setup. It's a non-issue now, g.findfile solved it. Thanks! Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
