[Proj] Coming releases of PROJ.4
richard.greenwood at gmail.com
Wed Jun 28 20:03:04 EST 2017
I'm really excited to see these proposals and totally unqualified to
comment on the technical aspects. I'll only half seriously throw out my
thought on naming/numbering. Rather than "Proj.4 10.0" I think something
like "cs2cs version 2.0" would be better. Projections are just that and
that's all Proj.4 did under Gerald Evenden. Correctly if I'm wrong, but I
don't think Proj.4 had any sense of datums until Frank Wamerdam took on
maintenance of the project. Aside from Charles Karney's work on etmerc I
haven't seen much happening with projections, but datums are increasingly
important and will become even more so over at least the next decade.
Like I said, this is only a half serious suggestion, but maybe a more
creative mind than mine could come up with a name more accurately conveys
what Proj.4 currently is without completely divorcing itself from its
When I started what is now called "proj4js" I named is "CSCS" as a play on
cs2cs as well as Client Side Coordinate Systems (client being browser
name be more important than trying to convey its larger role.
On Tue, Jun 27, 2017 at 7:36 AM, Thomas Knudsen <knudsen.thomas at gmail.com>
> You need time tagging of observations in order to transform from a global
> reference frame (WGS84, ITRF) to a plate fixed (NAD83, ETRS89).
> For a next generation of dynamic datums, this will be even more of an
> issue, although in ways that are not totally clear as yet.
> 2017-06-26 15:17 GMT+02:00 caress <caress at mbari.org>:
>> Thanks. Looking again at the discussion thread it should have been clear
>> to me that the functions used by MB-System are not changing.
>> With respect to time dependence, we certainly are doing repeated seafloor
>> surveys that resolve both lateral and vertical deformation. For instance,
>> on Axial seamount our repeated 1-m-scale bathymetry surveys show ~10-m wide
>> fissures that opened coincident with the 2011 and 2015 eruptions, and
>> annual repeat surveys are measuring the several tens of cm of uplift each
>> year associated with the inflation of the subsurface magma reservoir.
>> However, I’m not sure how having time dependence in Proj can tie into our
>> representing or modeling this deformation. Any advice would be welcome.
>> > On Jun 24, 2017, at 8:57 AM, Thomas Knudsen <knudsen.thomas at gmail.com>
>> > Dave,
>> > We are NOT changing the API of a core dependency of yours. We are
>> adding a new, more coherent one, in anticipation of a growing need of fully
>> dynamic datum transformations.
>> > The new API in proj.h is orthogonal to the classic API in proj_api.h
>> > I do, however, expect that you will need the functionality exposed in
>> the new API - if not now, then in a few years time.
>> > /Thomas
>> > 2017-06-24 10:46 GMT+02:00 caress <caress at mbari.org>:
>> > As the architect of a package, I have similar feelings about anyone
>> that changes the API of a core dependency.
>> > _______________________________________________
>> > Proj mailing list
>> > Proj at lists.maptools.org
>> > http://lists.maptools.org/mailman/listinfo/proj
>> David W. Caress
>> Software Engineer
>> Monterey Bay Aquarium Research Institute
>> 7700 Sandholdt Road
>> Moss Landing, CA 95039
>> caress at mbari.org
>> Phone: 831-775-1775
>> Proj mailing list
>> Proj at lists.maptools.org
> Proj mailing list
> Proj at lists.maptools.org
Richard W. Greenwood, PLS
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Proj