Make CRS parsing of GTI:index.parquet consistent with STACIT:items.json

[scottyhq]

Feature description

I was expecting that STACIT and GTI drivers would recognize a STAC item's CRS in the same way, but this is currently only true if an item uses proj:epsg.

For the STAC projection extension, it's possible to specify proj:projjson and proj:wkt2 (and proj:epsg has been deprecated in favor of proj:code... I see those changes for STACIT are being worked on here #10773).

If I understand correctly, the STACIT driver chooses the CRS with the following order (1. epsg code, 2. wkt2, 3. projjson)

gdal/frmts/stacit/stacitdataset.cpp

Lines 221 to 237 in 42ca02c

	auto oProjEPSG = GetAssetOrFeatureProperty("proj:epsg");
	std::string osProjUserString;
	if (oProjEPSG.IsValid() && oProjEPSG.GetType() != CPLJSONObject::Type::Null)
	{
	osProjUserString = "EPSG:" + oProjEPSG.ToString();
	}
	else
	{
	auto oProjWKT2 = GetAssetOrFeatureProperty("proj:wkt2");
	if (oProjWKT2.IsValid() &&
	oProjWKT2.GetType() == CPLJSONObject::Type::String)
	{
	osProjUserString = oProjWKT2.ToString();
	}
	else
	{
	auto oProjPROJJSON = GetAssetOrFeatureProperty("proj:projjson");

But the GTI driver currently does not read projjson or wkt2:

gdal/frmts/gti/gdaltileindexdataset.cpp

Lines 1171 to 1178 in 42ca02c

	if (bIsStacGeoParquet && !pszSRS && !pszResX && !pszResY && !pszMinX &&
	!pszMinY && !pszMaxX && !pszMaxY &&
	((iProjEPSG = poLayerDefn->GetFieldIndex(
	CPLSPrintf("assets.%s.proj:epsg", osAssetName.c_str()))) >= 0 ||
	(iProjEPSG = poLayerDefn->GetFieldIndex("proj:epsg")) >= 0) &&
	((iProjTransform = poLayerDefn->GetFieldIndex(CPLSPrintf(
	"assets.%s.proj:transform", osAssetName.c_str()))) >= 0 ||
	(iProjTransform = poLayerDefn->GetFieldIndex("proj:transform")) >= 0))

Additional context

Here is a valid STAC item without epsg, but with wkt2:
For example, here is a STAC Item without an EPSG code:
https://landsatlook.usgs.gov/stac-server/collections/landsat-c2l2alb-sr/items/LC09_L2SP_062047_20241216_20241217_02_A1_SR

And here is a valid item with projjson:
https://raw.githubusercontent.com/uw-cryo/stv-aux-data/refs/heads/main/CO_WestCentral_2019_A19/utm12/USGS_1M_12_x76y426_CO_WestCentral_2019_A19.json

The docs are currently accurate in that the GTI driver only seems to look at proj:epsg and proj:transform, but it would be great if these similar drivers worked consistently with the CRS parsing.

It can make use of fields proj:epsg and proj:transform from the Projection Extension Specification, to correctly infer the appropriate projection and resolution.

[rouault]

see #11514