Image CRS

[jetgeo]

[From Roger Lott]: "Image CRS. Those in yesterday's teleconference were pretty unanimously of the view that Image CRS and all classes hanging off it (DerivedImageCRS, ImageCS [already removed], ImageDatum, PixelInCell) were described in ISO 19123 / OGC Coverages specifications and therefore not required in 19111. But before we remove them I need to contact the coverages community to get their input."

[jetgeo]

[From Roger Lott]: Contrary to the CRS SWG discussion two weeks ago it would seem that there is a requirement not only to retain Image CRS but to augment it:

1. In the CRS package, add a class IndexCRS subtyped off ImageCRS
2. In the CS package: a. add a class Index subtyped off CoordinateSystem b. In the AxisUnit class add an attribute +Index:Integer
3. In the CS-CRS associations, add an aggregation named CoordinateSystem from IndexCRS to Index

This will accommodate the IndexAxis attribute in the coverages specifications: • An image CRS shall have either an affine coordinate system or a Cartesian coordinate system (unchanged from 19111:2007). • An index CRS shall have an IndexCS. Through the inheritance from CoordinateSystem (unchanged from 19111:2007) the IndexCS shall have one to many [ordered] axes, each of which shall have name or ID, an abbreviation, a direction and a unit (an index) and may have minimum and maximum values. The axisUnit should be an Index which is an integer (2b above), analogous to the temporalCount quantity. • Image CRS shall have an image datum which includes the pixel in cell attribute (unchanged from 19111:2007). Index CRS inherits this.

There is arguably some duplication here in that in the AxisUnit class temporalCount and Index are the same thing, applied to different types of axis. But for simplicity in understanding it might be best to live with this duplication, at least for the next draft.

[jetgeo]

Ok, I think I have done this now, but I would like to have it confirmed before I start with the new, alternative model. As much as possible should be fixed before I start on that model.

New CRS diagram:

New CS Diagram:

New CRS-CS Diagram:

[jetgeo]

Class Index renamed to IndexCS

[jetgeo]

Comments from Eric Hirschcorn: Some friendly comments on a subset of Peter’s suggestions:

1. I agree that ImageCRS should be subtyped from the simpler IndexCRS. Not the other way around.

2. I really like Peter’s suggestion of adding an overall direction (or orientation) to the ImageCRS definition. However, please call it an “image” direction (or orientation), not “screen”. A computer screen displays an image, but is not itself an image.

3. An “elliptic footprint” represents what a pixel looks like when it is projected onto the ground model. It comes up in discussions of error propagation of light from the ground that is transmitted to a sensor. This elliptical pixel shape is not typically considered a part of an image-based CRS since they are a result of a “ground projection”.

If these error parameters were to be relocated into an OGC CRS, they (IMO) would be made part of a new sort of Engineering CRS that could be described as a Photogrammetry CRS.

4. For the pixel origin, we have “origin-in-corner” and “origin-in-center”. They are very limiting, although I’ve never heard anyone suggest generalizing them: the 2 available are necessary but already cause lots of headaches – let’s not make the problem worse by adding more possibilities. (To generalize, one could just supply 2 real numbers x and y, such that 0<=x<1 and 0<=y<1. But don’t do that please!)

5. “origin-in-corner” usually refers to the top left corner. Adding a directionality attribute (from point 2) adds constraints on “origin-in-corner”. For directionality starting from top down, “origin-in-corner” refers to the top left corner. For directionality starting from the bottom, “origin-in-corner” refers to the bottom left corner. Should this be made explicit?

[jetgeo]

Comments from Eric Hirschcorn: Just a correction to an obvious mistake in my last email on point 5:

“origin-in-corner” usually refers to the top left corner. Adding a directionality attribute (from point 2) adds constraints on “origin-in-corner”. For directionality starting from top down, “origin-in-corner” refers to the top left corner. For directionality starting from the bottom, “origin-in-corner” refers to the bottom left corner. Should this be made explicit?

But if the image directionality is upwards, that would not affect the pixel origin. The “origin-in-corner” still implies the top-left corner. So, pixel origin-in-corner would imply top-left corner for either directionality.

Sorry for the confusion…

[jetgeo]

From: Hedley, Mark Sent: 25 April 2017 10:13

I am pretty wary of any IndexCRS provision within the CRS standard. I would be concerned to see ImageCRS dependent on IndexCRS by way of a subtype.

I think that the requirements for ImageCRS can be very well met without taking this approach and I think that this approach will cause issues within the standard and for implementers of the standard.

There is a crucial difference that I see here, which I think we should be mindful of. Referencing in ISO19111 is referencing by coordinates. It provides a way to interpret coordinate values.

An image may be considered a continuous space, with pixels the coordinate values. It is reasonable to talk about pixels as decimal quantities, and conduct mathematical transforms and calculations on part pixel quantities. This is a common feature of image processing algorithms.

However index values are pretty different, they are integer locations into an array. There is no interpretation (that I am aware of) of decimal quantities, partial index values, or continuity.

From my point of view, an index is not a coordinate. A coordinate may map to an index and a coordinate may be spatio-temporally referenced, but I do not see that an index may be spatio-temporally referenced directly.

I think that it is reasonable to talk about image coordinates and include an ImageCRS in the ISO19111 standard.
I would not advocate making an ImageCRS dependent on an IndexCRS, I do not think that an ImageCRS is an IndexCRS, this specialisation does not fit with my understanding of the 19111 approach. I would advocate avoiding an IndexCRS all together, I think this is a coverage, in ISO19123 terminology. The coverage should provide coordinates which map to its index space. If such coordinates are continuous and spatio-temporal, then those coordinates may be spatially referenced using the mechanisms provided in ISO19111.

[jetgeo]

Fra: Hedley, Mark Sendt: 27. april 2017 11:11

I would like to follow up a little on my earlier post.

I would like to note that ImageCRS is published in ISO19111:2007 Its removal from the new version of ISO19111 does require justification; the continuation of its presence is to some extent expected.

IndexCRS does not exist in ISO19111:2007 at all. Its inclusion requires significant justification, in my mind. At present I do not perceive this justification so I am not in favour of its inclusion, for the reasons I detailed previously.

I don't think these details were clear in my previous posting.

[jetgeo]

Fra: Peter Baumann Sendt: 27. april 2017 11:21

Hi Mark, all,

there are manifold use cases for n-D IndexCRSs. Fortunately, they are condensed in one place, the OGC coverage data model, CIS [1], so looking at this shows the mechanisms - concretely, the CIS 1.1 package contains a series of examples, including IndexCRSs (which, BTW, are served by the OGC resolver [2] already since some time as coverages need it). So let's move forrward in the quest of finding new CRSs which are going beyond classical "horizontal" cases.

[pebau]

adding the references pertaining to the above mail: [1] http://external.opengeospatial.org/twiki_public/CoveragesDWG/CoveragesBigPicture [2] http://www.opengis.net/def/crs/OGC/0/Index3D

[RogerLott]

Let's be quite clear here: this is not a quest for finding new CRSs. We are revising Abstract Spec Topic 2, currently called "spatial referencing by coordinates" but it is proposed that this be changed to "referencing by coordinates". We want to be sure that Topic 2 has all of the appropriate foundations to support the CRS requirements of grids and coverages, but also that there is no overlap or gap. That requires a common understanding of the boundary between the two.

Topic 2 (referencing by coordinates) currently includes the definition of a coordinate system as: coordinate system: set of mathematical rules for specifying how coordinates are to be assigned to points

and a coordinate reference system as coordinate reference system: coordinate system that is related to an object by a datum

It defines a coordinate as coordinate: one of a sequence of n numbers designating the position of a point in n-dimensional space Note 1 to entry: In a coordinate reference system, the coordinate numbers are qualified by units.

Is there perhaps a corollary to the note: if the coordinate numbers are not qualified by units then we do not have a CRS? And if it is not a CRS, what is it? A grid?

From the perspective of those who have been actively participating within the CRS SWG teleconference meetings it is clear that TINS, meshes, etc. are out of scope for Topic 2. Grids are a bit closer to coordinate reference systems, but they clearly have synergy with TINS, meshes, etc. as far as data population is concerned and from that data population perspective grids probably are best dealt with alongside TINS and meshes. But the constructs of referenceable grids as described in 16-083r2, in particular the subtype referenceable grid by transformation, has similarities to the derived CRS construct in Topic 2.

We will be discussing the modelling of derivedCRSs in the next CRS SWG telecon (Wednesday 3rd May 1400 UTC for ~90 minutes) and if those in the coverages community could join that at say 1500 UTC we could try to identify what elements of a grid, an index, a grid CRS, an index CRS and an image CRS, if any, should be included in Topic 2.

In the mean time could somebody please explain the distinction (if any) between a coordinate system, a grid, an index, a grid CRS, an index CRS and an image CRS. I can't find a definition of an index CRS anywhere.

Roger Grid definitions.docx

[desruisseaux]

I tend to agree with Mark position, about whether IndexCRS or ImageCRS should really be part of ISO 19111. Do we have a use case for them? On my side, coverages are almost always associated to another kind of CRS (GeodeticCRS, ProjectedCRS, etc.) and I use ImageCRS only as a fallback meaning "no real CRS information available". But I could as well use some kind of null value for that purpose.

Roger Lott via CRS.SWG wrote:

Is there perhaps a corollary to the note: if the coordinate numbers are not qualified by units then we do not have a CRS? And if it is not a CRS, what is it? A grid?

To me, the fact that ImageCRS "coordinates" are indices without units of measurements seems an indication that they may not fit in the ISO 19111 model. Or at least, if the group choose to keep ImageCRS, I think it would be worth to clarify which units are expected (units are mandatory in ISO 19111:2007).

Peter Baumann via CRS.SWG wrote:

there are manifold use cases for n-D IndexCRSs. (...snip...) So let's move forward in the quest of finding new CRSs which are going beyond classical "horizontal" cases.

I think it is a matter of type name. I think there is no fundamental difference between ImageCRS and the proposed IndexCRS except the number of dimensions, isn't? ISO 19111:2007 does not specify different CRS types for different number of dimensions (there is always a more fundamental reason). So if an ImageCRS-like type was kept in ISO 19111, instead than increasing the number of CRS definitions, maybe it would be sufficient to rename ImageCRS as GridCRS for avoiding the perception that ImageCRS is restricted to the two-dimensional case?

[2] http://www.opengis.net/def/crs/OGC/0/Index3D

(side note: I'm surprised by the elements like <identifier codeSpace="http://www.ietf.org/rfc/rfc3986">%cartesian3D%</identifier> in above GML. RFC-3986 seems to be about URI definitions; Is it really appropriate to use it as a code space for coordinate system types?)

[marqh]

Hi Martin, all,

there are manifold use cases in coverage world. The unit problem has been solved in the OGC IndexRCS by assigning unit "1" (in UCUM: "10^0"). Works like a charm. I am not so sure, though, what the unit of an image would be (if in doubt I'd also propose 1).

-Peter

Hello Peter

I feel that the unit problem is not well solved by the use of '1' as a unit for an index

Assigning a unit of 1 to a coordinate strongly implies that the coordinate is continuous and that the values can be used to represent some comprehension of size.

This seems very different from an index value, which can represent adjacent and non adjacent entities of variable size.

Some example questions:

• Is the distance from index[7] to index[8] the same as the distance from index[17] to index[18]?
• Does the location index[9.4] exist?
• Does the location index[9.5] represent the mid point between index[9] and index[10]?

I don't think that any of these hold true for an index I don't think that treating an index as a coordinate which may be spatio-temporally referenced fits with the ISO19111 approach.

As I have previously stated, I think that an index should be related to a coordinate and that coordinate is then spatio-temporally referenced using a CRS. ~IndexCRS~ does not fit this model.

I think image is in the middle ground, I could see it being out of scope, but I can see how it may fit, using the notion of image space. If an image may be defined as a contiguous set of pixels of the same size, then an image space, with image coordinates may be defined.

This is done in many drawing programmes, with the image coordinates being defined from 0 - 1 (with units of unity('1')) and the indices of the individual pixels mapped to image space via coordinates. These image space coordinates are continuous, may be interpolated over and so on.

So, I would say ImageCRS is on the cusp of whether it should be in scope for ISO19111, I can see the arguments both ways. Certainly some care about coordinates and units are required for these if they are maintained in the new version. ~IndexCRS~ seems to me a more clear cut case, this is defining a grid, a coverage. I do not think this is a CRS.

all the best mark

[RogerLott]

On Wednesday 3rd May Chris Little wrote:

Roger and colleagues,

I have been belatedly catching up with this interesting scoping debate about what is and is not a CRS.

If we were starting from scratch, I would take the view that an abstract CRS is about relating coordinate systems to objects via datum . I would not include an Image CRS as a special case that mixes several concepts of coordinates, references, images, grids, topologies, scanning patterns, cell methods (the CF-NETCDF term for how a variable relates to the grid cell – point value, areal or temporal mean, etc) or interpolation type (the TimeseriesML and WaterML term for the same CF-NetCDF concept)

I would also exclude indexed grids, whether rectilinear, TINS, meshes, etc, as not per se CRSs, and can be processed in many real world systems. Especially because the n-D mathematical aspects are well understood, and are much closer to numerical analysis than geospatial, and this clear distinction is important, especially in environmental science and other numerical models. For example, the ‘cell method’ aspect that I mentioned becomes more complicated in such models, and have been classified into Arakawa A to E types horizontally and Charney-Phillips types vertically, where different associated variables are assigned differently to the centre or corners or midpoints of the sides of a cell for good numerical analysis reasons.

The geo-referencing aspects for such grid points can often be calculated once for a given grid, thus becoming ‘constants’ for a given (expensive) calculation, and the topic of numerical interest is the topological relationship of the grid point values (top/bottom, up/down, left/right, last/next, etc.)

Consequently, I would advocate that continuing to keep Images as part of the abstract model, with its mixture of geo, grid, engineering and image coordinates is a mistake.

Obviously, there is a historical and continuity argument for keeping Image CRS, but I would advocate having this as a separate document.

Just my 5 cents worth. Chris

[RogerLott]

Telecon 2017-05-03 agreed that ImageCRS and its component ImageDatum including PixelInCell should remain in model to cover an image space in which there are continuous regular axes e.g. when pixels/voxels are same dimensions and contiguous. The description of the PixelInCell attribute cellCorner to be modified to clarify that the corner is that with minimum coordinates.

Irregular grids and indexing systems are out of scope and all requirements should be covered in ISO19123 / OGCTopic6. Therefore Index, IndexCS and IndexCRS should be removed from the 19111 model.

[pebau]

hm, just for documenting: it's a pity and IMHO a lost opportunity:

• ImageCRS is useful, but not conceptualized appropriately (eg, I am surprised to see it as a continuous space while screens today are discrete with fixed resolution each; further, it is classically 2D "flat"; etc.)

• IndexCRS is definitely required by coverages; it is definitely not a grid definition extrinsically (see my last mail), and I find it sad that non-referenced n-D data are excluded from 19111...so we will have to define it elsewhere, which will lead to different places to go for collecting CRS definitions in future.

• it is sort of ok that grid definitions are not in 19111, so this will have to be defined elsewhere in OGC and maybe ISO.

This entails that we are getting a growing dependency graph with at least 3 specs involved (19111, IndexCRS, grids).

You sense I am not overly happy, but the advantage is that there is clarity on how to proceed further.

cheers,

Peter

On 05/04/2017 09:17 AM, RogerLott wrote:

Telecon 2017-05-03 agreed that ImageCRS and its component ImageDatum including PixelInCell should remain in model to cover an image space in which there are continuous regular axes e.g. when pixels/voxels are same dimensions and contiguous. The description of the PixelInCell attribute cellCorner to be modified to clarify that the corner is that with minimum coordinates.

Irregular grids and indexing systems are out of scope and all requirements should be covered in ISO19123 / OGCTopic6. Therefore Index, IndexCS and IndexCRS should be removed from the 19111 model.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ISO-TC211/ISO19111/issues/5#issuecomment-299113086, or mute the thread https://github.com/notifications/unsubscribe-auth/AF0ejgZGnJJI9OXgYErXgz8CYkUlkfEOks5r2XungaJpZM4NAPdj.

-- Dr. Peter Baumann

• Executive Director, rasdaman GmbH Bremen (HRB 26793) www.rasdaman.com, mail: baumann@rasdaman.com tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
• Professor of Computer Science, Jacobs University Bremen www.faculty.jacobs-university.de/pbaumann mail: p.baumann@jacobs-university.de tel: +49-421-200-3178, fax: +49-421-200-493178 "A brilliant idea is a job halfdone."

[jetgeo]

Extracted from https://github.com/ISO-TC211/ISO19111/issues/6:

• [x] Delete the IndexCRS class

• [x] Delete the IndexCS class

• [x] Remove +index attribute from the AxisUnit class

[jetgeo]

Ok, done. New figures in https://github.com/ISO-TC211/ISO19111/tree/master/Figures/Main%20version