Hi, working on the new JDBCDataStore I found the necessity to store the native SRID of the geometry columns into some data structure, per feature type and descriptor.
The necessity comes out from the observation that various spatial databases pretend the data inserted to match the srid declared for the column (Oracle and in some configuration PostGIS do). Now, the srid might be something GeoTools is not able to parse into a CRS, so we need to store it somewhere to force the proper value on geometry insertion/update. Now, the most natural place seems the GeometryDescritor userData structure, using a NATIVE_SRID key. What do you think? There are a few decisions to be made. How does one set that field? We could have SimpleFeatureTypeBuilder.add(name, binding, srid) add the value. Unfortunately that would blow up with an SRID CRS.decode cannot handle (that's a bug and has to be fixed, spatial databases such as Oracle have plenty of srid codes that are not in the EPSG database). As an alternative, we could expose a SimpleFeatureTypeBuilder.setAttributeUserData(Object, value) that piles up the user data attribute for the next attribute. I'm ok with both of them Where do we declare NATIVE_SRID? In JDBCDataStore? If that's the sole user of that user data, it may be a good place. Yet I have the impression this field might be useful for other data stores as well. GeometryDescriptor then? Ugh... that would be a GeoApi change. Any better idea? Cheers Andrea ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
