Clarify if "input@position values" are tile or extent

[joanma747]

The issue emerged from this two possible syntax:
A:
<link rel="tile" tref="http://maps.nofc.cfs.nrcan.gc.ca/geoserver/public/wms?service=WMS&version=1.1.0&request=GetMap&layers=public:fdr_current&styles=&bbox={xmin},{ymin},{xmax},{ymax}&width=256&height=256&srs=EPSG:3978&FORMAT=image/png&TRANSPARENT=TRUE&m4h=t"/>
B:
<link rel="image" tref="http://maps.nofc.cfs.nrcan.gc.ca/geoserver/public/wms?service=WMS&version=1.1.0&request=GetMap&layers=public:fdr_current&styles=&bbox={xmin},{ymin},{xmax},{ymax}&width=256&height=256&srs=EPSG:3978&FORMAT=image/png&TRANSPARENT=TRUE&m4h=t"/>

In both cases {xmin},{ymin},{xmax},{ymax} are numbers in the projected CRS (assumed as units=pcrs) but in the first case they need to have "tile" positions and in the second "extent" positions.

Please expand the table to include:
Keyword State
tile-top-left Identifies a location relative to a tile.
tile-top-right Identifies a location relative to a tile.
tile-bottom-left Identifies a location relative to a tile.
tile-bottom-right Identifies a location relative to a tile.
tile-center-left Identifies a location relative to a tile.
tile-center-right Identifies a location relative to a tile.
tile-top-center Identifies a location relative to a tile.
tile-bottom-center Identifies a location relative to a tile.
tile-center Identifies a location relative to a tile.
extent-top-left Identifies a location relative to the extent.
extent-top-right Identifies a location relative to the extent.
extent-bottom-left Identifies a location relative to the extent.
extent-bottom-right Identifies a location relative to the extent.
extent-center-left Identifies a location relative to the extent.
extent-center-right Identifies a location relative to the extent.
extent-top-center Identifies a location relative to the extent.
extent-bottom-center Identifies a location relative to the extent.
extent-center Identifies a location relative to the extent.

[prushforth]

I'll think a bit more about this, but you are probably aware that xmin etc are variable names that are have no meaning on the client other than relating the URL template position in @tref to the associated <input name="xmin" ...>.

I think @pomakis should be involved as they've implemented MapML on their server too.

And this discussion isn't so much about the link template as it is about the attributes and their values for the <input type="location"> element. There are four link template rel values: image, tile, feature and query. It would seem that inputs associated to a rel=tile template would require the input to be a tilematrix row or column value. But that is not necessarily the case; to generate a tile image from a WMS back end, we need the ability to specify request bounds per tile in the pcrs or perhaps other coordinate system not just tilematrix row or column. So that's why there are other attributes on the input apart from units: so as to identify which coordinate system to use for the variable value.

Currently, we are using the @units attribute to be the first signal about what kind of location is being asked of the browser. As such, I believe the (@position) tile- and extent- prefixes are redundant because the @units value is all you need to know in order to understand whether the @position is tile or extent-relative. I may be wrong. I will see if I can find any more discussion of this somewhere.

[prushforth]

Note that there is input@rel which makes the relation explicit when necessary:

The meaning of the position attribute value (keyword) depends upon the presence and value of the associated rel attribute. When the rel attribute is not present or has the value image, the position attribute keyword value describes the input location relative to the ancestor extent. When rel=tile (only applicable when the units value equals tilematrix), the position attribute values describe the input location relative to the tile at the location in question.

I'm not sure if such a rel would ever be necessary, since it could be deduced from the fact that @units=tilematrix, I believe.

[prushforth]

I'm not sure if such a rel would ever be necessary, since it could be deduced from the fact that @Units=tilematrix, I believe.

I guess you could be in search of the tiles that are the rough locations of the corners of the extent, so you might want to use it like this:

<input name=ymin type=location units=tilematrix rel=image position=top-left axis=row>
<input name=ymax type=location units=tilematrix rel=image position=bottom-left axis=row>
<input name=xmin type=location units=tilematrix rel=image position=top-left axis=column>
<input name=xmax type=location units=tilematrix rel=image position=top-right axis=column>

Unsure if that would ever be useful.

[prushforth]

And yes, I debated whether 'image' should have been 'extent' but since 'image' already existed as a rel value, I decided against adding a new value for the same concept. YMMV.

[joanma747]

And this discussion isn't so much about the link template as it is about the attributes and their values for the <input type="location"> element.

That is correct.

Currently, we are using the @Units attribute to be the first signal about what kind of location is being asked of the browser.

I see what you mean but I object on having attributes with fuzzy meaning.

My interpretation is that we need 3 things:

• coordinate reference
• axis name
• corner name
  that clearly define what we are talking about:
  "coordinate reference" should defined completely the meaning of the numbers: are they pixels, m, deg, "tiles cols or rows" and where the origin of them are.
  "axis" should be the direction (you are using the name of the axis; that is fine). Current definitions are clear
  "corner" should tell us to what object-extreme the location is reffering to. It is a tile, an image... and width side of it we are talking about..

I guess you could be in search of the tiles that are the rough locations of the corners of the extent, so you might want to use it like this:

That might be a way out. "corner" remains only the "extreme" name and "rel" could tell us about the "object" name: Tile or image. I like that. In the end 4 things will tell us exactly what we are talking about.

[prushforth]

That might be a way out. "corner" remains only the "extreme" name and "rel" could tell us about the "object" name: Tile or image. I like that. In the end 4 things will tell us exactly what we are talking about.

So do you agree with the current design? I take it by "corner" you are talking about the current @position attribute, of which the domain of values is (perhaps these are "extremes"):

top-left Identifies a location relative to a tile or extent.
top-right Identifies a location relative to a tile or extent.
bottom-left Identifies a location relative to a tile or extent.
bottom-right Identifies a location relative to a tile or extent.
center-left Identifies a location relative to a tile or extent.
center-right Identifies a location relative to a tile or extent.
top-center Identifies a location relative to a tile or extent.
bottom-center Identifies a location relative to a tile or extent.
center Identifies a location relative to a tile or extent.

[joanma747]

I agree if the following changes are accepted:
input@units= is the "coordinate reference" defined in way that defines the meaning of the numbers: are they pixels, m, deg, "tiles cols or rows" and where the origin of them are. It is says "tilematrix" numbers of the variable are tilecol and tilerow. If it says "pcrs" numbers are projected coordinates.
we add input@rel to determine if this is tile or image.

The following case should be considered wrong:

<input name=ymin type=location units=tilematrix rel=image position=top-left axis=row>
<link rel="image" tref="http://geoserver.com/wms?service=WMS&version=1.1.0&request=GetMap&layers=public:fdr_current&styles=&bbox={xmin},{ymin},{xmax},{ymax}&width=256&height=256"/>

and should be:

<input name=ymin type=location units=pcrs rel=image position=top-left axis=row>
<link rel="image" tref="http://geoserver.com/wms?service=WMS&version=1.1.0&request=GetMap&layers=public:fdr_current&styles=&bbox={xmin},{ymin},{xmax},{ymax}&width=256&height=256"/>

[prushforth]

and should be:

 <input name=ymin type=location units=pcrs rel=image position=top-left axis=row>
 <link rel="image" tref="http://geoserver.com/wms?service=WMS&version=1.1.0&request=GetMap&layers=public:fdr_current&styles=&bbox={xmin},{ymin},{xmax},{ymax}&width=256&height=256"/>

That looks wrong too because you are requesting the row axis (which does not apply to pcrs) so you would get ?nothing? or if leniency was applied perhaps the vertical axis?

[joanma747]

My appologies. You are completelly right and I was distracted.

it should be:

<input name=ymin type=location units=pcrs rel=image position=top-left axis=northing>
<link rel="image" tref="http://geoserver.com/wms?service=WMS&version=1.1.0&request=GetMap&layers=public:fdr_current&styles=&bbox={xmin},{ymin},{xmax},{ymax}&width=256&height=256"/>

[prushforth]

It should be:

<input name=ymin type=location units=pcrs rel=image position=top-left axis=northing>
<link rel="image" tref="http://geoserver.com/wms?service=WMS&version=1.1.0&request=GetMap&layers=public:fdr_current&styles=&bbox={xmin},{ymin},{xmax},{ymax}&width=256&height=256"/>

So we agree on the above, with the caveat that rel=image is redundant because it is the default rel. OK?

On the other hand, to go back one:

The following case should be considered wrong:

<input name=ymin type=location units=tilematrix rel=image position=top-left axis=row>
<link rel="image" tref="http://geoserver.com/wms?service=WMS&version=1.1.0&request=GetMap&layers=public:fdr_current&styles=&bbox={xmin},{ymin},{xmax},{ymax}&width=256&height=256"/>

I would not say that the input is wrong, but the URL template won't be filled in correctly because you'll be serializing a row value for the upper left hand corner of the extent, which won't return anything useful from a WMS. But I won't say the input is strictly wrong. Perhaps that is what you meant by wrong?? If you are confused, I am discouraged for the school children I hope to convert to MapML, and we should try harder to make it not confusing, I agree.

[joanma747]

So we agree on the above, with the caveat that rel=image is redundant because it is the default rel. OK?

Yes

I would not say that the input is wrong, but the URL template won't be filled in correctly because you'll be serializing a row value for the upper left hand corner of the extent, which won't return anything useful from a WMS.

Yes. That is exactly what should happen.

[prushforth]

Great this is actually implemented now, closing.