[PROJ] Seeking clarification on PROJ support for temporal transformations
Joel Haasdyk
joel.haasdyk at customerservice.nsw.gov.au
Wed Aug 28 03:31:46 PDT 2019
Apologies for coming in late to the conversation, and replying to the DIGEST no less...
Certainly,
It is extremely important to bring into focus and differentiate between different ‘epochs’, e.g.
(1) ‘Epoch of Expression’ (i.e. the date at which the coordinate is described w.r.t. the CRS).
a. Explicit for time-dependence frames ITRF2014 (@epoch of expression)
b. Implicit for static frames: GDA2020, implicitly @2020.0)
c .Forgotten for the masses: WGS84(@epoch of expression???)
(2 ) ‘Epoch of Observation’ (i.e. the timestamp at which the data was gathered)
(3) ‘Realisation epoch’, (i.e. ITRF2014 vs ITRF2008)
(4) ‘Reference epoch’ (i.e. ITRF2014 has reference epoch 2010-01-01)
ARRRGGG!
I've just discovered that EPSG calls this the ‘realization epoch’. Why does it call (3) then??
See EPSG::7789 (ITRF2014), 5332 (ITRF2008), 4269 (NAD83), 7842 (GDA2020)
Of all of these, I think ‘Epoch of Expression’ is paramount!
• ‘Epoch of Expression’ is mandatory to properly describe the coordinate position in the CRS.
• ‘Epoch of Observation’ on the other hand is optional metadata.
Along with transformation methods (or lineage), this can be employed to recreate the original observations…
but is not _necessary_ to describe position.
Note1)
“ITRF2014(@2010.0), observed at [unknown epoch]”is more immediately useful, than
“ITRF2014(@unknown epoch), observed at 2015.9”
Note2)
As the rate of change of a dynamic feature approaches the rate of change of the tectonic plate,
the appropriate choice of how to describe the feature becomes more interesting.
ITRF2014(@2010) @timeseries isn’t a very informative dataset for a perfectly plate-fixed feature! ;-)
• ‘Realisation epoch’ simply forms part of the CRS definition, but can be a source of confusion for users.
This is simply an ‘identifier’ which usually denotes the era in which a datum was defined
(often denoting the latest data employed in the definition of the datum).
• ‘Reference Epoch’ is just used under the bonnet. E.g. the reference point (t0) for defining time-dependent
parameters such as in a 15 parameter transformation.
As for feature vs dataset level metadata, I’ve always thought feature level metadata was not practicable to implement, as Nyall has suggested below.
However, if I were to create a standard from scratch I would suggest that it should / could simply support the level of detail required by the user or application.
• Provide dataset level Epoch of Expression, and WHERE REQUIRED allow features to specify their own epoch which supersedes (or modifies) the data-level metadata.
• Separately, provide for (optional) dataset-level Epoch of Observation, which is also extensible to the feature level if required.
•Granularity of epoch could be achieved by the supplied precision,
i.e. decimal places of the year, although this isn’t generally human readable
(but we live with Lat and Long in this form…)
Sorry for the long post... that's what I get for reading all your contributions in one go!
Joel Haasdyk | GDA2020 Implementation Program Manager (NSW)
--------------------------------------------------------------------------------------------------
Spatial Services | Department of Customer Service
p (02) 87376322 | m 0427 229 589
e Joel.Haasdyk at customerservice.nsw.gov.au
w www.spatial.nsw.gov.au
Level 14 West, McKell Building, 2-24 Rawson Place, Sydney NSW 2000
https://www.icsm.gov.au/gda2020 (FAQs & Forum)
--------------------------------------------------------------------------------------------------
-----Original Message-----
From: PROJ <proj-bounces at lists.osgeo.org> On Behalf Of proj-request at lists.osgeo.org
Sent: Wednesday, 28 August 2019 9:07 AM
To: proj at lists.osgeo.org
Subject: PROJ Digest, Vol 10, Issue 20
Send PROJ mailing list submissions to
proj at lists.osgeo.org
To subscribe or unsubscribe via the World Wide Web, visit
https://clicktime.symantec.com/37hUAv7MQPNaUxxwsjPTNpr7Vc?u=https%3A%2F%2Flists.osgeo.org%2Fmailman%2Flistinfo%2Fproj
or, via email, send a message with subject or body 'help' to
proj-request at lists.osgeo.org
You can reach the person managing the list at
proj-owner at lists.osgeo.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of PROJ digest..."
Today's Topics:
1. Re: Seeking clarification on PROJ support for temporal
transformations (Even Rouault)
2. Re: Seeking clarification on PROJ support for temporal
transformations (Nyall Dawson)
3. Re: Seeking clarification on PROJ support for temporal
transformations (Nyall Dawson)
4. Re: Seeking clarification on PROJ support for temporal
transformations (Nyall Dawson)
5. Re: Seeking clarification on PROJ support for temporal
transformations (Even Rouault)
6. Re: Seeking clarification on PROJ support for temporal
transformations (Cameron Shorter)
----------------------------------------------------------------------
Message: 1
Date: Tue, 27 Aug 2019 23:34:35 +0300
From: Even Rouault <even.rouault at spatialys.com>
To: proj at lists.osgeo.org
Subject: Re: [PROJ] Seeking clarification on PROJ support for temporal
transformations
Message-ID: <4138519.eZhnYTKfua at even-i700>
Content-Type: text/plain; charset="us-ascii"
> WKT2:2018 isn't yet published. Hopefully should come out "soon" from
> ISO / OGC.
OK, I actually see it has now been finally published !
https://clicktime.symantec.com/3JRKQYkqoKCNcPGd1eoi9AL7Vc?u=http%3A%2F%2Fdocs.opengeospatial.org%2Fis%2F18-010r7%2F18-010r7.html
And the ISO19111 spec called on the OGC side as Abstract Topic 2 was already available at https://clicktime.symantec.com/3RHKY1g1VYCn14v29BsQFC97Vc?u=http%3A%2F%2Fdocs.opengeospatial.org%2Fas%2F18-005r4%2F18-005r4.html
--
Spatialys - Geospatial professional services https://clicktime.symantec.com/3LRVJEevh8vqiD9DDeK88QQ7Vc?u=http%3A%2F%2Fwww.spatialys.com
------------------------------
Message: 2
Date: Wed, 28 Aug 2019 06:53:22 +1000
From: Nyall Dawson <nyall.dawson at gmail.com>
To: Kristian Evers <kreve at sdfe.dk>
Cc: Even Rouault <even.rouault at spatialys.com>, PROJ
<proj at lists.osgeo.org>
Subject: Re: [PROJ] Seeking clarification on PROJ support for temporal
transformations
Message-ID:
<CAB28AsiXdNrEoOxZWoEbP5M2PrNRx0yLLNu3CEM0-eKHPQgdDg at mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
On Wed, 28 Aug 2019 at 06:12, Kristian Evers <kreve at sdfe.dk> wrote:
>
> Nyall,
>
> The epoch of a coordinate, e.g. the time it was measured, has nothing to do with the CRS definition.
> But it is important once you want to transform from one CRS to another or propagate the coordinate
> through time in the same CRS. Coordinates in a dataset will not necessarily have the same
> measuring time/epoch, which is why it is not a good idea to store that information alongside the CRS
> description. This is why 4D coordinates are necessary for dynamic CRS's. You need a XYZT geometry,
> as it were.
Right... I've been down this rabbit hole already :) My thoughts:
Realistically, we are years away from having support for per-feature
(or per-node(!)) epochs in geospatial data. This brings with it a
whole raft of complications, including throwing out all existing data
formats and replacing them with new formats which support the extra
dimension, and also huge complexities in the UI/UX for end-user
applications. Then there's the added storage/memory/processing
overhead of handling the extra dimension for every geometry
feature/node.
In the near future we're best off aiming for per-dataset epochs. I.e.
a layer has a single reference epoch which applies to all
features/nodes in that layer. This is practically achievable within
the next couple of years, as (above discussions aside) we'd be able to
store the per-dataset epoch in the WKT2 definition of the layer (or in
some other metadata field, or as a sidecar file). The software would
then need to ensure that any newly added features are correctly
transformed back into the reference epoch for the layer to ensure all
features have the same consistent epoch, but that's relatively
straightforward.
Nyall
>
> There are of course exceptions, for instance a raster image where all pixels are captured simultaneous by the sensor. For that it would be nice to have a way to register the capture time in a standardized way. I am not sure if this is already possible with WKT2:2018.
>
> /Kristian
>
> -----Original Message-----
> From: PROJ <proj-bounces at lists.osgeo.org> On Behalf Of Nyall Dawson
> Sent: 27. august 2019 22:49
> To: Even Rouault <even.rouault at spatialys.com>
> Cc: PROJ <proj at lists.osgeo.org>
> Subject: Re: [PROJ] Seeking clarification on PROJ support for temporal transformations
>
> On Wed, 28 Aug 2019 at 01:26, Even Rouault <even.rouault at spatialys.com> wrote:
> >
> > > But, if I understand correctly, WKT2:2018 would be the ultimate answer
> > > to this, in that it would allow us to specify the epoch of a dataset
> > > as an integral part of the data's CRS definition (which it is).
> >
> > Not sure to understand your "what it is", but pedantically, the epoch of the
> > dataset is not part of the CRS definition. Anyway...
>
> Well -- I think it IS a fundamental part of the definition, of equal
> importance to other parameters such as false easting/northing. Without
> the epoch information the coordinate data becomes meaningless, and
> it's required in order to accurately position them. While it would
> theoretically be possible to store this information somewhere else in
> a dataset's metadata, it's such an integral part of the CRS that
> shoving it right into the CRS definition is the right way forward...
>
> Nyall
>
>
> >
> > --
> > Spatialys - Geospatial professional services
> > https://clicktime.symantec.com/3LRVJEevh8vqiD9DDeK88QQ7Vc?u=http%3A%2F%2Fwww.spatialys.com
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://clicktime.symantec.com/37hUAv7MQPNaUxxwsjPTNpr7Vc?u=https%3A%2F%2Flists.osgeo.org%2Fmailman%2Flistinfo%2Fproj
------------------------------
Message: 3
Date: Wed, 28 Aug 2019 06:56:09 +1000
From: Nyall Dawson <nyall.dawson at gmail.com>
To: Chris Crook <ccrook at linz.govt.nz>
Cc: Kristian Evers <kreve at sdfe.dk>, Even Rouault
<even.rouault at spatialys.com>, PROJ <proj at lists.osgeo.org>
Subject: Re: [PROJ] Seeking clarification on PROJ support for temporal
transformations
Message-ID:
<CAB28Asi0nUxhQquERfi2MZCWMNq9CfMt_w9b7YjFx_7SK4zUrw at mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
On Wed, 28 Aug 2019 at 06:27, Chris Crook <ccrook at linz.govt.nz> wrote:
>
> Nyall
>
> I wonder if the distinction here is that a reference epoch is a parameter of some coordinate transformation functions, such as 14-15 (with ref epoch) Bursa Wolf transformation, rather than a fundamental parameter of the datum. Similarly false easting is a parameter of some projection transformations.
Fair point - but I think Even's follow up regarding storing CRS + a
coordinate epoch (via COORDINATEMETADATA[] WKT2:2018 construct) at a
whole-of-dataset level would address this.
So I guess the EPSG registry (or similar) would include the CRS
definition with its component transformation parameters, and then the
COORDINATEMETADATA element gives the remaining piece of the puzzle
required to use the coordinates...
(This is my new favorite PROJ mailing list thread!)
Nyall
>
> Traditionally we also like to associate reference epochs with datums, which historically were somewhat arbitrary, for example when the datum was calculated or standardised. These days they also tend to be used to as an epoch at which the datum was aligned with a global datum. So in Australia the datum GDA2020 is defined to be aligned with ITRFxxxx (2014?) at 2020. In New Zealand we used to say that a NZGD2000 coordinate was "where an object was in 2000", but that is clearly a nonsense for something that didn't exist in 2000, and in any case it is not even true anymore as we have changed some coordinates following earthquakes, but they are still NZGD2000 coordinates.
>
> Essential point is that some transformation functions use a reference epoch, some don't. The epoch is a parameter of a transformation. As Even also says, the critical thing is that there is an epoch associated with data. Without that many datum transformations become even more ambiguous than they already are!
>
> Cheers
> Chris
>
> -----Original Message-----
> From: PROJ [mailto:proj-bounces at lists.osgeo.org] On Behalf Of Kristian Evers
> Sent: Wednesday, 28 August 2019 8:13 a.m.
> To: Nyall Dawson; Even Rouault
> Cc: PROJ
> Subject: Re: [PROJ] Seeking clarification on PROJ support for temporal transformations
>
> Nyall,
>
> The epoch of a coordinate, e.g. the time it was measured, has nothing to do with the CRS definition.
> But it is important once you want to transform from one CRS to another or propagate the coordinate through time in the same CRS. Coordinates in a dataset will not necessarily have the same measuring time/epoch, which is why it is not a good idea to store that information alongside the CRS description. This is why 4D coordinates are necessary for dynamic CRS's. You need a XYZT geometry, as it were.
>
> There are of course exceptions, for instance a raster image where all pixels are captured simultaneous by the sensor. For that it would be nice to have a way to register the capture time in a standardized way. I am not sure if this is already possible with WKT2:2018.
>
> /Kristian
>
> -----Original Message-----
> From: PROJ <proj-bounces at lists.osgeo.org> On Behalf Of Nyall Dawson
> Sent: 27. august 2019 22:49
> To: Even Rouault <even.rouault at spatialys.com>
> Cc: PROJ <proj at lists.osgeo.org>
> Subject: Re: [PROJ] Seeking clarification on PROJ support for temporal transformations
>
> On Wed, 28 Aug 2019 at 01:26, Even Rouault <even.rouault at spatialys.com> wrote:
> >
> > > But, if I understand correctly, WKT2:2018 would be the ultimate
> > > answer to this, in that it would allow us to specify the epoch of a
> > > dataset as an integral part of the data's CRS definition (which it is).
> >
> > Not sure to understand your "what it is", but pedantically, the epoch
> > of the dataset is not part of the CRS definition. Anyway...
>
> Well -- I think it IS a fundamental part of the definition, of equal importance to other parameters such as false easting/northing. Without the epoch information the coordinate data becomes meaningless, and it's required in order to accurately position them. While it would theoretically be possible to store this information somewhere else in a dataset's metadata, it's such an integral part of the CRS that shoving it right into the CRS definition is the right way forward...
>
> Nyall
>
>
> >
> > --
> > Spatialys - Geospatial professional services https://clicktime.symantec.com/3LRVJEevh8vqiD9DDeK88QQ7Vc?u=http%3A%2F%2Fwww.spatialys.com
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://clicktime.symantec.com/37hUAv7MQPNaUxxwsjPTNpr7Vc?u=https%3A%2F%2Flists.osgeo.org%2Fmailman%2Flistinfo%2Fproj
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://clicktime.symantec.com/37hUAv7MQPNaUxxwsjPTNpr7Vc?u=https%3A%2F%2Flists.osgeo.org%2Fmailman%2Flistinfo%2Fproj
>
> ________________________________
>
> This message contains information, which may be in confidence and may be subject to legal privilege. If you are not the intended recipient, you must not peruse, use, disseminate, distribute or copy this message. If you have received this message in error, please notify us immediately (Phone 0800 665 463 or info at linz.govt.nz) and destroy the original message. LINZ accepts no responsibility for changes to this email, or for any attachments, after its transmission from LINZ. Thank You.
------------------------------
Message: 4
Date: Wed, 28 Aug 2019 07:25:37 +1000
From: Nyall Dawson <nyall.dawson at gmail.com>
To: Even Rouault <even.rouault at spatialys.com>
Cc: PROJ <proj at lists.osgeo.org>
Subject: Re: [PROJ] Seeking clarification on PROJ support for temporal
transformations
Message-ID:
<CAB28AsinJ5yAjW9bXy9wc2h91i74zAXf07BefBQuLCdrpF3q=A at mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
On Wed, 28 Aug 2019 at 01:26, Even Rouault <even.rouault at spatialys.com> wrote:
> > But, if I understand correctly, WKT2:2018 would be the ultimate answer
> > to this, in that it would allow us to specify the epoch of a dataset
> > as an integral part of the data's CRS definition (which it is).
>
> Not sure to understand your "what it is", but pedantically, the epoch of the
> dataset is not part of the CRS definition. Anyway...
I concede this point -- the specs clearly are in your favour:
16.1: "Coordinate epoch is not part of a CRS definition, it is
additional metadata for the coordinates which is required to ensure
that they are unambiguous when referenced to a dynamic CRS."
Nyall
>
> --
> Spatialys - Geospatial professional services
> https://clicktime.symantec.com/3LRVJEevh8vqiD9DDeK88QQ7Vc?u=http%3A%2F%2Fwww.spatialys.com
------------------------------
Message: 5
Date: Wed, 28 Aug 2019 00:50:14 +0300
From: Even Rouault <even.rouault at spatialys.com>
To: Kristian Evers <kreve at sdfe.dk>
Cc: Nyall Dawson <nyall.dawson at gmail.com>, PROJ <proj at lists.osgeo.org>
Subject: Re: [PROJ] Seeking clarification on PROJ support for temporal
transformations
Message-ID: <2096164.pDk9JYgsY7 at even-i700>
Content-Type: text/plain; charset="us-ascii"
>
> A global plate motion model is part of ITRF2014 [0]. It comes in the form of
>
Euler pole rotation parameters. They can be used in a time-dependent
> Helmert Transformation. Some time ago I included all the parameters in the
> ITRF2014 init file [1]. I use them to transform data from ITRF2014 to the
> local Greenlandic frame GR96 (effectively ITRF94 at 1996.623). I've defined a
> pipeline like this:
> proj = pipeline ellps = GRS80
> step inv init = ITRF2014:ITRF94 t_obs = 1996.623
> step inv init = ITRF2014:NOAM t_epoch=1996.623
>
That's interesting !
I believe there's a small mistake in the ITRF2014 file (or the IGN page might
have been updated in the meantime) for the ITRF2014:ITRF94 entry. It lacks a
+drz=0.00002 (the ITRF96 entry as well). I can see it in https://clicktime.symantec.com/3DYnpibATcWTafjkYa66Zbh7Vc?u=http%3A%2F%2Fitrf.ign.fr%2F
doc_ITRF/Transfo-ITRF2014_ITRFs.txt and it is also there in the EPSG dataset:
$ projinfo -s ITRF2014 -t ITRF94 -o PROJ -q
+proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert
+xy_in=deg +xy_out=rad +step +proj=cart +ellps=GRS80 +step +inv +proj=helmert
+x=-0.0074 +y=0.0005 +z=0.0628 +rx=0 +ry=0 +rz=-0.00026 +s=-0.0038 +dx=-0.0001
+dy=0.0005 +dz=0.0033 +drx=0 +dry=0 +drz=-2e-05 +ds=-0.00012 +t_epoch=2010
+convention=position_vector +step +inv +proj=cart +ellps=GRS80 +step
+proj=unitconvert +xy_in=rad +xy_out=deg +step +proj=axisswap +order=2,1
(the signs are different due to EPSG having ITRF94 to ITRF2014 natively, and
thus PROJ applying a +inv)
Another detail: the pipeline you mention above is from GR96 to ITRF2014, right
(due to the 'inv' of ITRF2014:ITRF94) ?
And the last step which I assume is for the northamerica plate motion doesn't
seem to have any effect as you forced t_obs in the previous step to the
t_epoch of that step, so the time difference is 0.
$ echo " 2768773.7909 -1598552.2935 5500477.1338" | src/cct +proj=pipeline
+ellps=GRS80 +step +inv +init=ITRF2014:ITRF94 +t_obs=1996.623
2768773.7710 -1598552.2904 5500477.1757
$ echo " 2768773.7909 -1598552.2935 5500477.1338" | src/cct +proj=pipeline
+ellps=GRS80 +step +inv +init=ITRF2014:ITRF94 +t_obs=1996.623 +step +inv
+init=ITRF2014:NOAM +t_epoch=1996.623
2768773.7710 -1598552.2904 5500477.1757
Even
--
Spatialys - Geospatial professional services
https://clicktime.symantec.com/3LRVJEevh8vqiD9DDeK88QQ7Vc?u=http%3A%2F%2Fwww.spatialys.com
------------------------------
Message: 6
Date: Wed, 28 Aug 2019 09:07:00 +1000
From: Cameron Shorter <cameron.shorter at gmail.com>
To: proj at lists.osgeo.org
Cc: Joel Haasdyk <Joel.Haasdyk at finance.nsw.gov.au>
Subject: Re: [PROJ] Seeking clarification on PROJ support for temporal
transformations
Message-ID: <bfac6548-d291-8e76-babc-b68f10278d99 at gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
I'm interested in this thread because Joel Haasdyk (from NSW Spatial
Services) will be presenting at the OGC Technical Committee in a few
weeks on the topics of Australia's experience and pain that we are
facing with time-dependent datums, misaligned maps in web mapping, need
to update OGC standards, and a bit more.
I'm helping Joel collate the list of challenges and potential solutions,
and this thread is a topic which should be on the list.
In particular, I want to question the technical implementability of
storing observation time with every single coordinate. While this is an
option for a few high precision use cases, I'd argue that the vast
majority of use cases would want to store datasets in a globally
recognised fixed epoch to facilitate interoperability.
So a dataset could store:
* Coordinates of all features, stored at a fixed epoch
* Observation date
* Point Motion Operation (PCO) used to move to fixed epoch. (PCO is new
term for transformation between epochs). This PCO hopefully can be
applied in reverse to get back to the original observation date.
So what should I capture about feasibility of implementation, and
whether it addresses real world use cases.
The last draft of the paper I'm pulling together is here:
https://clicktime.symantec.com/3TXKQycNfbKob6ERPJq5kdE7Vc?u=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F15uBX2qICODRkiHXeksT0zEy6TuysanIxuc4anV0o5F0%2Fedit%3Fusp%3Ddrive_web%26ouid%3D110542442124937335472
I'm planning to put out another version at the end of the week.
Cheers, Cameron
On 28/8/19 7:25 am, Nyall Dawson wrote:
> On Wed, 28 Aug 2019 at 01:26, Even Rouault <even.rouault at spatialys.com> wrote:
>>> But, if I understand correctly, WKT2:2018 would be the ultimate answer
>>> to this, in that it would allow us to specify the epoch of a dataset
>>> as an integral part of the data's CRS definition (which it is).
>> Not sure to understand your "what it is", but pedantically, the epoch of the
>> dataset is not part of the CRS definition. Anyway...
> I concede this point -- the specs clearly are in your favour:
>
> 16.1: "Coordinate epoch is not part of a CRS definition, it is
> additional metadata for the coordinates which is required to ensure
> that they are unambiguous when referenced to a dynamic CRS."
>
> Nyall
>
On 28/8/19 6:53 am, Nyall Dawson wrote:
> Right... I've been down this rabbit hole already:) My thoughts:
>
> Realistically, we are years away from having support for per-feature
> (or per-node(!)) epochs in geospatial data. This brings with it a
> whole raft of complications, including throwing out all existing data
> formats and replacing them with new formats which support the extra
> dimension, and also huge complexities in the UI/UX for end-user
> applications. Then there's the added storage/memory/processing
> overhead of handling the extra dimension for every geometry
> feature/node.
>
> In the near future we're best off aiming for per-dataset epochs. I.e.
> a layer has a single reference epoch which applies to all
> features/nodes in that layer. This is practically achievable within
> the next couple of years, as (above discussions aside) we'd be able to
> store the per-dataset epoch in the WKT2 definition of the layer (or in
> some other metadata field, or as a sidecar file). The software would
> then need to ensure that any newly added features are correctly
> transformed back into the reference epoch for the layer to ensure all
> features have the same consistent epoch, but that's relatively
> straightforward.
>
> Nyall
>
--
Cameron Shorter
Technology Demystifier
Open Technologies and Geospatial Consultant
M +61 (0) 419 142 254
------------------------------
Subject: Digest Footer
_______________________________________________
PROJ mailing list
PROJ at lists.osgeo.org
https://clicktime.symantec.com/37hUAv7MQPNaUxxwsjPTNpr7Vc?u=https%3A%2F%2Flists.osgeo.org%2Fmailman%2Flistinfo%2Fproj
------------------------------
End of PROJ Digest, Vol 10, Issue 20
************************************
**********************************************************************************
This email message and any attached files is confidential and intended solely for the use of the individual or entity to whom it is addressed and may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you have received this email in error, delete all copies and notify the sender.
This email is subject to copyright. No part of it should be reproduced, published, communicated or adapted without the copyright owner's written consent. No employee or agent is authorised to conclude any binding agreement on behalf of the Department of Customer Service (DCS) by email without express written confirmation.
The views or opinions presented in this email are solely those of the author and do not necessarily represent those of the DCS. DCS accepts no liability for any loss or damage arising from the use of this email and the recipient should check this email and any attached files for the presence of viruses.
**********************************************************************************
More information about the PROJ
mailing list