I have a test application modeled on the Getting Started example for displaying SQL Server items. I can flip a switch between using MsSql2008FeatureLayer, and using custom classes derived from FeatureLayer and FeatureSource. The feature source class overrides GetAllFeaturesCore(), which queries the geometry in the database tables and constructs features accordingly. If I use the custom classes, all of the layers are displayed. If I use the MsSql2008FeatureLayer, some of the layers are displayed, and some are not. The features are loaded, the count is correct, the boundaries are correct, the visible flag is set, there is just no evidence on the screen. Aside from the layer and source classes, everything else is identical, e.g. zoom levels and styles. I am not seeing in either the code or the database what the difference might be between layers that are displayed and layers that are not. Do you have any troubleshooting suggestions?
MsSql2008FeatureLayer not displayed
Problem solved. Turns out that some tables have geometry with SRID of 0 and some tables have geometry with SRID of 3395. In the layer constructor, providing one of these SRIDs results in layers with the other SRID not being displayed. Providing no SRID results in no layers being displayed. Which doesn’t necessarily seem like ideal behavior. Maybe there should be a generic option?
Katherine,
I hope I do not misunderstand anything. What you are trying to do now is try to show all the features in several SQL tables in one SQL feature layer instead of one table as always we have done. If so, we need to make sure all the features are in the same projection system. For example, table 1 SRID is default one 4326, while table 2 SRID is 3395, when we want to show all the features in the same projection system 3395, we have to get the features out from table1 and project them into 3395 before passing them out.
Any more questions please feel free to let me know.
Thanks.
Yale
Each layer displays one table. The trouble was that I am unfamiliar with this database, and had been informed that the SRID was 3395. When I passed 3395 into the ThinkGeo layer constructor, some layers/tables were displayed, and some were not. Upon further investigation, I determined that the SRID was actually 0 for the tables that were not being displayed, and when I passed 0 into the constructor, they were fine. This is a problem with the database, and it will be fixed. A question I have about the ThinkGeo component is that when I don’t give the constructor an SRID, i.e. use the constructor MsSql2008FeatureLayer(Connection, Table, ID), I would expect it to determine the SRID, possibly by using the first record in the table, but instead nothing is displayed. (If I create a custom source that runs a SQL query and constructs features from the SqlGeometry without explicitly providing an SRID, then everything is displayed, but this was an experiment, not standard implementation.)
Katherine,
Thanks for your post and feedback.
When an MsFeatureLayer was created without passing any constructor, we will use a default SRID value 4326 which indicates it is geodetic projection system. I remember when it is set to 0, it means it is a Geomery system instead of a Geographic system.
Any more questions please feel free to let me know.
Thanks.
Yale