Increasingly, large volumes of disaggregated individual level data are
available to the analyst [see e.g. Kwan’s statement for this workshop].
Then, by employing a moderate amount of aggregation, it is possible to
derive a spatially referenced data base with a common spatial context.
This would seem to provide a platform for techniques such as multi-level
models (Kelvyn Jones et al; and Cressie’s statement for this workshop).
I would like to explore this potential question at the workshop. In my
own experience, for example, in retail trade area analysis, I have been
combining observations into blocks to provide a number of observations
of individuals with more or less common retail choice sets. These commonalties
may be exploited to great effect. In situations where a residential zone
is accessible to several alternative destinations, we may use the variations
in rates of patronage to the several alternatives to estimate the impact
of size, distance, spatial structure effects, and other commonly used explanatory
variables that are typical of the spatial interaction modeler’s arsenal.
The paper discusses techniques such as density models, interaction models,
and so on, and outlines the appropriate estimation steps needed to fit
parameters in these models. While the comments are made in the context
of a specific practical application, the relevance of these techniques
to other problems (hospital planning, participation in social programs,
and school assessment) is fairly obvious.
GIS/spatial analysis projects focus a lot of attention on discussions
of graphical user interfaces (GUI), menu layout, and ease-of-use issues.
The discussion can drift into the appearance of dialog boxes, the choices
of selection sets, and the offering of a variety of alternative objectives
and constraint formulations to the clients. This focus would make more
sense if the underlying data structures and models and algorithms were
already fully understood and worked out, but regrettably, the basic methodological
issues are still in need of intensive effort. More important that these
usability issues would be expert system support from a knowledge
base that embodies experience, best practice, and even rules-of-thumb.
For instance, when people discover spatial analysis via a GIS package,
they encounter a very steep learning curve; (e.g. gravity interaction models
in ArcInfo, traffic assignment models in Transcad, or Kernel density estimation
in ArcView Spatial Analyst). My suggestion is that the software environment
should provide help and give substantive guidance to non-specialists (and
“learners”). This, in my view, would be a major improvement over the current
state of knowledge. Ideally, software for GIS/spatial analysis would be
used by people with a thorough exposure to, and training in, geographical
analysis. In reality though, spatial analysis concepts may be completely
unfamiliar to those who have access to GIS. To give a few short examples
that would be worth fleshing out further at the workshop:
? A menu for kriging may put powerful tools at the disposal of a user:
if that user does not appreciate some of the required properties of the
theoretical covariogram, nonsense can result. The situation could be improved
by giving the user some support in terms of fundamentals.
? As an over-simplified example (just for the sake of illustration):
in trip distribution models, a user intending to use a value of a parameter
equal to 0.4, would be informed that this value implies an average journey
to work length of 35 miles. This is the kind of consistency check, and
pre-estimation, and ideally “verification and validation” that we expect
people to do with more routine statistical analysis and should be used
as more complex techniques become available.
? Another example would be a warning of the need for edge correction
to a user about to estimate an empirical K(h) function, where h could be
up to 50 km, in a study region of say 100 square km.
The goal differences between the research community and the corporations
and individuals who design software for applications purposes are fairly
obvious. Thus, in my opinion, there is a tension between “GIS design” and
creative mathematical/spatial analysis. The GIS design process, has as
its goal “the efficient and effective application of existing technology
to the problem set” (Marble). For all its merits, and for all its success
in preventing horror stories when implemented rigorously, it is clear that
“GIS design” addresses a question that is much different from the creative
process of new model development. The design protocol/regimen requires
that the analyst make successively more specific passes at the specification
of a solution to the problem. Knowing who is going to use the system, and
what the system is to be used for, is rightly given priority in such a
scheme. Research per se, and extension of the state-of-the-art is
not the goal, although research extensions could occur as by-products from
a particular application. The demand for skilled individuals to do this
kind of work for software companies will mean the reduction of the pool
of people ready and willing to do much-needed fundamental academic research.
The competition for scarce talent in this area has already been felt in
the job market. There are exceptions, of course, and many of those who
have successfully straddled both sides of this fence will be in attendance
at the workshop, and so I hope to hear more examples and feedback on this
discussion point.
It is probably worth exploring the changing labor/capital intensity of inputs to GIS and spatial analysis research. In the 60s, quantitative spatial analysis was a time consuming labor intensive activity, with the resultant product regarded as a “research work” because of the time and effort needed to make it. Nowadays routinization has made many analytical steps much easier, and we could realistically expect a powerful data base manager, a good statistical analysis package, a GIS mapper, and perhaps a sophisticated report writer to produce custom reports for 100 MSAs in the USA. Although some technical skill would be needed to do the data integration steps, the products of this process would not be generally acceptable as research.
The archtypical example is the suite of tools for demographic data mapping. These data CD ROM’s come packed with data for hundreds of undigested variables and allow the user to select infinitely varied study areas. Products such as Census-CD, a simple desktop thematic mapper, is capable of producing an immense array of maps and we have to ask if we have taken a step backwards in making the production of these maps so easy: we give people/end users access to reams of undigested data and expect them to be able to make intelligent use of these covarying data sets. Didn’t the factorial ecologists teach us to boil the data into essential factors?
The correct model, to my mind, is one of continuous improvement. An operational version of an idea should be rapidly prototyped, using either novel or existing text book methods. The tool is presented, tested, and debugged. Then a series of upgrades, re-writes, enhancements, and so on are built. These are upgrades both to the way that the simple model is implemented, but also perhaps, new discoveries of critical process and adaptations. An example that typifies the successful idea here might be the PASS dial-a-ride software system, one which has many geographical ingredients, complex data base linkages, and a challenging underlying algorithmic problem (vehicle routing with time windows). Another example might be the continuous improvement and re-refinement of the location-allocation suite of models, which some here will remember fondly from the mainframe days at IOWA and the ALLOC package. A final example might be in the area of trade area mapping and estimation of gravity model parameters.
Of course the relevance of these ideas must depend somewhat on the position one holds in the spectrum of pure research through to applied commercial software development. I’m coming at this from the point of view of someone who is quite comfortable experimenting with ideas and in thinking about general new ideas for spatial analysis. Often such ideas are exploratory, or are left partially documented, perhaps to be revisited at a later time. I would find it difficult to change hats and consider application issues, because I prefer to think of spatial analysis as an intermediate calculation on the way to exploration of actual processes. This academic/practitioner division of labor that has served us well so far: a question for the workshop is whether the future growth of spatial analysis and GIS needs a revised model.
Email: okelly+@osu.edu