Re: [GRASS-dev] [GRASS GIS] #3356: v.to.db: incorrect area calculations in lat-long location

[GRASS GIS]

#3356: v.to.db: incorrect area calculations in lat-long location
--+---
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.4.0
 Component:  Vector   |Version:  svn-trunk
Resolution:   |   Keywords:  v.to.db area lat-long
   CPU:  Unspecified  |   Platform:  Unspecified
--+---

Comment (by mlennert):

 Replying to [comment:8 mmetz]:
 > Replying to [comment:7 mmetz]:
 > > Replying to [comment:6 mlennert]:
 > > > Replying to [comment:5 annakrat]:
 > > >
 > > > > But the area computation problem must be somewhere in
 [https://grass.osgeo.org/programming7
 > > > >/area__poly1_8c.html#af6f1f53bacc34249be98006c95369695
 G_ellipsoid_polygon_area], probably related
 > > > > to very small numbers, but I couldn't pinpoint the problem. There
 is something specific about this
 > > > > polygon, when I draw a similar one, it gives more reasonable
 results.
 > > >
 > > > So, yes, this definitely seems to be a precision issue, but at this
 stage I can't really see where in the source code, and don't have much
 time to delve into it in greater detail. Maybe MarkusM has an idea ?
 > >
 > > The problem seems to be in G_ellipsoid_polygon_area() at
 [https://trac.osgeo.org/grass/browser/grass/trunk/lib/gis/area_poly1.c#L161
 L161]. If dy is much smaller than dx, dx / dy becomes very large and
 erroneus values might sneak in. A simple solution could be to set dy to
 zero if dy is very small, but then how to define "very small"?
 Interestingly, dx must not be snapped to zero, otherwise I get complete
 nonsense results for the test shapefile.
 >
 > Apparently small differences in latitudes of adjacent vertices can cause
 a wrong latitude correction in G_ellipsoid_polygon_area(). Please try
 trunk r71167.
 >
 > Note that this does not affect areas created with v.in.region, but this
 fix also affects larger areas such as country boundaries.

 Thanks for the quick find !

 I tested and compared with the results of the R
 [https://cran.r-project.org/package=geosphere geosphere] package (which
 apparently uses [https://geographiclib.sourceforge.io/ GeographicLib]:

 {{{
 v.to.db poly -p op=area --q
 1|0.126662200952979
 }}}

 In R:

 {{{
 crswgs84=CRS("+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs")
 
poly=readShapePoly("GRASS_area_problem/training_single.shp",proj4string=crswgs84,verbose=TRUE)
 areaPolygon(poly)
 [1] 0.1262853
 }}}

 Don't know if there are other "authoritative" programs to measure the area
 of this polygon ? At one point, I guess it comes down to floating point
 precision used in the different stages of the algorithm...

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3350: wxGUI: map decorations are not removed when creating new workspace (Ctrl-N)

[GRASS GIS]

#3350: wxGUI: map decorations are not removed when creating new workspace 
(Ctrl-N)
--+---
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  normal   |  Milestone:  7.2.2
 Component:  wxGUI|Version:  svn-trunk
Resolution:  fixed|   Keywords:  wxGUI display decorations
   CPU:  Unspecified  |   Platform:  Unspecified
--+---
Changes (by annakrat):

 * status:  new => closed
 * resolution:   => fixed


--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3350: wxGUI: map decorations are not removed when creating new workspace (Ctrl-N)

[GRASS GIS]

#3350: wxGUI: map decorations are not removed when creating new workspace 
(Ctrl-N)
--+---
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.2.2
 Component:  wxGUI|Version:  svn-trunk
Resolution:   |   Keywords:  wxGUI display decorations
   CPU:  Unspecified  |   Platform:  Unspecified
--+---

Comment (by annakrat):

 In [changeset:"71168" 71168]:
 {{{
 #!CommitTicketReference repository="" revision="71168"
 wxGUI: remove decorations when creating new workspace, see #3350 (merge
 from trunk, r71165)
 }}}

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [SoC] Week 01 Report - Integration Of PDAL into GRASS GIS

[Vaclav Petras]

This is actually a question for PDAL ML, not grass-dev, and Paul was
discussing it there, hence Adam's email.

But anyway, I told Paul not to worry about it for now, because the issue
(linking LAZ libraries to PDAL) is more or less orthogonal to Paul's
project (using PDAL in GRASS).

Thanks all for all the support,
Vaclav

On Wed, Jun 7, 2017 at 3:16 AM, Margherita Di Leo 
wrote:

> Hi Paul,
>
> in grass-dev ML you can likely find guidance, putting it in cc. Thanks.
>
> On Tue, Jun 6, 2017 at 9:51 PM, Paul Schrum  wrote:
>
>> Thank you Adam.
>>
>> I was able to build PDAL from source following instructions at Unix
>> Compilation .  I
>> then ran all of the unit tests based on Testing
>> .
>>
>> Later I realized that I am not able to read .laz files.  Doing so will be
>> essential to my project's success.  The way I know it can't read laz is,
>> from the command line, I enter:
>>
>> pdal info autzen.laz
>>
>> and it responds:
>>
>> PDAL: readers.las: Can't read compressed file without LASzip or LAZperf
>> decompression library.
>>
>> Do I need to download LASzip source and build that, then rebuild pdal?
>>
>> - Paul
>>
>>
>> On Mon, Jun 5, 2017 at 4:53 PM, Adam Steer  wrote:
>>
>>> Hi Paul
>>>
>>> What issues are you having with PDAL and LAZ compression? I don’t know
>>> if I can help for your use case, but I do have a working
>>> PDAL/laszip/laz-perf system natively installed on Linux without docker.
>>>
>>> Also I’m not officially a mentor of your or any project, but happy to
>>> help - and happy to discuss with your mentor(s) also if need be.
>>>
>>> Cheers
>>>
>>> Adam
>>>
>>> --
>>> Dr. Adam Steer
>>> Earth systems data service specialist
>>> National Computational Infrastructure
>>> Leonard Huxley Building, Mills Road
>>> The Australian National University
>>> Acton ACT 2600 Australia
>>>
>>> adam.st...@anu.edu.au
>>> +61 2 6125 1413
>>> http://nci.org.au
>>>
>>>
>>>
>>>
>>> > On 5 Jun 2017, at 11:13 am, Paul Schrum  wrote:
>>> >
>>> > Submitted by Paul Schrum
>>> > Also available at Integration Of PDAL into GRASS GIS
>>> >
>>> >   • What did you get done this week?
>>> >   • Built GRASS73 from source from my local repo directoy.
>>> >   • Stepped into a module (v.in.ascii) using the debugger to watch
>>> it work at the source code level. This was only proving the concept of
>>> stepping into the code – just getting it to work.
>>> >   • Talked with my mentor about the nature of the existing
>>> v.in.pdal module and what are some of the things which must be changed,
>>> fixed, or improved.
>>> >   • What do you plan on doing next week?
>>> >   • Continue stepping through v.in.ascii to see how it works at
>>> the source level in order to understand how to write points to a vectormap.
>>> >   • Get GRASS 73 to link to current version of PDAL.
>>> >   • Fix broken references to PDAL data structures in the GRASS
>>> source
>>> >   • Refactor existing v.in.pdal so that operations which r.in.pdal
>>> and r3.in.pdal will need are in a separate module and available as
>>> functions to be called from all three of them.
>>> >   • Learn the process of calling PDAL and how to get it to do the
>>> basic operation of reading a lidar file and handing over the data to the
>>> caller.
>>> >   • Set up a basic set of test data for PDAL, open it from pdal
>>> without GRASS, then open it using pdal through GRASS with only the most
>>> basic options in operation.
>>> >   • Get PDAL to be able to read .laz (compressed) files. For some
>>> reason it can’t do that after build-from-source.
>>> >   • Are you blocked on anything?
>>> > I had two listed on the Wiki when I originally posted it, but my
>>> mentor helped me work through those before the end of the reporting period
>>> for Week 1. So there are currently no issues blocking me.
>>> >
>>> > ___
>>> > SoC mailing list
>>> > s...@lists.osgeo.org
>>> > https://lists.osgeo.org/mailman/listinfo/soc
>>>
>>>
>>
>> ___
>> SoC mailing list
>> s...@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/soc
>>
>
>
>
> --
> Margherita Di Leo
>
> ___
> 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

Re: [GRASS-dev] [GRASS GIS] #3356: v.to.db: incorrect area calculations in lat-long location

[GRASS GIS]

#3356: v.to.db: incorrect area calculations in lat-long location
--+---
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.4.0
 Component:  Vector   |Version:  svn-trunk
Resolution:   |   Keywords:  v.to.db area lat-long
   CPU:  Unspecified  |   Platform:  Unspecified
--+---

Comment (by mmetz):

 Replying to [comment:7 mmetz]:
 > Replying to [comment:6 mlennert]:
 > > Replying to [comment:5 annakrat]:
 > >
 > > > But the area computation problem must be somewhere in
 [https://grass.osgeo.org/programming7
 > > >/area__poly1_8c.html#af6f1f53bacc34249be98006c95369695
 G_ellipsoid_polygon_area], probably related
 > > > to very small numbers, but I couldn't pinpoint the problem. There is
 something specific about this
 > > > polygon, when I draw a similar one, it gives more reasonable
 results.
 > >
 > > So, yes, this definitely seems to be a precision issue, but at this
 stage I can't really see where in the source code, and don't have much
 time to delve into it in greater detail. Maybe MarkusM has an idea ?
 >
 > The problem seems to be in G_ellipsoid_polygon_area() at
 [https://trac.osgeo.org/grass/browser/grass/trunk/lib/gis/area_poly1.c#L161
 L161]. If dy is much smaller than dx, dx / dy becomes very large and
 erroneus values might sneak in. A simple solution could be to set dy to
 zero if dy is very small, but then how to define "very small"?
 Interestingly, dx must not be snapped to zero, otherwise I get complete
 nonsense results for the test shapefile.

 Apparently small differences in latitudes of adjacent vertices can cause a
 wrong latitude correction in G_ellipsoid_polygon_area(). Please try trunk
 r71167.

 Note that this does not affect areas created with v.in.region, but this
 fix also affects larger areas such as country boundaries.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3331: ctypes: ValueError: invalid literal for int() with base 8: '08420217248550443400745280086994171'

[GRASS GIS]

#3331: ctypes: ValueError: invalid literal for int() with base 8:
'08420217248550443400745280086994171'
--+
  Reporter:  neteler  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.2.2
 Component:  Python   |Version:  unspecified
Resolution:   |   Keywords:  ctypes, python
   CPU:  Unspecified  |   Platform:  Unspecified
--+

Comment (by brunofriedmann):

 I've tried a stupid patch and remove -D_Bool=uint8_t and got never error
 like
 so the culprit is somewhere else.

 {{{
 [   65s] ValueError: invalid literal for int() with base 8:
 '08420217248550443400745280086994171'
 }}}

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3356: v.to.db: incorrect area calculations in lat-long location

[GRASS GIS]

#3356: v.to.db: incorrect area calculations in lat-long location
--+---
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.4.0
 Component:  Vector   |Version:  svn-trunk
Resolution:   |   Keywords:  v.to.db area lat-long
   CPU:  Unspecified  |   Platform:  Unspecified
--+---

Comment (by mmetz):

 Replying to [comment:6 mlennert]:
 > Replying to [comment:5 annakrat]:
 >
 > > But the area computation problem must be somewhere in
 [https://grass.osgeo.org/programming7
 > >/area__poly1_8c.html#af6f1f53bacc34249be98006c95369695
 G_ellipsoid_polygon_area], probably related
 > > to very small numbers, but I couldn't pinpoint the problem. There is
 something specific about this
 > > polygon, when I draw a similar one, it gives more reasonable results.
 >
 > So, yes, this definitely seems to be a precision issue, but at this
 stage I can't really see where in the source code, and don't have much
 time to delve into it in greater detail. Maybe MarkusM has an idea ?

 The problem seems to be in G_ellipsoid_polygon_area() at
 [https://trac.osgeo.org/grass/browser/grass/trunk/lib/gis/area_poly1.c#L161
 L161]. If dy is much smaller than dx, dx / dy becomes very large and
 erroneus values might sneak in. A simple solution could be to set dy to
 zero if dy is very small, but then how to define "very small"?
 Interestingly, dx must not be snapped to zero, otherwise I get complete
 nonsense results for the test shapefile.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [SoC] Week 01 Report - Integration Of PDAL into GRASS GIS

[Margherita Di Leo]

Hi Paul,

in grass-dev ML you can likely find guidance, putting it in cc. Thanks.

On Tue, Jun 6, 2017 at 9:51 PM, Paul Schrum  wrote:

> Thank you Adam.
>
> I was able to build PDAL from source following instructions at Unix
> Compilation .  I
> then ran all of the unit tests based on Testing
> .
>
> Later I realized that I am not able to read .laz files.  Doing so will be
> essential to my project's success.  The way I know it can't read laz is,
> from the command line, I enter:
>
> pdal info autzen.laz
>
> and it responds:
>
> PDAL: readers.las: Can't read compressed file without LASzip or LAZperf
> decompression library.
>
> Do I need to download LASzip source and build that, then rebuild pdal?
>
> - Paul
>
>
> On Mon, Jun 5, 2017 at 4:53 PM, Adam Steer  wrote:
>
>> Hi Paul
>>
>> What issues are you having with PDAL and LAZ compression? I don’t know if
>> I can help for your use case, but I do have a working PDAL/laszip/laz-perf
>> system natively installed on Linux without docker.
>>
>> Also I’m not officially a mentor of your or any project, but happy to
>> help - and happy to discuss with your mentor(s) also if need be.
>>
>> Cheers
>>
>> Adam
>>
>> --
>> Dr. Adam Steer
>> Earth systems data service specialist
>> National Computational Infrastructure
>> Leonard Huxley Building, Mills Road
>> The Australian National University
>> Acton ACT 2600 Australia
>>
>> adam.st...@anu.edu.au
>> +61 2 6125 1413
>> http://nci.org.au
>>
>>
>>
>>
>> > On 5 Jun 2017, at 11:13 am, Paul Schrum  wrote:
>> >
>> > Submitted by Paul Schrum
>> > Also available at Integration Of PDAL into GRASS GIS
>> >
>> >   • What did you get done this week?
>> >   • Built GRASS73 from source from my local repo directoy.
>> >   • Stepped into a module (v.in.ascii) using the debugger to watch
>> it work at the source code level. This was only proving the concept of
>> stepping into the code – just getting it to work.
>> >   • Talked with my mentor about the nature of the existing
>> v.in.pdal module and what are some of the things which must be changed,
>> fixed, or improved.
>> >   • What do you plan on doing next week?
>> >   • Continue stepping through v.in.ascii to see how it works at the
>> source level in order to understand how to write points to a vectormap.
>> >   • Get GRASS 73 to link to current version of PDAL.
>> >   • Fix broken references to PDAL data structures in the GRASS
>> source
>> >   • Refactor existing v.in.pdal so that operations which r.in.pdal
>> and r3.in.pdal will need are in a separate module and available as
>> functions to be called from all three of them.
>> >   • Learn the process of calling PDAL and how to get it to do the
>> basic operation of reading a lidar file and handing over the data to the
>> caller.
>> >   • Set up a basic set of test data for PDAL, open it from pdal
>> without GRASS, then open it using pdal through GRASS with only the most
>> basic options in operation.
>> >   • Get PDAL to be able to read .laz (compressed) files. For some
>> reason it can’t do that after build-from-source.
>> >   • Are you blocked on anything?
>> > I had two listed on the Wiki when I originally posted it, but my mentor
>> helped me work through those before the end of the reporting period for
>> Week 1. So there are currently no issues blocking me.
>> >
>> > ___
>> > SoC mailing list
>> > s...@lists.osgeo.org
>> > https://lists.osgeo.org/mailman/listinfo/soc
>>
>>
>
> ___
> SoC mailing list
> s...@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/soc
>



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