PROJ6 support in GRASS

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

PROJ6 support in GRASS

Markus Metz-3
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.

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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: PROJ6 support in GRASS

Anna Petrášová
Hi,


On Tue, Sep 3, 2019 at 4:22 AM Markus Metz <[hidden email]> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-dev

_______________________________________________
grass-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: [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á <[hidden email]> wrote:
Hi,


On Tue, Sep 3, 2019 at 4:22 AM Markus Metz <[hidden email]> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-dev


--
Doug Newcomb - Cartographer
USFWS
551F Pylon Dr
Raleigh, NC
919-856-4520 ext. 14 [hidden email]
---------------------------------------------------------------------------------------------------------

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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: PROJ6 support in GRASS

Markus Neteler
In reply to this post by Anna Petrášová
On Wed, Sep 4, 2019 at 4:31 AM Anna Petrášová <[hidden email]> wrote:

> On Tue, Sep 3, 2019 at 4:22 AM Markus Metz <[hidden email]> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: PROJ6 support in GRASS

Markus Metz-3


On Wed, Sep 4, 2019 at 6:01 PM Markus Neteler <[hidden email]> wrote:

>
> On Wed, Sep 4, 2019 at 4:31 AM Anna Petrášová <[hidden email]> wrote:
> > On Tue, Sep 3, 2019 at 4:22 AM Markus Metz <[hidden email]> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: PROJ6 support in GRASS

Markus Metz-3
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 <[hidden email]> wrote:


On Wed, Sep 4, 2019 at 6:01 PM Markus Neteler <[hidden email]> wrote:

>
> On Wed, Sep 4, 2019 at 4:31 AM Anna Petrášová <[hidden email]> wrote:
> > On Tue, Sep 3, 2019 at 4:22 AM Markus Metz <[hidden email]> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: PROJ6 support in GRASS

Even Rouault-2
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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: PROJ6 support in GRASS

Markus Metz-3


On Wed, Sep 25, 2019 at 10:55 PM Even Rouault <[hidden email]> wrote:

>
> On mercredi 25 septembre 2019 22:47:21 CEST Markus Metz wrote:
> >
> > 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

The (my) idea is that proj suggests reasonable paths to store grids, search paths should be available in PJ_INFO. Otherwise applications may decide for a directory specific to that application, not generally valid for proj used by different applications. Applications can then check the existing proj search paths and install grids to a path where the current user has write access. Thus no need to use proj_context_set_search_paths() and no need to install the same grid(s) repeatedly.

However, there are no default search paths in PJ_INFO. Can you give a hint where the default search paths accessible in the C API?

Markus M


_______________________________________________
grass-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: PROJ6 support in GRASS

Even Rouault-2
> The (my) idea is that proj suggests reasonable paths to store grids, search
> paths should be available in PJ_INFO. Otherwise applications may decide for
> a directory specific to that application, not generally valid for proj used
> by different applications. Applications can then check the existing proj
> search paths and install grids to a path where the current user has write
> access. Thus no need to use proj_context_set_search_paths() and no need to
> install the same grid(s) repeatedly.

That's not adressed indeed. Currently each application has to handle that for
itself.
I may work at a later point on something related, which is that PROJ would
automatically download the grids (actually the chunk of the grid it needs) it
needs if they are not already available.
That's the discussion in
https://lists.osgeo.org/pipermail/proj/2019-September/008858.html
We're currently half of that effort funded; we're looking for the other half

>
> However, there are no default search paths in PJ_INFO. Can you give a hint
> where the default search paths accessible in the C API?

Hum, proj_info().searchpath ? But I may not understand your question

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
grass-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-dev