headers
Edward Tomlinson | 1 Nov 2008 01:47
Picon

Newbie question: Reclassifying raster (ndvi) using fisher method

Hi all,
 
I am not sure as to which list this best fits (Grass or R-sig-geo).
 
I am trying to reclass a raster map (ndvi) into 5 different zones using the fisher method, ultimatley i am trying to reclass as natural breaks.
 
The point of this exercise is for precision agriculture. I want to determine management zones according to the current crop, so i can use this information for inputs for next years crop. Therefore i have no use for a range of ndvi values -1 thru 1. I need to split this into a number of zones (5 or 7 is good number, unless i can get an algorithm to determine the exact number of groups it needs). Each zone then in turn needs to be ground truthed (hence need for classifying into 5 or 7 zones).
 
My problem at the moment is that the way i am doing it takes a while... I would sure love it if anyone has any suggestions to speed up the process... Is it possible to do the reclass bit in R and export the raster (SpatialDataFrame) back into grass? I have read a post from Roger Bivand on how to do the whole classinterval thing (thank you Roger) however i am unsure of how then to create a new image from those values. I have looked through the sp package breifly but I dont very well understand the R system.
 
 
Current method (this has to be done for each paddock, or paddocks can be grouped if they have similar management history).
 
create ndvi
r.mapcalc 'ndvi=1.0*(nir-red)/(nir+red)'
move ndvi raster to R
-R-R-R-----------------
library(spgrass6)
G <- gmeta6()
ndvi <- readRAST6(ndvi <at> mapset)
library(classInt)
t1 <- classIntervals(ndvi$ndvi.mapset, n=5, style="fisher")
print(t1)
--------------------------------
create text document for reclass rules, multiply everything by 10,000,000 (as reclass will round my numbers)
-----------------------------
back in grass
r.mapcalc ndvi_10M = ndvi * 10000000
r.reclass input=ndvi_10M output=ndvi.reclass rules="rules created in text doc" title="title"
 
 
I hope this all makes sense. Thank you for your time and reading through my problem. If you have any suggestions i sure would be greatful.
 
Kind regards,
Ed
_______________________________________________
grass-user mailing list
grass-user <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Permalink | Reply | 0 comments |
headers
Glynn Clements | 1 Nov 2008 05:29

Re: using grass on rasters without converting?


Markus Neteler wrote:

> >> > I'm not too familiar with the WMS driver.  But if it doesn't support
> >> > skipping rows then it is a bug and should be fixed.  To file a ticket on
> >> > this issue it would be helpful if a demonstration of the problem could
> >> > be boiled down to a small C/C++ program or Python script just depending
> >> > on GDAL.
> >> >
> >> > Adam Nowaki is the main author of the WMS driver.
> >>
> >> Unfortunately I am not skilled enough in Python to write down the
> >> requested test case.
> >
> > Does "gdal_translate -outsize ..." work with WMS?
> 
> Apparently not:
> 
> gdal_translate -outsize 20% 20% wms_jpl_onearth.xml bla.tif
> Input file size is 2666666, 1333333
> 0
> 
> ... then it goes into poll time-out (according to strace).

In that case, it's a GDAL issue, and that should be a sufficient test
case.

--

-- 
Glynn Clements <glynn <at> gclements.plus.com>
_______________________________________________
grass-user mailing list
grass-user <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Permalink | Reply | 1 comment |
headers
Glynn Clements | 1 Nov 2008 05:33

Re: Re: Help: Converting a raster map between locations (from wgs84 lat / long to UTM)


Sebastian P. Luque wrote:

> On an "additional" question: How do people set the resolution
> correctly when transforming from lat/lon to meter and vice-versa?

There is no "correct" resolution when re-projecting rasters; whatever
you choose, the conversion will be "lossy" to some extent. It's just a
question of what's adequate for your purposes.

--

-- 
Glynn Clements <glynn <at> gclements.plus.com>
_______________________________________________
grass-user mailing list
grass-user <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Permalink | Reply | 1 comment |
headers
Markus Neteler | 1 Nov 2008 07:10
Favicon

Re: using grass on rasters without converting?

On Sat, Nov 1, 2008 at 5:29 AM, Glynn Clements <glynn <at> gclements.plus.com> wrote:
>
> Markus Neteler wrote:
>
>> >> > I'm not too familiar with the WMS driver.  But if it doesn't support
>> >> > skipping rows then it is a bug and should be fixed.  To file a ticket on
>> >> > this issue it would be helpful if a demonstration of the problem could
>> >> > be boiled down to a small C/C++ program or Python script just depending
>> >> > on GDAL.
>> >> >
>> >> > Adam Nowaki is the main author of the WMS driver.
>> >>
>> >> Unfortunately I am not skilled enough in Python to write down the
>> >> requested test case.
>> >
>> > Does "gdal_translate -outsize ..." work with WMS?
>>
>> Apparently not:
>>
>> gdal_translate -outsize 20% 20% wms_jpl_onearth.xml bla.tif
>> Input file size is 2666666, 1333333
>> 0
>>
>> ... then it goes into poll time-out (according to strace).
>
> In that case, it's a GDAL issue, and that should be a sufficient test
> case.

Right. Filed as
http://trac.osgeo.org/gdal/ticket/264

Markus
_______________________________________________
grass-user mailing list
grass-user <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Permalink | Reply | 0 comments |
headers
Craig Leat | 1 Nov 2008 13:07
Picon

Re: dem - long section

Hi Edmondo

Edmondo wrote:
> there is in grass (or in QGis ?) a way to extracting long section along a
> transect with annotation? E.g : elevation, station, etc...

This has come up a few times in the past:

GRASS options:
http://article.gmane.org/gmane.comp.gis.grass.user/23786/match=profile
http://article.gmane.org/gmane.comp.gis.grass.user/23788/match=profile
http://article.gmane.org/gmane.comp.gis.grass.user/23796/match=profile
http://article.gmane.org/gmane.comp.gis.grass.user/24490/match=profile
http://article.gmane.org/gmane.comp.gis.grass.user/26418/match=profile

QGIS option:
http://article.gmane.org/gmane.comp.gis.qgis.user/3067/match=profile

Craig
_______________________________________________
grass-user mailing list
grass-user <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Permalink | Reply | 0 comments |
headers
Nikos Alexandris | 2 Nov 2008 03:52
Picon

Re: Tips for setting up an new FOSS-GEO-linux-box

On Wed, 2008-10-29 at 07:19 -0700, Dylan Beaudette wrote:
> > Partitions:
> > Do you keep your geo-data in a separate partition? I suppose yes.
> Have
> > you split further your partition based on other criteria, always
> related
> > with "working with geospatial data"?
> 
> I like putting all of my GRASS data on a seperate disk-- so that IO
> intensive operations on GIS data do not slow my machine to a crawl.
> Alternatively a scratch disk for the /tmp/ folder might be nice too.

Dylan, could you please explain the "scratch disk"?

Thank you, Nikos

_______________________________________________
grass-user mailing list
grass-user <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Permalink | Reply | 3 comments |
headers
Nikos Alexandris | 2 Nov 2008 03:58
Picon

Re: Tips for setting up an new FOSS-GEO-linux-box

On Wed, 2008-10-29 at 15:08 +0100, Nikos Alexandris wrote:
> 
> P.S. Maybe we can add a new wiki-page if something useful comes out of
> this thread. Or maybe not... :-)

I whink an new page in http://wiki.osgeo.org/wiki/Main_Page is better
than in the GRASS-wiki.

What do you think for "Tips for setting up a Linux Operating System /
GIS Workstation" as a title? Since I am "forced" to speak greeklish very
frequently some language check is never bad to have.

If I am not wrong, the title is not possible to modify in a wiki (?), so
it's better to define it correctly

Thank you, Nikos

P.S. Anyway, here is an initial idea for the structure
---

Operating System/ Distribution
Are there any advantages to choose a specific linux distribution?

Filesystems
Which filesystem is better(=safer/faster)?

* According to some benchmarks [1] the XFS filesystem seems to perform
an overall highscore.

Partitions / Organisation

1. Geospatial data
* Keep your geospatial data in a separate partition

* Even further, using another hard disk drive than the main (the one in
which the operating system is installed) to save the GIS database, will
help... (Dylan, did I get this right, placing the data in another
partition on another hard disk than the "main hd", secures the resources
from being consumed 100% which the machine to crawl when under heavy
gis-processing... ?)

* Easy data exporting/sharing and multi-user access can be achieved
using NFS

2. Free Open Source Geospatial Applications (Software)
Where do you keep source codes?
* All in one directory
(+++add more)

BackUp
How often do you back up your data?
How do you back up your data?
* simple method: tar cjvf
* syncing method: using rsync

Other important issues
(+++add more)

_______________________________________________
grass-user mailing list
grass-user <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Permalink | Reply | 0 comments |
headers
Hamish | 2 Nov 2008 07:50
Picon
Favicon
Gravatar

Re: TIN and B/T correction in grass...

Hamish ha scritto:
> > Luca Penasa wrote:
> > > Is there a way for apply a bridge/tunnel TIN correction in GRASS?
> > > Is there any other similar TIN correction yet implemented in GRASS
> > > GIS? Anybody know if this function is only implemented in IDRISI?

Hamish ha scritto:
> > can you explain what this function does exactly?

Luca Penasa wrote:
> [Manual]
> "Contour lines at the top of a hill [...]
> Because all three of the points for all the triangles have the same
> elevation, the top of the hill is perfectly flat in the TIN model."

(see hint in r.surf.contour manual about importance of including trig and
ridge points in surface generation, if available)

> [Manual]
> "Our experience with actual terrain tells us that the true surface is
> probably not flat, but rather rises above the TIN facets. The edges of
> the TIN facets that lie below the true surface in this case are
> examples of what are called "tunnel edges". [...] A tunnel edge is any
> triangle edge that lies below the true surface.
> Similarly, if the contours of Figure 11-4a represented a valley bottom
> or depression, the TIN facets of 10-4b would describe a flat surface
> that is higher than the true surface. The edges of the TIN facets that
> lie above the true surface would then be termed "bridge edges"."

Do you have a TIN you would like to fix in GRASS? (original or rasterized?)
Or you are wondering how GRASS deals with the bad side effects of TINs?

To answer the first: each triangle confluence/vertex is a x,y,z data point.
Together these describe all the available actual data in the model, the
rest of the TIN is linear interpolation with some simple rules.
What you need to do in GRASS is load or convert the TIN into its
fundamental x,y,z data points, then use one of GRASS's more sophisticated
surface generation modules to create a new surface.  i.e. use v.surf.rst
to generate a more realistic DEM with peaks and valleys than the simple
TIN input describes.

To answer the second: GRASS doesn't really "do" TINs, for (AFAICT) the
simple reason that it doesn't have to resort to that. It has a very good
and mature raster engine with much better surface generation tools. IMHO
TIN is a hold-over technique for faux-raster surfaces from other GISs
which have been historically strong with vectors but weak with raster
data. (I would not count IDRISI among those, I speak more of Arc/Info,
but...) You can search the mailing list archives for my previous diatribes
on the subject. Of course all are free to work with whatever tools they
prefer, there is a little about GRASS+TINs here:
  http://grass.osgeo.org/wiki/Triangle_Mesh

Unfortunately AFAICT mediawiki's search engine does not consider three
letter words so it is hard to guess if there is any more content. (if not
there will be in the mailing list archives)

So my advice is to spend some time with v.surf.* and r.surf.* (including
r.surf.nnbathy from wiki addons) and enjoy the things that GRASS does well.

2c,
Hamish

_______________________________________________
grass-user mailing list
grass-user <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Permalink | Reply | 1 comment |
headers
Hamish | 2 Nov 2008 09:07
Picon
Favicon
Gravatar

RE: GRASS 6.4 and Ubuntu Intrepid

Liangxu Wang wrote:
>   Just download a new and latest svn version of grass 6.4, and compile
> as instructions in README.DEBIAN, get -lgdi error first, and resolved it
> by [1]:
>   sudo ln -s /usr/lib/python2.5/site-packages/wx-2.8-gtk2-unicode/wx/_gdi_.so /usr/local/lib/libgdi.so
....
> [1] http://svn.osgeo.org/grass/grass/trunk/wxpython/README

(ie http://svn.osgeo.org/grass/grass/trunk/gui/wxpython/README)

Hi,

FYI we just updated the DebianGIS build rules for 6.4 a few days ago
(it again builds with the instructions found in debian/README.debian).

AFAIU the wx support there is still somewhat in development, please report
any clearly packaging errors to DebianGIS directly:
  http://wiki.debian.org/DebianGis
No idea if Ubuntu follows debian for wx2.8 dir paths.

Hamish

_______________________________________________
grass-user mailing list
grass-user <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Permalink | Reply | 0 comments |
headers
Luca Penasa | 2 Nov 2008 10:07
Picon
Favicon

Re: TIN and B/T correction in grass...

Hamish, thank you for your really exhaustive answer!
The second question was right for me...

Thank you!!

Luca

> Do you have a TIN you would like to fix in GRASS? (original or rasterized?)
> Or you are wondering how GRASS deals with the bad side effects of TINs?
> 
> To answer the first: each triangle confluence/vertex is a x,y,z data point.
> Together these describe all the available actual data in the model, the
> rest of the TIN is linear interpolation with some simple rules.
> What you need to do in GRASS is load or convert the TIN into its
> fundamental x,y,z data points, then use one of GRASS's more sophisticated
> surface generation modules to create a new surface.  i.e. use v.surf.rst
> to generate a more realistic DEM with peaks and valleys than the simple
> TIN input describes.
> 
> To answer the second: GRASS doesn't really "do" TINs, for (AFAICT) the
> simple reason that it doesn't have to resort to that. It has a very good
> and mature raster engine with much better surface generation tools. IMHO
> TIN is a hold-over technique for faux-raster surfaces from other GISs
> which have been historically strong with vectors but weak with raster
> data. (I would not count IDRISI among those, I speak more of Arc/Info,
> but...) You can search the mailing list archives for my previous diatribes
> on the subject. Of course all are free to work with whatever tools they
> prefer, there is a little about GRASS+TINs here:
>   http://grass.osgeo.org/wiki/Triangle_Mesh
> 
> Unfortunately AFAICT mediawiki's search engine does not consider three
> letter words so it is hard to guess if there is any more content. (if not
> there will be in the mailing list archives)
> 
> So my advice is to spend some time with v.surf.* and r.surf.* (including
> r.surf.nnbathy from wiki addons) and enjoy the things that GRASS does well.
> 
> 
> 2c,
> Hamish
> 
> 
> 
>       
> 

 

 --
 Email.it, the professional e-mail, gratis per te: http://www.email.it/f

 Sponsor:
 Scegli la tua suoneria! Il meglio della musica sul tuo cellulare! 
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8269&d=2-11
_______________________________________________
grass-user mailing list
grass-user <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Permalink | Reply | 0 comments |

Gmane