Re: [GRASS-user] [DWE]- Landsat Cloud detection with GRASS
maning wrote: > Off-topic: I hope the landsat tools (i.topo.corr, > i.landsat.toar, i.landsat.acca, i.landsat.dehaze, i.attcorr) gets into > the core in the future. yes, we're working on .toar and .acca now; I think .dehaze needs some minor cleanup & pythonization for trunk but no one is working on that right now; and i.atcorr is already there in all branches. (today's .acca got a little messy in svn, give it a few days to get cleaned back up) you'll want to read the PDF paper by Irish in the refs section of the .acca man page, it discusses where the cloud detection algorithm does well and where it does not do well: for opaque clouds it does well, for thin semi- transparent clouds it does not do well. creating a cloud MASK from the output of i.landsat.acca with r.reclass or r.mapcalc is very simple. together they form a nice RS suite, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] [DWE]- Landsat Cloud detection with GRASS
2010/9/29 Markus Neteler : > 2010/9/28 António Rocha : >> Greetings >> >> I'm trying to find if GRASS includes some-sort of way to detect/eliminatd >> cloud cover and shadows from LANDSAT Images. >> The only thing I found was this: >> http://svn.osgeo.org/grass/grass-addons/imagery/i.landsat.acca/description.html >> But: >> 1- has anyone tried/used this? Is this useful and working? Yes, I've used it in the past using 6.3 svn. I highly recommend it. You need to convert your Landsat data to top-of-atmosphere radiance or top-of-atmosphere reflectance first before running i.landsat.acca: http://grass.osgeo.org/wiki/GRASS_AddOns#i.landsat.toar Off-topic: I hope the landsat tools (i.topo.corr, i.landsat.toar, i.landsat.acca, i.landsat.dehaze, i.attcorr) gets into the core in the future. > It is currently under active development. Useful - hope so :) > >> 2- can I use it to detect-and-eliminate clouds? > > Should be the idea. The best way is to contact the author who > is very responsive (see manual page). > > Cheers > Markus > >> Thanks >> Antonio >> >> >> __ Information from ESET NOD32 Antivirus, version of virus signature >> database 5486 (20100928) __ >> >> The message was checked by ESET NOD32 Antivirus. >> >> http://www.eset.com >> >> >> ___ >> 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 > -- cheers, maning -- "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: how to v.label d.labels usage - labels do not appear
Thanks it worked! :D -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/how-to-v-label-d-labels-usage-labels-do-not-appear-tp5578731p5581567.html Sent from the Grass - Users mailing list archive at Nabble.com. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: how to v.label d.labels usage - labels do not appear
Thanks a lot, it did apear something but not what i wanted , but with your sugestion "ps- see also 'd.vect disp=attr attrcol=column_name' " it worked ! -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/how-to-v-label-d-labels-usage-labels-do-not-appear-tp5578731p5581564.html Sent from the Grass - Users mailing list archive at Nabble.com. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] multi-date image segmentation in grass
On Tue, Sep 28, 2010 at 1:12 PM, maning sambale wrote: > Hi, > > I have several Landsat (4-7) images from 1990-2002 which will be used > for change analysis of land cover. FAO's FRA-RSS [1] developed a > standard methodology for integrating multi-temporal Landsat into a > consistent sample tiles. The article [2] outlined the general method > as: > - Image subsetting > - Radiometric normalization > - Contrast enhancement > - Multi-date image segmentation > > Most of the processing procedures I was able to do in GRASS GIS, > except for the last step. The process combined the multi-date imagery > where an automated image segmentation was implemented to derive > preliminary polygons to identify changes. I believe they used > ecognition for the segmentation. We can (start to) recommend r.seg from Addons for this (I will ask the author to accept inclusion in GRASS 7 as i.segmentation). We could greatly improve the performance of i.smap by preprocessing data with r.seg. > I've used i.smap for preliminary > segmentation on separate dates but not for a combined multi-date > imagery. Anyone tried this with GRASS? Can i.pca do this or another > tool? I didn't try but it sounds interesting also for us (just lack of time). If could provide me with a small spatial excerpt of all the channels as location, I would try a few ideas and report. Markus > Any idea > > [1] http://www.fao.org/forestry/fra/remotesensingsurvey/en/ > [2] > http://www.informaworld.com/smpp/content~content=a923063789~db=all~jumptype=rss > > -- > cheers, > maning > -- > "Freedom is still the most radical idea of all" -N.Branden > wiki: http://esambale.wikispaces.com/ > blog: http://epsg4253.wordpress.com/ > -- > ___ > 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] [DWE]- Landsat Cloud detection with GRASS
2010/9/28 António Rocha : > Greetings > > I'm trying to find if GRASS includes some-sort of way to detect/eliminatd > cloud cover and shadows from LANDSAT Images. > The only thing I found was this: > http://svn.osgeo.org/grass/grass-addons/imagery/i.landsat.acca/description.html > But: > 1- has anyone tried/used this? Is this useful and working? It is currently under active development. Useful - hope so :) > 2- can I use it to detect-and-eliminate clouds? Should be the idea. The best way is to contact the author who is very responsive (see manual page). Cheers Markus > Thanks > Antonio > > > __ Information from ESET NOD32 Antivirus, version of virus signature > database 5486 (20100928) __ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > ___ > 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] Region and not-processed data
This thread in the archives may answer your questions. http://osgeo-org.1803224.n2.nabble.com/Import-question-td5551110.html#a5558429 HTH, Stephen Sefick On Tue, Sep 28, 2010 at 8:17 AM, Kim Besson wrote: > Hi > Ok about this I just need to have an idea (or a link that can explain me > this): > 1- When I import a raster map (r.in.gdal) will it import all the raster or > only the portion that fits in the current defined region? > 2- If I define as a region a wider area than the image, will it process > where the image is not available? > Thanks > Kim > > 2010/9/27 stephen sefick >> >> Where you don't have the image, if I understand you correctly, would >> be NULL values? In that case you will have to default to someone more >> experienced, but I suspect that it is run on the entire map, but NULL >> means no data so no process. Just a wag. >> hth >> >> Stephen >> >> On Mon, Sep 27, 2010 at 8:58 AM, Kim Besson >> wrote: >> > Hi stephen and rest of GRASS users >> > >> > That was not my quiestion. My question is: if a have a an uimage inside >> > a >> > regions, will it process and run for all the region or only for where I >> > have >> > the image(it's not importing only image-processing). ? >> > >> > Thanks >> > Kim >> > >> > 2010/9/27 stephen sefick >> >> >> >> I get a little confused with the region raster processing stuff also. >> >> But, this is what I do, and it seems to work. Anything that is >> >> brought in from the outside (r.in.*) will import the entire map. >> >> Anything that is done withing GRASS will respect the region. So, just >> >> make sure to set the region before each calculation and you should be >> >> OK. >> >> >> >> On Mon, Sep 27, 2010 at 8:52 AM, Kim Besson >> >> wrote: >> >> > Greetings >> >> > >> >> > I have a very "dumb" question regarding region definition/processing: >> >> > - I have defined a an area (example; 30N 20S -10W -5W). I have a >> >> > raster >> >> > image with (30N 15N -7W -5) I mean, it only cover a part of the >> >> > region. >> >> > If I >> >> > run GRASS image-processing algorithms and processors does it run in >> >> > all >> >> > image or only where I have a raster image? >> >> > >> >> > Thanks and sorry for tyhis such a dumb question >> >> > Kim >> >> > ___ >> >> > grass-user mailing list >> >> > grass-user@lists.osgeo.org >> >> > http://lists.osgeo.org/mailman/listinfo/grass-user >> >> > >> >> > >> >> >> >> >> >> >> >> -- >> >> Stephen Sefick >> >> >> >> | Auburn University | >> >> | Department of Biological Sciences | >> >> | 331 Funchess Hall | >> >> | Auburn, Alabama | >> >> | 36849 | >> >> |___| >> >> | sas0...@auburn.edu | >> >> | http://www.auburn.edu/~sas0025 | >> >> |___| >> >> >> >> Let's not spend our time and resources thinking about things that are >> >> so little or so large that all they really do for us is puff us up and >> >> make us feel like gods. We are mammals, and have not exhausted the >> >> annoying little problems of being mammals. >> >> >> >> -K. Mullis >> >> >> >> "A big computer, a complex algorithm and a long time does not equal >> >> science." >> >> >> >> -Robert Gentleman >> > >> > >> >> >> >> -- >> Stephen Sefick >> >> | Auburn University | >> | Department of Biological Sciences | >> | 331 Funchess Hall | >> | Auburn, Alabama | >> | 36849 | >> |___| >> | sas0...@auburn.edu | >> | http://www.auburn.edu/~sas0025 | >> |___| >> >> Let's not spend our time and resources thinking about things that are >> so little or so large that all they really do for us is puff us up and >> make us feel like gods. We are mammals, and have not exhausted the >> annoying little problems of being mammals. >> >> -K. Mullis >> >> "A big computer, a complex algorithm and a long time does not equal >> science." >> >> -Robert Gentleman > > > ___ > grass-user mailing list > grass-user@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > > -- Stephen Sefick | Auburn University | | Department of Biological Sciences | | 331 Funchess Hall | | Auburn, Alabama | | 36849
[GRASS-user] [DWE]- Landsat Cloud detection with GRASS
Greetings I'm trying to find if GRASS includes some-sort of way to detect/eliminatd cloud cover and shadows from LANDSAT Images. The only thing I found was this: http://svn.osgeo.org/grass/grass-addons/imagery/i.landsat.acca/description.html But: 1- has anyone tried/used this? Is this useful and working? 2- can I use it to detect-and-eliminate clouds? Thanks Antonio __ Information from ESET NOD32 Antivirus, version of virus signature database 5486 (20100928) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Region and not-processed data
Hi Ok about this I just need to have an idea (or a link that can explain me this): 1- When I import a raster map (r.in.gdal) will it import all the raster or only the portion that fits in the current defined region? 2- If I define as a region a wider area than the image, will it process where the image is not available? Thanks Kim 2010/9/27 stephen sefick > Where you don't have the image, if I understand you correctly, would > be NULL values? In that case you will have to default to someone more > experienced, but I suspect that it is run on the entire map, but NULL > means no data so no process. Just a wag. > hth > > Stephen > > On Mon, Sep 27, 2010 at 8:58 AM, Kim Besson > wrote: > > Hi stephen and rest of GRASS users > > > > That was not my quiestion. My question is: if a have a an uimage inside a > > regions, will it process and run for all the region or only for where I > have > > the image(it's not importing only image-processing). ? > > > > Thanks > > Kim > > > > 2010/9/27 stephen sefick > >> > >> I get a little confused with the region raster processing stuff also. > >> But, this is what I do, and it seems to work. Anything that is > >> brought in from the outside (r.in.*) will import the entire map. > >> Anything that is done withing GRASS will respect the region. So, just > >> make sure to set the region before each calculation and you should be > >> OK. > >> > >> On Mon, Sep 27, 2010 at 8:52 AM, Kim Besson > >> wrote: > >> > Greetings > >> > > >> > I have a very "dumb" question regarding region definition/processing: > >> > - I have defined a an area (example; 30N 20S -10W -5W). I have a > raster > >> > image with (30N 15N -7W -5) I mean, it only cover a part of the > region. > >> > If I > >> > run GRASS image-processing algorithms and processors does it run in > all > >> > image or only where I have a raster image? > >> > > >> > Thanks and sorry for tyhis such a dumb question > >> > Kim > >> > ___ > >> > grass-user mailing list > >> > grass-user@lists.osgeo.org > >> > http://lists.osgeo.org/mailman/listinfo/grass-user > >> > > >> > > >> > >> > >> > >> -- > >> Stephen Sefick > >> > >> | Auburn University | > >> | Department of Biological Sciences | > >> | 331 Funchess Hall | > >> | Auburn, Alabama | > >> | 36849| > >> |___| > >> | sas0...@auburn.edu | > >> | http://www.auburn.edu/~sas0025 | > >> |___| > >> > >> Let's not spend our time and resources thinking about things that are > >> so little or so large that all they really do for us is puff us up and > >> make us feel like gods. We are mammals, and have not exhausted the > >> annoying little problems of being mammals. > >> > >> -K. Mullis > >> > >> "A big computer, a complex algorithm and a long time does not equal > >> science." > >> > >> -Robert Gentleman > > > > > > > > -- > Stephen Sefick > > | Auburn University | > | Department of Biological Sciences | > | 331 Funchess Hall | > | Auburn, Alabama | > | 36849| > |___| > | sas0...@auburn.edu | > | http://www.auburn.edu/~sas0025 | > |___| > > Let's not spend our time and resources thinking about things that are > so little or so large that all they really do for us is puff us up and > make us feel like gods. We are mammals, and have not exhausted the > annoying little problems of being mammals. > > -K. Mullis > > "A big computer, a complex algorithm and a long time does not equal > science." > > -Robert Gentleman > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: how to v.label d.labels usage - labels do not appear
On 28/09/2010 13:07, lara wrote: I see my raster map.. when i display it first... if not.. i see nothing.. Raster? Please try this first First: v.info -c What's the name of the column that contains the labels? If there are no column names, then rerun the ascii import as follows: v.in.ascii --o in=/stations_LU_AB out=stations_LU_ab columns="x double precision, y double precision, label varchar(8)" (I'm assuming the columns are X first then Y) Recheck v.info -c to be sure you've got the label column. Now do: d.erase g.region -p vect=stations_LU_ab d.vect stations_LU_ab disp=shape,attr attrcol=label What do you get? If this works, then redo the v.label command and retry the d.vect and d.labels command as before. -- Micha Silver http://www.surfaces.co.il/ Arava Development Co. +972-52-3665918 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] how to v.label d.labels usage - labels do not appear
Lara wrote: > Dear all > I am quite new to GRASS, only use it few times. > I need to label my points, so i tried to use v.label > i have this file which i imported with : > v.in.ascii --o in=/stations_LU_AB out=stations_LU_ab > > 705131.45|5513243.33|LU0104A ... > 725777.59|5505529.71|LU0106A > > and it works fine... then i used v.label > > v.label labels=stat_labels map=stations_LU_ab column=cat > type=point,centroid layer=1 xoffset=0 yoffset=0 > reference=center font=standard size=100 > color=black rotation=0 width=1 hcolor=none hwidth=0 > background=none border=none opaque=yes > > ... there were no complains: > "Labeled 14 lines." > > and finally : > > d.vect stations_LU_ab > d.labels stat_labels > > > and it nothing appears ... :( > > Could you give me some lights in what I am doing wrong? I think I know the reason- the quick answer is try to use the v.label fontsize= option. set it to 10 or 12 or so. the long answer is that v.label has both size= and fontsize= options. The fontsize= works as you might expect, but the size= option (the default) is measured in map units. So in your case it would make the labels sized as 100 meters on the map. If you zoom way out that becomes very tiny and the label disappears. (see also the d.labels min and max options) This exists so you can have things like town names sized to the population, so when you zoom in you see the small towns but when you zoom out to the country scale you only see the big cities, and labels do not overlap when you change the zoom. Also it is for precision when designing cartography with ps.map. But if you set fontsize=10 or so, the labels will be the same size regardless of the map scale. (I had this same problem last week) Hamish ps- see also 'd.vect disp=attr attrcol=column_name' ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] multi-date image segmentation in grass
Hi, I have several Landsat (4-7) images from 1990-2002 which will be used for change analysis of land cover. FAO's FRA-RSS [1] developed a standard methodology for integrating multi-temporal Landsat into a consistent sample tiles. The article [2] outlined the general method as: - Image subsetting - Radiometric normalization - Contrast enhancement - Multi-date image segmentation Most of the processing procedures I was able to do in GRASS GIS, except for the last step. The process combined the multi-date imagery where an automated image segmentation was implemented to derive preliminary polygons to identify changes. I believe they used ecognition for the segmentation. I've used i.smap for preliminary segmentation on separate dates but not for a combined multi-date imagery. Anyone tried this with GRASS? Can i.pca do this or another tool? Any idea [1] http://www.fao.org/forestry/fra/remotesensingsurvey/en/ [2] http://www.informaworld.com/smpp/content~content=a923063789~db=all~jumptype=rss -- cheers, maning -- "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: how to v.label d.labels usage - labels do not appear
I see my raster map.. when i display it first... if not.. i see nothing.. -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/how-to-v-label-d-labels-usage-labels-do-not-appear-tp5578731p5578900.html Sent from the Grass - Users mailing list archive at Nabble.com. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: how to v.label d.labels usage - labels do not appear
On 28/09/2010 12:55, lara wrote: thnaks Micha.. But i've tried that and it does not work... I 'm probably skiping some important step...??!!?!? Do you see anything in the graphics monitor windows? -- Micha Silver http://www.surfaces.co.il/ Arava Development Co. +972-52-3665918 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: how to v.label d.labels usage - labels do not appear
thnaks Micha.. But i've tried that and it does not work... I 'm probably skiping some important step...??!!?!? -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/how-to-v-label-d-labels-usage-labels-do-not-appear-tp5578731p5578868.html Sent from the Grass - Users mailing list archive at Nabble.com. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] how to v.label d.labels usage - labels do not appear
On 28/09/2010 12:02, lara wrote: Dear all I am quite new to GRASS, only use it few times. I need to label my points, so i tried to use v.label i have this file which i imported with : v.in.ascii --o in=/stations_LU_AB out=stations_LU_ab 705131.45|5513243.33|LU0104A 738198.49|5513485.53|LU0105A 715628.70|5486561.69|LU0001A 739861.59|5489430.06|LU0099A 715474.80|5488410.95|LU0102A 726771.85|553.64|LU0013A 726722.32|5499259.57|LU0101A 725889.30|5499966.84|LU0100A 710345.43|5504908.79|LU0008A 727890.58|5537167.57|LU0103A 725969.76|5499970.19|LU0012A 717207.29|5487366.69|LU0107A 728209.78|5537181.14|LU0018A 725777.59|5505529.71|LU0106A and it works fine... then i used v.label v.label labels=stat_labels map=stations_LU_ab column=cat type=point,centroid layer=1 xoffset=0 yoffset=0 reference=center font=standard size=100 color=black rotation=0 width=1 hcolor=none hwidth=0 background=none border=none opaque=yes ... there were no complains: "Labeled 14 lines." and finally : d.vect stations_LU_ab d.labels stat_labels and it nothing appears ... :( Maybe you're not at the right region. Try first: g.region vect=stations_LU_ab Could you give me some lights in what I am doing wrong? I thank you in advance Lara A. REis -- Micha Silver http://www.surfaces.co.il/ Arava Development Co. +972-52-3665918 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] how to v.label d.labels usage - labels do not appear
Dear all I am quite new to GRASS, only use it few times. I need to label my points, so i tried to use v.label i have this file which i imported with : v.in.ascii --o in=/stations_LU_AB out=stations_LU_ab 705131.45|5513243.33|LU0104A 738198.49|5513485.53|LU0105A 715628.70|5486561.69|LU0001A 739861.59|5489430.06|LU0099A 715474.80|5488410.95|LU0102A 726771.85|553.64|LU0013A 726722.32|5499259.57|LU0101A 725889.30|5499966.84|LU0100A 710345.43|5504908.79|LU0008A 727890.58|5537167.57|LU0103A 725969.76|5499970.19|LU0012A 717207.29|5487366.69|LU0107A 728209.78|5537181.14|LU0018A 725777.59|5505529.71|LU0106A and it works fine... then i used v.label v.label labels=stat_labels map=stations_LU_ab column=cat type=point,centroid layer=1 xoffset=0 yoffset=0 reference=center font=standard size=100 color=black rotation=0 width=1 hcolor=none hwidth=0 background=none border=none opaque=yes ... there were no complains: "Labeled 14 lines." and finally : d.vect stations_LU_ab d.labels stat_labels and it nothing appears ... :( Could you give me some lights in what I am doing wrong? I thank you in advance Lara A. REis -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/how-to-v-label-d-labels-usage-labels-do-not-appear-tp5578731p5578731.html Sent from the Grass - Users mailing list archive at Nabble.com. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] converting lines to polygons
On 28/09/2010 10:00, Markus Metz wrote: Micha Silver: Markus Metz wrote: Micha Silver wrote: In any case, importing polygon shapefiles first as lines (not boundaries), doing the topology cleanup, and then convert to boundaries and add centroids seems to be the smoother way to go. I object because 1. you would need to replicate the cleaning steps done by v.in.ogr which has, amongst others, a snapping option I never noticed that option. http://grass.osgeo.org/grass64/manuals/html64_user/v.in.ogr.html Still, importing unclean shapefile polygons, and correcting the topology is often accompanied by much hair pulling... Unfortunately yes. If data providers would only provide clean data... I have partially good news: v.in.ogr in 6.4.1 and above is faster and produces cleaner and smaller output. Further on, it shows progress when cleaning polygons, indicating that something is happening. Previously (up to 6.4.0), it went silent for quite some time on larger polygon imports which annoyed me considerably, I want to see that something is happening. Great, I'm looking forward to seeing the improvements. Markus M This mail was received via Mail-SeCure System. -- Micha Silver http://www.surfaces.co.il/ Arava Development Co. +972-52-3665918 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Estimating Albedo from Landsat
Nikos wrote: > > Downloaded: > > - extra: LT50160351988258XXX03 (includes visible > > clouds - maybe good for testing?) in the GloVis preview I only see a few clouds in the NE corner for that date. (Sept 14, 1988) Maybe 1991/10/25 is another good scene for a cloud test? (looks like 20% high cumulus with shadows) Note the % cloud cover in the GloVis previewer is (AFAIU) using the same ACCA algorithm as i.landsat.acca, so the result should be similar. (??) For the Sept 14, 1998 example the GloVis info says 0% cloud cover, but maybe that data is old and the latest ACCA says something else? > # rgb colors for 742 > i.landsat.rgb r=lsat5_1988.2 g=lsat5_1988.4 b=lsat5_1988.7 > strength=96 > d.rgb r=lsat5_1988.2 g=lsat5_1988.4 b=lsat5_1988.7 # > obvious clouds maybe i.landsat.dehaze is worth trying before i.landsat.rgb? > # toar > i.landsat.toar band_prefix=lsat5_1988 method=uncorrected \ > sensor=5 product_date=1988-09-14 date=1988-09-14 \ > solar_elevation=48.6773844 do not assume production date is the same as acq. date; check metadata values against values in the source code. For the Mar 31, 2000 sample data it made a difference. > # acca > i.landsat.acca -5f2 band_prefix=lsat5_1988.toar \ > output=lsat5_1988.toar.acca > > # how many cats? > r.info lsat5_1988.toar.acca -r > min=6 > max=9 see r.category, r.stats -c, or d.legend for meaning of category numbers. (6=cold cloud, 9=warm cloud, 2=shadow) i.landsat.acca is in flux today, best to wait a few days .. (some earlier improvements just got clobbered and new ones introduced, so I'm unsure of where we are now) > In the "acca" result: > > - clouds are detected (cat=6), not that bad(ly) I suppose. > Some filtering could push away the (rest of the) "noise". the cloud despeckle filter can remove some lone non-cloud cells which are surrounded by cloud. after that I guess it's r.neighbors or r.mfilter. > - obvious mis-detections (commission errors) found within > - n=188310 s=168270 w=618870 e=636150 (bare ground? > urban area? not sure > about the confusing land cover/class here...) > - n=219030 s=180510 w=646410 e=655740 (road) ? maybe google maps satellite view helps if the landsat is too coarse to ID features. > - in the borders due to the non-identical extent of > all bands (!?) I've seen something similar, maybe r.series to accumulate NULLs in all input bands and use that as a MASK? > - categories 7 and 8 seem to be empty, category 9 looks > very messy cat 7,8 are undefined, cat 9 probably has more false positives in warm land, cat 6 (cold cloud) probably has more problems in snowy areas. > Could it be that non-cloudy acquisitions are mistreated by > the algorithm? The paper by Irish listed in the i.landsat.acca man page is worth reading, it explains a lot and points out where the algorithm does not do well. > I can't clearly recognise clouds in the landsat > scenes included in NC data set > (both the 1987 and the 2000 scenes). I'd guess that they were specifically chosen to avoid days with obscuring clouds. > Will (then) the algorithm work (only) with (very) cloudy > data? One thing the paper mentions, and I've observed, is that it does not do well with thin wispy cirrus clouds. Apparently MODIS does a bit better there because it has a detector in the needed 2um range to pick those up, while the Landsat only has 11um which misses those cloud tops. (IIRC) fyi, I've just added what we know about the NC 2008 dataset Landsat images to the grass wiki: http://grass.osgeo.org/wiki/LANDSAT#Sample_data I'm downloading them now.. I expect they'll be reprocessed versus the metadata calibration values shipped with the dataset. (??) Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] converting lines to polygons
Micha Silver: > Markus Metz wrote: > >> Micha Silver wrote: >> >>> >>> In any case, importing polygon shapefiles first as lines (not >>> boundaries), >>> doing the topology cleanup, and then convert to boundaries and add >>> centroids >>> seems to be the smoother way to go. >>> >> >> I object because >> >> 1. you would need to replicate the cleaning steps done by v.in.ogr >> which has, amongst others, a snapping option >> >> > > I never noticed that option. http://grass.osgeo.org/grass64/manuals/html64_user/v.in.ogr.html > > Still, importing unclean shapefile polygons, and correcting the topology is > often accompanied by much hair pulling... Unfortunately yes. If data providers would only provide clean data... I have partially good news: v.in.ogr in 6.4.1 and above is faster and produces cleaner and smaller output. Further on, it shows progress when cleaning polygons, indicating that something is happening. Previously (up to 6.4.0), it went silent for quite some time on larger polygon imports which annoyed me considerably, I want to see that something is happening. Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: grass-user, , , , how to convert poly line as polygon....
On 28/09/2010 07:29, bharath s wrote: hai, i have one map info (dxf ,mif) file ,which is a region , if i read from grass using v.in.ogr, v.in.dxf the boundary is coming as poly line not polygon (region )...please help me ,how can i convert the map as region using grass...even i tried the shape file also ... First check If the polylines are imported as closed boundaries with: v.info -t (Note the line "boundaries=...") If you don't have closed boundaries, you'll have to do some cleaning to snap the nodes of the polylines together with v.clean ... tool=snap, etc. Then just run: v.centroids out= to add centroids to each closed boundary. This mail was received via Mail-SeCure System. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user This mail was received via Mail-SeCure System. -- Micha Silver http://www.surfaces.co.il/ Arava Development Co. +972-52-3665918 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] converting lines to polygons
On 27/09/2010 20:29, Markus Metz wrote: Micha Silver wrote: Cheers. Although I think I misled you a bit. I was mistaken about the orange line color in the digitizer. It simply indicates a boundary that is wholly shared by two adjacent areas. *Not* a topological error. In any case, importing polygon shapefiles first as lines (not boundaries), doing the topology cleanup, and then convert to boundaries and add centroids seems to be the smoother way to go. I object because 1. you would need to replicate the cleaning steps done by v.in.ogr which has, amongst others, a snapping option I never noticed that option. 2. adding centroids will add centroids to all areas, also those that where holes in polygons provided by OGR, e.g. a waterbodies shapefile with lakes and islands in lakes: the islands are not waterbodies and should not get a centroid I think Bryan's original problem was areas being imported without centroids. But in the general case, I see that importing lines, then converting to boundaries and adding centroids would be wrong. 3. you will loose attributes because there is no (easy) way to link any attributes coming with the shapefile to newly generated centroids, e.g. land cover/land use shapefiles Yes, this was clear. Markus M Still, importing unclean shapefile polygons, and correcting the topology is often accompanied by much hair pulling... Thanks for the clarifications! -- Micha ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
