FDO Shape Provider

[jacklloyd]

When creating a data source using the Shape FDO provider, there is an option to select either a file or a folder. My preference is to use the folder option and point it at a folder where all of my Shape files are, instead of having 100+ individual data sources (1 for each Shape file). When I use the folder option, MGE Studio times out when I try and create a new layer using the "folder" based data source. I also noticed that something is creating IDX files for each Shape file. Is there a known problem trying to reference multiple Shape files from a single Shape FDO data source? I'm trying to establish an easy way to keep the data for the current, and I thought updating Shape files would be the best approach, but maybe not. Any suggestions?

[jacklloyd]

Playing with this a little I've come to the conclusion that MGE, or maybe it's Studio, doesn't like folders with several (not sure how many yet) Shape files represented as a single FDO Shape datasource. All of the Shape files are in the same projection. They range in size from single features to several hundred thousands of features. Is there a know limitation on the number a Shape files a single FDO datasource can access? Is there a know limit of how many Shape files a single FDO datasource can access without effecting performance?

[Anonymous]

jlloyd wrote:
> Playing with this a little I've come to the conclusion that MGE, or maybe it's Studio, doesn't like folders with several (not sure how many yet) Shape files represented as a single FDO Shape datasource. All of the Shape files are in the same projection. They range in size from single features to several hundred thousands of features. Is there a know limitation on the number a Shape files a single FDO datasource can access? Is there a know limit of how many Shape files a single FDO datasource can access without effecting performance?

You may find this ticket over on MapGuide Open Source issue tracker
interesting/useful:

http://trac.osgeo.org/mapguide/ticket/175

MGE 2008 is equivalent to MGOS 1.2, and MGE 2009 is (more or less)
equivalent to MGOS 2.0.

Jason

[jacklloyd]

Thanks Jason, I'll check it out. I'm really struggling with MGE. Having been a MG 3x to 6.5 shop for over 10 years, we're trying to look at MGE to begin trying to migrate. Every time I try, things like this throw me a curve and I just want to bag MGE. It's really frustrating.

[Anonymous]

jlloyd wrote:
> Thanks Jason, I'll check it out. I'm really struggling with MGE. Having been a MG 3x to 6.5 shop for over 10 years, we're trying to look at MGE to begin trying to migrate. Every time I try, things like this throw me a curve and I just want to bag MGE. It's really frustrating.

Yeah, it's absolutely different technology, and in some ways MapGuide
6.5 is still a better performer than MapGuide OS/Enterprise are. Part
of this is software maturity, and part is the change in architecture.

I'm pushing forward with MGOS because with the 2009/2.0 you get a lot
more out of the box than you did with 6.5, the capabilities in the
native API are far more than you could do with the 6.5 mish mosh, and
you don't have to deal with annoying high-support-load browser plugins
unless you really really want to 🙂

Jason

[jacklloyd]

I'll keep working with it too. MG 6.5 has served it's purpose far beyond my expectations for it's usefulness, but sooner or later, Microsoft will break it for good with a SP or patch. We need to move forward. I agree that MGE/MGOS have far superior capabilities and it's just a matter of time before the product matures. I've downloaded MGE 2009 from the ADN site and will give it a try. Thanks Jason.