Re: [GRASS-user] Announcing new command line interface of `grass` program in trunk

[Vaclav Petras]

On Thu, Jun 4, 2015 at 3:25 PM, Rainer M Krug  wrote:
>
> > [1, 2] The code now allows to introduce such interface. The challenge
> > is where to store the information about active Location and Mapset.
> > Currently, .gisrc (or .grassrc or .grassgisrc) file stored in the
> > current working directory seems as the best option to me. Another
> > option is to use environment variables [3, 4] but I don't consider it
> > a nice solution.
>
> I agree - unless it is in a scrip with shebang #!grass71exec or
> similar. Then it would be easy to use environmental variables.

Let me clarify here, GRASS modules read Mapset from a "gisrc" file. The
path to this file is stored in `GISRC` environment variable. The standard
interface now creates this file (its content) based on what was provided in
the command line. In the subcommand interface, only the first command knows
the Mapset and it must pass it to commands called later. The way how to do
this easily is to create a file with a given name in the current directory
(e.g., .grassrc). When grass command is called with subcommand (other than
setmapset), it looks for that file, if it is there, GISRC is set to this
file, if it is not there, it fails.

The environment variables I was mentioning are different thing. They
wouldn't be (cannot) be used inside the GRASS session (so no usage for them
in shebang mode). If the grass program would respect them, you can get poor
man's subcommand-like interface without implementing it:

export GRASS_FULL_MAPSET=/path/to/mapset
grass [--mapset-from-environment] --exec r.univar map=elevation

I don't think this is how the API should look like and the subcommand
interface seems more natural (or just modern?) and more extensible (but do
we need it?).

> What about a user specified name? This would make switching mapsets in a
> script much more symbolic, as one does not has to specify the path of
> the mapset and just an easy to remember name? This would make it possible
to
> setup a whole bunch of mapsets associated with names in a text file and
> then just load the .grassEXEC file?

Mapset is the data. Should the data be specified in a "config file" or some
general file and then passed to the program? I don't think so. I think one
should pass the Mapset as a parameter.

To your suggestion of symbolic names. It might be easier to switch but it
would complicate the API and implementation a lot. How the file would be
managed? I don't think it is worth the trouble. Also I don't want to
implement interfaces which don't have precedence. An existing example of
something like that could change my opinion about a nickname file but I'm
unsure how this would fit with the rest.

> >
> > [1] https://trac.osgeo.org/grass/ticket/2579#Additionalideas
> > [2] https://trac.osgeo.org/grass/ticket/2579#comment:10
> > [3] https://trac.osgeo.org/grass/ticket/2679
> > [4] https://trac.osgeo.org/grass/ticket/2681
> >
> >> ,
> >> | grass71 --setmapset .../grassdata/test1/PERMANENT/
> >> | grass71 --exec r.external input=basins.tiff output=basins
> >> | grass71 --exec r.external input=elevation.tiff output=elevation
> >> | grass71 --unsetmapset
> >> `
> >
> > Rather than this, I prefer subcommand interface as known from git,
docker
> > or apt-get:
> >
> > ,
> > | grass71 setmapset .../grassdata/test1/PERMANENT/
> > | grass71 run r.external input=basins.tiff output=basins
> > | grass71 run r.external input=elevation.tiff output=elevation
> > | grass71 unsetmapset
> > `
>
> Looks much nicer - I agree.
>
> >
> > Which subcommands and how to name them is of course a separate question.
> > I'm quite comfortable with `run` but not so much with `setmapset` and
> > `unsetmapset`.
>
> They were just descriptive names. And if you want to stick with the
> subcommand options, something like
>
> ,
> | grass71 set mapset .../grassdata/test1/PERMANENT/
> | grass71 run r.external input=basins.tiff output=basins
> | grass71 run r.external input=elevation.tiff output=elevation
> | grass71 unset mapset
> `

The decision if to nest subcommands or not is one of the main disadvantages
of this kind of interface. I'm quite unsure about the syntax you proposed.
Perhaps something simpler like:

,
| grass71 start .../grassdata/test1/PERMANENT/
| grass71 run r.external input=basins.tiff output=basins
| grass71 run r.external input=elevation.tiff output=elevation
| grass71 stop
`

would be nicer and simpler.

> Then one could also use
>
> ,
> | grass71 set mapset ./input
> `
>
> where input would be a file which contains something like
>
> ,
> | mapset = .../grassdata/test1/PERMANENT/
> `
>
> This would make it possible to easily run the same script for different
> mapsets.

I don't see any advantage in that. You should pass the the Mapset to your
script as a parameter instead of hardcoding path to file in the script and
then changing the file. If you script has a lot of parameters then some
kind of config file is appropriate but this should be

Re: [GRASS-user] Imagen de fondo en v.digit

[Veronica Andreo]

Hola Nestor,

Supongo que estas usando GRASS 6.4 porque en GRASS 7.0 el comando se llama
g.gui.vdigit y se hace todo desde la interfaz gráfica. De todos modos, es
muy sencillo. Fijate en la pagina del módulo que al final están los
ejemplos: http://grass.osgeo.org/grass64/manuals/v.digit.html

Igualmente, si el caso es que usas GRASS 6.4, la cosa sería así

# abrís un monitor
d.mon x0
# cargas el raster que necesitas
d.rast curvasdenivel
# y haces la digitalización
v.digit ...

También podes hacer todo desde la GUI (interfaz gráfica), cargando un
raster como se hace normalmente y después procedes a digitalizar sobre él
(acá el manual para grass70:
http://grass.osgeo.org/grass70/manuals/g.gui.vdigit.html).

Espero que te ayude.
Saludos

Vero



El 4 de junio de 2015, 10:38, Néstor Ramires 
escribió:

>  Hola
> Estoy tratando de digitalizar un mapa de curvas de nivel. Tengo una imagen
> tif de 1bit georreferenciada (latitud/longitud) la cual quiero traer de
> fondo en v.digit para digitalizar en una capa vectorial para luego generar
> un modelo digital de terreno.
> La pregunta ¿cómo hago para traer de fondo la imagen en v.digit?
> Saludos
>
>
>
> ___
> 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] Announcing new command line interface of `grass` program in trunk

[Rainer M Krug]

Vaclav Petras  writes:

> Thank you all for the comments. Here are some more from me.
>
> On Thu, Jun 4, 2015 at 3:53 AM, Rainer M Krug  wrote:
>>
>> Vaclav Petras  writes:
>>
>> > Hi all,
>> >
>> > I'm happy to announce new command line interface of the `grass` program
> [1,
>> > 2] available in trunk.
>>
>> This sounds very exciting - and will make life much easier. Thanks a
>> lot.
>>
>> It might be to early to ask, but are there any penalties is speed when
>> using this construct compared with the "traditional" way?
>
> It is not too early. The time you have to currently pay is approximately
> 0.05 s. However, you pay for having the full session with all checks,
> cleanups and Mapset locking. Although the execution time is much longer
> than when just setting the variables manually (when you don't execute any
> cleanups, for example), the time is relatively short when running some
> computation.

0.05s is not to bad ion most cases, as the computation of the command
time will usually be much longer.

>
> Unfortunately, the price has to be paid every time you call a module. Then
> the price can grow especially if you call something many times (e.g. in a
> loop). This can be dealt with by not executing individual modules directly
> and creating a script (or module) for GRASS instead. Although this is less
> convenient then direct execution of modules, it brings advantages of
> writing Python script with GRASS Python API, script which can become true
> GRASS module and finally, and finally it separates GRASS-related
> functionality from your script (separation is good for maintenance and
> reuse). In any case, the goal is to keep the time as low as possible to
> support as many use cases as possible.

That leads to the shebang point below - I will come back to it later.

>
> And here is my simple benchmark:
>
> time grass71 ~/grassdata/nc_spm_08_grass7/PERMANENT/ --exec echo "from
> GRASS"
>
> real0m0.069s
> user0m0.048s
> sys 0m0.008s
>

Thanks.

>>> >
>> > Certainly you already know that you can start GRASS GIS session in the
>> > specified Location and Mapset in the following way:
>> >
>> > grass71 .../grassdata/location/mapset/
>> >
>> > The new interface adds `--exec` flag for specifying a command which
> will be
>> > executed inside that GRASS session:
>> >
>> > grass71 .../grassdata/location/mapset/ --exec r.univar map=elevation
>>
>> Am I right in assuming, that the --exec effectively splits the command
>> into the "setup part" (mapset) before and the "command part" after and
>> whatever follows will be executed?
>
> Exactly, it splits the command line: standard `grass` program parameters
> are before --exec, command to execute is after.

Perfect.

>
>> What happens when one specifies a shell command - I assume it will it
> also be
>> executed?
>
> Right, anything is executed, e.g.
> env
> RScript...
> python -c "import grass.script as gscript; gscript.run_command('g.region',
> flags='g')"
> r.external --ui
> g.gui -f
>
> Just note that the shell syntax is interpreted in the current shell (e.g.
> $VARIABLE), `grass` program gets just plain parameters to execute.

Good to know and might be useful (I just don't know for what, at the
moment - but I am sure there is something...).

>
>> I guess that if this is working, the next step would be to introduce the
>> single command version so that one does not have to specify the mapset
>> each time. E.g:
>
> Yes!

Great.

> [1, 2] The code now allows to introduce such interface. The challenge
> is where to store the information about active Location and Mapset.
> Currently, .gisrc (or .grassrc or .grassgisrc) file stored in the
> current working directory seems as the best option to me. Another
> option is to use environment variables [3, 4] but I don't consider it
> a nice solution.

I agree - unless it is in a scrip with shebang #!grass71exec or
similar. Then it would be easy to use environmental variables.

What about a user specified name? This would make switching mapsets in a
script much more symbolic, as one does not has to specify the path of
the mapset and just an easy to remember name? This would make it possible to
setup a whole bunch of mapsets associated with names in a text file and
then just load the .grassEXEC file?

>
> [1] https://trac.osgeo.org/grass/ticket/2579#Additionalideas
> [2] https://trac.osgeo.org/grass/ticket/2579#comment:10
> [3] https://trac.osgeo.org/grass/ticket/2679
> [4] https://trac.osgeo.org/grass/ticket/2681
>
>> ,
>> | grass71 --setmapset .../grassdata/test1/PERMANENT/
>> | grass71 --exec r.external input=basins.tiff output=basins
>> | grass71 --exec r.external input=elevation.tiff output=elevation
>> | grass71 --unsetmapset
>> `
>
> Rather than this, I prefer subcommand interface as known from git, docker
> or apt-get:
>
> ,
> | grass71 setmapset .../grassdata/test1/PERMANENT/
> | grass71 run r.external input=basins.tiff output=basins
> | grass71 run r.external input=elevation.tiff output=eleva

Re: [GRASS-user] i.atcorr for GeoEye-1 and Worldview-3

[Nikos Alexandris]

* Markus Neteler  [2015-06-04 20:52:54 +0200]:

> On Thu, Jun 4, 2015 at 2:19 PM, Moritz Lennert
>  wrote:
> ...
> >>> Do I understand correctly that you would need the numbers behind the
> >>> curves in this document:
> >>>
> >>>
> >>> https://www.digitalglobe.com/sites/default/files/DigitalGlobe_Spectral_Response_1.pdf
> 
> Yes, exactly - we would need the original values which were used to produce:
> 
>  Figure 6. Spectral Response of the WorldView-3 panchromatic and
>  multispectral imagery, visible and near infrared bands.
> 
> 
> > I don't have the time to do this now, but using something like [1], it
> > should be easy to quickly get an approximate dataset from the graphs in that
> > document.
> 
> Maybe with a little more crowd-hunting or by someone just contacting
> DigitalGlobe we would get the table of values right away?

I tried to contact DigitalGlobe in the past about WV2.  I did not
succeed back then.  Maybe now if someone has recently bought some WV3
imagery.

Nikos
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] i.atcorr for GeoEye-1 and Worldview-3

[Markus Neteler]

On Thu, Jun 4, 2015 at 2:19 PM, Moritz Lennert
 wrote:
...
>>> Do I understand correctly that you would need the numbers behind the
>>> curves in this document:
>>>
>>>
>>> https://www.digitalglobe.com/sites/default/files/DigitalGlobe_Spectral_Response_1.pdf

Yes, exactly - we would need the original values which were used to produce:

 Figure 6. Spectral Response of the WorldView-3 panchromatic and
 multispectral imagery, visible and near infrared bands.


> I don't have the time to do this now, but using something like [1], it
> should be easy to quickly get an approximate dataset from the graphs in that
> document.

Maybe with a little more crowd-hunting or by someone just contacting
DigitalGlobe we would get the table of values right away?

Markus
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Appending map to another with GRASS 7

[simogeo]

Hi list,

I experience some difficulties related to v.patch and category / attributes
when merging vector maps together.

I've read the following thread :
osgeo-org.1560.x6.nabble.com/Appending-a-map-to-another-td5176882.html and
proceeded the way Markus dis explained it. FI 'm working with grass70.

*Point I : *
As Tommaso said (in mentioned thread), I noticed that the /v.category
option=sum to change the categories  / doesn't seem to be needed because
grass reclass it automatically. Is this correct ?


*Point II*

More problematic, opening attributes table, I can see the following cats :

10003 30006 60009 70013 90017 120021

And /v.category input=poly_iso option=print layer=1 id=1-50/ will return
same values

but displaying it on the map shows both boundaries and areas - And
retrieving attributes on click will only work on areas. On the image below,
I have 3 areas (sometimes it is 2).

 

And exporting with /v.out.ogr/ says that features without category were
skipped - here 3 (on a total of 6).


I use v.patch in a loop and do as follow :



Thanks for your help. I'm struggling with that !




--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Appending-map-to-another-with-GRASS-7-tp5209201.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] Announcing new command line interface of `grass` program in trunk

[Vaclav Petras]

Thank you all for the comments. Here are some more from me.

On Thu, Jun 4, 2015 at 3:53 AM, Rainer M Krug  wrote:
>
> Vaclav Petras  writes:
>
> > Hi all,
> >
> > I'm happy to announce new command line interface of the `grass` program
[1,
> > 2] available in trunk.
>
> This sounds very exciting - and will make life much easier. Thanks a
> lot.
>
> It might be to early to ask, but are there any penalties is speed when
> using this construct compared with the "traditional" way?

It is not too early. The time you have to currently pay is approximately
0.05 s. However, you pay for having the full session with all checks,
cleanups and Mapset locking. Although the execution time is much longer
than when just setting the variables manually (when you don't execute any
cleanups, for example), the time is relatively short when running some
computation.

Unfortunately, the price has to be paid every time you call a module. Then
the price can grow especially if you call something many times (e.g. in a
loop). This can be dealt with by not executing individual modules directly
and creating a script (or module) for GRASS instead. Although this is less
convenient then direct execution of modules, it brings advantages of
writing Python script with GRASS Python API, script which can become true
GRASS module and finally, and finally it separates GRASS-related
functionality from your script (separation is good for maintenance and
reuse). In any case, the goal is to keep the time as low as possible to
support as many use cases as possible.

And here is my simple benchmark:

time grass71 ~/grassdata/nc_spm_08_grass7/PERMANENT/ --exec echo "from
GRASS"

real0m0.069s
user0m0.048s
sys 0m0.008s

>> >
> > Certainly you already know that you can start GRASS GIS session in the
> > specified Location and Mapset in the following way:
> >
> > grass71 .../grassdata/location/mapset/
> >
> > The new interface adds `--exec` flag for specifying a command which
will be
> > executed inside that GRASS session:
> >
> > grass71 .../grassdata/location/mapset/ --exec r.univar map=elevation
>
> Am I right in assuming, that the --exec effectively splits the command
> into the "setup part" (mapset) before and the "command part" after and
> whatever follows will be executed?

Exactly, it splits the command line: standard `grass` program parameters
are before --exec, command to execute is after.

> What happens when one specifies a shell command - I assume it will it
also be
> executed?

Right, anything is executed, e.g.
env
RScript...
python -c "import grass.script as gscript; gscript.run_command('g.region',
flags='g')"
r.external --ui
g.gui -f

Just note that the shell syntax is interpreted in the current shell (e.g.
$VARIABLE), `grass` program gets just plain parameters to execute.

> I guess that if this is working, the next step would be to introduce the
> single command version so that one does not have to specify the mapset
> each time. E.g:

Yes! [1, 2] The code now allows to introduce such interface. The challenge
is where to store the information about active Location and Mapset.
Currently, .gisrc (or .grassrc or .grassgisrc) file stored in the current
working directory seems as the best option to me. Another option is to use
environment variables [3, 4] but I don't consider it a nice solution.

[1] https://trac.osgeo.org/grass/ticket/2579#Additionalideas
[2] https://trac.osgeo.org/grass/ticket/2579#comment:10
[3] https://trac.osgeo.org/grass/ticket/2679
[4] https://trac.osgeo.org/grass/ticket/2681

> ,
> | grass71 --setmapset .../grassdata/test1/PERMANENT/
> | grass71 --exec r.external input=basins.tiff output=basins
> | grass71 --exec r.external input=elevation.tiff output=elevation
> | grass71 --unsetmapset
> `

Rather than this, I prefer subcommand interface as known from git, docker
or apt-get:

,
| grass71 setmapset .../grassdata/test1/PERMANENT/
| grass71 run r.external input=basins.tiff output=basins
| grass71 run r.external input=elevation.tiff output=elevation
| grass71 unsetmapset
`

Which subcommands and how to name them is of course a separate question.
I'm quite comfortable with `run` but not so much with `setmapset` and
`unsetmapset`.

> and finally introduce a mapper around this (similar to Rscript ore
> littler) so that one could say
>
> ,
> | grass71exec setmapset .../grassdata/test1/PERMANENT/
> | grass71exec r.external input=basins.tiff output=basins
> | grass71exec r.external input=elevation.tiff output=elevation
> | grass71exec unsetmapset
> `

I don't see much advantage in this comparing to grass71 --exec for the
usages other than shebang which requires special approach anyway (see
below).

> and could use grass71exec as a shebang - that would be the ultimate
> convenience.

This would make sense. GRASS looks like an interpreter by requiring things
to run inside, so it should behave as an interpreter.

Shebang may require to have a special wrapper to set some parameters (since
shebang 

[GRASS-user] Imagen de fondo en v.digit

[Néstor Ramires]

Hola
Estoy tratando de digitalizar un mapa de curvas de nivel. Tengo una imagen tif 
de 1bit georreferenciada (latitud/longitud) la cual quiero traer de fondo en 
v.digit para digitalizar en una capa vectorial para luego generar un modelo 
digital de terreno.
La pregunta ¿cómo hago para traer de fondo la imagen en v.digit?
Saludos

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] i.atcorr for GeoEye-1 and Worldview-3

[Margherita Di Leo]

Hi,

On Thu, Jun 4, 2015 at 2:19 PM, Moritz Lennert  wrote:

> On 04/06/15 13:47, Nikos Alexandris wrote:
>
>> * Moritz Lennert  [2015-06-04 11:38:04
>> +0200]:
>>
>>  On 03/06/15 15:06, Markus Neteler wrote:
>>>
 On Wed, Jun 3, 2015 at 6:56 AM, Kamhul Camhol 
 wrote:

> Hello. I'm quite new with GRASS but I need to atmospherically process
> high-resolution imagery with i.atcorr. I have three images Quickbird,
> GeoEye-1 and Worldview-3 imagery of a single scene across three time
> periods. For Quickbird, I have all the data needed but basing from the
> following manual GRASS GIS manual: i.atcorr
> there appears to be no values for two required inputs for GeoEye-1 and
> Worldview-3.
>

 Yes, at time only Quickbird but not GeoEye-1 and Worldview-3 are
 supported.

  These are geometrical conditions and band. May I know if GRASS
> has updated the i.atcorr manual to include these sensors as well? Can
> I use
> the values of Worldview-2 for Worldview-3? Or is there any other way
> to do
> the atmospheric correction for these two sensors?
>

 We would be happy to add support for these sensors. We need the
 spectral filter curves for that, in order to integrate them in
 i.atcorr.

>>>
>>> Do I understand correctly that you would need the numbers behind the
>>> curves in this document:
>>>
>>>
>>> https://www.digitalglobe.com/sites/default/files/DigitalGlobe_Spectral_Response_1.pdf
>>>
>>> ?
>>>
>>
>> Yes Moritz, that is very relevant!  They updated the document I think (it
>> wasn't
>> there on Summer 2013 plus a few months later -- the properties of this
>> file indicate October 2014).
>>
>
> I don't have the time to do this now, but using something like [1], it
> should be easy to quickly get an approximate dataset from the graphs in
> that document.
>
> Moritz
>
> [1] http://arohatgi.info/WebPlotDigitizer/


For GeoEye-1 the curves are here:
https://apollomapping.com/wp-content/user_uploads/2013/08/GeoEye-1_Relative_Spectral_Response.xls
see https://apollomapping.com/about-us/whitepapers



-- 
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-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] i.atcorr for GeoEye-1 and Worldview-3

[Moritz Lennert]

On 04/06/15 13:47, Nikos Alexandris wrote:

* Moritz Lennert  [2015-06-04 11:38:04 +0200]:


On 03/06/15 15:06, Markus Neteler wrote:

On Wed, Jun 3, 2015 at 6:56 AM, Kamhul Camhol  wrote:

Hello. I'm quite new with GRASS but I need to atmospherically process
high-resolution imagery with i.atcorr. I have three images Quickbird,
GeoEye-1 and Worldview-3 imagery of a single scene across three time
periods. For Quickbird, I have all the data needed but basing from the
following manual GRASS GIS manual: i.atcorr
there appears to be no values for two required inputs for GeoEye-1 and
Worldview-3.


Yes, at time only Quickbird but not GeoEye-1 and Worldview-3 are supported.


These are geometrical conditions and band. May I know if GRASS
has updated the i.atcorr manual to include these sensors as well? Can I use
the values of Worldview-2 for Worldview-3? Or is there any other way to do
the atmospheric correction for these two sensors?


We would be happy to add support for these sensors. We need the
spectral filter curves for that, in order to integrate them in
i.atcorr.


Do I understand correctly that you would need the numbers behind the
curves in this document:

https://www.digitalglobe.com/sites/default/files/DigitalGlobe_Spectral_Response_1.pdf

?


Yes Moritz, that is very relevant!  They updated the document I think (it wasn't
there on Summer 2013 plus a few months later -- the properties of this
file indicate October 2014).


I don't have the time to do this now, but using something like [1], it 
should be easy to quickly get an approximate dataset from the graphs in 
that document.


Moritz

[1] http://arohatgi.info/WebPlotDigitizer/
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] i.atcorr for GeoEye-1 and Worldview-3

[Nikos Alexandris]

* Moritz Lennert  [2015-06-04 11:38:04 +0200]:

> On 03/06/15 15:06, Markus Neteler wrote:
> > On Wed, Jun 3, 2015 at 6:56 AM, Kamhul Camhol  wrote:
> >> Hello. I'm quite new with GRASS but I need to atmospherically process
> >> high-resolution imagery with i.atcorr. I have three images Quickbird,
> >> GeoEye-1 and Worldview-3 imagery of a single scene across three time
> >> periods. For Quickbird, I have all the data needed but basing from the
> >> following manual GRASS GIS manual: i.atcorr
> >> there appears to be no values for two required inputs for GeoEye-1 and
> >> Worldview-3.
> >
> > Yes, at time only Quickbird but not GeoEye-1 and Worldview-3 are supported.
> >
> >> These are geometrical conditions and band. May I know if GRASS
> >> has updated the i.atcorr manual to include these sensors as well? Can I use
> >> the values of Worldview-2 for Worldview-3? Or is there any other way to do
> >> the atmospheric correction for these two sensors?
> >
> > We would be happy to add support for these sensors. We need the
> > spectral filter curves for that, in order to integrate them in
> > i.atcorr.
> 
> Do I understand correctly that you would need the numbers behind the 
> curves in this document:
> 
> https://www.digitalglobe.com/sites/default/files/DigitalGlobe_Spectral_Response_1.pdf
> 
> ?

Yes Moritz, that is very relevant!  They updated the document I think (it wasn't
there on Summer 2013 plus a few months later -- the properties of this
file indicate October 2014).

Nikos
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] i.atcorr for GeoEye-1 and Worldview-3

[Kamhul Camhol]

Dear Moritz,

Yes, for GeoEye-1 and Worldview-3, the: A) geometric conditions and F) band 
values, two of the required inputs/parameters for the GRASS i.atcorr 6S  
algorithm. 

Thank you. Sincerely,
Armand 

 


 On Thursday, June 4, 2015 5:38 PM, Moritz Lennert 
 wrote:
   

 On 03/06/15 15:06, Markus Neteler wrote:
> On Wed, Jun 3, 2015 at 6:56 AM, Kamhul Camhol  wrote:
>> Hello. I'm quite new with GRASS but I need to atmospherically process
>> high-resolution imagery with i.atcorr. I have three images Quickbird,
>> GeoEye-1 and Worldview-3 imagery of a single scene across three time
>> periods. For Quickbird, I have all the data needed but basing from the
>> following manual GRASS GIS manual: i.atcorr
>> there appears to be no values for two required inputs for GeoEye-1 and
>> Worldview-3.
>
> Yes, at time only Quickbird but not GeoEye-1 and Worldview-3 are supported.
>
>> These are geometrical conditions and band. May I know if GRASS
>> has updated the i.atcorr manual to include these sensors as well? Can I use
>> the values of Worldview-2 for Worldview-3? Or is there any other way to do
>> the atmospheric correction for these two sensors?
>
> We would be happy to add support for these sensors. We need the
> spectral filter curves for that, in order to integrate them in
> i.atcorr.

Do I understand correctly that you would need the numbers behind the 
curves in this document:

https://www.digitalglobe.com/sites/default/files/DigitalGlobe_Spectral_Response_1.pdf

?

Moritz


  ___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] i.atcorr for GeoEye-1 and Worldview-3

[Moritz Lennert]

On 03/06/15 15:06, Markus Neteler wrote:

On Wed, Jun 3, 2015 at 6:56 AM, Kamhul Camhol  wrote:

Hello. I'm quite new with GRASS but I need to atmospherically process
high-resolution imagery with i.atcorr. I have three images Quickbird,
GeoEye-1 and Worldview-3 imagery of a single scene across three time
periods. For Quickbird, I have all the data needed but basing from the
following manual GRASS GIS manual: i.atcorr
there appears to be no values for two required inputs for GeoEye-1 and
Worldview-3.


Yes, at time only Quickbird but not GeoEye-1 and Worldview-3 are supported.


These are geometrical conditions and band. May I know if GRASS
has updated the i.atcorr manual to include these sensors as well? Can I use
the values of Worldview-2 for Worldview-3? Or is there any other way to do
the atmospheric correction for these two sensors?


We would be happy to add support for these sensors. We need the
spectral filter curves for that, in order to integrate them in
i.atcorr.


Do I understand correctly that you would need the numbers behind the 
curves in this document:


https://www.digitalglobe.com/sites/default/files/DigitalGlobe_Spectral_Response_1.pdf

?

Moritz
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] GRASS 7.1 for homebrew (on OS X)?

[Rainer M Krug]

Hi

is there a plan of creating a recipe for GRASS 7.1 for homebrew? I would
be delighted to do si=ome testing of the new --exec interfacxe if I
could install 7.1 via homebrew.

Cheers,

Rainer


-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax :   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

PGP: 0x0F52F982


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Announcing new command line interface of `grass` program in trunk

[Rainer M Krug]

Vaclav Petras  writes:

> Hi all,
>
> I'm happy to announce new command line interface of the `grass` program [1,
> 2] available in trunk.

This sounds very exciting - and will make life much easier. Thanks a
lot.

It might be to early to ask, but are there any penalties is speed when
using this construct compared with the "traditional" way?

>
> Certainly you already know that you can start GRASS GIS session in the
> specified Location and Mapset in the following way:
>
> grass71 .../grassdata/location/mapset/
>
> The new interface adds `--exec` flag for specifying a command which will be
> executed inside that GRASS session:
>
> grass71 .../grassdata/location/mapset/ --exec r.univar map=elevation

Am I right in assuming, that the --exec effectively splits the command
into the "setup part" (mapset) before and the "command part" after and
whatever follows will be executed?

What happens when one specifies a shell command - I assume it will it also be
executed?

I guess that if this is working, the next step would be to introduce the
single command version so that one does not have to specify the mapset
each time. E.g:

,
| grass71 --setmapset .../grassdata/test1/PERMANENT/
| grass71 --exec r.external input=basins.tiff output=basins
| grass71 --exec r.external input=elevation.tiff output=elevation
| grass71 --unsetmapset
`


,
| grass71 --setmapset .../grassdata/test1/PERMANENT/
| grass71 --exec r.external input=basins.tiff output=basins
| grass71 --exec r.external input=elevation.tiff output=elevation
| grass71 --unsetmapset
`

and finally introduce a mapper around this (similar to Rscript ore
littler) so that one could say

,
| grass71exec setmapset .../grassdata/test1/PERMANENT/
| grass71exec r.external input=basins.tiff output=basins
| grass71exec r.external input=elevation.tiff output=elevation
| grass71exec unsetmapset
`

and could use grass71exec as a shebang - that would be the ultimate
convenience.

Thanks a lot,

Rainer

>
> This starts GRASS session, executes whatever command is specified after
> `--exec` flag and then ends showing the (text) output of the module as if
> the module would be executed manually in the GRASS session. And example
> showing this in combination with r.external to get the data into the Mapset
> is in the documentation [3].
>
> This interface is meant to remove the need for lengthy manual setup of
> environmental variables followed by execution of GRASS modules in the
> mock-up GRASS session [4]. The idea is to use correct GRASS session
> maintained by `grass` program which means that any GRASS-related code must
> be passed to the `grass` program as opposed to direct execution in the
> former case.
>
> The interface can run any module or custom script with or without
> parameters. GUI tools including g.gui [5] can be called as well which opens
> new possibilities for application developers.
>
> The interface is the first implementation and currently is fully
> operational only on Linux and similar systems but it benefits from a lot of
> stable code which was already in place. Try it out and feel free to comment
> here, on grass-dev or in the related ticket [6]. There is definitively many
> potential improvements and it would be great to know what the community
> demands.
>
> Vaclav
>
> [1] https://trac.osgeo.org/grass/changeset/65252
> [2] https://trac.osgeo.org/grass/changeset/65294
> [3]
> http://grass.osgeo.org/grass71/manuals/grass7.html#exec-interface-example
> [4]
> http://grasswiki.osgeo.org/wiki/Working_with_GRASS_without_starting_it_explicitly
> [5] https://trac.osgeo.org/grass/changeset/65306
> [6] https://trac.osgeo.org/grass/ticket/2579
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user

-- 
Rainer M. Krug
email: Rainerkrugsde
PGP: 0x0F52F982


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user