Re: [GRASS-dev] g.remove usage syntax
On Tue, May 5, 2015 at 3:30 AM, Martin Landa landa.mar...@gmail.com wrote: Hi, 2015-05-05 12:28 GMT+02:00 Margherita Di Leo direg...@gmail.com: being name one of the two options (name, pat) that could be identifier= or something better. In this case, it would be possible to type the former command or the extended form: g.remove type=vect identifier=name name=foo -f or g.remove type=vect identifier=pattern name=f* -f (g.remove vect pat f* -f) what do you think? no idea, in any case it's issue for GRASS 8. Martin Sure. Is there any place (track? wiki?) already where to collect and discuss ideas? I saw recently in ML another post about r.shaded.relief, I haven't followed up but perhaps also that discussion could be included. Thanks -- Best regards, Dr. Margherita DI LEO Scientific / technical project officer European Commission - DG JRC Institute for Environment and Sustainability (IES) Via Fermi, 2749 I-21027 Ispra (VA) - Italy - TP 261 Tel. +39 0332 78 3600 margherita.di-...@jrc.ec.europa.eu Disclaimer: The views expressed are purely those of the writer and may not in any circumstance be regarded as stating an official position of the European Commission. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Testing an add-on from sandbox before moving to grass-addons
On Tue, May 5, 2015 at 8:41 AM, Nikos Alexandris n...@nikosalexandris.net wrote: * Martin Landa landa.mar...@gmail.com [2015-05-05 13:41:32 +0200]: 2015-05-05 13:42 GMT+02:00 Nikos Alexandris n...@nikosalexandris.net: it's not possible, to enable installing this extension via g.extension, you need to move this extension to `grass7/imagery`. Thanks Martin. Is grass7/imagery the safest place to move into? Just to confirm. yes, as grass7/imagery/i.fusion.hpf. Use `svn move` to do this job. Martin Noted, thank you for your time. You need to `svn checkout` the whole repository for this operation. At least this is what I have (grass-addons for work in addons but also the whole repo for these moves). Nikos ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Error reading null row 8 for MASK
http://pastebin.com/rMgRsqDp 2015-05-04 15:36 GMT-03:00 Markus Neteler nete...@osgeo.org: On Mon, May 4, 2015 at 8:05 PM, Alba German albager...@gmail.com wrote: Hello! I am running a loop with several r.mapcalc. I am using GRASS 7.1. The function stops with an error: ERROR: Error reading null row 8 for MASK I've noticed that Paulo van Breugel, had the same error but I didn't see the solution to it. Obviously it has something to do with the raster called MASK, created with r.mask before running the loop of multiple r.mapcalc. The code itself has no problem and is very simple and works just fine with the same list of images, but without running r.mask first. Hi Alba, could you post that part of the code e.g. here http://pastebin.com/ ? It sounds like a race condition... Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Testing an add-on from sandbox before moving to grass-addons
2015-05-05 13:42 GMT+02:00 Nikos Alexandris n...@nikosalexandris.net: it's not possible, to enable installing this extension via g.extension, you need to move this extension to `grass7/imagery`. Thanks Martin. Is grass7/imagery the safest place to move into? Just to confirm. yes, as grass7/imagery/i.fusion.hpf. Use `svn move` to do this job. Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.cz/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] g.remove usage syntax
On 05/05/15 12:28, Margherita Di Leo wrote:
Dear All,
I find the current syntax of g.remove a bit cumbersome, because it
doesn't seem to me in line with what happens with other commands.
If I want to remove the vector file foo, I have to type:
g.remove vect name=foo -f
Without the name= it won't work, which is not in line to the usage of
other commands.
To me it would be more natural (and indeed i always type wrong the first
time) something like:
g.remove vect name foo -f
being name one of the two options (name, pat) that could be identifier=
or something better. In this case, it would be possible to type the
former command or the extended form:
g.remove type=vect identifier=name name=foo -f
or
g.remove type=vect identifier=pattern name=f* -f
(g.remove vect pat f* -f)
what do you think?
AFAIK, this would mean a fundamental change in the way the parser works.
I think it might be better to create small wrapper scripts, e.g.:
g.remove.vect
which could use just the name option of g.remove to have a syntax such
as this:
g.remove.vect foo -f
If you use GNU/Linux you can also do this very simply by defining a
function in .grass7/bashrc:
g.remove.vect ()
{
g.remove type=vect name=$@
}
Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] g.remove usage syntax
2015-05-05 14:28 GMT+02:00 Margherita Di Leo direg...@gmail.com: Sure. Is there any place (track? wiki?) already where to collect and discuss ideas? I saw recently in ML another post about r.shaded.relief, I haven't followed up but perhaps also that discussion could be included. why not ticket with milestone 'GRASS 8'? Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.cz/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Testing an add-on from sandbox before moving to grass-addons
On Tue, May 5, 2015 at 2:41 PM, Nikos Alexandris n...@nikosalexandris.net wrote: * Martin Landa landa.mar...@gmail.com [2015-05-05 13:41:32 +0200]: 2015-05-05 13:42 GMT+02:00 Nikos Alexandris n...@nikosalexandris.net: it's not possible, to enable installing this extension via g.extension, you need to move this extension to `grass7/imagery`. Thanks Martin. Is grass7/imagery the safest place to move into? Just to confirm. In which sense safest place? The directory grass-addons/grass7/imagery/ is the right place for imagery Addons. best Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Testing an add-on from sandbox before moving to grass-addons
Nikos Alexandris: I am trying to not mess-up anything in grass-addons. Hence, I first uploaded the i.fusion.hpf script in sandbox: https://svn.osgeo.org/grass/sandbox/alexandris/i.fusion.hpf/. Is it possible to get the add-on from the sandox, via g.extension, under Windows? I have no easy access to a windows machine with GRASS and co. Martin: it's not possible, to enable installing this extension via g.extension, you need to move this extension to `grass7/imagery`. Thanks Martin. Is grass7/imagery the safest place to move into? Just to confirm. Nikos ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Testing an add-on from sandbox before moving to grass-addons
* Martin Landa landa.mar...@gmail.com [2015-05-05 13:41:32 +0200]: 2015-05-05 13:42 GMT+02:00 Nikos Alexandris n...@nikosalexandris.net: it's not possible, to enable installing this extension via g.extension, you need to move this extension to `grass7/imagery`. Thanks Martin. Is grass7/imagery the safest place to move into? Just to confirm. yes, as grass7/imagery/i.fusion.hpf. Use `svn move` to do this job. Martin Noted, thank you for your time. Nikos ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] g.remove usage syntax
On Tue, May 5, 2015 at 2:46 PM, Martin Landa landa.mar...@gmail.com wrote: 2015-05-05 14:28 GMT+02:00 Margherita Di Leo direg...@gmail.com: Sure. Is there any place (track? wiki?) already where to collect and discuss ideas? I saw recently in ML another post about r.shaded.relief, I haven't followed up but perhaps also that discussion could be included. why not ticket with milestone 'GRASS 8'? Martin yes and additionally http://trac.osgeo.org/grass/wiki/Grass8Planning Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] g.remove usage syntax
Hi Moritz,
On Tue, May 5, 2015 at 2:27 PM, Moritz Lennert mlenn...@club.worldonline.be
wrote:
On 05/05/15 12:28, Margherita Di Leo wrote:
Dear All,
I find the current syntax of g.remove a bit cumbersome, because it
doesn't seem to me in line with what happens with other commands.
If I want to remove the vector file foo, I have to type:
g.remove vect name=foo -f
Without the name= it won't work, which is not in line to the usage of
other commands.
To me it would be more natural (and indeed i always type wrong the first
time) something like:
g.remove vect name foo -f
being name one of the two options (name, pat) that could be identifier=
or something better. In this case, it would be possible to type the
former command or the extended form:
g.remove type=vect identifier=name name=foo -f
or
g.remove type=vect identifier=pattern name=f* -f
(g.remove vect pat f* -f)
what do you think?
AFAIK, this would mean a fundamental change in the way the parser works.
hmm.. I don't understand why. I tried to tailor this proposal on the
current behavior of the parser, as far as I could understand it. Can you
explain a bit more?
I think it might be better to create small wrapper scripts, e.g.:
g.remove.vect
which could use just the name option of g.remove to have a syntax such as
this:
g.remove.vect foo -f
If you use GNU/Linux you can also do this very simply by defining a
function in .grass7/bashrc:
g.remove.vect ()
{
g.remove type=vect name=$@
}
Thanks for the idea, I'll try .
--
Best regards,
Dr. Margherita DI LEO
Scientific / technical project officer
European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261
Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu
Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Error reading null row 8 for MASK
And just to be sure - OS and Python version. I was observing some strange error on Windows some time a go while running similar simple loop script. As on Linux it was fine, I wasn't investigating it any further. Maris. 2015-05-05 23:49 GMT+03:00 Luca Delucchi lucadel...@gmail.com: On 5 May 2015 at 13:49, Alba German albager...@gmail.com wrote: http://pastebin.com/rMgRsqDp could you send the output of r.info puntosmonitoreo -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] g.remove usage syntax
On 05/05/15 15:41, Margherita Di Leo wrote: Hi Moritz, On Tue, May 5, 2015 at 2:27 PM, Moritz Lennert mlenn...@club.worldonline.be mailto:mlenn...@club.worldonline.be wrote: On 05/05/15 12:28, Margherita Di Leo wrote: Dear All, I find the current syntax of g.remove a bit cumbersome, because it doesn't seem to me in line with what happens with other commands. If I want to remove the vector file foo, I have to type: g.remove vect name=foo -f Without the name= it won't work, which is not in line to the usage of other commands. To me it would be more natural (and indeed i always type wrong the first time) something like: g.remove vect name foo -f being name one of the two options (name, pat) that could be identifier= or something better. In this case, it would be possible to type the former command or the extended form: g.remove type=vect identifier=name name=foo -f or g.remove type=vect identifier=pattern name=f* -f (g.remove vect pat f* -f) what do you think? AFAIK, this would mean a fundamental change in the way the parser works. hmm.. I don't understand why. I tried to tailor this proposal on the current behavior of the parser, as far as I could understand it. Can you explain a bit more? AFAIK, the parser only accepts the first argument as positional argument, for all the other arguments you have to provide the parameter name, so in your proposal g.remove vect id=name searchstring=foo would work, but g.remove vect name foo wouldn't. As a side question: why do you find g.remove type=vect id=pattern name=f* easier than the current g.remove type=vect pattern=f* ? The current behaviour does mean less typing (and just as much compared to your proposal with positional parameters, except for the '='). Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Landsat 5TM pre-processing - histogram matching - problem
Hello! It's me again :) If you go all the way from DN to Top-of-Atmosphere reflectances (via i.landsat.toar), then to Top-of-Canopy (via i.atcorr), you'll have floating point values ranging in [0, 1.0]. If you recode this back to 8-bit, you should consider whether there is an important loss of the radiometric resolution. So, recoding to another range is different than converting to integer numbers and trying to preserve the range. The thing that worries me is that I don't know how to check if the loss of the radiometric resolution is important :/ What should I compare? I was trying to convert to integer through r.mapcalc (the only other way I've found) with the function int(x) and x was my map (I hope it was ok to put map instead of x) but the result was a map with "one shade" of grey, so maybe it was wrong to put a map instead of x... According to i.atcorr there is an option "output raster map as integer" (i), so if my input file will be _toar2@konfa (float) and I check that option I will have a map with integer values, right? However, the most confusing thing for me with i.atcorr is "the aerosol optical depth". I don't have "meteorological parameter visibility". I have images from 1984 and 2007. I've found files forGlobal Aerosol Climatology (1981-2006)on this websitehttp://gacp.giss.nasa.gov/data_sets/ I've found the proper row and column in the asci format, but they don't have data for 2007. I was trying to find it on different pageshttp://modis-atmos.gsfc.nasa.gov/MOD04_L2/acquiring.html but areas of my interest are black - so no data. On your page github with i.landsat.toar and i.atcorr you wrote "the value for aerosols optical depth (AOD), is set to 0.111 for winter and 0.222 for summer aquisitions" Are these default values? For DOS methods? Can I use i.landsat.toar with DOS3instead of i.atcorr? The others where using thishttp://gis.stackexchange.com/questions/126742/which-dos-method-use-to-convert-at-sensor-radiance-to-at-surface-values-in-grass And also on your graph (the one on github) Nikos, this DOS method leads to "corrected" reflectance. So it means that I can omit i.atccor, right? I'm thinking about preprocessing of my images like this: i.landsat.toar + DOS3, then r.recode (I don't know the other way to change float to integer), then i.histo.match And after that classification (I want to compare land change cover, it is Syrian Jezirah, so +/-95% is agriculture). Greetings Joanna ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Landsat 5TM pre-processing - histogram matching - problem
* joanna mardas joanna.mar...@wp.pl [2015-05-05 00:19:02 +0200]: Hello! You both are my heros! Thank you Moritz and Nikos! r.recode worked :D I did i.histo.match on two test images and it looks fine. If you go all the way from DN to Top-of-Atmosphere reflectances (via i.landsat.toar), then to Top-of-Canopy (via i.atcorr), you'll have floating point values ranging in [0, 1.0]. If you recode this back to 8-bit, you should consider whether there is an important loss of the radiometric resolution. So, recoding to another range is different than converting to integer numbers and trying to preserve the range. So now the rest of bands, and then band composite and supervised classification (I've found nice tutorial on youtube, so I'm gonna follow it, or I will try semi-automatic classification plugin for qgis). Nikos, you've wrote Each band is one single image. No matter its bitness, it is normal to appear mono-chromatic -- its normal to apply a grey scale. I know that grey scale is normal, but I didn't have, let's say 50 shades of grey ;) but only one shade, one color-no scale of colors. Thanks for the details Joanna. I now understand better. After each processing you can check the range of your image(s) via `r.info -r` and or r.univar for basic descriptive stats. If all looks fine (min value, max value, mean and standard deviation show clearly there is useful information in the queried image(s)), then it's only a color-table issue. You should only need to apply the correct color table via r.colors. Forunately, Moritz was right, thanks a lot! Now it looks normal. Sure. But consider what is your aim and if you are ok giving away some portion of the radiometric details. And you wrote also that the correct way is to not use the Digital Numbers directly. Rather, convert to reflectance, then do whatever you have to. So application of i.landsat.toar is correct, right? Yes. Sorry for all stupid/basic questions but this is my first serious time with grass and landsat image processing. If you do request (from me, at least) to accept apologies, then accept my apologies for my infinite silly questions I have asked in this list :-) Nikos ps- Please try to keep some flow-of-text from top-to-bottom when replying in the list. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] gdal/ogr 2.0 beta 1 available - grass gis ready?
Hi, 2015-05-04 23:16 GMT+02:00 Helmut Kudrnovsky hel...@web.de: http://lists.osgeo.org/pipermail/gdal-dev/2015-May/041694.html is grass gis already ready for the next generation gdal/ogr? I am using GRASS 7 together with GDAL 2.0 for several months, recently I added also support for multigeometry support [1]. Martin [1] http://freegis.fsv.cvut.cz/wiki/images/2/26/Grass70-vfr.png -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.cz/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Error reading null row 8 for MASK
On 5 May 2015 at 13:49, Alba German albager...@gmail.com wrote: http://pastebin.com/rMgRsqDp could you send the output of r.info puntosmonitoreo -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] g.remove usage syntax
Dear All, I find the current syntax of g.remove a bit cumbersome, because it doesn't seem to me in line with what happens with other commands. If I want to remove the vector file foo, I have to type: g.remove vect name=foo -f Without the name= it won't work, which is not in line to the usage of other commands. To me it would be more natural (and indeed i always type wrong the first time) something like: g.remove vect name foo -f being name one of the two options (name, pat) that could be identifier= or something better. In this case, it would be possible to type the former command or the extended form: g.remove type=vect identifier=name name=foo -f or g.remove type=vect identifier=pattern name=f* -f (g.remove vect pat f* -f) what do you think? Thank you -- Best regards, Dr. Margherita DI LEO Scientific / technical project officer European Commission - DG JRC Institute for Environment and Sustainability (IES) Via Fermi, 2749 I-21027 Ispra (VA) - Italy - TP 261 Tel. +39 0332 78 3600 margherita.di-...@jrc.ec.europa.eu Disclaimer: The views expressed are purely those of the writer and may not in any circumstance be regarded as stating an official position of the European Commission. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Testing an add-on from sandbox before moving to grass-addons
Hi, I am trying to not mess-up anything in grass-addons. Hence, I first uploaded the i.fusion.hpf script in sandbox: https://svn.osgeo.org/grass/sandbox/alexandris/i.fusion.hpf/. Is it possible to get the add-on from the sandox, via g.extension, under Windows? I have no easy access to a windows machine with GRASS and co. Anyone willing to test? Thanks, Nikos ps- the plan is, still, to integrate the method in i.pansharpen, but I really have no time to work on this also. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Testing an add-on from sandbox before moving to grass-addons
Hi, 2015-05-05 11:54 GMT+02:00 Nikos Alexandris n...@nikosalexandris.net: I am trying to not mess-up anything in grass-addons. Hence, I first uploaded the i.fusion.hpf script in sandbox: https://svn.osgeo.org/grass/sandbox/alexandris/i.fusion.hpf/. Is it possible to get the add-on from the sandox, via g.extension, under Windows? I have no easy access to a windows machine with GRASS and co. it's not possible, to enable installing this extension via g.extension, you need to move this extension to `grass7/imagery`. Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.cz/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #2668: Browse button v.external
#2668: Browse button v.external -+- Reporter: madi | Owner: grass-dev@… Type: enhancement | Status: new Priority: normal | Milestone: 7.0.1 Component: Default |Version: unspecified Keywords: v.external |CPU: Unspecified Platform: Unspecified | -+- It would be useful to have the browse button in the GUI of v.external, just like the one available for r.external, in the field of Name of input OGR or PostGIS data source (input parameter). -- Ticket URL: http://trac.osgeo.org/grass/ticket/2668 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] g.remove usage syntax
Hi, 2015-05-05 12:28 GMT+02:00 Margherita Di Leo direg...@gmail.com: being name one of the two options (name, pat) that could be identifier= or something better. In this case, it would be possible to type the former command or the extended form: g.remove type=vect identifier=name name=foo -f or g.remove type=vect identifier=pattern name=f* -f (g.remove vect pat f* -f) what do you think? no idea, in any case it's issue for GRASS 8. Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.cz/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
