search

opengeospatial / ogcapi-maps

OGC API - Map draft specification
https://ogcapi.ogc.org/maps
Other
53 stars 16 forks source link

Ability to specify Projection Center #92

Closed jerstlouis closed 1 year ago

jerstlouis commented 2 years ago

In projections like stereographic (of which Arctic Polar Stereographic and Antarctic Polar Sterographic are examples with specific projection centers), it is desirable to use a projection center close to the view center.

There currently is no mechanism to specify such a variable projection center other than by providing a full projection definition (which might not be supported by Part 1: Core -- only by URI / reference).

A challenge is that the resulting CRS would not have a URI to return (in CRS response header), since the projection center of the original CRS was overridden. On one hand this introduces complexity, on the other it can result in a maps more appropriate for the selected area, especially in projections like a stereographic projection.

jerstlouis commented 1 year ago

A related parameter would be the projection orientation.

e.g., a stereographic projection would allow you to specify a projection center and an orientation.

jerstlouis commented 1 year ago

Examples of projections where a particular projection center include Oblique Stereographic (EPSG:9809), Lambert Azimuthal Equal Area (EPSG:9820), Orthographic (EPSG:9840). An orientation could be specified as well.

How could an API support these conveniently? I don't see these EPSG codes in http://www.opengis.net/def/crs/EPSG/0, so I imagine it is because they are not CRS per se, but projections.

Would we need a projections OGC registry as well? There are definitions for ellipsoids, datums, and coordinate systems, but I cannot find these projections EPSG code on the definition server.

Then we could have a map request like:

   .../map?
      projection=[epsg-projection:9840]&
      projection-center=Lat(40),Lon(-120)&
      orientation=40

NOTE: I included -projection because we said for CURIEs that if -{objectType} is missing, the default object type is crs. It would be nice if we can do without it...

@desruisseaux Your CRS expertise would be most welcome here. Any thoughts on this approach?

If I understand correctly, ISO 19111 conceptually does support defining CRS hierarchy with a base projection, for which a center and orientation could then be specified separately.

I imagine this is essentially defining a custom CRS in an ad-hoc manner. The Content-Crs: response header could perhaps then be a CRS JSON/PROJJSON object in this case?

I believe this is an important use case for OGC API - Maps, which is moving away from dynamic maps to focus more on static maps and print cartography. On the other hand, I wouldn't expect this functionality to be used together with Map Tiles. Instead dynamic maps can use geographic data with variable width TMS and re-project / re-orient on the fly in the client.

As for the subset/bbox-crs, probably we do not need to extend this functionality to those. Subsetting with a custom projection center/orientation would likely typically be done simply by setting the scale-denominator, width and height, and optionally center if it should be different from the projection center.

We will also need a projections property in the origin (landing page or collection) to list available projections. This could all be defined in a Custom projection and orientation conformance class (projections property; projection, projection-center and orientation query parameters; and how to deal with the Content-Crs: response i.e., returning a CRS JSON/PROJJSON object). We could also include a few other common projection parameters (e.g., projection-ellipsoid, projection-false-easting, projection-false-northing). A note could explain the projection center latitude is the latitude of true scale for cylindrical projections like Mercator.

@joanma747 This is our very last issue that needs thoughts / discussions :) It would be nice to have gone through them all before the sprint, where tons of new ones will magically appear :) It would make for an interesting discussion topic at the sprint as well.

jerstlouis commented 1 year ago

@ghobona @rob-metalinkage Do we have a registry of projections in the definition server (e.g., EPSG:9840)? Thanks.

EDIT: We do, they are called operation methods and it is at http://www.opengis.net/def/method/ .

desruisseaux commented 1 year ago

OGC Web Map Service (WMS) §6.7.3.4 defines CRS in "AUTO2" namespace as a syntax of the form "AUTO2: projection, factor, longitude, latitude". Projection codes defined in annex B are (no relationship with EPSG codes):

Code Projection
42001 WGS 84 / Auto UTM
42002 WGS 84 / Auto Tranverse Mercator
42003 WGS 84 / Auto Orthographic
42004 WGS 84 / Auto Equirectangular
42005 WGS 84 / Auto Mollweide

So for example AUTO2:42003,1,-100,45 is an orthographic projection centred on 100°W and 45°N. There is no stereographic code yet, but I see no reason to not add it. Maybe orientation could be added as an optional parameter. Note that there is currently no way to use a datum other than WGS84.

On the topic or OGC registry for projection, this is called "Operation Method" in ISO 19111 terminology. This registry exists in https://epsg.org and I guess could be reflected on OGC server. For referencing an EPSG object unambiguously, the EPSG code is not sufficient. We need the specify the kind of object (CRS, datum, etc.) as well. OGC we used to define a syntax for that, the Definition identifier URNs in OGC namespace (OGC tends to favor HTTP URL instead of URN, but I still find URN more human-readable). Table 2 lists 23 object types, including crs, axis, method and parameter. So for example:

In WKT2 specification (ISO 19162), it is recommended to rely on EPSG codes for parameters instead of their name, because there is too much risk that a parameter name such as "Latitude of natural origin" is named differently on different implementations ("Latitude", "lat0", "Latitude of centre", etc.).

I suppose that parameter codes could be used for building something like below (I wonder if "urn:ogc:def" could or should be omitted for brevity in this context):

.../map?
    baseCRS=urn:ogc:def:crs:EPSG::4326&
    projection=urn:ogc:def:method:EPSG::9804,
               urn:ogc:def:parameter:EPSG::8801=40,
               urn:ogc:def:parameter:EPSG::8802=-120
jerstlouis commented 1 year ago

Thank you very much @desruisseaux for the prompt feedback.

On the topic or OGC registry for projection, this is called "Operation Method" in ISO 19111 terminology. This registry exists in https://epsg.org/ and I guess could be reflected on OGC server.

Ah, yes thank you, I see 9840, 9820, 9809 are already all there at http://www.opengis.net/def/method/EPSG/0 .

About URNs vs URIs, the recent policy on Compact URIs (CURIEs) allows us to use safe CURIEs. The -method in [epsg-method:9840] (that I had called -projection) would already specifically refer to the EPSG operation method 9840.

A key goal here is simplicity and intuitiveness, so I am hoping we can take some liberty in OGC API - Maps to specifically define parameters such as projection, projection-center and orientation, ending up up with something more like:

   .../map?
      projection=[epsg-method:9840]&
      projection-center=Lat(40),Lon(-120)&
      orientation=40

Requirements in the specification would clearly explain how to apply the orientation and projection-center parameters for different projections.

I hope this is not swaying away too unreasonably far from ISO 19111 :)

We probably do not need factor, since we already have scale-denominator, width and height. I think the datum / base CRS could be implied from the dataset's native CRS. The ability to specify projection-spheroid could be an additional option, with a value such as [epsg-ellipsoid:1024].

desruisseaux commented 1 year ago

I was not aware of the new http://www.opengis.net/def/method/ space, thanks for pointing that out. Indeed it can be useful.

On the parameter names, I wonder if there is a risk of adding confusion if we invent new names. For example for the Stereographic projection, the same parameter already has all the following names:

For some other projections the name is "latitude of false origin", or "latitude of centre", etc. Those differences in names are not random; they carry a difference in what the parameter means. If we nevertheless want some simple names, the ones defined in §10.6.1 of OGC 01-009 are in wide use. For a more complete list the GeoTIFF projections list seems to reflect common usages. So for stereographic projection it would be:

jerstlouis commented 1 year ago

@desruisseaux the idea is to have a single, intuitive, readily understood by non-experts projection-center parameter, and explain in requirements to what it should map in the different projections. My 2nd best choice for the parameter would be to split it into projection-lat0 and projection-lon0, but I feel it is not as nice, short and intuitive as:

projection-center=Lat(...),Lon(...).

In dynamic 2D cartographic maps with runtime re-projection, it is a tyical concept to have a "projection center" which is following your "view center" (center in OGC API - Maps, which would default automatically to projection-center if center is not specified separately) as you pan around the map.

The requirements would explicitly map the Lon() value of projection-center to the central meridian, and the Lat() value to the latitude of origin (e.g., using those exact terms and adding "or the closest equivalent projection parameter").

On the parameter names, I wonder if there is a risk of adding confusion if we invent new names. For example for the Stereographic projection, the same parameter already has all the following names:

I don't see how one single simple name applying to both latitude and longitude, for all projections, can add further confusion to this already existing soup of names ;) Au contraire...

Those differences in names are not random; they carry a difference in what the parameter means.

They might carry a subtle differences, but there is almost always a clear mapping to the projection center. A counter-example where it would be ambiguous which latitude or longitude parameter should be considered for the projection center would be useful (most likely one where neither central meridian nor latitude of origin is defined).

The PROJ documentation says that +lat_0 (Latitude of origin) and +lon_0 (Central meridian) can be applied to most coordinate system definitions.

Thank you!

desruisseaux commented 1 year ago

When the projection has "False Easting" or "False Northing" parameter, then there is an ambiguity about whether the projection centre, i.e. the (0,0) coordinates, is before of after the easting/northing offset. I suspect that it may be the difference between "Latitude of natural origin" and "Latitude of false origin" (but I didn't verified).

Some EPSG projections (e.g. "Lambert Cylindrical Equal Area", "Mercator (variant A)", "Popular Visualisation Pseudo Mercator", "Polar Stereographic (variants B and C)") do not have a "central latitude" parameter, but only a "latitude true scale" parameter with a very different effect. How should we define "central latitude" in those cases?

jerstlouis commented 1 year ago

This link is very useful:

https://sis.apache.org/tables/CoordinateOperationMethods.html#9804

Difficult to find the valid parameters for methods anywhere else.

How should we define "central latitude" in those cases?

Actually, according to that SIS link, there is only an unmodifiable parameter called Latitude of natural origin [epsg-parameter:8801] for Mercator (variant A). Variant B and C have the Latitude of 1st standard parallel which is the latitude of true scale that we want the projection-center to map to. For Polar Stereographic B and C, it is also called Latitude of standard parallel. We could provide an ordered list of operation parameters to which the projection center latitude and longitude are mapped in the requirement, e.g.:

The projection-center Lat value SHALL be mapped to the first matching operation method parameter available for the selected operation method of the projection query parameter, in this order:

The projection-center Lon value SHALL be mapped to the first matching operation method parameter available for the selected operation method of the projection query parameter, in this order:

When the projection has "False Easting" or "False Northing" parameter, then there is an ambiguity about whether the projection centre, i.e. the (0,0) coordinates, is before of after the easting/northing offset.

From what I understand of the proj explanations of operation latitude parameters here:

Latitude of natural origin/Center Latitude The latitude of the point from which the values of both the geographical coordinates on the ellipsoid and the grid coordinates on the projection are deemed to increment or decrement for computational purposes. Alternatively it may be considered as the latitude of the point which in the absence of application of false coordinates has grid coordinates of (0,0). Latitude of projection centre For an oblique projection, this is the latitude of the point at which the azimuth of the central line is defined. Latitude of false origin The latitude of the point which is not the natural origin and at which grid coordinate values false easting and false northing are defined. Latitude of standard parallel For polar aspect azimuthal projections, the parallel on which the scale factor is defined to be unity.

The latitude of false origin is a point different from the projection center which corresponds to the false origin. Therefore, I think there is no direct correspondance between the latitude of false origin and the projection center i.e., the Latitude of natural origin / Center latitude must still be specified or default to some value separately. For OGC API - Maps, I think the main use case is visualization / portrayal, and the center query prameter allows us to center on the portion of the map of interest, so I don't think the false easting / northing will be particularly useful.

ADDENDUM: To put it another way (assuming I understand correctly), the latitude/longitude of false origin essentially means projecting those coordinates and obtaining a northing/easting to be subtracted from the false northing/easting to be added after applying the forward projection. You could alternatively pre-compute this and subtract it from the false northing/easting being specified, if those parameters are available. Both set of parameters deal with a post-projection translation operation in the projected space.

For projections with e.g., multiple standard parallels, I think to be useful one would need more control over the additional parameters. For those cases in particular, I think it would be useful to define the ability to unambiguously set any projection parameters with a syntax like:

Lambert Conic Conformal (2SP) example

   .../map?
      projection=[epsg-method:9802]&
      projection-parameters=[epsg-parameter:8823](40),[epsg-parameter:8824](90)&
      center=-120,60&center-crs=[ogc:crs84]&
      orientation=40

EDIT: I am a bit confused with PROJ lat_0 / [epsg-parameter:8821] / Latitude of false origin vs. PROJ lat_1 / [epsg-parameter:8823] / 1st standard parallel for this one, especially since PROJ seems to bundle both the 1SP and 2SP forms in a single projection.

ADDENDUM: I think what we could do for e.g., LCC 2SP is to define the projection-center (when not explicitly setting the 2 standard parallels) as the latitude in the center of the map, while automatically computing the 2 standard parallels based on the view scale denominator / bounding box / range. So the scale (which is true at both standard parallels) would be true at the northernmost and southernmost latitudes visible in the viewport. Though this might be a bit tricky...

I think we don't need the projection operation to apply a false origin, since that translation will be taken care by the center parameter (the panning / subsetting of the map). e.g., centering on 60N in the above example. center is very unambiguous: that point will be in the center of the map content of the returned image. Even for geo-referenced formats like GeoTIFF, the important thing for the Maps target use cases is that the ad-hoc CRS is well described, probably not so much that it uses a particular false northing/easting for the output CRS, which makes no visual difference. Those false northing/easting parameters could still be supported with projection-parameters, but possibly Maps should not make that a requirement.

The OGC API - Maps center parameter could default to the specified projection-center value (even if it does not get matched to any parameter e.g., if the false origins parameters are not considered). However, I am not sure in this LCC 2SP example if setting the projection-center latitude, which would get mapped to the 1st of two standard parallels, would have the desired effect. I think those 2SP are a special case where the simple projection-center doesn't work too well.

EDIT: I was also confused with the Mercator variants. PROJ only has a single Mercator projection with _latts as the only parameter, whereas in the SIS list Mercator A has one (but it is marked as Unmodifiable), Mercator B has two, but in this case I think the projection center latitude should map to the 1st standard parallel / latitude of true scale, not the natural origin, and Mercator C seems mostly the same as B without the optional latitude of natural origin and with the alternative way to specify the easting/northing. I have edited the rules at the top to reflect what I think now makes sense.

joanma747 commented 1 year ago

We decided that we will add a conformance class that will become an alternative to crs=

we will allow this set of parameters:

crs-datum=[epsg-datum:6326] crs-proj=[epsg-method:9840] crs-proj-param=epsg-parameter:8823,epsg-parameter:8824 crs-proj-center=Lat(...),Lon(...) crs-orientation=40 (we are forcing it in degrees)

( there could be a:

crs-wkt= but we will not describe this in the standard (yet). )

The crs-proj-center Lat value SHALL be mapped to the first matching operation method parameter available for the selected operation method of the projection query parameter, in this order:

[epsg-parameter:8832] Latitude of standard parallel (PROJ: lat_ts) [epsg-parameter:8823] Latitude of first standard parallel, if only a single standard parallel can be set i.e., no [epsg-parameter:8824] parameter is available (PROJ: lat_ts) [epsg-parameter:8801] Latitude of natural origin (PROJ: lat_0 ) [epsg-parameter:8811] Latitude of projection center (PROJ: lat_0)

The crs-proj-center Lon value SHALL be mapped to the first matching operation method parameter available for the selected operation method of the projection query parameter, in this order:

[epsg-parameter:8802] Longitude of natural origin (PROJ: lon_0) [epsg-parameter:8812] Longitude of projection center (PROJ: lon_0) [epsg-parameter:8833] Longitude of origin (PROJ: lon_0)

joanma747 commented 1 year ago

I understand, these "crs-*" params replaces the "crs=" param. Do we need to apply all this stuff to the bbox-crs? and to the other places where we have it (e.g. centre-crs...)? There will be an explosion of parametres!

jerstlouis commented 1 year ago

Do we need to apply all this stuff to the bbox-crs? and to the other places where we have it (e.g. centre-crs...)? There will be an explosion of parametres!

No :)

The common / easy thing to do for a client is to simply use center=lon,lat (default CRS84 center-crs), scale-denominator= and width and/or height for the desired map dimension, not having to deal at all with the coordinate values in that custom CRS.

Potentially what we could do is define a special value that refers to the output crs (whether specified by crs= or this custom projection CRS) for use by bbox-crs, center-crs and subset-crs e.g., bbox-crs=output-crs or bbox-crs=output, or if a special CRS URI from WMS already exists for this purpose.

A couple related questions are:

joanma747 commented 1 year ago

We realize that we need