Best Practice 7 - discussion of projections

[PeterParslow]

We correctly say

"Spatial data is often projected from the curved surface of the Earth onto a flat plane (e.g. a computer screen or a topographical map) to make it easier to compute distances between positions and calculate areas."

Is it worth also acknowledging that some coordinate reference systems project the earth-based position onto a spherical surface? At least, that's the way I understand "pseudo-Mercator" (EPSG::3857) - although perhaps its projected via a mathematical spherical surface before being displayed on the flat (or curved!) screen of most web browsing devices!

Something similar is in the second NOTE of the Possible Approach to Implementation, suggesting that it's the datum that is spherical. Perhaps that's also a reflection of IOGP's "Uses spherical development of ellipsoidal coordinates."

[PeterParslow]

I would challenge the statement under Possible Approach to Implementation that

"Where you have geo-imagery (i.e. raster data, comprised of a rectangular pattern of pixels on a flat plane) it is best to use Web Mercator (EPSG:3857) which has global coverage"

Given that "Relative to WGS 84 / World Mercator (CRS code 3395) gives errors of 0.7 percent in scale and differences in northing of up to 43km in the map (21km on the ground)." (quote from https://epsg.org/crs_3857/WGS-84-Pseudo-Mercator.html) - whether that's an acceptable difference/error depends on the application, not the fact its raster imagery.

[PeterParslow]

Slightly off the topic, but still on this Best Practice. Should we also make more mention of WGS 84 Long/Lat (OGC CRS84) as that is the only CRS recommended for GeoJSON and the default CRS for GeoSPARQL, so is increasingly popular (however much that might infuriate old mariners & pilots :) ).

Oddly, roughly that is stated in the first note to BP8, "the clear majority of spatial data published on the Web uses WGS 84 Long/Lat (as used by GPS)" - although true, at least the long & lat are clearly flagged in the raw GPS NMEA data (although somewhat obscured because the switch from degrees to minutes is defined by the format, not a separator!):

$GPGGA,235317.000,4003.9039,N,10512.5793,W

40° 3.939' N

It is also mentioned again (by example) in EXAMPLE 27 of BP8, as an example of specifying the CRS in the format specification (standard)

[FransKnibbe]

Slightly off the topic, but still on this Best Practice. Should we also make more mention of WGS 84 Long/Lat (OGC CRS84) as that is the only CRS recommended for GeoJSON and the default CRS for GeoSPARQL, so is increasingly popular (however much that might infuriate old mariners & pilots :) ).

There is a difference between popular practice and best practice. Yes, CRS84 is a popular CRS, but recommending it is something else. On the contrary, it could be advisable not to use CRS84 outside of North America (I think both GeoJSON and GeoSPARQL were short-sighted in this respect). The standard CRS for geographical data in Europe is ETRS89.

[PeterParslow]

I agree with not recommending - but for different reasons (to do with tectonic drift). But we do discuss it in BP8, so it would seem reasonable to mention it in BP7

[situx]

@PeterParslow Would this be something you could bring in the shape of a pull request? Then we could better discuss it, seeing exactly what you would like to change

[PeterParslow]

I tried, @situx , but it seems to have resulted in a branch (related above) with my pull request against that branch - and that branch would need to be merged into the main one....