Re: [GRASS-dev] [EXTERNAL] vector patching frustration

[Newcomb, Doug via grass-dev]

Have you tried a .csvt file for your .csv file? 
https://gdal.org/drivers/vector/csv.html


From: grass-dev  on behalf of Michael Barton 
via grass-dev 
Sent: Wednesday, March 13, 2024 7:02 PM
To: GRASS developers ; GRASS user list 

Subject: [EXTERNAL] [GRASS-dev] vector patching frustration




 This email has been received from outside of DOI - Use caution before clicking 
on links, opening attachments, or responding.



I am completely stymied in my attempt to do what should be a simple task. I 
have a map of vector areas, linked with an attribute table. I would like to 
patch in one more vector area, for which I have equivalent attribute 
information. I have tried this multiple ways and I cannot make this patch 
happen so that the added area has attribute info.

The closest I've come is to create and link a one line table to the new area 
that has exactly the same fields as the larger vector area map. The first map 
has 154 areas (i.e., cat=1-155). When I patch the maps and look at the 
resulting attribute table, I indeed see line and cat 155. But it is not linked 
with the patched area--which has been assigned a cat=183 for reasons I cannot 
fathom. The patch also renumbers my cat field to cat=2-155 from the original 
1-154.

This has been made more complicated by the fact that v.in.ogr imports all 
columns of a *.csv as text, regardless of what is in them and assigns cat 
numbers starting at 1. So I can't specify an integer key field of 155 to try 
the linking. Nor can I change the assigned cat of the single area I am trying 
to patch from 1 to 155 using v.category (or anything else I can find).

I'm hoping that someone has a clever solution that I've not seen or I'll just 
have to do this fairly simple and straightforward vector operation in QGIS.

Michael
_

C. Michael Barton
Associate Director, School of Complex Adaptive Systems 
(https://scas.asu.edu)
Professor, School of Human Evolution & Social Change 
(https://shesc.asu.edu)
Director, Center for Social Dynamics & Complexity 
(https://complexity.asu.edu)
Arizona State University
Tempe, AZ 85287-2701
USA

Executive Director, Open Modeling Foundation 
(https://openmodelingfoundation.github.io)
Director, Network for Computational Modeling in Social & Ecological Sciences 
(https://comses.net)

personal website: http://www.public.asu.edu/~cmbarton


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

Re: [GRASS-dev] [EXTERNAL] Can GRASS import a *.ige file?

[Newcomb, Doug via grass-dev]

Sorry, 2 GB is the size the needs the spill file.  See 
https://gdal.org/drivers/raster/hfa.html#raster-hfa


From: Newcomb, Doug 
Sent: Monday, March 4, 2024 12:57 PM
To: Michael Barton 
Cc: Brendan ; GRASS users 
; evillasenor713 ; GRASS 
developers list 
Subject: Re: [EXTERNAL] [GRASS-dev] Can GRASS import a *.ige file?

No,
The .ige file is what spills over after the 4GB of the .img file fills up.  You 
need to have both.


From: Michael Barton 
Sent: Monday, March 4, 2024 12:12 PM
To: Newcomb, Doug 
Cc: Brendan ; GRASS users 
; evillasenor713 ; GRASS 
developers list 
Subject: Re: [EXTERNAL] [GRASS-dev] Can GRASS import a *.ige file?

The info I downloaded for 2021 had a much more modes sized *.img file and a 
huge *.ige file (25 Gb or so). It looks like the best approach is to use the 
*.img file and discard the *.ige file. Perhaps that latter is the uncompressed 
one.

Michael
_

C. Michael Barton
Associate Director, School of Complex Adaptive Systems 
(https://scas.asu.edu<https://scas.asu.edu/>)
Professor, School of Human Evolution & Social Change 
(https://shesc.asu.edu<https://shesc.asu.edu/>)
Director, Center for Social Dynamics & Complexity 
(https://complexity.asu.edu<https://complexity.asu.edu/>)
Arizona State University
Tempe, AZ 85287-2701
USA

Executive Director, Open Modeling Foundation 
(https://openmodelingfoundation.github.io<https://openmodelingfoundation.github.io/>)
Director, Network for Computational Modeling in Social & Ecological Sciences 
(https://comses.net<https://comses.net/>)

personal website: http://www.public.asu.edu/~cmbarton


On Mar 4, 2024, at 7:56 AM, Newcomb, Doug  wrote:

Michael,
The last time I checked, the NLCD data in .img format is an uncompressed 
raster.  You can save a massive amount of hard drive space by converting the 
.img files to deflate compressed geotiff, then linking via r.external.

That's what I did for the 2019 NLCD , 
https://youtu.be/0NHdWSF96o0<https://urldefense.com/v3/__https://youtu.be/0NHdWSF96o0__;!!IKRxdwAv5BmarQ!blFVjt0b_VzE5YHFAP329crlFPnXaqNiZ4D-fL-iXPQ5XyqvecAcD8O_8casHv10elH0LT7wGuoEBXEk0QGvrXJmh8d9eLE$>
 .  The 2021 is the same.  The .img /ige file is 26 GB for 1 year nationwide. 
Converting to deflate compressed geotiff takes it down to 1.5 GB.

Hope this helps!

Doug

From: grass-dev 
mailto:grass-dev-boun...@lists.osgeo.org>> 
on behalf of Michael Barton via grass-dev 
mailto:grass-dev@lists.osgeo.org>>
Sent: Friday, March 1, 2024 7:00 PM
To: Brendan mailto:brendan.har...@gmail.com>>
Cc: GRASS users 
mailto:grass-u...@lists.osgeo.org>>; evillasenor713 
mailto:evillasenor...@gmail.com>>; GRASS developers 
list mailto:grass-dev@lists.osgeo.org>>
Subject: [EXTERNAL] Re: [GRASS-dev] Can GRASS import a *.ige file?




 This email has been received from outside of DOI - Use caution before clicking 
on links, opening attachments, or responding.


Thanks!
_
C. Michael Barton
Associate Director, School of Complex Adaptive Systems 
(https://scas.asu.edu<https://scas.asu.edu/>)
Professor, School of Human Evolution & Social Change 
(https://shesc.asu.edu<https://shesc.asu.edu/>)
Director, Center for Social Dynamics & Complexity 
(https://complexity.asu.edu<https://complexity.asu.edu/>)
Arizona State University
Tempe, AZ 85287-2701
USA

Executive Director, Open Modeling Foundation 
(https://openmodelingfoundation.github.io<https://urldefense.com/v3/__https://openmodelingfoundation.github.io/__;!!IKRxdwAv5BmarQ!blFVjt0b_VzE5YHFAP329crlFPnXaqNiZ4D-fL-iXPQ5XyqvecAcD8O_8casHv10elH0LT7wGuoEBXEk0QGvrXJmYULrX7M$>)
Director, Network for Computational Modeling in Social & Ecological Sciences 
(https://comses.net<https://urldefense.com/v3/__https://comses.net/__;!!IKRxdwAv5BmarQ!blFVjt0b_VzE5YHFAP329crlFPnXaqNiZ4D-fL-iXPQ5XyqvecAcD8O_8casHv10elH0LT7wGuoEBXEk0QGvrXJmuzKOqRQ$>)

personal website: http://www.public.asu.edu/~cmbarton


On Mar 1, 2024, at 4:43 PM, Brendan  wrote:

Hi Michael. As a rules file for r.category.

r.colors map=nlcd rules=landcover_colors.txt
r.category map=ncld separator=pipe rules=landcover_categories.txt

On Fri, Mar 1, 2024 at 5:39 PM Michael Barton 
mailto:michael.bar...@asu.edu>> wrote:
Thanks Brendan,

Any suggestions on how to get this into the raster? Or are you thinking we 
should export the raster to vector and link the csv that way?

Michael
_
C. Michael Barton
Associate Director, School of Complex Adaptive Systems 
(https://scas.asu.edu<https://scas.asu.edu/>)
Professor, School of Human Evolution & Social Change 
(https://shesc.asu.edu<https://shesc.asu.edu/>)
Director, Center for Social Dynamics & Complexity 
(https://complexity.asu.edu<https://complexity.asu.edu/>)
Arizona State 

Re: [GRASS-dev] [EXTERNAL] Can GRASS import a *.ige file?

[Newcomb, Doug via grass-dev]

No,
The .ige file is what spills over after the 4GB of the .img file fills up.  You 
need to have both.


From: Michael Barton 
Sent: Monday, March 4, 2024 12:12 PM
To: Newcomb, Doug 
Cc: Brendan ; GRASS users 
; evillasenor713 ; GRASS 
developers list 
Subject: Re: [EXTERNAL] [GRASS-dev] Can GRASS import a *.ige file?

The info I downloaded for 2021 had a much more modes sized *.img file and a 
huge *.ige file (25 Gb or so). It looks like the best approach is to use the 
*.img file and discard the *.ige file. Perhaps that latter is the uncompressed 
one.

Michael
_

C. Michael Barton
Associate Director, School of Complex Adaptive Systems 
(https://scas.asu.edu<https://scas.asu.edu/>)
Professor, School of Human Evolution & Social Change 
(https://shesc.asu.edu<https://shesc.asu.edu/>)
Director, Center for Social Dynamics & Complexity 
(https://complexity.asu.edu<https://complexity.asu.edu/>)
Arizona State University
Tempe, AZ 85287-2701
USA

Executive Director, Open Modeling Foundation 
(https://openmodelingfoundation.github.io<https://openmodelingfoundation.github.io/>)
Director, Network for Computational Modeling in Social & Ecological Sciences 
(https://comses.net<https://comses.net/>)

personal website: http://www.public.asu.edu/~cmbarton


On Mar 4, 2024, at 7:56 AM, Newcomb, Doug  wrote:

Michael,
The last time I checked, the NLCD data in .img format is an uncompressed 
raster.  You can save a massive amount of hard drive space by converting the 
.img files to deflate compressed geotiff, then linking via r.external.

That's what I did for the 2019 NLCD , 
https://youtu.be/0NHdWSF96o0<https://urldefense.com/v3/__https://youtu.be/0NHdWSF96o0__;!!IKRxdwAv5BmarQ!blFVjt0b_VzE5YHFAP329crlFPnXaqNiZ4D-fL-iXPQ5XyqvecAcD8O_8casHv10elH0LT7wGuoEBXEk0QGvrXJmh8d9eLE$>
 .  The 2021 is the same.  The .img /ige file is 26 GB for 1 year nationwide. 
Converting to deflate compressed geotiff takes it down to 1.5 GB.

Hope this helps!

Doug

From: grass-dev 
mailto:grass-dev-boun...@lists.osgeo.org>> 
on behalf of Michael Barton via grass-dev 
mailto:grass-dev@lists.osgeo.org>>
Sent: Friday, March 1, 2024 7:00 PM
To: Brendan mailto:brendan.har...@gmail.com>>
Cc: GRASS users 
mailto:grass-u...@lists.osgeo.org>>; evillasenor713 
mailto:evillasenor...@gmail.com>>; GRASS developers 
list mailto:grass-dev@lists.osgeo.org>>
Subject: [EXTERNAL] Re: [GRASS-dev] Can GRASS import a *.ige file?




 This email has been received from outside of DOI - Use caution before clicking 
on links, opening attachments, or responding.


Thanks!
_
C. Michael Barton
Associate Director, School of Complex Adaptive Systems 
(https://scas.asu.edu<https://scas.asu.edu/>)
Professor, School of Human Evolution & Social Change 
(https://shesc.asu.edu<https://shesc.asu.edu/>)
Director, Center for Social Dynamics & Complexity 
(https://complexity.asu.edu<https://complexity.asu.edu/>)
Arizona State University
Tempe, AZ 85287-2701
USA

Executive Director, Open Modeling Foundation 
(https://openmodelingfoundation.github.io<https://urldefense.com/v3/__https://openmodelingfoundation.github.io/__;!!IKRxdwAv5BmarQ!blFVjt0b_VzE5YHFAP329crlFPnXaqNiZ4D-fL-iXPQ5XyqvecAcD8O_8casHv10elH0LT7wGuoEBXEk0QGvrXJmYULrX7M$>)
Director, Network for Computational Modeling in Social & Ecological Sciences 
(https://comses.net<https://urldefense.com/v3/__https://comses.net/__;!!IKRxdwAv5BmarQ!blFVjt0b_VzE5YHFAP329crlFPnXaqNiZ4D-fL-iXPQ5XyqvecAcD8O_8casHv10elH0LT7wGuoEBXEk0QGvrXJmuzKOqRQ$>)

personal website: http://www.public.asu.edu/~cmbarton


On Mar 1, 2024, at 4:43 PM, Brendan  wrote:

Hi Michael. As a rules file for r.category.

r.colors map=nlcd rules=landcover_colors.txt
r.category map=ncld separator=pipe rules=landcover_categories.txt

On Fri, Mar 1, 2024 at 5:39 PM Michael Barton 
mailto:michael.bar...@asu.edu>> wrote:
Thanks Brendan,

Any suggestions on how to get this into the raster? Or are you thinking we 
should export the raster to vector and link the csv that way?

Michael
_
C. Michael Barton
Associate Director, School of Complex Adaptive Systems 
(https://scas.asu.edu<https://scas.asu.edu/>)
Professor, School of Human Evolution & Social Change 
(https://shesc.asu.edu<https://shesc.asu.edu/>)
Director, Center for Social Dynamics & Complexity 
(https://complexity.asu.edu<https://complexity.asu.edu/>)
Arizona State University
Tempe, AZ 85287-2701
USA

Executive Director, Open Modeling Foundation 
(https://openmodelingfoundation.github.io<https://urldefense.com/v3/__https://openmodelingfoundation.github.io/__;!!IKRxdwAv5BmarQ!fYLFZEUpm1jpIJ_wm9a70bYCdA7aB_txlsEaQfBpT7KsCcPE0D-XCqh0G78yAHLt9z7W65xcJpglR-yakP99V5Z7ExxQeoo$>)

Re: [GRASS-dev] [EXTERNAL] Re: Can GRASS import a *.ige file?

[Newcomb, Doug via grass-dev]

Michael,
The last time I checked, the NLCD data in .img format is an uncompressed 
raster.  You can save a massive amount of hard drive space by converting the 
.img files to deflate compressed geotiff, then linking via r.external.

That's what I did for the 2019 NLCD , https://youtu.be/0NHdWSF96o0 .  The 2021 
is the same.  The .img /ige file is 26 GB for 1 year nationwide. Converting to 
deflate compressed geotiff takes it down to 1.5 GB.

Hope this helps!

Doug

From: grass-dev  on behalf of Michael Barton 
via grass-dev 
Sent: Friday, March 1, 2024 7:00 PM
To: Brendan 
Cc: GRASS users ; evillasenor713 
; GRASS developers list 
Subject: [EXTERNAL] Re: [GRASS-dev] Can GRASS import a *.ige file?




 This email has been received from outside of DOI - Use caution before clicking 
on links, opening attachments, or responding.



Thanks!
_

C. Michael Barton
Associate Director, School of Complex Adaptive Systems 
(https://scas.asu.edu)
Professor, School of Human Evolution & Social Change 
(https://shesc.asu.edu)
Director, Center for Social Dynamics & Complexity 
(https://complexity.asu.edu)
Arizona State University
Tempe, AZ 85287-2701
USA

Executive Director, Open Modeling Foundation 
(https://openmodelingfoundation.github.io)
Director, Network for Computational Modeling in Social & Ecological Sciences 
(https://comses.net)

personal website: http://www.public.asu.edu/~cmbarton


On Mar 1, 2024, at 4:43 PM, Brendan  wrote:

Hi Michael. As a rules file for r.category.

r.colors map=nlcd rules=landcover_colors.txt
r.category map=ncld separator=pipe rules=landcover_categories.txt

On Fri, Mar 1, 2024 at 5:39 PM Michael Barton 
mailto:michael.bar...@asu.edu>> wrote:
Thanks Brendan,

Any suggestions on how to get this into the raster? Or are you thinking we 
should export the raster to vector and link the csv that way?

Michael
_

C. Michael Barton
Associate Director, School of Complex Adaptive Systems 
(https://scas.asu.edu)
Professor, School of Human Evolution & Social Change 
(https://shesc.asu.edu)
Director, Center for Social Dynamics & Complexity 
(https://complexity.asu.edu)
Arizona State University
Tempe, AZ 85287-2701
USA

Executive Director, Open Modeling Foundation 
(https://openmodelingfoundation.github.io)
Director, Network for Computational Modeling in Social & Ecological Sciences 
(https://comses.net)

personal website: http://www.public.asu.edu/~cmbarton


On Mar 1, 2024, at 4:08 PM, Brendan 
mailto:brendan.har...@gmail.com>> wrote:

Hi Michael, I've attached an NLCD legend in csv format and text files with 
categories and color table for GRASS in case it helps.

On Fri, Mar 1, 2024 at 4:34 PM Michael Barton via grass-dev 
mailto:grass-dev@lists.osgeo.org>> wrote:
Thanks Ana,

I was able to do that. I'm trying to look at the NLCD. While it opens fine and 
is classified, there are no text labels for the landcover categories. Would 
these be hiding in the *.ige file?

Michael
_

C. Michael Barton
Associate Director, School of Complex Adaptive Systems 
(https://scas.asu.edu)
Professor, School of Human Evolution & Social Change 
(https://shesc.asu.edu)
Director, Center for Social Dynamics & Complexity 
(https://complexity.asu.edu)
Arizona State University
Tempe, AZ 85287-2701
USA

Executive Director, Open Modeling Foundation 
(https://openmodelingfoundation.github.io)
Director, Network for Computational Modeling in Social & Ecological Sciences 
(https://comses.net)

personal website: http://www.public.asu.edu/~cmbarton


On Mar 1, 2024, at 3:01 PM, Anna Petrášová 
mailto:kratocha...@gmail.com>> wrote:

There should be an .img file, try open that instead.

On Fri, Mar 1, 2024 at 4:51 PM Michael Barton via grass-dev 
mailto:grass-dev@lists.osgeo.org>> wrote:
It doesn't look like r.in.gdal does this. Is there an extension or other way to 
import an ERDAS *.ige file?

Michael
_

C. 

Re: [GRASS-dev] [EXTERNAL] Re: [release planning] GRASS GIS 8.3.1

[Newcomb, Doug via grass-dev]

I wouldn't mind seeing the fix to g.extension for Windows that just went in, so 
you can load addons  on Windows in 8.3.x 
https://github.com/OSGeo/grass/pull/3166#issuecomment-1727462938
[https://opengraph.githubassets.com/f9d53daef25fcfb526eac15d1abc3b2f3aab12de75e83651422088b0bd791720/OSGeo/grass/pull/3166]<https://github.com/OSGeo/grass/pull/3166#issuecomment-1727462938>
g.extension: fix installing addons on the OS MS Windows by tmszi · Pull Request 
#3166 · 
OSGeo/grass<https://github.com/OSGeo/grass/pull/3166#issuecomment-1727462938>
Fixes #3077. Fix installing addons via g.extension module on the OS MS Windows 
without dependency on Git program. Gettings official GitHub addons repository 
branches g.extension -l is based on the ...
github.com


From: grass-dev  on behalf of Nicklas 
Larsson via grass-dev 
Sent: Wednesday, September 20, 2023 4:14 AM
To: Markus Neteler 
Cc: GRASS developers list 
Subject: [EXTERNAL] Re: [GRASS-dev] [release planning] GRASS GIS 8.3.1




 This email has been received from outside of DOI - Use caution before clicking 
on links, opening attachments, or responding.



In general, I wouldn’t mind a quick patch 8.3.1 release. Remaining 
(non-blocking) issues may be bumped to 8.3.2, which in turn can be released as 
soon as possible.

The changes since 8.3.0:
https://github.com/OSGeo/grass/compare/8.3.0...OSGeo:grass:releasebranch_8_3?expand=1


Best,
Nicklas


On 19 Sep 2023, at 21:33, Markus Neteler 
mailto:nete...@osgeo.org>> wrote:

Any other opinions?
What about the Windows g.extension git story, to be added to 8.3.1?

Markus

On Mon, Sep 11, 2023 at 1:48 PM Newcomb, Doug 
mailto:doug_newc...@fws.gov>> wrote:

This is an important function of GRASS. I think it would be wise to rectify the 
issue as soon as possible


From: grass-dev 
mailto:grass-dev-boun...@lists.osgeo.org>> 
on behalf of Markus Neteler mailto:nete...@osgeo.org>>
Sent: Monday, September 11, 2023 6:26 AM
To: GRASS developers list 
mailto:grass-dev@lists.osgeo.org>>
Subject: [EXTERNAL] [GRASS-dev] [release planning] GRASS GIS 8.3.1

Hi devs,

While 8.3.0 has been released rather recently, an important bug showed up:
- r.watershed: fix streams and basins #3140

Unfortunately r.watershed is partially broken in 8.3.0 such that
streams and basins are no longer correctly calculated. This has been
now been fixed.

Given the importance of r.watershed, I suggest an anticipated release of 8.3.1

Here the milestone:
https://github.com/OSGeo/grass/milestone/21

What do you think?

Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org<mailto:grass-dev@lists.osgeo.org>
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

Re: [GRASS-dev] [EXTERNAL] [release planning] GRASS GIS 8.3.1

[Newcomb, Doug via grass-dev]

This is an important function of GRASS. I think it would be wise to rectify the 
issue as soon as possible


From: grass-dev  on behalf of Markus Neteler 

Sent: Monday, September 11, 2023 6:26 AM
To: GRASS developers list 
Subject: [EXTERNAL] [GRASS-dev] [release planning] GRASS GIS 8.3.1



 This email has been received from outside of DOI - Use caution before clicking 
on links, opening attachments, or responding.



Hi devs,

While 8.3.0 has been released rather recently, an important bug showed up:
- r.watershed: fix streams and basins #3140

Unfortunately r.watershed is partially broken in 8.3.0 such that
streams and basins are no longer correctly calculated. This has been
now been fixed.

Given the importance of r.watershed, I suggest an anticipated release of 8.3.1

Here the milestone:
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FOSGeo%2Fgrass%2Fmilestone%2F21=05%7C01%7Cdoug_newcomb%40fws.gov%7C26a98786f90649a4285708dbb2b18d3e%7C0693b5ba4b184d7b9341f32f400a5494%7C0%7C0%7C638300247899902911%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=TVxcmemqNwNHpsYv%2Fuopx0A6S83s6BcTIt%2FbyR7j3Zw%3D=0

What do you think?

Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.osgeo.org%2Fmailman%2Flistinfo%2Fgrass-dev=05%7C01%7Cdoug_newcomb%40fws.gov%7C26a98786f90649a4285708dbb2b18d3e%7C0693b5ba4b184d7b9341f32f400a5494%7C0%7C0%7C638300247899902911%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=oMu3BWddkv%2B7%2FrgsY9Di8F7a2P2ZcyTNACaeEZJ61ws%3D=0
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [EXTERNAL] Re: screenshots of old GRASS

[Newcomb, Doug via grass-dev]

Screenshots from the Shatner video?  https://youtu.be/cZia3ShzTWM

From: grass-dev  on behalf of Veronica 
Andreo 
Sent: Tuesday, July 11, 2023 7:51 AM
To: Michael Barton 
Cc: GRASS developers 
Subject: [EXTERNAL] Re: [GRASS-dev] screenshots of old GRASS




 This email has been received from outside of DOI - Use caution before clicking 
on links, opening attachments, or responding.



Perhaps Helena or MarkusN

The oldest I could find within the website repo are these:
- 
https://github.com/OSGeo/grass-website/blob/master/static/images/gallery/history/grass32_tape.jpg
- 
https://github.com/OSGeo/grass-website/blob/master/static/images/gallery/museum/grass421_tcltkgrass.png

Vero

El lun, 10 jul 2023 a las 19:21, Michael Barton 
(mailto:michael.bar...@asu.edu>>) escribió:
Has anybody got a screenshot of the CERL GRASS versions (1, 2, and/or 3)?

Michael
_

C. Michael Barton
Associate Director, School of Complex Adaptive Systems 
(https://scas.asu.edu)
Professor, School of Human Evolution & Social Change 
(https://shesc.asu.edu)
Director, Center for Social Dynamics & Complexity 
(https://complexity.asu.edu)
Arizona State University
Tempe, AZ 85287-2701
USA

Executive Director, Open Modeling Foundation 
(https://openmodelingfoundation.github.io)
Director, Network for Computational Modeling in Social & Ecological Sciences 
(https://comses.net)

personal website: http://www.public.asu.edu/~cmbarton


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

[GRASS-dev] Comments on DCAT-US Metadata Schema version 3.0 requested

[Newcomb, Doug via grass-dev]

Hi Folks,
I was asked to spread the word to the internal and external open source 
geospatial communities that version 3.0 of the DCAT-US Metadata Schema is under 
development and  open to public comment.  If you, or your organization, is 
interested in helping to shape the next US Metadata Schema, feel free to 
comment and/or contribute via github:
https://github.com/DOI-DO/dcat-us
https://github.com/DOI-DO/dcat-us/issues

Doug

Doug Newcomb - Cartographer
USFWS
551F Pylon Dr
Raleigh, NC
919-856-4520 ext. 14 doug_newc...@fws.gov
-

NOTE: This email correspondence and any attachments to and from this sender is 
subject to the Freedom of Information Act (FOIA) and may be disclosed to third 
parties.​

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

Re: [GRASS-dev] [EXTERNAL] Link to installation

[Newcomb, Doug via grass-dev]

On my personal laptop last night for Linux Mint 21.1, I just followed the 
compilation instructions for the source at 
https://grasswiki.osgeo.org/wiki/Compile_and_Install_Ubuntu for Ubuntu 20.04 ( 
adding --with-pdal  to the configuration script ) and had no problems compiling 
from the current main tree ( probably doing the 8.2 release branch would be 
better)  . Make but don't make install.  You can make a launcher on the desktop 
in Linux Mint that points directly to the compiled binary .  This makes it 
somewhat easy to have different versions of GRASS compiled for comparison.

This is probably more than you wanted to know and does not help with your issue 
of conflicts with the precompiled binaries, but it works and I personally 
thought it was pretty nifty.

To address your issue, You might try adding the Ubuntu GIS ppa, 
https://wiki.ubuntu.com/UbuntuGIS   
https://launchpad.net/~ubuntugis/+archive/ubuntu/ubuntugis-unstable .

Doug




From: grass-dev  on behalf of 
gisfi...@t-online.de 
Sent: Tuesday, January 10, 2023 7:23 AM
To: grass-dev@lists.osgeo.org 
Subject: [EXTERNAL] [GRASS-dev] Link to installation




 This email has been received from outside of DOI - Use caution before clicking 
on links, opening attachments, or responding.



Hello list,



does a link exist to a simple installation for GRASS 8 on Linux Mint? I just 
tried to install and I get a lot of confusing ‚broken packages‘ messages, so I 
cannot install.

Thanks for help,



Uwe


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

Re: [GRASS-dev] [EXTERNAL] Re: [release planning] GRASS GIS 8.0.0

[Newcomb, Doug via grass-dev]

There may be some work to be done on the Windows standalone installer yet. What 
is at https://wingrass.fsv.cvut.cz/grass80/x86_64/ does not seem to represent 
the latest work.

Doug

From: grass-dev  on behalf of Veronica 
Andreo 
Sent: Tuesday, January 11, 2022 12:51 PM
To: Markus Neteler 
Cc: GRASS developers list 
Subject: [EXTERNAL] Re: [GRASS-dev] [release planning] GRASS GIS 8.0.0




 This email has been received from outside of DOI - Use caution before clicking 
on links, opening attachments, or responding.




El dom, 9 ene 2022 a las 16:36, Markus Neteler 
(mailto:nete...@osgeo.org>>) escribió:
Hi,

On Thu, Dec 30, 2021 at 5:02 PM Markus Neteler 
mailto:nete...@osgeo.org>> wrote:
>
> Dear all,
>
> hooray, GRASS GIS 8.0.0RC1 has been published:
> https://github.com/OSGeo/grass/releases/tag/8.0.0RC1
>
> Please test it!

I'd love to see 8.0.0 being published

We have no more blockers:
https://github.com/OSGeo/grass/issues?q=is%3Aopen+is%3Aissue+label%3Ablocker+milestone%3A8.0.0

This is the 8.0.0 milestone:
https://github.com/OSGeo/grass/milestone/4

We may bump the remaining 13 issues/PRs to milestone 8.0.1.

Here the changes after RC1 on releasebranch_8_0:
https://github.com/OSGeo/grass/compare/8.0.0RC1...releasebranch_8_0

Can we now publish "final" or do we still need a RC2?

With no blockers, I'd be in favor of publishing final already :)
Is there any "policy" regarding the number of RC's before final?

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

Re: [GRASS-dev] [EXTERNAL] PROJ6+ / WKT2 support

[Newcomb, Doug via grass-dev]

Thank you!


From: grass-dev  on behalf of Markus Metz 

Sent: Monday, January 25, 2021 2:25 PM
To: GRASS developers list 
Subject: [EXTERNAL] [GRASS-dev] PROJ6+ / WKT2 support




 This email has been received from outside of DOI - Use caution before clicking 
on links, opening attachments, or responding.



Dear all,

I have prepared a rather large PR [0] to include proper support for PROJ6+ and 
WKT2.

The reason is that PROJ6+ uses a new mechanism based on spatial reference id 
(authority name and code) and WKT2 for coordinate transformations. The good old 
GRASS projection definition, a derivate of PROJ4-style definition, is not able 
to capture details of all currently available coordinate reference systems. 
With the recent substantial enhancements in PROJ, it is time for GRASS to use 
these new enhancements. Current support for PROJ6+ in G78 is not complete and 
still contains some bugs.

This PR (together with previous commits) would fix bugs also present in G78:

CRS mismatch [1] between input and output when creating a location from some 
GDAL/OGR recognized input, importing to this location and exporting again. The 
CRS should be exactly preserved. This bug happens when GRASS is compiled with 
PROJ6+ and GDAL3.

A bug in PROJ can cause PROJ to select a wrong coordinate operation with a 
datum transformation grid that does not cover the whole area of interest. In 
these cases, reprojection fails. This PR takes care of this bug.

Fixing these bugs in G78 requires that all changes related to the new SRID and 
WKT2 handling including all affected import and export modules need to be 
backported.

Therefore I want to backport all relevant changes from master to G78 in order 
to fix these bugs. These changes do not modify existing function definitions, 
but add new functions to the GRASS headers.

Please let me know if you have objections regarding backporting to G78!

Markus M

[0] 
https://github.com/OSGeo/grass/pull/1240
[1] 
https://github.com/qgis/QGIS/issues/18596#issuecomment-753481210
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [EXTERNAL] Re: r.external cache or add overviews?

[Newcomb, Doug via grass-dev]

I ask because I have created a 55 billion pixel vrt of elevation data. I linked 
it to a GRASS mapset . It did take an hour to link , but the zooming and 
panning is reasonably responsive afterwards.

Doug

From: Markus Neteler 
Sent: Wednesday, December 23, 2020 4:51 PM
To: Newcomb, Doug 
Cc: grass-dev@lists.osgeo.org 
Subject: [EXTERNAL] Re: [GRASS-dev] r.external cache or add overviews?



 This email has been received from outside of DOI - Use caution before clicking 
on links, opening attachments, or responding.



On Wed, Dec 16, 2020 at 2:26 PM Newcomb, Doug via grass-dev
 wrote:
>
> Hi Folks,
> Does r.external generate overviews during the linking process?

I don't think so.
There is no sign of it in
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FOSGeo%2Fgrass%2Fblob%2Fmaster%2Flib%2Fraster%2Fgdal.cdata=04%7C01%7Cdoug_newcomb%40fws.gov%7C4f0883ee7d50465461ea08d8a78cf995%7C0693b5ba4b184d7b9341f32f400a5494%7C0%7C0%7C637443571215425088%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Qqzy%2BTGm%2FTciBVpdomqzSW6vcggZMD9vfmvQSV4FDiE%3Dreserved=0
or
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FOSGeo%2Fgrass%2Fblob%2Fmaster%2Fraster%2Fr.external%2Flink.cdata=04%7C01%7Cdoug_newcomb%40fws.gov%7C4f0883ee7d50465461ea08d8a78cf995%7C0693b5ba4b184d7b9341f32f400a5494%7C0%7C0%7C637443571215425088%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=vQs7F7GNkdpppxsX5iakyWEA64%2FivjqvZx1pbabnFkY%3Dreserved=0

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

[GRASS-dev] r.external cache or add overviews?

[Newcomb, Doug via grass-dev]

Hi Folks,
Does r.external generate overviews during the linking process?

Doug

Doug Newcomb - Cartographer
USFWS
551F Pylon Dr
Raleigh, NC
919-856-4520 ext. 14 doug_newc...@fws.gov
-

NOTE: This email correspondence and any attachments to and from this sender is 
subject to the Freedom of Information Act (FOIA) and may be disclosed to third 
parties.​

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

Re: [GRASS-dev] [EXTERNAL] ZSTD error

[Newcomb, Doug]

It may be an older version of the zstd library compiled on 7.6.0.

Doug

On Wed, Dec 4, 2019 at 4:01 AM Anna Petrášová  wrote:

> Hi,
>
> I can't open colleague's data, I am getting:
>
> ZSTD compression error -2: Unknown frame descriptor
> Error uncompressing fp raster data for row 24 of : error
> code -1
>
> r.compress -p:
>  is compressed (method 5: ZSTD). Data type: FCELL
>  has a compressed NULL file
>
> Any idea what could be going on? He said it works ok on his Mac and
> Windows? I tried latest master and 78 with ZSTD compression on my side.
>
> Thank you,
> Anna
>


-- 
Doug Newcomb - Cartographer
USFWS
551F Pylon Dr
Raleigh, NC
919-856-4520 ext. 14 doug_newc...@fws.gov
-

*NOTE: This email correspondence and any attachments to and from this
sender is subject to the Freedom of Information Act (FOIA) and may be
disclosed to third parties.*​
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [EXTERNAL] Re: [GRASS-user] GRASS GIS 7.8.1 released with PROJ 6 and GDAL 3 support

[Newcomb, Doug]

A bit confused.  From the command line this morning on the Windows version
of 7.8.1 , I was able to run r.external to link to a vrt raster file and it
seems to have worked fine ( GUI is another matter) .  In what way is
r.external not working?

Doug



On Tue, Nov 12, 2019 at 11:09 AM Markus Metz 
wrote:

> Regarding GDAL 3 support, we still need to add the new GDAL library
> versions to lib/raster/gdal.c for r.external to work.
>
> Markus M
>
> On Tue, Nov 12, 2019 at 8:56 AM Markus Neteler  wrote:
>
>> What's new in a nutshell
>>
>> As a follow-up to the recent GRASS GIS 7.8.0 release we have pusblished
>> the new stable release GRASS GIS 7.8.1. Besides improving the Python 3
>> compatibility efforts have concentrated on implementing PROJ 6 and GDAL 3
>> support.
>>
>> An overview of the new features in the 7.8 release series is available at new
>> features in GRASS GIS 7.8
>> .
>> Binaries/Installer download:
>>
>>- winGRASS 7.8.1: 32bit standalone installer
>>
>> 
>>| 64bit standalone installer
>>
>> 
>>- winGRASS 7.8.1 OSGeo4W: 32bit OSGeo4W installer
>> | 64bit
>>OSGeo4W installer
>>
>>- Debian 
>>- Fedora and EPEL7
>> (CentOS7,
>>RHEL7, ... - included in Fedora 31+)
>>- Linux Mint: see Ubuntu
>>- Ubuntu
>>
>>(ubuntugis-unstable)
>>-
>> *... further binary packages for other Linux distributions will follow
>>shortly, please check at software downloads
>>. *
>>
>> Source code download:
>>
>>- https://grass.osgeo.org/grass78/source/
>>- https://grass.osgeo.org/grass78/source/grass-7.8.1.tar.gz
>>- To get the GRASS GIS 7.8.1 source code directly from GitHub, see
>>here .
>>
>> More details:
>>
>> See also our detailed announcement:
>> https://trac.osgeo.org/grass/wiki/Release/7.8.1-News
>> https://trac.osgeo.org/grass/wiki/Grass7/NewFeatures78 (overview of new
>> 7.8 stable release series)
>> https://grass.osgeo.org/grass7/manuals/addons/ (list of available addons)
>>
>> Thanks to all contributors!
>> ___
>> grass-user mailing list
>> grass-u...@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/grass-user
>
>

-- 
Doug Newcomb - Cartographer
USFWS
551F Pylon Dr
Raleigh, NC
919-856-4520 ext. 14 doug_newc...@fws.gov
-

*NOTE: This email correspondence and any attachments to and from this
sender is subject to the Freedom of Information Act (FOIA) and may be
disclosed to third parties.*​
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [EXTERNAL] Re: PROJ6 support in GRASS

[Newcomb, Doug]

Markus,
Thank you for working on this!

 Perhaps a flag to default to the transformation with the least error ( via
something like the  projinfo  -s x -t y --summary  query and with details
captured about the option selected  in the metadata)?
https://media.ccc.de/v/bucharest-198-revamp-of-coordinate-reference-system-management-in-the-osgeo-c-c-stack-with-proj-and-gdal#t=666
around
10:33 minutes in.

Looking at the reprojection options in QGIS 3.8.2 the menu for picking the
reprojection option lists the accuracy, the number of contributing
stations, and a preferred alternative. If this data can be gleaned from a
projinfo query, a preferred alternative can be established.  I would not
make that the default.

A sample workflow would be that someone tries r.proj with no flags. If
there are multiple alternatives, it does not proceed and gives a message
along the lines of " Multiple projection options detected, please rerun
with --info flag to see alternatives.

User reruns with --info flag ( which supersedes all other flags )  and sees
5 alternatives with accuracy and number of stations listed with an asterisk
next to the "preferred" alternative

User runs r.proj with a --prefer flag that takes the option with the least
error and most stations.  Alternatively, --file flag that points to a text
file with a proj6 pipeline to enforce exactly what is desired.

The preferred option may not always be the same over time, but if the
pipeline is captured in the metadata you will have a record of how it was
done.

Doug



On Tue, Sep 3, 2019 at 10:31 PM Anna Petrášová 
wrote:

> Hi,
>
>
> On Tue, Sep 3, 2019 at 4:22 AM Markus Metz 
> wrote:
>
>> Hi all,
>>
>> there is a new PR for PROJ6 support in GRASS
>> https://github.com/OSGeo/grass/pull/118
>>
>> There are two important changes when using PROJ6:
>>
>> First, reprojection with v.proj and r.proj is no longer always possible
>> without the user making informed decisions. The reason is that there can be
>> several different operations available to reproject coordinates from one
>> CRS to another CRS. These different operations are listed and the user has
>> to provide the appropriate operation with the pipeline option, taking care
>> of any axisswap.
>>
>
> first, thanks for all the work. Second, I don't see how most users are
> supposed to know what to pick. Is there perhaps a way to pick a good
> default? I just can't imagine not having r.import/v.import...
>
> Anna
>
>>
>> Second, axis order is no longer always easting, northing, e.g. for
>> EPSG:4326 it is northing, easting, and an axisswap might need to be removed
>> from operations provided by PROJ.
>>
>> There are many more changes (see details in the PR), but these are the
>> two most important ones.
>>
>> Feedback welcome!
>> ___
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/grass-dev
>
>

-- 
Doug Newcomb - Cartographer
USFWS
551F Pylon Dr
Raleigh, NC
919-856-4520 ext. 14 doug_newc...@fws.gov
-

*NOTE: This email correspondence and any attachments to and from this
sender is subject to the Freedom of Information Act (FOIA) and may be
disclosed to third parties.*
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [EXTERNAL] Re: [gdal-dev] GDAL 3.0.0 is released

[Newcomb, Doug]

Gdal 3.0, Proj 6, Python 3 only.  Would this be sufficient change for an
8.0 release?

Doug

On Fri, May 10, 2019 at 3:55 PM Stefan Blumentrath <
stefan.blumentr...@nina.no> wrote:

>
> FYI. Maybe of interest...
>
> 
> Fra: gdal-dev  på vegne av Even Rouault
> 
> Sendt: torsdag 9. mai 2019 12.54
> Til: gdal-...@lists.osgeo.org; gdal-annou...@lists.osgeo.org;
> news_i...@osgeo.org
> Emne: [gdal-dev] GDAL 3.0.0 is released
>
> Hi,
>
> On behalf of the GDAL/OGR development team and community, I am pleased to
> announce the release of GDAL/OGR 3.0.0.  GDAL/OGR is a C++ geospatial
> data access library for raster and vector file formats, databases and
> web services.  It includes bindings for several languages, and a variety
> of command line tools.
>
>http://www.gdal.org/
>
> The 3.0.0 release is a new feature release with the following highlights:
>
>  * Implement RFC 73: Integration of PROJ6 for WKT2, late binding
> capabilities,
> time-support and unified CRS database.
> ==> PROJ >= 6 is now a build requirement
> https://trac.osgeo.org/gdal/wiki/rfc73_proj6_wkt2_srsbarn
>  * New GDAL drivers:
>   - DAAS: read driver for Airbus DS Intelligence Data As A Service
>   - TileDB: read/write driver for https://www.tiledb.io (#1402)
>  * New OGR drivers:
>   - MongoDBv3: read/write driver using libmongocxx v3.4.0 client (for
> MongoDB
> >= 4.0)
>  * Improved drivers:
>- FITS: read/write support for scale, offset and CRS
>- netCDF: read support for groups
>- PDF: add a COMPOSITION_FILE creation option to generate a complex
> document
>- PDS4: subdataset creation support, read/write table/vector support
>  * Support for minimal builds on Unix (#1250)
>  * Add a docker/ directory with Dockerfile for different configurations
>  * Continued code linting
>
> More complete information on the new features and fixes in the 3.0.0
> release can be found at:
>
>   http://trac.osgeo.org/gdal/wiki/Release/3.0.0-News
>
> The release can be downloaded from:
>   * http://download.osgeo.org/gdal/3.0.0/gdal300.zip - source as a zip
>   * http://download.osgeo.org/gdal/3.0.0/gdal-3.0.0.tar.gz - source as
> .tar.gz
>   * http://download.osgeo.org/gdal/3.0.0/gdal-3.0.0.tar.xz - source as
> .tar.xz
>   * http://download.osgeo.org/gdal/3.0.0/gdal-grass-3.0.0.tar.gz -
> GDAL-GRASS
> plugin
>   * http://download.osgeo.org/gdal/3.0.0/gdalautotest-3.0.0.tar.gz - test
> suite
>   * http://download.osgeo.org/gdal/3.0.0/gdal300doc.zip - documentation /
> website
>
> The migration guide can be found at  :
>
> https://github.com/OSGeo/gdal/blob/release/3.0/gdal/MIGRATION_GUIDE.TXT
>
> Best regards,
>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> ___
> gdal-dev mailing list
> gdal-...@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>


-- 
Doug Newcomb - Cartographer
USFWS
551F Pylon Dr
Raleigh, NC
919-856-4520 ext. 14 doug_newc...@fws.gov
-

*NOTE: This email correspondence and any attachments to and from this
sender is subject to the Freedom of Information Act (FOIA) and may be
disclosed to third parties.*​
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [EXTERNAL] gdal version question

[Newcomb, Doug]

I have not tried on the computer at I compiled it on yet. ( Linux)

Doug

On Thu, Feb 7, 2019 at 3:06 PM Michael Barton 
wrote:

> Thanks. That is encouraging. Did you run into any issues related to this?
>
> Michael
> 
> C. Michael Barton
> Director, Center for Social Dynamics & Complexity
> Professor of Anthropology, School of Human Evolution & Social Change
> Head, Graduate Faculty in Complex Adaptive Systems Science
> Arizona State University
>
> voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
> fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
> www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Feb 7, 2019, at 9:00 PM, Newcomb, Doug  wrote:
>
> Michael,
> I've compiled GRASS with both 2.3.x and 2.4.0 ( the current version)
>
> Doug
>
> On Thu, Feb 7, 2019 at 2:49 PM Michael Barton 
> wrote:
>
>> Can  GRASS work with GDAL versions higher than 2.0, including version
>> 3.x?
>>
>> I'd like to import new Sentinel-SAFE files and it seems like I need a
>> newer version of GDAL to do it.
>>
>> MIchael
>> 
>> C. Michael Barton
>> Director, Center for Social Dynamics & Complexity
>> Professor of Anthropology, School of Human Evolution & Social Change
>> Head, Graduate Faculty in Complex Adaptive Systems Science
>> Arizona State University
>>
>> voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
>> fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
>> www: http://www.public.asu.edu/~cmbarton
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.public.asu.edu_-7Ecmbarton=DwMFaQ=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0=RNJwSC3Ek5cdtRJHd6gFZPafy1W7295DnIFV2PLj1Rc=PDNQmQRROmeASWPaZMGIY-cOGF61Oiqaik2sndDEr3E=>,
>> http://csdc.asu.edu
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__csdc.asu.edu=DwMFaQ=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0=RNJwSC3Ek5cdtRJHd6gFZPafy1W7295DnIFV2PLj1Rc=HpxaY2114FwLS9Om6gka1iDRS6DN9TZYA9JLJ_Poz3o=>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ___
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/grass-dev
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.osgeo.org_mailman_listinfo_grass-2Ddev=DwMFaQ=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0=RNJwSC3Ek5cdtRJHd6gFZPafy1W7295DnIFV2PLj1Rc=Y66kcTxne2TxynSisqnIRiV3sP-LqwYSFQsyrYGImkA=>
>
>
>
> --
> Doug Newcomb - Cartographer
> USFWS
> 551F Pylon Dr
> Raleigh, NC
> 919-856-4520 ext. 14 doug_newc...@fws.gov
>
> -
>
> *NOTE: This email correspondence and any attachments to and from this
> sender is subject to the Freedom of Information Act (FOIA) and may be
> disclosed to third parties.*​
>
>
>

-- 
Doug Newcomb - Cartographer
USFWS
551F Pylon Dr
Raleigh, NC
919-856-4520 ext. 14 doug_newc...@fws.gov
-

*NOTE: This email correspondence and any attachments to and from this
sender is subject to the Freedom of Information Act (FOIA) and may be
disclosed to third parties.*​
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [EXTERNAL] gdal version question

[Newcomb, Doug]

Michael,
I've compiled GRASS with both 2.3.x and 2.4.0 ( the current version)

Doug

On Thu, Feb 7, 2019 at 2:49 PM Michael Barton 
wrote:

> Can  GRASS work with GDAL versions higher than 2.0, including version 3.x?
>
> I'd like to import new Sentinel-SAFE files and it seems like I need a
> newer version of GDAL to do it.
>
> MIchael
> 
> C. Michael Barton
> Director, Center for Social Dynamics & Complexity
> Professor of Anthropology, School of Human Evolution & Social Change
> Head, Graduate Faculty in Complex Adaptive Systems Science
> Arizona State University
>
> voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
> fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
> www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev



-- 
Doug Newcomb - Cartographer
USFWS
551F Pylon Dr
Raleigh, NC
919-856-4520 ext. 14 doug_newc...@fws.gov
-

*NOTE: This email correspondence and any attachments to and from this
sender is subject to the Freedom of Information Act (FOIA) and may be
disclosed to third parties.*​
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [EXTERNAL] Package grass installed by pip is not GRASS GIS

[Newcomb, Doug]

Contact the authors?

Doug

On Wed, Oct 10, 2018 at 9:47 AM Vaclav Petras  wrote:

> [was:[GRASS-user] Using grass.script in Jupyter (Azure)]
>
> Dear all,
>
> in less than two days, I have seen two users reporting "I have
> successfully installed GRASS using pip" (see e.g. the post to the
> grass-user list below, cc'ed).
>
> It is an an unfortunate situation because there is a package called
> `grass` unrelated to GRASS GIS project. See:
>
> https://pypi.org/project/grass/
>
> The package installs a executable called `grass` and of course a Python
> package called grass. See also:
>
> https://github.com/COMBINE-lab/GRASS
>
> What do you think would be the best course of action?
>
> Thanks,
> Vaclav
>
>
> On Wed, Oct 10, 2018 at 5:18 AM Markus Neteler  wrote:
> >
> > Hi,
> >
> > Mehrdad Varedi  schrieb am Mi., 10. Okt. 2018, 03:25:
> >>
> >> Hi Everyone,
> >>
> >> I want to develop a program using GRASS python libraries in Jupyter(on
> Azure). All codes begin with:
> >>
> >> import grass.script as gscript
> >>
> >> of course the grass.script is not available in Jupyter. I tried to
> install GRASS
> >>
> >> I used: !pip install GRASS
> >> and it worked like a charm, although I can't have access to
> grass.script.
> >> Sorry if it is a silly question, although I apreciate any idea to begin
> programming GRASS on Azure.
> >
> > Please check the Jupyter examples here:
> >
> > https://grasswiki.osgeo.org/wiki/GRASS_GIS_Jupyter_notebooks
> >
> > They may give you a start. Please let us know how it goes and feel free
> to add your notes to the wiki page.
> >
> > Best,
> > Markus
>


-- 
Doug Newcomb - Cartographer
USFWS
551F Pylon Dr
Raleigh, NC
919-856-4520 ext. 14 doug_newc...@fws.gov
-

*NOTE: This email correspondence and any attachments to and from this
sender is subject to the Freedom of Information Act (FOIA) and may be
disclosed to third parties.*​
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [EXTERNAL] [GRASS GIS] #3560: r.in.lidar: error to open valid LAZ file

[Newcomb, Doug]

On a related note, I tried compiling liblas1.8.1 ( current version)  on
Ubuntu 18.04 last night and I get a lot of errors out of the box that seem
to be related to compiler version.  Will need to set up a virtual 16.04 box
for the short term.

Doug

On Wed, May 9, 2018 at 4:14 PM, Newcomb, Doug  wrote:

>
>
> On Wed, May 9, 2018 at 4:02 PM, Markus Neteler  wrote:
>
>> On Wed, May 9, 2018 at 9:37 PM, Newcomb, Doug 
>> wrote:
>> > On Wed, May 9, 2018 at 3:21 PM, Markus Neteler 
>> wrote:
>> >>
>> >> Doug,
>> >>
>> >> On Wed, May 9, 2018 at 9:17 PM, Newcomb, Doug 
>> >> wrote:
>> >> > Markus,
>> >> > Liblas reads LAS version 1.2 , which is limited to 4.2 billion
>> points.
>> >>
>> >> I see. But "count" states 297.683.873 which is way less points?
>> >
>> > Good question
>> >
>> >> > You have to compile liblas with an older version of laszip .
>> >>
>> >> Uhm, why an _older_ version?
>> >
>> > The API to LASzip changed with version 3.   I use LASzip 2.2.0 compiled
>> with
>> > liblas from 2013 and have no problems so far.   https://laszip.org/
>> The most
>> > recent version of 3  was for version 1.4 of the LAS spec.
>> >
>> > You need to compile current pdal and current  liblas with different
>> versions
>> > of the Laszip library .
>>
>> On that machine is PDAL-1.7.0 (wit patches) which requires laszip 3.2.x.
>>
>> So, to compile liblas with an older laszip would be tricky.
>>
>
> On the machine I am using for this  , I have compiled the old laszip as
> the system laszip library and compile but do not install the newer one.  I
> then point pdal to the directory with the newer version when compiling it.
> So far, that seems to work.
>
>
>>
>> > pdal used to output version 1.2 of las data by default . I t worked
>> fine for
>> > me at version 1.6 . I have not checked if that is the case with version
>> > 1.7.1 .  1.7 had a bug which required a quick bugfix to 1.7.1, by the
>> way. (
>> > I do not recall the bug off of the top of my head.)
>>
>> The solution would be the implementation of r.in.pdal:
>> https://trac.osgeo.org/grass/ticket/3515
>
>
>>
>> to get rid of liblas which is not developed any more.
>
>
>> And/or package laz-perf sigh, so many hours already spent on
>> packaging...
>>
>> Markus
>>
>>
> Doug
>
> --
> Doug Newcomb
> USFWS
> 551F Pylon Dr
> Raleigh, NC
> 919-856-4520 ext. 14 doug_newc...@fws.gov
> 
> -
>
> *NOTE: This email correspondence and any attachments to and from this
> sender is subject to the Freedom of Information Act (FOIA) and may be
> disclosed to third parties.*​
>



-- 
Doug Newcomb
USFWS
551F Pylon Dr
Raleigh, NC
919-856-4520 ext. 14 doug_newc...@fws.gov
-

*NOTE: This email correspondence and any attachments to and from this
sender is subject to the Freedom of Information Act (FOIA) and may be
disclosed to third parties.*​
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [EXTERNAL] GRASS and Anaconda

[Newcomb, Doug]

Just glancing over the recipe, it does not look like liblas and laszip are
included for LiDAR analysis.

Doug

On Thu, Jun 7, 2018 at 2:39 PM, Michael Barton 
wrote:

> Along with helping me set up a new way to compile and package GRASS
> binaries for the Mac, Eric Hutton of the Community Surface Dynamics
> Modeling System (CSDMS – http//csdms.colorado.edu) has created a Conda
> recipe for building GRASS in the Anaconda environment. This is now deployed
> in the csdms stack at GitHub. Several versions of GRASS, for Linux and Mac
> are available. Details and instructions for building GRASS with Anaconda
> can be found at:
>
>
>
> https://github.com/csdms-stack/grass-recipe
>
>
>
> Many thanks to Eric and CSDMS
>
>
>
> Happy GRASSing!
>
> Michael
>
>
>
> __
>
> C. Michael Barton
>
> Director, Center for Social Dynamics & Complexity
>
> Professor of Anthropology, School of Human Evolution & Social Change
>
> Head, Graduate Faculty in Complex Adaptive Systems Science
>
> Arizona State University
>
> Tempe, AZ  85287-2402
>
> USA
>
>
>
> voice:480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
>
> fax:  480-965-7671(SHESC), 480-727-0709 (CSDC)
>
> www:  http://csdc.asu.edu, http://shesc.asu.edu
>
> http://www.public.asu.edu/~cmbarton
>
>
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>



-- 
Doug Newcomb
USFWS
551F Pylon Dr
Raleigh, NC
919-856-4520 ext. 14 doug_newc...@fws.gov
-

*NOTE: This email correspondence and any attachments to and from this
sender is subject to the Freedom of Information Act (FOIA) and may be
disclosed to third parties.*​
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [EXTERNAL] [GRASS GIS] #3560: r.in.lidar: error to open valid LAZ file

[Newcomb, Doug]

On Wed, May 9, 2018 at 4:02 PM, Markus Neteler <nete...@osgeo.org> wrote:

> On Wed, May 9, 2018 at 9:37 PM, Newcomb, Doug <doug_newc...@fws.gov>
> wrote:
> > On Wed, May 9, 2018 at 3:21 PM, Markus Neteler <nete...@osgeo.org>
> wrote:
> >>
> >> Doug,
> >>
> >> On Wed, May 9, 2018 at 9:17 PM, Newcomb, Doug <doug_newc...@fws.gov>
> >> wrote:
> >> > Markus,
> >> > Liblas reads LAS version 1.2 , which is limited to 4.2 billion points.
> >>
> >> I see. But "count" states 297.683.873 which is way less points?
> >
> > Good question
> >
> >> > You have to compile liblas with an older version of laszip .
> >>
> >> Uhm, why an _older_ version?
> >
> > The API to LASzip changed with version 3.   I use LASzip 2.2.0 compiled
> with
> > liblas from 2013 and have no problems so far.   https://laszip.org/ The
> most
> > recent version of 3  was for version 1.4 of the LAS spec.
> >
> > You need to compile current pdal and current  liblas with different
> versions
> > of the Laszip library .
>
> On that machine is PDAL-1.7.0 (wit patches) which requires laszip 3.2.x.
>
> So, to compile liblas with an older laszip would be tricky.
>

On the machine I am using for this  , I have compiled the old laszip as the
system laszip library and compile but do not install the newer one.  I then
point pdal to the directory with the newer version when compiling it.  So
far, that seems to work.


>
> > pdal used to output version 1.2 of las data by default . I t worked fine
> for
> > me at version 1.6 . I have not checked if that is the case with version
> > 1.7.1 .  1.7 had a bug which required a quick bugfix to 1.7.1, by the
> way. (
> > I do not recall the bug off of the top of my head.)
>
> The solution would be the implementation of r.in.pdal:
> https://trac.osgeo.org/grass/ticket/3515


>
> to get rid of liblas which is not developed any more.


> And/or package laz-perf sigh, so many hours already spent on
> packaging...
>
> Markus
>
>
Doug

-- 
Doug Newcomb
USFWS
551F Pylon Dr
Raleigh, NC
919-856-4520 ext. 14 doug_newc...@fws.gov
-

*NOTE: This email correspondence and any attachments to and from this
sender is subject to the Freedom of Information Act (FOIA) and may be
disclosed to third parties.*​
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [EXTERNAL] [GRASS GIS] #3560: r.in.lidar: error to open valid LAZ file

[Newcomb, Doug]

On Wed, May 9, 2018 at 3:21 PM, Markus Neteler <nete...@osgeo.org> wrote:

> Doug,
>
> On Wed, May 9, 2018 at 9:17 PM, Newcomb, Doug <doug_newc...@fws.gov>
> wrote:
> > Markus,
> > Liblas reads LAS version 1.2 , which is limited to 4.2 billion points.
>
> I see. But "count" states 297.683.873 which is way less points?
>
Good question


>
> > You have to compile liblas with an older version of laszip .
>
> Uhm, why an _older_ version?
>

The API to LASzip changed with version 3.   I use LASzip 2.2.0 compiled
with liblas from 2013 and have no problems so far.   https://laszip.org/
The most recent version of 3  was for version 1.4 of the LAS spec.

You need to compile current pdal and current  liblas with different
versions of the Laszip library .


> thanks
> Markus
>
>
pdal used to output version 1.2 of las data by default . I t worked fine
for me at version 1.6 . I have not checked if that is the case with version
1.7.1 .  1.7 had a bug which required a quick bugfix to 1.7.1, by the way.
( I do not recall the bug off of the top of my head.)




Doug




-- 
Doug Newcomb
USFWS
551F Pylon Dr
Raleigh, NC
919-856-4520 ext. 14 doug_newc...@fws.gov
-

*NOTE: This email correspondence and any attachments to and from this
sender is subject to the Freedom of Information Act (FOIA) and may be
disclosed to third parties.*​
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [EXTERNAL] [GRASS GIS] #3560: r.in.lidar: error to open valid LAZ file

[Newcomb, Doug]

Markus,
Liblas reads LAS version 1.2 , which is limited to 4.2 billion points.  You
have to compile liblas with an older version of laszip .

Doug

On Wed, May 9, 2018 at 3:05 PM, GRASS GIS  wrote:

> #3560: r.in.lidar: error to open valid LAZ file
> +-
>  Reporter:  neteler |  Owner:  grass-dev@…
>  Type:  defect  | Status:  new
>  Priority:  normal  |  Milestone:  7.4.1
> Component:  Raster  |Version:  svn-releasebranch74
>  Keywords:  r.in.lidar  |CPU:  Unspecified
>  Platform:  All |
> +-
>  We currently fail to import a larger LiDAR file (LAZ)
>
>  {{{
>  pdal info dom1l_fp_tr_gebiet.laz > meta.txt
>  head -n 300 meta.txt
>  {
>"filename": "dom1l_fp_tr_gebiet.laz",
>"pdal_version": "1.7.0 (git-version: Release)",
>"stats":
>{
>  "bbox":
>  {
>"EPSG:4326":
>{
>  "bbox":
>  {
>"maxx": 7.311614961,
>"maxy": 50.83646173,
>"maxz": 344.69,
>"minx": 7.196437705,
>"miny": 50.78981976,
>"minz": 56.12
>  },
>  "boundary": {
>  "coordinates" :
>  [
>  [
>  [
>  7.198168120001,
>  50.78981976
>  ],
>
>  ...
> "statistic":
>  [
>{
>  "average": 377073.6011,
>  "count": 297683873,
>  "kurtosis": -4.436009717e+18,
>  "maximum": 381000,
>  "minimum": 373000,
>  "name": "X",
>  "position": 0,
>  "skewness": 5.047057151e+17,
>  "stddev": 1853.891145,
>  "variance": 3436912.377
>},
>  }}}
>
>  This file was created with "pdal merge" from several LAZ tiles.
>
>  Now, the import fails without any specific explanation:
>
>  {{{
>  GRASS 7.4.1svn (lidar):/scratch/kaldauen_klassifikation >
>
>  r.in.lidar imput=dom1l_fp_tr_gebiet.laz out=bla
>  FEHLER: Unable to open file 
>  as a LiDAR point cloud
>
>  g.gisenv set="DEBUG=3"
>  r.in.lidar imput=dom1l_fp_tr_gebiet.laz out=bla
>  D1/3: G_set_program_name(): r.in.lidar
>  D2/3: G_file_name(): path = /home/mundialis/grassdata/lidar/anika
>  D2/3: G_file_name(): path = /home/mundialis/grassdata/
> lidar/anika/cell/bla
>  D2/3: G_file_name(): path = /home/mundialis/grassdata/lidar/anika/WIND
>  D2/3: G_file_name(): path = /home/mundialis/grassdata/lidar/anika/WIND
>  D2/3: file open: read (mode = r)
>  D2/3: G__read_Cell_head
>  D2/3: G__read_Cell_head_array
>  D3/3: region item: proj:   99
>  D3/3: region item: zone:   0
>  D3/3: region item: north:  5631000
>  D3/3: region item: south:  5628000
>  D3/3: region item: east:   379002
>  D3/3: region item: west:   375000
>  D3/3: region item: cols:   1334
>  D3/3: region item: rows:   1000
>  D3/3: region item: e-w resol:  3
>  D3/3: region item: n-s resol:  3
>  D3/3: region item: top:1.000
>  D3/3: region item: bottom: 0.000
>  D3/3: region item: cols3:  1334
>  D3/3: region item: rows3:  1000
>  D3/3: region item: depths: 1
>  D3/3: region item: e-w resol3: 3
>  D3/3: region item: n-s resol3: 3
>  D3/3: region item: t-b resol:  1
>  FEHLER: Unable to open file 
>  as a LiDAR point cloud
>  D1/3: G_set_program_name(): g.gisenv
>  D3/3: G_option_to_separator(): key = separator -> sep = '/'
>  }}}
>
>  To be sure, a check if liblas was compiled with LAZ support:
>
>  {{{
>  ldd `which r.in.lidar`
>  linux-vdso.so.1 (0x7fff91df4000)
>  libgrass_raster.7.4.1svn.so =>
>  /home/mundialis/software/grass74_svn/dist.x86_64-pc-linux-
>  gnu/lib/libgrass_raster.7.4.1svn.so  0x7f225909b000)
>  libgrass_gis.7.4.1svn.so =>
>  /home/mundialis/software/grass74_svn/dist.x86_64-pc-linux-
>  gnu/lib/libgrass_gis.7.4.1svn.so (0x7f2258e42000)
>  libm.so.6 => /lib64/libm.so.6 (0x7f2258af7000)
>  libgrass_gproj.7.4.1svn.so =>
>  /home/mundialis/software/grass74_svn/dist.x86_64-pc-linux-
>  gnu/lib/libgrass_gproj.7.4.1svn.so (0x7f22588ec000)
>  liblas.so.3 => /lib64/liblas.so.3 (0x7f225862b000)
>  liblas_c.so.3 => /lib64/liblas_c.so.3 (0x7f22583f4000)
>  libboost_program_options.so.1.64.0 =>
>  /lib64/libboost_program_options.so.1.64.0 (0x7f2258179000)
>  ...
>  libboost_regex.so.1.64.0 => /lib64/libboost_regex.so.1.64.0
>  (0x7f225454c000)
>  libstdc++.so.6 => /lib64/libstdc++.so.6 (0x7f22541c5000)
>  libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7f2253fae000)
>  librt.so.1 => /lib64/librt.so.1 (0x7f2253da6000)
>  libpthread.so.0 => /lib64/libpthread.so.0 (0x7f2253b88000)
>  libarmadillo.so.7 => /lib64/libarmadillo.so.7 (0x7f225397f000)
>  libpoppler.so.68 => /lib64/libpoppler.so.68 

Re: [GRASS-dev] [EXTERNAL] Helena Mitasova awarded 2018 Waldo-Tobler GIScience Prize

[Newcomb, Doug]

Congratulations Helena!

Doug

On Tue, Apr 3, 2018 at 5:25 PM, Markus Neteler  wrote:

> https://gi-science.blogspot.com/2018/04/helena-mitasova-
> awarded-2018-waldo.html
>
> "The Austrian Academy of Sciences through its Commission for GIScience is
> awarding the GIScience Prize named after Prof Waldo Tobler to a scientist
> having demonstrated outstanding and sustained contributions to the
> discipline worthy of inspiring young scientists in Geoinformatics and
> Geographic Information Science, and having accomplished significant
> advances in research and education.
>
> The received nominations were reviewed and assessed by an external panel
> of peers, who unanimously recommended to award the 2018 prize to Prof
> Helena Mitasova (North Carolina State University).
> "
>
> Congratulations, Helena!!
>
> Best wishes,
> Markus
>
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>



-- 
Doug Newcomb
USFWS
551F Pylon Dr
Raleigh, NC
919-856-4520 ext. 14 doug_newc...@fws.gov
-

*NOTE: This email correspondence and any attachments to and from this
sender is subject to the Freedom of Information Act (FOIA) and may be
disclosed to third parties.*​
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [EXTERNAL] Re: PROJ 5 support in trunk

[Newcomb, Doug]

Thank you for this work!

Doug

On Fri, Mar 23, 2018 at 5:55 AM, Moritz Lennert <
mlenn...@club.worldonline.be> wrote:

> On 23/03/18 10:41, Markus Metz wrote:
>
>> Now (last related commit is trunk r72522) it's finished. I have
>> introduced a new GRASS API that handles both PROJ 4 and PROJ 5, consisting
>> of
>>
>> GPJ_init_transform() (new, initializes coordinate transformation)
>> GPJ_transform() replacing pj_do_proj()
>> GPJ_transform_array() replacing pj_do_transform()
>>
>> The old GRASS API is still there but is no longer used by core modules.
>>
>> Only few ifdefs in lib/proj are needed for different PROJ versions.
>> Modules do not need any ifdefs, they can simply call GPJ_init_transform() +
>> GPJ_transform() without caring about the PROJ API.
>>
>> As soon as PROJ 5.0.1 is out, I would like to drop support for PROJ 5.0.0
>> and only support PROJ 4 and PROJ 5.0.1 or higher (learning from GDAL :-)).
>>
>
> Wow ! Congratulations and thank you for all this hard work !!
>
> Moritz
>
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>



-- 
Doug Newcomb
USFWS
551F Pylon Dr
Raleigh, NC
919-856-4520 ext. 14 doug_newc...@fws.gov
-

*NOTE: This email correspondence and any attachments to and from this
sender is subject to the Freedom of Information Act (FOIA) and may be
disclosed to third parties.*​
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSOC 2018 project for GRASS GIS

[Newcomb, Doug]

Sanjeet,
Spotted this the other day if it helps.

https://medium.com/@boxed/moving-a-large-and-old-codebase-to-python3-33a5a13f8c99

Doug

On Tue, Mar 6, 2018 at 4:38 AM, Margherita Di Leo 
wrote:

>
>
> On Tue, Mar 6, 2018 at 5:37 AM, Sanjeet  wrote:
>
>> On Sat, Mar 3, 2018 at 10:50 PM, Anna Petrášová 
>> wrote:
>> > Basically, the GUI is mostly ported to work with wxPython4 (phoenix),
>> > which is (unlike wxpython 3) Python 3 ready. So far we are running the
>> > GUI on Python 2.7 only. There are some loose ends and depreciation
>> > warnings, which would be nice to get rid of. Since we need to keep
>> > backwards compatibility with wxpython 3, we wrapped some GUI classes
>> > (gui/wxpython/gui_core/wrap.py), so you can start there. You need to
>> > test your changes under both wxpython 3 and 4. Let me know if you need
>> > more clarification. More info what is Attribute Table manager:
>> >
>> > https://grass.osgeo.org/grass75/manuals/wxGUI.dbmgr.html
>> > https://grasswiki.osgeo.org/wiki/WxGUI_Attribute_Table_Manager
>>
>> Hi Anna,
>>
>> I've created a patch file for the ticket #3510.
>>
>> > To post a patch in that ticket, you need to get osgeo id:
>> > https://www.osgeo.org/community/getting-started-osgeo/osgeo_userid/
>>
>> I'm waiting for 'mantra' to create the osgeo user id, so that I can
>> upload the patch file.
>>
>
> What's your username?
>
>>
>
>
> --
> Margherita Di Leo
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>



-- 
Doug Newcomb
USFWS
551F Pylon Dr
Raleigh, NC
919-856-4520 ext. 14 doug_newc...@fws.gov
-

*NOTE: This email correspondence and any attachments to and from this
sender is subject to the Freedom of Information Act (FOIA) and may be
disclosed to third parties.*​
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3485: Introduce a new 64-bit integer raster data type

[Newcomb, Doug]

Yes!

On Mon, Jan 29, 2018 at 4:08 AM, GRASS GIS  wrote:

> #3485: Introduce a new 64-bit integer raster data type
> ---+-
>  Reporter:  mlennert   |  Owner:  grass-dev@…
>  Type:  enhancement| Status:  new
>  Priority:  normal |  Milestone:  8.0.0
> Component:  LibRaster  |Version:  svn-trunk
>  Keywords:  raster 64-bit  |CPU:  Unspecified
>  Platform:  Unspecified|
> ---+-
>  From #3084:
>
>  "Most importantly, a GRASS raster format for 64-bit signed integer. Note
>  that GDAL does not support 64-bit signed or unsigned integers. The reason
>  is probably that a portable implementation of 64-bit integers is not so
>  easy. Regarding GRASS raster processing, the need for 64-bit integers
>  usually arises only for raster maps with more than 2,147,483,647 cells
>  which in turn usually requires Large File Support (LFS). Therefore the
>  check for the availability of a 64-bit integer could be coupled to LFS. If
>  support for 64-bit signed integer raster maps (say, LCELL) could be added
>  to GRASS, users would need to stick to GRASS since GDAL raster export of
>  64-bit integers is not available. Interesting idea."
>
>  and
>
>  "As of r68944, i.segment supports regions with more than 2,147,483,647
>  cells, but the number of final objects must not exceed 2,147,483,647. This
>  can only be solved by introducing a new 64 bit integer data type in
>  addition to CELL, FCELL, DCELL, something for GRASS 8 maybe."
>
> --
> Ticket URL: 
> GRASS GIS 
>
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>



-- 
Doug Newcomb
USFWS
551F Pylon Dr
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.
*NOTE: This email correspondence and any attachments to and from this
sender is subject to the Freedom of Information Act (FOIA) and may be
disclosed to third parties.*​
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] List of tutorials

[Newcomb, Doug]

There is also the list here:
https://grasswiki.osgeo.org/wiki/GRASS_Documents#GRASS_tutorials

Doug

On Sun, Dec 17, 2017 at 10:59 AM, Paulo van Breugel 
wrote:

>
> On 12/17/17 4:57 PM, Markus Neteler wrote:
>
>> On Sun, Dec 17, 2017 at 10:19 AM, Paulo van Breugel
>>  wrote:
>>
>>> Hi devs,
>>>
>>> I think it is important to have a good and curated list of tutorials on
>>> the
>>> main grass gis website. The current list with tutorials on
>>> https://grass.osgeo.org/documentation/tutorials/ is not very complete,
>>> and
>>> does include old tutorials. What about adding a form to the page, where
>>> people can fill in tutorials and courses? Then there would still be
>>> somebody
>>> that needs to add (or remove) them to the list (I wouldn't mind doing
>>> that).
>>> An alternative would be to link directly to a dedicated page on the GRASS
>>> GIS wiki?
>>>
>> I'd suggest to make it a Wiki page to which we then link from the Web
>> site.
>>
>> Paulo, would  you be willing to start that?
>>
>
> Yes, sure. Will make something in the coming week
>
>
>
>> thanks,
>> Markus
>>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>



-- 
Doug Newcomb
USFWS
551F Pylon Dr
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.
*NOTE: This email correspondence and any attachments to and from this
sender is subject to the Freedom of Information Act (FOIA) and may be
disclosed to third parties.*​
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Deactivate lidar modules in winGRASS?c

[Newcomb, Doug]

On Thu, Dec 14, 2017 at 10:43 AM, Helmut Kudrnovsky  wrote:

> Helmut Kudrnovsky wrote
> > deactivated now lidar modules in winGRASS 32bit and 64bit by:
> >
> > [GRASS-SVN] r71920 - grass/trunk/mswindows/osgeo4w   svn_grass at
> > osgeo.org
> > [GRASS-SVN] r71921 - grass/branches/releasebranch_7_4/mswindows/osgeo4w
> > svn_grass at osgeo.org
> > [GRASS-SVN] r71922 - grass/trunk/mswindows/osgeo4w   svn_grass at
> > osgeo.org
> > [GRASS-SVN] r71923 - grass/branches/releasebranch_7_2/mswindows/osgeo4w
> > svn_grass at osgeo.org
> >
> > in a mid term, a fix of the liblas/libzip tools in OSGeo4W is needed.
>
> taken from the related OSGeo4W ticket:
>
> ---
> hobu:
>
> This was caused by me. I updated LASzip, but libLAS hasn't been updated to
> use the new LASzip API. You'll have to revert to the LASzip 2.2.0 version
> to
> use libLAS
> --
>
> the winGRASS build environment there are 2 choices now:
>
> - compilation works with the the buggy liblas/laszip due to my fixes above,
> though no lidar modules
> - build environment reverts back to the LASzip 2.2.0 version to use libLAS
>
> I think the latter course of action is better in the short term.  Howard,
Would this affect other software?

Doug





>
>
>
> -
> best regards
> Helmut
> --
> Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>



-- 
Doug Newcomb
USFWS
551F Pylon Dr
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.
*NOTE: This email correspondence and any attachments to and from this
sender is subject to the Freedom of Information Act (FOIA) and may be
disclosed to third parties.*​
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Deactivate lidar modules in winGRASS?c

[Newcomb, Doug]

Helmet,
I have folks using those programs to do binning analysis of LiDAR data on
Windows.  Not that I know how to fix that, but what needs to be done?

Doug

On Sun, Dec 10, 2017 at 1:23 PM, Helmut Kudrnovsky  wrote:

> Helmut Kudrnovsky wrote
> > looking at
> >
> > https://wingrass.fsv.cvut.cz/grass75/x86_64/logs/log-r71915-25/error.log
> >
> > Started compilation: Sat Dec  9 21:35:30 2017
> > --
> > Errors in:
> > /c/msys64/usr/src/grass_trunk/raster/r.in.lidar
> > /c/msys64/usr/src/grass_trunk/raster3d/r3.in.lidar
> > /c/msys64/usr/src/grass_trunk/vector/v.out.lidar
> > /c/msys64/usr/src/grass_trunk/vector/v.in.lidar
> > --
> >
> > lidar tools are already deactivated in winGRASS 32bit, now it seems also
> > winGRASS 64bit affected.
> >
> > have seen the same error on a local 64bit compilation.
>
> [sorry pushed the post button too early]
>
> see related OSGeo4W ticket:
>
> https://trac.osgeo.org/osgeo4w/ticket/550
>
> should we deactivate lidar tools also in winGRASS 64bit as long the OSGeo4W
> ticket unsolved.
>
> it breaks at the moment winGRASS 64 bit on the build server.
>
>
>
>
> -
> best regards
> Helmut
> --
> Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>



-- 
Doug Newcomb
USFWS
551F Pylon Dr
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.
*NOTE: This email correspondence and any attachments to and from this
sender is subject to the Freedom of Information Act (FOIA) and may be
disclosed to third parties.*​
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Adding an expert mode to the parser

[Newcomb, Doug]

+1

On Mon, Sep 26, 2016 at 6:11 PM, Vaclav Petras  wrote:

>
> On Fri, Sep 23, 2016 at 5:22 PM, Markus Neteler  wrote:
>
>> * various commands: "Use the low-memory version" - also more advanced
>
>
> I guess this is a typical example where we need to be careful. I can
> imagine a situation when a beginner has a lot of data and low-end hardware.
> By hiding an parameter like this, we would make it even more advanced. Now
> you not only need to understand that your hardware is not enough and that
> the algorithm should somehow account for that. You also need to know that
> there might be a hidden option for that and you need to know how to find
> it. Having this in the manual or even a Memory or Speed tab in the GUI,
> gives some hope that even a beginner will be able to use it.
>
> ___
> 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?

[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] Memory use in v.in.lidar for points with attributes

[Newcomb, Doug]

v.lidar.mcc seems to be running fine without attributes or topology.  Not
sure why I thought it needed a regular point vector layer.  Sorry for the
noise.

Doug

On Fri, Jul 22, 2016 at 11:27 AM, Moritz Lennert <
mlenn...@club.worldonline.be> wrote:

> On 22/07/16 16:05, Newcomb, Doug wrote:
>
>> Hi Folks,
>> My goal is to import a LiDAR point cloud from an LAS file with 152
>> million points.  I would like to use v.lidar.mcc to extract bare earth
>> points from the point cloud for generating a DEM  However, v.lidar.mcc
>> requires that the point layer have an attribute table
>>
>
> Are you sure ? The example in the v.lidar.mcc man page says:
>
> v.in.lidar -tr input=points.las output=points
> v.lidar.mcc points ground=ground_points nonground=non_ground_points
>
> the -t in v.in.lidar means "Do not create attribute table".
>
> > rather than just
> > the raw x,y,z points without topography.
>
> Do you mean topology ?
>
> Attribute table and topology are two seperate issues.
>
>
>> So using v.in.lidar, I am importing  the lidar points as normal points,
>> and the memory usage is steadily climbing.  Less than 1/4 of the points
>> are imported and memory usage is at 5GB . This on a Windows 7 64 bit
>> system with GRASS 7.2 svn
>>
>> I'm suspecting this is not the expected behavior.
>>
>
> I would say that it is expected. YMMMV with different database backends,
> but attribute handling can be memory-heavy.
>
> What does v.in.lidar -t give you ?
>
> If some attribute really need to be conserver, maybe this a good case to
> test Vaclav's additions to v.in.lidar, storing attributes as cat values,
> instead of attributes in a table:
>
> https://lists.osgeo.org/pipermail/grass-dev/2015-September/076490.html
> https://trac.osgeo.org/grass/changeset/66343
>
> Moritz
>



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

[GRASS-dev] Memory use in v.in.lidar for points with attributes

[Newcomb, Doug]

Hi Folks,
My goal is to import a LiDAR point cloud from an LAS file with 152 million
points.  I would like to use v.lidar.mcc to extract bare earth points from
the point cloud for generating a DEM  However, v.lidar.mcc requires that
the point layer have an attribute table rather than just the raw x,y,z
points without topography.

So using v.in.lidar, I am importing  the lidar points as normal points, and
the memory usage is steadily climbing.  Less than 1/4 of the points are
imported and memory usage is at 5GB . This on a Windows 7 64 bit system
with GRASS 7.2 svn

I'm suspecting this is not the expected behavior.

Doug

-- 
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] is it time to release GRASS71?

[Newcomb, Doug]

+1

On Thu, Feb 25, 2016 at 2:56 PM, Markus Neteler  wrote:

>
> On Feb 25, 2016 5:05 PM, "Vaclav Petras"  wrote:
> >
> >
> > On Thu, Feb 25, 2016 at 10:00 AM, Martin Landa 
> wrote:
> >>
> >> this system is used also by QGIS, MapServer, moreover it's part of
> >> GRASS history (with one exception - 6.3). I have no strong option
> >> about that. I would say let's follow our tradition to use odd numbers
> >> for dev versions. Martin
> >
> >
> >
> > The fact that other OSGeo projects are using it is quite convincing. But
> anyway, I don't see a point in simply skipping a version number.
>
> Well, we are using 7.1 visibly for so long as unstable/dev version.
> So it sounds perfectly fine to call the result 7.2.
>
> Markus
>
> ___
> 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] GSoC 2016 Ideas page

[Newcomb, Doug]

With the increasing importance of LiDAR data,  would the inclusion of
vertical datums in the GRASS projection model be something to start
thinking about?

Doug

On Tue, Feb 16, 2016 at 7:44 AM, Moritz Lennert <
mlenn...@club.worldonline.be> wrote:

> I've taken the liberty to create
>
> https://trac.osgeo.org/grass/wiki/GSoC/2016
>
> I just took over the ideas from the 2015 page (except for the metadata
> which has already been subject of two GSoCs).
>
> Please everyone review the existing proposals, possibly amending/deleting
> your old proposals, adding new ones and adding yourself as mentor or
> co-mentor.
>
> Moritz
>
>
>
> On 16/02/16 11:23, Margherita Di Leo wrote:
>
>>
>> -- Forwarded message --
>> From: *Margherita Di Leo* > >>
>> Date: Tue, Feb 16, 2016 at 11:16 AM
>> Subject: [@Mentors: Action required] GSoC 2016 Ideas page
>> To: OSGeo Discussions > >, OSGeo-SoC > >
>> Cc: Anne Ghisla >
>>
>>
>> Dear All,
>>
>>
>> we would like to inform you all that we have applied on behalf of OSGeo,
>> as a mentor organization for Google Summer of Code 2016. The application
>> can be found at [1]. We ask your cooperation to set up the ideas page
>> within few days. It is extremely important that the ideas page looks in
>> good shape as it is the key page Google will be looking at when
>> evaluating OSGeo. As usual, each community will set up its ideas page on
>> its own wiki and will send us the link, that will be added by us to the
>> main page [2]. Please forward this email to your communities.
>>
>> As past years, OSGeo welcomes like minded projects that wish to
>> participate under the org’s umbrella, not being official OSGeo projects.
>> Please contact us to discuss it further.
>>
>>
>> Your OSGeo GSoC 2016 Admins
>>
>> Margherita Di Leo (madi)
>>
>> Anne Ghisla (aghisla)
>>
>>
>> [1] https://wiki.osgeo.org/wiki/Google_Summer_of_Code_Application_2016
>>
>> [2] https://wiki.osgeo.org/wiki/Google_Summer_of_Code_2016_Ideas
>>
>>
>>
>> --
>> Margherita Di Leo
>>
>>
>> ___
>> 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] wingrass daily buidls + addons temporary down

[Newcomb, Doug]

r67403_x86_64.exe starts fine on Windows 7 64 bit

Doug

On Tue, Dec 29, 2015 at 11:02 AM, Anna Petrášová 
wrote:

> Hi,
>
> On Thu, Dec 17, 2015 at 11:04 AM, Martin Landa 
> wrote:
>
>> Hi,
>>
>> 2015-12-17 14:51 GMT+01:00 Helmut Kudrnovsky :
>> > 7.0.2 32 bit (old mingw tool chain) -> 7.1.svn 32 bit (new mingw2 tool
>> > chain) -> 7.1.svn 64 bit (new mingw2 tool chain)
>>
>> please try to compare 7.0.2 vs 7.0.3svn (32bit and 64bit) [1,2]. Thanks,
>> Martin
>>
>
>
> I was wondering, are the latest 64bit binaries (standalone) working for
> anyone? For me GRASS fails to start, basically any command segfaults.
> I tried r67314 and r67403 and both fail.
>
> Thanks
>
> Anna
>
>>
>> [1] http://wingrass.fsv.cvut.cz/x86/grass70/
>> [2] http://wingrass.fsv.cvut.cz/x86_64/grass70/
>>
>> --
>> 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 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] wingrass daily buidls + addons temporary down

[Newcomb, Doug]

Great!  Thank you for your continued efforts.

Doug


On Fri, Dec 11, 2015 at 11:20 AM, Martin Landa 
wrote:

> Hi all,
>
> winGRASS daily builds and addons (http://wingrass.fsv.cvut.cz) will be
> temporary down due to moving building environment from mingw to
> mingw-w64. Please stay tuned.
>
> 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




-- 
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.lidar: read multiple LAS files in one run

[Newcomb, Doug]

Vaclav,

I have successfully  processed  a county with 966 laz files with well over
4.2 billion points, using a base elevation raster with 2.4 billion pixels (
Hyde county, NC  5 ft resolution DEM , about half water).  It is a bit
slower, but it does solve several of my issues.  Well done!

Will this be backported to 7.0 ?  :-)

Doug

On Mon, Oct 26, 2015 at 3:00 PM, Vaclav Petras <wenzesl...@gmail.com> wrote:

>
> On Mon, Oct 26, 2015 at 1:20 PM, Newcomb, Doug <doug_newc...@fws.gov>
> wrote:
>
>> multiple files at the 4.2 point las 1.2 limit! I can live with slow, just
>> concerned about the memory demands working with larger areas.
>
>
> The processing goes by row chunks. By default everything is in the memory.
> You can say that only half of rows will be in the memory at a time by
> percent=50 (you have to guess how much memory it will take). It will be
> (much) slower because it will iterate over the files (twice in this case).
> I was not able to do any tests with large amounts of points but the only
> problem will be capacity of some counters for percentage and report. The
> actual processing takes one point at a time, so there shouldn't be any
> limit. This is by the way still the same as before, I haven't changed
> anything in the way how this is handled. Let me know if this doesn't
> address your concerns.
>



-- 
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] Planning of 7.0.2 release

[Newcomb, Doug]

"Import of common formats with reprojection"  sounds better to me.


Doug

On Fri, Oct 30, 2015 at 4:42 AM, Markus Neteler  wrote:

> On Fri, Oct 30, 2015 at 2:12 AM, Anna Petrášová 
> wrote:
> ...
> > The label should be changed to 'Import common formats' and the name of
> tag
> > would be ImportCommonRasterFormat and ImportCommonVectorFormat.
>
> Any native speaker out there?
> I'm still not convinced of
> "Common formats import with reprojection"
>
> and would suggest
> "Import of common formats with reprojection"
>
> (even if reprojection not always applies)
>
> ?
> Markus
> ___
> 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.lidar: read multiple LAS files in one run

[Newcomb, Doug]

Vaclav,

I cannot wait to try this with multiple files at the 4.2 point las 1.2
limit! I can live with slow, just concerned about the memory demands
working with larger areas.

Thank you very much!

Doug







On Mon, Oct 26, 2015 at 11:28 AM, Vaclav Petras 
wrote:

> Hi all,
>
> r.in.lidar in trunk (r66601) can now read multiple LAS files specified in
> a text file (similarly to what e.g. r.colors supports for raster maps). It
> is nothing fancy, no indexing or something, but you can bin point from
> several tiles without any edge effects. It is not particularly fast either,
> but it is not worse than the original code.
>
> Here is an example with custom resolution and extent derived from the data:
>
> r.in.lidar file=list.txt output=raster method=mean -e res=30 zrange=-1,200
>
> The file list.txt contains something like:
>
> /home/johnuser/data/tile_55.las
> /home/johnuser/data/tile_56.las
> /home/johnuser/data/tile_57.las
>
> A major refactoring of the code (r66593-r66596) was necessary for smooth
> implementation. I did my best to test different combination of parameters
> with comparison to original results, but I was not able to create an
> automated test partially for the lack of standardized input data. More
> testing appreciated.
>
> The options and tabs were reorganized to accommodate new inputs, but the
> documentation is missing.
>
> Let me know what you think.
>
> Vaclav
>
>
> https://grass.osgeo.org/grass71/manuals/r.in.lidar.html
> https://trac.osgeo.org/grass/changeset/66601
> https://trac.osgeo.org/grass/changeset/66593
> https://trac.osgeo.org/grass/changeset/66594
> https://trac.osgeo.org/grass/changeset/66595
> https://trac.osgeo.org/grass/changeset/66596
>
> ___
> 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.lidar: height above ground

[Newcomb, Doug]

Thanks!  Will try it out!

Doug

On Sun, Oct 11, 2015 at 12:55 AM, Vaclav Petras 
wrote:

> Hi all,
>
> On Tue, Sep 8, 2015 at 11:54 PM, Vaclav Petras 
> wrote:
>
>> With the resolution option one case change the resolution of the output
>> while using computational region to set extent and resolution of the base
>> raster. However, after discussion with Doug, I see that it makes more sense
>> to match the output to the region, which can be nicely set beforehand to
>> align with some other raster. If this resolution would low (coarse) - we do
>> binning - it makes sense to use the input base raster at higher (finer)
>> resolution, the original resolution of the data is a clear choice. I'm not
>> sure if this should be the default but probably not, since it would violate
>> the region behavior.
>>
>> As a result, r.in.lidar output would respect region, optionally modified
>> by resolution (current behavior) and the input would use the region as
>> well, unless a flag would be set. This flag would be something like -d "Use
>> the resolution of the input base raster when reading it instead of using
>> current region (cells aligned to the raster)".
>>
>
>
> I've added the flag to use base raster resolution instead of the
> computation region resolution in r66468 to trunk. It is not by default
> since the region should be respected by default (and that has its own use
> cases). I've used -d for flag, since I had no better idea (r, a, b are used
> in often used other contexts).
>
> There is no documentation yet, but there is a test on artificial data
> which looks good. I was testing this on real data, but I was able to see
> some bigger differences only with ratio of raster and region resolution
> about 1/30, so I was not able to check the result in detail in this case.
> More testing is appreciated.
>
> The implementation should handle the the cases when region extent and
> raster extent are different in some better way, but for cases when region
> is the same or little bit smaller than the base raster, it will work fine.
>
> Vaclav
>
> https://trac.osgeo.org/grass/changeset/66468
>
>
> ___
> 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] v.rast.stats disables MASK

[Newcomb, Doug]

+1 Agree.  I've run into this before

Doug

On Wed, Oct 7, 2015 at 1:05 AM, Maris Nartiss  wrote:

> This definitely needs a flag + explanation in documentation.
>
> Taking into account philosophy behind GRASS raster processing, I would
> say - default should be to apply MASK, as MASK affects all raster
> reading operations (unless stated otherwise or requested by user).
>
> Maris.
>
>
> 2015-10-06 19:15 GMT+03:00 Martin Landa :
> > 2015-10-06 18:13 GMT+02:00 Moritz Lennert  >:
> >> But this was a bug that you fixed in r66421, or ?
> >
> > yes, it was. I was just wondering why the module should ignore the
> > mask. It was answered. 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 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] PlanarRad ?

[Newcomb, Doug]

I wonder if this could be used in calculating light penetration through a
vegetative canopy?

Doug

On Tue, Sep 8, 2015 at 3:33 AM, Yann  wrote:

> Hi,
>
> anybody bridged PlanarRad to GRASS-GIS?
>
> http://www.planarrad.com/index.php?title=PlanarRad
>
> Cheers,
> Yann
>
> --
> -
> Mobile: +33 (0)7 83 85 52 34
>
> ___
> 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.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.in.lidar: height above ground

[Newcomb, Doug]

This feature will be greatly appreciated by anyone working with lidar and
vegetation.

Doug

On Thu, Sep 3, 2015 at 10:49 PM, Vaclav Petras  wrote:

> Hi,
>
> in r66094, I've added base raster map to r.in.lidar. When provided,
> r.in.lidar with subtract its values from the points' z values. In this way,
> one can get height about ground.
>
> Needs testing before general anouncement, so feel free to do so.
>
> Adding a simple suggestion how to do a benchmark or test.
>
> Vaclav
>
> https://trac.osgeo.org/grass/changeset/66094
>
> PS: Just now I realized that this should have been the commit with word
> news or feature or something for automatic extraction.
>
> ___
> 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.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] New Mac binaries uploaded

[Newcomb, Doug]

  mkdir makefiles
  cd makefiles
 
  export
 BOOST_ROOT=/Users/cmbarton/Dropbox/GRASS_dropbox/compiling/boost-snow
 
  cmake -G Unix Makefiles -D CMAKE_OSX_ARCHITECTURES=i386;x86_64 -D
 CMAKE_OSX_SYSROOT=/Developer/SDKs/MacOSX10.7.sdk ../
 
  ## fails because it can’t find geotiff libraries. But it does find
 geotiff libraries. So that’s weird. Also cannot find laszip. I can’t tell
 if this is required or optional. I didn’t need it before.
  ## here is the error…
 
  Searching for LASzip 2.0.1+ library
  -- Could NOT find LASzip (missing:  LASZIP_LIBRARY LASZIP_INCLUDE_DIR)
 (Required is at least version 2.0.1)
  -- Searching for GDAL 1.7.0+ library
  -- Found acceptable GDAL version 1.11.2
  -- Searching for GeoTIFF 1.2.5+ library
  -- Found GeoTIFF version: 1.4.0
  -- Could NOT find GeoTIFF (missing:  GEOTIFF_LIBRARY) (Required is at
 least version 1.2.5)
  CMake Error at CMakeLists.txt:262 (message):
   GDAL support requires GeoTIFF library which was not found
 
 
 
  So this is where I’m stuck currently. Any suggestions would be
 appreciated.
 
  Michael
 
 
  
  C. Michael Barton
  Director, Center for Social Dynamics  Complexity
  Professor of Anthropology, School of Human Evolution  Social Change
  Head, Graduate Faculty in Complex Adaptive Systems Science
  Arizona State University
 
  voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
  fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
  www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  On Aug 24, 2015, at 10:50 AM, Vaclav Petras wenzesl...@gmail.com
 wrote:
 
 
 
  On Mon, Aug 24, 2015 at 1:40 PM, Michael Barton 
 michael.bar...@asu.edu wrote:
  If I am understanding the compiling instructions correctly, it
 installs binaries of the open source LAStools and Liblas too. But I may
 misunderstand. The GRASS LAS tool set needs both I believe.
 
  GRASS GIS is fine just with the library. The expected library libLAS (
 http://www.liblas.org/) as far as I know.
 
  I'm not sure what open source LAStools would be, some of the
 LAStools are perhaps open source but some are definitively not. In any
 case, GRASS GIS does not depend on any tools -- the ones related to libLAS
 nor the ones related LASlib.
 
  Vaclav
 
 
  Michael
  
  C. Michael Barton
  Director, Center for Social Dynamics  Complexity
  Professor of Anthropology, School of Human Evolution  Social Change
  Head, Graduate Faculty in Complex Adaptive Systems Science
  Arizona State University
 
  voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
  fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
  www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  On Aug 24, 2015, at 10:29 AM, Newcomb, Doug doug_newc...@fws.gov
 wrote:
 
  Liblas or LASTools?
 
  Doug
 
  On Mon, Aug 24, 2015 at 1:08 PM, Michael Barton 
 michael.bar...@asu.edu wrote:
  Yes. The LAS tools are compiled for GDAL 1.10. They were a royal
 pain to compile. The instructions to the newest LAStools source code makes
 it sound like it is much easier now. Does anyone have any experience with
 the current version? I was going to try it but wanted to make sure I had a
 GRASS version out with at least a clunky working version before risking it.
 
  Michael
  
  C. Michael Barton
  Director, Center for Social Dynamics  Complexity
  Professor of Anthropology, School of Human Evolution  Social Change
  Head, Graduate Faculty in Complex Adaptive Systems Science
  Arizona State University
 
  voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
  fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
  www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  On Aug 24, 2015, at 9:56 AM, William Kyngesburye 
 wokl...@kyngchaos.com wrote:
 
  Michael, you may need to recompile your las tools to use the
 current GDAL, this is separate from GRASS compilation.
 
  On Aug 24, 2015, at 10:31 AM, Michael Barton 
 michael.bar...@asu.edu wrote:
 
  Anna,
 
  These work for me and at least some of my students here. So we
 need to find out why they don't work for you. I'm teaching spatial tech
 this fall and want to make sure others don't run into trouble. 7.0.1 was a
 completely fresh checkout and 7.1 was compiled after a make distclean.
 
  Do you have any idea what causes this error? Did you install a new
 gdal? I compiled with William's most current version. I am still using
 stock Mac Python and wx version 2.8.12. Have you installed anything newer
 in the testing I saw on the list?
 
  Michael Barton
  School of Human Evolution Social Change
  Center for Social Dynamics  Complexity
  Arizona State University
 
  ...Sent from my iPad
 
  On Aug 24, 2015, at 7:43 AM, Anna Petrášová kratocha...@gmail.com
 wrote:
 
  Hi Michael,
 
 
  sorry to report but the new binaries (70 and 71) don't work, the
 gui doesn't open with this error. I already saw this error multiple

Re: [GRASS-dev] New Mac binaries uploaded

[Newcomb, Doug]

Liblas or LASTools?

Doug

On Mon, Aug 24, 2015 at 1:08 PM, Michael Barton michael.bar...@asu.edu
wrote:

 Yes. The LAS tools are compiled for GDAL 1.10. They were a royal pain to
 compile. The instructions to the newest LAStools source code makes it sound
 like it is much easier now. Does anyone have any experience with the
 current version? I was going to try it but wanted to make sure I had a
 GRASS version out with at least a clunky working version before risking it.

 Michael
 
 C. Michael Barton
 Director, Center for Social Dynamics  Complexity
 Professor of Anthropology, School of Human Evolution  Social Change
 Head, Graduate Faculty in Complex Adaptive Systems Science
 Arizona State University

 voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
 fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
 www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu















  On Aug 24, 2015, at 9:56 AM, William Kyngesburye wokl...@kyngchaos.com
 wrote:
 
  Michael, you may need to recompile your las tools to use the current
 GDAL, this is separate from GRASS compilation.
 
  On Aug 24, 2015, at 10:31 AM, Michael Barton michael.bar...@asu.edu
 wrote:
 
  Anna,
 
  These work for me and at least some of my students here. So we need to
 find out why they don't work for you. I'm teaching spatial tech this fall
 and want to make sure others don't run into trouble. 7.0.1 was a completely
 fresh checkout and 7.1 was compiled after a make distclean.
 
  Do you have any idea what causes this error? Did you install a new
 gdal? I compiled with William's most current version. I am still using
 stock Mac Python and wx version 2.8.12. Have you installed anything newer
 in the testing I saw on the list?
 
  Michael Barton
  School of Human Evolution Social Change
  Center for Social Dynamics  Complexity
  Arizona State University
 
  ...Sent from my iPad
 
  On Aug 24, 2015, at 7:43 AM, Anna Petrášová kratocha...@gmail.com
 wrote:
 
  Hi Michael,
 
 
  sorry to report but the new binaries (70 and 71) don't work, the gui
 doesn't open with this error. I already saw this error multiple times and
 it might be enough just to make distclean and recompile or fresh svn
 checkout.
  GRASS 7.1.svn (loc_ncarolina_spm_base0.3.1):~  Traceback (most recent
 call last):
 
   File
 /Applications/GRASS-7.1.app/Contents/MacOS/gui/wxpython/wxgui.py, line
 140, in module
 
 sys.exit(main())
 
   File
 /Applications/GRASS-7.1.app/Contents/MacOS/gui/wxpython/wxgui.py, line
 132, in main
 
 app = GMApp(workspaceFile)
 
   File
 /Applications/GRASS-7.1.app/Contents/MacOS/gui/wxpython/wxgui.py, line
 46, in __init__
 
 wx.App.__init__(self, False)
 
   File
 /Applications/GRASS-7.1.app/Contents/MacOS/etc/python/wx/_core.py, line
 7981, in __init__
 
 self._BootstrapApp()
 
   File
 /Applications/GRASS-7.1.app/Contents/MacOS/etc/python/wx/_core.py, line
 7555, in _BootstrapApp
 
 return _core_.PyApp__BootstrapApp(*args, **kwargs)
 
   File
 /Applications/GRASS-7.1.app/Contents/MacOS/gui/wxpython/wxgui.py, line
 79, in OnInit
 
 from lmgr.frame import GMFrame
 
   File
 /Applications/GRASS-7.1.app/Contents/MacOS/gui/wxpython/lmgr/frame.py,
 line 50, in module
 
 from lmgr.layertreeimport LayerTree, LMIcons
 
   File
 /Applications/GRASS-7.1.app/Contents/MacOS/gui/wxpython/lmgr/layertree.py,
 line 37, in module
 
 from mapdisp.frameimport MapFrame
 
   File
 /Applications/GRASS-7.1.app/Contents/MacOS/gui/wxpython/mapdisp/frame.py,
 line 34, in module
 
 from vdigit.toolbarsimport VDigitToolbar
 
   File
 /Applications/GRASS-7.1.app/Contents/MacOS/gui/wxpython/vdigit/toolbars.py,
 line 30, in module
 
 from iclass.digit   import IClassVDigit
 
   File
 /Applications/GRASS-7.1.app/Contents/MacOS/gui/wxpython/iclass/digit.py,
 line 23, in module
 
 from vdigit.wxdisplay import DisplayDriver, TYPE_AREA
 
  ImportError: cannot import name TYPE_AREA
 
 
 
 
 
  Also, v.in.lidar or las2las (anything using liblas) doesn't work. I
 don't have GDAL 1.10, but 1.11.
 
  dyld: Library not loaded:
 /Library/Frameworks/GDAL.framework/Versions/1.10/GDAL
 
   Referenced from:
 /Applications/GRASS-7.1.app/Contents/MacOS/lib/liblas.2.2.0.dylib
 
   Reason: image not found
 
  Trace/BPT trap: 5
 
  If you don't have time to look at it now, could you please post the
 GRASS 7.0.0 binary which I believe worked.
 
 
  Thank you,
 
 
  Anna
 
 
  -
  William Kyngesburye kyngchaos*at*kyngchaos*dot*com
  http://www.kyngchaos.com/
 
  First Pogril: Why is life like sticking your head in a bucket filled
 with hyena offal?
  Second Pogril: I don't know.  Why IS life like sticking your head in a
 bucket filled with hyena offal?
  First Pogril: I don't know either.  Wretched, isn't it?
 
  -HitchHiker's Guide to the Galaxy

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

Re: [GRASS-dev] grass.osgeo.org contains harmful programs

[Newcomb, Doug]

Https version is also blacklisted.

Doug

On Sun, Aug 9, 2015 at 5:11 PM, Markus Neteler nete...@osgeo.org wrote:

 On Fri, Aug 7, 2015 at 3:55 PM, Anna Petrášová kratocha...@gmail.com
 wrote:
  Hi,
 
  in google chrome on Windows machine, I am getting big red screen The
 site
  ahead contains harmful programs. Details:

 ... I spent several hours on this issue and did not identify any problem.
 Again: the CMS is also updated to the latest version. File locally
 checked for modification. CSS Stylesheets manually checked for
 injection.

 New - thanks to Martin Spott we have now https:// support for
 https://grass.osgeo.org/
 https://grasswiki.osgeo.org/wiki/Main_Page

 This will hopefully help to solve the current blacklisting by Google.

 Markus

 PS: If anyone has a scanner, please scan the site. Just to exclude any
 issue which we didn't manage to identify so far.
 ___
 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.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] OpenMP 4.0 / gcc5.0

[Newcomb, Doug]

Last time I tried compiling with OpenMP, It made the process slower.  Not
sure why.

Doug

On Sun, Jul 19, 2015 at 10:07 PM, Yann Chemin yche...@gmail.com wrote:

 Hi,

 Ubuntu Wily is going towards gcc5.0 as we speak.
 anybody following the OpenMP 4.0 integration into gcc 5.0?
 it seems there is embedding of heterogeneous computing in it (i.e. ala
 OpenCL).

 is GRASS code using OpenMP forward compatible with this, or will it need
 modification?

 y


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

Re: [GRASS-dev] projection system in metadata [was: Re: GSoC 2015 Improved metada for GRASS GIS week 4]

[Newcomb, Doug]

Most of the local implementations of best practices for metadata that I
have seen include projection information.  Where I work, there are 6
possible projections that are commonly used.

Doug

On Mon, Jun 22, 2015 at 4:18 AM, Moritz Lennert 
mlenn...@club.worldonline.be wrote:

 Hi Matej,

 Thank you for the updates.

 I have one question concerning the metadata templates: do I understand
 correctly that by default, neither the basic, nor the inspire template
 contain a reference to the projection system ?

 IIUC, INSPIRE currently does not impose this, but I don't really
 understand how such basic information can be missing from the metadata.
 What help is the bounding box info, if we don't know in which CRS it is ?

 But maybe I'm just missing something...

 Moritz

 On 21/06/15 21:04, Matej Krejci wrote:

 Hi,
 below is my report for Improved metadata for GRASS GIS project.

 1) What do I have completed this week?

   * I have finished support of metada for temporal framework.

 2) What am I going to achieve for next week?

   * Testing, debugging temporal metadata management
   * To make smome improvements for temporal metadata management
   * Main plan for next week is to start with designing pycsw catalogue
 browser

 3) Is there any blocking issue?

   * I spent more time than I expected with ISO 19108 documentation



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

Re: [GRASS-dev] GSOC 2015: Improved Metadata for GRASS GIS

[Newcomb, Doug]

Thank you for working on this! :-)

Doug

On Tue, Apr 28, 2015 at 2:16 PM, Matej Krejci matejkre...@gmail.com wrote:

 Hi,
 Thanks for the chance to participate on GSOC 2015. The page about project
 is on wiki site[1]. Thank you for ideas and notes in advance.

 Matej

 [1] http://trac.osgeo.org/grass/wiki/GSoC/2015/ImprovedMetadata

 2015-03-11 1:55 GMT+01:00 Matej Krejci matejkre...@gmail.com:

 Hi all,

 Last GSOC I was working on ISO based metadata management for GRASS. In
 this term I was created 'package' wx.metadata which is currently available
 in GRASS add-ons. This part was essential. During playing with
 possibilities of implementation I did a draft of metadata catalogue which
 is the main task of current GSOC topic[1]. Moreover to implement additional
 functions (see list[1]) for current metadata modules is more than suitable.
 Since last GSOC I am still slightly in coding for GRASS and I like to
 continue in this topic. Please let me know if the topic is still free.

 Thanks in advance,
 Matej


 [1]
 http://trac.osgeo.org/grass/wiki/GSoC/2015#ImprovedMetadataforGRASSGIS



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

[GRASS-dev] Standalone GRASS 7 windows installer 64 bit?

[Newcomb, Doug]

Hi Folks
I have a training class for Lidar coming up for which  I would like to use
GRASS 7.  However the standalone installer for windows crashes ( GRASS 7
has stopped working  message) whenever I try to import las data in the
laszip format. ( LAS format works fine).

This appears to have been fixed in the 64 bit build of OSGeo4W, see
http://trac.osgeo.org/osgeo4w/ticket/429, but not in the 32 bit build (
hence the crash)

Is there any timeline on a 64 bit build of the standalone installer for
GRASS 7 for windows?

Doug

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

Re: [GRASS-dev] Standalone GRASS 7 windows installer 64 bit?

[Newcomb, Doug]

Martin,
Thank you for your efforts!  I'll keep my training planning flexible.

Doug

On Thu, Apr 2, 2015 at 11:29 AM, Martin Landa landa.mar...@gmail.com
wrote:

 Hi,

 2015-04-02 17:15 GMT+02:00 Newcomb, Doug doug_newc...@fws.gov:
  Is there any timeline on a 64 bit build of the standalone installer for
  GRASS 7 for windows?

 unfortunately no timeline, I hope to have finish 64bit builds soon...
 Martin

 --
 Martin Landa
 http://geo.fsv.cvut.cz/gwiki/Landa
 http://gismentors.cz/mentors/landa




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

Re: [GRASS-dev] [GRASS GIS] #2584: Vectors skipping columns (character limit !!!) while exporting to OGR data

[Newcomb, Doug]

Sajid,
The shape file format has a 10 character limit on field name length.  The
smallest field name I see above is 11. see,
http://webhelp.esri.com/arcgisdesktop/9.3/index.cfm?TopicName=Geoprocessing%20considerations%20for%20shapefile%20output

Doug

On Tue, Feb 10, 2015 at 12:13 PM, GRASS GIS t...@osgeo.org wrote:

 #2584: Vectors skipping columns (character limit !!!) while exporting to
 OGR data

 +---
  Reporter:  spareeth|   Owner:  grass-dev@…
  Type:  defect  |  Status:  new
  Priority:  normal  |   Milestone:  7.0.0
 Component:  LibVector   | Version:  svn-trunk
  Keywords:  OGR, shapefile  |Platform:  Linux
   Cpu:  Unspecified |

 +---
  Hi
  I am trying to export a vector data with many columns to shape format. But
  it seems it is avoiding all the columns with greater than 10 characters
  (from the pattern, not sure). Tried in GRASS 6.4.5, GRASS 7.0 svn and
  GRASS 7.1 svn, giving the same error.

  Please find attached the packed vector layer which i tried.

  {{{
  v.out.ogr input=test output=test_output.shp
  }}}
  gives me following error, but finishes the job with remaining columns.


  {{{
  ERROR 6: Failed to add field named 'int_minimum'
  ERROR 6: Failed to add field named 'int_maximum'
  ERROR 6: Failed to add field named 'int_average'
  ERROR 6: Failed to add field named 'int_variance'
  ERROR 6: Failed to add field named 'int_coeff_var'
  ERROR 6: Failed to add field named 'int_first_quartile'
  ERROR 6: Failed to add field named 'int_third_quartile'
  ERROR 6: Failed to add field named 'int_percentile_90'
  }}}

  Regards

  Sajid

 --
 Ticket URL: http://trac.osgeo.org/grass/ticket/2584
 GRASS GIS http://grass.osgeo.org

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

Re: [GRASS-dev] New splash screen for GRASS GIS 7?

[Newcomb, Doug]

On Thu, Feb 5, 2015 at 11:18 AM, Anna Petrášová kratocha...@gmail.com
wrote:



 On Thu, Feb 5, 2015 at 10:32 AM, Vincent Bain b...@toraval.fr wrote:

 In addition to latest changes in
 http://grasswiki.osgeo.org/wiki/Identity

 you can find several banner images.Images are all 618x150 PNG8 files.

 Anna : each is available with/without alpha channel, still in 8-bit depth.


 Thank you, do people like more the versions with the white background or
 transparent? I like the transparent one, which seems to be advantageous
 when changing the width of the start up window.


I like the transparent with the capital letters. :-)
Doug




 Anna


 Yours,
 Vincent.



 Le jeudi 05 février 2015 à 12:20 +0100, Vincent Bain a écrit :
  Hello Madi,
  [moved the reply back to the correct thread, I posted the previous
  message on the wrong topic]
 
   Perhaps in D1 the grass symbol and the writing perhaps should be
   slightly moved to right, because the symbol appears cut.
 
  You are right, these vignettes are quickdirty layouts, just there to
  help people choose between different styles.
 
   Is there particular reason why grass is in bold and gis not? I
   would like it better to have the same rule for both words, because a
   different style is already applied to the slogan, I would reduce the
   diversity.
 
  Once again a matter of typographic trick; here we don't actually
  multiply fontfaces, we only play with various strokes weights from a
  same family. It is a way to slightly emphasise the name of the software.
 
  I guess many of you (so do I) really care about the serious image of
  this project: maybe I (or you) should propose a radically sober but
  still elegant splash screen, without any flourish, e.g. the A row with
  single fontface, single weight, green and black logo+text.
 
  Thanks for participating,
  Vincent
 
 
 
  ___
  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 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.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] New splash screen for GRASS GIS 7?

[Newcomb, Doug]

Would location directory be clearer than just location?

Doug

On Wed, Jan 21, 2015 at 12:03 PM, Vaclav Petras wenzesl...@gmail.com
wrote:


 On Wed, Jan 21, 2015 at 9:28 AM, Markus Neteler nete...@osgeo.org wrote:

 On Wed, Jan 21, 2015 at 11:37 AM, Vincent Bain b...@toraval.fr wrote:
  Just for fun, I made a couple of tests there:
  http://www.lesfavrets.fr/telec/grass_splash.tar.gz


 Please, have a look at my suggestion in the attachment for welcome/startup
 screen/window. It contains a graphics but it has small height. Title and
 whole upper part is changed. Note that it is actually done in code, so it
 is pretty precise, except for the graphics which was done just quickly. The
 gray in the background of the image is the one of the window done using
 transparency so it should always match with the window. Unfortunately, this
 will fail miserably when somebody has dark window background color or green
 one (text or logo will be invisible).

 I would also like to change some terms used in the startup window. Namely,
 avoid using ambiguous word project. If it is not clear, use GRASS
 location, otherwise just location. Same for mapset. We should also let
 the translators know that location and mapset should not be translated, or
 translated very carefully. Perhaps also, Start GRASS should be replaced
 by Start GRASS session which is something we avoid in documentation but
 it is quite crucial to understand how it works.

 I like the splash with grass in the background. Hopefully, there is enough
 CC BY images out there.

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

[GRASS-dev] Export of integer raster from GRASS 70 with raster attribute table shifts classes

[Newcomb, Doug]

Hi Folks,

I was running r.geomorphon,
http://grass.osgeo.org/grass70/manuals/addons/r.geomorphon.html, to
generate a landscape integer grid.  I decided to share the output with a
colleague running ArcGIS.  I exported with the raster attribute table
option to HFA ( img , int16 ) format and passed it along.  He noticed
something in the attribute table that was a bit odd.

The the output values for r.geomorphon are integer values from 1 -10 .  The
output .img file
had the following in the following output for gdalinfo ( see below)



As you can see below, a 0 value was added to the color table and the
class_names start at 0 and not at 1 ( i.e, flat=0, but flat should equal 1)
 .  The pixel values do not change, the class names in the
GDALRasterAttributeTable  are are associated  with a lower pixel value
(shifted down one value.1---0 and so on)

Exporting via r.out.gdal to the same file format without a raster attribute
table or a color table gave a raster with values of 1-10.

running gdal 1.11.1 on ubuntu  12.04 with GRASS 7.0 snapshot 2014_10_25.

Not sure if it's a  grass or gdal issue

gdalinfo output:

---

Driver: HFA/Erdas Imagine Images (.img)
Files: NED_SoApp_forms_cell25.img
   NED_SoApp_forms_cell25.img.aux.xml
Size is 22854, 12004
Coordinate System is:
GEOGCS[GCS_WGS_1984,
DATUM[WGS_1984,
SPHEROID[WGS_84,6378137,298.257223563]],
PRIMEM[Greenwich,0],
UNIT[Degree,0.017453292519943295]]
Origin = (-86.094722219722215,37.8480502)
Pixel Size = (0.0002802,-0.0002801)
Corner Coordinates:
Upper Left  ( -86.0947222,  37.8480556) ( 86d 5'41.00W, 37d50'53.00N)
Lower Left  ( -86.0947222,  34.5136111) ( 86d 5'41.00W, 34d30'49.00N)
Upper Right ( -79.7463889,  37.8480556) ( 79d44'47.00W, 37d50'53.00N)
Lower Right ( -79.7463889,  34.5136111) ( 79d44'47.00W, 34d30'49.00N)
Center  ( -82.9205556,  36.1808333) ( 82d55'14.00W, 36d10'51.00N)
Band 1 Block=64x64 Type=Int16, ColorInterp=Palette
  Description = Layer_1
  NoData Value=-32768
  Metadata:
COLOR_TABLE_RULE_RGB_0=1.00e+00 1.00e+00 220 220 220 220 220 220
COLOR_TABLE_RULE_RGB_10=1.10e+01 1.10e+01 255 0 255 255 0 255
COLOR_TABLE_RULE_RGB_1=2.00e+00 2.00e+00 56 0 0 56 0 0
COLOR_TABLE_RULE_RGB_2=3.00e+00 3.00e+00 200 0 0 200 0 0
COLOR_TABLE_RULE_RGB_3=4.00e+00 4.00e+00 255 80 20 255 80 20
COLOR_TABLE_RULE_RGB_4=5.00e+00 5.00e+00 250 210 60 250 210 60
COLOR_TABLE_RULE_RGB_5=6.00e+00 6.00e+00 255 255 60 255 255 60
COLOR_TABLE_RULE_RGB_6=7.00e+00 7.00e+00 180 230 20 180 230 20
COLOR_TABLE_RULE_RGB_7=8.00e+00 8.00e+00 60 250 150 60 250 150
COLOR_TABLE_RULE_RGB_8=9.00e+00 9.00e+00 0 0 255 0 0 255
COLOR_TABLE_RULE_RGB_9=1.00e+01 1.00e+01 0 0 56 0 0 56
COLOR_TABLE_RULES_COUNT=11
Generated_with=GRASS GIS 7.0.0svn
LAYER_TYPE=athematic
  Image Structure Metadata:
COMPRESSION=RLE
  Color Table (RGB with 11 entries)
0: 0,0,0,0
1: 220,220,220,255
2: 56,0,0,255
3: 200,0,0,255
4: 255,80,20,255
5: 250,210,60,255
6: 255,255,60,255
7: 180,230,20,255
8: 60,250,150,255
9: 0,0,255,255
   10: 0,0,56,255
GDALRasterAttributeTable Row0Min=0 BinSize=1
  FieldDefn index=0
NameRed/Name
Type0/Type
Usage6/Usage
  /FieldDefn
  FieldDefn index=1
NameGreen/Name
Type0/Type
Usage7/Usage
  /FieldDefn
  FieldDefn index=2
NameBlue/Name
Type0/Type
Usage8/Usage
  /FieldDefn
  FieldDefn index=3
NameOpacity/Name
Type0/Type
Usage9/Usage
  /FieldDefn
  FieldDefn index=4
Namemin/Name
Type0/Type
Usage0/Usage
  /FieldDefn
  FieldDefn index=5
Namemax/Name
Type0/Type
Usage0/Usage
  /FieldDefn
  FieldDefn index=6
NameClass_Names/Name
Type2/Type
Usage2/Usage
  /FieldDefn
  Row index=0
F0/F
F0/F
F0/F
F0/F
F1/F
F1/F
Fflat/F
  /Row
  Row index=1
F220/F
F220/F
F220/F
F255/F
F2/F
F2/F
Fsummit/F
  /Row
  Row index=2
F56/F
F0/F
F0/F
F255/F
F3/F
F3/F
Fridge/F
  /Row
  Row index=3
F200/F
F0/F
F0/F
F255/F
F4/F
F4/F
Fshoulder/F
  /Row
  Row index=4
F255/F
F80/F
F20/F
F255/F
F5/F
F5/F
Fspur/F
  /Row
  Row index=5
F250/F
F210/F
F60/F
F255/F
F6/F
F6/F
Fslope/F
  /Row
  Row index=6
F255/F
F255/F
F60/F
F255/F
F7/F
F7/F
Fhollow/F
  /Row
  Row index=7
F180/F
F230/F
F20/F
F255/F
F8/F
F8/F
Ffootslope/F
  /Row
  Row index=8
F60/F
F250/F
F150/F
F255/F
F9/F
F9/F
Fvalley/F
  /Row
  Row index=9
F0/F
F0/F
F255/F
F255/F
F10/F
F10/F
Fdepression/F
  /Row
  Row index=10
F0/F
F0/F
F56/F
F255/F
F11/F
F11/F
FERROR/F
  /Row
/GDALRasterAttributeTable

Re: [GRASS-dev] v.in.lidar return filter

[Newcomb, Doug]

I don't think it was intentional to drop first and only returns, but if it
is the first and only return the filter for First and Last Return would
both match.
Putting another if statement in front along the lines of  if(n_returns ==
1) set case LAS_FIRST should fix it.

Doug


On Mon, Sep 22, 2014 at 6:54 PM, Anna Petrášová kratocha...@gmail.com
wrote:

 Hi,

 I want to import first return points with v.in.lidar, but I get only
 points where the pulse had more then one return. So it gives me trees but
 not ground or buildings. I looked in the code and there is an 'if' which
 skips points with only 1 return:

 http://trac.osgeo.org/grass/browser/grass/trunk/vector/v.in.lidar/main.c#L672

 So the behavior looks intentional but what's the reason?

 Thanks,

 Anna

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

Re: [GRASS-dev] v.in.lidar return filter

[Newcomb, Doug]

It looks like the same patch needs to be applied to r.in.lidar main.c
before line 791. So modifying to the following for both v.in.lidar and
r.in.lidar  main.c should fix both?

if (n_returns == 1) {

switch (return_filter) {
case LAS_FIRST:
if (return_no == 1)
skipme = 0;
break;
  }
if (n_returns  1) {

switch (return_filter) {
case LAS_FIRST:
if (return_no == 1)
skipme = 0;
break;
case LAS_LAST:
if (return_no == n_returns)
skipme = 0;
break;
case LAS_MID:
if (return_no  1  return_no  n_returns)
skipme = 0;
break;
}

Doug


On Tue, Sep 23, 2014 at 8:05 AM, Newcomb, Doug doug_newc...@fws.gov wrote:

 I don't think it was intentional to drop first and only returns, but if it
 is the first and only return the filter for First and Last Return would
 both match.
 Putting another if statement in front along the lines of  if(n_returns ==
 1) set case LAS_FIRST should fix it.

 Doug


 On Mon, Sep 22, 2014 at 6:54 PM, Anna Petrášová kratocha...@gmail.com
 wrote:

 Hi,

 I want to import first return points with v.in.lidar, but I get only
 points where the pulse had more then one return. So it gives me trees but
 not ground or buildings. I looked in the code and there is an 'if' which
 skips points with only 1 return:

 http://trac.osgeo.org/grass/browser/grass/trunk/vector/v.in.lidar/main.c#L672

 So the behavior looks intentional but what's the reason?

 Thanks,

 Anna

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




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

Re: [GRASS-dev] v.in.lidar return filter

[Newcomb, Doug]

Much better :-) !

On Tue, Sep 23, 2014 at 11:40 AM, Anna Petrášová kratocha...@gmail.com
wrote:



 On Tue, Sep 23, 2014 at 8:19 AM, Newcomb, Doug doug_newc...@fws.gov
 wrote:

 It looks like the same patch needs to be applied to r.in.lidar main.c
 before line 791. So modifying to the following for both v.in.lidar and
 r.in.lidar  main.c should fix both?

 if (n_returns == 1) {

 switch (return_filter) {
 case LAS_FIRST:
 if (return_no == 1)
 skipme = 0;
 break;
   }
 if (n_returns  1) {

 switch (return_filter) {
 case LAS_FIRST:
 if (return_no == 1)
 skipme = 0;
 break;
 case LAS_LAST:
 if (return_no == n_returns)
 skipme = 0;
 break;
 case LAS_MID:
 if (return_no  1  return_no  n_returns)
 skipme = 0;
 break;
 }


 Thanks, I rewrote it but it should be hopefully the same logic:

   switch (return_filter) {

   case LAS_FIRST:

   if (return_no == 1)

   skipme = 0;

   break;

   case LAS_MID:

   if (return_no  1  return_no  n_returns)

   skipme = 0;

   break;

   case LAS_LAST:

   if (n_returns  1  return_no == n_returns)

   skipme = 0;

   break;


 Committed in r62055 and backported.


 Anna


  }

 Doug


 On Tue, Sep 23, 2014 at 8:05 AM, Newcomb, Doug doug_newc...@fws.gov
 wrote:

 I don't think it was intentional to drop first and only returns, but if
 it is the first and only return the filter for First and Last Return would
 both match.
 Putting another if statement in front along the lines of  if(n_returns
 == 1) set case LAS_FIRST should fix it.

 Doug


 On Mon, Sep 22, 2014 at 6:54 PM, Anna Petrášová kratocha...@gmail.com
 wrote:

 Hi,

 I want to import first return points with v.in.lidar, but I get only
 points where the pulse had more then one return. So it gives me trees but
 not ground or buildings. I looked in the code and there is an 'if' which
 skips points with only 1 return:

 http://trac.osgeo.org/grass/browser/grass/trunk/vector/v.in.lidar/main.c#L672

 So the behavior looks intentional but what's the reason?

 Thanks,

 Anna

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




 --
 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.





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

Re: [GRASS-dev] metadata naming and location

[Newcomb, Doug]

Matej,
Thank you for all of the hard work on this project!  I would suggest going
with r_ and v_ for simplicity.

Doug


On Wed, Aug 13, 2014 at 9:28 AM, Matej Krejci matejkre...@gmail.com wrote:

 Hi,

 I would like to introduce possibility/decision of naming and choice of
 location for .xml metadata files.
 With Margherita and Martin we agreed:

 To create new folder 'metadata' in grass location:
 path/to/location/metadata

 naming:
 for raster map:
 cell_ + nameofmap +.xml
 e.g cell_basin.xml

 for vector map:
 vector_ + nameofmap+ .xml
 vector_route.xml

 also prefix can be r_ and v_. What you think?

 We decide to leave postfix in accordance with type of profile (basic,
 inspire) and hold just one metadata file.

 Does that make sense?

 Thank you
 Matej




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

Re: [GRASS-dev] Week 11: GRASS GIS 3D flowlines

[Newcomb, Doug]

Anna,
This parallels my experience in running v.surf.rst with OpenMP enabled and
disabled on large areas.  With OpenMP enabled on an 8 core computer, the
process used 700% of CPU time, but took about twice as long as running the
same data set on a single core with OpenMP disabled.

Doug


On Wed, Aug 6, 2014 at 10:58 PM, Anna Petrášová kratocha...@gmail.com
wrote:

 Hi,


 On Tue, Aug 5, 2014 at 11:04 AM, Newcomb, Doug doug_newc...@fws.gov
 wrote:

 Anna,
 Will you post the  benchmarking results  for the OpenMP computation vs
 the non-OpenMP?


 after some testing, my conclusion is that OpenMP does not really speed up
 gradient computation and it can even slow it down. I tried it on my laptop
 with 2 cores and on a powerful computer with 12 cores, with different sizes
 of processed blocks and I didn't get any significant speed-up. The most
 costly seems to be writing of the three 3D rasters and the gradient
 computation is relatively short. I also tested different cache settings but
 default settings seems to be optimal, I got only similar or worse results
 with different cache settings.  I hope I didn't missed anything, since this
 is quite new to me.

 Best,

 Anna


 Doug


 On Fri, Aug 1, 2014 at 3:54 PM, Anna Petrášová kratocha...@gmail.com
 wrote:

 Hi,

 1. What did you get done this week:
 I implemented adding attributes to each segment of a flowline. I added
 column with velocities and values of input 3D raster along the flowline.
 The result can be visualized by using vector color tables (v.colors) in 2D
 and 3D.
 I started writing r3.gradient module based on the gradient function in
 r3.flow. The module is already running and giving correct results, I will
 add it to addons once the gradient function is moved to library.

 2. What do you plan on doing next week?
 I will try to parallelize the gradient computation with openMP, the
 structure of the code is already prepared for that. Then, I plan to add
 more tests.

 3. Are you blocked on anything?
 No.

 Anna

 [1]
 http://trac.osgeo.org/grass/wiki/GSoC/2014/ImplementationOf3DRasterFlowLine
 [2]
 http://trac.osgeo.org/grass/browser/grass-addons/grass7/raster3d/r3.flow

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





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

Re: [GRASS-dev] Week 11: GRASS GIS 3D flowlines

[Newcomb, Doug]

Anna,
Will you post the  benchmarking results  for the OpenMP computation vs the
non-OpenMP?

Doug


On Fri, Aug 1, 2014 at 3:54 PM, Anna Petrášová kratocha...@gmail.com
wrote:

 Hi,

 1. What did you get done this week:
 I implemented adding attributes to each segment of a flowline. I added
 column with velocities and values of input 3D raster along the flowline.
 The result can be visualized by using vector color tables (v.colors) in 2D
 and 3D.
 I started writing r3.gradient module based on the gradient function in
 r3.flow. The module is already running and giving correct results, I will
 add it to addons once the gradient function is moved to library.

 2. What do you plan on doing next week?
 I will try to parallelize the gradient computation with openMP, the
 structure of the code is already prepared for that. Then, I plan to add
 more tests.

 3. Are you blocked on anything?
 No.

 Anna

 [1]
 http://trac.osgeo.org/grass/wiki/GSoC/2014/ImplementationOf3DRasterFlowLine
 [2]
 http://trac.osgeo.org/grass/browser/grass-addons/grass7/raster3d/r3.flow

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

Re: [GRASS-dev] future of GRASS for Windows [was: Re: [GRASS-SVN] r60679 - grass/trunk/lib/python/script]

[Newcomb, Doug]

I agree with Martin and Helmut.

In my experience, the bulk of the existing GIS users are using Windows and
those using GIS professionally are often in work environments where the use
of virtual machines or installation of other OS's is prohibited.

The unfortunate fact is that many GIS users have not been exposed to an OS
environment other than Windows.  Requiring them to load/learn another OS
just to run this GIS software would be a fairly high bar for the average
user. Without a Windows port, GRASS will simply not be available to a
majority of institutional/mainstream GIS users.

If the goal is to expand the user base of GRASS, the maintaining a Windows
port is an excellent method.

Doug


On Wed, Jul 2, 2014 at 7:40 AM, Helmut Kudrnovsky hel...@web.de wrote:

 Martin Landa wrote
  Hi,
 
  2014-07-02 13:22 GMT+02:00 Moritz Lennert lt;

  mlennert@.worldonline

  gt;:
  [Starting a new thread as this is an important point on its own.
 Original
  mail is [1].]
 
  On 02/07/14 01:10, Glynn Clements wrote: But in the longer term, should
  we
  be claiming to support a platform
  for which we appear to have no active developers?
 
  I think that the question merits discussion. In my teaching experience
 it
  has been very helpful to have a MS Windows version to allow students
 with
  MS
  Windows machines to install the software on these machines. I also have
  colleagues who, for different reasons, are quite resistant to installing
  another OS on their machines, but would like to use GRASS. So,
 generally,
  I
  think that there should be a MS Windows port of GRASS.
 
  we simply _must_ support as much as possible GRASS on Windows. It's
  crucial for us, without users there is no need for developing
  software.
 
  Martin

 I concur with Martin! supporting winGRASS is a must.

 maybe let's spend some money to fix some crucial OS-depending issues...




 -
 best regards
 Helmut
 --
 View this message in context:
 http://osgeo-org.1560.x6.nabble.com/future-of-GRASS-for-Windows-was-Re-GRASS-SVN-r60679-grass-trunk-lib-python-script-tp5149214p5149221.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




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

Re: [GRASS-dev] [SoC] gsoc2014 grass metadata week 6

[Newcomb, Doug]

g.gui.metadata is the most clear to me.

Doug


On Mon, Jun 30, 2014 at 4:30 AM, Martin Landa landa.mar...@gmail.com
wrote:

 Hi,

 2014-06-30 9:37 GMT+02:00 Luca Delucchi lucadel...@gmail.com:
  I think that g.gui.editor it is not so clear, could you rename it to
  g.gui.metadata or g.gui.metaeditor?

 right, `g.gui.metadata` seems to be the most appropriate, Martin


 --
 Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
 ___
 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.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Metadata GRASS (GSOC)

[Newcomb, Doug]

I heard yesterday  that EPA is releasing a new version of their metadata
tool , doing away with the access database and writing everything to xml
files.  It's being written in C#, but they plan on putting the source code
on github. Not sure of the timeline.

Doug


On Sat, May 17, 2014 at 3:19 AM, Matej Krejci matejkre...@gmail.com wrote:

 Hi,


  I was wondering was whether it would be possible to extract from pycsw
 just the part for reading/writing the xml meta-data, without all the
 overhead linked to its status as a server.




 More generally, I just think that we can't be the only ones working on
 metadata in a Python environment and that we maybe not have to reinvent the
 wheel.


 I got news that OWSLib can be used for parse XML according ISO without
 dependence on pycsw server. In addition I found that  there is a pycsw
 package in UbuntuGIS and also there is a plan to develop package for Debian
 with the development  should start probably after couple of months. OWSLib
 have dependence only on lxml so this is not a barrier. If we use OWSLib for
 first task, it could to ensure a smoother continuity to develop second
 task- pywps.

 Matej


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

Re: [GRASS-dev] r.in.lidar tuning

[Newcomb, Doug]

Great!  I will test when I have a spare moment!

In the long term.. Any chance of filtering the input points through an
elevation raster to subtract to get height above ground before statistics?

las file--- subtract value of elevation grid generated from ground points
-- run statistics on modified z values of las points.

One problem I can see is that you generally have higher resolution
elevation rasters than the resolution of forest canopy structure you wish
to create.  6m elevation grid vs 18m canopy structure grids)  This might be
better as a separate function (r.lashag?) in which you have inputs of an
external las file and an elevation raster layer and an output of an las
file with the z value as height above ground.



I've done this externally with python scripts ( badly and slowly) . On the
upside, the resulting las datasets are quite promising for landscape -
level canopy structure analysis.

Doug


On Fri, May 16, 2014 at 6:02 PM, Markus Neteler nete...@osgeo.org wrote:

 (back to an older topic)

 On Tue, Oct 8, 2013 at 8:37 PM, Markus Neteler wrote:
  On Tue, Oct 8, 2013 at 4:31 PM, Markus Metz  wrote:
  Markus Neteler wrote:

 [ wish for r.in.lidar: ]
 ...
  filter   Only import points of selected return type
If not specified, all points are imported
   options: first,last,mid
 
  which would be great for r.in.lidar as well to avoid that I need to
  split the file with las2las beforehand.
 
  Why would you want to do filtering? The r.in.lidar methods min, max,
  mean, median, percentile are not sufficient?

 For some LAS files not.

  I omitted to mention the sometimes existing classification of returns
  and had in mind to be able to restrict the import to e.g. ground
  points only, or the like. Then apply the methods min, max, etc only to
  the selected subset of LiDAR points.

 I have implemented that now in
 http://trac.osgeo.org/grass/changeset/60247/grass/trunk/raster/r.in.lidar

 (hope I got it right over from v.in.lidar)

 Concerning Doug's intensity wish which also became mine yesterday:
 Attached a patch to import intensity values rather than z values (flag -i).
 Using -i all statistics are applied to intensity.

 The code is a bit simple (ugly) since the variable names further on
 in the code remain related to z rather than e.g. become a generic
 value. Not sure if all related variables should be renamed, hence I
 didn't commit that to SVN.
 Please try from svn + attached patch.

 markusN




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

Re: [GRASS-dev] r.in.lidar tuning

[Newcomb, Doug]

I pulled the latest 71 trunk ( 60278) , applied the patch, and the
intensity option appears to work.

Doug



On Fri, May 16, 2014 at 6:02 PM, Markus Neteler nete...@osgeo.org wrote:

 (back to an older topic)

 On Tue, Oct 8, 2013 at 8:37 PM, Markus Neteler wrote:
  On Tue, Oct 8, 2013 at 4:31 PM, Markus Metz  wrote:
  Markus Neteler wrote:

 [ wish for r.in.lidar: ]
 ...
  filter   Only import points of selected return type
If not specified, all points are imported
   options: first,last,mid
 
  which would be great for r.in.lidar as well to avoid that I need to
  split the file with las2las beforehand.
 
  Why would you want to do filtering? The r.in.lidar methods min, max,
  mean, median, percentile are not sufficient?

 For some LAS files not.

  I omitted to mention the sometimes existing classification of returns
  and had in mind to be able to restrict the import to e.g. ground
  points only, or the like. Then apply the methods min, max, etc only to
  the selected subset of LiDAR points.

 I have implemented that now in
 http://trac.osgeo.org/grass/changeset/60247/grass/trunk/raster/r.in.lidar

 (hope I got it right over from v.in.lidar)

 Concerning Doug's intensity wish which also became mine yesterday:
 Attached a patch to import intensity values rather than z values (flag -i).
 Using -i all statistics are applied to intensity.

 The code is a bit simple (ugly) since the variable names further on
 in the code remain related to z rather than e.g. become a generic
 value. Not sure if all related variables should be renamed, hence I
 didn't commit that to SVN.
 Please try from svn + attached patch.

 markusN




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

Re: [GRASS-dev] Metadata GRASS (GSOC)

[Newcomb, Doug]

With option 1) , would the tool also operate on externally linked datasets
( via v.external and r.external) ?

Doug


On Wed, May 14, 2014 at 4:06 PM, Matej Krejci matejkre...@gmail.com wrote:

 Hi,

 I would like to discuss the metadata management in GRASS which is my topic
 for GSOC.

 My idea for GSOC term is to Python library, command line modules and wxGUI
 front-end.

 The current plan has two parts, however the second one is optional.

 1)
 Main task is to make Python library that can create, read and edit XML
 (ISO standard). I think it is necessary to implement standards externally.
 In this case it is useful to use XSD (xml template) to generate the valid
 XML. There is an option to use generateDS[1] to generates Python code with
 classes representing XSD structure. Also the generateDS can fill XSD  and
 then export it to XML.
 In this case the module will read raster and vector metadata from current
 GRASS flat files. In the future(GRASS 8 development) a new C lib can be
 created. It would enable to fill in fundamental XML with values from
 GRASS(v, r, r3d) and other values by default values that can be replaced
 by this module. This C library will be just for fill in basic XML and any
 control (edit,read,etc) will be provide by Python module (GSOC). What you
 think about generateDS?

 2)
 If theres some time left in GSOC term or after I would like to implement a
 server-client management of metadata using pycsw [3](server side) and
 owslib[3] in client side. Demonstration of functions that provide this
 solution is i.e. in QGIS plugin (Meta Search).  I  wanted to use this
 suggestion at first, but there are quite heavy dependences on others
 packages. In addition there is no any package for debian... So this
 solution will be for a user who really want to work with metadata but not
 fundamental ones.


 [1]http://www.rexx.com/~dkuhlman/generateDS.html
 [2]http://pycsw.org/
 [3]http://geopython.github.io/OWSLib/

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

Re: [GRASS-dev] Handling of Python scripts on MS Windows

[Newcomb, Doug]

On Thu, May 8, 2014 at 9:52 AM, Vaclav Petras wenzesl...@gmail.com wrote:


 On Thu, May 8, 2014 at 9:22 AM, Sören Gebbert 
 soerengebb...@googlemail.com wrote:

 
  On MS Windows, users do have a free choice of what they install. Third
  party software packages are on MS Windows completely independent of
  each other. If you don't like this, you have to change the MS Windows
  world first, then GRASS.
 
  On MS Windows, GRASS and a system-wide Python installation are third
  party software packages that are completely independent of each other.

 In my Institute the user do not have the free choice of what they
 can install on their windows machines.
 There are guidelines what software and version is allowed to be
 installed. There are Institution specific software repositories that
 must be used.
 All software must be installed by the system administrator, user do
 not have any permissions
 to do this them self. This is for security and maintenance reasons.

 I think this is very common in companies and public institutions. I
 know several companies with much more restrictive guideline (no
 internet connection, USB sticks not allowed, ...). So you can't expect
 that
 user have a free choice.


 Hi, I don't understand how this actually influence whether GRASS should
 have Python inside or outside. For user there is no difference since it
 should be managed by sysadmin, so what is sysadmin's decision process?


1) does it introduce any security risks ( open ports, install remotely
accessible services, change system file/directory permissions, etc)?
2) does it require administrative access to run ( i.e, write access to
install directories under c:\Program Files by normal users is generally
prohibited) ?
3) does it break existing software?
4) does it perform useful tasks ?

Doug



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

Re: [GRASS-dev] GSoC ideas - vector legend, medial axis

[Newcomb, Doug]

Another QGIS plugin effort.

http://gis-lab.info/qa/metatools-eng.html#Working_with_FGDC

Doug


On Thu, Feb 27, 2014 at 12:56 PM, Newcomb, Doug doug_newc...@fws.govwrote:

 Metadata code reference:


 https://geo-ide.noaa.gov/wiki/index.php?title=ISO_19115_and_19115-2_CodeList_Dictionaries

 Doug





 On Tue, Feb 25, 2014 at 3:36 PM, Antony Scott antony.sc...@gmail.comwrote:

 Doug/all,

 First, my apologies for not responding to your earlier nudge. However
 there's not a great deal to report on the plugin - MapAction remains keen
 to take it forward, but doesn't have the development resources at the
 moment to be able to do much about it. We'd be happy to expand on the
 documentation though, and the osgeo gsoc could be an opportunity to get
 things moving if people were interested. Certainly our experiences in the
 Philippines last year underlined our need for better metadata creation and
 management tools, so it's high on our list of action points for follow up.

 Look forward to seeing how things develop, and we'll see if there's
 anything we can contribute.

 regards
 Ant Scott



 On 25 February 2014 12:54, Newcomb, Doug doug_newc...@fws.gov wrote:

 I had a chat with Antony Scott a while back about a metadata component
 to this plugin:

 https://github.com/mapaction/RAMP-QGIS

 I have not kept up with the progress of the plugin.

 Doug


 On Mon, Feb 24, 2014 at 5:53 PM, Hamish hamis...@yahoo.com wrote:

 Hi,

 (thanks for the great ideas pages everyone: osgeo gsoc 2014 is accepted
 and happening!)


 integrating an existing open source metadata library instead of
 starting from scratch would be faster and easier to maintain in
 the long run. :)

 e.g. try to cooperate with the GeoNetwork and pycsw teams. is qgis
 doing anything wrt metadata that we could share development with?



 Hamish




 --
 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.





 --
 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.




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

Re: [GRASS-dev] GSoC ideas - vector legend, medial axis

[Newcomb, Doug]

Metadata code reference:

https://geo-ide.noaa.gov/wiki/index.php?title=ISO_19115_and_19115-2_CodeList_Dictionaries

Doug





On Tue, Feb 25, 2014 at 3:36 PM, Antony Scott antony.sc...@gmail.comwrote:

 Doug/all,

 First, my apologies for not responding to your earlier nudge. However
 there's not a great deal to report on the plugin - MapAction remains keen
 to take it forward, but doesn't have the development resources at the
 moment to be able to do much about it. We'd be happy to expand on the
 documentation though, and the osgeo gsoc could be an opportunity to get
 things moving if people were interested. Certainly our experiences in the
 Philippines last year underlined our need for better metadata creation and
 management tools, so it's high on our list of action points for follow up.

 Look forward to seeing how things develop, and we'll see if there's
 anything we can contribute.

 regards
 Ant Scott



 On 25 February 2014 12:54, Newcomb, Doug doug_newc...@fws.gov wrote:

 I had a chat with Antony Scott a while back about a metadata component to
 this plugin:

 https://github.com/mapaction/RAMP-QGIS

 I have not kept up with the progress of the plugin.

 Doug


 On Mon, Feb 24, 2014 at 5:53 PM, Hamish hamis...@yahoo.com wrote:

 Hi,

 (thanks for the great ideas pages everyone: osgeo gsoc 2014 is accepted
 and happening!)


 integrating an existing open source metadata library instead of starting
 from scratch would be faster and easier to maintain in
 the long run. :)

 e.g. try to cooperate with the GeoNetwork and pycsw teams. is qgis doing
 anything wrt metadata that we could share development with?



 Hamish




 --
 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.





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

Re: [GRASS-dev] GSoC ideas - vector legend, medial axis

[Newcomb, Doug]

From what I understand, the ISO 19115-1 metadata standard should be
finalized shortly.  Getting an official copy of the standard for this work
( if they finalize in time) would be useful.

Doug



On Tue, Feb 25, 2014 at 4:36 AM, Margherita Di Leo 
dileomargher...@gmail.com wrote:

 Hi All,


 On Mon, Feb 24, 2014 at 8:22 PM, Martin Landa landa.mar...@gmail.comwrote:

 Hi,

 2014-02-24 20:18 GMT+01:00 Tereza Fiedlerová tfiedler...@gmail.com:
  finally I considered the metadata topic is probably the most
 appropriate for
  me. My aim now is to find out as much as I can about it to have better
 idea
  what is going on. If you have any additional information or resources I
  could study, please let me know. Thanks


 Tereza, I'm glad to hear that. As several hints have already come, I'd
 suggest to set a page in the trac where we can store all these inputs that
 otherwise would be difficult to find again.


 perfect, in this regard I would like to open discussion whether to
 speak just about metadata (ISO, Inspire) or also about  supporting
 Inspire services (view and download)...


 Martin, this makes sense, but I'd stick with a target that is reachable
 within the GSoC. Of course the occasion is suitable to gather all the ideas
 which can be developed in the future.

 Thanks,
 MaDi



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




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

Re: [GRASS-dev] GSoC ideas - vector legend, medial axis

[Newcomb, Doug]

I had a chat with Antony Scott a while back about a metadata component to
this plugin:

https://github.com/mapaction/RAMP-QGIS

I have not kept up with the progress of the plugin.

Doug


On Mon, Feb 24, 2014 at 5:53 PM, Hamish hamis...@yahoo.com wrote:

 Hi,

 (thanks for the great ideas pages everyone: osgeo gsoc 2014 is accepted
 and happening!)


 integrating an existing open source metadata library instead of starting
 from scratch would be faster and easier to maintain in
 the long run. :)

 e.g. try to cooperate with the GeoNetwork and pycsw teams. is qgis doing
 anything wrt metadata that we could share development with?



 Hamish




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

Re: [GRASS-dev] GSoC ideas - vector legend, medial axis

[Newcomb, Doug]

A good metadata tool that generates  ISO compliant xml  would be very
useful and a substantial accomplishment by itself.

Doug




On Mon, Feb 24, 2014 at 2:22 PM, Martin Landa landa.mar...@gmail.comwrote:

 Hi,

 2014-02-24 20:18 GMT+01:00 Tereza Fiedlerová tfiedler...@gmail.com:
  finally I considered the metadata topic is probably the most appropriate
 for
  me. My aim now is to find out as much as I can about it to have better
 idea
  what is going on. If you have any additional information or resources I
  could study, please let me know. Thanks

 perfect, in this regard I would like to open discussion whether to
 speak just about metadata (ISO, Inspire) or also about  supporting
 Inspire services (view and download)...

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

Re: [GRASS-dev] Handling of Python scripts on MS Windows

[Newcomb, Doug]

As someone who uses both ArcGIS and GRASS on windows, I see it as a bonus
that the python installations are separate.  I can recommend that folks in
my agency install GRASS on a computer and I can assure them that it does
not affect their ArcGIS installation, with it's own ESRI - specific version
of python.

Doug


On Tue, Jan 28, 2014 at 6:07 AM, Markus Metz
markus.metz.gisw...@gmail.comwrote:

 On Mon, Jan 27, 2014 at 12:16 AM, Glynn Clements
 gl...@gclements.plus.com wrote:
 
  Markus Metz wrote:
 
  On Sat, Jan 25, 2014 at 3:59 PM, Helena Mitasova hmit...@ncsu.edu
 wrote:
   Just a note, given that most of these problems were caused by
 conflicts with python installed by ArcGIS,
   I checked with our GIS support and the latest ArcGIS 10.2 installs
 python2.7 which (I guess) should work with GRASS.
 
  No, there are different versions of Python 2.7, and not all work with
  GRASS, see e.g. ticket 2015
 
  Any version of Python 2.7 should be suitable for GRASS.

 Not all versions of Python 2.7 are suitable for WinGRASS, see ticket #2150.

  However, it
  needs to be installed correctly, and GRASS needs to not attempt to
  bundle Python.
 
  GRASS should not use a system-wide Python installation, or more
  precisely, should explicitly ignore any system-wide python file
  associations. Expecting system-wide python file associations is the
  cause of all the trouble.
 
  Executing a script uses the registry associations for the script's
  extension.

 WinGRASS does not set registry associations for Python scripts, nor
 does it install Python system-wide. This is because we do not want to
 modify an existing Python installation.
 
  Attempting to by-pass the system's script execution mechanism (by
  explicitly executing Python scripts via a specific interpreter) is the
  cause of all the trouble.

 I disagree. Troubles arise if the system's interpreter, e.g. Python
 installed by ArcGIS, is used instead of the python version embedded in
 WinGRASS.

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

Re: [GRASS-dev] r.null apparently doesn't work on vrt via r.external on G7

[Newcomb, Doug]

I thought r.external was a read-only link.

Doug


On Thu, Dec 19, 2013 at 3:35 AM, Margherita Di Leo 
dileomargher...@gmail.com wrote:

 Hi All,

 Is it an expected behaviour that r.null doesn't affect vrt raster linked
 via r.external?
 Tested on forest map 2000 available for download from
 http://forest.jrc.ec.europa.eu/download/data/forest-data-download/
 I build the mosaic with gdalbuildvrt and then use r.external
 then I want to set to null the values 0,2,3:
 r.null mosaic setnull=0-2-3
 this command doesn't have any effect on the map.

 thanks

 madi

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




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

Re: [GRASS-dev] r.in.lidar tuning

[Newcomb, Doug]

Any thoughts on applying further filtering and using the intensity of the
return for statistical analysis?  For example, if one wanted to calculate
the mean/range/in/max/std_dev  intensity of the last returns or first
returns.

Doug



On Tue, Oct 8, 2013 at 2:37 PM, Markus Neteler nete...@osgeo.org wrote:

 On Tue, Oct 8, 2013 at 4:31 PM, Markus Metz
 markus.metz.gisw...@gmail.com wrote:
  Markus Neteler wrote:
 
  One more wish comes to mind (indeed, I started cross-porting but :-)
 
  v.in.lidar comes with a filter (which should perhaps be generalized to
  the nth return; or, the last *is* the nth return but then mid could
  be more than one in this case?):
 
  Yes, for n returns, the first return is number 1, the last return is
  the nth return and mid returns are all returns in between, i.e. none
  for 2 returns. Choosing the nth return does not make sense to me.

 ok

  filter   Only import points of selected return type
If not specified, all points are imported
   options: first,last,mid
 
  which would be great for r.in.lidar as well to avoid that I need to
  split the file with las2las beforehand.
 
  Why would you want to do filtering? The r.in.lidar methods min, max,
  mean, median, percentile are not sufficient?


 I omitted to mention the sometimes existing classification of returns
 and had in mind to be able to restrict the import to e.g. ground
 points only, or the like. Then apply the methods min, max, etc only to
 the selected subset of LiDAR points.

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

[GRASS-dev] Fwd: [LAStools] Datum converson

[Newcomb, Doug]

FYI

Doug

-- Forwarded message --
From: Gottfried Mandlburger g...@ipf.tuwien.ac.at
Date: Tue, Sep 17, 2013 at 3:40 AM
Subject: Re: [LAStools] Datum converson
To: lasto...@googlegroups.com
Cc: Heidemann, Hans kheidem...@usgs.gov


Dear all,

I'd like to jump into this discussion concerning 2D and 3D transformation
as I strongly believe this is a hot issue. Howard was referring to
proj.4+gdal+libgeotiff (GDAL/OGR) and said that it provides the 3D
transformation. True, if you want to transform from geometrically defined
(i.e. ellipsoidal) heights in the source datum to ellipsoidal heights in
the target datum. True also for specific orthometric height systems like
NAVD88 as long as the required geoid undulations are available in the
correct format and at the expected place (on disc). But this dataset is
restricted to North America. For the rest of the world, geoid undulation
w.r.t the WGS84 spheroid are available via the EGM2008 model but, however,
in general the the federal geodetic administrations provide more precise
local geoid models. All these models are not supported in GDAL/OGR. If you
would like to use them, you would have to hack the library. In other words,
user-defined geoid models are not supported by the library (nor is there an
established (OGC, ...) standard), and therefore, the spatial reference
system transformations by GDAL/OGR cannot be regarded as being full 3D.

Concerning datum transformations in general, there is another issue.
Currently, we have two commonly accepted ways for performing the datum
transition:

1) Via a 7-parameter spatial similarity transformation (3 shifts, 3
rotations, 1 scale). This is established in the OGC Coordinate
Transformation Services standard (http://www.opengeospatial.**
org/standards/ct http://www.opengeospatial.org/standards/ct) by the
TOWGS84 parameter in the Well-Known-Text representation. However, due to
inconsistencies in the (historically grown) national surveying systems,
multiple 7P datasets are necessary to transform from the inhomogeneous
national system (eg. NAD..., DHDN/Germany, MGI/Austria...) to the
(homogeneous) trans-national system (WGS84, ETRS89, ITRS..) in sub-meter
accuracy. This becomes relevant as, nowadays,  the typical (planimetric and
height) accuracy of lidar data is in the decimeter range.

2) Via NTv2 grid shift files. This is not established in OGC/CT, but only
an industry standard. Certain grid shift transformations are supported by
GDAL/OGR, but, as discussed before for geoid undulation models, others are
not. Apart from that problem, there is another general problem, when it
comes to the transformation of heights. As grid shifts directly transform
lat/lon from one datum to the other, the respective ellipsoidal height on
the target system is lost, which is not the case for the 7P datum
transformation!

To overcome at least some of the aforementioned problems, we (TU Vienna,
Department of Geodesy and Geoinformation, Research group Photogrammetry and
Laserscanning) have initiated a Google-Summer-of-Code project (Rigorous
support of Vertical Datums within OGRSpatialReference, see:
https://github.com/**ottointhesky/OGRSpatialRef3Dhttps://github.com/ottointhesky/OGRSpatialRef3D).
The project is not yet finished, but pencil-down is this week, so we expect
a clean version at the end of the month.

The primary goal was to extend the OGRSpatialReference classes to support:

.) user defined geoid undulation models (ellip.-orthom. heights)
.) user defined height correction models (to compensate anomaliess of the
height system)
.) a vertical offset (false elevation)

Tools from the raster domain of the GDAL library are used to read/process
the geoid undulation grid models and to use them within 3D-coordinate
transformations implemented in OGRCoordinateTransformation.

I'm sure the above mentioned initiative is no universal remedy, but at
least is an attempt to shed light on the 3d transformation jungle. Coming
back to Karls original request. Yes, it would definitely be nice to have
tools available to reliably perform 3D-transformations for lidar data. If
this is within LAStools or any other commonly accessible implementation
(like GDAL/OGR) is of minor importance.

Kind regards,
Gottfried

-- 
Dr. Gottfried Mandlburger

Tel.: +43 1 58801 12235
Fax.: +43 1 58801 12299
http://www.ipf.tuwien.ac.at
http://www.geo.tuwien.ac.at/**opals http://www.geo.tuwien.ac.at/opals
_ _ _
   /// ___///  Vienna University of Technology
  // __ / /__ / // /  Department of Geodesy and Geoinformation
 //__/// /__ / // /  Research Groups Photogrammetry and Remote Sensing
//////  Gusshausstrasse 27-29, A-1040 Vienna







On 13.09.2013 18:39, Heidemann, Hans wrote:

 ...and my understanding is that the vertical error Kirk refers to can be
 significant, particularly at high latitude i.e., Alaska North Slope.

 Karl

 *H. Karl Heidemann, GISP*
 /Physical Scientist, Lidar Science/

 U.S. Geological Survey
 

Re: [GRASS-dev] Missing subgroup functionality in GRASS 7 wxGUI's i.group?

[Newcomb, Doug]

Confirmed that the option does not work in the gui, but does work on the
command line.  Have you filed a ticket?

Doug


On Wed, Sep 11, 2013 at 5:35 AM, Nikos Alexandris
n...@nikosalexandris.netwrote:

 Hi list.

 Working with version=7.0.svn, revision=57486M here.  It seems the option to
 create a subgroup is missing from:

 Imagery  Develop images and groups  Create/edit group [i.group]

 Best regards, Nikos
 ___
 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.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] sample implimentation for upcoming OGC geopackage standard

[Newcomb, Doug]

Hi Folks,
One of the entities working on the proposed OGC geopackage standard has
some sample code out under the Apache 2. License.  Uses sqlite.

https://bitbucket.org/luciad/libgpkg




Doug

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

Re: [GRASS-dev] rast_open_new() saturates after opening 127 temporary files

[Newcomb, Doug]

See here ( entry and comments)
http://www.cyberciti.biz/faq/linux-unix-nginx-too-many-open-files/
It's  a 3 step process on Ubuntu.
1) Check the settings for fs.file-max in /etc/sysctl.conf
2)Edit /etc/security/limits.conf and bump up the file limit for the userid
that you run GRASS under.  I bumped mine up to 1 for hard and soft
3) Add session required pam_limits.so to /etc/pam.d/common-session

Doug



On Wed, May 29, 2013 at 8:03 AM, Markus Neteler nete...@osgeo.org wrote:

 On Wed, May 29, 2013 at 4:34 AM, Yann Chemin yche...@gmail.com wrote:
  Hi,
 
  Linux: Ubuntu 13.04
  ulimit: open files  (-n) 1024
 
 
  from :
 http://www.itworld.com/operating-systems/317369/setting-limits-ulimit
 
  -n The maximum number of open file descriptors (most systems
 do not allow this value to be set)
 
  indeed:
  ulimit -n unlimited
  bash: ulimit: open files: cannot modify limit: Operation not permitted

 See also here:


 http://grasswiki.osgeo.org/wiki/Large_raster_data_processing#Number_of_open_files_limitation

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

Re: [GRASS-dev] Rast_open_new_null()

[Newcomb, Doug]

Yann,
You could just use r.reclass  on an existing layer and set everything to
NULL,
http://grass.osgeo.org/grass64/manuals/r.reclass.html

Doug



On Mon, May 27, 2013 at 11:38 PM, Yann Chemin yche...@gmail.com wrote:

 Hi,

 is there a small way to open a new file and set all values to NULL?
 The function would be something like Rast_open_new_null(),

 Yann

 --
 

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

[GRASS-dev] Pausing of wxGUI with commands that use v.category fro large point sets

[Newcomb, Doug]

Hi Folks,
I've noticed that for point data sets  about 200 million points and above ,
all open windows using the  WxGUI are frozen when I use commands that call
v.category on the back end ( v.info, v.surf.rst, etc) until v.category
finishes.  I was going to file it in trac , but I was just wondering if I
should be listing it under enhancement or bug?  I can understand the
individual window freezing, but the entire group of windows freezing seemed
odd.

Doug



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

Re: [GRASS-dev] GRASS 6.4.3 release planning

[Newcomb, Doug]

Will development of GRASS 7 be proceeding to a release in parallel to 6.4.4?

Doug


On Wed, May 1, 2013 at 8:20 AM, Markus Neteler nete...@osgeo.org wrote:

 Hi,

 since RC3 was published some days ago and since there are no more blockers:


 http://trac.osgeo.org/grass/query?status=newstatus=assignedstatus=reopenedgroup=typeorder=prioritypriority=blockerpriority=criticalmilestone=6.4.3milestone=6.4.2milestone=6.4.1milestone=6.4.0

 ... we should get GRASS GIS 6.4.3 final out of the doors.

 What's missing, any objections? Remember that 6.4.4 can follow then.

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

Re: [GRASS-dev] GRASS 6.4.3 release planning

[Newcomb, Doug]

Yes, thanks for the reply

Doug



On Wed, May 1, 2013 at 8:39 AM, Markus Neteler nete...@osgeo.org wrote:

 On Wed, May 1, 2013 at 2:32 PM, Newcomb, Doug doug_newc...@fws.gov
 wrote:
  Will development of GRASS 7 be proceeding to a release in parallel to
 6.4.4?

 IMHO the two release branches are independent from each other.
 Both will be maintained for the foreseeable future but not necessarily
 be in sync with the release dates (there is no reason to force that).

 Does this answer the question?

 Markus




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

Re: [GRASS-dev] calculating inverse matrix

[Newcomb, Doug]

Does that require compiling with OpenMP?
Doug

On Tue, Mar 26, 2013 at 1:27 PM, Michael Barton michael.bar...@asu.eduwrote:

  i.pan.sharpen contains python code to do an inverse pca. It uses some of
 the new r.mapcalc capabilities to do parallel processing on multi-core
 processors. So it's pretty fast.

  Michael
 
 C. Michael Barton
 Director, Center for Social Dynamics  Complexity
 Professor of Anthropology, School of Human Evolution  Social Change
 Arizona State University

  voice:  480-965-6262 (SHESC), 480-727-9746 (CSDC)
 fax:  480-965-7671 (SHESC),  480-727-0709 (CSDC)
 www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu











  On Mar 26, 2013, at 4:24 AM, grass-dev-requ...@lists.osgeo.org
  wrote:

  *From: *Martin Landa landa.mar...@gmail.com
  *Subject: **[GRASS-dev] calculating inverse matrix*
  *Date: *March 26, 2013 4:20:08 AM MST
  *To: *GRASS developers list grass-dev@lists.osgeo.org


 Hi all,

 I found several methods in GRASS code which compute inverse matrix

 1) v.generalize


 http://trac.osgeo.org/grass/browser/grass/trunk/vector/v.generalize/matrix.c#L134

 2) i.orto.photo


 http://trac.osgeo.org/grass/browser/grass/trunk/imagery/i.ortho.photo/lib/m_inverse.c#L16

 3) GMath lib (depends on lapack/blas)

 http://trac.osgeo.org/grass/browser/grass/trunk/lib/gmath/la.c#L566

 It would be nice to consolidate it including data structures (modules
 noted above define their own data structures for matrix). In other
 worlds to incorporate v.generalize/i.orto.photo code into GMath lib.
 Any pointers here?

 Thanks, Martin

 --
 Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~landa



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

Re: [GRASS-dev] d.rast.multi ?

[Newcomb, Doug]

Yann,
About all I can recommend is the vrt format tutorial,
http://www.gdal.org/gdal_vrttut.html, gdal,  data model
http://www.gdal.org/gdal_datamodel.html, and driver tutorial,
http://www.gdal.org/gdal_drivertut.html  , etc in the gdal online
documentation. You might look at the existing gdal/GRASS interface code.
I'm not a C programmer yet, so I can't help much there.

Doug

On Tue, Mar 19, 2013 at 10:01 PM, Yann Chemin yann.che...@gmail.com wrote:

 Thank you Doug,

 yes r.patch is a good alternative, but it means writing to disk etc.
 Was more thinking of a display memory thingy.

 Been thinking about the virtual rasters indeed, maybe will have a
 look, any C code page you could direct me to?

 Cheers,
 Yann

 On 20 March 2013 05:39, Newcomb, Doug doug_newc...@fws.gov wrote:
  Yann,
  If I have a large number of layers, I usually do it from a command line
 or
  with a script.  I done r.patch with over 100 layers in one command (
 before
  I discovered gdalbuildvirt :-))
 
  Doug
 
 
  On Tue, Mar 19, 2013 at 4:36 AM, Vaclav Petras wenzesl...@gmail.com
 wrote:
 
  On 19 March 2013 09:31, Yann Chemin yann.che...@gmail.com wrote:
   OK found Ctrl+Shift+L in wxGUI
  
  Yes, it is my favorite feature. I use it even to find and add one map.
 
  However, there is some issue with many layers in layer manager. If you
  load more than 20 (?) layers (maps) only some of them will be
  rendered. There were no investigations; maybe it applies only to
  vectors. And, of course, it is slow.
 
   Thanks !
   Yann
  
   On 19 March 2013 13:56, Yann Chemin yann.che...@gmail.com wrote:
   I am dealing with hourly Microwave data that are not covering the
   whole World in each layer.
  
   To have a decent presentation map of the data, I'd like to get a set
   (say 30-50 layers) displayed in one go.
  
   OK I could do it with the png driver in a script (which is what it
 may
   eventually become), but for the sake of knowledge, is there a GUI
   option to load a (rather large) set of images in one block without
   having to struggle with a cluttered GIS Manager?
  
   Thanks
   Yann
  
   --
   Yann Chemin
   Researcher@IWMI
   Skype/FB: yann.chemin
  
  
  
   --
   Yann Chemin
   Researcher@IWMI
   Skype/FB: yann.chemin
   ___
   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.



 --
 Yann Chemin
 Researcher@IWMI
 Skype/FB: yann.chemin




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

Re: [GRASS-dev] [GRASS-user] minimal wxPython version

[Newcomb, Doug]

By at least, do you mean looking at 2.6, 2.7 or 3.0 as well?

Doug

On Tue, Mar 19, 2013 at 2:04 PM, Michael Barton michael.bar...@asu.eduwrote:

  I think that this is a good idea for GRASS 7. We shouldn't really do it
 with GRASS 6.

  I like going to at least Python 2.5 also.

  Michael
  __
 C. Michael Barton
 Director, Center for Social Dynamics  Complexity
 Professor of Anthropology, School of Human Evolution  Social Change
 Arizona State University
 Tempe, AZ  85287-2402
 USA

  voice:  480-965-6262 (SHESC), 480-727-9746 (CSDC)
 fax:  480-965-7671(SHESC), 480-727-0709 (CSDC)
 www:  http://csdc.asu.edu, http://shesc.asu.edu
 http://www.public.asu.edu/~cmbarton

  On Mar 19, 2013, at 10:58 AM, grass-user-requ...@lists.osgeo.org
  wrote:

  *From: *Anna Kratochvílová kratocha...@gmail.com
  *Subject: **[GRASS-user] minimal wxPython version*
  *Date: *March 19, 2013 6:39:33 AM MST
  *To: *GRASS-dev grass-dev@lists.osgeo.org, GRASS user list 
 grass-u...@lists.osgeo.org


 Hi all,

 I would like to change minimal required version of wxPython [1].
 Currently we support (theoretically) version 2.8.1.1 (released 2007).
 I suggest to change it to 2.8.10.1 (2009), for example 2.8.10.1 was
 shipped with Ubuntu 10.04 LTS. The reason is obvious: wxGUI is limited
 by this requirement. Even the 2.8.10.1 version is pretty old so I
 think this won't hurt anybody. Any objections?

 [1] http://grass.osgeo.org/grass70/source/snapshot/REQUIREMENTS.html


 PS - There is a similar problem with Python version (required 2.4).
 Some interesting features start with 2.5 but usually we can live
 without it. Any opinions?



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

Re: [GRASS-dev] d.rast.multi ?

[Newcomb, Doug]

Yann,
If I have a large number of layers, I usually do it from a command line or
with a script.  I done r.patch with over 100 layers in one command ( before
I discovered gdalbuildvirt :-))

Doug

On Tue, Mar 19, 2013 at 4:36 AM, Vaclav Petras wenzesl...@gmail.com wrote:

 On 19 March 2013 09:31, Yann Chemin yann.che...@gmail.com wrote:
  OK found Ctrl+Shift+L in wxGUI
 
 Yes, it is my favorite feature. I use it even to find and add one map.

 However, there is some issue with many layers in layer manager. If you
 load more than 20 (?) layers (maps) only some of them will be
 rendered. There were no investigations; maybe it applies only to
 vectors. And, of course, it is slow.

  Thanks !
  Yann
 
  On 19 March 2013 13:56, Yann Chemin yann.che...@gmail.com wrote:
  I am dealing with hourly Microwave data that are not covering the
  whole World in each layer.
 
  To have a decent presentation map of the data, I'd like to get a set
  (say 30-50 layers) displayed in one go.
 
  OK I could do it with the png driver in a script (which is what it may
  eventually become), but for the sake of knowledge, is there a GUI
  option to load a (rather large) set of images in one block without
  having to struggle with a cluttered GIS Manager?
 
  Thanks
  Yann
 
  --
  Yann Chemin
  Researcher@IWMI
  Skype/FB: yann.chemin
 
 
 
  --
  Yann Chemin
  Researcher@IWMI
  Skype/FB: yann.chemin
  ___
  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.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS GIS nightly builds

[Newcomb, Doug]

Ok folks,
I am a bit confused now. After setting OMP_NUM_THREADS=1 and exporting, I
get

 100%
v.surf.rst complete.

real 352m46.451s
user 341m14.196s
sys 2m16.477s

Over 100 minutes faster.  So the multiple cores get in each other's way...

Recompiling without OpenMP.


Thanks!

Doug



On Mon, Feb 25, 2013 at 12:14 AM, Hamish hamis...@yahoo.com wrote:

 Hi,

 to test the efficiency (does 650% of the CPU go 6.5x as fast as
 running 100% on a single core?) you can use the OMP_* environment
 variables.  from the bash command line:


 # try running it serially:
 OMP_NUM_THREADS=1
 export OMP_NUM_THREADS
 time g.module ...


 # let OpenMP set number of concurrent threads to number of local CPU cores
 unset OMP_NUM_THREADS
 time g.module ...


 then compare the overall  system time to complete.
 see http://grasswiki.osgeo.org/wiki/OpenMP#Run_time

 if that is horribly inefficient, it will probably be more
 efficient to run multiple (different) jobs serially, at the same
 time. The bash wait command is quite nice for that, waits
 for all backgrounded jobs to complete before going on.

 for r.in.{xyz|lidar|mb} this works quite well for generating
 multiple statistics at the same time, as the jobs will all want
 to read the same part of the input file at the about the same
 time, so it will still be fresh in the disk cache keeping I/O
 levels low.  (see the r3.in.xyz scripts)


 for v.surf.bspline my plan was to put each of the data subregions
 in their own thread; for v.surf.rst my plan was to put each of
 the quadtree squares into their own thread. Since each thread
 introduces a finite amount of time to create and destroy, the
 goal is to make fewer, longer running ones. Anything more than ~
 an order of mangnitude more that the number of cores you have is
 unneeded overhead.

 e.g., processing all satellite bands at the same time is a nice
 efficient win. If you process all 2000 rows of a raster map in
 2000 just-an-instant-to-complete threads, the create/destroy
 overhead to thread survival time really takes its toll.
 Even as thread creation/destruction overheads become more
 efficiently handled by the OSs and compilers, the situation will
 still be the same. The interesting case is OpenCL, where your
 video card can run 500 GPU units..


 Hamish




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

Re: [GRASS-dev] GRASS GIS nightly builds

[Newcomb, Doug]

Hamish,

On Sun, Feb 24, 2013 at 1:41 AM, Hamish hamis...@yahoo.com wrote:

 Doug wrote:
  Compiled with openmp and liblas?

 fwiw I would not really recommend to compile with OpenMP support
 unless you are willing to help develop that. Most of it is fine I
 think, but the LU parts used by v.surf.rst and v.surf.bspline are
 not very efficient, overhead is like 70%. So you do get a little speedup
 verus single core, but use a lot of power to do it.
 (currently that spawns 10s of thousands of threads when it would be better
 to spawn nearer to the number of local CPU cores)

 I've been playing with generating surfaces at home on an 8 core AMD
vishera system 3.5 ghz Ubuntu 12.04 system with G7  using this point layer:

++
 | Name:nc_2a
  |
 | Mapset:  PERMANENT
  |
 | Location:nc_stpft
   |
 | Database:/data2/grass70_data
  |
 | Title:
  |
 | Map scale:   1:1
  |
 | Name of creator: dnewcomb
   |
 | Organization:
   |
 | Source date: Sat Feb 23 08:16:54 2013
   |
 | Timestamp (first layer): none
   |
 ||
 | Map format:  native
   |
 ||
 |   Type of map: vector (level: 1)
  |
 |
   |
 |   Number of points:   73232338Number of centroids:  0
   |
 |   Number of lines:0   Number of boundaries: 0
   |
 |   Number of areas:0   Number of islands:0
   |
 |   Number of faces:0   Number of kernels:0
   |
 |   Number of volumes:  0   Number of holes:  0
   |
 |
   |
 |   Map is 3D:  Yes
   |
 |   Number of dblinks:  0
   |
 |
   |
 |   Projection: Lambert Conformal Conic
   |
 |
   |
 |   N: 694901.76S: 482704.72
  |
 |   E: 580721.99W: 492486.01
  |
 |   B:   1083.51T:   5558.44
  |
 |
   |
 |   Digitization threshold: 0
   |
 |   Comment:
  |
 |
   |
 ++
(Sat Feb 23 09:49:39 2013) Command finished (34 sec)
--
I get the following 20ft resolution surface using v.usrf.bspline

-
r.info map=nc_2_bspline_cubic@PERMANENT

 ++
 | Layer:nc_2_bspline_cubic@PERMANENT   Date: Sat Feb 23 19:13:29 2013
   |
 | Mapset:   PERMANENT  Login of Creator: dnewcomb
   |
 | Location: nc_stpft
  |
 | DataBase: /data2/grass70_data
   |
 | Title:bicubic interpolation with Tykhonov regularization (
nc_2_bsplin |
 | Timestamp: none
   |
 ||
 |
   |
 |   Type of Map:  raster   Number of Categories: 0
  |
 |   Data Type:DCELL
   |
 |   Rows: 10568
   |
 |   Columns:  4412
  |
 |   Total Cells:  46626016
  |
 |Projection: Lambert Conformal Conic
  |
 |N: 693610S: 482260   Res: 19.99905375
  |
 |E: 580722W: 492486   Res: 19.99909338
  |
 |   Range of data:min = 92.2649807704968  max = 5558.35850509857
  |
 |
   |
 |   Data Description:
   |
 |generated by v.surf.bspline
  |
 |
   |
 |   Comments:
   |
 |v.surf.bspline -z input=nc_2a@PERMANENT layer=1 raster_output=n\
  |
 |c_2_bspline_cubic sie=40.0 sin=40.0 method=bicubic lambda_i=0.01 \
  |
 |solver=cholesky maxit=200 error=0.01 memory=3000
   |
 |
   |
 ++
(Sun Feb 24 19:53:17 2013) Command finished (0 sec)



subregion 920 of 920...
v.surf.bspline complete.
(Sun Feb 24 08:39:12 2013) Command finished (805 min 43 sec)
--

As you can see , the surface generation ran in 805 minutes.  I'm currently
rerunning the analysis with maxit = 100 to see how long it takes with the
iterations lowered.

Now with v.surf.rst, I generated the following grid:


-
---+
 | Layer:nc_2_rst_npmin_120@PERMANENT   Date: Sat Feb 23 01:14:43 2013
   |
 | Mapset:   PERMANENT  

Re: [GRASS-dev] how to sample a series at one location?

[Newcomb, Doug]

t.create-- t.register-- t.vect.observer.strds   in GRASS7 ?   Looks
really nifty, could be useful with the Landsat Cube data sets
http://landsat.usgs.gov/documents/Oct27_29_2009_huang_LST_boston.pptview-source:http://landsat.usgs.gov/documents/Oct27_29_2009_huang_LST_boston.ppt



Doug


On Fri, Feb 22, 2013 at 2:53 PM, Michael Barton michael.bar...@asu.eduwrote:

  Thanks Doug,

  I knew I could do it with a script and v.what.rast.

  What I was hoping was that there is a shortcut already usable in GRASS
 modules. Looks like the new temporal GIS tools may be able to do it.

  Michael
  __
 C. Michael Barton
 Director, Center for Social Dynamics  Complexity
 Professor of Anthropology, School of Human Evolution  Social Change
 Arizona State University
 Tempe, AZ  85287-2402
 USA

  voice:  480-965-6262 (SHESC), 480-727-9746 (CSDC)
 fax:  480-965-7671(SHESC), 480-727-0709 (CSDC)
 www:  http://csdc.asu.edu, http://shesc.asu.edu
 http://www.public.asu.edu/~cmbarton

  On Feb 22, 2013, at 12:31 PM, Newcomb, Doug doug_newc...@fws.gov
  wrote:

  Michael,
 You could use v.what.rast  in a python script , iterating the raster
 layers with an sqlite database back end.  I think that would go up to 2000
 columns for each point you have.

  Alternatively, you could use a bit of python with gdal.  I was trying to
 do something similar in GRASS, to change the Z value of each point in a
 text LiDAR file, from absolute above sea level to relative the elevation of
 the ground.  For 25.5 billion text points and a Statewide 20 ft elevation
 grid (6.5 ? billion cells) , it was a bit slow using r.what.  So I
 converted the LiDAR data to (7)  3.3 billion point  LAS format files and
 exported the GRASS layer to an Erdas imagine format file and wrote the
 following ugly python script:

  #!/usr/bin/python
 import os,string,glob,re,gdal
 from liblas import file
 from liblas import header
 from liblas import point
 from gdalconst import *
 h=header.Header()
 #enter the LAS point file name
 infile=raw_input(Enter the input lidar data points file: )
 #Hardcoded edras imagine file, you will have to use an array for the
 different data layer names
 imgfile=/gisdata2/raster/allnc_20ft_el.img
 #print suggest /gisdata2/raster for output dir\n
 inarr=infile.split('.')
 #This sets the LAS output file, substitute your output text file instead
 outfil=inarr[0]+_norm.las
 #outfil=raw_input(Enter output text file name: )
 #This part reads the LAS file, if you
 l=file.File(infile,mode='r')
 #Outputs the LAS file
 lout=file.File(outfil,mode='w',header=h)
 # register all of the drivers, hopefully your gdal speaks GRASS
 gdal.AllRegister()
 #opening and closing the image layers might take some time if you are
 reading thousands of images
 ds=gdal.Open(imgfile,GA_ReadOnly)
 if ds is None:
 print 'Could not open image'
 sys.exit(1)
 # get image size
 rows = ds.RasterYSize
 cols = ds.RasterXSize
 bands = ds.RasterCount
 # get georeference info, not sure how this would work for GRASS data layers
 transform = ds.GetGeoTransform()
 xOrigin = transform[0]
 yOrigin = transformAsArray(xOffset, yOffset, 1, 1)
 pixelWidth = transform[1]
 pixelHeight = transform[5]
  for p in l:
 x=float(p.x)
 y=float(p.y)
 z=float(p.z)
 # compute pixel offset
 xOffset = int((x - xOrigin) / pixelWidth)
 yOffset = int((y - yOrigin) / pixelHeight)
 band = ds.GetRasterBand(1) # 1-based index 0? 1?
 data = band.Readr(value) :continue
 value = data[0,0]
 #print value,11,\n
 if nan in st[3]
 znorm = z-value
 #print znorm,\n
 pt=point.Point()
 pt.x=p.x
 pt.y=p.y
 pt.z=znorm
 lout.write(pt)

  l.close()
 lout.close()
 #25561312019 points in allreturns

  This managed to process everything over a weekend( in 7 parallel
 threads), which was fast enough for me at the time.  Approaching your
 problem , if your data layers are all n GRASS and your version of gdal can
 read GRASS data layers,  I would grab the list of GRASS layers via glob and
 iterate the layers , writing the name of the raster layer and the value of
 the raster layer at the point coordinates out to a text file as you state
 below.

  Hope this helps,
 Doug


 On Fri, Feb 22, 2013 at 1:23 PM, Michael Barton michael.bar...@asu.eduwrote:

 But I want to do it with a time series of hundreds or thousands of maps.

 Michael
 __
 C. Michael Barton
 Director, Center for Social Dynamics  Complexity
 Professor of Anthropology, School of Human Evolution  Social Change
 Arizona State University
 Tempe, AZ  85287-2402
 USA

 voice:  480-965-6262 (SHESC), 480-727-9746 (CSDC)
 fax:  480-965-7671(SHESC), 480-727-0709 (CSDC)
 www:http://csdc.asu.edu, http://shesc.asu.edu
 http://www.public.asu.edu/~cmbarton

  On Feb 22, 2013, at 10:53 AM, Markus Neteler nete...@osgeo.org
   wrote:

  On Fri, Feb 22, 2013 at 6:41 PM, Michael Barton michael.bar...@asu.edu
 wrote

Re: [GRASS-dev] how to sample a series at one location?

[Newcomb, Doug]

Soren,
What a great Friday afternoon brain stretch!  Thanks!

Doug


On Fri, Feb 22, 2013 at 4:13 PM, Sören Gebbert soerengebb...@googlemail.com
 wrote:

 Hi,
 Am 22.02.2013 21:44 schrieb Newcomb, Doug doug_newc...@fws.gov:

 
  t.create-- t.register-- t.vect.observer.strds   in GRASS7 ?   Looks
 really nifty, could be useful with the Landsat Cube data sets
 http://landsat.usgs.gov/documents/Oct27_29_2009_huang_LST_boston.ppt

 Yes, thats the idea. I totally forgot, I made I short presentation and
 tutorial at the geostat in 2012:
 http://www.geostat-course.org/Topic_Gebbert

 The presentation and the scripts are available there. The
 t.vect.observe.strds example is in part three of the presentation. The cool
 thing is that t.vect.observe.strds uses time stamped attribute tables to
 store the values.

 Best regards
 Soeren

 
 
 
  Doug
 
 
  On Fri, Feb 22, 2013 at 2:53 PM, Michael Barton michael.bar...@asu.edu
 wrote:
 
  Thanks Doug,
 
  I knew I could do it with a script and v.what.rast.
 
  What I was hoping was that there is a shortcut already usable in GRASS
 modules. Looks like the new temporal GIS tools may be able to do it.
 
  Michael
  __
  C. Michael Barton
  Director, Center for Social Dynamics  Complexity
  Professor of Anthropology, School of Human Evolution  Social Change
  Arizona State University
  Tempe, AZ  85287-2402
  USA
 
  voice:  480-965-6262 (SHESC), 480-727-9746 (CSDC)
  fax:  480-965-7671(SHESC), 480-727-0709 (CSDC)
  www:  http://csdc.asu.edu, http://shesc.asu.edu
  http://www.public.asu.edu/~cmbarton
 
  On Feb 22, 2013, at 12:31 PM, Newcomb, Doug doug_newc...@fws.gov
   wrote:
 
  Michael,
  You could use v.what.rast  in a python script , iterating the raster
 layers with an sqlite database back end.  I think that would go up to 2000
 columns for each point you have.
 
  Alternatively, you could use a bit of python with gdal.  I was trying
 to do something similar in GRASS, to change the Z value of each point in a
 text LiDAR file, from absolute above sea level to relative the elevation of
 the ground.  For 25.5 billion text points and a Statewide 20 ft elevation
 grid (6.5 ? billion cells) , it was a bit slow using r.what.  So I
 converted the LiDAR data to (7)  3.3 billion point  LAS format files and
 exported the GRASS layer to an Erdas imagine format file and wrote the
 following ugly python script:
 
  #!/usr/bin/python
  import os,string,glob,re,gdal
  from liblas import file
  from liblas import header
  from liblas import point
  from gdalconst import *
  h=header.Header()
  #enter the LAS point file name
  infile=raw_input(Enter the input lidar data points file: )
  #Hardcoded edras imagine file, you will have to use an array for the
 different data layer names
  imgfile=/gisdata2/raster/allnc_20ft_el.img
  #print suggest /gisdata2/raster for output dir\n
  inarr=infile.split('.')
  #This sets the LAS output file, substitute your output text file
 instead
  outfil=inarr[0]+_norm.las
  #outfil=raw_input(Enter output text file name: )
  #This part reads the LAS file, if you
  l=file.File(infile,mode='r')
  #Outputs the LAS file
  lout=file.File(outfil,mode='w',header=h)
  # register all of the drivers, hopefully your gdal speaks GRASS
  gdal.AllRegister()
  #opening and closing the image layers might take some time if you are
 reading thousands of images
  ds=gdal.Open(imgfile,GA_ReadOnly)
  if ds is None:
  print 'Could not open image'
  sys.exit(1)
  # get image size
  rows = ds.RasterYSize
  cols = ds.RasterXSize
  bands = ds.RasterCount
  # get georeference info, not sure how this would work for GRASS data
 layers
  transform = ds.GetGeoTransform()
  xOrigin = transform[0]
  yOrigin = transformAsArray(xOffset, yOffset, 1, 1)
  pixelWidth = transform[1]
  pixelHeight = transform[5]
  for p in l:
  x=float(p.x)
  y=float(p.y)
  z=float(p.z)
  # compute pixel offset
  xOffset = int((x - xOrigin) / pixelWidth)
  yOffset = int((y - yOrigin) / pixelHeight)
  band = ds.GetRasterBand(1) # 1-based index 0? 1?
  data = band.Readr(value) :continue
  value = data[0,0]
  #print value,11,\n
  if nan in st[3]
  znorm = z-value
  #print znorm,\n
  pt=point.Point()
  pt.x=p.x
  pt.y=p.y
  pt.z=znorm
  lout.write(pt)
 
  l.close()
  lout.close()
  #25561312019 points in allreturns
 
  This managed to process everything over a weekend( in 7 parallel
 threads), which was fast enough for me at the time.  Approaching your
 problem , if your data layers are all n GRASS and your version of gdal can
 read GRASS data layers,  I would grab the list of GRASS layers via glob and
 iterate the layers , writing the name of the raster layer and the value of
 the raster layer at the point coordinates out to a text file as you state
 below.
 
  Hope this helps,
  Doug
 
 
  On Fri, Feb 22, 2013 at 1:23 PM, Michael Barton 
 michael.bar...@asu.edu wrote:
 
  But I want to do

Re: [GRASS-dev] Ignored enhancements

[Newcomb, Doug]

Seth,

I appreciate the effort.  Working with  large rasters, this will make a big
difference!

Doug


On Sun, Feb 10, 2013 at 9:18 PM, Seth Price s...@pricepages.org wrote:

 They should. I didn't really make any changes to the calculations, I just
 rearranged the code to make it more processor and compiler friendly.

 ~Seth


 via iPhone

 On Feb 9, 2013, at 3:27 PM, Newcomb, Doug doug_newc...@fws.gov wrote:

 Seth,
 I finally got a chance to patch your enhancements from the GRASS 70 svn
 code I pulled last night.

 I compiled with these options:
 ./configure --with-gdal  --with-freetype
 --with-freetype-includes=/usr/include/freetype2 --with-proj   --with-sqlite
 --enable-largefile --with-cxx --enable-64bit  --with-python  --with-blas
 --with-lapack  --with-cairo  --with-wxwidgets --with-spatialite
 --with-tcltk --with-tcltk-includes=/usr/include/tcl8.4
 --with-liblas=/usr/local/bin/liblas-config --enable-largefile --with-openmp
 --with-readline

 The computer uses an AMD Vishera 8 core cpu with 8GB DDR3 1333 RAM  (
 freshly updated home machine)


 I used this 23 million cell raster of 20ft bare earth elevation in the
 mountains of western North Carolina.


  Layer:nc_1@PERMANENT Date: Thu Jul  5 20:56:51 2012
|
  | Mapset:   PERMANENT  Login of Creator: dnewcomb
|
  | Location: ncstpft
|
  | DataBase: /data1/grass7
|
  | Title:bilinear interpolation with Tykhonov regularization ( nc_1 )
 |
  | Timestamp: none
|

  
 ||
  |
|
  |   Type of Map:  raster   Number of Categories: 7000
|
  |   Data Type:DCELL
|
  |   Rows: 5328
 |
  |   Columns:  4375
 |
  |   Total Cells:  2331
 |
  |Projection: Lambert Conformal Conic
 |
  |N: 593000S: 486439   Res: 20.00018769
 |
  |E: 492500W: 405000   Res:20
 |
  |   Range of data:min = -8269.7102472716  max = 6999.76272107517
 |
  |
|
  |   Data Description:
|
  |generated by v.surf.bspline
 |
  |
|
  |   Comments:
|
  |v.surf.bspline -z input=nc_1@PERMANENT raster=nc_1 sie=40
 sin=40\   |
  | method=bilinear lambda_i=0.01 layer=1 solver=cholesky
 maxit=1\   |
  |00 error=0.01 memory=300
|
  |
|

  
 ++


 First, with the default GRASS 7 svn pull from 2/9

 GRASS 7.0.svn (ncstpft):~  time r.horizon -d elevin=nc_1 horizonstep=90
 horizon=test_normal
 Calculating map 1 of 4 (angle 0.00, raster map test_normal_0)
  100%
 Calculating map 2 of 4 (angle 90.00, raster map test_normal_1)
  100%
 Calculating map 3 of 4 (angle 180.00, raster map test_normal_2)
  100%
 Calculating map 4 of 4 (angle 270.00, raster map test_normal_3)
  100%

 real 16m14.028s
 user 16m11.993s
 sys 0m1.860s


 Second, patching r.horizon main.c with the diff file from your patch.

 GRASS 7.0.svn (ncstpft):~  time r.horizon -d elevin=nc_1 horizonstep=90
 horizon=test_price
 Calculating map 1 of 4 (angle 0.00, raster map test_price_0)
  100%
 Calculating map 2 of 4 (angle 90.00, raster map test_price_1)
  100%
 Calculating map 3 of 4 (angle 180.00, raster map test_price_2)
  100%
 Calculating map 4 of 4 (angle 270.00, raster map test_price_3)
  100%

 real 14m22.607s
 user 14m20.582s
 sys 0m1.836s

 Using r.mapcal to subtract the normal r.horizon calculation from the
 modified calculation shows 0 difference between the two results

 I usually run r.horizon on a 755 million cell grid and do 24 horizons, I
 am assuming the the benefits would scale proportionally?


 Doug



 On Mon, Feb 4, 2013 at 12:40 PM, Seth Price s...@pricepages.org wrote:

 A while ago I made some simple, but significant, enhancements and
 submitted them to trac. They haven't been picked up, so I wanted to point
 them out so someone can commit them before they diverge from the trunk.

 http://trac.osgeo.org/grass/ticket/1624

 This has had some activity recently, but it's status is still new and
 it isn't in trunk.

 http://trac.osgeo.org/grass/ticket/1575

 ~Seth


 via iPhone

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




-- 
Doug Newcomb
USFWS
Raleigh, NC
919-856-4520 ext. 14 doug_newc...@fws.gov
-
The opinions I express

Re: [GRASS-dev] Ignored enhancements

[Newcomb, Doug]

Seth,
I finally got a chance to patch your enhancements from the GRASS 70 svn
code I pulled last night.

I compiled with these options:
./configure --with-gdal  --with-freetype
--with-freetype-includes=/usr/include/freetype2 --with-proj   --with-sqlite
--enable-largefile --with-cxx --enable-64bit  --with-python  --with-blas
--with-lapack  --with-cairo  --with-wxwidgets --with-spatialite
--with-tcltk --with-tcltk-includes=/usr/include/tcl8.4
--with-liblas=/usr/local/bin/liblas-config --enable-largefile --with-openmp
--with-readline

The computer uses an AMD Vishera 8 core cpu with 8GB DDR3 1333 RAM  (
freshly updated home machine)


I used this 23 million cell raster of 20ft bare earth elevation in the
mountains of western North Carolina.


 Layer:nc_1@PERMANENT Date: Thu Jul  5 20:56:51 2012
 |
 | Mapset:   PERMANENT  Login of Creator: dnewcomb
   |
 | Location: ncstpft
   |
 | DataBase: /data1/grass7
   |
 | Title:bilinear interpolation with Tykhonov regularization ( nc_1 )
  |
 | Timestamp: none
   |
 ||
 |
   |
 |   Type of Map:  raster   Number of Categories: 7000
   |
 |   Data Type:DCELL
   |
 |   Rows: 5328
  |
 |   Columns:  4375
  |
 |   Total Cells:  2331
  |
 |Projection: Lambert Conformal Conic
  |
 |N: 593000S: 486439   Res: 20.00018769
  |
 |E: 492500W: 405000   Res:20
  |
 |   Range of data:min = -8269.7102472716  max = 6999.76272107517
  |
 |
   |
 |   Data Description:
   |
 |generated by v.surf.bspline
  |
 |
   |
 |   Comments:
   |
 |v.surf.bspline -z input=nc_1@PERMANENT raster=nc_1 sie=40 sin=40\
  |
 | method=bilinear lambda_i=0.01 layer=1 solver=cholesky maxit=1\
  |
 |00 error=0.01 memory=300
   |
 |
   |
 ++


First, with the default GRASS 7 svn pull from 2/9

GRASS 7.0.svn (ncstpft):~  time r.horizon -d elevin=nc_1 horizonstep=90
horizon=test_normal
Calculating map 1 of 4 (angle 0.00, raster map test_normal_0)
 100%
Calculating map 2 of 4 (angle 90.00, raster map test_normal_1)
 100%
Calculating map 3 of 4 (angle 180.00, raster map test_normal_2)
 100%
Calculating map 4 of 4 (angle 270.00, raster map test_normal_3)
 100%

real 16m14.028s
user 16m11.993s
sys 0m1.860s


Second, patching r.horizon main.c with the diff file from your patch.

GRASS 7.0.svn (ncstpft):~  time r.horizon -d elevin=nc_1 horizonstep=90
horizon=test_price
Calculating map 1 of 4 (angle 0.00, raster map test_price_0)
 100%
Calculating map 2 of 4 (angle 90.00, raster map test_price_1)
 100%
Calculating map 3 of 4 (angle 180.00, raster map test_price_2)
 100%
Calculating map 4 of 4 (angle 270.00, raster map test_price_3)
 100%

real 14m22.607s
user 14m20.582s
sys 0m1.836s

Using r.mapcal to subtract the normal r.horizon calculation from the
modified calculation shows 0 difference between the two results

I usually run r.horizon on a 755 million cell grid and do 24 horizons, I am
assuming the the benefits would scale proportionally?


Doug



On Mon, Feb 4, 2013 at 12:40 PM, Seth Price s...@pricepages.org wrote:

 A while ago I made some simple, but significant, enhancements and
 submitted them to trac. They haven't been picked up, so I wanted to point
 them out so someone can commit them before they diverge from the trunk.

 http://trac.osgeo.org/grass/ticket/1624

 This has had some activity recently, but it's status is still new and it
 isn't in trunk.

 http://trac.osgeo.org/grass/ticket/1575

 ~Seth


 via iPhone

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

Re: [GRASS-dev] Parallel computing for r.sun

[Newcomb, Doug]

I would vote for multicore OpenMP/OPENCL.  I just purchased an 8 core AMD
Vishera MB and CPU combo for under $300US to use at home , which is faster
than the 8 core Xeon server system I used to do statewide solar irradiation
modeling at work  for a 755 Million cell grid for 365 days (half hour
increments)  in 2011. With the advances in multicore architecture ( who
knows what core densities ARM will bring?) and utilization of the
processing elements in video cards, I think you will benefit many more
users on going the multicore route.

Doug

On Tue, Jan 29, 2013 at 8:05 AM, Ruzicka Jan jan.ruzi...@vsb.cz wrote:

 Dear developers,

 We are planning to rewrite the module r.sun for parallel computation and
 would like to ask you, which platform is more desired by the GRASS
 community. To our understanding there are two main ways of development.
 Either we design it for multi-core desktop systems that use shared memory
 (for example with use of OpenMP) or create module for large clusters with
 use of MPI library.

 Which way do you think would benefit GRASS more?

 Best regards

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

Re: [GRASS-dev] [GRASS GIS] #1798: all relevant vector modules should have cats and where parameters

[Newcomb, Doug]

I guess the question is, if you then performed v.rast.stats for an
underlying raster using the overlapping buffers generated with -t , how
would the statistics for the overlapped polygons work?  Think 2 1km circles
whose centers are .75km apart.

Doug

On Thu, Nov 15, 2012 at 7:51 AM, Markus Metz
markus.metz.gisw...@gmail.comwrote:

 [replying outside ticket #1798 because it's a bit off-topic ]

 On Thu, Nov 15, 2012 at 9:12 AM, GRASS GIS t...@osgeo.org wrote:
 
   Imagine the case where you have 100 points and want to create individual
   buffers around each, i.e. you can't call v.buffer on all at once as this
   will fusion the buffers.

 Buffers are not fused if you use the new -t flag with v.buffer which
 preserves categories and attributes of the input vector. The resulting
 areas may have more than one category per layer (one for each original
 input feature). An example is in the manual.

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