Re: [GRASS-dev] PROJ6 support in GRASS

[Even Rouault]

On mercredi 25 septembre 2019 22:47:21 CEST Markus Metz wrote:
> Several different methods might be available to reproject from one CRS to
> another CRS. PROJ6 can select the most appropriate method if a bounding box
> is provided. This means that the selected method depends on the bounding
> box and that results of a reprojection can differ depending on the provided
> bounding box.
> 
> In GRASS, this bounding box can be obtained from the current region. That
> means if the current region changes, the method and thus the results of
> coordinate reprojection might change. This effect can not be underestimated.
> 
> With the current pull request #118 the current region is used to help PROJ6
> select the best method, and [r|v].import should work as before. Results can
> be different compared to PROJ5 or earlier.
> 
> IMHO, there is no way around that users become more familiar with details
> of coordinate reprojection and need to read the output of [r|v].proj
> carefully regarding different methods known to PROJ6.
> 
> PROJ6 will not use the best method if any required datum transformation
> grid is not available. Users will need to obtain the corresponding grid
> themselves, which raises another question: where to put this grid? On
> Linux, this would be e.g. /usr/share/proj, but if the user can not write to
> /usr/share/proj, the grids need to be saved somewhere in $HOME, and PROJ6
> must look at that place. This problem, i.e. the place where PROJ6 should
> look for in $HOME is not yet solved AFAICT (proj-6.2.0).

Applications may decide for an appropriate user directory and set it with 
proj_context_set_search_paths() (in that case this overrides PROJ_LIB or 
hardcoded directories, so you have to add in the search paths if this is the 
desired behaviour)

QGIS has code to do exactly that:
https://github.com/qgis/QGIS/blob/65359bc7eafbfe967c669d1428eeedb87c5cd2a1/
src/core/qgsapplication.cpp#L312
and
https://github.com/qgis/QGIS/blob/d45c3dd4f1e8fe3642d42d84aa978b28dba913aa/
src/core/qgsprojutils.cpp#L258

-- 
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] PROJ6 support in GRASS

[Markus Metz]

Several different methods might be available to reproject from one CRS to
another CRS. PROJ6 can select the most appropriate method if a bounding box
is provided. This means that the selected method depends on the bounding
box and that results of a reprojection can differ depending on the provided
bounding box.

In GRASS, this bounding box can be obtained from the current region. That
means if the current region changes, the method and thus the results of
coordinate reprojection might change. This effect can not be underestimated.

With the current pull request #118 the current region is used to help PROJ6
select the best method, and [r|v].import should work as before. Results can
be different compared to PROJ5 or earlier.

IMHO, there is no way around that users become more familiar with details
of coordinate reprojection and need to read the output of [r|v].proj
carefully regarding different methods known to PROJ6.

PROJ6 will not use the best method if any required datum transformation
grid is not available. Users will need to obtain the corresponding grid
themselves, which raises another question: where to put this grid? On
Linux, this would be e.g. /usr/share/proj, but if the user can not write to
/usr/share/proj, the grids need to be saved somewhere in $HOME, and PROJ6
must look at that place. This problem, i.e. the place where PROJ6 should
look for in $HOME is not yet solved AFAICT (proj-6.2.0).

Markus M

On Wed, Sep 4, 2019 at 9:46 PM Markus Metz 
wrote:

>
>
> On Wed, Sep 4, 2019 at 6:01 PM Markus Neteler  wrote:
> >
> > On Wed, Sep 4, 2019 at 4:31 AM Anna Petrášová 
> wrote:
> > > On Tue, Sep 3, 2019 at 4:22 AM Markus Metz <
> markus.metz.gisw...@gmail.com> wrote:
> > >>
> > >> Hi all,
> > >>
> > >> there is a new PR for PROJ6 support in GRASS
> > >> https://github.com/OSGeo/grass/pull/118
> > >>
> > >> There are two important changes when using PROJ6:
> > >>
> > >> First, reprojection with v.proj and r.proj is no longer always
> possible without the user making informed decisions. The reason is that
> there can be several different operations available to reproject
> coordinates from one CRS to another CRS. These different operations are
> listed and the user has to provide the appropriate operation with the
> pipeline option, taking care of any axisswap.
> > >
> > > first, thanks for all the work. Second, I don't see how most users are
> supposed to know what to pick. Is there perhaps a way to pick a good
> default? I just can't imagine not having r.import/v.import...
> >
> > I see the same problem: users won't know what to select if defaults
> > are gone with PROJ 6.
>
> We can provide information that enables users to make an informed
> decision. The options listed by PROJ6 are ordered by guessed best choice,
> i.e. the first one is, given the provided information, the best choice. But
> users need to review the list of options.
>
> Reprojection from one CRS to another CRS was never easy. For both raster
> and vector data, some preparation was always needed to decide on
> appropriate settings. PROJ6 provides methods to improve the accuracy of
> reprojected coordinates, depending on the actual use case. The user decides
> (must decide).
> >
> > > Anna
> > >>
> > >>
> > >> Second, axis order is no longer always easting, northing, e.g. for
> EPSG:4326 it is northing, easting, and an axisswap might need to be removed
> from operations provided by PROJ.
> > >>
> > >> There are many more changes (see details in the PR), but these are
> the two most important ones.
> > >>
> > >> Feedback welcome!
> >
> > Thanks for your hard work.
> >
> > I talked to Robert Bivand here at the GeoSTAT 2019 in Münster who gave
> > a talk about the topic:
> >
> > "Not just R-spatial: sustaining open source geospatial software stacks"
> > https://github.com/rsbivand/geostat19_talk
> >
> > You can quick-view the talk in rendered HTML like this (maybe there
> > are better ways):
> >
> http://htmlpreview.github.io/?https://raw.githubusercontent.com/rsbivand/geostat19_talk/master/docs/geostat_bivand_19.html
> >
> > It contains a section about PROJ (6).
>
> Not so random citation:
> "...we need to manipulate the CRS read in with the file to insert our
> choice of how to make the transformation..."
>
> I will try to restrict the number of options based on the current region
> in a modified PR.
>
> Markus M
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3901: Addons missing in Makefile

[GRASS GIS]

#3901: Addons missing in Makefile
--+-
  Reporter:  sbl  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:
 Component:  Addons   |Version:  unspecified
Resolution:   |   Keywords:  Makefile
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by neteler):

 Replying to [comment:4 sbl]:
 > Now, I updated the [https://github.com/OSGeo/grass-addons/pull/30 PR]
 so, modules with a DEPRECATED file are filtered out. I would be glad if
 someone could test it.

 Great, thanks for the re-work (didn't test yet).

 > With this change all Makefiles in raster, vector, temporal, imagery,
 general would be identical. So it is probably better to include the
 content of the Makefiles one level higher (meaning on the grass-
 addon/grass7/ hierarchy?

 ... not sure what you mean?

 > Regarding the filtering of deprecated modules: What about adding a
 deprecation warning to the manual instead of not building it? That way,
 also deprecated modules can be discovered and inspected on the addon
 manual website, but with a clear information that module ''r.in.whatever''
 has been superseded by ''r.in.newandawsome'' (or what ever the reason for
 the deprecation was)?

 I think that the overview page would become pretty cluttered. Maybe (in
 case) in a separate section but overall, it would be an extra maintenance
 burden for rather old code which if often not even any more compatible
 with the current GRASS GIS libs.

-- 
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] #3913: new feature band reference breaks space time vector datasets (was: new feature image collections breaks space time vector datasets)

[GRASS GIS]

#3913: new feature band reference breaks space time vector datasets
---+-
  Reporter:  mmetz |  Owner:  grass-dev@…
  Type:  defect| Status:  new
  Priority:  blocker   |  Milestone:  8.0.0
 Component:  Temporal  |Version:  svn-trunk
Resolution:|   Keywords:  image collections,stvds
   CPU:  All   |   Platform:  All
---+-

Comment (by mmetz):

 See [https://github.com/OSGeo/grass/pull/132 PR #132]

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] [GRASS GIS] #3913: new feature image collections breaks space time vector datasets

[GRASS GIS]

#3913: new feature image collections breaks space time vector datasets
-+-
 Reporter:  mmetz|  Owner:  grass-dev@…
 Type:  defect   | Status:  new
 Priority:  blocker  |  Milestone:  8.0.0
Component:  Temporal |Version:  svn-trunk
 Keywords:  image collections,stvds  |CPU:  All
 Platform:  All  |
-+-
 When trying to register vector maps in a stvds I get

 {{{
 ERROR: 'VectorDataset' object has no attribute
'read_band_reference_from_grass'
 }}}

-- 
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] #3639: Write table like output directly to database

[GRASS GIS]

#3639: Write table like output directly to database
--+--
  Reporter:  sbl  |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  8.0.0
 Component:  Database |Version:  svn-trunk
Resolution:   |   Keywords:  table,database,write
   CPU:  Unspecified  |   Platform:  Unspecified
--+--

Comment (by sbl):

 I am considering adding a function to the Python scripting library for
 parsing table-like stdout from GRASS modules into Numpy arrays. Nothing
 complicated, but probably a convenient wrapper function!?

 See:

 {{{
 def stdout2numpy(stdout=None, sep=',', names=False, null_value=None,
  fill_value=None, comments='#', usecols=None):
 """Read table-like output from grass modules as Numpy array;
 format instructions are handed down to Numpys genfromtxt function

 param str|byte stdout: tabular stdout from GRASS GIS module call
 param str sep: Separator delimiting columns
 param list names: List of strings with names for columns
 param str null_value: Characters representing the no-data value
 param str fill_value: Value to fill no-data with
 param str comments: Character that
 param list usecols: List of columns to import

 """
 import numpy as np
 from io import BytesIO
 if type(stdout) == str:
 stdout = gscript.encode(stdout)
 elif type(stdout) != byte:
 gscript.fatal(_('Unsupported data type'))
 np_array = np.genfromtxt(BytesIO(stdout),
  missing_values=null_value,
  filling_values=fill_value,
  usecols=usecols,
  names=names,
  dtype=None, delimiter=sep)
 return np_array

 }}}

 or alternatively as np_parse_command (equivalent to parse_command()):

 {{{
 def np_parse_command(*args, **kwargs):
 """Passes all arguments to read_command, then parses the output
 using Numpys genfromtxt() function to generate a Numpy array from
 table like output.

 Parsing options in Numpys genfromtxt() function can be
 optionally given by parse dictionary, e.g.

 ::

 parse_command(..., parse = { 'delimiter' : '|' }))

 As far as possible, at least standard parser options in GRASS
 commands are handed down and translated to genfromtxt()
 automatically, e.g. separator (GRASS) -> delimiter (Numpy).

 import numpy as np
 from io import BytesIO
 stdout = read_command(*args, **kwargs)
 if type(stdout) == str:
 stdout = gscript.encode(stdout)
 elif type(stdout) != byte:
 gscript.fatal(_('Unsupported data type'))


 filling_values = parse['filling_values'] if 'filling_values' in parse
 else np.nan
 usecols = parse['usecols'] if 'usecols' in parse else None
 names = parse['names'] if 'names' in parse else None
 dtype = parse['dtype'] if 'dtype' in parse else None

 # Check if separator is specified in GRASS command
 if 'delimiter' not in parse:
 if 'separator' in args:
 parse['delimiter'] = args['separator']
 elif 'separator' in kwargs:
 parse['delimiter'] = kwargs['separator']
 else:
 parse['delimiter'] = ','

 # Check if null_value is specified in GRASS command
 if 'missing_values' not in parse:
 if 'null_value' in args:
 parse['missing_values'] = args['null_value']
 elif 'null_value' in kwargs:
 parse['missing_values'] = kwargs['null_value']
 else:
 parse['missing_values'] = '*'

 np_array = np.genfromtxt(BytesIO(stdout), **parse)
 return np_array

 }}}

 That would probably be a first step for a Python function that can write
 output to DB...

 Any thoughts/opinions?

-- 
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] #3901: Addons missing in Makefile

[GRASS GIS]

#3901: Addons missing in Makefile
--+-
  Reporter:  sbl  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:
 Component:  Addons   |Version:  unspecified
Resolution:   |   Keywords:  Makefile
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by sbl):

 Now, I updated the [https://github.com/OSGeo/grass-addons/pull/30 PR] so,
 modules with a DEPRECATED file are filtered out. I would be glad if
 someone could test it.

 With this change all Makefiles in raster, vector, temporal, imagery,
 general would be identical. So it is probably better to include the
 content of the Makefiles one level higher (meaning on the grass-
 addon/grass7/ hierarchy?

 Regarding the filtering of deprecated modules: What about adding a
 deprecation warning to the manual instead of not building it? That way,
 also deprecated modules can be discovered and inspected on the addon
 manual website, but with a clear information that module ''r.in.whatever''
 has been superseded by ''r.in.newandawsome'' (or what ever the reason for
 the deprecation was)?

-- 
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] #3618: v.distance: allow copying multiple attributes from nearest feature

[GRASS GIS]

#3618: v.distance: allow copying multiple attributes from nearest feature
--+-
  Reporter:  sbl  |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  closed
  Priority:  normal   |  Milestone:  7.6.2
 Component:  Vector   |Version:  unspecified
Resolution:  wontfix  |   Keywords:  v.distance
   CPU:  All  |   Platform:  All
--+-
Changes (by sbl):

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


Comment:

 Of course, one can use the primary key of the to map in to_column and then
 run v.db.join. That is probably good enough...

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] issue with the compilation of several addons: ImportError: No module named lib.gis

[Markus Neteler]

On Wed, Sep 25, 2019 at 2:39 PM Anna Petrášová  wrote:
>
> I assume some problem with ctypes compilation.

Some time ago, I had to run
git checkout lib/python/ctypes/ctypesgencore/parser/lextab.py

to cleanup my local system(s). Maybe that's needed on the server
compiling the addons as well?
@Martin Landa could you check please?

Markus



> On Wed, Sep 25, 2019 at 5:56 AM Moritz Lennert  
> wrote:
>>
>> Hi,
>>
>> Several addon modules are currently not compiled (imagery/i.cutlines,
>> imagery/i.fusion.hpf, imagery/i.image.bathymetry, raster/r.cell.area,
>> raster/r.gradient, raster/r.series.filter, etc). All show the same error
>> message: "ImportError: No module named lib.gis".
>>
>> Any ideas where this comes from ?
>>
>> Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] issue with the compilation of several addons: ImportError: No module named lib.gis

[Anna Petrášová]

I assume some problem with ctypes compilation.

On Wed, Sep 25, 2019 at 5:56 AM Moritz Lennert 
wrote:

> Hi,
>
> Several addon modules are currently not compiled (imagery/i.cutlines,
> imagery/i.fusion.hpf, imagery/i.image.bathymetry, raster/r.cell.area,
> raster/r.gradient, raster/r.series.filter, etc). All show the same error
> message: "ImportError: No module named lib.gis".
>
> Any ideas where this comes from ?
>
> Moritz
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] issue with the compilation of several addons: ImportError: No module named lib.gis

[Moritz Lennert]

Hi,

Several addon modules are currently not compiled (imagery/i.cutlines, 
imagery/i.fusion.hpf, imagery/i.image.bathymetry, raster/r.cell.area, 
raster/r.gradient, raster/r.series.filter, etc). All show the same error 
message: "ImportError: No module named lib.gis".


Any ideas where this comes from ?

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