Opened 9 years ago

Closed 6 years ago

#740 closed defect (fixed)

GETSPATIALCONTEXTS and GDAL always returns default extents

Reported by: crispinatime Owned by:
Priority: medium Milestone: 2.2
Component: Feature Service Version: 2.2.0
Severity: critical Keywords:
Cc: External ID:

Description

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>
...

Attachments (2)

GDALProvider_493.zip (112.3 KB) - added by jng 7 years ago.
GDAL Provider dlls (for FDO 3.5 with patch for FDO ticket 493)
GRFPProvider_FDO35_MGOS22_x64.zip (110.8 KB) - added by crispinatime 6 years ago.
GDAL Provider dll 64-bit (for FDO 3.5 with patch for FDO ticket 493)

Download all attachments as: .zip

Change History (15)

comment:1 Changed 9 years ago by 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.

comment:2 Changed 9 years ago by 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.

comment:3 Changed 9 years ago by 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.

comment:4 Changed 9 years ago by 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;

comment:5 Changed 9 years ago by 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?

comment:6 Changed 9 years ago by 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!

comment:7 Changed 9 years ago by jbirch

Resolution: invalid
Status: newclosed

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

comment:8 Changed 7 years ago by zspitzer

Milestone: 2.12.2
Resolution: invalid
Severity: majorblocker
Status: closedreopened
Version: 2.0.22.2.0

re-opening

comment:10 Changed 7 years ago by zspitzer

Severity: blockercritical
Summary: GETSPATIALCONTEXTS and GDAL Always Returns Default ExtentsGETSPATIALCONTEXTS and GDAL always returns default extents

Changed 7 years ago by jng

Attachment: GDALProvider_493.zip added

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

comment:11 Changed 7 years ago by 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.

Changed 6 years ago by crispinatime

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

comment:12 Changed 6 years ago by 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.

comment:13 Changed 6 years ago by jng

Resolution: fixed
Status: reopenedclosed

Confirmed on 64-bit as well. Closing

Note: See TracTickets for help on using tickets.