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 S

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

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&data=05%7C01%7Cdoug_newcomb%40fws.gov%7C26a98786f90649a4285708dbb2b18d3e%7C0693b5ba4b184d7b9341f32f400a5494%7C0%7C0%7C638300247899902911%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=TVxcmemqNwNHpsYv%2Fuopx0A6S83s6BcTIt%2FbyR7j3Zw%3D&reserved=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&data=05%7C01%7Cdoug_newcomb%40fws.gov%7C26a98786f90649a4285708dbb2b18d3e%7C0693b5ba4b184d7b9341f32f400a5494%7C0%7C0%7C638300247899902911%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=oMu3BWddkv%2B7%2FrgsY9Di8F7a2P2ZcyTNACaeEZJ61ws%3D&reserved=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.c&data=04%7C01%7Cdoug_newcomb%40fws.gov%7C4f0883ee7d50465461ea08d8a78cf995%7C0693b5ba4b184d7b9341f32f400a5494%7C0%7C0%7C637443571215425088%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Qqzy%2BTGm%2FTciBVpdomqzSW6vcggZMD9vfmvQSV4FDiE%3D&reserved=0
or
https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FOSGeo%2Fgrass%2Fblob%2Fmaster%2Fraster%2Fr.external%2Flink.c&data=04%7C01%7Cdoug_newcomb%40fws.gov%7C4f0883ee7d50465461ea08d8a78cf995%7C0693b5ba4b184d7b9341f32f400a5494%7C0%7C0%7C637443571215425088%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=vQs7F7GNkdpppxsX5iakyWEA64%2FivjqvZx1pbabnFkY%3D&reserved=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&d=DwMFaQ&c=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ&r=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0&m=RNJwSC3Ek5cdtRJHd6gFZPafy1W7295DnIFV2PLj1Rc&s=PDNQmQRROmeASWPaZMGIY-cOGF61Oiqaik2sndDEr3E&e=>,
>> http://csdc.asu.edu
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__csdc.asu.edu&d=DwMFaQ&c=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ&r=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0&m=RNJwSC3Ek5cdtRJHd6gFZPafy1W7295DnIFV2PLj1Rc&s=HpxaY2114FwLS9Om6gka1iDRS6DN9TZYA9JLJ_Poz3o&e=>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ___
>> 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&d=DwMFaQ&c=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ&r=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0&m=RNJwSC3Ek5cdtRJHd6gFZPafy1W7295DnIFV2PLj1Rc&s=Y66kcTxne2TxynSisqnIRiV3sP-LqwYSFQsyrYGImkA&e=>
>
>
>
> --
> 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  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.*​
___
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  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 .


> 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 (0x7f22534da0

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* mailto:direg...@gmail.com
>> >>
>> 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 mailto:a.ghi...@gmail.com>>
>>
>>
>> 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  wrote:

>
> On Mon, Oct 26, 2015 at 1:20 PM, Newcomb, Doug 
> 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]

am to
> delete -gdwarf-2  ## already done
> >>>
> >>> export CXXFLAGS=-stdlib=libstdc++
> >>> ./bootstrap.sh
> --prefix=/Users/cmbarton/Dropbox/GRASS_dropbox/compiling/boost-snow
> --without-libraries=python
> >>>
> >>> ## this worked several years ago but now fails. I DO have the OS X
> 10.7 SDK FWIW
> >>> ./bjam variant=release link=static --without-mpi -j4
> macosx-version=10.7 macosx-version-min=10.7 architecture=x86
> address-model=32_64 install
> >>>
> >>> ## So I tried without specifying the minimum OS and address model.
> This compiled but could be incorrect
> >>> ./bjam variant=release link=static --without-mpi -j4 install
> >>>
> >>> ## This was in my notes but does not seem needed
> >>> Need to manually delete the comma at the end of the list on line 117
> of /boost-snow/include/boost/interprocess/errors.hpp
> >>>
> >>> 3. Then follow instructions at:
> http://www.liblas.org/compilation.html#using-xcode-on-os-x for standard
> install (not xcode)
> >>> from libLAS folder...
> >>>
> >>> cd to liblas source folder
> >>> 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 
> 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
&

Re: [GRASS-dev] New Mac binaries uploaded

[Newcomb, Doug]

Liblas or LASTools?

Doug

On Mon, Aug 24, 2015 at 1:08 PM, Michael Barton 
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 
> 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 
> 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á 
> 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 
> >>>
> >>>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 
> >>>
> >>>from lmgr.layertreeimport LayerTree, LMIcons
> >>>
> >>>  File
> "/Applications/GRASS-7.1.app/Contents/MacOS/gui/wxpython/lmgr/layertree.py",
> line 37, in 
> >>>
> >>>from mapdisp.frameimport MapFrame
> >>>
> >>>  File
> "/Applications/GRASS-7.1.app/Contents/MacOS/gui/wxpython/mapdisp/frame.py",
> line 34, in 
> >>>
> >>>from vdigit.toolbarsimport VDigitToolbar
> >>>
> >>>  File
> "/Applications/GRASS-7.1.app/Contents/MacOS/gui/wxpython/vdigit/toolbars.py",
> line 30, in 
> >>>
> >>>from iclass.digit   import IClassVDigit
> >>>
> >>>  File
> "/Applications/GRASS-7.1.app/Contents/MacOS/gui/wxpython/iclass/digit.py",
> line 23, in 
> >>>
> >>>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 
> > 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 l

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

[Newcomb, Doug]

Markus,
Your efforts to resolve this issue are very much appreciated.

Doug

On Mon, Aug 10, 2015 at 10:08 AM, Markus Neteler  wrote:

> Hi,
>
> just FYI:
>
> root@osgeo6:~# clamscan --infected --remove --recursive /var/www/
>
> --- SCAN SUMMARY ---
> Known viruses: 3930644
> Engine version: 0.98.7
> Scanned directories: 221355
> Scanned files: 1325267
> Infected files: 0  <<<-- !
> Data scanned: 27042.44 MB
> Data read: 35670.30 MB (ratio 0.76:1)
> Time: 1793.563 sec (29 m 53 s)
> Nothing found.
>
> 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] grass.osgeo.org contains harmful programs

[Newcomb, Doug]

Yes,  it's just with Google Chrome.

Unfortunately about 28% of the web is using google chrome,
http://www.netmarketshare.com/browser-market-share.aspx?qprid=1http://www.netmarketshare.com/browser-market-share.aspx?qprid=1
, and will see the red warning until the review process is finished



https://support.google.com/webmasters/answer/168328

https://support.google.com/webmasters/answer/35843




Doug


On Mon, Aug 10, 2015 at 9:11 AM, Vaclav Petras  wrote:

>
> On Mon, Aug 10, 2015 at 8:52 AM, Markus Neteler  wrote:
>
>> On Mon, Aug 10, 2015 at 1:37 PM, Newcomb, Doug 
>> wrote:
>> > Https version is also blacklisted.
>>
>> I know... Maybe avoid the Chrome browser for now.
>
>
> Just for the record: Chromium and Firefox are fine at least today on
> Lubuntu 15.04.
>



-- 
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.osgeo.org contains harmful programs

[Newcomb, Doug]

Https version is also blacklisted.

Doug

On Sun, Aug 9, 2015 at 5:11 PM, Markus Neteler  wrote:

> On Fri, Aug 7, 2015 at 3:55 PM, Anna Petrášová 
> 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  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: ]

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

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

> Hi,
>
> 2015-04-02 17:15 GMT+02:00 Newcomb, Doug :
> > 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

[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] [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  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: 
> GRASS GIS 
>
> ___
> 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á 
wrote:

>
>
> On Thu, Feb 5, 2015 at 10:32 AM, Vincent Bain  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 quick&dirty 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 
wrote:

>
> On Wed, Jan 21, 2015 at 9:28 AM, Markus Neteler  wrote:
>
>> On Wed, Jan 21, 2015 at 11:37 AM, Vincent Bain  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.00"W, 37d50'53.00"N)
Lower Left  ( -86.0947222,  34.5136111) ( 86d 5'41.00"W, 34d30'49.00"N)
Upper Right ( -79.7463889,  37.8480556) ( 79d44'47.00"W, 37d50'53.00"N)
Lower Right ( -79.7463889,  34.5136111) ( 79d44'47.00"W, 34d30'49.00"N)
Center  ( -82.9205556,  36.1808333) ( 82d55'14.00"W, 36d10'51.00"N)
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

  
Red
0
6
  
  
Green
0
7
  
  
Blue
0
8
  
  
Opacity
0
9
  
  
min
0
0
  
  
max
0
0
  
  
Class_Names
2
2
  
  
0
0
0
0
1
1
flat
  
  
220
220
220
255
2
2
summit
  
  
56
0
0
255
3
3
ridge
  
  
200
0
0
255
4
4
shoulder
  
  
255
80
20
255
5
5
spur
  
  
250
210
60
255
6
6
slope
  
  
255
255
60
255
7
7
hollow
  
  
180
230
20
255
8
8
footslope
  
  
60
250
150
255
9
9
valley
  
  
0
0
255
255
10
10
depression
  
  
0
0
56
255
11
11
ERROR
  



-- 
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á 
wrote:

>
>
> On Tue, Sep 23, 2014 at 8:19 AM, Newcomb, Doug 
> 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 
>> 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á 
>>> 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] 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  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á 
> 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]

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á 
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] 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  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á 
wrote:

> Hi,
>
>
> On Tue, Aug 5, 2014 at 11:04 AM, Newcomb, Doug 
> 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á 
>> 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á 
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  wrote:

> Martin Landa wrote
> > Hi,
> >
> > 2014-07-02 13:22 GMT+02:00 Moritz Lennert <
>
> > mlennert@.worldonline
>
> > >:
> >> [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]

[Newcomb, Doug]

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

Doug


On Mon, Jun 30, 2014 at 4:30 AM, Martin Landa 
wrote:

> Hi,
>
> 2014-06-30 9:37 GMT+02:00 Luca Delucchi :
> > 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  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]

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

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  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  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  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] Handling of Python scripts on MS Windows

[Newcomb, Doug]

Hi folks,
A lot of the folks I introduce to GRASS are already GIS users, using a
different GIS software package.  They are unlikely to stop using their
existing software while trying GRASS, have a "spare" computer that would
only have GRASS loaded, or be able to install a virtual instance of windows
to run just GRASS .

In the managed Windows desktop  environment that I work in, there is an
"approved"  mainline proprietary gis that is installed with its own version
of python installed as the system python. I cannot recommend the
installation of any software that interferes with that combination of
software.  The mainline gis, when updated periodically, will also probably
have a new version of python installed, without regards to other geospatial
software that is installed.

If GRASS7 cannot operate reliably in that environment , it is unlikely that
it will be installed in my managed Windows work environment.

I appreciate the ongoing technical discussion and I'm looking forward to a
workable solution.  There are several ways that GRASS7  on Windows could be
( in my personal opinion) an effective tool in my organization.

Doug

On Wed, Apr 30, 2014 at 3:51 AM, Glynn Clements wrote:

>
> Markus Metz wrote:
>
> > >> > By all means provide fall-backs, workarounds, alternatives, or
> > >> > whatever, but anything which tries to make such things mandatory is
> > >> > going to get reverted. Again.
> > >>
> > >> really nice attitude ;-) Martin
> > >
> > > At least I'm not saying "you ARE going to use our version of Python,
> > > whether you like it or not".
> >
> > People installing GRASS want to use GRASS. They want GRASS to work out
> > of the box. They can use any Python version they want, as long as
> > WinGRASS uses its embedded Python version. Users will not notice it.
>
> You're assuming that users have a free choice as to what they install.
> Some sites actually have policies about what software they'll allow on
> their systems.
>
> When it comes to determining those policies, general-purpose
> interpreted languages get a rougher ride than most. Applications which
> bundle private copies of such get an even rougher ride, if they don't
> simply get rejected out of hand.
>
> --
> Glynn Clements 
> ___
> 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.stream.* to trunk - what about r.stream.basins?

[Newcomb, Doug]

Hi Folks,

I very much appreciate the efforts in the code sprint this week!

On Thu, Mar 27, 2014 at 8:54 AM, Helmut Kudrnovsky  wrote:

>
>
>
> 1) to keep r.stream.basins as an add-on, demanding the delineation of
> multiple subbasins from coordinates to a user´s script looping
> r.water.outlet;
> 2) to include r.stream.basins and keep also r.water.outlet;
> 3) to include r.stream.basins in the core and remove r.water.outlet as
> obsolete.
> 4) ?
>
> regards from Vienna
>
> Madi, Helmut
>
> [1] http://grass.osgeo.org/grass70/manuals/addons/r.stream.basins.html
> [2] http://grass.osgeo.org/grass70/manuals/r.water.outlet.html
> [3] http://grass.osgeo.org/grass70/manuals/r.watershed.html


If r.stream.basins can replicate the functionality of r.water.outlet, I
would prefer 3  . Some argument might be made for a conservative approach
for option 2 for version 7.0 and drop r.water.outlet in version 7.1, but
7.0 is in development status. Why not make the change now?


Doug



>
>
>
>
> -
> best regards
> Helmut
> --
> View this message in context:
> http://osgeo-org.1560.x6.nabble.com/r-stream-to-trunk-what-about-r-stream-basins-tp5131543.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] 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 wrote:

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

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

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

>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 wrote:
>
>> Hi,
>>
>> 2014-02-24 20:18 GMT+01:00 Tereza Fiedlerová :
>> > 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]

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

> Hi,
>
> 2014-02-24 20:18 GMT+01:00 Tereza Fiedlerová :
> > 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
wrote:

> On Mon, Jan 27, 2014 at 12:16 AM, Glynn Clements
>  wrote:
> >
> > Markus Metz wrote:
> >
> >> On Sat, Jan 25, 2014 at 3:59 PM, Helena Mitasova 
> 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] G7: v.loutlier Decomposition failed

[Newcomb, Doug]

Are those bare earth points only, or are you feeding it the entire point
cloud?



On Fri, Dec 6, 2013 at 7:17 AM, Blumentrath, Stefan <
stefan.blumentr...@nina.no> wrote:

>  Hi
>
>
>
> Maybe it is not of importance, because no one else would use such extreme
> settings, but in case someone considers it as a bug:
>
>
>
> I was testing a bit with v.outlier in GRASS 7 on dense LiDAR data (~4
> points per m2).
>
>
>
> When I use a very low Tykhonov regularization parameter (lambda_i) of
> 0.001 and rather short spline steps (1.5) at 0.5m
> resolution I get an error-message:
>
> “Decomposition failed at row 16499 and col 0”
>
>  Stefan
>
>
>
> ___
> 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  wrote:

> On Tue, Oct 8, 2013 at 4:31 PM, Markus Metz
>  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 
Date: Tue, Sep 17, 2013 at 3:40 AM
Subject: Re: [LAStools] Datum converson
To: lasto...@googlegroups.com
Cc: "Heidemann, Hans" 


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 ) 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/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 
_ _ _
   /// ___///  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
> Mundt Federal Building

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

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

> On Wed, May 29, 2013 at 4:34 AM, Yann Chemin  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  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]

Yes, thanks for the reply

Doug



On Wed, May 1, 2013 at 8:39 AM, Markus Neteler  wrote:

> On Wed, May 1, 2013 at 2:32 PM, Newcomb, Doug 
> 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] 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  wrote:

> Hi,
>
> since RC3 was published some days ago and since there are no more blockers:
>
>
> http://trac.osgeo.org/grass/query?status=new&status=assigned&status=reopened&group=type&order=priority&priority=blocker&priority=critical&milestone=6.4.3&milestone=6.4.2&milestone=6.4.1&milestone=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] calculating inverse matrix

[Newcomb, Doug]

Does that require compiling with OpenMP?
Doug

On Tue, Mar 26, 2013 at 1:27 PM, Michael Barton wrote:

>  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, 
>  wrote:
>
>  *From: *Martin Landa 
>  *Subject: **[GRASS-dev] calculating inverse matrix*
>  *Date: *March 26, 2013 4:20:08 AM MST
>  *To: *GRASS developers list 
>
>
> 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  * 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] [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 wrote:

>  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, 
>  wrote:
>
>  *From: *Anna Kratochvílová 
>  *Subject: **[GRASS-user] minimal wxPython version*
>  *Date: *March 19, 2013 6:39:33 AM MST
>  *To: *GRASS-dev , 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,
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  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  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 
> wrote:
> >>
> >> On 19 March 2013 09:31, Yann Chemin  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  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] 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  wrote:

> On 19 March 2013 09:31, Yann Chemin  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  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 GSoC idea: the line intersection problem

[Newcomb, Doug]

+1

On Mon, Mar 4, 2013 at 2:54 PM, Markus Metz
wrote:

> I would like to propose a project for the next Google Summer of Code:
>
> The current implementation of Vect_break_lines() is causing a lot of
> headache for larger vector maps with high spatial detail.
> Vect_break_lines() is already much faster in G7 than in G6, but still
> sometimes so slow that the procedure appears to make no progress at
> all. There are a number of published alternatives on to how find
> intersections between two lines, most of them based on the
> Bentley–Ottmann algorithm. The best one or two, according to
> literature review, should be implemented in the GSoC project. Benefit
> to users: faster import of non-topological vectors, faster cleaning of
> vectors with topological errors. Some more detail is on the wiki page
> for GSoC 2013 [0].
>
> Markus M
>
> [0] http://grasswiki.osgeo.org/wiki/GRASS_SoC_Ideas_2013#Vector
> ___
> 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  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  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