Time for a new release?

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

Re: Time for a new release?

Norman Vine-2

> On Nov 10, 2017, at 1:47 PM, Markus Neteler <[hidden email]> wrote:
>
> On Nov 10, 2017 7:29 PM, "Sebastiaan Couwenberg" <[hidden email]> wrote:
> ...
> > The new release is and major version bump is a good opportunity to
> > de-emphasize the "4" that crept into the naming. The project in Trac is
> > just called "proj", as is its package name in Debian, the name of this
> > mailinglist, etc.
>
> Yes, this upcoming release is a good occasion to de-emphasize the "4".
>
> > Having the next release be PROJ v.5.0.0 is fine with me.
>
> Yes, like this the name will be separated from the version number and future-ready.

+1
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Time for a new release?

J Luis
In reply to this post by Charles Karney
On Fri, 10 Nov 2017 18:24:16 -0000, Charles Karney  
<[hidden email]> wrote:

> Yes and no on "PROJ.4 v 5.0.0".  I agree that it sounds contradictory.
> However the name PROJ.4 is firmly baked into many places; e.g., PROJ4 is
> the Cmake package name.  So I vote for "PROJ.4 v 5.0.0" since it signals
> a major change and yet won't needless causes other things to break.

Fully agree.

Joaquim


>
>    --Charles
>
> On 11/10/17 10:51, Howard Butler wrote:
>> I'm interested to hear other opinions, although I suppose version
>> numbering is the ultimate bike shedding exercise. I agree it's going
>> to cause churn, and that churn was my primary objection to
>> incrementing the name in the first place. That said, it seems
>> dissonant to me to call it PROJ.4 v 5.0.0.
> _______________________________________________
> Proj mailing list
> [hidden email]
> http://lists.maptools.org/mailman/listinfo/proj
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Time for a new release?

Howard Butler-3
In reply to this post by Norman Vine-2
On Fri, Nov 10, 2017 at 12:53 PM, Norman Vine <[hidden email]> wrote:

>> Yes, this upcoming release is a good occasion to de-emphasize the "4".
>>
>> > Having the next release be PROJ v.5.0.0 is fine with me.
>>
>> Yes, like this the name will be separated from the version number and future-ready.
>
> +1

This is enough consensus to satisfy me.

PROJ v5.0.0 it is!

Howard
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Time for a new release?

Greg Troxel-2

Howard Butler <[hidden email]> writes:

> On Fri, Nov 10, 2017 at 12:53 PM, Norman Vine <[hidden email]> wrote:
>
>>> Yes, this upcoming release is a good occasion to de-emphasize the "4".
>>>
>>> > Having the next release be PROJ v.5.0.0 is fine with me.
>>>
>>> Yes, like this the name will be separated from the version number and future-ready.
>>
>> +1
>
> This is enough consensus to satisfy me.
>
> PROJ v5.0.0 it is!
Sounds good to me to.

FWIW, the current pkgsrc package is:

  proj-4.9.3

and it installs:

  /usr/pkg/include/org_proj4_PJ.h
  /usr/pkg/include/org_proj4_Projections.h
  /usr/pkg/include/proj_api.h
  /usr/pkg/include/projects.h
  /usr/pkg/lib/libproj.la
  /usr/pkg/lib/libproj.a
  /usr/pkg/lib/libproj.so
  /usr/pkg/lib/libproj.so.12
  /usr/pkg/lib/libproj.so.12.0.0
  /usr/pkg/lib/pkgconfig/proj.pc

so the big thing remaining is whether the include paths that  have 4 in
them are staying, or if all the code that uses it are going to have to
search for two pathnames and have HAVE_ ifdefs  from
autoconf/cmake/whatever.

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj

signature.asc (167 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Time for a new release?

Kristian Evers-2
PROJ v. 5.0.0 is also good with me. It also brings us into "braking changes territory". With this in mind I think we should consider only supporting the new API in proj.h and dropping the other APIs. This will allow us to simplify the code immensely. At the moment we jump through a bunch of hoops to keep backwards compatibility. We'd probably still do that for the next release, but not having projects.h and proj_api.h as part of the public API we can change things behind the scenes in future releases.


Kristian

-----Oprindelig meddelelse-----
Fra: [hidden email] [mailto:[hidden email]] På vegne af Greg Troxel
Sendt: 10. november 2017 22:24
Til: Howard Butler <[hidden email]>
Cc: PROJ.4 and general Projections Discussions <[hidden email]>
Emne: Re: [Proj] Time for a new release?


Howard Butler <[hidden email]> writes:

> On Fri, Nov 10, 2017 at 12:53 PM, Norman Vine <[hidden email]> wrote:
>
>>> Yes, this upcoming release is a good occasion to de-emphasize the "4".
>>>
>>> > Having the next release be PROJ v.5.0.0 is fine with me.
>>>
>>> Yes, like this the name will be separated from the version number and future-ready.
>>
>> +1
>
> This is enough consensus to satisfy me.
>
> PROJ v5.0.0 it is!

Sounds good to me to.

FWIW, the current pkgsrc package is:

  proj-4.9.3

and it installs:

  /usr/pkg/include/org_proj4_PJ.h
  /usr/pkg/include/org_proj4_Projections.h
  /usr/pkg/include/proj_api.h
  /usr/pkg/include/projects.h
  /usr/pkg/lib/libproj.la
  /usr/pkg/lib/libproj.a
  /usr/pkg/lib/libproj.so
  /usr/pkg/lib/libproj.so.12
  /usr/pkg/lib/libproj.so.12.0.0
  /usr/pkg/lib/pkgconfig/proj.pc

so the big thing remaining is whether the include paths that  have 4 in
them are staying, or if all the code that uses it are going to have to
search for two pathnames and have HAVE_ ifdefs  from
autoconf/cmake/whatever.
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Time for a new release?

Kurt Schwehr-2
Sorry if I am not seeing something that exists.  Is there a document that explains how to transition from the old APIs to the new?

On Nov 11, 2017 9:34 AM, "Kristian Evers" <[hidden email]> wrote:
PROJ v. 5.0.0 is also good with me. It also brings us into "braking changes territory". With this in mind I think we should consider only supporting the new API in proj.h and dropping the other APIs. This will allow us to simplify the code immensely. At the moment we jump through a bunch of hoops to keep backwards compatibility. We'd probably still do that for the next release, but not having projects.h and proj_api.h as part of the public API we can change things behind the scenes in future releases.


Kristian

-----Oprindelig meddelelse-----
Fra: [hidden email] [mailto:[hidden email]] På vegne af Greg Troxel
Sendt: 10. november 2017 22:24
Til: Howard Butler <[hidden email]>
Cc: PROJ.4 and general Projections Discussions <[hidden email]>
Emne: Re: [Proj] Time for a new release?


Howard Butler <[hidden email]> writes:

> On Fri, Nov 10, 2017 at 12:53 PM, Norman Vine <[hidden email]> wrote:
>
>>> Yes, this upcoming release is a good occasion to de-emphasize the "4".
>>>
>>> > Having the next release be PROJ v.5.0.0 is fine with me.
>>>
>>> Yes, like this the name will be separated from the version number and future-ready.
>>
>> +1
>
> This is enough consensus to satisfy me.
>
> PROJ v5.0.0 it is!

Sounds good to me to.

FWIW, the current pkgsrc package is:

  proj-4.9.3

and it installs:

  /usr/pkg/include/org_proj4_PJ.h
  /usr/pkg/include/org_proj4_Projections.h
  /usr/pkg/include/proj_api.h
  /usr/pkg/include/projects.h
  /usr/pkg/lib/libproj.la
  /usr/pkg/lib/libproj.a
  /usr/pkg/lib/libproj.so
  /usr/pkg/lib/libproj.so.12
  /usr/pkg/lib/libproj.so.12.0.0
  /usr/pkg/lib/pkgconfig/proj.pc

so the big thing remaining is whether the include paths that  have 4 in
them are staying, or if all the code that uses it are going to have to
search for two pathnames and have HAVE_ ifdefs  from
autoconf/cmake/whatever.
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj

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

Re: Time for a new release?

Kristian Evers-2

Doesn’t exist yet. I’ve created an issue for it: https://github.com/OSGeo/proj.4/issues/653

 

/Kristian

 

Fra: [hidden email] [mailto:[hidden email]] På vegne af Kurt Schwehr
Sendt: 11. november 2017 18:56
Til: PROJ.4 and general Projections Discussions <[hidden email]>
Emne: Re: [Proj] Time for a new release?

 

Sorry if I am not seeing something that exists.  Is there a document that explains how to transition from the old APIs to the new?

 

On Nov 11, 2017 9:34 AM, "Kristian Evers" <[hidden email]> wrote:

PROJ v. 5.0.0 is also good with me. It also brings us into "braking changes territory". With this in mind I think we should consider only supporting the new API in proj.h and dropping the other APIs. This will allow us to simplify the code immensely. At the moment we jump through a bunch of hoops to keep backwards compatibility. We'd probably still do that for the next release, but not having projects.h and proj_api.h as part of the public API we can change things behind the scenes in future releases.


Kristian

-----Oprindelig meddelelse-----
Fra: [hidden email] [mailto:[hidden email]] På vegne af Greg Troxel
Sendt: 10. november 2017 22:24
Til: Howard Butler <[hidden email]>
Cc: PROJ.4 and general Projections Discussions <[hidden email]>
Emne: Re: [Proj] Time for a new release?


Howard Butler <[hidden email]> writes:

> On Fri, Nov 10, 2017 at 12:53 PM, Norman Vine <[hidden email]> wrote:
>
>>> Yes, this upcoming release is a good occasion to de-emphasize the "4".
>>>
>>> > Having the next release be PROJ v.5.0.0 is fine with me.
>>>
>>> Yes, like this the name will be separated from the version number and future-ready.
>>
>> +1
>
> This is enough consensus to satisfy me.
>
> PROJ v5.0.0 it is!

Sounds good to me to.

FWIW, the current pkgsrc package is:

  proj-4.9.3

and it installs:

  /usr/pkg/include/org_proj4_PJ.h
  /usr/pkg/include/org_proj4_Projections.h
  /usr/pkg/include/proj_api.h
  /usr/pkg/include/projects.h
  /usr/pkg/lib/libproj.la
  /usr/pkg/lib/libproj.a
  /usr/pkg/lib/libproj.so
  /usr/pkg/lib/libproj.so.12
  /usr/pkg/lib/libproj.so.12.0.0
  /usr/pkg/lib/pkgconfig/proj.pc

so the big thing remaining is whether the include paths that  have 4 in
them are staying, or if all the code that uses it are going to have to
search for two pathnames and have HAVE_ ifdefs  from
autoconf/cmake/whatever.
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj


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

Re: Time for a new release?

Even Rouault-2
In reply to this post by Kristian Evers-2

On samedi 11 novembre 2017 17:32:05 CET Kristian Evers wrote:

> PROJ v. 5.0.0 is also good with me. It also brings us into "braking changes

> territory". With this in mind I think we should consider only supporting

> the new API in proj.h and dropping the other APIs. This will allow us to

> simplify the code immensely.

 

Can you sketch a bit what would be simplified in doing so ?

 

> At the moment we jump through a bunch of hoops

> to keep backwards compatibility. We'd probably still do that for the next

> release, but not having projects.h and proj_api.h as part of the public API

> we can change things behind the scenes in future releases.

 

If I remember the analysis of Debian packages, while dropping projects.h would have a moderate impact, dropping proj_api.h would cause massive breakage. This would likely cause proj 5 to take months to years before being available in distributions due to many packages not being ready for it (and the proj_api.h -> proj.h port is the kind of change that needs to be done by upstream projects. not a quick&dirty hack that the packager can do)

Thus in this context of software distributions, applications that would be adapted to use the new API wouldn't be able to use it in practice for a long time. Worse, applications that would do the changes to support proj >= 5 would still to have to support both proj < 5 and proj >= 5 in a transition period if they want their new releases to be packaged. To make their life easier by avoiding to have them to support both API, a proj 5 should be available as packaged as fast as possible.

 

I'm wondering if there wouldn't be a way of having a proj_api.c compatibiliy layer that would use the new API behind the scene ? The projPJ struct could be something different than the PJ one, for example just storing the text. And when doing pj_transform() you would build a pipeline from the src and dest projPJ. Things like that. I believe the cost of creating this compatibility layer (assuming this is possible) would be worth it

 

 

Or alternate plan :

 

- for proj 5.0, add at top of proj_api.h

 

#ifndef I_AM_M_AWARE_PROJ_API_H_WILL_BE_REMOVED_IN_PROJ_5_1

#error "proj_api.h will be removed in proj 5.1. You can still use it for now by defining I_AM_AWARE_PROJ_API_H_WILL_BE_REMOVED_IN_PROJ_5_1, but you should strongly consider using proj.h now"

#endif

 

Perhaps do the same for projects.h, if we really want proj 5 to be a no-brainer for packagers

 

- for proj 5.1, remove proj_api.h (and projects.h)

 

 

Benefits:

* this would make proj 5 easy to be packaged, by avoiding a flag day

* applications would be clearly warned they have to do something, and have time to do the changes

* after proj 5.0 release, proj master could benefit from the needed cleanups.

 

Even

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


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

Re: Time for a new release?

Thomas Knudsen
Even, regarding simplification by elimination:

Obviously Kristian will want to answer this himself, but I would like to mention at least one thing (or perhaps rather aspect) that will buy us simplification by eliminating projects.h and proj_api.h:

We would get rid of the type-punning-by-preprocessor-defs that destroyed Gerald's classic PROJ.4 core API, (pj_init, pj_fwd, pj_inv, and pj_free), by turning XY and LP into UV behind the back of the user, such that XY xy is no longer adressed xy.x and xy.y, but xy.u and xy.v

We would also get rid of the half baked namespacing-and-information-hiding-by-misleading-typedef, implemented by e.g.
typedef void *projPJ, and typedef void *projCtx, rather than by forward declarations.

This kind of stuff has been hell to work around (see the text in the top of proj.h for rationale for the work). This is not said to belittle Frank's work, which has been of immense value for PROJ.4, and has kept it afloat and in constant evolution, for more than 15 years: His work is admirable, but has, naturally, been focused on whatever (or whom-ever) paid the bills.

This has given us support for vertical datums, support for NTv2, support for a "failrly accurate for the needs when it was introduced 15 years ago" interface function as pj_transform, which to a large degree succeeds in "giving the user what (s)he wants without asking too many annoying geodetic questions".

It has, however, also given us the, largely superfluous contexts, and the  fileapi, which, apart form missing a fgetc- style function, also in general suffer from a feeling of "work made for hire" for a specific customer, using it for in house stuff (only since it is largely unknown by search engines) - but now we have to maintain this stuff,without even knowing what the rationale behind was.

So yes - we could certainly benefit from skipping projects.h and proj_api.h : It will buy us some simplifications -  I'm just not sure that this is the right way to do things. More about this later.



2017-11-11 20:06 GMT+01:00 Even Rouault <[hidden email]>:

On samedi 11 novembre 2017 17:32:05 CET Kristian Evers wrote:

> PROJ v. 5.0.0 is also good with me. It also brings us into "braking changes

> territory". With this in mind I think we should consider only supporting

> the new API in proj.h and dropping the other APIs. This will allow us to

> simplify the code immensely.

 

Can you sketch a bit what would be simplified in doing so ?

 

> At the moment we jump through a bunch of hoops

> to keep backwards compatibility. We'd probably still do that for the next

> release, but not having projects.h and proj_api.h as part of the public API

> we can change things behind the scenes in future releases.

 

If I remember the analysis of Debian packages, while dropping projects.h would have a moderate impact, dropping proj_api.h would cause massive breakage. This would likely cause proj 5 to take months to years before being available in distributions due to many packages not being ready for it (and the proj_api.h -> proj.h port is the kind of change that needs to be done by upstream projects. not a quick&dirty hack that the packager can do)

Thus in this context of software distributions, applications that would be adapted to use the new API wouldn't be able to use it in practice for a long time. Worse, applications that would do the changes to support proj >= 5 would still to have to support both proj < 5 and proj >= 5 in a transition period if they want their new releases to be packaged. To make their life easier by avoiding to have them to support both API, a proj 5 should be available as packaged as fast as possible.

 

I'm wondering if there wouldn't be a way of having a proj_api.c compatibiliy layer that would use the new API behind the scene ? The projPJ struct could be something different than the PJ one, for example just storing the text. And when doing pj_transform() you would build a pipeline from the src and dest projPJ. Things like that. I believe the cost of creating this compatibility layer (assuming this is possible) would be worth it

 

 

Or alternate plan :

 

- for proj 5.0, add at top of proj_api.h

 

#ifndef I_AM_M_AWARE_PROJ_API_H_WILL_BE_REMOVED_IN_PROJ_5_1

#error "proj_api.h will be removed in proj 5.1. You can still use it for now by defining I_AM_AWARE_PROJ_API_H_WILL_BE_REMOVED_IN_PROJ_5_1, but you should strongly consider using proj.h now"

#endif

 

Perhaps do the same for projects.h, if we really want proj 5 to be a no-brainer for packagers

 

- for proj 5.1, remove proj_api.h (and projects.h)

 

 

Benefits:

* this would make proj 5 easy to be packaged, by avoiding a flag day

* applications would be clearly warned they have to do something, and have time to do the changes

* after proj 5.0 release, proj master could benefit from the needed cleanups.

 

Even

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj


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

Re: Time for a new release?

Kristian Evers-2
Thomas,

you said most of what I had in mind, so I’ll just add that almost all functions in the library today is part of the public API. Either through projects.h or proj_api.h. That doesn’t leave much room for refactoring in general. I recently touched the gridshifting code, but had to stay within the boundaries of the current functions in order to not break the API. I could have come up with better implementations if I had been able to change things at a deeper level. The biggest offender is projects.h which absolutely should be a private header.

Even,

I think it is possible to make a compatibility layer as you suggest. Most of what is needed is in place already. I understand your reasoning, though I am not too keen on taking on this task myself. Your alternative plan sounds better to me, although we would then introduce a breaking change at the 5.1.0 version, which kind of goes against the semantic versioning scheme that we ought to follow. It can easily be solved by changing your proposed error message to I_AM_M_AWARE_PROJ_API_H_WILL_BE_REMOVED_IN_PROJ_6_0 and then release version 6 a year after version 5. It should also be added to projects.h.

Anyway, I don’t want to restart the discussion we had a few months ago, I just wanted to take the temperature on this with the clear decision about going to version 5 in the next release.

/Kristian
 

On 13 Nov 2017, at 16:43, Thomas Knudsen <[hidden email]> wrote:

Even, regarding simplification by elimination:

Obviously Kristian will want to answer this himself, but I would like to mention at least one thing (or perhaps rather aspect) that will buy us simplification by eliminating projects.h and proj_api.h:

We would get rid of the type-punning-by-preprocessor-defs that destroyed Gerald's classic PROJ.4 core API, (pj_init, pj_fwd, pj_inv, and pj_free), by turning XY and LP into UV behind the back of the user, such that XY xy is no longer adressed xy.x and xy.y, but xy.u and xy.v

We would also get rid of the half baked namespacing-and-information-hiding-by-misleading-typedef, implemented by e.g.
typedef void *projPJ, and typedef void *projCtx, rather than by forward declarations.

This kind of stuff has been hell to work around (see the text in the top of proj.h for rationale for the work). This is not said to belittle Frank's work, which has been of immense value for PROJ.4, and has kept it afloat and in constant evolution, for more than 15 years: His work is admirable, but has, naturally, been focused on whatever (or whom-ever) paid the bills.

This has given us support for vertical datums, support for NTv2, support for a "failrly accurate for the needs when it was introduced 15 years ago" interface function as pj_transform, which to a large degree succeeds in "giving the user what (s)he wants without asking too many annoying geodetic questions".

It has, however, also given us the, largely superfluous contexts, and the  fileapi, which, apart form missing a fgetc- style function, also in general suffer from a feeling of "work made for hire" for a specific customer, using it for in house stuff (only since it is largely unknown by search engines) - but now we have to maintain this stuff,without even knowing what the rationale behind was.

So yes - we could certainly benefit from skipping projects.h and proj_api.h : It will buy us some simplifications -  I'm just not sure that this is the right way to do things. More about this later.



2017-11-11 20:06 GMT+01:00 Even Rouault <[hidden email]>:
On samedi 11 novembre 2017 17:32:05 CET Kristian Evers wrote:
> PROJ v. 5.0.0 is also good with me. It also brings us into "braking changes
> territory". With this in mind I think we should consider only supporting
> the new API in proj.h and dropping the other APIs. This will allow us to
> simplify the code immensely.

 

Can you sketch a bit what would be simplified in doing so ?

 

> At the moment we jump through a bunch of hoops
> to keep backwards compatibility. We'd probably still do that for the next
> release, but not having projects.h and proj_api.h as part of the public API
> we can change things behind the scenes in future releases.

 

If I remember the analysis of Debian packages, while dropping projects.h would have a moderate impact, dropping proj_api.h would cause massive breakage. This would likely cause proj 5 to take months to years before being available in distributions due to many packages not being ready for it (and the proj_api.h -> proj.h port is the kind of change that needs to be done by upstream projects. not a quick&dirty hack that the packager can do)
Thus in this context of software distributions, applications that would be adapted to use the new API wouldn't be able to use it in practice for a long time. Worse, applications that would do the changes to support proj >= 5 would still to have to support both proj < 5 and proj >= 5 in a transition period if they want their new releases to be packaged. To make their life easier by avoiding to have them to support both API, a proj 5 should be available as packaged as fast as possible.

 

I'm wondering if there wouldn't be a way of having a proj_api.c compatibiliy layer that would use the new API behind the scene ? The projPJ struct could be something different than the PJ one, for example just storing the text. And when doing pj_transform() you would build a pipeline from the src and dest projPJ. Things like that. I believe the cost of creating this compatibility layer (assuming this is possible) would be worth it

 

 

Or alternate plan :

 

- for proj 5.0, add at top of proj_api.h

 

#ifndef I_AM_M_AWARE_PROJ_API_H_WILL_BE_REMOVED_IN_PROJ_5_1
#error "proj_api.h will be removed in proj 5.1. You can still use it for now by defining I_AM_AWARE_PROJ_API_H_WILL_BE_REMOVED_IN_PROJ_5_1, but you should strongly consider using proj.h now"
#endif

 

Perhaps do the same for projects.h, if we really want proj 5 to be a no-brainer for packagers

 

- for proj 5.1, remove proj_api.h (and projects.h)

 

 

Benefits:
* this would make proj 5 easy to be packaged, by avoiding a flag day
* applications would be clearly warned they have to do something, and have time to do the changes
* after proj 5.0 release, proj master could benefit from the needed cleanups.

 

Even

 

--
Spatialys - Geospatial professional services

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj


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

Re: Time for a new release?

Kristian Evers-2
In reply to this post by Kurt Schwehr-2
Kurt,

I’ve hacked together a basic migration guide here https://kbevers.github.io/development/migration.html

I based it on the docs for the current API. It doesn’t go into detail with the many undocumented functions in proj_api.h. Please let me know if there’s is anything you think should be added or improved in the guide.

Kristian

On 11 Nov 2017, at 18:56, Kurt Schwehr <[hidden email]> wrote:

Sorry if I am not seeing something that exists.  Is there a document that explains how to transition from the old APIs to the new?


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

Re: Time for a new release?

Kurt Schwehr-2
Thanks!

On Wed, Nov 15, 2017 at 12:50 PM, Kristian Evers <[hidden email]> wrote:
Kurt,

I’ve hacked together a basic migration guide here https://kbevers.github.io/development/migration.html

I based it on the docs for the current API. It doesn’t go into detail with the many undocumented functions in proj_api.h. Please let me know if there’s is anything you think should be added or improved in the guide.

Kristian

On 11 Nov 2017, at 18:56, Kurt Schwehr <[hidden email]> wrote:

Sorry if I am not seeing something that exists.  Is there a document that explains how to transition from the old APIs to the new?


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj



--

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

Re: Time for a new release?

karney
In reply to this post by Kristian Evers-2
I have a selfish wish that I should be able to build current versions of
gdal and geotiff with either proj 4.9.x or proj 5.0.x.  However it seems
that proj 5.0.x won't be backward compatible (at the source code level).
Is this right?

I don't expect proj 5.x to maintain backward compatibility indefinitely.
However, if it is possible to provide it for a year or so, that would
definitely ease the incorporation of proj 5.x into our software
ecosystem.

If this isn't possible, it would be good to get started on new versions
of gdal and geotiff which work with the new proj API.

   --Charles

On 11/15/2017 03:50 PM, Kristian Evers wrote:

> Kurt,
>
> I’ve hacked together a basic migration guide here
> https://kbevers.github.io/development/migration.html
>
> I based it on the docs for the current API. It doesn’t go into detail
> with the many undocumented functions in proj_api.h. Please let me know
> if there’s is anything you think should be added or improved in the guide.
>
> Kristian
>
>> On 11 Nov 2017, at 18:56, Kurt Schwehr <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>> Sorry if I am not seeing something that exists.  Is there a document
>> that explains how to transition from the old APIs to the new?
>
>
>
> _______________________________________________
> Proj mailing list
> [hidden email]
> http://lists.maptools.org/mailman/listinfo/proj

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

Re: Time for a new release?

Roger Bivand
In reply to this post by Kristian Evers-2
Hi Kristian,

OK, thanks, this is a start.

Please consider adding an example with +proj=ob_tran - will it still require
the swapping of from and to projection definitions?

A further example showing how to catch errors when a projection definition
has no inverse (error handling when proj is running inside other software).

The basic guide should help for most of the standard cases, but the
transition will be easiest if the oddities are covered authoritatively
(otherwise we'll end up with lots of different work-arounds).

Best wishes,

Roger

PS. Please (very nicely) increment the version in the git repo master/trunk.
Until that is done, we're stuck as far as implementation of migration steps,
because conditioning on proj version is not possible.



-----
Roger Bivand
NHH Norwegian School of Economics, Bergen, Norway
--
Sent from: http://osgeo-org.1560.x6.nabble.com/PROJ-4-f3840930.html
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Roger Bivand
NHH Norwegian School of Economics, Bergen, Norway
Reply | Threaded
Open this post in threaded view
|

Re: Time for a new release?

Lukasz Komsta
In reply to this post by Kristian Evers-2

Dear All,

If my small contribution has a chance to be included
(https://github.com/OSGeo/proj.4/pull/662), then I am a lucky man that a
release is planned, as there will be quite short time to propagate this
new projection to software using PROJ4 (and it is some kind of "breaking
news" for Polish botany community).

Anyway, I must also honestly commend the source code of PROJ4. So far, I
programmed only my own projects wiht svn and never seriously contributed
anything to existing code (it is also my first experience with git).
PROJ4 is very well organized and it took me only an hour to be sure what
to change and where. It is a piece of good work and it is a pleasure to
have a contribution to such well done project.

Regards,
Lukasz
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Time for a new release?

Roger Bivand
In reply to this post by Roger Bivand
... and please explain PJ_FWD in the example - is it the macro in line 357
ff. in proj.h?

/* Apply transformation to observation - in forward or inverse direction */
enum PJ_DIRECTION {
    PJ_FWD   =  1,   /* Forward    */
    PJ_IDENT =  0,   /* Do nothing */
    PJ_INV   = -1    /* Inverse    */
};

The question about non-existent inverses will bite for PJ_INV - am I looking
in the right place i pj_internal.c, line 80 ff:

PJ_COORD pj_inv4d (PJ_COORD coo, PJ *P) {
    if (0!=P->inv4d)
        return P->inv4d (coo, P);
    if (0!=P->inv3d) {
        coo.lpz  =  pj_inv3d (coo.xyz, P);
        return coo;
    }
    if (0!=P->inv) {
        coo.lp  =  pj_inv (coo.xy, P);
        return coo;
    }
    proj_errno_set (P, EINVAL);
    return proj_coord_error ();
}

so a no-inverse definition sets an error number and returns HUGE_VAL,
pj_internal.c line 56:

/* Work around non-constness of MSVC HUGE_VAL by providing functions rather
than constants */
PJ_COORD proj_coord_error (void) {
    PJ_COORD c;
    c.v[0] = c.v[1] = c.v[2] = c.v[3] = HUGE_VAL;
    return c;
}

Can P->inv4d, P->inv3d and P->inv be read in the API?

These are the kinds of things that the migration guide could helpfully show.

Roger



-----
Roger Bivand
NHH Norwegian School of Economics, Bergen, Norway
--
Sent from: http://osgeo-org.1560.x6.nabble.com/PROJ-4-f3840930.html
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Roger Bivand
NHH Norwegian School of Economics, Bergen, Norway
Reply | Threaded
Open this post in threaded view
|

Re: Time for a new release?

Kristian Evers-2
In reply to this post by Roger Bivand
Roger,

Regarding the version number see https://github.com/OSGeo/proj.4/pull/673. Is that satisfactory?

Thanks for you inputs on the documentation. Obviously it is still very much under construction, so you won’t find an answer to all your questions just yet. It is better than ever though, so that’s a start. Unfortunately no one but me has shown an interest in getting the documentation in place so far. That is mostly because the API still changes rapidly and documentation efforts can easily be wasted. I have already burned my fingers on that a few times. The migration guide is not meant to be a stand-alone document. You will have to go through the regular development guide to find more information. See https://kbevers.github.io/development/index.html. As you can see I have planned on making a section on error handling. Just haven’t gotten round to it yet. There is also a bunch of general transformation setup info in the “Using PROJ.4” section. That stuff wil be not covered in the development guide.

I am not very familiar with ob_tran myself, so if you could provide me with an example I can better answer your question.

The API reference https://kbevers.github.io/development/reference/index.html is currently the most updated part of the documentation. There are examples for many of the functions.

Any input and help with the documentation is very appreciated. Create GitHub issues if there is something you think is missing or submit a pull request with new sections on your favourite topic. Otherwise it will be a very slow process of getting the documentation in a proper state.

Kristian



On 17 Nov 2017, at 09:32, Roger Bivand <[hidden email]> wrote:

Hi Kristian,

OK, thanks, this is a start.

Please consider adding an example with +proj=ob_tran - will it still require
the swapping of from and to projection definitions?

A further example showing how to catch errors when a projection definition
has no inverse (error handling when proj is running inside other software).

The basic guide should help for most of the standard cases, but the
transition will be easiest if the oddities are covered authoritatively
(otherwise we'll end up with lots of different work-arounds).

Best wishes,

Roger

PS. Please (very nicely) increment the version in the git repo master/trunk.
Until that is done, we're stuck as far as implementation of migration steps,
because conditioning on proj version is not possible.



-----
Roger Bivand
NHH Norwegian School of Economics, Bergen, Norway
--
Sent from: http://osgeo-org.1560.x6.nabble.com/PROJ-4-f3840930.html
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj


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

Re: Time for a new release?

Kristian Evers-2
In reply to this post by Roger Bivand
Roger,

To check if there’s an inverse use proj_pj_info: https://kbevers.github.io/development/reference/functions.html#c.proj_pj_info (click 
PJ_PROJ_INFO to see how the struct is defined)

You can not access P->fwd4d and friends in the public API. That is what the proj_trans* functions are for. The transformation direction is controlled with the PJ_DIRECTION enum.

I’ll try to fit that into the migration guide. Or better yet, you can submit a pull request with the changes you’d like to see.

Kristian


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

Re: Time for a new release?

Roger Bivand
In reply to this post by Kristian Evers-2
(Copied from a comment on the PR)

Will the acid test be that < 5, there is no config-proj --version at all (on
systems supporting config-*) but that proj_api.h declares the version? For
./configure, confirmation that config-proj --version returns the
authoritative version number if it exists is sufficient.



-----
Roger Bivand
NHH Norwegian School of Economics, Bergen, Norway
--
Sent from: http://osgeo-org.1560.x6.nabble.com/PROJ-4-f3840930.html
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Roger Bivand
NHH Norwegian School of Economics, Bergen, Norway
Reply | Threaded
Open this post in threaded view
|

Re: Time for a new release?

Greg Troxel-2
In reply to this post by Kristian Evers-2

Kristian Evers <[hidden email]> writes:

> PROJ v. 5.0.0 is also good with me. It also brings us into "braking
> changes territory". With this in mind I think we should consider only
> supporting the new API in proj.h and dropping the other APIs. This
> will allow us to simplify the code immensely. At the moment we jump
> through a bunch of hoops to keep backwards compatibility. We'd
> probably still do that for the next release, but not having projects.h
> and proj_api.h as part of the public API we can change things behind
> the scenes in future releases.

When thinking about a deprecation/migration path, please keep packaging
systems and the impacts on depending projects in mind.  This was pretty
painful with geos when there were only a small number of other packages
using deprecated/changed APIs.

Right now a very large amount of software uses the current/old/stable
API.  The main path to removing that should be:

  Publish a release with a new supported API.  Include in the release
  notes the intent to deprecate/remove the old one.

  Expect upstream software to look for the new API and use it, and if
  not found, use the old API.

  Perhaps have a release with a define that has to be on to use the old
  API.  But this doesn't really do what you think, because people
  maintaining packaging systems will notice the failure to build and
  turn on the define.

  Find all the projects that use proj and help/prod them into updating

  Eventually, decide that projects that have not both changed their code
  to use the new API and *had a formal release with the changes* are
  unmaintained and that packaging systems *should* drop them.

  Make a new proj release without the old API.   Understand that
  packaging system maintainers are now faced with a choice to hold off
  on updating proj or to remove other packages that haven't updated.

An alternate path is:

  Construct a new proj release that has a *completely disjoint set* of
  installed files, so that it's reasonable to have  proj 4 and proj 5
  installed.

  Do not have any compat in proj 5, and expect programs to migrate to it
  over time.

  Continue to have security updates, if warranted, for the old package.


I'm not sure what people are thinking, but I tend to hear things like
"people who haven't updated their code can just use the old version".
The problem is that packaging systems have to make choices, and almost
all software gets run via packaging systems.  And, as soon as some
programs move to requiring the new API only, it's not possible to run
everything on the same system if the current release of proj drops the
old API.


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj

signature.asc (167 bytes) Download Attachment
123