[PROJ] Static/Dynamic Webmapping Problem version 2.0

[Cameron Shorter]

Hi Greg,

I can see that you have put quite a bit of effort into thinking about 
the questions below. Could I ask for another 15 mins of your time to 
read the 8 page position paper? I think half your questions are answered 
in the doc.

You are asking understandably questions which I feel is really 
important, and I hope you can help with that. Please login before adding 
comments so we know who said what. Comments are welcome, but please 
don't use track changes in the text (as the doc becomes hard to read).

https://docs.google.com/document/d/15uBX2qICODRkiHXeksT0zEy6TuysanIxuc4anV0o5F0/edit#

Cheers, Cameron

On 17/7/19 12:22 am, Greg Troxel wrote:
> Cameron Shorter <cameron.shorter at gmail.com> writes:
>
>> Thanks for feedback so far. I'm aggregating answers into one email,
>> and copying your comments into the master working doc here:
>> https://docs.google.com/document/d/15uBX2qICODRkiHXeksT0zEy6TuysanIxuc4anV0o5F0/edit#
>>
>> On 15/7/19 9:58 pm, Greg Troxel wrote:
>>> It might also help to have your notes in plain text and actually send
>>> them to the list, after editing for minimum length
>> Greg, you are asking good questions, but it would be bad manners for
>> me dump my long, half baked paper onto this list. Instead I'll copy
>> the introduction, and hopefully you might be tempted to read the
>> details in doc reference above:
> I would suggest that you first write something that presumes the
> appropriate background and is as short as possible.  Explaining it to
> people who don't understand surveuying/geodesy is much harder of course.
>
>> Increasing demands for location accuracy has exposed design flaws in
>> current “good-enough” approaches to web-mapping. Prior implementations
>> haven’t accounted for tectonic plate shifts, resulting in systematic
>> metre-level inaccuracies which are increasing over time.
> This is not about web mapping.  I think you are conflating issues with
> fuzzy or old datum use with web presentation.
>
>
>> The problem we’ve inherited is that a dynamicdatum is being used as if
>> it were static. (Think of a datum as a mathematical model and
>> associated coordinate system for the earth.)
> So this is a clue that you are writing for a different audience than I
> suggest.  I realize that may be your end goal, but I think you should
> have the professional audience crisp version peer reviewed first.
>
>>     Web-mapping applications use pre-rendered map tiles to improve
>>     performance and scalability. This freezes map tiles at a point in time.
> Yes, but typically the underlying databases are updated and tiles are
> rebuilt.  In openstreetmap my impression is that tiles rarely get to be
> 30 days old.
>
> Are you really talking about station velocities that are so large that a
> tile from even a year ago has a big enough shift to be perceptible at
> z19?  z20?  I have not done the math, but this seems hard to believe.
>
> At z19 (mid latitude) on a normal computer, it seems that 20m is about
> 100 pixels (very roughly).  So that's 20 cm/pixel.  How far apart do
> epochs needto be for trouble?  (Note that I'm assuming all the data has
> been transformed into the same datum.)
>
>>   To facilitate interoperability, implementers have selected a
>>     defacto-standard map projection of WGS84 Web Mercatorwhich is
>>     <https://www.epsg-registry.org/report.htm?type=selection&entity=urn:ogc:def:crs:EPSG::3857&reportDetail=short&style=urn:uuid:report-style:default-with-code&style_name=OGP%20Default%20With%20Code&title=EPSG:3857>based
>>     on the WGS84 datum.
> Yes, but the notion of which WGS84 has been fuzzy, because it has not
> been that important.   It seems obvious as new WGS84 realizations happen
> over time that the database/projection should be interpreted as the
> recent one, for people that care about meter-level accuracy.
>
>>     However the WGS84 datum is dynamic (time dependant),meaning that a
>>     feature’s coordinates change over time as the tectonic plates drift
>>     across the earth.
> This would be a really good place to insert the velocity of typical
> stations in your country in the latest WGS84 realization.  Or perhaps
> the 90th percentile of velocity.   Are you talking 1 cm/year, or is it
> much higher?
>
>>     This results in misaligned map layers.
> "misaligned" is an odd word, because I'm not sure what is misaligned to
> what.  If you mean multiple map layers, because one  is epoch 2010.0 and
> one ecpoh 2014.0, then I can see the point.  But again, what are the
> velocities, and what is the resulting position error?   How does that
> compare to the uncertainties in the positions in the first place?
>
>>     Adopting a static datum for web mapping, probably using the WGS84
>>     realisations currently in use.
> If you mean, "for web mapping, specify that we use some recent flavor of
> WGS84 (or ITRFXxx?), and some epoch", I can see the point, but who is it
> you want to adopt?   And, how is that epoch going to be chosen, and when
> will it be updated?
>
>
>
> Please note that I'm not saying that epochs can be ignored always.  In
> the glorious future, the type used for positions will have velocities
> and an epoch.  But I am having a hard time seeing this as a web mapping
> problem now.

-- 
Cameron Shorter
Technology Demystifier
Open Technologies and Geospatial Consultant

M +61 (0) 419 142 254