Testing Infinite Scenarios

I have been involved with implementing integration into a mapping service.  I am thankful we were not responsible for testing the accuracy of the third-party GIS (Geographic Information System) service itself, but only the integration of the service with our solution.

However, in testing we did notice a few problems with some of the information we were receiving.  Some of our client properties were not displayed correctly.  They were *close*, but not exact.

When I read this article yesterday, I was reminded of an anxiety I had when I tried to place myself in the shoes of those implementing and testing the GIS itself.

Apple Map flaw results in drivers crossing airport runway

As test engineers know, most test configuration matrices are massive (exponentially affected when adding new configurations), but the GIS testing poses a truly staggering challenge.  Nearly infinite scenarios.

In these times, I use my handy-dandy guide to prioritizing test cases:

1. Do an equivalence analysis (what configurations/scenarios are the same for testing purposes)
2. Do a risk/impact analysis (what happens if something goes wrong?  do people die?  is revenue impacted?)
3. Do a change set analysis (what has recently changed?)
4. Prioritize your configurations (what are the most common configurations?)
5. Prioritize your functionality (what is the most commonly used functionality?  usage statistics are very handy here)
6. Identify the complexity and time-to-test of the different configurations (prioritize complex tests lower, all other factors being equal)

However, I feel like something is missing in my list above, with regards to this particular GIS problem.

How would you approach GIS testing?