[mapguide-users] Unmanaged SHP File Locations

[Zak James]

There may be efficiencies to be gained in the provider, but there are
some limitations that don't have easy solutions.

There are no attribute indexes for shapefiles so a lookup in a large
file is going to be slow.

Pointing at a directory of shapefiles is like pointing at one big data
source with many feature classes. It may be convenient during
development, but for production you will want to reference specific
shapefiles or at least break down the large directory into smaller
sets. I'm pretty sure managed shapefile feature sources are one per
directory.

If an unmanaged shape feature source draws more slowly than a managed
one, it's worth checking that the shx file is present and valid.

zak

On 5/25/07, Andy Morsell <amorsell at spatialgis.com> wrote:
>
>
> First, I love the unmanaged resource concept and will most likely deploy
> most future MGOS applications this way.
>
> But, similar to Chris' problems, I have discovered that displaying tooltips
> from unmanaged shape files causes a much more significant performance hit
> and delay.  In my case, I have a 150 MB parcel polygon shape file for a
> county.  In the unmanaged case, each tooltip AJAX fetch spikes the CPU with
> mgserver.exe at 100% for a couple of seconds.  Doing the same with the exact
> same shape file in a managed state (not converted to SDF at load time), the
> CPU will only hit 25% or less and responds much more quickly.
>
> Further, I discovered that the more unmanaged data in a map, the slower the
> tooltip response is for all layers.  For instance, if I add another 7 or so
> layers (like streets, water bodies, etc) to the map, when I float over a
> parcel polygon it can take up to 10 seconds for a tooltip response during
> which time mgserver is cranking away.  So, I'm not sure what it's doing at
> that point.  All of these additional layers are all in the same unmanaged
> data source folder.
>
> I went ahead and loaded all of the shape files into the repository and
> created a duplicate map pointing to the new managed feature sources.  This
> map behaves fine with tooltip fetches consuming 25% of a single CPU and very
> quick response time.  So, this seems to confirm that the more unmanaged
> feature sources in a map (at least from the same directory), the larger the
> performance hit and the slower the map responds to requests.
>
> I have appended this information to the TRAC ticket that Chris started
> earlier today.
>
>
> Andy Morsell, P.E.
> Spatial Integrators, Inc.
> http://www.SpatialGIS.com
>  ________________________________
>  From: mapguide-users-bounces at lists.osgeo.org
> [mailto:mapguide-users-bounces at lists.osgeo.org] On Behalf
> Of Chris Gountanis
> Sent: Friday, May 25, 2007 7:52 AM
> To: 'MapGuide Users Mail List'
> Subject: [mapguide-users] Unmanaged SHP File Locations
> Importance: High
>
>
>
>
>
>
> Why do unmanaged FeatureSources respond slower as more files get added to
> the directory location? We have a FeatureSource called SHPDefualt for
> example. The zooms take longer as well as other functions. It seems when you
> query a Feature Source is does not hit the DBF you want directly it seems to
> fiddle with everything in the unmanaged directory. We love the concept of a
> folder that contains all SHP files. One location is great for batch
> processes and great for editing new layers. It is just simple for customers
> to understand. For sure easier to back up and recreate. Will this always be
> a performance killer?
>
>
>
>
>
> Is this a bug? Will this be fixed soon?
>
>
>
>
>
> This really takes the complication out of knowing what the heck is going on
> in the repository. Here is XML Example:
>
> <?xml version="1.0" encoding="utf-8" ?>
>
> <FeatureSource
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> xsi:noNamespaceSchemaLocation="FeatureSource-1.0.0.xsd">
>
> <Provider>OSGeo.SHP</Provider>
>
> <Parameter>
>
> <Name>DefaultFileLocation</Name>
>
> <Value>C:\SHPFILES</Value>
>
> </Parameter>
>
> </FeatureSource>
>
>
>
>
>
>
>
>
> Chris
>
>
> _______________________________________________
> mapguide-users mailing list
> mapguide-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-users
>
>


-- 
Zak James
Applications and Software Development
DM Solutions Group Inc.
http://www.dmsolutions.ca