MG Sutdio 2008 and Oracle Spatial

[Anonymous]

Hi all,

i have an issue that i can´t get resolve.

I have a dataset in an Oracle database with several spatial enabled tables. Most of the geometries are Multipoint, Multipolygon and polyline.

I can read all tables, and see it on Map, except one, a point (GTYPE 2001) layer.

When i try to load it into a layer i get this error: Reset to defaults? You are about to change to an incompatible data source....

This error is driving me mad because there is no explanation for it. The layer is built based in geographic coordinates of GPS points, about 300 of them. I have other tables with other point data and i do not have this issue! They are the same GTYPE geometries, same SRID, different attributes.

Does any one as knowledge of some type of solution to resolve this issue?

Any help will be appreciated, thanks.

Tiago

[Anonymous]

Hi again,

after a long struggle i have found the issue. The issue is a Autodesk FDO Provider for Oracle issue. Don't know why the connector cannot read the geographic data on the table and stops showing the objects.

Solution: Use the KingOracleProvider (version 0.73). It´s faster and i can see all my data, that was tested without problems. Another good thing - it's FREE!

I do think Autodesk should considered reviewing the 3.2.0 provider in MGE 2008.

[dswilson]

Sorry Tiago I had no ideas on what could be wrong with the data and hence I didn't respond initially. I assume this is native Oracle spatial data and not an FDO datastore? The only thing I can think to validate is the spatial index and that the USER_SDO_GEOM_METADATA records are correct, particularly the bounds.

Are you able to send us a sample of the table that fails? I suspect if you dump the table it will be too large (even zipped) to attach, but you might try. If not what is your email address so that I can get in touch?

Regards,
Dave

[Anonymous]

Hi Dave,

the data are native Oracle Spatial data. I'm not allowed to give the data, company policy, but i will do my best to detail the procedure.

The dataset is a 263 records a table with the following structure:

CREATE TABLE TABLEA
(
CODE VARCHAR2(10 BYTE) NOT NULL,
LOCAL VARCHAR2(50 BYTE) NOT NULL,
LCO_LAT NUMBER(10,6),
LCO_LONG NUMBER(10,6),
CORD_M NUMBER(10,2) NOT NULL,
CORD_P NUMBER(10,2) NOT NULL,
GEOM MDSYS.SDO_GEOMETRY
)

very simple i believe.

In the fields LCO_LAT and LCO_LONG i have latitude and longitude coordinates. GEOM field has the geometry. SRID is 4274, GTYPE 2001, and the spatial index was generated using layer_gtype= MULTIPOINT.

There was no issues concerning the SDO_GEOM... extent neither the SPATIAL INDEX.

Geometry generation:

Geometry was generated using an update script:

UPDATE TABLEA set GEOM =
MDSYS.SDO_GEOMETRY(
2001,
4274,
MDSYS.SDO_POINT_TYPE(LCO_LONG, LCO_LAT, NULL),
NULL,
NULL
);
commit;

Quite simple i think.

Procedure A:

The firs procedure was generate the geometries, build the spatial index and inserting the USER_SDO... TABLEA data. The data didn't show, what was very awkward. Then, after updating to null the GEOM field in the table, i tried to generate geometries by groups of ten points, rebuilding after that the spatial index and extention.

I've found that 13 points ware blowing up the layer. When using MG Studio 2008 i could in preview zoom in and zoom out, and see 250 ok points without a problem! But if i inserted the other 13 in the table, in the preview the layer would not show all of records. Very strange indeed.

Procedure B:

After analyzing the 13 points, i didn't found any kind difference in data format from the other 250 points. So i tried to create a new table, different table name, same structure.
After inserting the data, I've generate index and extent, in the data preview in MG Studio all the data appeared in the window. I thought that the issue was solved....but no, using zoom in or zooming out the data in the layer becomes invisible, i found myself clueless!

Procedure C:

In the time that i was testing the data preview, i saw that the provider didn't identified the geometry type of my geographic data in the table. This is although other data displayed has polygon, line or point, the layer was identified has a complex/compound layer and not, point, line or polygon layer!
Seeing this problem i tried using the King Oracle Providers, release 0.73. What i found was that the data in both the tables, the original and the test table i have created before was previewed by the MG Studio, the zooming was working and the provider identified the GTYPE data of the table has point, line or polygon data. Indeed i found that was faster retrieving the data and being displayed in the preview of MG Studio 2008.

Conclusion:

I do think that this can be a provider issue, what i don't understand is why some simple data, point data, would generate so many problems, because i had heavy polygon geometry and that issue didn't happened. The GTYPE was resolved with the King Oracle Provider.

Hope this detail helps,
Tiago

[dswilson]

Thanks Tiago for a very detailed response.

I'm very surprised as you were that simple point geometry would cause problems. Since there is obviously an issue with the 13 points is there anything unique about them compared to the other records? I understand you can't share the dataset, but can you provide 1 or 2 records at least that fail? The data is effectively meaningless anyway because there is nothing to put it in context. Without finding some samples of points that fail this is going to be very hard to debug. The table definition helps certainly, but I could enter points forever and not necessarily encounter the bug.

I guess another question to ask is what patch level is the Oracle instance at? We have seen once instance where an Oracle bug sometimes prevents data from displaying.

I'm wondering if there is something about the magnitude of the points or the number of decimal places that makes then stand out?

Regards,
Dave

[Anonymous]

Dave,

there is nothing special about those points. They are similar with the rest of the sample in decimal places and so on.

In attach there are the 13 points i told you.

I'm usig Oracle 10gR2, with ODAC 10.2.0.2.

good work
Tiago

[dswilson]

I can't seem to reproduce the problem with MGE 2008 and the Autodesk provider and the info you supplied.

Dave

[Anonymous]

I don't have any clues. For the present time the solution i found fits me.

Did the MG Studio 2008 identified the geometries as points or has compounds (point, line, area)?

Tiago

[dswilson]

The way the FDO provider is implemented it always reports an Oracle FeatureClass as being compound even if it only contains a single geometry type.

Dave