Re: [GRASS-dev] [GRASS GIS] #3900: Go back to using community version of ctypesgen

[GRASS GIS]

#3900: Go back to using community version of ctypesgen
+-
  Reporter:  ossalanr   |  Owner:  grass-dev@…
  Type:  defect | Status:  new
  Priority:  normal |  Milestone:  8.0.0
 Component:  Python ctypes  |Version:  unspecified
Resolution: |   Keywords:
   CPU:  All|   Platform:  All
+-
Changes (by annakrat):

 * milestone:   => 8.0.0


Comment:

 That's great, it would be preferable to use your version. Not sure how
 much work it is to get it working with GRASS, there are some differences.

-- 
Ticket URL: 
GRASS GIS 

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

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

[Markus Neteler]

On Wed, Sep 4, 2019 at 4:31 AM Anna Petrášová  wrote:
> On Tue, Sep 3, 2019 at 4:22 AM Markus Metz  
> wrote:
>>
>> Hi all,
>>
>> there is a new PR for PROJ6 support in GRASS
>> https://github.com/OSGeo/grass/pull/118
>>
>> There are two important changes when using PROJ6:
>>
>> First, reprojection with v.proj and r.proj is no longer always possible 
>> without the user making informed decisions. The reason is that there can be 
>> several different operations available to reproject coordinates from one CRS 
>> to another CRS. These different operations are listed and the user has to 
>> provide the appropriate operation with the pipeline option, taking care of 
>> any axisswap.
>
> first, thanks for all the work. Second, I don't see how most users are 
> supposed to know what to pick. Is there perhaps a way to pick a good default? 
> I just can't imagine not having r.import/v.import...

I see the same problem: users won't know what to select if defaults
are gone with PROJ 6.

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

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

Re: [GRASS-dev] [EXTERNAL] Re: PROJ6 support in GRASS

[Newcomb, Doug]

Markus,
Thank you for working on this!

 Perhaps a flag to default to the transformation with the least error ( via
something like the  projinfo  -s x -t y --summary  query and with details
captured about the option selected  in the metadata)?
https://media.ccc.de/v/bucharest-198-revamp-of-coordinate-reference-system-management-in-the-osgeo-c-c-stack-with-proj-and-gdal#t=666
around
10:33 minutes in.

Looking at the reprojection options in QGIS 3.8.2 the menu for picking the
reprojection option lists the accuracy, the number of contributing
stations, and a preferred alternative. If this data can be gleaned from a
projinfo query, a preferred alternative can be established.  I would not
make that the default.

A sample workflow would be that someone tries r.proj with no flags. If
there are multiple alternatives, it does not proceed and gives a message
along the lines of " Multiple projection options detected, please rerun
with --info flag to see alternatives.

User reruns with --info flag ( which supersedes all other flags )  and sees
5 alternatives with accuracy and number of stations listed with an asterisk
next to the "preferred" alternative

User runs r.proj with a --prefer flag that takes the option with the least
error and most stations.  Alternatively, --file flag that points to a text
file with a proj6 pipeline to enforce exactly what is desired.

The preferred option may not always be the same over time, but if the
pipeline is captured in the metadata you will have a record of how it was
done.

Doug



On Tue, Sep 3, 2019 at 10:31 PM Anna Petrášová 
wrote:

> Hi,
>
>
> On Tue, Sep 3, 2019 at 4:22 AM Markus Metz 
> wrote:
>
>> Hi all,
>>
>> there is a new PR for PROJ6 support in GRASS
>> https://github.com/OSGeo/grass/pull/118
>>
>> There are two important changes when using PROJ6:
>>
>> First, reprojection with v.proj and r.proj is no longer always possible
>> without the user making informed decisions. The reason is that there can be
>> several different operations available to reproject coordinates from one
>> CRS to another CRS. These different operations are listed and the user has
>> to provide the appropriate operation with the pipeline option, taking care
>> of any axisswap.
>>
>
> first, thanks for all the work. Second, I don't see how most users are
> supposed to know what to pick. Is there perhaps a way to pick a good
> default? I just can't imagine not having r.import/v.import...
>
> Anna
>
>>
>> Second, axis order is no longer always easting, northing, e.g. for
>> EPSG:4326 it is northing, easting, and an axisswap might need to be removed
>> from operations provided by PROJ.
>>
>> There are many more changes (see details in the PR), but these are the
>> two most important ones.
>>
>> Feedback welcome!
>> ___
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/grass-dev
>
>

-- 
Doug Newcomb - Cartographer
USFWS
551F Pylon Dr
Raleigh, NC
919-856-4520 ext. 14 doug_newc...@fws.gov
-

*NOTE: This email correspondence and any attachments to and from this
sender is subject to the Freedom of Information Act (FOIA) and may be
disclosed to third parties.*
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3899: g.gui.gmodeler: loading of modeller file broken with TypeError

[GRASS GIS]

#3899: g.gui.gmodeler: loading of modeller file broken with TypeError
--+-
  Reporter:  neteler  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.8.0
 Component:  wxGUI|Version:  unspecified
Resolution:   |   Keywords:  python3
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by pesekon2):

 Replying to [comment:2 neteler]:

 > Only this msg clutter remained:
 >
 > {{{
 > /home/mundialis/software/grass78_git/dist.x86_64-pc-linux-
 gnu/gui/wxpython/gmodeler/dialogs.py:952: wxPyDeprecationWarning: Call to
 deprecated item. Use InsertItem instead.
 >   index = self.InsertStringItem(i, str(i))
 > /home/mundialis/software/grass78_git/dist.x86_64-pc-linux-
 gnu/gui/wxpython/gmodeler/dialogs.py:953: wxPyDeprecationWarning: Call to
 deprecated item. Use SetItem instead.
 >   self.SetStringItem(index, 0, name)
 > /home/mundialis/software/grass78_git/dist.x86_64-pc-linux-
 gnu/gui/wxpython/gmodeler/dialogs.py:954: wxPyDeprecationWarning: Call to
 deprecated item. Use SetItem instead.
 >   self.SetStringItem(index, 1, inloop)
 > /home/mundialis/software/grass78_git/dist.x86_64-pc-linux-
 gnu/gui/wxpython/gmodeler/dialogs.py:955: wxPyDeprecationWarning: Call to
 deprecated item. Use SetItem instead.
 >   self.SetStringItem(index, 2, param)
 > /home/mundialis/software/grass78_git/dist.x86_64-pc-linux-
 gnu/gui/wxpython/gmodeler/dialogs.py:956: wxPyDeprecationWarning: Call to
 deprecated item. Use SetItem instead.
 >   self.SetStringItem(index, 3, desc)
 > }}}

 Yes, I know. Yesterday, I have created a pull request to get rid of these
 messages (they appeared on more places after switching to wxPython4):
 https://github.com/OSGeo/grass/pull/120

-- 
Ticket URL: 
GRASS GIS 

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