map projections

[michaelchin]

The gplates app will not reconstruct data on the fly. So, the time increment really depends on the pre-prepared time-dependent rasters.

I'm assuming this also applies to vector data (ie, not just raster data). As in the points in the vector data are reconstructed on the server and then those post-reconstructed locations sent across the network. I assume the GPlates app is basically going to be streaming pre-processed data from the server (whether that's vector or raster or any data really).

And I just checked Cesiumjs doc, it seems they still only have three view modes -- 3D globe, 2D orthographic projection and 2.5D columbus view. If we really need other projections, one way is to display it as a static map image, it would not be nice if users try to zoom in. The other way is to use d3js https://github.com/d3/d3-geo-projection/ or other libraries. It requires much more dev efforts. I don't think it is practical for our project.

I agree that you wouldn't want a static map image, and that map projections can be added in the future sometime. I'll just mention a couple of thoughts on map projections (for the future):

1. GPlates only has a handful of map projections (four), and hasn't increased that number for a long time, so one option is to have pre-map-projected versions of your vector datasets. These could be stored on the server. However the dataset storage gets multiplied by five (one for 3D globe and four for map projections; although maybe that's four if 3D globe and Rectangular projections both use lat-lon coordinates).
2. ...alternatively can map-project the data just before sending it. For example, the app requests a Mollweide projection of coastlines at 100Ma, so server accesses its internal present day coastlines, reconstructs them to 100Ma, map projects to Mollweide and sends the map-project points across the network. Saves on server dataset storage at the cost of a slight delay due to map projection (in addition to the reconstruction).
3. There's the issue of dateline wrapping (where polylines/polygons intersect the dateline and have to be wrapped onto the lat-lon projection). I don't know if/how the d3js library deals with that. But in any case if the map projections were done on the server you could use the dateline wrapping in pyGPlates and send the post-dateline-wrapped points across the network (perhaps also tessellated where needed - pyGPlates has an option for that - to follow curved map boundary, eg, Mollweide; although tessellation on the server is a disadvantage in terms of network bandwidth, so something local like d3js has an advantage there).
4. If there's too many points sent across the network you could run a simplifying pass over the un-reconstructed vector datasets as a pre-process before storing on the server. Some datasets are probably unnecessarily dense for a phone display. Unless you zoom in greatly, in which case could ultimately have different levels-of-detail (LODs) of each vector dataset. In other words, use simplified LOD when zoomed out (but send all the data on the globe, because it's all visible) and use original high detail dataset when zoomed in (but only send the data that's visible) - so in either case the amount of streamed data is limited (in a similar manner to using LOD raster tiles for raster data). The amount of vector data stored on the server is probably about 30% more (the simplified datasets are smaller than the original high resolution dataset). Of course this LOD would complicate things. So it's more of a future-looking thing if the GPlates app is going to be based around streaming pre-processed data from the server while minimizing delays due to network bandwidth.

Originally posted by @jcannon-gplates in https://github.com/GPlates/gplates-app/issues/8#issuecomment-1120657682

[michaelchin]

John's further comment on the map projects https://github.com/GPlates/gplates-app/issues/8#issuecomment-1120672384

[michaelchin]

Another John's comment https://github.com/GPlates/gplates-app/issues/8#issuecomment-1121961768

[michaelchin]

The map projection issue was brought up by @jcannon-gplates in issue #8 initially. Issue #8 is getting too big to manage. Create a new Issue to discuss map projection.