DomainSet: Specifying both Geospatial and Temporal CRS? #7
Comments
|
yes, it is - maybe look into CIS and the examples? |
|
@pebau As we've identified, the latest CIS examples are currently lacking and misleading, and we are trying to improve on this and address those shortcomings. The related example I see from the rasdaman OGC API server is:
Our client (and most clients) will not want to go and fetch and analyze responses from that server describing the SRS, nor will they want to do fragile parsing of such a combination string, rather we want to quickly identify known reference systems that we are already aware of. "srsName" : "http://www.opengis.net/def/crs/EPSG/0/4326",
"trsName" : "http://www.opengis.net/def/uom/ISO-8601/0/Gregorian",This has nothing to do with seeing space and time as one continuum or not, it's the exact same idea of creating a "compound" SRS by combining a spatial and time reference sytems, but it would be done in a way that is actually practical. |
|
@jerstlouis there are reasons behind this, you might want to understand coverages before writing standards about them; at least read the spec. When endeavoring new multi-dimensional pathways it might become necessary to get out of the comfort zone of 2-D flatland. |
|
Thank you @pebau . I do see those two examples: http://schemas.opengis.net/cis/1.1/json/examples/25_3D_time.json also using http://www.opengis.net/def/crs-compound . However, both fail to resolve because there is an XML character code ( should probably be I also see this text in the CIS 1.1 specifications:
Yes this minimizes the problem of going and fetching the URL, but still it seems to me that having separate properties for the spatial and temporal CRS (with the exact same meaning as On a separate note, I am struggling to find the CRS to use for Gregorian Date+Time, e.g. to use in Coverages API with ISO 8601 -- any help would be welcomed! At http://www.opengis.net/def/crs/OGC/0 UPDATE: Would that be appropriate to use with combine-crs ? (No, it doesn't get resolved) Thanks. |
|
@jerstlouis I keep on bringing up personal opinions which you do not substantiate. You claim that something is "better" for "the user". I don't see that, practical experience is different. Normally only programs see that URL anyway, as well as script hackers; implementers just concatenate strings, which is trivial in all languages. What actually is tedious is exactly what your idea does not remedy either: the limitation to CRS URLs is the source for these ugly, strange, and long CRS spelling. This focused behavior was dictated by CRS.SWG and OGC-NA, and we accepted that earlier; it is also easy to handle by program. But we might propose to extend with shorthands. For example, 3D WGS84+time might be written exactly like that: "EPSG:4326+OGC:AnsiDate"; the tool internally can expand this to OGC-NA conforming URLs (WCPS 1.1 does that). However, this is not in our power, OGC-NA needs to decide. Separation of CRS axes is a dead end, a dinosaur from last millennium. Exactly the unification of all axes is a key progress in Earth data service science since then. Did you find out meantime why separation is a disadvantage? We may want to concentrate on essentials rather than doing cosmetics at will now, without considering effects. Standards are about continuity. |
|
I understand we want all axes to be treated the same, regardless of whether they represent spatial or temporal or other dimensions of the DomainSet. We are in complete agreement there. We are also agreeing that defining ahead of time every single combination of spatial CRS and time and height is not very practical. And I understand that this is what crs-combine was trying to achieve. But the issue I raise with crs-combine is that this information then becomes purely informative, and is not something clients can really make use of. This is because there are significant problems associated with both: Specifying the constituent CRS as separate properties serves exactly the same objectives as the combine-crs (the resulting SRS is not any less unified), but that does not suffer from those limitations. Therefore clients can actually recognize these CRSes, and as a result this allows them to make sense of what each axis name enumerated in the DomainSet represents. This is what I mean by "separate properties being more useful to the client" (from the client developer's perspective -- while concatenating strings is trivial for the server, splitting up URI strings is generally avoided in clients), and I am considering practical experience developing a OGC API - Coverages client & server and over the last year working on Technology Integration Experiments with multiple servers, whose implementers are still not clear on how to specify the combined spatial & temporal CRS because of this. I agree it would be good to discuss this with OGC NA @ghobona and maybe @joanma747 might also be interested to chime in... |
|
Trying to pick apart the multiple issues being mixed here. From what I read, this is actually several issues:
On the first 2 we can do something, on the third only warn developers to run some regex over their strings before trying to consume ;) |
|
@jerstlouis "splitting up URI strings is generally avoided in clients" - to get out of the shifting sands of assumptions about developer capabilities, do we have a definition of the minimum capabilities any OAPI c/s developer must have? I mean, string splitting is 1-3 lines of JavaScript... |
The neatest that comes to my mind is like the above example: "EPSG:4326+OGC:AnsiDate"; GDAL understands similar syntax AFAIK, it can be mapped to ISO 19111, can be parsed trivially. I am sure @jerstlouis has found this already, but just to illustrate one more reason for the simple single-CRS approach: |
Actually, this is managed by ISO 19111 / CRS.SWG, and they are not amused about anybody bypassing their specs (which makes sense, no further islands please). Instead of GML you can use WKT, but experience tells this doesn't really make it easier. So: onboarding CRS experts would help so much. |
It is not about string splitting being difficult, but that it then gets complicated to define (or properly implement) the rules surrounding the use of crs-compound and how one should extract the multiple constitutents out of it, and which combined CRSes are considered equivalent, etc. In other places in OGC API the CRS are URI which are compared as expected to be exactly the same, if I understand correctly. Essentially if we stick to a single The fact that an issue like https://issues.apache.org/jira/browse/SIS-341 exists speaks to the fact that this is not trivial. But what I am gathering is that in fact clients wishing to make use of the
I assume you are referring to the axis order being different... |
|
Interestingly, the opengis.net crs-compound script seems to only resolve successfully in one order (with a confusing error message as well): says
While works. However, this (flipping the numbers in the request URL instead) works and returns "Julian Date / WGS 84" instead of "WGS 84 / Julian Date": which is really confusing... Likely a bug on the definition server? |
Best forward this request to CRS.SWG - just to repeat once more, CRS handling is, for a good purpose, not homebrewn here but adopted from the CRS.SWG. Or just start writing it and then get it scrutinized by them - as always in a do-ocracy this might speed things up.
ahem, issue is fixed and closed - that seems to me the regular software development process I am used to.
...and this is less error prone, distributing information and hiding it?? I wouldn't want to sit in that jet. Ya know, change just for the sake of change and "I like this style better"... I remember in older times we had documented issues with detailed technical requirements and use cases, not just "but I prefer". |
might be indeed, would be a nice catch - opening a ticket now, will report back. |
or "crsComponents" : [
"http://www.opengis.net/def/crs/EPSG/0/4326",
"http://www.opengis.net/def/crs/OGC/0/AnsiDate"
]is what is less error prone, less subject to misinterpretation and confusion, and much more straightforward than: "srsName" :
"http://www.opengis.net/def/crs-compound?1=http://www.opengis.net/def/crs/EPSG/0/4326&2=http://www.opengis.net/def/crs/OGC/0/AnsiDate",as exemplified by:
I don't think it's a matter of preference or style :) But I realize there's an interoperability cost with any change, so perhaps it is not worth changing anything (other than clarifications / guidance on the use of crs-compound and more examples). crs-compound is not happy with 2=http://www.opengis.net/def/uom/ISO-8601/0/Gregorian so I'm still wondering if we are missing a CRS definition for Date+Time using ISO-8601? It would be nice if such a temporal CRS was defined where Right now the closest thing accepted by crs-compound supporting time is http://www.opengis.net/def/crs/OGC/0/UnixTime, but specifying this in the DomainSet seems at odds with ISO-8601 values expected by the |
hm, not sure where that URL comes from. It refers to uom, BTW.
it is, indeed - I share your view that this is counterintuitive -> OGC-NA could resolve to have aliases, then we can set that up on short notice.
There was a long discussion with CRS.SWG at some time, with the effect that both should be possible. Roger Lott & friends (and GML folks!) for a long time insisted on seconds since epoch, and didn't like at all to have strings instead of numbers in coordinates; meantime they are converted and sell it as their outcome :) and 8601 is seen as a user-friendly way of specifying it, and it can be converted to seconds following standard tools like in Unix. |
|
What worries me most on this discussion is that just as CIS 1.1 has opened up the coverage perspective to be able to deal with all sorts of axes, this discussion is again focusing it down to the classical lat&long plus sorta-elevation (long as you're in m or a standard CRS) and time - does help to explain why some of the Copernicus DIAS are bypassing coverage models altogether and just going for a clean data cube solution |
|
@pebau Yes I know it refers to uom, and so it is understandable that it doesn't work, but as I mentioned above, that URI appears as a member definition of http://www.opengis.net/def/trs/ISO-8601/0/ (which also has me wondering why we have /trs but some temporal reference system are also found in /crs) |
diversity :) OGC has given up on clear guidance in favour of having competing ecosystems, and that is the effect now. Certainly for people outside even more confusing than for us. We might ask OGC-NA... |
|
Genuine question, which I'm sure is an old chestnut - if CRSs are denoted by name or identifier, what's the method for specifying a CRS that takes parameters, i.e. one that is not completely predefined at an existing URL? |
|
this below is from a slide, sorry for the hasty copy.
|
|
In light of all this, how is a simple client expected to look at the single CRS URI, and say "yes, I know what this is, I can work with data expressed in this CRS and map it to what I support"? If there are more than one single URI string which are equivalent, and the client is working offline or does not wish to make additional HTTP requests or perform analysis of yet another document at another location, how can this be done? Even if the client is ready to do some string parsing / analysis of the URI, there is nowhere to begin on how it should proceed to do so. I feel like providing some guidance regarding this (whether in CIS itself, or a user's guide, or in OGC API - Coverages or its user's guide) would go long way, something like:
Is there anything like this, currently? Is that something covered by the CRS SWG? I don't think I am alone having difficulties coming across this this type of information, even when actively looking for it, while I think it should be very easy for developers to find. This is because many clients are not really interested in looking up the CRS of every new coverage they come across using an online request, but rather are trying to identify the CRS used in that data to quickly identify it and/or look it up in their own local database. |
|
@pebau - thanks, very useful! @jerstlouis - yes, I understand and feel this pain too. I also don't particularly want to dereference a URI in order to get the details of a CRS. I'd rather (a) get an identifier I can look up in my own database, or (b) see the complete definition of the CRS inline (does the "Inline CRS definition" Peter mentions above do the trick? What's the syntax for this?) I'm biased by my background in CF-NetCDF, where (almost) everything is defined inline, and it's common to use CRSs that have not been defined in an external database. CF-NetCDF can also map different CRSs to different dimensions, and combinations of dimensions. I don't think this creates any limitations on use: you can still request arbitrary slices in any dimension of course and this takes care of CRSs of any dimensionality. I personally find the CF-NetCDF approach to be practical, which is why we used a similar-ish structure in CoverageJSON. |
|
@jonblower About b), that is great for custom CRS, but for cases that can be handled by a), I feel there should be a recommendation that the simpler aproach be used. Parsing a custom CRS makes it difficult to then map the data to a known CRS, unless you can somehow relate axis names and projections, e.g. to integrate multiple data sources, or visualize on a virtual globe. A simple client may also not want to write or import tons of code to parse an inline CRS definition when it only supports one or two CRSes, only to try to figure out if the inline CRS defined is one of these. For an inline CRS, I don't see any examples currently in the JSON examples. It is not clear to me how this should be done in CIS JSON, and I think a proper JSON encoding based on either the GML or WKT CRS definition should be required. |
Oh, I totally agree. I wouldn't want to "spell out" EPSG:4326 inline every time I used it. Custom CRSs could get very tricky, but the main use case I'm thinking of here is a parameterised projection (e.g. polar stereographic, Lambert Equal-Area), or rotated-pole CRS (which is surprisingly common in meteorology, but does not appear in any external database that I know of).
Yes, I'd support that. We made a suggestion in CoverageJSON, but this isn't really fully baked so I'm certainly not going to propose it as a final solution, maybe just a starting point: https://covjson.org/spec/#514-providing-inline-definitions-of-crss. |
|
So the two conflicting goals seem to be: simplicity and unique identification (aka URL resolution). Maybe we can get the ball rolling with OGC-NA ? FWIW, the following mail I have sent to @ghobona on 2021-mar-16: from various sides I hear that CRS URLs are considered quite inconvenient, in particular when it comes to compound CRSs as frequently used in coverages, but also in applications combining, eg, some random horizontal CRS with a vertical one. We have a case with a 6D cube, just imagine the CRS! Actually, there are common notations which can make life easier - ESRI, PROJ, etc use that regularly in one or the other shape - simple example: EPSG:4326 = www.opengis.net/def/crs/EPSG/0/4326 OGC-NA could introduce well-defined shorthands, such as "EPSG:4326+OGC:AnsiDate+OGC:Index1D" with a simple mapping of
This mail is just a first ping to see whether there is an opportunity, so I am curious about your thoughts on it. |
exactly: CIS simply uses CRSs following the method that was given to us then. Any encoding, JSON or so, should come from CRS.SWG, therefore. They would not enjoy us defining a "proprietary" solution. |
The silent, cautious opening of a door out of the GML cage! |
|
@jonblower the parameterized projection is definitely an interesting use case... If we had a simple JSON data structure to easily describe a CRS by specifying projection, spheroid, units, etc., in the end I think that would be a lot more practical/recognizable than a URI that clients end up having to do some not well defined parsing, or deference like:
It doesn't seem that Is there a JSON Schema for that WKT->JSON mapping? I just discovered PROJJSON, which does provide a JSON schema:
|
|
@jonblower @jerstlouis @KathiSchleidt
definitely agreed that parsing of the complete definition is undesirable. But bypassing is not an option either - the client wants to know the CRS to decide whether it can put the hurricane on the right spot on the map.
In XML it would be simply be a GML CRS definition embedded in the metadata. In JSON it would likewise be...no, that's really too ugly, XML in JSON. So we definitely need a JSON equivalent (earlier someone asked for the same in RDF), fully supported! |
|
@jerstlouis - I'm not aware of a formal WKT->JSON mapping, and we didn't do a schema for it ourselves, so I don't know, I'm afraid. If we want a syntax for a "parameterised" CRS, maybe there is inspiration we can take from CF (e.g. here). @pebau - yes, I fully understand that CIS inherits this from CRS.SWG. And I quite like the shorthand you propose above, in principle at least. It's nice to have a simple and readable way to address common use cases. I must admit I still don't quite understand how CIS maps the components of the compound CRS to the domain axes, but I'm sure this must be defined - do you have any quick pointers? |
that is simply by name: with "1=EPSG:4326 & 2=OGC:AnsiDate" (to use the shorthand) you get Lat/Long as axis 1 + 2, followed by axis 3 = time. So it is by position of the numeric key in the KVP. |
PROJJSON seems to be very promising, and seems in line with where you wanted to go next in terms of defining an encoding for WKT2? It would be interesting to see if the CRS SWG might be willing to take on the standardization of the PROJJSON encoding as an OGC standard. |
Thanks @pebau - so in this case the underlying data array is 3D, and the client figures out that EPSG:4326 is a 2D CRS and therefore corresponds with the first two axes of the array - is that right? Do the number of dimensions in the data array always have to match the sum of the dimensions of the CRSs? I'm wondering about the case where (for example) the data array is 1D, but the CRS is 3D (e.g. a 1D series of xyt points, like a ship track)? Or, perhaps more awkwardly, a case where the data array is 2D but the CRS is 3D, e.g. an array with time on one axis and xy position on the other, representing a synchronised set of timeseries at a number of points on the Earth's surface? In this case, one domain axis (time) would have a 1D CRS and the other (position) would have a 2D CRS (like EPSG:4326). (In case it helps, a CovJSON example of something similar is here - see Trajectory: https://covjson.org/spec/#613-examples and a few more examples in the Domain Specs: https://covjson.org/domain-types/) |
|
(@jerstlouis - at first glance, PROJJSON looks just the thing!) |
pretty much - see CIS 1.0 + 1.1 for details
that's the difference between geometric and topological dimensions, yes.
see CIS 1.1 axis types here. |
|
Thanks @pebau - it seems that the key is in the difference between geometric and topological dimensions, but I can't find an explanation of these in the CIS1.1 spec. There are a couple of mentions of those terms in the spec but I can't see a definition of either. Could you point me in the right direction please? Alternatively, are there examples of CIS encoding (XML or JSON, I don't mind) of those things (e.g. 1D series of xyt points, like a ship track)? (I'm aware this might be a bit off-topic from this original ticket, so we could open a new one - but it's related to the problem of interpreting CRSs.) |
|
@joanma747 The CIS 1.1 examples are at http://schemas.opengis.net/cis/1.1/json/examples/ |
|
@jerstlouis - thanks, yes, I've seen the examples but I don't think there's one there yet that fits that specific use case. The point cloud use case is probably the closest, but that example doesn't have any coordinate referencing information in the I assume that (if there were an By the way, I think this use case argues against having separate |
yes, absolutely - any spatial, temporal, or "abstract" axis qualifies.
couldn't agree more! We had this discussion just this afternoon in the OGC TC meeting; the separation is unfortunate, backwards oriented, and closes doors for several use cases. And complicates artificially. What is really ugly is the requirement to have mile-long URLs for CRS identifiers. I have made a proposal today, let's see whether it gets through. |
|
Thanks @pebau. Just thinking further about linking CRS axes with grid axes, or positions in a coordinate tuple. If I've understood correctly (please let me know if I'm wrong!) the CIS structure means that the axes must be used in the same order that they are in the component CRSs, and that axes from different CRSs can't be interleaved? This probably isn't very clear, so here's an example. Let's say I have a 4D grid that uses CRS:84 for the xy positions, SomeVerticalCRS for the z positions and AnsiTime for the t positions. If the order of axes in my data array are lon-lat-height-time, I don't have a problem; my CRS string would be something like But let's say that I want to express my data array using a different axis order, e.g. lat-time-lon-height. Could I do this? I can't quite see how that would work, as you need more information than just the order of CRSs. You need to think about the CRS axes individually and reorder them. You could create a custom CRS with the axis order you want, I suppose. Maybe that could be done inline, as you probably wouldn't want to define it and host it at a URL? In CF-NetCDF (and in CoverageJSON) you don't have the same issue because the CRS-data axis mapping is more explicit. I do appreciate that this looks like a rather contrived use case, and it probably doesn't come up very often, but I have used it myself, mainly when thinking about performance (reordering the axes on disk is a good way to increase performance for certain extraction use cases, as of course you know!) |
|
I'm not the expert here, but would expect this to be explained in the coverageFunction: |
|
@jonblower |
@pebau can you confirm if the coverageFunction is the way to do this, as @KathiSchleidt suggests? In the examples I've seen I have only seen this used for modifying the grid offsets, but maybe there's a structure that can map the axis order like this? (I know doing things like splitting lat and lon is a bit of an obscure use case, but I think it's a valid one that I'd have an occasional need for.) |
|
@jonblower no, as stated it is about assembling the axes in the domain set. CIS has made the world a little easier to handle, in particular CIS 1.1. |
|
@pebau - thanks, but I don't think I've quite understood yet. I wonder if an example of my use case could be created to clarify things? I think it would be helpful in any mapping from NetCDF to CIS. Let me know if I should raise a ticket somewhere else about this for consideration. |
Currently GeneralGrid specifies a single
srsName.Is that enough to specify both the spatial and temporal reference systems?
Are there SRS defined supporting all combinations of srs & trs?
The Common
extentapproach specifies those separately.The text was updated successfully, but these errors were encountered: