FDO Usage Questions

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

FDO Usage Questions

Geoffrey Curtis
i have a few questions with regard to the usage and design of the FDO interfaces.

We currently have a working implementation setup and can successfully retrieve the feature class data we require, but at times the access to the information seems slow or lacking from an end-user stand point.

If it helps, this is currently with regard to the ArcSDE provider, but we may have others implemented in the future.

1.) Is there a way to query the number of feature classes?  The number of entries in a FeatureReader?

2.) Currently using the GetClassNames command returns all Class definitions within Schemas.  Is there a way to filter this to just Feature Class definitions?  The DescribeSchema command can be slow, and does more than I need initially from a UI perspective.

Without initial counts, at times i can't do more than simply throw up a Busy cursor instead of a proper progress bar or other informative UI.

3.) Are there ways to filter Feature Classes by Coordinate System?  What are the correct ways to filter Feature Classes by Extent?

4.) What are the proper ways to get the extents of a Feature Class?  Using the SpatialExtents function with the SelectAggregates command seems to work, but at times can seem to take as long as retrieving the Geometry data through the FeatureReader interface.

5.) Are Schema definitions persistent?  Accessing the GetQualifiedName method has caused a number of exceptions with methods because the parent of a FeatureClass seems to have gone out of scope after retrieving it.  It seems strange to be able to query for a FeatureClass or FeatureReader by name and not be able to rely on getting the proper qualified name back.

6.) More out of curiosity: Is there any documentation on the classes that are supposed to be treated as reference counted?  Since raw pointers are returned everywhere we have run into a couple of cases where the return value was actually not intended to be used with FdoPtr, even though it is actually derived from FdoIDisposable (the FdoProviderCollection returned from FdoProviderRegistry::getProviders() for example).  Just wanted to make sure there were not any others.

7.) Are there any other things i may have missed that could possibly improve the response times of these commands?

Given the number of back-end implementations that seem to be based on databases, some of these i would have figured to be rather simple tasks, but i am not sure if i am looking in the right place to find other alternatives to the methods we are currently using.

Thanks in advance.
Reply | Threaded
Open this post in threaded view
|

Re: FDO Usage Questions

Jackie Ng
1) Do a DescribeSchema and count the number of Class Definition elements inside. Or do a GetClassNames and count the number of items.

Feature Readers are uncountable, you have to spin through the whole reader to get a total count. Alternatives are (if the provider supports them), using the Count() aggregate function or executing an IExtendedSelect and inspect the Count property of the returned scrollable feature reader.

2) The GetClassNames API does not support filtering on class types. Only on the parent schema name (if one is given). This would actually be a nice FDO API enhancement to have actually.

3) Geometry properties of Feature Classes are tied to spatial contexts (that specify the coordinate system and extent). Such filtering would require fetching the full schema and the spatial context list and walking through the child Class Definitions for ones that match your desired spatial context. Not the ideal solution.

4) 4 ways to do it:
 1. The extents of the associated spatial context (may be a static value and not reliable)
 2. The SpatialExtents() aggregate function (the most reliable. Provider support varies)
 3. Pass through SQL (provider support varies, syntax would have to be specific to the provider)
 4. Raw spinning the feature reader (obviously slowest of the lot)

5) Not sure about this one. If the Class Definition is from a DescribeSchema call, you should be able to interrogate its qualified name. Class Definitions from other places (eg. A feature reader) are probably computed so there wouldn't be a qualified name as such.

6) Anything inheriting from FdoIDisposable is a reference counted class, though I think anything involving the FDO provider registry or the Feature Access Manager is an exception to this.

7) Given the current constraints of the FDO API, this is probably all you can do for now.

To be pedantic, ArcSDE isn't exactly a database. It's a middle-man to a backing RDBMS. So therefore the provider would have to play by the APIs and abstractions offered by ArcSDE. We can't exactly apply RDBMS-type optimizations if we have to go through a non-RDBMS middleman.

- Jackie
Reply | Threaded
Open this post in threaded view
|

Re: FDO Usage Questions

Geoffrey Curtis
Thanks for taking the time to reply.

1.) The DescribeSchema command can take ages in comparison to the GetClassNames command.  Not sure why exactly, but i definitely would like to avoid/defer the overhead we are seeing with that command if possible.

4.) Was reading some past posts that mentioned using the SQL commands to avoid some of the overhead here.  Will have to take a look and see if that will work for what i need.  For now response time would have higher priority over being generic like i wanted.

5.) Well this one was weird to me, mainly because the SchemaElement parent pointer is not reference counted.  So even if i originally got the reference through DescribeSchema, if i only hold onto the FeatureClass reference, it's parent becomes invalid afterwards.  Guess i will have to simply modify things to store the Schema pointer as well.  But having a reference to a feature class definition and it not tracking its parent Schema seems inconvenient as just because two definitions have the same name doesn't mean their definitions are in any way similar.  That means there is no way to get the original referencing Schema from any of the methods or queries that only return FeatureReader references.  Given it takes a qualified name to query for a FeatureReader when there are duplicate names, i figured it would know its Schema, but i guess again i should just keep the name around.

-

i  need to find a good reference on the supported SQL commands necessary to do what is needed.

Simple things like table retrieval and record counting is simple, and fast, as I would expect it to be (don’t know why it is so much slower through FDO).  New to the GIS related commands though so I do not know all the ones I need to access data the way I would like.

The SpatialExtents function through SelectAggregates is very slow, almost as bad as simply reading the Geometries.

If the above tests are any indication, if i can get things to work successfully through SQL i should be all set.

Thanks for the information.
Reply | Threaded
Open this post in threaded view
|

Re: FDO Usage Questions

Dan Stoica
Regarding " The SpatialExtents function through SelectAggregates is very slow, almost as bad as simply reading the Geometries." please note ArcGis doesn't have a native method to accomplish this. Therefore the provider delegates the task to the Expression Engine which is computing the extents by brute force.

In general, for FDO usage examples, I recommend checking the unit tests.

Regards,
Dan.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Geoffrey Curtis
Sent: Tuesday, June 26, 2012 9:35 AM
To: [hidden email]
Subject: Re: [fdo-users] FDO Usage Questions

Thanks for taking the time to reply.

1.) The DescribeSchema command can take ages in comparison to the GetClassNames command.  Not sure why exactly, but i definitely would like to avoid/defer the overhead we are seeing with that command if possible.

4.) Was reading some past posts that mentioned using the SQL commands to avoid some of the overhead here.  Will have to take a look and see if that will work for what i need.  For now response time would have higher priority over being generic like i wanted.

5.) Well this one was weird to me, mainly because the SchemaElement parent pointer is not reference counted.  So even if i originally got the reference through DescribeSchema, if i only hold onto the FeatureClass reference, it's parent becomes invalid afterwards.  Guess i will have to simply modify things to store the Schema pointer as well.  But having a reference to a feature class definition and it not tracking its parent Schema seems inconvenient as just because two definitions have the same name doesn't mean their definitions are in any way similar.  That means there is no way to get the original referencing Schema from any of the methods or queries that only return FeatureReader references.  Given it takes a qualified name to query for a FeatureReader when there are duplicate names, i figured it would know its Schema, but i guess again i should just keep the name around.

-

i  need to find a good reference on the supported SQL commands necessary to do what is needed.

Simple things like table retrieval and record counting is simple, and fast, as I would expect it to be (don’t know why it is so much slower through FDO).  New to the GIS related commands though so I do not know all the ones I need to access data the way I would like.

The SpatialExtents function through SelectAggregates is very slow, almost as bad as simply reading the Geometries.

If the above tests are any indication, if i can get things to work successfully through SQL i should be all set.

Thanks for the information.


--
View this message in context: http://osgeo-org.1560.n6.nabble.com/FDO-Usage-Questions-tp4982701p4983938.html
Sent from the FDO Users mailing list archive at Nabble.com.
_______________________________________________
fdo-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-users
_______________________________________________
fdo-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-users
Reply | Threaded
Open this post in threaded view
|

Re: FDO Usage Questions

Geoffrey Curtis
Thanks for the information.

In the end we ended up querying the layer table directly as mentioned in a previous post.

Though these functions appear to also support doing/calculating the same thing:
SE_layerinfo_get_envelope
SE_layer_calculate_extent
SE_stream_calculate_layer_extent

Haven't tried them yet though, since we are not using the ArcSDE interface directly, only through FDO for the moment.