[GRASS-user] (no subject)
Markus, Thanks for the feedback. The advice is very helpful. I've been slowly getting used to GRASS but still have a way to go. If I can stick with it I hope to learn enough to create a week-long "GRASS for conservation" workshop that we can offer at our research station in southeastern Arizona and in our projects in SE Asia. Here are some clarifying remarks and a few more questions if anyone can help. > It will work. Everything takes time but I don't expect problems. GRASS 6.2 > has been used for >10GB images, since then more testing and fixing > happened. Best is to use the latest 6.4.0RC2 version. > I'll see if I can get this version set up so it doesn't conflict with the GRASS version bundled with QGIS. My linux (Ubuntu) skill are also still quite poor but I'm learning (again). >> 4) Georeference shrub / non-shrub map to reference Landsat images [might do >> this with ENVI or ERDAS unless GRASS is a good choice] >> > > Also unclear to me: above you say that you generate the shrub / non-shrub map > in GRASS, then it is already geocoded. Or not? > Sorry - I wasn't very clear. The images I'm working with are geocoded but the image-to-image registration is poor. I plan to project all of the images into the same projection (some are in UTM and some use different datums) and then do an image-to-image registration. I wasn't sure if GRASS would be an efficient tool to do the image-to-image registration. I should just try it. > >> 5) Create percent shrub cover map using regression tree algorithm, Landsat imagery, >> and shrub location data from the high resolution shrub / non-shrub map. I will >> probably do this using proprietary software unless I can do it easily in GRASS >> since a method has been established for another project. >> > > Of course GRASS-R-extention comes to mind for all kinds of statistics. I'm considering using GRASS for this but would like to know if anyone has used GRASS with R as the regression tree engine. I have a vague recollection of someone doing this several years ago but didn't find anything after a quick search. I suppose it would require getting training data from GRASS to R to generate the regression tree and then port the tree results back to GRASS to apply the rules to the dataset. It would be great if an interface already existed to do this but if not I can probably figure it out. I'm just not sure how long it will take me. All the best, Ned ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Original location: Hot to create from the command line ?
Hi Markus, by the way. These links on the GRASS Tutor example page (http://www.grassbook.org/examples_menu2nd.php) seem to be broken: http://grass.itc.it/statsgrass/index.html#grassgstat http://grass.itc.it/statsgrass/index.html#grassR Marco Markus Neteler schrieb: > On Mon, Jan 19, 2009 at 12:06 PM, "Peter Löwe" wrote: > is there an (easy) recipe to create a completely new location from scratch without using a GUI ? To be precise: If GRASS is started for the first time in "-text" mode (=no GUI) ** without having a sample location like Spearfish or North Carolina around**, how can location parameters (projection, extent, EPSG...) be handed over to set up a very first location ? >>> Just type in the name of the location you want to create and GRASS will >>> prompt you for the parameters. >>> >>> Moritz >>> >> That's true. But is there also a way to provide the parameters _without_ >> interaction >> with the user (-> GRASS scripting & automation) ? >> > > Sure. > An older version of a shell script is here: > http://www.grassbook.org/examples_menu2nd.php > -> create_location.sh > > Keeping in mind > http://grass.osgeo.org/wiki/GRASS_and_Shell#GRASS_Batch_jobs > it should be even easier to write it. > > Markus > ___ > grass-user mailing list > grass-user@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: grass-user Digest, Vol 33, Issue 39
> > -- Message: 5 Date: Mon, 19 Jan 2009 > 12:00:08 +0100 From: Moritz Lennert > Subject: Re: [GRASS-user] generating lines from points To: Martin > Landa Cc: GRASS users list > Message-ID: > <49745d38.9030...@club.worldonline.be> Content-Type: text/plain; > charset=ISO-8859-1; format=flowed On 18/01/09 18:08, Martin Landa wrote: >> > Hi, >> > >> > 2009/1/18 Martin Landa : >> > >> > [...] >> > >> >>> >> The more lines you need to generate the longer list of categories will >>> >> be, not possible to give the list as the parameter. Then v.edit could >>> >> read categories from stdin, simillary to v.net.path. Hm, what about >>> >> v.net? New tool to generate network from points? >>> >> >>> >> v.net input=points output=net operation=lines line_file=- << EOF >>> >> 1 1 2 >>> >> 2 2 3 >>> >> EOF >>> >> >>> >> creates edges between points 1-2 and 2-3 with category 1 and 2? >>> >> > >> > better >> > >> > v.net points=points output=net operation=net file=- << EOF >> > 1 1 2 >> > 2 2 3 >> > EOF >> > >> > What do you think about that? >> > > I think that a GRASS module for connecting lines between chosen points > is a definite yes (think of point coordinates of airports with > information about flight connections between airports). Up to now I've > been doing it with a simple script + v.in.ascii. > I think a module would be wonderful, since I've struggled with this task a few times. Would it be rude to ask about your script, Moritz? Richard > Not sure v.net is the most logical place to have this. Maybe a > stand-alone module v.points2lines ? > > Moritz > > > -- > > Message: 6 > Date: Mon, 19 Jan 2009 12:04:26 +0100 > From: Moritz Lennert > Subject: Re: [GRASS-user] Original location: Hot to create from the > command line? > To: peter.lo...@gmx.de > Cc: grass-user@lists.osgeo.org > Message-ID: <49745e3a.1000...@club.worldonline.be> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 19/01/09 10:47, peter.lo...@gmx.de wrote: > >> > Hi, >> > >> > is there an (easy) recipe to create a completely new location from >> > scratch without using a GUI ? >> > >> > To be precise: If GRASS is started for the first time in "-text" mode >> > (=no GUI) ** without having a sample location like Spearfish or North >> > Carolina around**, how can location parameters (projection, extent, >> > EPSG...) be handed over to set up a very first location ? >> > > Just type in the name of the location you want to create and GRASS will > prompt you for the parameters. > > Moritz > > > -- > > Message: 7 > Date: Mon, 19 Jan 2009 12:06:56 +0100 > From: "Peter L?we" > Subject: Re: [GRASS-user] Original location: Hot to create from the > command line? > To: Moritz Lennert > Cc: grass-user@lists.osgeo.org > Message-ID: <20090119110656.4...@gmx.net> > Content-Type: text/plain; charset="iso-8859-1" > > > >>> > > is there an (easy) recipe to create a completely new location from >>> > > scratch without using a GUI ? >>> > > >>> > > To be precise: If GRASS is started for the first time in "-text" mode >>> > > (=no GUI) ** without having a sample location like Spearfish or North >>> > > Carolina around**, how can location parameters (projection, extent, >>> > > EPSG...) be handed over to set up a very first location ? >>> >> > >> > Just type in the name of the location you want to create and GRASS will >> > prompt you for the parameters. >> > >> > Moritz >> > > That's true. But is there also a way to provide the parameters _without_ > interaction with the user (-> GRASS scripting & automation) ? > > Peter > -- Dr. Peter Lo"we Sensationsangebot verla"ngert: > GMX FreeDSL - Telefonanschluss + DSL fu"r nur 16,37 Euro/mtl.!* > http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a > -- Message: 8 Date: Mon, 19 Jan 2009 > 12:23:37 +0100 From: Nikos Alexandris > Subject: Re: [GRASS-user] > v.digit under wxGUI To: Vincent Bain Cc: GRASS user > list Message-ID: > <1232364217.6974.0.ca...@vertical> Content-Type: text/plain On Sun, > 2009-01-18 at 19:30 +0100, Vincent Bain wrote: >> > OK, >> > >> > so in order to fully enjoy the wxpython GUI on an 64 bit architecture >> > (especially the wxdigit module) one should first read carefully the >> > README file located in the your_grass_source_location/gui/wxpython >> > directory. >> > >> > The section named "7 - VECTOR DIGITIZER" tells you to create a symbolic >> > link to a wx library : >> > >> > sudo ln -s `locate _gdi_.so` /usr/local/lib/libgdi.so >> > >> > The command locate _gdi_.so may points towards the 32 bit library and >> > ignore (?) the 64 bit libs path (/usr/lib64/...), so it fails. In my >> > configuration I had to type : >> > >> > sudo ln -s /usr/lib64/python2.5/site-packages\ >> > /wx-2.8-gtk2-unicode/wx/_gdi_.so /usr/local/lib/libgdi.so >> > >> > And it worked !
Re: [GRASS-user] Landsat classification with CORINE CLC color codes?
On Mon, 2009-01-19 at 16:45 -0800, Hamish wrote: > there are 2^8 = 256 possibilities. So range could be 0-255 or 1-256. > If you use 0-255 then 0/255=0.0 and 255/255 is 1.0 and life is easy. > Hamish Hehehe... actually I did divide by 255 in the beginning, but then, I thought of playing around with sed, cut, tr and just a bit with bc. And I thought of 256. Nonsense but it's a good command-line training I think :-) - Take the set of 44 rows and 2 columns, e.g. 111,"255,154,211" 112,"012,234,123" 113,"122,233,133" [...] and transform it to grassrgb and LaTeX format. -- ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Landsat classification with CORINE CLC color codes?
Nikos: > would you advise to divide the 0-255 values by 255 or > by 256 to transform them to values ranging from 0 ~ 1 ? Or > it doesn't really matter? (The values I posted in the previous post, > are divided by 256). 255. there are 2^8 = 256 possibilities. So range could be 0-255 or 1-256. If you use 0-255 then 0/255=0.0 and 255/255 is 1.0 and life is easy. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] DBMI-DBF driver error
You are correct. 'river.dbf' is a typo. I did a cut and past, but
the first character of the first line in the "Output - GIS.m" window
always appears a couple of line up and to the right of the printer and
"X" icons: it should have read "driver:dbf".
The directory 'C:/Users/Matt/Documents/GISdata/nc_spm_08/PERMANENT/dbf'
does exist.
This is probably grasping as straws, but could the difference between
forward slash and back slash be important? If I open a Windows
Command Prompt window (a DOS window) and type
cd C:/Users/Matt/Documents/GISdata/nc_spm_08/PERMANENT/dbf
I go to the correct directory. If I then type dir in the Command
Prompt window, I see the directory listing.
BUT if I am back at the root directory (c:\) and type
dir C:/Users/Matt/Documents/GISdata/nc_spm_08/PERMANENT/dbf
I get an error message. Repeating with the back slash gives the
correct result in both cases. For shorter examples "dir c:\" works,
but "dir c:/" does not work (invalid switch). Depending how GRASS and
Windows interact, might this be a problem?
On Mon, Jan 19, 2009 at 4:49 PM, Markus Neteler wrote:
> Matt,
>
> On Sat, Jan 17, 2009 at 7:21 PM, Matt wrote:
>> I have a problem working through the DBF driver example on pp 174-175
>> of Neteler & Mitasova with the North Carolina dataset. I''m running
>> version 6.3.0-4 under Windows Vista. The first two commands execute
>> without any obvious errors when run from the bottom window of "GIS.m".
>> But the third command has problems.
>>
>> db.connect driver=dbf database='$GISDBASE/$LOCATION_NAME/$MAPSET/dbf/'
>> db.connect -p
>> g.copy vect=roadsmajor,myroadsmajor
>>
>> Output from db.connect -p is
>> river:dbf
>
> ("river" this is just a typo, no?)
>
>> database:'$GISDBASE/$LOCATION_NAME/$MAPSET/dbf
>> schema:
>> group:
>>
>> Output from g.copy vect=roadsmajor,myroadsmajor is
>> g.copy vect=roadsmajor,myroadsmajor
>>
>> Copy vector to current mapset as
>> DBMI-DBF driver error:
>> Cannot create dbf database:
>> 'C:/Users/Matt/Documents/GISdata/nc_spm_08/PERMANENT/dbf
>
> Does the directory exist?
> If no, can you create it manually?
>
> Markus
>
>> Cannot open database
>> ''C:/Users/Matt/Documents/GISdata/nc_spm_08/PERMANENT/dbf'
>> no database is open
>>
>> Unable to copy table
>>
>> Cannot copy to current mapset as
>>
>> I've checked and the file
>> 'C:/Users/Matt/Documents/GISdata/nc_spm_08/PERMANENT/roadsmajor.dbf'
>> does indeed exist. What am I doing wrong?
>>
>> Thanks in advance.
>> Matt
>> ___
>> grass-user mailing list
>> grass-user@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-user
>>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Landsat classification with CORINE CLC color codes?
On Mon, 2009-01-19 at 15:17 -0800, Hamish wrote:
> > > Dimos wrote:
> > > > > > 44 CORINE CLC RGB color codes are mentioned for each of the 44
> > > > > > land use classes at:
> > http://dataservice.eea.europa.eu/download.asp?id=14234&filetype=.csv
> > > > > >
> > > > > > Can we classify a Landsat RGB image based on these rgb color
> > > > > > codes in GRASS GIS and how?
> > >
> > > Markus:
> > > > > In my opinion it doesn't make much sense to use the RGB colors
> > > > > here since they are arbitrary (well, ok, ideally "close" to
> > > > > natural colors).
>
> Hamish:
> > > I am trying to understand; there are 256^3 RGB possibilities (@ 8bits
> > > per channel) and CORINE have selected 44 of those possibilities to
> > > give labels to? Your chances of hitting those exactly are rather
> > > low. I suppose these are meant to be 3D spectral peaks somehow with
> > > the land-use category doing like a 3D form of a nearest-neighbor
> > > thiessen polygon.
> > >
> > > It seems a rather lossy and sensitive approach, ie it would be better
> > > to base it on all 7 bands & include some method to remove time of
> > > day/luminance issues. e.g. specify color normalization step first
> > > [eg i.landsat.rgb], or convert LANDSAT r,g,b pseudo-visual bands to
> > > HIS and classify on that (I'm guessing that hue would be less
> > > sensitive to sun angle).
>
> Nikos:
> > Hmmm??
> >
> > Maybe I am talking nonsense but, I think, the designers must have tried
> > to create a color scheme that, not only is connected in a way to natural
> > colors, but also that makes the land cover classes easy to discriminate
> > visually and the whole thing a *nice* looking map. Or maybe not... (?).
>
> so we are looking at this backwards?
>
> I answered from the perspective of taking LANDSAT imagery and classifying
> it into those 44 categories based on imagery ground color. But perhaps
> those colors are meant for people who have categorical data layer (44 cats)
> and want to display it in a consistent & pretty way.
As I said, maybe I am completely wrong, but it's my guess that the RGB
combinations provided by EEA are not directly related to radiometric
values.
> In that case all that
> needs to be done is to reformat the CSV file to pass to r.colors.
There are already raster versions of the CORINE land cover map. Check
EEA's website. And the grassrgb are also here [*] :-)
> In the other direction, if you have a land-use map given in those colors
> and which you wish to attach cat numbers/labels to them, & then use them
> as training areas for classifying other LANDSAT imagery, that is another
> task.
That's what I thought initially.
>
> > By the way, below are the official rgb combinations for use
> > with "\usepackage{colortbl}" (LaTeX).
Ehhmm... Hamish, would you advise to divide the 0-255 values by 255 or
by 256 to transform them to values ranging from 0 ~ 1 ? Or it doesn't
really matter? (The values I posted in the previous post, are divided by
256).
>
> how does that relate?
>
>
> Hamish
>
[*] That's here for copy-paste :-)
--
111 230:000:077
112 255:000:000
121 204:077:242
122 204:000:000
123 230:204:204
124 230:204:230
131 166:000:204
132 166:077:000
133 255:077:255
141 255:166:255
142 255:230:255
211 255:255:168
212 255:255:000
213 230:230:000
221 230:128:000
222 242:166:077
223 230:166:000
231 230:230:077
241 255:230:166
242 255:230:077
243 230:204:077
244 242:204:166
311 128:255:000
312 000:166:000
313 077:255:000
321 204:242:077
322 166:255:128
323 166:230:077
324 166:242:000
331 230:230:230
332 204:204:204
333 204:255:204
334 000:000:000
335 166:230:204
411 166:166:255
412 077:077:255
421 204:204:255
422 230:230:255
423 166:166:230
511 000:204:242
512 128:242:230
521 000:255:166
522 166:255:230
523 230:242:255
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Landsat classification with CORINE CLC color codes?
> > Dimos wrote:
> > > > > 44 CORINE CLC RGB color codes are mentioned for each of the 44
> > > > > land use classes at:
> http://dataservice.eea.europa.eu/download.asp?id=14234&filetype=.csv
> > > > >
> > > > > Can we classify a Landsat RGB image based on these rgb color
> > > > > codes in GRASS GIS and how?
> >
> > Markus:
> > > > In my opinion it doesn't make much sense to use the RGB colors
> > > > here since they are arbitrary (well, ok, ideally "close" to
> > > > natural colors).
Hamish:
> > I am trying to understand; there are 256^3 RGB possibilities (@ 8bits
> > per channel) and CORINE have selected 44 of those possibilities to
> > give labels to? Your chances of hitting those exactly are rather
> > low. I suppose these are meant to be 3D spectral peaks somehow with
> > the land-use category doing like a 3D form of a nearest-neighbor
> > thiessen polygon.
> >
> > It seems a rather lossy and sensitive approach, ie it would be better
> > to base it on all 7 bands & include some method to remove time of
> > day/luminance issues. e.g. specify color normalization step first
> > [eg i.landsat.rgb], or convert LANDSAT r,g,b pseudo-visual bands to
> > HIS and classify on that (I'm guessing that hue would be less
> > sensitive to sun angle).
Nikos:
> Hmmm??
>
> Maybe I am talking nonsense but, I think, the designers must have tried
> to create a color scheme that, not only is connected in a way to natural
> colors, but also that makes the land cover classes easy to discriminate
> visually and the whole thing a *nice* looking map. Or maybe not... (?).
so we are looking at this backwards?
I answered from the perspective of taking LANDSAT imagery and classifying
it into those 44 categories based on imagery ground color. But perhaps
those colors are meant for people who have categorical data layer (44 cats)
and want to display it in a consistent & pretty way. In that case all that
needs to be done is to reformat the CSV file to pass to r.colors.
In the other direction, if you have a land-use map given in those colors
and which you wish to attach cat numbers/labels to them, & then use them
as training areas for classifying other LANDSAT imagery, that is another
task.
> By the way, below are the official rgb combinations for use
> with "\usepackage{colortbl}" (LaTeX).
how does that relate?
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS 6.4 windows open off screen
I have no problem like this with one monitor. Try unhooking one of the monitors and trying it. My guess is that it has to do with your 2- monitor setup and its configuration. Michael On Jan 19, 2009, at 2:45 PM, wrote: Date: Mon, 19 Jan 2009 14:37:09 -0500 From: Kurt Springs Subject: [GRASS-user] GRASS 6.4 windows open off screen To: grassu...@grass.itc.it Message-ID: <7784040d-bd8a-4a66-8280-712d97788...@mac.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Hi folks, I was wondering if any one has encountered this. I am now using GRASS 6.4 RC2. So far I've liked it. The problem I am running into is that when I go to open up a raster or vector map the windows that hold the maps opens off screen. Normally I can see a little bit of it off the right hand side of the monitor that I can grab and pull back onto the screen, though sometimes I have to close GRASS and start again. I am using William Kybgesburye's build on OS X. I don't know if this would have anything to do with it, but I am using two monitors. I don't know if the problem is with GRASS 6.4 or Active Tcl 8.5. Any ideas. Kurt ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Landsat classification with CORINE CLC color codes?
On Mon, 2009-01-19 at 13:30 -0800, Hamish wrote:
> Dimos wrote:
> > > > 44 CORINE CLC RGB color codes are mentioned for each of the 44
> > > > land use classes at:
> http://dataservice.eea.europa.eu/download.asp?id=14234&filetype=.csv
> > > >
> > > > Can we classify a Landsat RGB image based on these rgb color
> codes
> > > > in GRASS GIS and how?
>
> Markus:
> > > In my opinion it doesn't make much sense to use the RGB colors
> here
> > > since they are arbitrary (well, ok, ideally "close" to natural
> colors).
>
> I am trying to understand; there are 256^3 RGB possibilities (@ 8bits
> per
> channel) and CORINE have selected 44 of those possibilities to give
> labels
> to? Your chances of hitting those exactly are rather low. I suppose
> these
> are meant to be 3D spectral peaks somehow with the land-use category
> doing
> like a 3D form of a nearest-neighbor thiessen polygon.
>
>
> It seems a rather lossy and sensitive approach, ie it would be better
> to
> base it on all 7 bands & include some method to remove time of
> day/luminance
> issues. e.g. specify color normalization step first [eg
> i.landsat.rgb],
> or convert LANDSAT r,g,b pseudo-visual bands to HIS and classify on
> that
> (I'm guessing that hue would be less sensitive to sun angle).
Hmmm??
Maybe I am talking nonsense but, I think, the designers must have tried
to create a color scheme that, not only is connected in a way to natural
colors, but also that makes the land cover classes easy to discriminate
visually and the whole thing a *nice* looking map. Or maybe not... (?).
By the way, below are the official rgb combinations for use with
"\usepackage{colortbl}" (LaTeX).
Kind regards, Nikos
\definecolor{111}{rgb}{0.8984,0,0.3008}
\definecolor{112}{rgb}{0.9961,0,0}
\definecolor{121}{rgb}{0.7969,0.3008,0.9453}
\definecolor{122}{rgb}{0.7969,0,0}
\definecolor{123}{rgb}{0.8984,0.7969,0.7969}
\definecolor{124}{rgb}{0.8984,0.7969,0.8984}
\definecolor{131}{rgb}{0.6484,0,0.7969}
\definecolor{132}{rgb}{0.6484,0.3008,0}
\definecolor{133}{rgb}{0.9961,0.3008,0.9961}
\definecolor{141}{rgb}{0.9961,0.6484,0.9961}
\definecolor{142}{rgb}{0.9961,0.8984,0.9961}
\definecolor{211}{rgb}{0.9961,0.9961,0.6563}
\definecolor{212}{rgb}{0.9961,0.9961,0}
\definecolor{213}{rgb}{0.8984,0.8984,0}
\definecolor{221}{rgb}{0.8984,0.5,0}
\definecolor{222}{rgb}{0.9453,0.6484,0.3008}
\definecolor{223}{rgb}{0.8984,0.6484,0}
\definecolor{231}{rgb}{0.8984,0.8984,0.3008}
\definecolor{241}{rgb}{0.9961,0.8984,0.6484}
\definecolor{242}{rgb}{0.9961,0.8984,0.3008}
\definecolor{243}{rgb}{0.8984,0.7969,0.3008}
\definecolor{244}{rgb}{0.9453,0.7969,0.6484}
\definecolor{311}{rgb}{0.5,0.9961,0}
\definecolor{312}{rgb}{0,0.6484,0}
\definecolor{313}{rgb}{0.3008,0.9961,0}
\definecolor{321}{rgb}{0.7969,0.9453,0.3008}
\definecolor{322}{rgb}{0.6484,0.9961,0.5}
\definecolor{323}{rgb}{0.6484,0.8984,0.3008}
\definecolor{324}{rgb}{0.6484,0.9453,0}
\definecolor{331}{rgb}{0.8984,0.8984,0.8984}
\definecolor{332}{rgb}{0.7969,0.7969,0.7969}
\definecolor{333}{rgb}{0.7969,0.9961,0.7969}
\definecolor{334}{rgb}{0,0,0}
\definecolor{335}{rgb}{0.6484,0.8984,0.7969}
\definecolor{411}{rgb}{0.6484,0.6484,0.9961}
\definecolor{412}{rgb}{0.3008,0.3008,0.9961}
\definecolor{421}{rgb}{0.7969,0.7969,0.9961}
\definecolor{422}{rgb}{0.8984,0.8984,0.9961}
\definecolor{423}{rgb}{0.6484,0.6484,0.8984}
\definecolor{511}{rgb}{0,0.7969,0.9453}
\definecolor{512}{rgb}{0.5,0.9453,0.8984}
\definecolor{521}{rgb}{0,0.9961,0.6484}
\definecolor{522}{rgb}{0.6484,0.9961,0.8984}
\definecolor{523}{rgb}{0.8984,0.9453,0.9961}
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] generating lines from points
Hi,
2009/1/19 Moritz Lennert :
[...]
>> v.net points=points output=net operation=net file=- << EOF
>> 1 1 2
>> 2 2 3
>> EOF
>>
>> What do you think about that?
>
> I think that a GRASS module for connecting lines between chosen points is a
> definite yes (think of point coordinates of airports with information about
> flight connections between airports). Up to now I've been doing it with a
> simple script + v.in.ascii.
>
> Not sure v.net is the most logical place to have this. Maybe a stand-alone
v.net seems to be good place. There is already tool for generating
points ('nodes'), so why not tool for generating lines (arcs/edges)?
v.net updated in GRASS7 [1].
> module v.points2lines ?
This could be more general module.
v.points? input=- output=lines type=line << EOF
1 1 2
2 2 3
3 4 5
EOF
creates separated lines
v.points? input=- output=area type=area << EOF
1 1 2
2 2 3
3 4 5
EOF
creates closed ring -> area
Note that `v.net operation=arcs` create vector map with two layes -
arcs (lines) and nodes (point).
Martin
[1] http://trac.osgeo.org/grass/changeset/35490
--
Martin Landa * http://gama.fsv.cvut.cz/~landa *
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Original location: How to create from the command line ?
Hamish wrote: > > So what we need is a wrapper script that will create a dummy location/ > > mapset in /tmp/ and run 'grass64 + g.proj -c' via a GRASS_BATCH_JOB > > (be it .sh or .py). Any hints on how the man page parts of the build > > process accomplish this? Markus wrote: > See > include/Make/Html.make > The relevant variables are set, that's all. does $GISBASE/demolocation/ get installed with 'make install' so you can use it at runtime? Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] DBMI-DBF driver error
Matt,
On Sat, Jan 17, 2009 at 7:21 PM, Matt wrote:
> I have a problem working through the DBF driver example on pp 174-175
> of Neteler & Mitasova with the North Carolina dataset. I''m running
> version 6.3.0-4 under Windows Vista. The first two commands execute
> without any obvious errors when run from the bottom window of "GIS.m".
> But the third command has problems.
>
> db.connect driver=dbf database='$GISDBASE/$LOCATION_NAME/$MAPSET/dbf/'
> db.connect -p
> g.copy vect=roadsmajor,myroadsmajor
>
> Output from db.connect -p is
> river:dbf
("river" this is just a typo, no?)
> database:'$GISDBASE/$LOCATION_NAME/$MAPSET/dbf
> schema:
> group:
>
> Output from g.copy vect=roadsmajor,myroadsmajor is
> g.copy vect=roadsmajor,myroadsmajor
>
> Copy vector to current mapset as
> DBMI-DBF driver error:
> Cannot create dbf database:
> 'C:/Users/Matt/Documents/GISdata/nc_spm_08/PERMANENT/dbf
Does the directory exist?
If no, can you create it manually?
Markus
> Cannot open database
> ''C:/Users/Matt/Documents/GISdata/nc_spm_08/PERMANENT/dbf'
> no database is open
>
> Unable to copy table
>
> Cannot copy to current mapset as
>
> I've checked and the file
> 'C:/Users/Matt/Documents/GISdata/nc_spm_08/PERMANENT/roadsmajor.dbf'
> does indeed exist. What am I doing wrong?
>
> Thanks in advance.
> Matt
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Original location: Hot to create from the command line ?
On Mon, Jan 19, 2009 at 12:06 PM, "Peter Löwe" wrote: > >> > is there an (easy) recipe to create a completely new location from >> > scratch without using a GUI ? >> > >> > To be precise: If GRASS is started for the first time in "-text" mode >> > (=no GUI) ** without having a sample location like Spearfish or North >> > Carolina around**, how can location parameters (projection, extent, >> > EPSG...) be handed over to set up a very first location ? >> >> Just type in the name of the location you want to create and GRASS will >> prompt you for the parameters. >> >> Moritz > > That's true. But is there also a way to provide the parameters _without_ > interaction > with the user (-> GRASS scripting & automation) ? Sure. An older version of a shell script is here: http://www.grassbook.org/examples_menu2nd.php -> create_location.sh Keeping in mind http://grass.osgeo.org/wiki/GRASS_and_Shell#GRASS_Batch_jobs it should be even easier to write it. Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: DBMI-DBF driver error
Any suggestions on what I may be doing wrong? On Sat, Jan 17, 2009 at 1:21 PM, Matt wrote: > I have a problem working through the DBF driver example on pp 174-175 > of Neteler & Mitasova with the North Carolina dataset. I''m running > version 6.3.0-4 under Windows Vista. The first two commands execute > without any obvious errors when run from the bottom window of "GIS.m". > But the third command has problems. > > db.connect driver=dbf database='$GISDBASE/$LOCATION_NAME/$MAPSET/dbf/' > db.connect -p > g.copy vect=roadsmajor,myroadsmajor > > Output from db.connect -p is > river:dbf > database:'$GISDBASE/$LOCATION_NAME/$MAPSET/dbf > schema: > group: > > Output from g.copy vect=roadsmajor,myroadsmajor is > g.copy vect=roadsmajor,myroadsmajor > > Copy vector to current mapset as > DBMI-DBF driver error: > Cannot create dbf database: > 'C:/Users/Matt/Documents/GISdata/nc_spm_08/PERMANENT/dbf > > > Cannot open database > ''C:/Users/Matt/Documents/GISdata/nc_spm_08/PERMANENT/dbf' > no database is open > > Unable to copy table > > Cannot copy to current mapset as > > I've checked and the file > 'C:/Users/Matt/Documents/GISdata/nc_spm_08/PERMANENT/roadsmajor.dbf' > does indeed exist. What am I doing wrong? > > Thanks in advance. > Matt > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Original location: How to create from the command line ?
On Mon, Jan 19, 2009 at 10:00 PM, Hamish wrote: > So what we need is a wrapper script that will create a dummy location/ > mapset in /tmp/ and run 'grass64 + g.proj -c' via a GRASS_BATCH_JOB (be > it .sh or .py). Any hints on how the man page parts of the build process > accomplish this? See include/Make/Html.make The relevant variables are set, that's all. Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Advice for starting a GRASS project
Ned, On Fri, Jan 9, 2009 at 12:53 PM, Ned Horning wrote: > I'd like to get some feedback on my proposed approach for a land cover > classification > project in GRASS. Basically I'm looking for pointers to help me avoid too many > learning curve pitfalls. I have the 3rd edition of the Grass book (great > resource) > and lots of image processing experience using other software but limited GRASS > experience. > > After several years of failed attempts at learning GRASS I have (nearly) > decided > to do a large project using it to force myself to become proficient enough > with > GRASS to use it on a regular basis. In the past I would always start a GRASS > project, get frustrated and then would turn to the proprietary software I was > very familiar with to do the project to save time. I have been encouraging > other > people to use GRASS and figure it's time that I do the same. Excellent & welcome :) > The project is fairly straightforward but it involves processing about 30 > fairly > large (1 – 2 GB each) 2.5m SPOT and 1m IKONOS images. The initial step is to > create a shrub/non-shrub map using the high resolution imagery and then use > the shrub presence locations (from the shrub / non-shrub map) and several > Landsat > TM/ETM+ images to train regression trees to create a percent shrub cover map. > Many sets of images were acquired in the same pass on the same day and can be > mosaicked but then they would then be near or over the BIGTIFF limits. (in GRASS there is large file support, enable with --enable-largefile when configuring the source code or pick an enabled binary). > These are the steps I expect to follow. Any comments or answers to my > questions > would be greatly appreciated. > > 1) Import SPOT and IKONOS images into GRASS [one location for each image] If they are of the same place, I would import them into the same location and even the same mapset (eg PERMANENT). Then elaborate in a separate *mapset* within this location to separate originals from own stuff. Of course only if all have the same projection. > 2) Shrub / non-shrub classification using GRASS. I am trying to think of ways > to avoid having to pick training data from each image (to save time) since > there > are many sets of images that were collected consecutively on the same path on > the same day and therefore have similar illumination conditions. > I could mosaic them but I'm concerned the images will be too cumbersome to > handle > (~3-8GB). How is GRASS performance with large images and a 4 year old > computer? It will work. Everything takes time but I don't expect problems. GRASS 6.2 has been used for >10GB images, since then more testing and fixing happened. Best is to use the latest 6.4.0RC2 version. > To avoid mosaicking the images I could collect training statistics from one > (or maybe combine statistics from two images?) and apply those statistics to > each of the images in the set using a supervised classification algorithm. In my former institute we developed a histogram matching algorithm as master thesis but it was too complicated to maintain. In another project we used OSSIM for this step, then continued in GRASS. > I may just end up picking training data from each image but that will be very > time consuming. I am considering using i.smap. Is this feasible with large > images? Yes (for i.smap). > A maximum likelihood algorithm would probably work fine but I thought it would > be interesting to try smap. i.smap is definitely superior to i.maxlik. Consider to generate synthetic channels with r.texture, in your case it may well improve the results. > 3) Project shrub/non-shrub and SPOT/IKONOS images Albers using GDAL [automate > using a script] Unclear to me: from what to what? Ok for automatization. > 4) Georeference shrub / non-shrub map to reference Landsat images [might do > this with ENVI or ERDAS unless GRASS is a good choice] Also unclear to me: above you say that you generate the shrub / non-shrub map in GRASS, then it is already geocoded. Or not? > 5) Create percent shrub cover map using regression tree algorithm, Landsat > imagery, > and shrub location data from the high resolution shrub / non-shrub map. I > will > probably do this using proprietary software unless I can do it easily in GRASS > since a method has been established for another project. Of course GRASS-R-extention comes to mind for all kinds of statistics. best, Markus -- Markus Neteler Fondazione Mach - Centre for Alpine Ecology 38100 Viote del Monte Bondone (Trento), Italy Web: http://gis.fem-environment.eu/ Email: neteler AT cealp.it ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Landsat classification with CORINE CLC color codes?
Dimos wrote: > > > 44 CORINE CLC RGB color codes are mentioned for each of the 44 > > > land use classes at: http://dataservice.eea.europa.eu/download.asp?id=14234&filetype=.csv > > > > > > Can we classify a Landsat RGB image based on these rgb color codes > > > in GRASS GIS and how? Markus: > > In my opinion it doesn't make much sense to use the RGB colors here > > since they are arbitrary (well, ok, ideally "close" to natural colors). I am trying to understand; there are 256^3 RGB possibilities (@ 8bits per channel) and CORINE have selected 44 of those possibilities to give labels to? Your chances of hitting those exactly are rather low. I suppose these are meant to be 3D spectral peaks somehow with the land-use category doing like a 3D form of a nearest-neighbor thiessen polygon. It seems a rather lossy and sensitive approach, ie it would be better to base it on all 7 bands & include some method to remove time of day/luminance issues. e.g. specify color normalization step first [eg i.landsat.rgb], or convert LANDSAT r,g,b pseudo-visual bands to HIS and classify on that (I'm guessing that hue would be less sensitive to sun angle). Nikos: > In my humble opinion, there is no way in this case to completely avoid > some manual digitisation of training samples, or edit the samples you > will extract from CORINE. > There is, on the web, a nice step-by-step which uses COREIN + i.smap on > Landsat [1]. > [1] http://www.custom-scenery.org/Building-Scener.331.0.html interesting. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Original location: How to create from the command line ?
Peter wrote: > is there an (easy) recipe to create a completely new location from > scratch without using a GUI ? To be precise: If GRASS is started for the first time in "-text" mode (=no GUI) ** without having a sample location like Spearfish or North Carolina around**, how can location parameters (projection, extent, EPSG...) be handed over to set up a very first location ? >>> is there also a way to provide the parameters _without_ interaction >>> with the user (-> GRASS scripting & automation) Glynn: > > You can create a new location and mapset with "g.proj -c ...", then > > make it current with g.mapset. But those are GRASS commands, and only > > work within GRASS. Moritz: > I imagine that you can create your own location by having a > script create the location directory, the PERMANENT mapset > directory and the PROJ_INFO, DEFAULT_WIND and PROJ_UNITS > files, or ? So what we need is a wrapper script that will create a dummy location/ mapset in /tmp/ and run 'grass64 + g.proj -c' via a GRASS_BATCH_JOB (be it .sh or .py). Any hints on how the man page parts of the build process accomplish this? To give access to g.parser, could the enviro vars be set up at the start of the script so the thing could bootstrap itself? ie can we somehow find a way to use the GRASS parser from the non-GRASS command line? I'm guessing this is not easy due to the 2-pass way g.parser works, but a smart devel might be able to make it happen somehow. Writing a custom shell script parser as a wrapper for g.proj -c and all its options seems rather non-ideal, but access to 'g.proj -c' from the command line outside GRASS seems like a very nice tool. how do the Tcl/wx GUIs manage the bootstrapping? Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] GRASS 6.4 windows open off screen
Hi folks, I was wondering if any one has encountered this. I am now using GRASS 6.4 RC2. So far I've liked it. The problem I am running into is that when I go to open up a raster or vector map the windows that hold the maps opens off screen. Normally I can see a little bit of it off the right hand side of the monitor that I can grab and pull back onto the screen, though sometimes I have to close GRASS and start again. I am using William Kybgesburye's build on OS X. I don't know if this would have anything to do with it, but I am using two monitors. I don't know if the problem is with GRASS 6.4 or Active Tcl 8.5. Any ideas. Kurt ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: grass-user Digest, Vol 33, Issue 40
On Jan 19, 2009, at 10:00 AM, wrote: Date: Mon, 19 Jan 2009 17:37:07 +0100 From: Moritz Lennert Subject: Re: [GRASS-user] Original location: How to create from the command line ? To: Glynn Clements Cc: grass-user@lists.osgeo.org, Peter L?we Message-ID: <4974ac33.9080...@club.worldonline.be> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 19/01/09 17:16, Glynn Clements wrote: "Peter Löwe" wrote: is there an (easy) recipe to create a completely new location from scratch without using a GUI ? To be precise: If GRASS is started for the first time in "-text" mode (=no GUI) ** without having a sample location like Spearfish or North Carolina around**, how can location parameters (projection, extent, EPSG...) be handed over to set up a very first location ? Just type in the name of the location you want to create and GRASS will prompt you for the parameters. That's true. But is there also a way to provide the parameters _without_ interaction with the user (-> GRASS scripting & automation) You can create a new location and mapset with "g.proj -c ...", then make it current with g.mapset. But those are GRASS commands, and only work within GRASS. I imagine that you can create your own location by having a script create the location directory, the PERMANENT mapset directory and the PROJ_INFO, DEFAULT_WIND and PROJ_UNITS files, or ? Moritz AFAICT, you'll need to script this, since you can't run GRASS commands to create a location until you've started GRASS in a location. We are switching GRASS to primarily use Python for scripting (though it will always be possible to use other languages). Check out the new Python location wizard for code to create locations before starting GRASS. ../gui/wxpythyon/gui_modules/location_wizard.py Michael___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Original location: How to create from the command line ?
On 19/01/09 17:16, Glynn Clements wrote: "Peter Löwe" wrote: is there an (easy) recipe to create a completely new location from scratch without using a GUI ? To be precise: If GRASS is started for the first time in "-text" mode (=no GUI) ** without having a sample location like Spearfish or North Carolina around**, how can location parameters (projection, extent, EPSG...) be handed over to set up a very first location ? Just type in the name of the location you want to create and GRASS will prompt you for the parameters. That's true. But is there also a way to provide the parameters _without_ interaction with the user (-> GRASS scripting & automation) You can create a new location and mapset with "g.proj -c ...", then make it current with g.mapset. But those are GRASS commands, and only work within GRASS. I imagine that you can create your own location by having a script create the location directory, the PERMANENT mapset directory and the PROJ_INFO, DEFAULT_WIND and PROJ_UNITS files, or ? Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Original location: How to create from the command line ?
"Peter Löwe" wrote: > > > is there an (easy) recipe to create a completely new location from > > > scratch without using a GUI ? > > > > > > To be precise: If GRASS is started for the first time in "-text" mode > > > (=no GUI) ** without having a sample location like Spearfish or North > > > Carolina around**, how can location parameters (projection, extent, > > > EPSG...) be handed over to set up a very first location ? > > > > Just type in the name of the location you want to create and GRASS will > > prompt you for the parameters. > That's true. But is there also a way to provide the parameters > _without_ interaction with the user (-> GRASS scripting & automation) You can create a new location and mapset with "g.proj -c ...", then make it current with g.mapset. But those are GRASS commands, and only work within GRASS. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] To change DEM resolution
On Monday 19 January 2009, Edmondo Elisei wrote: > I've a DEM with 90m m res. (from CGIAR SRTM) and I need drape over it a map > tif (resolution 1m). > > Seeing the resultant map in NViz the quality is very low. I suppose it > depends from the different resolutions. > There is a way to change the DEM resolution? > > Thanks > > Regards > > Edmondo if you are using GRASS64, check out r.resamp.interp, otherwise r.bilinear should do the trick. Cheers, Dylan -- Dylan Beaudette Soil Resource Laboratory http://casoilresource.lawr.ucdavis.edu/ University of California at Davis 530.754.7341 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] To change DEM resolution
I've a DEM with 90m m res. (from CGIAR SRTM) and I need drape over it a map tif (resolution 1m). Seeing the resultant map in NViz the quality is very low. I suppose it depends from the different resolutions. There is a way to change the DEM resolution? Thanks Regards Edmondo ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Color names?
Thanks a lot - that answers my question Rainer On Sat, Jan 17, 2009 at 1:10 PM, Glynn Clements wrote: > > Rainer M Krug wrote: > >> Hi >> >> I am looking for a list of the available color names one can use >> (e.g.in r.colors), but I couldn't find them. Could anybody provide me >> with a link of where I can find them or a list of them? > > lib/gis/color_str.c contains the list, as does include/colors.h, and > the output from d.colorlist. > > FWIW, the list is: > >black >red >green >blue >yellow >cyan >magenta >white >grey (alias gray) >orange >aqua >indigo >violet (alias purple) >brown > > This list is used for most GRASS commands, but *not* by ps.map, which > has its own table. Although ps.map supports the same set of names, the > actual colours differ in a few cases: > >nameps.map other >RGB RGB > >grey0.75 0.75 0.75 0.50 0.50 0.50 >aqua0.00 0.75 0.75 0.40 0.50 1.00 >brown 0.75 0.50 0.25 0.70 0.30 0.10 > > -- > Glynn Clements > -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Faculty of Science Natural Sciences Building Private Bag X1 University of Stellenbosch Matieland 7602 South Africa ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Landsat classification with CORINE CLC color codes?
Thanks for the great input! I just want to create a high resolution land use map, based on an already existing classification such as CORINE using Landsat data: I will follow your instructions as below. Regards, Dimos On Mon, 2009-01-19 at 12:40 +0100, Nikos Alexandris wrote: > On Mon, 2009-01-19 at 08:25 +0100, Markus Neteler wrote: > > On Mon, Jan 19, 2009 at 7:42 AM, Dimos wrote: > > > Hello, > > > > > > My apologies if this question is already covered in this list... > > > > > > 44 CORINE CLC RGB color codes are mentioned for each of the 44 land use > > > classes at: > > > http://dataservice.eea.europa.eu/download.asp?id=14234&filetype=.csv > > > > > > Can we classify a Landsat RGB image based on these rgb color codes in > > > GRASS GIS and how? > > > > In my opinion it doesn't make much sense to use the RGB colors here > > since they are arbitrary (well, ok, ideally "close" to natural colors). > > > > What you can do: > > - download the related CORINE shape file(s) > > - extract training areas > > - run i.gensigset to generate statistics > > - run i.smap to do the classification > > - validate > > > > Markus > > Hi! Markus suggestion is one solution. > > I just want to add that, if you take samples (=areas) from CORINE (as > they are), they can be a bit rough to classify a, let's say, 15m > pixel-resolution Landsat satellite image. In my humble opinion, there is > no way in this case to completely avoid some manual digitisation of > training samples, or edit the samples you will extract from CORINE. > > Well, it depends also on what (e.g. which land cover classes) you want > to extract from Landsat. > > There is, on the web, a nice step-by-step which uses COREIN + i.smap on > Landsat [1]. > > Dimo, if you could be a bit more precise... ? > Kind regards, Nikos > > [1] http://www.custom-scenery.org/Building-Scener.331.0.html > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Landsat classification with CORINE CLC color codes?
On Mon, 2009-01-19 at 08:25 +0100, Markus Neteler wrote: > On Mon, Jan 19, 2009 at 7:42 AM, Dimos wrote: > > Hello, > > > > My apologies if this question is already covered in this list... > > > > 44 CORINE CLC RGB color codes are mentioned for each of the 44 land use > > classes at: > > http://dataservice.eea.europa.eu/download.asp?id=14234&filetype=.csv > > > > Can we classify a Landsat RGB image based on these rgb color codes in > > GRASS GIS and how? > > In my opinion it doesn't make much sense to use the RGB colors here > since they are arbitrary (well, ok, ideally "close" to natural colors). > > What you can do: > - download the related CORINE shape file(s) > - extract training areas > - run i.gensigset to generate statistics > - run i.smap to do the classification > - validate > > Markus Hi! Markus suggestion is one solution. I just want to add that, if you take samples (=areas) from CORINE (as they are), they can be a bit rough to classify a, let's say, 15m pixel-resolution Landsat satellite image. In my humble opinion, there is no way in this case to completely avoid some manual digitisation of training samples, or edit the samples you will extract from CORINE. Well, it depends also on what (e.g. which land cover classes) you want to extract from Landsat. There is, on the web, a nice step-by-step which uses COREIN + i.smap on Landsat [1]. Dimo, if you could be a bit more precise... ? Kind regards, Nikos [1] http://www.custom-scenery.org/Building-Scener.331.0.html ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Original location: How to create from the command line ?
peter.lo...@gmx.de wrote: > is there an (easy) recipe to create a completely new location from > scratch without using a GUI ? > > To be precise: > If GRASS is started for the first time in "-text" mode (=no GUI) ** > without having a sample location like Spearfish or North Carolina > around**, how can location parameters (projection, extent, EPSG...) > be handed over to set up a very first location ? You can create a new location via the curses dialog, and specify projection information interactively, but you can't use an EPSG code here. However, you can just provide bogus projection information at that point, then correct it with "g.proj -c ..." once the startup is complete. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.digit under wxGUI
On Sun, 2009-01-18 at 19:30 +0100, Vincent Bain wrote: > OK, > > so in order to fully enjoy the wxpython GUI on an 64 bit architecture > (especially the wxdigit module) one should first read carefully the > README file located in the your_grass_source_location/gui/wxpython > directory. > > The section named "7 - VECTOR DIGITIZER" tells you to create a symbolic > link to a wx library : > > sudo ln -s `locate _gdi_.so` /usr/local/lib/libgdi.so > > The command locate _gdi_.so may points towards the 32 bit library and > ignore (?) the 64 bit libs path (/usr/lib64/...), so it fails. In my > configuration I had to type : > > sudo ln -s /usr/lib64/python2.5/site-packages\ > /wx-2.8-gtk2-unicode/wx/_gdi_.so /usr/local/lib/libgdi.so > > And it worked ! Geat! Thanks ;-) ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Original location: Hot to create from the command line ?
> > is there an (easy) recipe to create a completely new location from > > scratch without using a GUI ? > > > > To be precise: If GRASS is started for the first time in "-text" mode > > (=no GUI) ** without having a sample location like Spearfish or North > > Carolina around**, how can location parameters (projection, extent, > > EPSG...) be handed over to set up a very first location ? > > Just type in the name of the location you want to create and GRASS will > prompt you for the parameters. > > Moritz That's true. But is there also a way to provide the parameters _without_ interaction with the user (-> GRASS scripting & automation) ? Peter -- Dr. Peter Löwe Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Original location: Hot to create from the command line ?
On 19/01/09 10:47, peter.lo...@gmx.de wrote: Hi, is there an (easy) recipe to create a completely new location from scratch without using a GUI ? To be precise: If GRASS is started for the first time in "-text" mode (=no GUI) ** without having a sample location like Spearfish or North Carolina around**, how can location parameters (projection, extent, EPSG...) be handed over to set up a very first location ? Just type in the name of the location you want to create and GRASS will prompt you for the parameters. Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] generating lines from points
On 18/01/09 18:08, Martin Landa wrote: Hi, 2009/1/18 Martin Landa : [...] The more lines you need to generate the longer list of categories will be, not possible to give the list as the parameter. Then v.edit could read categories from stdin, simillary to v.net.path. Hm, what about v.net? New tool to generate network from points? v.net input=points output=net operation=lines line_file=- << EOF 1 1 2 2 2 3 EOF creates edges between points 1-2 and 2-3 with category 1 and 2? better v.net points=points output=net operation=net file=- << EOF 1 1 2 2 2 3 EOF What do you think about that? I think that a GRASS module for connecting lines between chosen points is a definite yes (think of point coordinates of airports with information about flight connections between airports). Up to now I've been doing it with a simple script + v.in.ascii. Not sure v.net is the most logical place to have this. Maybe a stand-alone module v.points2lines ? Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Original location: Hot to create from the command line ?
Hi, is there an (easy) recipe to create a completely new location from scratch without using a GUI ? To be precise: If GRASS is started for the first time in "-text" mode (=no GUI) ** without having a sample location like Spearfish or North Carolina around**, how can location parameters (projection, extent, EPSG...) be handed over to set up a very first location ? Peter -- Dr. Peter Löwe Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
