[PROJ] Static/Dynamic Webmapping Problem version 2.0

Even Rouault even.rouault at spatialys.com
Wed Jul 17 12:05:16 PDT 2019


> Thanks - that's certainly a lot faster than my ground is moving.  Trying
> to ground this in acceptable accuracies and fitness for use of data, it
> feels like 5 years of fuzz is not a big deal (35cm) for anything called
> "web mapping", as opposed to "GNSS vectors used for geodetic surveying".

That's questionable. There are a lot of people doing webmapping with aerial 
photographies with < 10cm resolution ...

> Perhaps a bit strong on my end, but I was thinking about the
> Openstreetmap database, which has always had the notion of "coordinates
> of objects are in WGS84".  That seemed like a good choice in 2004, and
> my ipmression is that successive realizations of WGS84 are ever closer
> to the successive ITRFxx realizations.  Also that the differences in
> successive realizations are reasonably small compared to the accuracy
> achievable with non-differential GPS.  So were I to try to put accurate
> (cm level) coordinates in the OSM database for a point, I'd be trying to
> use the most recent WGS84 realization expecting to to more or less be
> equal to a recent ITRF.  Looking this up, it seems WGS84(G1762) is more
> or less ITRF2008 epoch 2005.0.

The issue with OSM is more than you don't have the coordinate epoch specified. 
You could use the creation timestampof the object as a hint, but the time 
where the object is entered in the database isn't necessary the epoch at which 
the coordinate was collected (for example, if you import from another 
database, like a cadastre, which was built a few years before)

> 
> Trying to get back to point for proj, then, I guess the question is what
> operations do people need to do are missing or awkward.  One thing I
> wonder about based on your metadata comments and my reaction is the
> notion of
> 
>   T=createtransform(src_datum, src_epoch, dst_datum, dst_epoch)
>   apply_transform(T, vector_of_points[lat, lon, ellipsoidal_height])
> 
> versus the notion that the point object (rather than the transform) has
> an epoch, to end up with something that feels like
> 
>   T=createtransform(src_datum, dst_datum, dst_epoch)
>   apply_transform(T, vector_of_points[lat, lon, ellipsoidal_height, epoch])
> 
> Probably that's too messy to contemplate for now, without a clear enough
> need.

We discussed about that in:

https://lists.osgeo.org/pipermail/proj/2019-June/008668.html
https://lists.osgeo.org/pipermail/proj/2019-June/008669.html
https://lists.osgeo.org/pipermail/proj/2019-June/008670.html

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com


More information about the PROJ mailing list