While OGR is a neat provider, we did experience certain issues with it that makes me feel that for some data sources it might not be the best solution. We would basically get unreliable results when doing queries against it, which isn't really good when users are trying to run queries on their data for decision-making purposes.
With OGR on MapInfo (TAB) we would get bad results when applying both a spatial filter and attribute filter at the same time. On a MgFeatureQueryOptions we would call up SetSpatialFilter and then SetFilter and we would get invalid results. The same code that would do the equivalent of the SetFilter on a C# DataTable would work just fine. Although if we do start focusing more on making sure the OGR provider is tested and validated under multiple spatial data types. I do wonder if using an abstraction layer (OGR) on top of another abstraction layer (FDO), we might have a harder time debugging issues and getting better performances. I don't have any metrics at the moment, but I could likely work on some if it's something that could be useful. -- Sent from: http://osgeo-org.1560.x6.nabble.com/MapGuide-Users-f4182607.html _______________________________________________ mapguide-users mailing list mapguide-users@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/mapguide-users