Re: [GRASS-dev] r.in.gdal: restrict extent of imported data set to current region?

[Helmut Kudrnovsky]

Markus Neteler wrote
> Hi,
> 
> for the upcoming GRASS GIS course at the FOSS4G [1] I have processed a
> set of Sentinel-2 scenes + a Landsat time series.
> Altogether it accumulates to 90GB of compressed GeoTIFFs.
> Since that's not very practical for a course, I would like to loop
> over all files and cut the extent by the current region.
> 
> Any ideas?
> 
> Maybe it would be sufficient to pass the xmin, xmax, ymin, ymax on to
> the right GDAL function?
> 
> thanks
> Markus
> 
> PS: sure, otherwise via GDAL ...
> 
> [1] http://2016.foss4g.org/ws27.html

what I've used recently quite a lot on the GDAL side of life:

feed gdal_translate with x,y of upper left and x,y of lower right and to get
automagically the raster with the extent of my interest with the same pixel
size of the original input raster and also the same pixel alignment of the
original input raster; without resampling, but with some kind of an off
adjustment of 1-2 pixels more or less regarding the input extent of
interest. 

it would be very nice to have such an automagic also in r.in.gdal. 




-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/r-in-gdal-restrict-extent-of-imported-data-set-to-current-region-tp5281223p5281259.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.in.gdal: restrict extent of imported data set to current region?

[Newcomb, Doug]

On Thu, Aug 18, 2016 at 1:07 PM, Veronica Andreo 
wrote:

> Hello Markus,
>
> Ohh, I would so very much like that -r flag in r.in.gdal (
> https://trac.osgeo.org/grass/ticket/2055)...
>
> For the time being, what about:
>
> r.external
> r.mapcalc
> g.remove
>
> ?
>
> or passing the xmin, xmax, ymin, ymax to gdal_translate with -projwin and
> then r.in.gdal?
>
>
I would  get the coordinates of the extent of the current region and
pre-process with the gdal_translate  command .  A simple python script that
gets a list of all image files and extracts to that projwin with
gdal_translate for each one in turn would be fairly quick.





> Dunno how efficient would that be for such a huge dataset, though... I'd
> still prefer the -r in r.in.gdal ;)
>
> cheers,
> Vero
>
> 2016-08-18 13:50 GMT-03:00 Markus Neteler :
>
>> Hi,
>>
>> for the upcoming GRASS GIS course at the FOSS4G [1] I have processed a
>> set of Sentinel-2 scenes + a Landsat time series.
>> Altogether it accumulates to 90GB of compressed GeoTIFFs.
>> Since that's not very practical for a course, I would like to loop
>> over all files and cut the extent by the current region.
>>
>> Any ideas?
>>
>> Maybe it would be sufficient to pass the xmin, xmax, ymin, ymax on to
>> the right GDAL function?
>>
>> thanks
>> Markus
>>
>> PS: sure, otherwise via GDAL ...
>>
>> [1] http://2016.foss4g.org/ws27.html
>>
>> --
>> Markus Neteler
>> http://www.mundialis.de - free data with free software
>> http://grass.osgeo.org
>> http://courses.neteler.org/blog
>> ___
>> 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
>



-- 
Doug Newcomb
USFWS
Raleigh, NC
919-856-4520 ext. 14 doug_newc...@fws.gov
-
The opinions I express are my own and are not representative of the
official policy of the U.S.Fish and Wildlife Service or Dept. of the
Interior.   Life is too short for undocumented, proprietary data formats.
As a federal employee, my email may be subject to FOIA request.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.in.gdal: restrict extent of imported data set to current region?

[Veronica Andreo]

Hello Markus,

Ohh, I would so very much like that -r flag in r.in.gdal (
https://trac.osgeo.org/grass/ticket/2055)...

For the time being, what about:

r.external
r.mapcalc
g.remove

?

or passing the xmin, xmax, ymin, ymax to gdal_translate with -projwin and
then r.in.gdal?

Dunno how efficient would that be for such a huge dataset, though... I'd
still prefer the -r in r.in.gdal ;)

cheers,
Vero

2016-08-18 13:50 GMT-03:00 Markus Neteler :

> Hi,
>
> for the upcoming GRASS GIS course at the FOSS4G [1] I have processed a
> set of Sentinel-2 scenes + a Landsat time series.
> Altogether it accumulates to 90GB of compressed GeoTIFFs.
> Since that's not very practical for a course, I would like to loop
> over all files and cut the extent by the current region.
>
> Any ideas?
>
> Maybe it would be sufficient to pass the xmin, xmax, ymin, ymax on to
> the right GDAL function?
>
> thanks
> Markus
>
> PS: sure, otherwise via GDAL ...
>
> [1] http://2016.foss4g.org/ws27.html
>
> --
> Markus Neteler
> http://www.mundialis.de - free data with free software
> http://grass.osgeo.org
> http://courses.neteler.org/blog
> ___
> 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

[GRASS-dev] r.in.gdal: restrict extent of imported data set to current region?

[Markus Neteler]

Hi,

for the upcoming GRASS GIS course at the FOSS4G [1] I have processed a
set of Sentinel-2 scenes + a Landsat time series.
Altogether it accumulates to 90GB of compressed GeoTIFFs.
Since that's not very practical for a course, I would like to loop
over all files and cut the extent by the current region.

Any ideas?

Maybe it would be sufficient to pass the xmin, xmax, ymin, ymax on to
the right GDAL function?

thanks
Markus

PS: sure, otherwise via GDAL ...

[1] http://2016.foss4g.org/ws27.html

-- 
Markus Neteler
http://www.mundialis.de - free data with free software
http://grass.osgeo.org
http://courses.neteler.org/blog
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] G6 manual pages: text box added to make users aware of G7

[Markus Neteler]

On Thu, Aug 18, 2016 at 2:53 PM, Vaclav Petras  wrote:
> On Thu, Aug 18, 2016 at 5:54 AM, Markus Neteler  wrote:
>>
>> > I am not a developer, just something I wondered; why not having one
>> > permanent address for the manual, which always reflects the latest
>> > stable
>> > release, and if needed, from there add links to older versions?
>> > Obviously
>> > not a solution for now, but this would lead, in the future, to more
>> > stable
>> > and permanent rankings for the most up-to-date version.
>>
>> +1
>>
>> Perhaps simply this:
>>
>> https://grass.osgeo.org/manuals/
>> https://grass.osgeo.org/manuals/addons
>>
>> I could easily add that in the CMS and make it point to the current
>> stable version.
>
>
> If we can maintain the URL in the long term that would be great.

+1

> BTW, surprised to see "keywords index" as part of the "manuals" page.

It was an attempt to tell the CMSMS to index the manual pages. Seems
not to work.

> Unfortunately the links are broken:
>
> https://grass.osgeo.org/v.hull.html

Internally it is this "user tag" in CMSMS:

print file_get_contents("http://grass.osgeo.org/grass72/manuals/keywords.html;);

which seems to eat the path. Ideas?


> Anyway, the above solution is better if we can have link like:
>
> https://grass.osgeo.org/manuals/v.hull.html
> https://grass.osgeo.org/manuals/v.hull

Yes.

> There is potential conflict of:
>
> https://grass.osgeo.org/grass70/manuals/grass7.html
> https://grass.osgeo.org/grass70/manuals/grass7
> https://grass.osgeo.org/grass70
> https://grass.osgeo.org/manuals/grass7.html
> https://grass.osgeo.org/manuals/grass7
>
> but if the command will be `grass7` (or even `grass`) and the version always
> two numbers and the order is not changed to "manuals/grass70", no conflict
> will happen.

Two numbers would always solve it.

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

Re: [GRASS-dev] [GRASS-SVN] r69152 - grass/trunk/scripts/g.search.modules

[Markus Neteler]

On Thu, Aug 18, 2016 at 4:27 PM,   wrote:
> Author: wenzeslaus
> Date: 2016-08-18 07:27:36 -0700 (Thu, 18 Aug 2016)
> New Revision: 69152
>
> Modified:
>grass/trunk/scripts/g.search.modules/g.search.modules.py
> Log:
> g.search.modules: flag to negate/invert selection
>
> Useful for reviewing info or manual pages.
> Alternativeky it could be -i (for invert) but -n (for NOT) used.

In v.extract we use -r Reverse selection
https://grass.osgeo.org/grass72/manuals/v.extract.html

In r.colors etc. we use  -n Invert colors

Maybe it is more like -r Reverse selection?

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

Re: [GRASS-dev] [GRASS GIS] #2252: wxGUI vector digitizer passing unescaped text to database

[GRASS GIS]

#2252: wxGUI vector digitizer passing unescaped text to database
-+-
  Reporter:  marisn  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  critical|  Milestone:  7.0.5
 Component:  wxGUI   |Version:  svn-trunk
Resolution:  |   Keywords:  security, code injection, SQL
   CPU:  |  injection, data loss, v.db.update
  Unspecified|   Platform:  Unspecified
-+-

Comment (by annakrat):

 Replying to [comment:14 annakrat]:
 > In [changeset:"69153" 69153]:
 > {{{
 > #!CommitTicketReference repository="" revision="69153"
 > wxGUI: escape single quotes when editing attributes from GUI, see #2252
 > }}}

 This deals with single quotes only, no security issue is solved by this.
 So please test, I can backport it and decide what else to do with this
 ticket. We should at least downgrade the priority if not close it at all.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2252: wxGUI vector digitizer passing unescaped text to database

[GRASS GIS]

#2252: wxGUI vector digitizer passing unescaped text to database
-+-
  Reporter:  marisn  |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  critical|  Milestone:  7.0.5
 Component:  wxGUI   |Version:  svn-trunk
Resolution:  |   Keywords:  security, code injection, SQL
   CPU:  |  injection, data loss, v.db.update
  Unspecified|   Platform:  Unspecified
-+-

Comment (by annakrat):

 In [changeset:"69153" 69153]:
 {{{
 #!CommitTicketReference repository="" revision="69153"
 wxGUI: escape single quotes when editing attributes from GUI, see #2252
 }}}

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] G6 manual pages: text box added to make users aware of G7

[Vaclav Petras]

On Thu, Aug 18, 2016 at 5:54 AM, Markus Neteler  wrote:

> > I am not a developer, just something I wondered; why not having one
> > permanent address for the manual, which always reflects the latest stable
> > release, and if needed, from there add links to older versions? Obviously
> > not a solution for now, but this would lead, in the future, to more
> stable
> > and permanent rankings for the most up-to-date version.
>
> +1
>
> Perhaps simply this:
>
> https://grass.osgeo.org/manuals/
> https://grass.osgeo.org/manuals/addons
>
> I could easily add that in the CMS and make it point to the current
> stable version.


If we can maintain the URL in the long term that would be great.

BTW, surprised to see "keywords index" as part of the "manuals" page.
Unfortunately the links are broken:

https://grass.osgeo.org/v.hull.html

Anyway, the above solution is better if we can have link like:

https://grass.osgeo.org/manuals/v.hull.html
https://grass.osgeo.org/manuals/v.hull

There is potential conflict of:

https://grass.osgeo.org/grass70/manuals/grass7.html
https://grass.osgeo.org/grass70/manuals/grass7
https://grass.osgeo.org/grass70
https://grass.osgeo.org/manuals/grass7.html
https://grass.osgeo.org/manuals/grass7

but if the command will be `grass7` (or even `grass`) and the version
always two numbers and the order is not changed to "manuals/grass70", no
conflict will happen.

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

Re: [GRASS-dev] 7.0.5 release planning

[Markus Neteler]

On Thu, Aug 18, 2016 at 12:05 PM, Markus Neteler  wrote:
> On Tue, Jul 19, 2016 at 4:27 PM, Moritz Lennert
>  wrote:
>> On 18/07/16 17:36, Martin Landa wrote:
>>>
>>> Hi all,
>>>
>>> as we are planning to release 7.0.5 in August [1] I suggest to start
>>> with "Soft freeze of release branch" [2] today. Martin
>>>
>>
>> +1
>>
>> I think it would be nice if we could apply the patches from Debian:
>> https://trac.osgeo.org/grass/ticket/3042. Has anyone had a look, yet ?
>>
>> There's also https://trac.osgeo.org/grass/ticket/2252 which has been pushed
>> from release to release. I don't really know how to handle the issue. Anyone
>> of the wxGUI developers maybe ?
>
> We are lacking a bit of feedback here :-)
>
> Let me suggest to not postpone 7.2.0 forever but have 7.2.1 in mind!

I meant to say: this is 7.0.5 but 7.2.0 is also to be released.

> Time to release...

... applies to both 7.0.5 and 7.2.0.

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

Re: [GRASS-dev] 7.0.5 release planning

[Markus Neteler]

On Tue, Jul 19, 2016 at 4:27 PM, Moritz Lennert
 wrote:
> On 18/07/16 17:36, Martin Landa wrote:
>>
>> Hi all,
>>
>> as we are planning to release 7.0.5 in August [1] I suggest to start
>> with "Soft freeze of release branch" [2] today. Martin
>>
>
> +1
>
> I think it would be nice if we could apply the patches from Debian:
> https://trac.osgeo.org/grass/ticket/3042. Has anyone had a look, yet ?
>
> There's also https://trac.osgeo.org/grass/ticket/2252 which has been pushed
> from release to release. I don't really know how to handle the issue. Anyone
> of the wxGUI developers maybe ?

We are lacking a bit of feedback here :-)

Let me suggest to not postpone 7.2.0 forever but have 7.2.1 in mind!
Time to release...

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

Re: [GRASS-dev] [GRASS GIS] #3042: Patches to make the build reproducible (fileordering, randomness)

[GRASS GIS]

#3042: Patches to make the build reproducible (fileordering, randomness)
--+-
  Reporter:  sebastic |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  critical |  Milestone:  7.0.5
 Component:  Compiling|Version:  7.0.4
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Linux
--+-

Comment (by neteler):

 added to
 https://grasswiki.osgeo.org/wiki/GRASS_Community_Sprint_Bonn_2016#Bug_squashing

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] G6 manual pages: text box added to make users aware of G7

[Markus Neteler]

On Thu, Aug 18, 2016 at 11:50 AM, Paulo van Breugel
 wrote:
> On 18-08-16 10:22, Markus Neteler wrote:
>> Hi devs,

right:
s+devs+all+

>> still our (Google) ranking of the G7 manual is fairly bad (ideas
>> welcome how to fix that).
>
> I am not a developer, just something I wondered; why not having one
> permanent address for the manual, which always reflects the latest stable
> release, and if needed, from there add links to older versions? Obviously
> not a solution for now, but this would lead, in the future, to more stable
> and permanent rankings for the most up-to-date version.

+1

Perhaps simply this:

https://grass.osgeo.org/manuals/
https://grass.osgeo.org/manuals/addons

I could easily add that in the CMS and make it point to the current
stable version.

>> For the time being I have added a HTML injection to the cronjob which
>> creates the G6 manual pages.
>>
>> Each page now contains a box, pointing the user to G7.
>
> Very helpful

Good!

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

Re: [GRASS-dev] G6 manual pages: text box added to make users aware of G7

[Paulo van Breugel]

On 18-08-16 10:22, Markus Neteler wrote:

Hi devs,

still our (Google) ranking of the G7 manual is fairly bad (ideas
welcome how to fix that).
I am not a developer, just something I wondered; why not having one 
permanent address for the manual, which always reflects the latest 
stable release, and if needed, from there add links to older versions? 
Obviously not a solution for now, but this would lead, in the future, to 
more stable and permanent rankings for the most up-to-date version.

For the time being I have added a HTML injection to the cronjob which
creates the G6 manual pages.

Each page now contains a box, pointing the user to G7.

Very helpful


Markus
___
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

[GRASS-dev] G6 manual pages: text box added to make users aware of G7

[Markus Neteler]

Hi devs,

still our (Google) ranking of the G7 manual is fairly bad (ideas
welcome how to fix that).
For the time being I have added a HTML injection to the cronjob which
creates the G6 manual pages.

Each page now contains a box, pointing the user to G7.

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