GETSPATIALCONTEXTS and GDAL always returns default extents

[crispinatime]

Hi,

I have been trying to debug Maestro wondering why when a raster config resource file is built it always contains bogus extents (-10000000 to 10000000).

I finally traced through to 'GetSpatialContextInfo(...)' which has created a temporary session resource to query via the MapGuide API - as far as I can see on my layer set-ups it is GETSPATIALCONTEXTS that is at fault.

I have tested the file with GDALinfo.exe to confirm the extents are returned OK by the GDAL14.dll.

To recreate (for example) add a raster file to a GDAL composite feature source in Maestro and put a braek point in HttpServerConnection.cs at line 922 to step into the call and see the extents generated.

Or simply edit the FeatureSource in the second URL below:

C

http://localhost/mapguide/mapagent/mapagent.fcgi?OPERATION=GETSPATIALCONTEXTS
 &VERSION=1.0.0
 &SESSION=5360ba88-0000-1000-8000-001422f493b1_en_7F0000010AFC0AFB0AFA
 &FORMAT=text%2fxml
 &RESOURCEID=Session%3a5360ba88-0000-1000-8000-001422f493b1_en_7F0000010AFC0AFB0AFA%2f%2fccbeeed0-d467-41c9-a439-8d7fc84593bc.FeatureSource
 &ACTIVEONLY=1
 &LOCALE=en

Can simplify for any GDAL resource you have with the following

http://localhost/mapguide/mapagent/mapagent.fcgi?OPERATION=GETSPATIALCONTEXTS
 &VERSION=1.0.0
 &FORMAT=text%2fxml
 &RESOURCEID=Library://Test/Data/NS66.FeatureSource
 &ACTIVEONLY=1
 &LOCALE=en

Always returns extents like below (non-GDAL feature sources return good extents)

...
<Extent>
<LowerLeftCoordinate>
<X>-10000000</X>
<Y>-10000000</Y>
</LowerLeftCoordinate>
<UpperRightCoordinate>
<X>10000000</X>
<Y>10000000</Y>
</UpperRightCoordinate>
</Extent>
...

[ksgeograf]

I have spent some time debugging Maestro myself, and at that point it seemed to work. There are some test files here: ​http://trac.osgeo.org/mapguide/ticket/601

I found that GDal reports the default extents, when it should have reported an error. Can you get correct extents with the files from #601?

You may also want to try running MapGuide in interactive mode with GDal debug turned on: ​http://trac.osgeo.org/fdo/wiki/FdoGdalNotes

It will show some extra info that GDal outputs when it loads your data.

[crispinatime]

Kenneth,

Thanks - I have been watching the GDAL Open() messages in the console previously. I think it is something to do with CS overrides.

If I use one of the ECW files from 601 in Maestro the CS info on the feature source is automatically populated.

My TIF files (with TFW) do not have a CS and I think MG's default override is causing the GDAL to think there is a coord conversion and so just defaults to the extents of *XY-M* / *XY-MT*. I have tried all sorts of CS overrides but can't find one that will return the values from the TFW file!

I can't post the file here but can pass on to anyone interested.

[ksgeograf]

What do you mean by "MG's default override"? MapGuide does not use an override by default. If Maestro shows one, you can try to delete it.

[crispinatime]

Well,... if in Maestro I delete the CS on the FeatureSource, Save it and then "Test Connection" in Maestro and refresh the CS override I find that Maestro has re-populated the CS-override with a default CS even though my TIF does not have a CS...

Default :: LOCAL_CS["*XY-MT*",LOCAL_DATUM["*X-Y*",10000],UNIT["Meter", 1],AXIS["X",EAST],AXIS["Y",NORTH]]

I thought I could be clever (never a good thing) and force the following where Maestro creates the temporary resource to get the extents - and I think something like this may be required when a user has specified an override at the FeatureSource level...

ConfigUpdater.cs (after line 181)

	MaestroAPI.SpatialContextType sctThis1 = new OSGeo.MapGuide.MaestroAPI.SpatialContextType();
	sctThis1.Name = "Default";
	// sctThis1.CoordinateSystem = "LOCAL_CS[\"Non-Earth (Meter)\",LOCAL_DATUM[\"Local Datum\",0],UNIT[\"Meter\", 1],AXIS[\"X\",EAST],AXIS[\"Y\",NORTH]]";
	// sctThis1.CoordinateSystem = "LOCAL_CS[\"*XY-MT*\",LOCAL_DATUM[\"*X-Y*\",10000],UNIT[\"Meter\", 1],AXIS[\"X\",EAST],AXIS[\"Y\",NORTH]]";
	sctThis1.CoordinateSystem = "";
	MaestroAPI.SpatialContextTypeCollection sctcThis = new OSGeo.MapGuide.MaestroAPI.SpatialContextTypeCollection();
	sctcThis.Add( sctThis1);
	fs.SupplementalSpatialContextInfo = sctcThis;

[ksgeograf]

The "Refresh" button actually assigns the coordinate system overrides. It reads all the coordinate systems reported by the FeatureSource, and then "overrides" them with the samme coordinate system. This gives the user a chance to examine what coordinate systems are being reported, with a very limited chance of trouble. The name "Refresh" is misleading in this context.

I would think that the GDal provider would like the coordinate system to be the same as it reports, when creating the document. Your adjustment seems to assign a coordinate system override to the FeatureSource.

If you add your suggestions to the code, does it return the correct extents?

If so, I would think that it would be safe to try first with the current code, and if invalid coordinates are detected, use your method. Perhaps it should do the same as the "Refresh" button, but perform it on the temporary FeatureSource instead?

[crispinatime]

Hi,

You say above,

It reads all the coordinate systems reported by the FeatureSource, and then "overrides" them with the samme coordinate system.

But as the TIF file has no CS it seems the FeatureSource is assigning a default one in the return values which then gets populated into the Maestro UI.

But I think that the original point about GETSPATIALCONTEXTS not working when querying a GDAL FeatureSource with no CS (but valid bounds in a TFW file in my case) is correct!

[jbirch]

I'm going to re-open this as a GDAL provider defect.

[zspitzer]

re-opening

[zspitzer]

FDO issue - ​http://trac.osgeo.org/fdo/ticket/493

[jng]

GDAL Provider dlls (for FDO 3.5 with patch for FDO ticket 493)

[jng]

I've attached a zip containing a custom built GDAL provider with a patch I made for FDO ticket 493 applied. This was built against FDO 3.5, meaning it will only work with a MGOS 2.2 install.

Give this provider a spin and see if it solves the problem. My initial tests are promising. Rasters that previously returned default extents now returned the proper values.

[crispinatime]

GDAL Provider dll 64-bit (for FDO 3.5 with patch for FDO ticket 493)

[crispinatime]

64-bit build version of file added - FDO 3.5 for OSGeo MapGuide v2.2 x64

If can get verification on this platform then maybe this case can be closed.

[jng]

Confirmed on 64-bit as well. Closing