Chris,
Do keep me in the loop on what you find out.
I think it's a fair assumption that Geoserver will only return the "boundedBy" value if the feature's geometry is included in the returned properties. Let's put this another way: If you want the "boundedBy" value to appear, SOMETHING has to query each feature's geometry. Even if the geometry doesn't make it all the way back to the output XML, it's still moving from the DB to the application in order to do such a calculation.
Now the above statement is true in GENERAL, but might not be true for SDE. I have to check, but it's possible that SDE allows you to very cheaply calculate the bounding box of a feature/features without actually fetching the entire geometry (there might be a pre-calculated bbox stored in that linked F_XXX table). If so, I can look at the geoserver/geotools code and see how and why geoserver isn't returning the boundedby for that query.
If the problem is a general one, then the solution will involve justin and chris h. I.e., if geoserver ACTIVELY disables the boundedBy element when it notices no geometry attribute, then the solution is in geoserver-architecture land.
If, on the other hand, geoserver asks each feature for its bounding box and the feature returns "-1" (i.e., too expensive to calculate) then it's possible that I can massage the ArcSDE connector to do something smarter in this case (and assuming that SDE does give us cheap feature boundedBy operations).
I'll poke a bit more. I've assigned the issue to me, but if Justin or someone on the gs-dev list can answer the question about how GS determines whether or not to include the boundedBy info, that would give me a head start.
--saul
-----Original Message-----
From: chris [mailto:chris@anonymised.com]
Sent: Tue 2/27/2007 8:27 PM
To: Farber, Saul (ENV)
Cc: jdeolive@anonymised.com; cholmes@anonymised.com
Subject: Re: JIRA: GEOS-927 -- ArcSDE column type handling
Hi Saul, thanks for your reply. It did make sense despite what you might have thought 
I appreciate how difficult it must be to interact with a black box such as SDE.
Unfortunately using a FID filter will not solve our problem. I think my initial report didn't clarify things enough so i'll give a bit more info (longer email alert),
For SLIP we have various use-cases we are looking at for our WFS service(s). Beyond the typical "viewing" and basic filtering, we need to cater for the common Search and zoom to feature extents. This will be arguably one of the more important use-cases because it will allow any application to use WFS for searching even if it doesn't support the viewing of the returned GML (eg. Take me to x1,x2,y1,y2 and then just bind to our WMS)
eg. Search for a Locality name of "Blah*", 20 results are returned, user can click each result to zoom to feature extents.
On this specific use-case, the great thing about Geoserver is that you can choose to not return the feature geometry which makes the responses lightning quick.
The example in jira obviously uses a spatial extent filter but you get the idea on what we are trying to achieve.
<wfs:GetFeature service="WFS" version="1.0.0" maxfeatures="10" outputFormat="GML2" xmlns:topp="http://www.openplans.org/topp" xmlns:wfs="http://www.opengis.net/wfs" xmlns:ogc="http://www.opengis.net/ogc" xmlns:gml="http://www.opengis.net/gml" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.opengis.net/wfs http://schemas.opengis.net/wfs/1.0.0/WFS-basic.xsd">
<wfs:Query typeName="slip:LGATE-008">
<wfs:PropertyName>NAME</wfs:PropertyName>
<ogc:Filter>
<ogc:BBOX>
<ogc:PropertyName>GID</ogc:PropertyName>
<gml:Box srsName="http://www.opengis.net/gml/srs/epsg.xml#4283">
<gml:coordinates>115.777,-31.916 115.79,-31.897</gml:coordinates>
</gml:Box>
</ogc:BBOX>
</ogc:Filter>
</wfs:Query>
</wfs:GetFeature>
This query results in,
<wfs:FeatureCollection xsi:schemaLocation="http://www.openplans.org/topp http://beta.landgate.com.au:80/geoserver/wfs/DescribeFeatureType?typeName=topp:SDE.W_LAND_ADM_LGAS_VIEW http://www.opengis.net/wfs http://beta.landgate.com.au:80/geoserver/schemas/wfs/1.0.0/WFS-basic.xsd">
<gml:boundedBy>
<gml:Box srsName="http://www.opengis.net/gml/srs/epsg.xml#4326">
<gml:coordinates decimal="." cs="," ts=" ">115.74991083,-31.96271134 115.89353163,-31.84201272</gml:coordinates>
</gml:Box>
</gml:boundedBy>
<gml:featureMember>
<topp:SDE.W_LAND_ADM_LGAS_VIEW fid="SDE.W_LAND_ADM_LGAS_VIEW.436">
<gml:boundedBy>
<gml:null>unknown</gml:null>
</gml:boundedBy>
<topp:NAME>STIRLING, CITY OF</topp:NAME>
</topp:SDE.W_LAND_ADM_LGAS_VIEW>
</gml:featureMember>
<gml:featureMember>
<topp:SDE.W_LAND_ADM_LGAS_VIEW fid="SDE.W_LAND_ADM_LGAS_VIEW.1095">
<gml:boundedBy>
<gml:null>unknown</gml:null>
</gml:boundedBy>
<topp:NAME>CAMBRIDGE, TOWN OF</topp:NAME>
</topp:SDE.W_LAND_ADM_LGAS_VIEW>
</gml:featureMember>
</wfs:FeatureCollection>
As you can see, boundedBy is unknown for both features. Yes, we do have the feature extents option checked :). Looking at the Geoserver log,
INFO: No FID attribute was contained in your query. Appending the discovered one to the list of columns to be fetched.
Initially, i translated this into Geoserver needing the GID.FID propertyname specified so it could calculate the extents. Thinking about things further - this might not be the case. This lead me to believe that perhaps Geoserver can not calculate the extents off SDE tables, but if you use the same query but drop the <wfs:PropertyName>NAME</wfs:PropertyName> constraint, Geoserver returns all attributes, feature geometry PLUS the boundedBy extents!
<gml:featureMember>
<topp:SDE.W_LAND_ADM_LGAS_VIEW fid="SDE.W_LAND_ADM_LGAS_VIEW.436">
<gml:boundedBy>
<gml:Box srsName="http://www.opengis.net/gml/srs/epsg.xml#4326">
<gml:coordinates decimal="." cs="," ts=" ">115.74991083,-31.93852352 115.89353163,-31.84201272</gml:coordinates>
</gml:Box>
</gml:boundedBy>
...
Now i've had longer to take a look at whats going on - i think its fair to say that the boundedBy element can only be generated if the feature geometry is requested aswell. If this is true, it will be unfortunate for our situation in terms of performance. Many of the common searches such as on Administration boundaries could contain 200kb+ of geometry which is a very large overhead if most just want the extents to formulate a WMS request. GML2-GZIP is an option but in any case, the overhead remains.
I will digest things further, apologies for the initial tracker as it seems the issue is ill-defined.
Regards,
Chris
On Tue, 27 Feb 2007 10:35:11 -0500, "Farber, Saul \(ENV\)" <Saul.Farber@anonymised.com415...> wrote:
Chris,
Hey there, my name is Saul Farber and I'm one of the developers of the
geotools arcsde plugin code. I've been looking at the JIRA bug you filed
(here: http://jira.codehaus.org/browse/GEOS-927) and trying to get a
handle on how to fix your problem.I wrote this long email, and realized you may just be looking for a short
anwser. So here's the short answer:If you want to query an FID on a geoserver featuretype use a FeatureID
filter. Like this one.<Filter xmlns="http://www.opengis.net/ogc">
<FeatureId fid="SCHEMA.TABLENAME.412" />
</Filter>Here's a qualification to the short answer: If your arcsde featureclass
has declared an SE_ROWID_COLUMN_NAME for its business table, this won't
work (it won't go to the SHAPE.FID field like I think you want).Here's the long answer that I originally typed about how to figure out
whether your FID filter is actually going to work. It can be safely
skipped if you're uninterested!Here's a bit about how ArcSDE handles 'FID' columns. ArcSDE has at least
two ways of coming up with a unique 'featureid' for a given row in a
spatial table.Method #1: Use the declared "rowid" field. ArcSDE allows a table to
declare that a particular column is the "rowid" column for that table.
RowID columns are essentially primary key columns. Can't be null, can't
duplicate values...etc. They can be managed by the user (so when you
insert something you have to deal with sequence/uniqueness yourself) or
they can be managed by SDE (leave that value blank when you insert, it
will fill in an appropriate one from a sequence for you).When Geoserver starts up and loads the configuration for a particular SDE
table, it inspects the table to see if there's a registered "rowid column"
for that table. If so, it maps the FID for that featuretype onto the rowid
column.Method #2: Use the foreign key value of the spatial field (usually called
SHAPE, but can be called whatever you like). The spatial field is actually
an integer foreign key into a seperate "F_###" table, which has a LONG_RAW
(or BLOB) which stores the actual geometry...along with some
pre-calculated values like area, perimeter, etc. So if your business
table row looks like this:ROADNAME: Main SUFFIX: St. SHAPE: 4
Then somewhere there's a table called "F_XXX" (where XXX is a number) with
a row like:FID: 4 AREA: 0 PERIMETER: 10 SHAPE: <LONG_RAW>
When geoserver starts up, if it can't do method #1 (because there's now
ROWID field registered for that table) then it will fall back to this
method. It will map the FID for that featuretype onto the value of the
TABLE.FID in that SDE featureclass.Here's the confusing part: ArcSDE allows you to reference fields in the
linked F_XXX table by using a 'dot'. So you can generally query ArcSDE
for the area of a shape by using "BUSINESS_TABLE.AREA" This doesn't work
from Geoserver, however.We *do* however, support the special case of the TABLE.FID column, but
only when Method #2 has been engaged. So if you need to query the
TABLE.FID column, use an FIDFilter and the query will be generated
correctly (TABLE.FID).Like this one:
<Filter xmlns="http://www.opengis.net/ogc">
<FeatureId fid="SCHEMA.TABLENAME.412" />
</Filter>Let me know if any of this is helpful.
--saul