0

I've been asked to create a feature class by unioning 18 polygon feature classes together, and retaining only certain attributes. The goal is to have a single feature class that can be queried once to get multiple attributes (e.g. zip code, technician territory, municipality, county), instead of having multiple feature classes that each need to be queried.

The user plans to feed a lat/long into some .NET application and get information about that location -- he can get the ~20 attributes he needs querying individual features, but would like a "one stop" solution. Apparently the data is taking up to ten seconds to pull from a number of map services, which is unacceptably long to the group who needs the application, and sending only one request would significantly improve performance.

The technical process of creating this feature class isn't really a problem. However, I am concerned about it from a "best practice" perspective -- it's a bulky bunch of polygons, and we are duplicating data that must be constantly re-created to capture any changes in the source data. Again, that's not a technical issue, I can run this as a scheduled task... but the potential time lag between updates makes me slightly uncomfortable about the accuracy of this new layer's results.

So my concern is really whether this is a good idea, and whether this is a typical solution for GIS web applications that query multiple layers simultaneously.

Are there some alternative ideas that I can propose that would quickly provide the necessary data, while letting us maintain our ZIP code, county, territory, etc. polygons as unique feature classes that aren't duplicated somewhere else?

I am thinking of something that's sort of like a "view" in a non-spatial database, holding only the particular attributes he's interested in but including a spatial context since it's location-based -- but I don't have enough database background to know whether that's possible.

The data is in an ArcSDE database, and he's querying Esri map services through .NET (probably ArcObjects).

Improve this question
3
  • Can't post it as an answer, but it sounds like Relationship Class could be useful, that is if you have a way to join those tables together in a non-spatial manner. It is useful since it allows updates to the original files, with or without, altering other relate files.
    – dof1985
    Commented Apr 17, 2015 at 19:26
  • Unfortunately, there's little or no relationship between them aside from spatial.
    – Erica
    Commented Apr 17, 2015 at 20:41
  • Union should "break" features due to intersections, thus might ater all require several queries (if those or spatial queries, i.e. on-click); Spatial join might be a better approach, but might bear the cost of some data loss if there is no spatial relation between some features in the database.
    – dof1985
    Commented Apr 17, 2015 at 20:44

1 Answer 1

Reset to default
1

Certainly from a desktop perspective using a unioned feature class lets you calculate the overlap relationships on the way in rather than on the way out thus providing faster access to those overlap relationships when you need it. I cannot see why it would be any different when that data is exposed as a web service. I think you should prototype and see if your idea meets your requirements.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.