Hi,
As an introduction, I used to have a problem in making a new Geoserver
FeatureType from my existing Oracle 9i spatial table created and
maintained by MapInfo tools. Creating DataStore from the Oracle database
was successful. When trying to create FeatureType all the available
Oracel tables came to selection list of the Geoserver administration
tool. Howeever, when I selected the desired table I could not create a
FeatureType from it. Administration application gave a hint that my
spatial table maybe does not have a geometry column, or the table is
empty.
After quite a many trials with my table and smaller spatial tables I
created into the same database with "shp2sdo" utility I have learned at
least the following things:
- There has to be a record in ALL_SDO_GEOM_METADATA that corresponds to
the spatial table.
- You need to have a primary key in your data. If you create it by using
shp2sdo utility it is easiest to tell the utility to create it.
These requirements are also mentioned in the Geoserver datastore
document. This additional information would have helped me a lot:
- You do not need to have SRID value set in your data but it can be null
as well. Geoserver do not care about that value in any case. It is
enough to tell Geoserver the EPSG code to be used with the FeatureType
editor.
- If you however have SRID value in your data then you must have the
same value also in the ALL_SDO_GEOM_METADATA table. Geoserver is not
using that, so it is better to insert the correct Oracle SRID code, that
has nothing to do with EPSG codes. For Geoserver you must feed the EPSG
code with FeatureType editor.
- Your spatial data must be migrated to suit your Oracle version. That
can be done by running the Oracle procedure SDO_MIGRATE.TO_CURRENT. But
do not try to run it without dropping the spatial index first if you
have one.
In my case all the trouble I had appeared to be due to the last
requirement. Obviously our MapInfo based utilities do not write the
spatial data in a strickly correct way. I cannot say that it is always
the case with MapInfo because our programs are already old and made for
other Oracle version originally. Actually my guess is that our program
was only partly fixed for Oracle 9i some years ago, but because MapInfo
and our own application do not have any problems we have not noticed the
wrong behaviour before.
I thought that my table was OK because it had correct 4-digit SDO_GTYPE
values, but there seem to be possibly something more to fix as well. The
procedure is according to Oracle doing the following:
- SDO_GTYPE values of 4 digits are created
- SDO_ETYPE values are created
- The procedure orders geometries so that exterior rings are followed
by their interior rings, and saves them in the correct rotation
(counterclockwise for exterior rings, and clockwise for interior rings)
I suppose that in my case the reason was caused by the not correctly
ordered geometries but I am not totally sure about that.
Regards,
-Jukka-