[PROJ] Use of EPSG codes in proj_create()

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

[PROJ] Use of EPSG codes in proj_create()

Oliver Eichler-2
Hi,

I am working on the transition of QMapShack from version 4 to version 5
API. So far so good. There is only on thing that breaks. The use of EPSG
codes for projection strings.

That's what I try to do:

     // used PROJ version: 6.0.0
     // PJ * pj = proj_create(PJ_DEFAULT_CTX, "EPSG:3395");      // [1]
result for x and y is inf
     PJ * pj = proj_create(PJ_DEFAULT_CTX, "+proj=merc");        // [2]
result is expected one
     // PJ * pj = proj_create(PJ_DEFAULT_CTX, "+init=EPSG:3395") // [3]
pj is nullptr
     PJ_COORD pt = {11 * DEG_TO_RAD, 48 * DEG_TO_RAD};
     size_t s = proj_trans_generic(pj, PJ_FWD,
                                 &pt.xy.x, 0, 1,
                                 &pt.xy.y, 0, 1,
                                 0,0,0,
                                 0,0,0);


If I use [1] to create a PJ object I succeed with a pointer. However if
I use it in proj_trans_generic() the result for x and y ins INF.

Version [2] is fine and works as expected.

Version [3] fails to create a PJ object, but as far as I understand the
docs this is perfectly fine.

So how is this intended to work? Maybe a bit of background about this:
QMapShack addresses consumers not scientific users. The experience of
the last years revealed that it is much easier to tell a user to use an
EPSG code as projection rather than a lengthy "+proj=..." string with
all kinds of possibilities to introduce typos. That's why I would like
to keep the possibility to use EPSSG codes.


Thanks for feedback

Oliver

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

Re: Use of EPSG codes in proj_create()

Even Rouault-2
On mardi 2 avril 2019 10:38:45 CEST Oliver Eichler wrote:

> Hi,
>
> I am working on the transition of QMapShack from version 4 to version 5
> API. So far so good. There is only on thing that breaks. The use of EPSG
> codes for projection strings.
>
> That's what I try to do:
>
>      // used PROJ version: 6.0.0
>      // PJ * pj = proj_create(PJ_DEFAULT_CTX, "EPSG:3395");      // [1]
> result for x and y is inf
>      PJ * pj = proj_create(PJ_DEFAULT_CTX, "+proj=merc");        // [2]
> result is expected one
>      // PJ * pj = proj_create(PJ_DEFAULT_CTX, "+init=EPSG:3395") // [3]
> pj is nullptr
>      PJ_COORD pt = {11 * DEG_TO_RAD, 48 * DEG_TO_RAD};
>      size_t s = proj_trans_generic(pj, PJ_FWD,
>                                  &pt.xy.x, 0, 1,
>                                  &pt.xy.y, 0, 1,
>                                  0,0,0,
>                                  0,0,0);
>

With PROJ 6, [1] instanciates a CRS object, not a coordinate transformation.
So proj_trans_generic() will return an error on it. You'd rather want to use
proj_create_crs_to_crs() with in the source CRS a geographic CRS and as target
CRS, "EPSG:3395". The coordinates passed and returned to/from
proj_trans_generic will have to follow the axis order and units of the source
and target CRS
See https://proj4.org/faq.html#why-is-the-axis-ordering-in-proj-not-consistent

[2] matches the PROJ 5 behaviour, and creates a coordinate operation using the
merc method. Input units and axis order is longitude, latitude in radians.

[3] is a deprecated syntax in PROJ 6. The reason is that older versions of
PROJ didn't respect the EPSG axis order in a lot of situations, and we didn't
want that to go on when using the new API.

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Use of EPSG codes in proj_create()

Oliver Eichler-2
Thanks for the answer! :D

But I still wonder what is the best way to get the same functionality as
with pj_transform(). It might not have been the most standard conform
thing but it did the job quite good and consistent. Now it seems to be
that everyone needs to write a beast that analyzes the axis ordering,
analyzes the coordinate format, fix all input to match requirements, do
the conversion and normalize all output.

It's a good thing for sure to have all these functions separately to use
them in an optimized way if possible. But on the other hand side a high
level function like pj_transform() that simply hides all the details
behind a very simple and generic interface would be nice to have, too.

Or do I miss the obvious?

Oliver


Am 2019-04-02 12:44, schrieb Even Rouault:

> On mardi 2 avril 2019 10:38:45 CEST Oliver Eichler wrote:
>> Hi,
>>
>> I am working on the transition of QMapShack from version 4 to version
>> 5
>> API. So far so good. There is only on thing that breaks. The use of
>> EPSG
>> codes for projection strings.
>>
>> That's what I try to do:
>>
>>      // used PROJ version: 6.0.0
>>      // PJ * pj = proj_create(PJ_DEFAULT_CTX, "EPSG:3395");      //
>> [1]
>> result for x and y is inf
>>      PJ * pj = proj_create(PJ_DEFAULT_CTX, "+proj=merc");        //
>> [2]
>> result is expected one
>>      // PJ * pj = proj_create(PJ_DEFAULT_CTX, "+init=EPSG:3395") //
>> [3]
>> pj is nullptr
>>      PJ_COORD pt = {11 * DEG_TO_RAD, 48 * DEG_TO_RAD};
>>      size_t s = proj_trans_generic(pj, PJ_FWD,
>>                                  &pt.xy.x, 0, 1,
>>                                  &pt.xy.y, 0, 1,
>>                                  0,0,0,
>>                                  0,0,0);
>>
>
> With PROJ 6, [1] instanciates a CRS object, not a coordinate
> transformation.
> So proj_trans_generic() will return an error on it. You'd rather want
> to use
> proj_create_crs_to_crs() with in the source CRS a geographic CRS and as
> target
> CRS, "EPSG:3395". The coordinates passed and returned to/from
> proj_trans_generic will have to follow the axis order and units of the
> source
> and target CRS
> See
> https://proj4.org/faq.html#why-is-the-axis-ordering-in-proj-not-consistent
>
> [2] matches the PROJ 5 behaviour, and creates a coordinate operation
> using the
> merc method. Input units and axis order is longitude, latitude in
> radians.
>
> [3] is a deprecated syntax in PROJ 6. The reason is that older versions
> of
> PROJ didn't respect the EPSG axis order in a lot of situations, and we
> didn't
> want that to go on when using the new API.
>
> Even
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Use of EPSG codes in proj_create()

Paul Ramsey
I understand (in an “I understand your premises but don’t share them” kind of way) the push back from the real live geodesists, but if PROJ doesn’t provide, then every downstream project is going to end up with one of these


P.

On Apr 2, 2019, at 11:08 AM, Oliver Eichler <[hidden email]> wrote:

Thanks for the answer! :D

But I still wonder what is the best way to get the same functionality as with pj_transform(). It might not have been the most standard conform thing but it did the job quite good and consistent. Now it seems to be that everyone needs to write a beast that analyzes the axis ordering, analyzes the coordinate format, fix all input to match requirements, do the conversion and normalize all output.

It's a good thing for sure to have all these functions separately to use them in an optimized way if possible. But on the other hand side a high level function like pj_transform() that simply hides all the details behind a very simple and generic interface would be nice to have, too.

Or do I miss the obvious?

Oliver


Am 2019-04-02 12:44, schrieb Even Rouault:
On mardi 2 avril 2019 10:38:45 CEST Oliver Eichler wrote:
Hi,
I am working on the transition of QMapShack from version 4 to version 5
API. So far so good. There is only on thing that breaks. The use of EPSG
codes for projection strings.
That's what I try to do:
    // used PROJ version: 6.0.0
    // PJ * pj = proj_create(PJ_DEFAULT_CTX, "EPSG:3395");      // [1]
result for x and y is inf
    PJ * pj = proj_create(PJ_DEFAULT_CTX, "+proj=merc");        // [2]
result is expected one
    // PJ * pj = proj_create(PJ_DEFAULT_CTX, "+init=EPSG:3395") // [3]
pj is nullptr
    PJ_COORD pt = {11 * DEG_TO_RAD, 48 * DEG_TO_RAD};
    size_t s = proj_trans_generic(pj, PJ_FWD,
                                &pt.xy.x, 0, 1,
                                &pt.xy.y, 0, 1,
                                0,0,0,
                                0,0,0);
With PROJ 6, [1] instanciates a CRS object, not a coordinate transformation.
So proj_trans_generic() will return an error on it. You'd rather want to use
proj_create_crs_to_crs() with in the source CRS a geographic CRS and as target
CRS, "EPSG:3395". The coordinates passed and returned to/from
proj_trans_generic will have to follow the axis order and units of the source
and target CRS
See https://proj4.org/faq.html#why-is-the-axis-ordering-in-proj-not-consistent
[2] matches the PROJ 5 behaviour, and creates a coordinate operation using the
merc method. Input units and axis order is longitude, latitude in radians.
[3] is a deprecated syntax in PROJ 6. The reason is that older versions of
PROJ didn't respect the EPSG axis order in a lot of situations, and we didn't
want that to go on when using the new API.
Even
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj


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

Re: Use of EPSG codes in proj_create()

Even Rouault-2
In reply to this post by Oliver Eichler-2
On mardi 2 avril 2019 20:08:46 CEST Oliver Eichler wrote:
> Thanks for the answer! :D
>
> But I still wonder what is the best way to get the same functionality as
> with pj_transform(). It might not have been the most standard conform
> thing but it did the job quite good and consistent. Now it seems to be
> that everyone needs to write a beast that analyzes the axis ordering,
> analyzes the coordinate format, fix all input to match requirements, do
> the conversion and normalize all output.

PROJ master (future 6.1.0) has a new proj_normalize_for_visualization()
function that takes a pedantic-axis-order compliant PJ object (returned by
proj_create_crs_to_crs()) and add the needed axis swapping to get the
traditional GIS friendly order.

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Use of EPSG codes in proj_create()

Paul Ramsey
:) life is grand. So every downstream project will have an #ifdef’d implementation for version 6.0 ;)

P

> On Apr 2, 2019, at 11:13 AM, Even Rouault <[hidden email]> wrote:
>
> On mardi 2 avril 2019 20:08:46 CEST Oliver Eichler wrote:
>> Thanks for the answer! :D
>>
>> But I still wonder what is the best way to get the same functionality as
>> with pj_transform(). It might not have been the most standard conform
>> thing but it did the job quite good and consistent. Now it seems to be
>> that everyone needs to write a beast that analyzes the axis ordering,
>> analyzes the coordinate format, fix all input to match requirements, do
>> the conversion and normalize all output.
>
> PROJ master (future 6.1.0) has a new proj_normalize_for_visualization()
> function that takes a pedantic-axis-order compliant PJ object (returned by
> proj_create_crs_to_crs()) and add the needed axis swapping to get the
> traditional GIS friendly order.
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> _______________________________________________
> PROJ mailing list
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/proj

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

Re: Use of EPSG codes in proj_create()

Even Rouault-2
On mardi 2 avril 2019 11:15:54 CEST Paul Ramsey wrote:
> :) life is grand. So every downstream project will have an #ifdef’d
> :implementation for version 6.0 ;)

Just require PROJ 6.1. Will be released May 1st

We had to release the 6.0 beast anyway so that people actually start testing
and providing feedback. Apparently nobody wants to be EPSG axis compliant :-)

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Use of EPSG codes in proj_create()

Martin Desruisseaux-3
In reply to this post by Paul Ramsey
Le 02/04/2019 à 20:13, Paul Ramsey a écrit :

> I understand (in an “I understand your premises but don’t share them”
> kind of way) the push back from the real live geodesists, but if PROJ
> doesn’t provide, then every downstream project is going to end up with
> one of these
>
This is debatable. In my past experience with GeoTools, the desire for
(longitude, latitude) axis order was largely caused by reluctance to use
mathematical constructs like affine transforms. The usual argument is
that peoples don't want to bother about such mathematics. I think it is
unfortunate, since 20 years of development in GIS convinced me that
mastering affine transforms enable better sofware, making issues like
axis order practically vanishing. More generally, even now I'm still
amazed by the power of mathematics (not just affine transforms). Of
course learning how to use affine transform and acquiring the discipline
to use them extensively requires effort, but the gain is largely worth
in my opinion. Downstream projects developed that way do not necessarily
need methods for reordering axes.

Note 1: this is of course not an objection against the inclusion of a
proj_normalize_for_visualization() method. This is only a reaction on
the "every downstream project will want (longitude, latitude)" thinking.

Note 2: in this email I'm talking about developers, of course not end users.

    Martin


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

Re: Use of EPSG codes in proj_create()

Oliver Eichler-2
In reply to this post by Even Rouault-2
>
> PROJ master (future 6.1.0) has a new proj_normalize_for_visualization()
> function that takes a pedantic-axis-order compliant PJ object (returned
> by
> proj_create_crs_to_crs()) and add the needed axis swapping to get the
> traditional GIS friendly order.

sounds promising. Will there be an example in the migration guide? Right
now this guide is pretty frustrating. It gives you a rough example of
something that does not even match the old behavior and the rest is
"find out yourself". No documentation in the headers. No obvious link to
API documentation on the web page. Yes, I found it by chance using
Google. I don't want to complain too much, but so far the migration is
more a PITA than anything else.

It would really help to have example code to restore the old complex
functions like pj_transform(). Keep in mind that you introduced quite
some pitfalls that will break the software using PROJ silently. The
moment a user uses a CRS that does it different the software will fail
leading to a bug report, a lot of investigation why it breaks, the
realization that new PROJ introduced inconsistencies (from the user's
point of view) and finally patching the software that uses PROJ over and
over again. This will be a very frustrating experience for every party
involved.

Would that be possible?

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

Re: Use of EPSG codes in proj_create()

Kristian Evers-2
To be honest I am leaning towards killing the migration guide. It was an attempt at making
it easier to move from proj_api.h to proj.h but since it was written a lot have happened
and the premise has changed. Instead I would rather write a couple of proper pages
demonstrating the use of the current API. If done properly it should be sufficient help
for those migrating old code to use the new API and will be better suited for newcomers.

But it raises the question: What sort of things will be useful to demonstrate on doc pages
like that?

/Kristian

> On 2 Apr 2019, at 20:59, Oliver Eichler <[hidden email]> wrote:
>
>> PROJ master (future 6.1.0) has a new proj_normalize_for_visualization()
>> function that takes a pedantic-axis-order compliant PJ object (returned by
>> proj_create_crs_to_crs()) and add the needed axis swapping to get the
>> traditional GIS friendly order.
>
> sounds promising. Will there be an example in the migration guide? Right now this guide is pretty frustrating. It gives you a rough example of something that does not even match the old behavior and the rest is "find out yourself". No documentation in the headers. No obvious link to API documentation on the web page. Yes, I found it by chance using Google. I don't want to complain too much, but so far the migration is more a PITA than anything else.
>
> It would really help to have example code to restore the old complex functions like pj_transform(). Keep in mind that you introduced quite some pitfalls that will break the software using PROJ silently. The moment a user uses a CRS that does it different the software will fail leading to a bug report, a lot of investigation why it breaks, the realization that new PROJ introduced inconsistencies (from the user's point of view) and finally patching the software that uses PROJ over and over again. This will be a very frustrating experience for every party involved.
>
> Would that be possible?
>
> Oliver
> _______________________________________________
> PROJ mailing list
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/proj

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

Re: Use of EPSG codes in proj_create()

Even Rouault-2
In reply to this post by Oliver Eichler-2
On mardi 2 avril 2019 20:59:11 CEST Oliver Eichler wrote:

> > PROJ master (future 6.1.0) has a new proj_normalize_for_visualization()
> > function that takes a pedantic-axis-order compliant PJ object (returned
> > by
> > proj_create_crs_to_crs()) and add the needed axis swapping to get the
> > traditional GIS friendly order.
>
> sounds promising. Will there be an example in the migration guide? Right
> now this guide is pretty frustrating. It gives you a rough example of
> something that does not even match the old behavior and the rest is
> "find out yourself". No documentation in the headers. No obvious link to
> API documentation on the web page. Yes, I found it by chance using
> Google.

Any suggestion on how to make it more accessible ?

>
> It would really help to have example code to restore the old complex
> functions like pj_transform(). Keep in mind that you introduced quite
> some pitfalls that will break the software using PROJ silently. The
> moment a user uses a CRS that does it different the software will fail
> leading to a bug report, a lot of investigation why it breaks, the
> realization that new PROJ introduced inconsistencies (from the user's
> point of view) and finally patching the software that uses PROJ over and
> over again. This will be a very frustrating experience for every party
> involved.
>
> Would that be possible?

Kristian filed https://github.com/OSGeo/proj.4/issues/1403 this morning about
updating the example / quickstart
I've just filed https://github.com/OSGeo/proj.4/issues/1407 for a Version 5
->Version 6 migration guide

Documentation contributions are also accepted :-)

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Use of EPSG codes in proj_create()

Oliver Eichler-2
>> sounds promising. Will there be an example in the migration guide?
>> Right
>> now this guide is pretty frustrating. It gives you a rough example of
>> something that does not even match the old behavior and the rest is
>> "find out yourself". No documentation in the headers. No obvious link
>> to
>> API documentation on the web page. Yes, I found it by chance using
>> Google.
>
> Any suggestion on how to make it more accessible ?

Easy ;) "PROJ API Documentation" as top level item in the left hand
menu.

And as a developer using this API I would expect the documentation to be
part of the header files. Don't know why you guys don't like Doxygen.

Cheers

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

Re: Use of EPSG codes in proj_create()

Oliver Eichler-2
In reply to this post by Kristian Evers-2

> But it raises the question: What sort of things will be useful to
> demonstrate on doc pages
> like that?
>

Well, as mentioned, it should contain a code snippet that restores the
old functionality of pj_transform(). I would guess that is in close to
100% of the migration cases the function to migrate. It does not have to
be necessarily API compliant to pj_transform(). But it shouldn't break
the functionality. And if it does this has to be documented as detailed
as possible.

There is no problem in telling the users that there has been a version
change and some things have to be done different. As long as I can point
out what's different and provide an example for the alternative. But
"Ooops it breaks because it's different and I don't really know why and
how to fix it" isn't satisfying for anyone.

And probably examples how to port the other complex functions like
pj_datum_transform(), pj_geocentric_to_geodetic(),
pj_geodetic_to_geocentric(), pj_compare_datums() and
pj_apply_gridshift() would be helpful. The rest of the functions seems
to be simple enough to be replaced by some counterpart of the new API.
But a complete table would help. The current one seems to be a bit
short.




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

Re: Use of EPSG codes in proj_create()

Kristian Evers-3
In reply to this post by Oliver Eichler-2


> On 3 Apr 2019, at 07:45, Oliver Eichler <[hidden email]> wrote:
>
>>> sounds promising. Will there be an example in the migration guide? Right
>>> now this guide is pretty frustrating. It gives you a rough example of
>>> something that does not even match the old behavior and the rest is
>>> "find out yourself". No documentation in the headers. No obvious link to
>>> API documentation on the web page. Yes, I found it by chance using
>>> Google.
>> Any suggestion on how to make it more accessible ?
>
> Easy ;) "PROJ API Documentation" as top level item in the left hand menu.
>

Yes, this should be done. Easy fix.

> And as a developer using this API I would expect the documentation to be part of the header files. Don't know why you guys don't like Doxygen.
>

We do in fact use Doxygen. At least for some of the code. The code is documented where it is implemented and not in the header files.
I don’t see this changing anytime soon.

/Kristian

> Cheers
>
> Oliver
> _______________________________________________
> PROJ mailing list
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/proj

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

Re: Use of EPSG codes in proj_create()

Kristian Evers-2
In reply to this post by Oliver Eichler-2
As you’ve already found out, maintaining the PROJ docs is not the most active area of work.
For that reason I am somewhat hesitant on making a lot of transition guides because they would
only be of interest for a limited time period and take time from writing docs that are generally
applicable to all developers. They are also extremely difficult to write since the old API’s are
poorly documented, so the code has to be studied carefully to determine what a given function
does.

I prefer to write good introductions to the API instead of spending
time on mapping old API functions to the new API. If the development guides are written properly
they will be of use both for developers migrating from an old API to the new API and for people
starting from scratch.

Unfortunately, I myself haven’t got much available time to work on this the next couple of months.
I hope someone else has available time to pull the heavy load on this one. I am very happy to
give feedback on any documenation contributions.

To finish off this mail I just want to remind everyone that the PROJ docs are better than they ever
have been before. The API’s in projects.h and proj_api.h was practically undocumented for ~20
years. Bridging that gap is a hell of a task and it is not one that anyone particularly enjoys working
on. So please be patient. We’ll get there eventually. Sooner if we get help from the community.
All inputs are valuable to us so we can spend time on the things that are the most need of fixing.

Thanks to everyone who’s pointed out shortcomings in the documentation. Hopefully we will be
able to address those quickly!

/Kristian

> On 3 Apr 2019, at 08:04, Oliver Eichler <[hidden email]> wrote:
>
>
>> But it raises the question: What sort of things will be useful to
>> demonstrate on doc pages
>> like that?
>
> Well, as mentioned, it should contain a code snippet that restores the old functionality of pj_transform(). I would guess that is in close to 100% of the migration cases the function to migrate. It does not have to be necessarily API compliant to pj_transform(). But it shouldn't break the functionality. And if it does this has to be documented as detailed as possible.
>
> There is no problem in telling the users that there has been a version change and some things have to be done different. As long as I can point out what's different and provide an example for the alternative. But "Ooops it breaks because it's different and I don't really know why and how to fix it" isn't satisfying for anyone.
>
> And probably examples how to port the other complex functions like pj_datum_transform(), pj_geocentric_to_geodetic(), pj_geodetic_to_geocentric(), pj_compare_datums() and pj_apply_gridshift() would be helpful. The rest of the functions seems to be simple enough to be replaced by some counterpart of the new API. But a complete table would help. The current one seems to be a bit short.
>
>
>
>
> _______________________________________________
> PROJ mailing list
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/proj

_______________________________________________
PROJ mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/proj