Re: [GRASS-dev] Translations and command description/options

[Panagiotis Mavrogiorgos]

If anyone has any other ideas, I would be happy to hear them out. here
 is
what has been tried so far.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Passed: GRASS-GIS/grass-ci#3322 (master - 1907aa8)

[Travis CI]

Build Update for GRASS-GIS/grass-ci
-

Build: #3322
Status: Passed

Duration: 9 mins and 23 secs
Commit: 1907aa8 (master)
Author: Markus Metz
Message: g.proj: also list SRS without proj definition

git-svn-id: https://svn.osgeo.org/grass/grass/trunk@74193 
15284696-431f-4ddb-bdfa-cd5b030d7da7

View the changeset: 
https://github.com/GRASS-GIS/grass-ci/compare/bb7d283bb464...1907aa888670

View the full build log and details: 
https://travis-ci.org/GRASS-GIS/grass-ci/builds/503759013?utm_medium=notification&utm_source=email

--

You can unsubscribe from build emails from the GRASS-GIS/grass-ci repository 
going to 
https://travis-ci.org/account/preferences/unsubscribe?repository=5458449&utm_medium=notification&utm_source=email.
Or unsubscribe from *all* email updating your settings at 
https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification&utm_source=email.
Or configure specific recipients for build notifications in your .travis.yml 
file. See https://docs.travis-ci.com/user/notifications.

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

[GRASS-dev] Errored: GRASS-GIS/grass-ci#3319 (master - 00ffd0d)

[Travis CI]

Build Update for GRASS-GIS/grass-ci
-

Build: #3319
Status: Errored

Duration: 10 mins and 19 secs
Commit: 00ffd0d (master)
Author: Markus Metz
Message: db: enlarge DB_SQL_MAX

git-svn-id: https://svn.osgeo.org/grass/grass/trunk@74189 
15284696-431f-4ddb-bdfa-cd5b030d7da7

View the changeset: 
https://github.com/GRASS-GIS/grass-ci/compare/89c58f3fcc4d...00ffd0dd4349

View the full build log and details: 
https://travis-ci.org/GRASS-GIS/grass-ci/builds/503752476?utm_medium=notification&utm_source=email

--

You can unsubscribe from build emails from the GRASS-GIS/grass-ci repository 
going to 
https://travis-ci.org/account/preferences/unsubscribe?repository=5458449&utm_medium=notification&utm_source=email.
Or unsubscribe from *all* email updating your settings at 
https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification&utm_source=email.
Or configure specific recipients for build notifications in your .travis.yml 
file. See https://docs.travis-ci.com/user/notifications.

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

Re: [GRASS-dev] [PROJ] GRASS GIS + PROJ 6 + GDAL 2.5

[Roger Bivand]

On Fri, 8 Mar 2019, Even Rouault wrote:


On vendredi 8 mars 2019 18:22:42 CET Markus Metz wrote:

On Fri, Mar 8, 2019 at 5:56 PM Even Rouault 

wrote:

On vendredi 8 mars 2019 17:01:57 CET Markus Metz wrote:

My question is, what should GRASS do with a SRS without proj string? The
best answer is probably: use WKT instead of a proj string. But most of


the


GRASS code uses (for historical reasons) some form of proj syntax, also


to


store projection info for a GRASS location. If there is no proj string,
GRASS thinks there is no SRS and falls back to a generic xy system


which is


not always correct.


The WKT will not help here. You will be able to get here, but you won't be
able to do coordinate transformation with it. This is just that this EPSG
method is not implemented or mapped to a PROJ projection method


I understand that coordinate transformation with PROJ will not be possible.
But having a valid SRS definition would at least allow to compare two
spatial references, i.e. OSRIsSame() should work. Having a valid SRS
instead of dumping it would also help if the corresponding PROJ method
becomes implemented in the future. That's why I am wondering about an
alternative to the current proj-like projection information in GRASS.


Might it be possible for proj_get_crs_info_list_from_database() to return 
a field indicating whether the record in proj_crs_info can be exported to 
proj_string?


I found example code for proj_log_func() in GDAL in ogr/ogr_proj_p.cpp, 
and am using that to do nothing on apparent PJ_LOG_ERROR messages reported 
in proj_as_proj_string(). The messages are suppressed, and I destroy the 
context after looping through the projections found. I'm a bit concerned 
that if something goes wrong, turning off error handling isn't safe.


In rgdal::make_EPSG(), the proj_string is returned as (null), and can be 
grepped, so it does provide information.


Roger



Yes, for having a reference SRS definition, you can use the WKT export. By
"useful", I meant being able to do coordinate transformation.
To compare SRS for equality, rather than using full string comparison, I'd
suggest using proj_is_equivalent_to() which has a few options for different
levels of equality.

Even




--
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; e-mail: roger.biv...@nhh.no
https://orcid.org/-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0J&hl=en
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3766: Update "Introduction to Raster classes" document

[GRASS GIS]

#3766: Update "Introduction to Raster classes" document
---+-
  Reporter:  Nikos Alexandris  |  Owner:  grass-dev@…
  Type:  defect| Status:  new
  Priority:  normal|  Milestone:
 Component:  Docs  |Version:  unspecified
Resolution:|   Keywords:
   CPU:  Unspecified   |   Platform:  All
---+-

Comment (by veroandreo):

 diff files with correct text are always welcome :)

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [PROJ] GRASS GIS + PROJ 6 + GDAL 2.5

[Even Rouault]

> I'm assuming there is no error handler to hook onto, to divert errors to
> R's error handler.

Actually you can install your own error handler with proj_log_func()

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [PROJ] GRASS GIS + PROJ 6 + GDAL 2.5

[Even Rouault]

On vendredi 8 mars 2019 18:22:42 CET Markus Metz wrote:
> On Fri, Mar 8, 2019 at 5:56 PM Even Rouault 
> 
> wrote:
> > On vendredi 8 mars 2019 17:01:57 CET Markus Metz wrote:
> > > My question is, what should GRASS do with a SRS without proj string? The
> > > best answer is probably: use WKT instead of a proj string. But most of
> 
> the
> 
> > > GRASS code uses (for historical reasons) some form of proj syntax, also
> 
> to
> 
> > > store projection info for a GRASS location. If there is no proj string,
> > > GRASS thinks there is no SRS and falls back to a generic xy system
> 
> which is
> 
> > > not always correct.
> > 
> > The WKT will not help here. You will be able to get here, but you won't be
> > able to do coordinate transformation with it. This is just that this EPSG
> > method is not implemented or mapped to a PROJ projection method
> 
> I understand that coordinate transformation with PROJ will not be possible.
> But having a valid SRS definition would at least allow to compare two
> spatial references, i.e. OSRIsSame() should work. Having a valid SRS
> instead of dumping it would also help if the corresponding PROJ method
> becomes implemented in the future. That's why I am wondering about an
> alternative to the current proj-like projection information in GRASS.

Yes, for having a reference SRS definition, you can use the WKT export. By 
"useful", I meant being able to do coordinate transformation.
To compare SRS for equality, rather than using full string comparison, I'd 
suggest using proj_is_equivalent_to() which has a few options for different 
levels of equality.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [PROJ] GRASS GIS + PROJ 6 + GDAL 2.5

[Markus Metz]

On Fri, Mar 8, 2019 at 5:56 PM Even Rouault 
wrote:
>
> On vendredi 8 mars 2019 17:01:57 CET Markus Metz wrote:
> >
> > My question is, what should GRASS do with a SRS without proj string? The
> > best answer is probably: use WKT instead of a proj string. But most of
the
> > GRASS code uses (for historical reasons) some form of proj syntax, also
to
> > store projection info for a GRASS location. If there is no proj string,
> > GRASS thinks there is no SRS and falls back to a generic xy system
which is
> > not always correct.
>
> The WKT will not help here. You will be able to get here, but you won't be
> able to do coordinate transformation with it. This is just that this EPSG
> method is not implemented or mapped to a PROJ projection method

I understand that coordinate transformation with PROJ will not be possible.
But having a valid SRS definition would at least allow to compare two
spatial references, i.e. OSRIsSame() should work. Having a valid SRS
instead of dumping it would also help if the corresponding PROJ method
becomes implemented in the future. That's why I am wondering about an
alternative to the current proj-like projection information in GRASS.

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

Re: [GRASS-dev] [PROJ] GRASS GIS + PROJ 6 + GDAL 2.5

[Even Rouault]

On vendredi 8 mars 2019 17:01:57 CET Markus Metz wrote:
> On Fri, Mar 8, 2019 at 12:41 PM Even Rouault 
> 
> wrote:
> > On vendredi 8 mars 2019 12:27:37 CET Markus Metz wrote:
> > > On Fri, Mar 8, 2019 at 10:49 AM Roger Bivand 
> 
> wrote:
> > > > Since rgdal::make_EPSG() is facing the same problems of listing
> 
> tabulated
> 
> > > > EPSG fields as g.proj -l, I was very happy to see Markus' code in
> > > > g.proj/main.c mentioned in this thread, and have used this approach in
> 
> https://r-forge.r-project.org/scm/viewvc.php/pkg/src/proj_info6.cpp?view=mar
> > > kup&root=rgdal
> > > 
> > > > However, there are plenty of messages such as: "proj_as_proj_string:
> > > > Unsupported conversion method: Lambert Conic Conformal (West
> > > 
> > > Orientated)". I
> > > 
> > > > haven't installed GRASS trunk with PROJ6, so I can't see whether
> 
> g.proj -l
> 
> > > > also sees the same messages.
> > > 
> > > I get the same messages with g.proj, but no error code from PROJ error
> > > handlers.
> > > 
> > > > If it does, maybe we could ask on the proj list
> > > 
> > > yes, we should ask. For now g.proj is ignoring those codes for which no
> > > proj string can be retrieved.
> > 
> > I'm not sure what the question is exactly :-)
> 
> My question is, what should GRASS do with a SRS without proj string? The
> best answer is probably: use WKT instead of a proj string. But most of the
> GRASS code uses (for historical reasons) some form of proj syntax, also to
> store projection info for a GRASS location. If there is no proj string,
> GRASS thinks there is no SRS and falls back to a generic xy system which is
> not always correct.

The WKT will not help here. You will be able to get here, but you won't be 
able to do coordinate transformation with it. This is just that this EPSG 
method is not implemented or mapped to a PROJ projection method


-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [PROJ] GRASS GIS + PROJ 6 + GDAL 2.5

[Markus Metz]

On Fri, Mar 8, 2019 at 12:41 PM Even Rouault 
wrote:
>
> On vendredi 8 mars 2019 12:27:37 CET Markus Metz wrote:
> > On Fri, Mar 8, 2019 at 10:49 AM Roger Bivand 
wrote:
> > > Since rgdal::make_EPSG() is facing the same problems of listing
tabulated
> > > EPSG fields as g.proj -l, I was very happy to see Markus' code in
> > > g.proj/main.c mentioned in this thread, and have used this approach in
> >
> >
https://r-forge.r-project.org/scm/viewvc.php/pkg/src/proj_info6.cpp?view=mar
> > kup&root=rgdal
> > > However, there are plenty of messages such as: "proj_as_proj_string:
> > > Unsupported conversion method: Lambert Conic Conformal (West
> >
> > Orientated)". I
> >
> > > haven't installed GRASS trunk with PROJ6, so I can't see whether
g.proj -l
> > > also sees the same messages.
> >
> > I get the same messages with g.proj, but no error code from PROJ error
> > handlers.
> >
> > > If it does, maybe we could ask on the proj list
> >
> > yes, we should ask. For now g.proj is ignoring those codes for which no
> > proj string can be retrieved.
>
> I'm not sure what the question is exactly :-)

My question is, what should GRASS do with a SRS without proj string? The
best answer is probably: use WKT instead of a proj string. But most of the
GRASS code uses (for historical reasons) some form of proj syntax, also to
store projection info for a GRASS location. If there is no proj string,
GRASS thinks there is no SRS and falls back to a generic xy system which is
not always correct.

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

Re: [GRASS-dev] [GRASS GIS] #3780: Python3 + g.gui.animation: Traceback when clicking on the settings button

[GRASS GIS]

#3780: Python3 + g.gui.animation: Traceback when clicking on the settings button
--+-
  Reporter:  pmav99   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:
 Component:  wxGUI|Version:  svn-trunk
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by pmav99):

 Just confirmed that this happens on Python2 too. It seems that this is an
 issue related to wxPython 4+. On my end, both on Python 2 and Python 3:
 {{{
 pip freeze | grep wx
 wxPython==4.0.4
 }}}

 It seems that the on wxPython4 they changed the namespace:
 - wx 3:
 http://xoomer.virgilio.it/infinity77/wxPython/Widgets/wx.HyperlinkCtrl.html
 - wx 4: https://wxpython.org/Phoenix/docs/html/wx.adv.HyperlinkCtrl.html

 Something like this should fix it:
 {{{
 import wx.adv
 # ...
 link = wx.adv.HyperlinkCtrl(
 }}}
 but that would break compatibility with wxPython3 (not sure if we still
 care for that).

-- 
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] #3780: Python3 + g.gui.animation: Traceback when clicking on the settings button

[GRASS GIS]

#3780: Python3 + g.gui.animation: Traceback when clicking on the settings button
--+-
  Reporter:  pmav99   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:
 Component:  wxGUI|Version:  svn-trunk
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by veroandreo):

 I confirm this error in python 3; works fine with python 2

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [PROJ] GRASS GIS + PROJ 6 + GDAL 2.5

[Roger Bivand]

On Fri, 8 Mar 2019, Even Rouault wrote:


On vendredi 8 mars 2019 12:27:37 CET Markus Metz wrote:

On Fri, Mar 8, 2019 at 10:49 AM Roger Bivand  wrote:

Since rgdal::make_EPSG() is facing the same problems of listing tabulated
EPSG fields as g.proj -l, I was very happy to see Markus' code in
g.proj/main.c mentioned in this thread, and have used this approach in


https://r-forge.r-project.org/scm/viewvc.php/pkg/src/proj_info6.cpp?view=mar
kup&root=rgdal

However, there are plenty of messages such as: "proj_as_proj_string:
Unsupported conversion method: Lambert Conic Conformal (West


Orientated)". I


haven't installed GRASS trunk with PROJ6, so I can't see whether g.proj -l
also sees the same messages.


I get the same messages with g.proj, but no error code from PROJ error
handlers.


If it does, maybe we could ask on the proj list


yes, we should ask. For now g.proj is ignoring those codes for which no
proj string can be retrieved.


I'm not sure what the question is exactly :-) Is that proj_context_errno()
doesn't return an error in that case ?


Yes, for example:

...
for (i = 0; i < crs_cnt; i++) {
const char *proj_definition;

pj = proj_create_from_database(ctx, proj_crs_info[i]->auth_name,
proj_crs_info[i]->code, PJ_CATEGORY_CRS, 0, NULL);
Rprintf("proj_create_from_database %s: %d\n", proj_crs_info[i]->code, 
proj_context_errno(ctx));

proj_definition = proj_as_proj_string(ctx, pj, PJ_PROJ_5, NULL);
Rprintf("proj_as_proj_string %s: %d\n", proj_crs_info[i]->code, 
proj_context_errno(ctx));

...

showing in one case:

proj_create_from_database 7082: 0
proj_as_proj_string: Unsupported conversion method: Polar Stereographic 
(variant C)

proj_as_proj_string 7082: 0

so the message is being delivered to the console (stderr?), no errno (or 
other notification seems to be set. Is there a way of checking first 
before calling proj_as_proj_string() to avoid the message?


I did find the *_destroy() functions instead of legacy pj_free() etc., 
thanks for prompting me to re-read proj.h.


I'm assuming there is no error handler to hook onto, to divert errors to 
R's error handler. In this case, it doesn't matter for replacing legacy 
functionality.


Roger


That's related to the error being emitted from the new code emitting C++
exceptions, which are caught by the C wrapper. It doesn't set errno style
errors currently. I'm not a big fan of the errno approach, and find the proper
error string currently emitted to be more expressive, but that can be
discussed if some harmonization should be done.

Even




--
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; e-mail: roger.biv...@nhh.no
https://orcid.org/-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0J&hl=en
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2048: i.pansharpen limited to 8-bit imagery

[GRASS GIS]

#2048: i.pansharpen limited to 8-bit imagery
-+-
  Reporter:  Nikos   |  Owner:  grass-dev@…
  Alexandris |
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.6.1
 Component:  Imagery |Version:  svn-trunk
Resolution:  |   Keywords:  i.pansharpen, sharpening, fusion,
 |  brovey, ihs, pca, 8-bit
   CPU:  All |   Platform:  Unspecified
-+-

Comment (by cmbarton):

 I just uploaded a slightly revised version of i.pansharpen with bit depth
 in the 2-30 range and faster parallel processing of image channel
 rescaling.

-- 
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] #2048: i.pansharpen limited to 8-bit imagery

[GRASS GIS]

#2048: i.pansharpen limited to 8-bit imagery
-+-
  Reporter:  Nikos   |  Owner:  grass-dev@…
  Alexandris |
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.6.1
 Component:  Imagery |Version:  svn-trunk
Resolution:  |   Keywords:  i.pansharpen, sharpening, fusion,
 |  brovey, ihs, pca, 8-bit
   CPU:  All |   Platform:  Unspecified
-+-
Changes (by cmbarton):

 * Attachment "i.pansharpen2" removed.

 i.pansharpen updated to allow for 8-32 bit imagery

-- 
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] #2048: i.pansharpen limited to 8-bit imagery

[GRASS GIS]

#2048: i.pansharpen limited to 8-bit imagery
-+-
  Reporter:  Nikos   |  Owner:  grass-dev@…
  Alexandris |
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.6.1
 Component:  Imagery |Version:  svn-trunk
Resolution:  |   Keywords:  i.pansharpen, sharpening, fusion,
 |  brovey, ihs, pca, 8-bit
   CPU:  All |   Platform:  Unspecified
-+-
Changes (by cmbarton):

 * Attachment "i.pansharpen2" added.

 updated pan sharpening module

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [PROJ] GRASS GIS + PROJ 6 + GDAL 2.5

[Even Rouault]

On vendredi 8 mars 2019 12:27:37 CET Markus Metz wrote:
> On Fri, Mar 8, 2019 at 10:49 AM Roger Bivand  wrote:
> > Since rgdal::make_EPSG() is facing the same problems of listing tabulated
> > EPSG fields as g.proj -l, I was very happy to see Markus' code in
> > g.proj/main.c mentioned in this thread, and have used this approach in
> 
> https://r-forge.r-project.org/scm/viewvc.php/pkg/src/proj_info6.cpp?view=mar
> kup&root=rgdal
> > However, there are plenty of messages such as: "proj_as_proj_string:
> > Unsupported conversion method: Lambert Conic Conformal (West
> 
> Orientated)". I
> 
> > haven't installed GRASS trunk with PROJ6, so I can't see whether g.proj -l
> > also sees the same messages.
> 
> I get the same messages with g.proj, but no error code from PROJ error
> handlers.
> 
> > If it does, maybe we could ask on the proj list
> 
> yes, we should ask. For now g.proj is ignoring those codes for which no
> proj string can be retrieved.

I'm not sure what the question is exactly :-) Is that proj_context_errno() 
doesn't return an error in that case ?
That's related to the error being emitted from the new code emitting C++ 
exceptions, which are caught by the C wrapper. It doesn't set errno style 
errors currently. I'm not a big fan of the errno approach, and find the proper 
error string currently emitted to be more expressive, but that can be 
discussed if some harmonization should be done.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2048: i.pansharpen limited to 8-bit imagery

[GRASS GIS]

#2048: i.pansharpen limited to 8-bit imagery
-+-
  Reporter:  Nikos   |  Owner:  grass-dev@…
  Alexandris |
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.6.1
 Component:  Imagery |Version:  svn-trunk
Resolution:  |   Keywords:  i.pansharpen, sharpening, fusion,
 |  brovey, ihs, pca, 8-bit
   CPU:  All |   Platform:  Unspecified
-+-

Comment (by cmbarton):

 Also, if you try to go beyond the range limit in the GUI, the value will
 be reset to the minimum (if you try to go below) or the maximum (if you
 try to go above. No error message is generated because the values are
 automatically corrected back to the limited range. In the terminal, you do
 get an error if you try to go outside the range.

-- 
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] #2048: i.pansharpen limited to 8-bit imagery

[GRASS GIS]

#2048: i.pansharpen limited to 8-bit imagery
-+-
  Reporter:  Nikos   |  Owner:  grass-dev@…
  Alexandris |
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.6.1
 Component:  Imagery |Version:  svn-trunk
Resolution:  |   Keywords:  i.pansharpen, sharpening, fusion,
 |  brovey, ihs, pca, 8-bit
   CPU:  All |   Platform:  Unspecified
-+-

Comment (by cmbarton):

 Here is another limit I didn't realize.

 r.rescale bombs with 32bit imagery, but can handle 30bit. So that needs to
 be the upper cut off for now.

-- 
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 + PROJ 6 + GDAL 2.5

[Markus Metz]

On Fri, Mar 8, 2019 at 10:49 AM Roger Bivand  wrote:
>
> Since rgdal::make_EPSG() is facing the same problems of listing tabulated
> EPSG fields as g.proj -l, I was very happy to see Markus' code in
> g.proj/main.c mentioned in this thread, and have used this approach in
>
https://r-forge.r-project.org/scm/viewvc.php/pkg/src/proj_info6.cpp?view=markup&root=rgdal
>
> However, there are plenty of messages such as: "proj_as_proj_string:
> Unsupported conversion method: Lambert Conic Conformal (West
Orientated)". I
> haven't installed GRASS trunk with PROJ6, so I can't see whether g.proj -l
> also sees the same messages.

I get the same messages with g.proj, but no error code from PROJ error
handlers.

> If it does, maybe we could ask on the proj list

yes, we should ask. For now g.proj is ignoring those codes for which no
proj string can be retrieved.

Markus M

> how they might be captured for summary reporting. I think they are coming
> from line 5758 in src/iso19111/coordinateoperation.cpp or maybe line 906
in
> same file. Maybe PROJ now has an error handler that
>
> Another question concerns the issue of whether one needs to free objects
> created, in particular proj_crs_info and pj. Not so important for g.proj,
> which exists when done, but important for rgdal whose functions don't
exit.
>
> Anyway, very helpful to see that Markus is looking at the same issues as
we
> are!
>
> Roger
>
>
>
>
>
> -
> Roger Bivand
> NHH Norwegian School of Economics, Bergen, Norway
> --
> 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 mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2048: i.pansharpen limited to 8-bit imagery

[GRASS GIS]

#2048: i.pansharpen limited to 8-bit imagery
-+-
  Reporter:  Nikos   |  Owner:  grass-dev@…
  Alexandris |
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.6.1
 Component:  Imagery |Version:  svn-trunk
Resolution:  |   Keywords:  i.pansharpen, sharpening, fusion,
 |  brovey, ihs, pca, 8-bit
   CPU:  All |   Platform:  Unspecified
-+-

Comment (by Nikos Alexandris):

 Replying to [comment:35 cmbarton]:
 > I am hoping that someone can test the revised code. I'll work on
 updating the docs a bit to match the new options.

 I will, as soon as I find some time.


 > The algorithms used in the script were devised with assumed 8bit image
 channels. The math might work with other bit depths, but other assumptions
 might be violated. Maybe someone else can clarify. Beyond that, the
 histogram matching method would need to be redesigned to accommodate
 imagery other than 8bit.  Allowing for floating point image value would
 require yet more reworking, including new versions of i.rgb.his and
 i.his.rgb. Hence, rescaling the original images to 8 bit seems like a good
 solution at the present.

 I understand.  Let's go step by step then.


 > While I'm comfortable with downscaling from higher to lower bit depth
 (e.g., 16 down to 8), I'm less comfortable with upscaling imagery at less
 than 8 bits.

 I agree. Yet, my understanding is, no rescaling should be performed.  What
 goes in, should go out. Some loss of precision due to rounding applies.
 But no other loss should be justified.  And this should be our target.
 Histogram matching doesn't or shouldn't care either about the input range.
 It should respect the given range, be it 4-bit or 64-bit.  Some histogram
 matching routines, though, will introduce values to fill-in gaps while
 trying to match a "real world" histogram with the one of a function. But
 this is not rescaling.

 > I tried this on 3bit imagery (rescaled from 8bit landsat) and it
 produced visually poor results that do not show the level of feature
 differentiation seen in the 3 bit pan channel alone. So keeping it at
 ≥8bit seems advisable unless there is a reason pan "sharpening" of lower
 bit depth is actually useful for something.

 Pan-sharpening fuses low and high spatial resolution images. These images
 are expected to capture the same object, in different dimensions. If we
 have 4-bit images, one high-res at 1m and one, or more, low-res at 4m,
 then these will be a valid subject for pan-sharpening.  Please correct me
 if I am wrong.


 > The cutoff at 32 bits is arbitrary and could easily be increased to
 higher values. Any reason to do this or not do this if the images are
 rescaled to 8bits for processing anyway?

 What about we support the maximum possible bitness that the GRASS raster
 engine can handle?

 > If you run i.pansharpen in the terminal, anything outside the 8-32 bit
 range will already generate an error with a message that bit depth is
 outside the allowed range.


 I did and I did not read any error. Unless I did not try your latest
 update.
 In any case, thanks for taking the time to work on 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] #2048: i.pansharpen limited to 8-bit imagery

[GRASS GIS]

#2048: i.pansharpen limited to 8-bit imagery
-+-
  Reporter:  Nikos   |  Owner:  grass-dev@…
  Alexandris |
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.6.1
 Component:  Imagery |Version:  svn-trunk
Resolution:  |   Keywords:  i.pansharpen, sharpening, fusion,
 |  brovey, ihs, pca, 8-bit
   CPU:  All |   Platform:  Unspecified
-+-

Comment (by cmbarton):

 Replying to [comment:34 Nikos Alexandris]:
 > As for the histogram matching routine, here two related open source
 examples (written in Rust):
 >
 > https://github.com/jblindsay/whitebox-
 
tools/blob/266c939ad236c16503b088d2faa4500362912fef/src/tools/image_analysis/histogram_matching.rs
 >
 > and
 >
 > https://github.com/jblindsay/whitebox-
 
tools/blob/266c939ad236c16503b088d2faa4500362912fef/src/tools/image_analysis/histogram_matching_two_images.rs
 >
 > My understanding is that the implementation bases upon (64-bit) floating
 point.

 I would prefer to get this upgrade to i.pansharpen tested and into GRASS
 for use before any complete rewrite of the module (maybe a task for
 someone else).

-- 
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] #2048: i.pansharpen limited to 8-bit imagery

[GRASS GIS]

#2048: i.pansharpen limited to 8-bit imagery
-+-
  Reporter:  Nikos   |  Owner:  grass-dev@…
  Alexandris |
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.6.1
 Component:  Imagery |Version:  svn-trunk
Resolution:  |   Keywords:  i.pansharpen, sharpening, fusion,
 |  brovey, ihs, pca, 8-bit
   CPU:  All |   Platform:  Unspecified
-+-

Comment (by cmbarton):

 I am hoping that someone can test the revised code. I'll work on updating
 the docs a bit to match the new options.

 The algorithms used in the script were devised with assumed 8bit image
 channels. The math might work with other bit depths, but other assumptions
 might be violated. Maybe someone else can clarify. Beyond that, the
 histogram matching method would need to be redesigned to accommodate
 imagery other than 8bit.  Allowing for floating point image value would
 require yet more reworking, including new versions of i.rgb.his and
 i.his.rgb. Hence, rescaling the original images to 8 bit seems like a good
 solution at the present.

 While I'm comfortable with downscaling from higher to lower bit depth
 (e.g., 16 down to 8), I'm less comfortable with upscaling imagery at less
 than 8 bits. I tried this on 3bit imagery (rescaled from 8bit landsat) and
 it produced visually poor results that do not show the level of feature
 differentiation seen in the 3 bit pan channel alone. So keeping it at
 ≥8bit seems advisable unless there is a reason pan "sharpening" of lower
 bit depth is actually useful for something. The cutoff at 32 bits is
 arbitrary and could easily be increased to higher values. Any reason to do
 this or not do this if the images are rescaled to 8bits for processing
 anyway?

 If you run i.pansharpen in the terminal, anything outside the 8-32 bit
 range will already generate an error with a message that bit depth is
 outside the allowed range. If you do it in the GUI, a message will only be
 generated in the console. I could add a wxPython pop up, but not sure it
 is worth it. Maybe the best is to have the module fail (i.e., with a
 return) if bit depth is outside the acceptable range rather than set it
 back to 8.

-- 
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] #2048: i.pansharpen limited to 8-bit imagery

[GRASS GIS]

#2048: i.pansharpen limited to 8-bit imagery
-+-
  Reporter:  Nikos   |  Owner:  grass-dev@…
  Alexandris |
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:  7.6.1
 Component:  Imagery |Version:  svn-trunk
Resolution:  |   Keywords:  i.pansharpen, sharpening, fusion,
 |  brovey, ihs, pca, 8-bit
   CPU:  All |   Platform:  Unspecified
-+-

Comment (by Nikos Alexandris):

 As for the histogram matching routine, here two related open source
 examples (written in Rust):

 https://github.com/jblindsay/whitebox-
 
tools/blob/266c939ad236c16503b088d2faa4500362912fef/src/tools/image_analysis/histogram_matching.rs

 and

 https://github.com/jblindsay/whitebox-
 
tools/blob/266c939ad236c16503b088d2faa4500362912fef/src/tools/image_analysis/histogram_matching_two_images.rs

 My understanding is that the implementation bases upon (64-bit) floating
 point.

-- 
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 + PROJ 6 + GDAL 2.5

[Roger Bivand]

Since rgdal::make_EPSG() is facing the same problems of listing tabulated
EPSG fields as g.proj -l, I was very happy to see Markus' code in
g.proj/main.c mentioned in this thread, and have used this approach in
https://r-forge.r-project.org/scm/viewvc.php/pkg/src/proj_info6.cpp?view=markup&root=rgdal
 

However, there are plenty of messages such as: "proj_as_proj_string:
Unsupported conversion method: Lambert Conic Conformal (West Orientated)". I
haven't installed GRASS trunk with PROJ6, so I can't see whether g.proj -l
also sees the same messages. If it does, maybe we could ask on the proj list
how they might be captured for summary reporting. I think they are coming
from line 5758 in src/iso19111/coordinateoperation.cpp or maybe line 906 in
same file. Maybe PROJ now has an error handler that 

Another question concerns the issue of whether one needs to free objects
created, in particular proj_crs_info and pj. Not so important for g.proj,
which exists when done, but important for rgdal whose functions don't exit.

Anyway, very helpful to see that Markus is looking at the same issues as we
are!

Roger





-
Roger Bivand
NHH Norwegian School of Economics, Bergen, Norway
--
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

Re: [GRASS-dev] [GRASS GIS] #3771: Run tests on Travis

[GRASS GIS]

#3771: Run tests on Travis
--+-
  Reporter:  pmav99   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:
 Component:  Tests|Version:  svn-trunk
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by sbl):

 In principle, fully agreed on all points regarding tests.

 Just to add some history. Python 3 support was to a significant amount
 worked on in a GSoC project in 2018
 (https://lists.osgeo.org/pipermail/soc/2018-August/004186.html), although
 that was a big step forward, open issues remained. And after that project
 finished, a decision had to be made to either merge the unfinished code
 (leading to failing tests) or wait and risk that merging the code later
 would become harder and harder. Decision was made for the latter (see
 r73229).

 Comparing test results before and after this commit (2018-09-02 vs.
 2018-09-03) can give an idea about failing tests because of introduction
 of Python 3 vs. other failures:

   *
 
http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2018-09-02-07-00/report_for_nc_basic_spm_grass7_nc/testsuites.html
   *
 
http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2018-09-03-07-00/report_for_empty_xy_all/testsuites.html


 So, making tests pass is a matter of resources (time) I guess, and I am
 sure contributions are more than welcome. The question is, what is the
 best way forward. Suggestions fromm my side would be to:

   * **Make the test suite and test coverage a topic for a community
 sprint**. If those who know the test suite well could help others (like
 me) to improve their procedures that would be really cool and appreciated.
   * **Prioritize move to git** if that helps people like you, Panos, to
 contribute and help with Python 3 support (which is supposed to be a focus
 for the 7.8 release) Really good to see your recent activity here, BTW!
   * **Crack down on the other 10%** of failing test (fix or deactivate
 temporarily if necessary as you suggest)

-- 
Ticket URL: 
GRASS GIS 

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