Re: [GRASS-dev] [GRASS GIS] #3319: v.overlay: incorrect results with "not" operator

2017-11-10 Thread GRASS GIS 
#3319: v.overlay: incorrect results with "not" operator
--+-
  Reporter:  sbl  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  minor|  Milestone:  7.4.0
 Component:  Vector   |Version:  svn-releasebranch72
Resolution:   |   Keywords:  v.overlay
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by mlennert):

 * priority:  normal => minor


Comment:

 This only bites in rare corner cases, so degrading priority to minor.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Different CRS matching in 7.2 and trunk

2017-11-10 Thread Markus Metz 
On Sat, Nov 11, 2017 at 12:22 AM, Helena Mitasova  wrote:
>
> Please note, that  in spite of the fact that the datum.table shows same
transformation parameters,
> different nad83 datums are different (it is not just a different name for
the same datum) and there are different EPSG codes associated
> with the relevant CRS.
> You can find more about it here (or just google it)
> https://confluence.qps.nl/pages/viewpage.action?pageId=29855153
>
> Supposedly, the shift from NAD83(86) to NAD83(HARN) can be done with the
NGS NADCON program (I have not checked it out)
> (http://www.ngs.noaa.gov/TOOLS/Nadcon/Nadcon.shtml).

There are 12 (!) different definitions for NAD83. What to do about this?
Regard these 12 definitions as different datums? In this case I would need
to reinstate the datum check and we need to add more entries to datum.table.

Markus M

>
> Helena
>
> On Nov 10, 2017, at 5:30 PM, Markus Metz 
wrote:
>
>
>
> On Fri, Nov 10, 2017 at 8:46 PM, Vaclav Petras 
wrote:
> >
> > On Fri, Nov 10, 2017 at 2:21 PM, Markus Metz <
markus.metz.gisw...@gmail.com> wrote:
> > >
> > > > >
> > > > > 7.2 considers this OK while trunk considers this different. I'm
not sure which one is correct.
> > > >
> > > > In this case, 7.2 is correct, but 7.2 does not compare datums, i.e.
projections would be regarded as matching even with e.g. nad27 and nad83.
> > > > The comparison of datums is new in 7.3 and needs some refinement.
> > > >
> > > > I will fix the comparison of swapped lat_1 and lat_2.
> > >
> > > Fixed in trunk r71656.
> > >
> > > The test for different datum names has been disabled again in trunk
r71657. There are several different datum names in lib/gis/datum.table that
apparently mean the same: same ellipsoid and same transformation
parameters. Apparently, GRASS does not provide a datum name when converting
projection information from GRASS to proj4 for reprojecting data.
> >
> >
> > Thank you so much, Markus. This saves me a lot of trouble.
>
> About avoiding trouble, the motivation of the stricter CRS comparison is
to avoid subsequent geolocation errors. If data have been imported and
differences in the CRS were not detected, it can become very difficult
later on in the processing to figure out the reason for geolocation errors
(different data not matching each other spatially). I'm not sure what to do
about different datum names. The current check relies on the test for
differences in ellipsoids.
>
> Markus M
>
> >
> > (I'm working on a Jupyter Notebook where I need trunk.)
> >
https://github.com/wenzeslaus/Notebook-for-processing-point-clouds-in-GRASS-GIS
> >
> > >
> > >
> > > Markus M
> > >
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>
>
> Helena Mitasova
> Professor at the Department of Marine,
> Earth, and Atmospheric Sciences
> and Center for Geospatial Analytics
> North Carolina State University
> Raleigh, NC 27695-8208
> hmit...@ncsu.edu
> http://geospatial.ncsu.edu/osgeorel/publications.html
>
> "All electronic mail messages in connection with State business which are
sent to or received by this account are subject to the NC Public Records
Law 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] [release planning] 7.4.0

2017-11-10 Thread Nikos Alexandris 

* Veronica Andreo  [2017-09-11 18:54:00 +0200]:


Hi all :)

2017-09-02 17:57 GMT+02:00 Markus Neteler :


On Fri, Sep 1, 2017 at 9:56 PM, Martin Landa 
wrote:
> Please all devs try to remember all cool features you implemented for
> G74 and put notes about that on trac wiki page! It will help a lot
> (going through all logs and discover new features is a very hard and
> time consuming job).

Some help for this:
* 24 May 2016 Creation of the GRASS GIS 7.2 release branch (r68500)

To save you some time, I have diff'ed the 7.2.2svn and 7.4.svn



there's no 7.4.svn yet, right? Only trunk (grass73), no?

Changelogs and removed from the result obvious "trivial" changes. The

remainder is here:
https://data.neteler.org/tmp/ChangeLog74_filtered.txt

From browsing this file memories may come back :-)

Please add findings then to
https://trac.osgeo.org/grass/wiki/Grass7/NewFeatures74



I started going through the document to add what I believe might be
relevant stuff to the NewFeatures74 page, but some things in that diff file
were already reported in NewFeatures72, eg: all d.* changes done by Adam
Laza in GSoC 2016... so, I'm (will be) double checking. I wonder however if
it is ok to diff against r68500 or should be a later version (eg.: the
stable version released in December 2016, for example)? No idea



(also screenshots would be great)



yes! As well as some extra description from devs for the new cool features
implemented or examples of use of new features (or important bug fixes)!
That would make it much easier to then write the announcements, promote
grass elsewhere and show off a bit ;-)

cheers,
Vero


Last 100+ lines of https://data.neteler.org/tmp/ChangeLog74_filtered.txt
checked. Majority of entries already included in
https://trac.osgeo.org/grass/wiki/Grass7/NewFeatures72 and/or
https://trac.osgeo.org/grass/log/grass/branches/releasebranch_7_2/.

Few entries added in
https://trac.osgeo.org/grass/wiki/Grass7/NewFeatures74.

Diff file between ChangeLog74_filtered.txt any my review attached.

Nikos

 * raster/r.lake/main.c: r.lake: more guisections* 
raster/r.lake/main.c: r.lake: more guisections
 * gui/wxpython/gmodeler/model.py: g.gui.gmodeler: substitute | [Exclude] * 
gui/wxpython/gmodeler/model.py: g.gui.gmodeler: s
 * vector/v.outlier/main.c: v.outlier: define parser rule for | [Exclude] * 
vector/v.outlier/main.c: v.outlier: define parser
 * include/iostream/mm.h, lib/iostream/mm.cpp: use exception  | [Exclude] * 
include/iostream/mm.h, lib/iostream/mm.cpp: use e
 * raster/r.terraflow/grass2str.h: r.terraflow: add space bet | [Exclude] * 
raster/r.terraflow/grass2str.h: r.terraflow: add 
 * lib/init/helptext.html: helptext.html: improved section ab | [Exclude] * 
lib/init/helptext.html: helptext.html: improved s
 * lib/init/helptext.html: helptext.html: add section about t | [Exclude] * 
lib/init/helptext.html: helptext.html: add sectio
 * lib/init/grass.py: init: fix typo in r68797; advise user a | [Exclude] * 
lib/init/grass.py: init: fix typo in r68797; advi
 * raster/r.topidx/r.topidx.html: r.topidx: Fixed a link  | [Exclude] * 
raster/r.topidx/r.topidx.html: r.topidx: Fixed a 
 * raster/r.topmodel/r.topmodel.html: r.topmodel: Fixed a lin | [Exclude] * 
raster/r.topmodel/r.topmodel.html: r.topmodel: Fi
 * lib/init/grass.py: init: advise user about --help and -c   | [Exclude] * 
lib/init/grass.py: init: advise user about --help
 * gui/wxpython/gui_core/gselect.py, gui/wxpython/modules/imp | [Exclude] * 
gui/wxpython/gui_core/gselect.py, gui/wxpython/mo
 * vector/v.overlay/main.c: v.overlay: avoid fatal error (lay | [Exclude] * 
vector/v.overlay/main.c: v.overlay: avoid fatal e
 * display/d.legend/d.legend.html: d.legend: typo in document | [Exclude] * 
display/d.legend/d.legend.html: d.legend: typo in
 * display/d.legend/d.legend.html, display/d.legend/d_legend_ | [Exclude] * 
display/d.legend/d.legend.html, display/d.legend/
 * display/d.legend/draw.c, display/d.legend/main.c: d.legend | [Exclude] * 
display/d.legend/draw.c, display/d.legend/main.c:
 * gui/wxpython/gui_core/dialogs.py, gui/wxpython/gui_core/fo | [Include][Font 
can be selected interactively in module dialog
 * lib/gis/colors.desc, lib/gis/colors/grass: add GRASS green | [Exclude] * 
lib/gis/colors.desc, lib/gis/colors/grass: add GR
 * gui/wxpython/gui_core/forms.py: wxGUI: fix escape button t | [Exclude] * 
gui/wxpython/gui_core/forms.py: wxGUI: fix escape
 * display/d.legend/draw.c, display/d.legend/local_proto.h, d | [???] * 
display/d.legend/draw.c, display/d.legend/local_p
 * raster/r.info/main.c: r.info: make category title the prim | [Exclude] * 
raster/r.info/main.c: r.info: make category title
 * raster/r.support/main.c: r.support: remove unused variable | [Exclude] * 
raster/r.support/main.c: r.support: remove unused
 * raster/r.support/main.c: r.support: write category title,  | [Exclude] * 
raster/r.support/main.c: r.support: write categor
 * raster/r.to.vect/main.c: r.to.vect: fix r6872

Re: [GRASS-dev] Different CRS matching in 7.2 and trunk

2017-11-10 Thread Helena Mitasova 
Please note, that  in spite of the fact that the datum.table shows same 
transformation parameters,
different nad83 datums are different (it is not just a different name for the 
same datum) and there are different EPSG codes associated
with the relevant CRS.
You can find more about it here (or just google it)
https://confluence.qps.nl/pages/viewpage.action?pageId=29855153 


Supposedly, the shift from NAD83(86) to NAD83(HARN) can be done with the NGS 
NADCON program (I have not checked it out)
(http://www.ngs.noaa.gov/TOOLS/Nadcon/Nadcon.shtml 
).

Helena

> On Nov 10, 2017, at 5:30 PM, Markus Metz  
> wrote:
> 
> 
> 
> On Fri, Nov 10, 2017 at 8:46 PM, Vaclav Petras  wrote:
> >
> > On Fri, Nov 10, 2017 at 2:21 PM, Markus Metz 
> >  wrote:
> > >
> > > > >
> > > > > 7.2 considers this OK while trunk considers this different. I'm not 
> > > > > sure which one is correct.
> > > >
> > > > In this case, 7.2 is correct, but 7.2 does not compare datums, i.e. 
> > > > projections would be regarded as matching even with e.g. nad27 and 
> > > > nad83.
> > > > The comparison of datums is new in 7.3 and needs some refinement.
> > > >
> > > > I will fix the comparison of swapped lat_1 and lat_2.
> > >
> > > Fixed in trunk r71656.
> > >
> > > The test for different datum names has been disabled again in trunk 
> > > r71657. There are several different datum names in lib/gis/datum.table 
> > > that apparently mean the same: same ellipsoid and same transformation 
> > > parameters. Apparently, GRASS does not provide a datum name when 
> > > converting projection information from GRASS to proj4 for reprojecting 
> > > data.
> >
> >
> > Thank you so much, Markus. This saves me a lot of trouble.
> 
> About avoiding trouble, the motivation of the stricter CRS comparison is to 
> avoid subsequent geolocation errors. If data have been imported and 
> differences in the CRS were not detected, it can become very difficult later 
> on in the processing to figure out the reason for geolocation errors 
> (different data not matching each other spatially). I'm not sure what to do 
> about different datum names. The current check relies on the test for 
> differences in ellipsoids.
> 
> Markus M
> 
> >
> > (I'm working on a Jupyter Notebook where I need trunk.)
> > https://github.com/wenzeslaus/Notebook-for-processing-point-clouds-in-GRASS-GIS
> >
> > >
> > >
> > > Markus M
> > >
> 
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev

Helena Mitasova
Professor at the Department of Marine, 
Earth, and Atmospheric Sciences
and Center for Geospatial Analytics
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu
http://geospatial.ncsu.edu/osgeorel/publications.html

"All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law 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] Different CRS matching in 7.2 and trunk

2017-11-10 Thread Markus Metz 
On Fri, Nov 10, 2017 at 8:46 PM, Vaclav Petras  wrote:
>
> On Fri, Nov 10, 2017 at 2:21 PM, Markus Metz <
markus.metz.gisw...@gmail.com> wrote:
> >
> > > >
> > > > 7.2 considers this OK while trunk considers this different. I'm not
sure which one is correct.
> > >
> > > In this case, 7.2 is correct, but 7.2 does not compare datums, i.e.
projections would be regarded as matching even with e.g. nad27 and nad83.
> > > The comparison of datums is new in 7.3 and needs some refinement.
> > >
> > > I will fix the comparison of swapped lat_1 and lat_2.
> >
> > Fixed in trunk r71656.
> >
> > The test for different datum names has been disabled again in trunk
r71657. There are several different datum names in lib/gis/datum.table that
apparently mean the same: same ellipsoid and same transformation
parameters. Apparently, GRASS does not provide a datum name when converting
projection information from GRASS to proj4 for reprojecting data.
>
>
> Thank you so much, Markus. This saves me a lot of trouble.

About avoiding trouble, the motivation of the stricter CRS comparison is to
avoid subsequent geolocation errors. If data have been imported and
differences in the CRS were not detected, it can become very difficult
later on in the processing to figure out the reason for geolocation errors
(different data not matching each other spatially). I'm not sure what to do
about different datum names. The current check relies on the test for
differences in ellipsoids.

Markus M

>
> (I'm working on a Jupyter Notebook where I need trunk.)
>
https://github.com/wenzeslaus/Notebook-for-processing-point-clouds-in-GRASS-GIS
>
> >
> >
> > Markus M
> >
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GRASS GIS Community sprint has taken off

2017-11-10 Thread Veronica Andreo 
Hi everybody,

The autumn GRASS GIS community sprint has started this morning in Enschede,
Netherlands!! :)

You are all invited and welcome to join us remotely to bugfix, implement
new stuff and enhancements, test, document and so on. Just add yourself to
the wiki:
https://grasswiki.osgeo.org/wiki/GRASS_GIS_Community_Sprint_Autumn_2017
and your reports here:
https://grasswiki.osgeo.org/wiki/Talk:GRASS_GIS_Community_Sprint_Autumn_2017

You can also find us in IRC channel (https://webchat.freenode.net/).

Cheers!
MarkusM, Nikos, Moritz, Vero and MarkusN
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3430: v.clean threshold in lat-long: metric or not?

2017-11-10 Thread GRASS GIS 
#3430: v.clean threshold in lat-long: metric or not?
--+-
  Reporter:  neteler  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.2.3
 Component:  Vector   |Version:  7.2.2
Resolution:   |   Keywords:  v.clean
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by mmetz):

 Replying to [comment:2 mmetz]:
 > Replying to [comment:1 mlennert]:
 > > Replying to [ticket:3430 neteler]:
 > [...]
 > > >
 > > > Should the G_important_message() be removed from main.c?
 > >
 > > Looking through the code, I actually have the feeling that the
 documentation is wrong, at least for some of v.clean's functionalities.
 > [...]
 > >
 > > So while area calculations might use meters (i.e. the rmarea function
 mentioned in the SE message), I'm not sure this is the case for snapping
 distances... I think this needs very careful review before deciding what
 to do.
 >
 > I suggest to remove the message, because the message does not
 distinguish between the different cleaning tools. For tool=rmarea, the
 threshold must always be in square meters as stated in the manual.
 Otherwise, I'm pretty sure that the threshold is map units, also for
 latlon.

 According to https://gis.stackexchange.com/questions/258089/v-clean-with-
 rmarea-and-lat-long-projection there is another issue with v.clean
 tool=rmarea because it might remove areas that should not be removed. A
 test dataset would be helpful.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Different CRS matching in 7.2 and trunk

2017-11-10 Thread Vaclav Petras 
On Fri, Nov 10, 2017 at 2:21 PM, Markus Metz 
wrote:
>
> > >
> > > 7.2 considers this OK while trunk considers this different. I'm not
sure which one is correct.
> >
> > In this case, 7.2 is correct, but 7.2 does not compare datums, i.e.
projections would be regarded as matching even with e.g. nad27 and nad83.
> > The comparison of datums is new in 7.3 and needs some refinement.
> >
> > I will fix the comparison of swapped lat_1 and lat_2.
>
> Fixed in trunk r71656.
>
> The test for different datum names has been disabled again in trunk
r71657. There are several different datum names in lib/gis/datum.table that
apparently mean the same: same ellipsoid and same transformation
parameters. Apparently, GRASS does not provide a datum name when converting
projection information from GRASS to proj4 for reprojecting data.


Thank you so much, Markus. This saves me a lot of trouble.

(I'm working on a Jupyter Notebook where I need trunk.)
https://github.com/wenzeslaus/Notebook-for-processing-point-clouds-in-GRASS-GIS

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

Re: [GRASS-dev] [GRASS GIS] #3429: g.gui.iclass: segfault when loading vector layer

2017-11-10 Thread GRASS GIS 
#3429: g.gui.iclass: segfault when loading vector layer
--+--
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.4.0
 Component:  wxGUI|Version:  svn-trunk
Resolution:   |   Keywords:  g.gui.iclass import segfault
   CPU:  Unspecified  |   Platform:  Unspecified
--+--

Comment (by annakrat):

 Replying to [comment:1 mlennert]:
 > Replying to [ticket:3429 mlennert]:
 > > * define group
 > > * define classes
 > > * digitize a few training areas
 > > * save training areas to vector map
 > > * close g.gui.iclass
 > > * reopen g.gui.iclass
 > > * import saved vector maps
 > > => segfault
 >
 > I still have this problem. Can anyone reproduce ? Does anyone have a
 hint on how to debug this ?

 Yes, I looked at it couple days ago, and I could see where the problem is,
 but I didn't have time to fix it. The problem is somewhere in
 iclass/frame, how it calls the C functions, but I need to explore it more.
 The simplest way to debug this (for me) is using debugger integrated into
 qtcreator (you need to import grass as a project there). First you run
 g.gui.iclass, then in qtcreator you attach this external process and then
 do the actions in gui and the debugger shows you the place where it
 crashes.

--
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] #3430: v.clean threshold in lat-long: metric or not?

2017-11-10 Thread GRASS GIS 
#3430: v.clean threshold in lat-long: metric or not?
--+-
  Reporter:  neteler  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.2.3
 Component:  Vector   |Version:  7.2.2
Resolution:   |   Keywords:  v.clean
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by mmetz):

 Replying to [comment:1 mlennert]:
 > Replying to [ticket:3430 neteler]:
 [...]
 > >
 > > Should the G_important_message() be removed from main.c?
 >
 > Looking through the code, I actually have the feeling that the
 documentation is wrong, at least for some of v.clean's functionalities.
 [...]
 >
 > So while area calculations might use meters (i.e. the rmarea function
 mentioned in the SE message), I'm not sure this is the case for snapping
 distances... I think this needs very careful review before deciding what
 to do.

 I suggest to remove the message, because the message does not distinguish
 between the different cleaning tools. For tool=rmarea, the threshold must
 always be in square meters as stated in the manual. Otherwise, I'm pretty
 sure that the threshold is map units, also for latlon.

--
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] #3429: g.gui.iclass: segfault when loading vector layer

2017-11-10 Thread GRASS GIS 
#3429: g.gui.iclass: segfault when loading vector layer
--+--
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.4.0
 Component:  wxGUI|Version:  svn-trunk
Resolution:   |   Keywords:  g.gui.iclass import segfault
   CPU:  Unspecified  |   Platform:  Unspecified
--+--

Comment (by mlennert):

 Replying to [ticket:3429 mlennert]:
 > * define group
 > * define classes
 > * digitize a few training areas
 > * save training areas to vector map
 > * close g.gui.iclass
 > * reopen g.gui.iclass
 > * import saved vector maps
 > => segfault

 I still have this problem. Can anyone reproduce ? Does anyone have a hint
 on how to debug this ?

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Different CRS matching in 7.2 and trunk

2017-11-10 Thread Markus Metz 
On Fri, Nov 10, 2017 at 6:43 PM, Markus Metz 
wrote:
>
>
>
> On Fri, Nov 10, 2017 at 6:08 PM, Vaclav Petras 
wrote:
> >
> > Hi all,
> >
> > I'm trying to understand a change of behavior between 7.2 and trunk.
With 7.2, I can do the following:
> >
> > curl -SL http://fatra.cnr.ncsu.edu/foss4g2017/nc_tile_0793_016_spm.zip \
> > > nc_tile_0793_016_spm.zip  && unzip nc_tile_0793_016_spm.zip
> >
> > grass72 -c EPSG:3358 ~/grassdata/crs_test -e
> > grass72 ~/grassdata/crs_test2/PERMANENT/ --exec r.in.lidar
input=nc_tile_0793_016_spm.las output=count_10 method=n -e -n resolution=10
> >
> > The last step (r.in.lidar) fails in current trunk because the
projection don't match. Here is the difference (name, datum and swapped
lat_1 and lat_2):
> >
> >GRASS LOCATION PROJ_INFO is:
> >name: NAD83(HARN) / North Carolina
> >datum: nad83harn
> >lat_1: 36.16
> >lat_2: 34.34
> >
> >Import dataset PROJ_INFO is:
> >name: NAD_1983_StatePlane_North_Carolina_FIPS_3200
> >datum: nad83
> >lat_1: 34.34
> >lat_2: 36.16
> >
> > 7.2 considers this OK while trunk considers this different. I'm not
sure which one is correct.
>
> In this case, 7.2 is correct, but 7.2 does not compare datums, i.e.
projections would be regarded as matching even with e.g. nad27 and nad83.
> The comparison of datums is new in 7.3 and needs some refinement.
>
> I will fix the comparison of swapped lat_1 and lat_2.

Fixed in trunk r71656.

The test for different datum names has been disabled again in trunk r71657.
There are several different datum names in lib/gis/datum.table that
apparently mean the same: same ellipsoid and same transformation
parameters. Apparently, GRASS does not provide a datum name when converting
projection information from GRASS to proj4 for reprojecting data.

Markus M

>
> >
> > Here is the lasinfo reference:
> >
> > PROJCS["NAD_1983_StatePlane_North_Carolina_FIPS_3200",
> > GEOGCS["GCS_North_American_1983",
> > DATUM["North_American_Datum_1983",
> > SPHEROID["GRS_1980",6378137,298.257222101]],
> > PRIMEM["Greenwich",0],
> > UNIT["Degree",0.0174532925199432955]],
> > PROJECTION["Lambert_Conformal_Conic_2SP"],
> > PARAMETER["False_Easting",609601.22],
> > PARAMETER["False_Northing",0],
> > PARAMETER["Central_Meridian",-79],
> > PARAMETER["Standard_Parallel_1",34.34],
> > PARAMETER["Standard_Parallel_2",36.16],
> > PARAMETER["Latitude_Of_Origin",33.75],
> > UNIT["Meter",1]]
> >
> > `r.in.lidar -p` in both 7.2 and trunk gives:
> >
> > +proj=lcc +lat_1=34.34 +lat_2=36.16
+lat_0=33.75 +lon_0=-79 +x_0=609601.22 +y_0=0 +datum=NAD83 +units=m +no_defs
> >
> > `g.proj -p` gives the following in 7.2 and trunk in locations created
by 7.2 and trunk:
> >
> > -PROJ_INFO-
> > name   : NAD83(HARN) / North Carolina
> > datum  : nad83harn
> > ellps  : grs80
> > proj   : lcc
> > lat_1  : 36.16
> > lat_2  : 34.34
> > lat_0  : 33.75
> > lon_0  : -79
> > x_0: 609601.22
> > y_0: 0
> > no_defs: defined
> > -PROJ_EPSG-
> > epsg   : 3358
> > -PROJ_UNITS
> > unit   : meter
> > units  : meters
> > meters : 1
> >
> > I don't know how to resolve it besides using -o but I don't know how to
justify it and why there is a difference (I don't see it in the recent
proj-related commits).
> >
> > Thank you,
> > Vaclav
> >
> > ___
> > 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] #3430: v.clean threshold in lat-long: metric or not?

2017-11-10 Thread GRASS GIS 
#3430: v.clean threshold in lat-long: metric or not?
--+-
  Reporter:  neteler  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.2.3
 Component:  Vector   |Version:  7.2.2
Resolution:   |   Keywords:  v.clean
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by mlennert):

 Replying to [ticket:3430 neteler]:
 > From:
 > https://gis.stackexchange.com/questions/258089/v-clean-with-rmarea-and-
 lat-long-projection
 >
 > There is some confusion concerning this message:
 > main.c:
 > {{{
 > /* TODO: threshold might be recalculated with optional geodesic
 support to meters */
 > if (G_projection() == PROJECTION_LL)
 > G_important_message(_("Note: In latitude-longitude coordinate
 system specify threshold in degree unit"));
 > }}}
 >
 > while the documentation reads:
 > {{{
 > grep meter v.clean.html
 > case, also the threshold parameter requires several values to be listed
 > Threshold must always be in square meters, also for latitude-longitude
 > locations or locations with units other than meters.
 > }}}
 >
 > Should the G_important_message() be removed from main.c?

 Looking through the code, I actually have the feeling that the
 documentation is wrong, at least for some of v.clean's functionalities.
 For example for snapping, I see the following in the
 [https://trac.osgeo.org/grass/browser/grass/trunk/lib/vector/Vlib/snap.c#L302
 code]:

 {{{
 dx = XPnts[pointb].x - XPnts[point].x;
 dy = XPnts[pointb].y - XPnts[point].y;
 dist2 = dx * dx + dy * dy;

 if (dist2 > thresh2) /* outside threshold */
 continue;
 }}}

 So while area calculations might use meters (i.e. the rmarea function
 mentioned in the SE message), I'm not sure this is the case for snapping
 distances... I think this needs very careful review before deciding what
 to do.

--
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] #3436: Renaming a vector map doesn't rename the layer name in the dbln metadata file

2017-11-10 Thread GRASS GIS 
#3436: Renaming a vector map doesn't rename the layer name in the dbln metadata
file
--+-
  Reporter:  hcho |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:
 Component:  Vector   |Version:  svn-trunk
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by mlennert):

 * Attachment "vect_rename_layer_names.diff" added.


--
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] #3436: Renaming a vector map doesn't rename the layer name in the dbln metadata file

2017-11-10 Thread GRASS GIS 
#3436: Renaming a vector map doesn't rename the layer name in the dbln metadata
file
--+-
  Reporter:  hcho |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:
 Component:  Vector   |Version:  svn-trunk
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by mlennert):

 Replying to [ticket:3436 hcho]:
 > The layer name in dbln is not renamed when renaming a vector map. For
 example, after renaming old to new:
 > {{{
 > g.rename vect=old,new
 > }}}
 >
 > {{{
 > cat location/mapset/vector/new/dbln
 > }}}
 > prints
 > {{{
 > 1/old|new|cat|database|pg
 > }}}
 >
 > Expected output:
 > {{{
 > 1/new|new|cat|database|pg
 > }}}

 Does the layer name necessarily have to correspond to the map name ?
 AFAIU, layer names are mostly used for direct OGR access. Internally in
 GRASS vector format, it's the layer number that is used. So I'm not sure I
 would call this a bug, but potentially an enhancement request for
 aesthetic reasons.

 The same actually happens when you copy a map:


 {{{
 g.copy vect=roadsmajor,roads
 Copie vector  vers  dans le jeu de cartes
 courant
 GRASS 7.3.svn (nc_spm_08_grass7):~ > v.db.connect -p roadsmajor
 Vector map  is connected by:
 layer <1/roadsmajor> table  in database
 
 through driver  with key 
 GRASS 7.3.svn (nc_spm_08_grass7):~ > v.db.connect -p roads
 Vector map  is connected by:
 layer <1/roadsmajor> table  in database
  through
 driver  with key 
 }}}

 I'll add a diff that seems to do the trick for me, but I'm not sure that
 this is really needed, nor if it is desirable. Martin introduced the
 layers names so he should probably have a look at it.

--
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] #3426: Impossible to not compute shape statistics with i.segment.stats

2017-11-10 Thread GRASS GIS 
#3426: Impossible to not compute shape statistics with i.segment.stats
--+-
  Reporter:  tgrippa  |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  normal   |  Milestone:
 Component:  Addons   |Version:  unspecified
Resolution:  fixed|   Keywords:
   CPU:  Unspecified  |   Platform:  Linux
--+-
Changes (by mlennert):

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


Comment:

 Closing this as it has worked in our tests so far. Please reopen if
 necessary.

--
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] #2456: read CSV from GDAL data directory

2017-11-10 Thread GRASS GIS 
#2456: read CSV from GDAL data directory
-+-
  Reporter:  martinl |  Owner:  grass-dev@…
  Type:  task| Status:  new
  Priority:  blocker |  Milestone:  7.4.0
 Component:  Projections/Datums  |Version:  svn-releasebranch70
Resolution:  |   Keywords:  gdal, g.proj
   CPU:  Unspecified |   Platform:  Unspecified
-+-

Comment (by mlennert):

 Replying to [comment:43 neteler]:
 > Is anything missing here?

 ping

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Different CRS matching in 7.2 and trunk

2017-11-10 Thread Markus Metz 
On Fri, Nov 10, 2017 at 6:08 PM, Vaclav Petras  wrote:
>
> Hi all,
>
> I'm trying to understand a change of behavior between 7.2 and trunk. With
7.2, I can do the following:
>
> curl -SL http://fatra.cnr.ncsu.edu/foss4g2017/nc_tile_0793_016_spm.zip \
> > nc_tile_0793_016_spm.zip  && unzip nc_tile_0793_016_spm.zip
>
> grass72 -c EPSG:3358 ~/grassdata/crs_test -e
> grass72 ~/grassdata/crs_test2/PERMANENT/ --exec r.in.lidar
input=nc_tile_0793_016_spm.las output=count_10 method=n -e -n resolution=10
>
> The last step (r.in.lidar) fails in current trunk because the projection
don't match. Here is the difference (name, datum and swapped lat_1 and
lat_2):
>
>GRASS LOCATION PROJ_INFO is:
>name: NAD83(HARN) / North Carolina
>datum: nad83harn
>lat_1: 36.16
>lat_2: 34.34
>
>Import dataset PROJ_INFO is:
>name: NAD_1983_StatePlane_North_Carolina_FIPS_3200
>datum: nad83
>lat_1: 34.34
>lat_2: 36.16
>
> 7.2 considers this OK while trunk considers this different. I'm not sure
which one is correct.

In this case, 7.2 is correct, but 7.2 does not compare datums, i.e.
projections would be regarded as matching even with e.g. nad27 and nad83.
The comparison of datums is new in 7.3 and needs some refinement.

I will fix the comparison of swapped lat_1 and lat_2.

Markus M


>
> Here is the lasinfo reference:
>
> PROJCS["NAD_1983_StatePlane_North_Carolina_FIPS_3200",
> GEOGCS["GCS_North_American_1983",
> DATUM["North_American_Datum_1983",
> SPHEROID["GRS_1980",6378137,298.257222101]],
> PRIMEM["Greenwich",0],
> UNIT["Degree",0.0174532925199432955]],
> PROJECTION["Lambert_Conformal_Conic_2SP"],
> PARAMETER["False_Easting",609601.22],
> PARAMETER["False_Northing",0],
> PARAMETER["Central_Meridian",-79],
> PARAMETER["Standard_Parallel_1",34.34],
> PARAMETER["Standard_Parallel_2",36.16],
> PARAMETER["Latitude_Of_Origin",33.75],
> UNIT["Meter",1]]
>
> `r.in.lidar -p` in both 7.2 and trunk gives:
>
> +proj=lcc +lat_1=34.34 +lat_2=36.16 +lat_0=33.75
+lon_0=-79 +x_0=609601.22 +y_0=0 +datum=NAD83 +units=m +no_defs
>
> `g.proj -p` gives the following in 7.2 and trunk in locations created by
7.2 and trunk:
>
> -PROJ_INFO-
> name   : NAD83(HARN) / North Carolina
> datum  : nad83harn
> ellps  : grs80
> proj   : lcc
> lat_1  : 36.16
> lat_2  : 34.34
> lat_0  : 33.75
> lon_0  : -79
> x_0: 609601.22
> y_0: 0
> no_defs: defined
> -PROJ_EPSG-
> epsg   : 3358
> -PROJ_UNITS
> unit   : meter
> units  : meters
> meters : 1
>
> I don't know how to resolve it besides using -o but I don't know how to
justify it and why there is a difference (I don't see it in the recent
proj-related commits).
>
> Thank you,
> Vaclav
>
> ___
> 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] [release planning] 7.4.0

2017-11-10 Thread Moritz Lennert 
Hi Maris,

Le Sun, 29 Oct 2017 12:31:35 +0200,
Maris Nartiss  a écrit :

> I added simple tests for v.profile. [1]
> I also changed one of examples from documentation to use NC Basic
> dataset. [2]
> 
> If v.profile is moved to trunk, README file should be deleted.
> 
> As there seem to be a lot of +1's and the requirement of tests is
> fulfilled, this addon should be moved to trunk to gain some exposure
> before release (or wait till 7.4.1).

v.profile still uses the old buffering library methods which has quite
a lot of issues.

As an example, I attach the output map of the following example:

v.profile input=geonames_NC@PERMANENT output=- separator=comma dp=3
buffer=500 profile_map=roadsmajor@PERMANENT profile_where=cat=193
map_output=test_profile

I also attach the equivalent v.buffer output:

v.buffer -c roadsmajor where=cat=193 dist=500 out=buff500

Would it be possible for you, Maris, to change to the GEOS method used
in v.buffer in order to get the same buffering output ?

This is not only formal as you can see when you use the following
vector points as input:

v.in.ascii in=- out=test_points << EOF
626382.68026139|228917.44816672|1
626643.91393428|228738.2879083|2
626907.14939778|228529.10079092|3
EOF

v.profile then misses out on point 2, even though it is within 500m:

v.profile input=test_points output=- separator=comma dp=3 buffer=500
profile_map=roadsmajor@PERMANENT profile_where=cat=193
Number,Distance,cat,dbl_1,dbl_2,int_1
1,2102.114,3,626907.14939778,228529.10079092,3
2,2960.822,1,626382.68026139,228917.44816672,1

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

Re: [GRASS-dev] new proj4 release

2017-11-10 Thread Helmut Kudrnovsky 
Helmut Kudrnovsky wrote
> fyi
> http://lists.maptools.org/pipermail/proj/2017-November/007849.html
> 
> All,
> 
> I think the current development cycle is coming to an end and a new
> release
> should be made. It's been more than a year since that least release of
> PROJ.4. In that period of time the library has improved significantly,
> most
> notably by the introduction of a new and more consistent API,
> transformation
> pipelines and the cct 4D transformation CLI utility. The new additions
> have
> already seen a fair amount of testing and are now at a point where I
> believe
> they are stable enough to be released to the public. I would like to
> propose
> that we release the next version of PROJ.4 on December 15. This gives
> roughly a month to take care of the last few kinks that need to be ironed
> out. It also gives users of the library amble time to test the developing
> version in the setups and report any issues that have appeared since the
> last release. With a release mid-december we should aim for a release
> candidate in the start of December.
> 
> I hope we all agree that the time has come to get a new release out there.
> Please voice your opinions on this matter.
> 
> Howard, I guess you will be doing some/most of the heavy lifting with
> preparing the actual release, so please feel free to propose another time
> if
> this doesn't fit your schedule.
> 
> 
> and some follow up in the email thread.

a nice overview about new proj4 API and stuff:

"Transformation pipelines for PROJ.4"

http://www.fig.net/resources/proceedings/fig_proceedings/fig2017/papers/iss6b/ISS6B_evers_knudsen_9156.pdf






-
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

[GRASS-dev] Different CRS matching in 7.2 and trunk

2017-11-10 Thread Vaclav Petras 
Hi all,

I'm trying to understand a change of behavior between 7.2 and trunk. With
7.2, I can do the following:

curl -SL http://fatra.cnr.ncsu.edu/foss4g2017/nc_tile_0793_016_spm.zip \
> nc_tile_0793_016_spm.zip  && unzip nc_tile_0793_016_spm.zip

grass72 -c EPSG:3358 ~/grassdata/crs_test -e
grass72 ~/grassdata/crs_test2/PERMANENT/ --exec r.in.lidar
input=nc_tile_0793_016_spm.las output=count_10 method=n -e -n resolution=10

The last step (r.in.lidar) fails in current trunk because the projection
don't match. Here is the difference (name, datum and swapped lat_1 and
lat_2):

   GRASS LOCATION PROJ_INFO is:
   name: NAD83(HARN) / North Carolina
   datum: nad83harn
   lat_1: 36.16
   lat_2: 34.34

   Import dataset PROJ_INFO is:
   name: NAD_1983_StatePlane_North_Carolina_FIPS_3200
   datum: nad83
   lat_1: 34.34
   lat_2: 36.16

7.2 considers this OK while trunk considers this different. I'm not sure
which one is correct.

Here is the lasinfo reference:

PROJCS["NAD_1983_StatePlane_North_Carolina_FIPS_3200",
GEOGCS["GCS_North_American_1983",
DATUM["North_American_Datum_1983",
SPHEROID["GRS_1980",6378137,298.257222101]],
PRIMEM["Greenwich",0],
UNIT["Degree",0.0174532925199432955]],
PROJECTION["Lambert_Conformal_Conic_2SP"],
PARAMETER["False_Easting",609601.22],
PARAMETER["False_Northing",0],
PARAMETER["Central_Meridian",-79],
PARAMETER["Standard_Parallel_1",34.34],
PARAMETER["Standard_Parallel_2",36.16],
PARAMETER["Latitude_Of_Origin",33.75],
UNIT["Meter",1]]

`r.in.lidar -p` in both 7.2 and trunk gives:

+proj=lcc +lat_1=34.34 +lat_2=36.16 +lat_0=33.75
+lon_0=-79 +x_0=609601.22 +y_0=0 +datum=NAD83 +units=m +no_defs

`g.proj -p` gives the following in 7.2 and trunk in locations created by
7.2 and trunk:

-PROJ_INFO-
name   : NAD83(HARN) / North Carolina
datum  : nad83harn
ellps  : grs80
proj   : lcc
lat_1  : 36.16
lat_2  : 34.34
lat_0  : 33.75
lon_0  : -79
x_0: 609601.22
y_0: 0
no_defs: defined
-PROJ_EPSG-
epsg   : 3358
-PROJ_UNITS
unit   : meter
units  : meters
meters : 1

I don't know how to resolve it besides using -o but I don't know how to
justify it and why there is a difference (I don't see it in the recent
proj-related commits).

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

Re: [GRASS-dev] [release planning] 7.4.0

2017-11-10 Thread Moritz Lennert 
Le Fri, 3 Nov 2017 17:56:35 +0100,
Markus Neteler  a écrit :

> On Thu, Nov 2, 2017 at 4:18 PM, Luca Delucchi 
> wrote:
> > On 2 October 2017 at 23:35, Markus Neteler 
> > wrote: 
> >>
> >> ###
> >> v.clip: NC dataset
> >> https://grass.osgeo.org/grass72/manuals/addons/v.clip.html
> >>
> >> A clip test could be made by counting points falling into a
> >> polygon, similar to the example in the manual page.
> >>  
> >
> > added tests in r71627.  
> 
> thanks!
> 
> v.clip addon moved to trunk in r71634 for further testing.
> 


I just added tests to r.object.geometry. Another potential candidate
for trunk, but not sure if we still want to do this now, or maybe for a
7.4.1.

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

[GRASS-dev] [GRASS GIS] #3437: Implement r.coin csv output to file

2017-11-10 Thread GRASS GIS 
#3437: Implement r.coin csv output to file
-+-
 Reporter:  marisn   |  Owner:  grass-dev@…
 Type:  enhancement  | Status:  new
 Priority:  normal   |  Milestone:  7.4.0
Component:  Raster   |Version:  unspecified
 Keywords:  r.coin   |CPU:  Unspecified
 Platform:  Unspecified  |
-+-
 At the moment r.coin only prints out a report to stdout. It would be
 useful to enhance r.coin with an option to output report or bare CSV
 values to file (machine readable output for importing into R).
 Thus r.coin would need one input option "output_file" and a flag "print
 csv instead of report". If "output_file" option is set, report/csv should
 go to file not screen.

 Format could be:
 {{{
 # COINCIDENCE TABULATION
 # Columns: <>
 # Rows: <>
 ,C1,C2,...
 C1,X,X,...
 C2,C,C,...
 }}}
 Any suggestions on output file structure or content?

--
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] new proj4 release

2017-11-10 Thread Helmut Kudrnovsky 
fyi
http://lists.maptools.org/pipermail/proj/2017-November/007849.html

All,

I think the current development cycle is coming to an end and a new release
should be made. It's been more than a year since that least release of
PROJ.4. In that period of time the library has improved significantly, most
notably by the introduction of a new and more consistent API, transformation
pipelines and the cct 4D transformation CLI utility. The new additions have
already seen a fair amount of testing and are now at a point where I believe
they are stable enough to be released to the public. I would like to propose
that we release the next version of PROJ.4 on December 15. This gives
roughly a month to take care of the last few kinks that need to be ironed
out. It also gives users of the library amble time to test the developing
version in the setups and report any issues that have appeared since the
last release. With a release mid-december we should aim for a release
candidate in the start of December.

I hope we all agree that the time has come to get a new release out there.
Please voice your opinions on this matter.

Howard, I guess you will be doing some/most of the heavy lifting with
preparing the actual release, so please feel free to propose another time if
this doesn't fit your schedule.


and some follow up in the email thread.



-
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