Thanks Gabriel, It looks like the table has an SDE managed row id, but from the dump I got from the user it looks like it may be based on a view, would this have an effect?
I've run across cases where there were no primary keys (either because there wasn't one, or because i was a view) and null fids were used, but this is case appears to be using a valid fids since i can find features later using the fids provided by gt. In this case the primary key is the PFI column, not OBJECTID, not sure if that would make a difference. sdetable -o describe -t vmprop.property_view -s d00711 -i 5161 -u mapshare_hotspots ArcSDE 9.3 for Oracle10g Build 1206 Fri Oct 19 08:31:29 2007 Attribute Administration Utility ----------------------------------------------------- Table vmprop.property_view: Column name Attribute type Null? Length,DPs RowID Column? ------------------------------------------------------------------------------- PFI SE_STRING NOT NULL 10 BASE_PFI SE_STRING NULL 10 CENTROID_PFI SE_STRING NULL 10 GRAPHIC_TYPE SE_STRING NULL 1 FOOTPRINT_TYPE SE_STRING NULL 1 Z_LEVEL SE_STRING NULL 2 FEATURE_TYPE SE_STRING NULL 6 FEATURE_QUALITY_ID SE_STRING NULL 20 PFI_CREATED SE_DATE NULL 0 UFI SE_FLOAT64 NOT NULL 11 UFI_CREATED SE_DATE NULL 0 UFI_OLD SE_FLOAT64 NULL 11 OBJECTID SE_INT32 NOT NULL 10 SDE Set SHAPE SE_SHAPE NULL 0 We have noticed that feature collections with filters are quicker compared to feature readers with queries with other operations, could it be that one is retrieving the geometry and the other isn't? Cheers, Shaun Make sure your ArcSDE featureclass has either an SDE or USER managed ROW_ID. That's gonna be used as the primary key (a.k.a. feature identifier). When a featureclass has no column of type row id, the geometry id is used as feature id, and the feature class can't be editable. Hope that helps. Gabriel On Tue, Aug 10, 2010 at 2:29 AM, Shaun Forbes <[email protected]>wrote: > Howdy, > > I've found that the GeoTools ArcSDE plugin is forcing the return of the > shape column when using a spatial filter even when the geometry is not one > of the attributes requested in the query, and to my thinking it doesn't have > to since the spatial filtering should be being performed on the ArcSDE > server, not in GeoTools. > > Am I correct or missing something here and this is the expected behaviour? > I've tested this in 2.5.x and 2.6.x > > In my situation I'm trying to return all the values from a single attribute > column (not the shape column) that fall within a polygon, but because the > underlying feature reader and attribute reader are having to parse and build > the geometry for each feature returned (even though it's then ignored) the > performance of the iteration is orders of magnitude worse than it should be. > > String typeName = "..."; > String keyColumn = "..."; > Filter intersectFilter = ...; > Query query = new DefaultQuery(typeName, intersectFilter, new String[] { > keyColumn }); > FeatureReader<SimpleFeatureType, SimpleFeature> fr = > ds.getFeatureReader(query, Transaction.AUTO_COMMIT); > while (fr.hasNext()) { > Feature feature = fr.next(); // takes too long because it's building > geometry it doesn't need > ... > } > > It seems to me it's the org.geotools.filterFilterAttributeExtractor saying > that the SHAPE column is needed but it isn't and I can't see from there how > to alter this. > > Cheers, > Shaun
------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________ Geotools-gt2-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
