search

Maps4HTML / MapML-Specification

Map Markup Language is hypertext for Web maps, like HTML is hypertext for Web pages https://maps4html.org/MapML-Specification/spec/
Other
55 stars 12 forks source link

Change request into WGS84 and tcrs. #23

Closed joanma747 closed 5 years ago

joanma747 commented 6 years ago

The issue emerged while discussing if WGS84 is a Coordinate system or projection system?

The answer is: you can use a projection that is identical to the world directly represented as long/lat: Plate Carrée that is an special case of Equidistant Cylindrical projection with fi0=0 https://proj4.org/operations/projections/eqc.html

In Plate Carrée, pixel size and long/lat differ only by an scale factor that depends on the zoom level. It reads directly long/lat as you can see by the Mathematical Definition.

This is what we need to do to make WGS84 a good TileMAtrixSet (called TCRS in MapML):

I request to change the TCRS "description" of "WGS84" Before: "World Geodetic System 1984." Proposed: "Plate Carrée projection in WGS84 datum."

I also suggest to change the TCRS "Base CRS / Projection system" of "WGS84" Before: EPSG::4326 Proposed: "CRS:84"

I also suggest to change the TCRS "Resolution" of "WGS84" Before: n/a Proposed (from: http://www.opengeospatial.org/standards/requests/169 Table D.3) 0.703125000000000 0.351562500000000 0.175781250000000 8.78906250000000 10-2 4.39453125000000 10-2 2.19726562500000 10-2 1.09863281250000 10-2 5.49316406250000 10-3 2.74658203125000 10-3 1.37329101562500 10-3 6.86645507812500 10-4 3.43322753906250 10-4 1.71661376953125 10-4 8.58306884765625 10-5 4.29153442382812 10-5 2.14576721191406 10-5 1.07288360595703 10-5 5.36441802978516 10-6

This way (as said in D.3) this one becomes compatible with INSPIRE SDI in Europe.

In addition, please also change the input@units values table with: Before: "tcrs | The location should be serialized in units associated to the TCRS instance, i.e. pixels or in the case of WGS84, decimal degrees" requested: "tcrs | The location should be serialized in units associated to the TCRS instance, i.e. pixels with the origin at the upper left corner of the tiled space, with coordinate axes' increasing right and downwards, respectively."

Before: gcrs | The location should be serialized in units associated to the geodetic coordinate system associated to the TCRS instance, e.g. decimal degrees for the OSMTILE TCRS, which has an underlying geodetic coordinate reference system of EPSG:4326. In the case of a TCRS such as WGS84, the gcrs and tcrs location are the same. requested: gcrs | The location should be serialized in units associated to the geodetic coordinate system associated to the TCRS instance, e.g. decimal degrees for the OSMTILE TCRS, which has an underlying geodetic coordinate reference system of EPSG:4326. In the case of a TCRS such as WGS84, the gcrs and pcrs location are the same. (note the change of the "t" by a "p" in "tcrs".

In addition, I propose to add the geodetic system (datum) to all other TCRS descriptions for clarity.

prushforth commented 6 years ago

I request to change the TCRS "description" of "WGS84" Before: "World Geodetic System 1984." Proposed: "Plate Carrée projection in WGS84 datum."

I counter-propose to add Plate Carrée as a TCRS identifier separate from WGS84.

I also suggest to change the TCRS "Base CRS / Projection system" of "WGS84" Before: EPSG::4326 Proposed: "CRS:84"

I considered this but I considered that a) the definitions of all the other base CRS' are available from EPSG and b) the only value that CRS:84 adds is the axis order, which that table makes explicit already, so I went with the EPSG code. At the same time CRS:84 is an obscure reference for those not in the OGC loop, I believe. Correct me if any of the above is flawed.

In addition, please also change the input@units values table with: Before: "tcrs | The location should be serialized in units associated to the TCRS instance, i.e. pixels or in the case of WGS84, decimal degrees" requested: "tcrs | The location should be serialized in units associated to the TCRS instance, i.e. pixels with the origin at the upper left corner of the tiled space, with coordinate axes' increasing right and downwards, respectively."

See the proposed addition, in which case the Before: still applies.

Before: gcrs | The location should be serialized in units associated to the geodetic coordinate system associated to the TCRS instance, e.g. decimal degrees for the OSMTILE TCRS, which has an underlying geodetic coordinate reference system of EPSG:4326. In the case of a TCRS such as WGS84, the gcrs and tcrs location are the same. requested: gcrs | The location should be serialized in units associated to the geodetic coordinate system associated to the TCRS instance, e.g. decimal degrees for the OSMTILE TCRS, which has an underlying geodetic coordinate reference system of EPSG:4326. In the case of a TCRS such as WGS84, the gcrs and pcrs location are the same. (note the change of the "t" by a "p" in "tcrs".

I would want to amend that to:

In the case of a TCRS such as WGS84, the tcrs, gcrs and pcrs location are the same.

joanma747 commented 6 years ago

I counter-propose to add Plate Carrée as a TCRS identifier separate from WGS84. Adding Plate Carrée heps a lot in clearing up the confusion and make progress towards harmonize MapML with WMS.

Thanks for that.

IMHO keeping WGS84 in the table will not clear the confusion completely.

Let me try to analyze the issue. I believe the confusion appears because in the text "tcrs" is used in two different meaning. TCRS is the whole concept of tiled spaces (the so called Tile Matrix Set in WMTS) (the big table in MapML spec) and it is also a possible value in coordinate reference in input@units (a reference for coordinates).

Here we are talking about a tcrs as a coordinate reference. You simple cannot have a coordinate reference that has one meaning in Web Mercator, Arctic,,... and another in WGS84. It is too confusing.

If you want to talk about WGS84 in long/lat you simply use gcrs coordinates in tiled spaced based on WGS84 datum, and problem solved!. Plate Carrée or any other could be the selected one for this (in extent).

CRS:84 is an obscure reference for those not in the OGC loop,

I disagree. CRS:84 is used as the only possible value for GeoJSON. If we admit that GeoJSON is a popular format in the web, then CRS:84 is also a popular CRS.

From: https://tools.ietf.org/html/rfc7946.html

The coordinate reference system for all GeoJSON coordinates is a geographic coordinate reference system, using the World Geodetic System 1984 (WGS 84) [WGS84] datum, with longitude and latitude units of decimal degrees. This is equivalent to the coordinate reference system identified by the Open Geospatial Consortium (OGC) URN urn:ogc:def:crs:OGC::CRS84. An OPTIONAL third-position element SHALL be the height in meters above or below the WGS 84 reference ellipsoid. In the absence of elevation values, applications sensitive to height or depth SHOULD interpret positions as being at local ground or sea level.

prushforth commented 6 years ago

I believe the confusion appears because in the text "tcrs" is used in two different meaning. TCRS is the whole concept of tiled spaces (the so called Tile Matrix Set in WMTS) (the big table in MapML spec) and it is also a possible value in coordinate reference in input@units (a reference for coordinates).

I agree. I changed the name of that table from "Projections" to TCRS, because of OGC objection to the use of the word "projection". Because the table is heterogeneous, containing some instances of TCRS but also including WGS84 (the name of which, I won't say I made it up, is just a common way of referring to the GCRS).

Here we are talking about a tcrs as a coordinate reference. You simple cannot have a coordinate reference that has one meaning in Web Mercator, Arctic,,... and another in WGS84. It is too confusing.

That's the heterogeneity that I was trying to encapsulate with the word "projection". While technically not correct, neither is tiled coordinate reference system (TCRS). TCRS is a neologism coined for MapML. Although zoom levels might not strictly apply to WGS84 coordinates, it only makes sense for a server to take into account the zoom level at which the features encoded in WGS84 will be consumed. Hence the inclusion of WGS84 in the table of TCRS. I the future would like to recommend an actual coordinate resolution for each zoom level that is based on best practices, but I have never done a full analysis so it is at this point impossible to provide such resolutions.

We had this discussion in email on July 30th of this year and I asked for suggestions for a name for the domain of things that included the TCRS and WGS84; I didn't get a response. I still think "projection" works as well as anything, especially since the string values "OSMTILE", "CBMTILE", "APSTILE", "WGS84" are instances in the domain of whatever that concept is.

If we admit that GeoJSON is a popular format in the web, then CRS:84 is also a popular CRS. From: https://tools.ietf.org/html/rfc7946.html

OK, fair point. I can live with the ('normative') reference to CRS84 in the table, but I prefer WGS84 as the name of the MapML coordinate system.

If you want to talk about WGS84 in long/lat you simply use gcrs coordinates in tiled spaced based on WGS84 datum, and problem solved!. Plate Carrée or any other could be the selected one for this (in extent).

Let's talk more about this last point on Monday. I think I see where you want to go and it might work out. Let's discuss.