Clarify text around transform origin being top-left corner

[kylebarron]

In geospatial data, the index (0, 0) tends to be at the top-left corner of the image, but unless we put additional restrictions on the format of spatial:transform, this is not necessarily true.

I think we should probably update the text to say (0, 0) is normally the top-left corner but isn't required by the spec.

spatial/README.md

Lines 148 to 161 in 59dd7f4

	- `a`: pixel width (w-e pixel resolution)
	- `b`: row rotation (typically 0)
	- `c`: x-coordinate of the upper-left corner of the upper-left pixel
	- `d`: column rotation (typically 0)
	- `e`: pixel height (n-s pixel resolution, negative value for north-up images)
	- `f`: y-coordinate of the upper-left corner of the upper-left pixel
	**Coordinate convention:**
	The transform operates on array indices where `(0, 0)` is at the **top-left corner** of the top-left pixel, and `(width, height)` is at the bottom-right corner of the bottom-right pixel. The center of the top-left pixel is at `(0.5, 0.5)`.
	This follows the GDAL geotransform and Python's Affine library convention.
	Note: Rasterio's `xy()` and `rowcol()` methods automatically add/subtract 0.5 to convert between pixel coordinates and corner coordinates. For example, `transformer.xy(0, 0)` is equivalent to applying this transform to `(0.5, 0.5)`, giving the coordinate at the center of the first pixel.

[maxrjones]

#9 intended to address this issue. I'll add you to this organization so that I can request a review from you

[kylebarron]

I think this issue is still separate. #9 looks like it's just being explicit about i meaning column index and j meaning row index. That looks like a beneficial improvement about being explicit.

But there's separate text that explains (0, 0) as the top-left corner:

spatial/README.md

Line 157 in 59dd7f4

The transform operates on array indices where `(0, 0)` is at the **top-left corner** of the top-left pixel, and `(width, height)` is at the bottom-right corner of the bottom-right pixel. The center of the top-left pixel is at `(0.5, 0.5)`.

this is commonly true but not required to be true unless we added more validation to the spec to require the e of the affine to be negative.

[maxrjones]

I think this issue is still separate. #9 looks like it's just being explicit about i meaning column index and j meaning row index. That looks like a beneficial improvement about being explicit.

But there's separate text that explains (0, 0) as the top-left corner:

spatial/README.md

Line 157 in 59dd7f4

The transform operates on array indices where (0, 0) is at the top-left corner of the top-left pixel, and (width, height) is at the bottom-right corner of the bottom-right pixel. The center of the top-left pixel is at (0.5, 0.5).
this is commonly true but not required to be true unless we added more validation to the spec to require the e of the affine to be negative.

you're right that this is distinct. I accidentally linked the wrong PR in my response; #11 is the one that actually relates to this language. I will improve #11 by using your suggested language.

[maxrjones]

just to confirm, are you referring to top-left in array index space or world space? In index space it should always refer to the top-left corner; in world space it would not.

[kylebarron]

Right, you're right to bring up that distinction.

I'm not sure I understand Zarr well enough, but it makes sense that Zarr might force the index space origin to be top left? Then the text can just clarify between pixel-space and world space.