LUPIS - Extending capabilities to facilitate multi-focussed and
multi-stakeholder spatial resource allocation.
Attempts to address complex land use issues can
undoubtedly be aided by the application of a decision support
system methodology. McClean et. al (1995), Land Use Planning:
A decision support system, J. Env. Plan. and Man. 38: 77-92.
Background to software product
LUPIS is a functional software product which has been used and
distributed over a number of years. The development of the Windows
version has provided an opportunity to totally redesign the
framework and programming environment of LUPIS. In so doing an
attempt has been made to provide a framework which lends itself to
efficiently add additional capabilities in the future when the need
What is it?
Basically LUPIS is a microcomputer-based spatial decision support
system developed to assist in implementing the SIRO-PLAN and SIRO-MED
approaches to spatial resource allocation by facilitating the
ranking of competing candidate land uses or management regimes on
each of the resource inventoried areas, which jointly comprise a
region of study. The ranking reflects the extent to which each land
use collectively addresses issue-induced guidelines and the relative
importance attached to achieving each guideline. In so doing, LUPIS
facilitates a multi-stakeholder driven approach to resource
allocation that builds upon resource inventory and evaluation.
LUPIS has been developed in an environment of practical
application, with on-going developments coming invariably as a
direct result of involvement in or knowledge of exercises in which
it has been used. Current adoption of LUPIS for resource allocation
studies for the Western Division of New South Wales and the
North-east Goldfields Region of Western Australia demand extension
to the capabilities already available. Consistent with the design
principles the addition of further capabilities is undertaken in a
generic form so that capabilities developed for either of the above
studies are not only automatically available to the other study but
available to any further studies.
The software provides an efficient mechanism for technology
transfer. Although the LUPIS software alone is no guarantee of good
resource allocation practice, the software provides a vehicle
encapsulating an issue-driven approach to spatial resource
allocation allowing the relevant stakeholders to systematically
explore options for the future. In the case of the Western Division
(NSW) and North-east Goldfields (WA) the technology will provide
on-going opportunity for stakeholders to explore land use options
for the two Regions well beyond the life of the current Projects.
What are the design principles behind LUPIS?
LUPIS has been developed in accordance with a number of design
1. Low end of the technology spectrum: although the
general level of computer literacy is increasing, the range of
understanding and adoption by people who are legitimate parties to
resource allocation (i.e. stakeholders) is variable. By aiming at
the low end of the technologyspectrum there is minimum risk that
these parties will be alienated from the planning process by the
forbidding nature of the computer technology. It is recognised
however that the low end of the computer technology spectrum is
continually rising. The evolution and adoption of the Windows
environment provided a convenient and timely opportunity to
consolidate past LUPIS capabilities and redesign it to accommodate
further enhancements for this almost universally accepted platform.
2. Capturing generic capabilities: effort has been made to
capture the generic capability that underlies any specific
application. In incorporating further capabilities into LUPIS
attention has been given to ensuring these capabilities are as
generic as possible. As a result LUPIS offers a comprehensive broad-
based approach to resource allocation. By comprehensive it is meant
that the full spectrum of conventional planning sub activities are
recognised and provided for and broad-based means that no limitation
is knowingly imposed upon the type of resource using allocands (e.g
land uses, management regime etc.) that can be considered.
As a consequence users have successfully used LUPIS in situations
in which it was never envisaged by the developers, e.g. planning an
environmentally sensitive route for an oil pipeline through a
portion of the Amazon Valley.
3. Adoption of a decision support approach to user interface:
underpinning this point is the view that one must strive to avoid
unduly constraining the way a user may seek to use the package.
Rather every attempt should be taken to provide an environment that
encourages the user to explore alternatives, options etc., without
the expectation that any particular allocation emerging will
necessarily be fully implemented- users will however be more aware
and wiser of the available options.
4. Avoid duplication of existing software capabilities:
rather effort has been taken to provide interfaces to encourage and
foster efficient transfer of information between packages so that a
user is not constrained in using other complementing packages that
allow data import. This approach provides flexibility and
opportunities for synergism from the choice and use of both other
in-house and commercial software packages. By so doing the risk of
users being locked into the approach of a particular software
package because of impediments to information transfer between
packages is minimised. In some cases seamless interface has been
developed to streamline the use of cosmopolitan generic software
5. Foster participation: historically to the extent that
resource allocation planning was undertaken, it was conducted
largely by single agencies with little obligation to consult
affected stakeholders. Times have changed, now public participation
involves not only scrutiny of candidate allocations but increasingly
also involvement in the derivation of the candidate plans. LUPIS
explicitly recognises and makes provision for a number of
stakeholders to develop individual and/ or collective plans.
6. Transparency: in recognition that with increasing
public accountability in resource planning it is necessary to
provide the opportunity to allow the reason underpinning any
allocation to be seen and reviewed as required by public scrutiny.
7. Reproduceability: as an adjunct to being transparent it
is essential that anyone undertaking the same exercise in the same
manner is able to reproduce a consistent result.
8. Trace back provisions: provides opportunity for the
user to gain insight and understanding of the allocation.
9. Response time: with increasing computing power users
expect a quick response to their requirements (red light syndrome).
The quicker the response time the more likely a user is to explore
the implications and alternatives- thereby contributing to decision
support. As an index to response time improvement, a gain of a
factor of 1700 has been achieved in the DOS- Windows upgrade (of
which x5 has been due to concurrent hardware improvements and x350
with software efficiencies). Translated to practical terms an
exercise that once took 19 hr. to conduct can now be undertaken in
10. Continuity with previous versions: ensure users who
upgrade their version of LUPIS (over a 100 versions have been
distributed) can revisit past exercises automatically and have
available the enhancements offered by later versions. In the past
this has been the case with DOS versions and is being continued with
the DOS- Windows upgrade.
11. Platform transferability: to assist in ensuring
maximum opportunity of transfer to alternative platforms, for
instance capabilities including file handling operations have been
developed as a dynamic link library in Visual C++, the user
interface is in Visual BASIC.
What are LUPIS’ capabilities?
The value and purpose of the core supporting capabilities can
only be gained from a demonstration or using LUPIS, however to
assist that process a brief coverage is provided:
Large exercises: the size of an exercise is determined by
the number of mapping units, land uses and guidelines. The limit on
number of mapping units is in principle constrained only by the size
of the hard disc, for formatting purposes the limit set on land uses
is 99 and for guidelines 999- values which considerably exceed
anything yet undertaken. Individually there can be 9999 commitment,
exclusion and preference guidelines and 999 data items held against
each mapping unit if required- subject to hard disk capacity.
Multiple stakeholders: earlier versions recognised only
one stakeholder, in essence being developed to support single party
planning (viz. SIRO-PLAN). The Windows version supports multiple
stakeholders (99 provided for) with each stakeholder having access
to the common map and data base (viz. SIRO-MED) as the inputs to
development of individual stakeholder plans a prelude to the
development of a consensus plan.
Hierarchal land use and guideline structure: historically
LUPIS has identified a single land use to each mapping unit implying
an exclusive allocation not conducive to multiple land use. The
introduction of hierarchal land use structure which may recognise a
preferred use, permitted uses, conditional uses and proscribed uses
fosters a more inclusive approach to resource use. The hierarchal
land use structure also recognises that land uses can be described
in various levels of detail, for instance pastoralism may be divided
into sheep and cattle grazing, sheep grazing in turn into breeding
and dry sheep operations. In principle there is no limitation upon
the number of levels that may be included in the hierarchy. The
different levels of land use capture the diversity of interest and
understanding relevant stakeholders express in formulating
guidelines which may be directed at any specific level, for instance
agencies may direct guideline attention to the highest level (e.g.
pastoralism), peak bodies may formulate guidelines at industry
levels (e.g. sheep or cattle) and individual pastoralists at the
activity level (e.g. breeding or dry sheep operations). The
integrated hierarchal structure of land use and guidelines enables
diversity of focus to be captured and utilised in resource
allocation- a feature that facilitates a ‘think globally, act
Spawning guidelines: guidelines proposed by way of example
frequently have numerous analogues which the stakeholder takes for
granted. To streamline the development of multiple guidelines to
capture the theme of an example, guideline spawning has been
developed whereby numerous specific guidelines are automatically
spawned for a single exemplary generic statement. The advantage of
this capability is that the stakeholder need only identify the
single example (conservation of a particular land system type) for
the underlying principle to be extended to all relevant cases (i.e.
all land systems). Stakeholders retain control over the level of
achievement on the individual spawned guidelines.
Multiple plans: each stakeholder can produce multiple
plans, each of which can be retained for further refinement or as a
component plan for plan blending. Provision is made for each
stakeholder to retain 999 plans.
Switches for land uses: to simplify the exploration and
development of appropriate land uses, individual land uses can be
selectively removed from an exercise by a simple switch, in effect
all the guidelines for a switched-off land use are ignored until
such time the user switches the land use on again. The switches can
be applied at any level within the hierarchy.
Switches for commitment and exclusion guidelines:
commitment and exclusion guidelines by their nature can have an
enormous impact upon the expression of preference guidelines and the
option space of a land use. The switches enable an efficient
exploration of this impact with the opportunity for the user to
simply switch on and off commitment and/ or exclusion guidelines
either individually or collectively.
Area adjustment: the relative area allocated to each land use in
a plan can be adjusted directly and accurately with this capability
whilst retaining the integrity of the land use values. The vote
profile consistent with the area adjusted allocation is derived and
retained. This feature can be used for those occasions when specific
areal requirements need to be met either in percentage or real
terms. Once an area requirement has been met this can be locked in
before turning to the next land use, sound in the knowledge that
land uses that have been locked in will not be altered in subsequent
area changes. Area adjustment can be applied at any level in the
land use hierarchy. However, once an area is locked in for a
particular activity all further adjustments whether up or down the
hierarchy are constrained to be consistent with activity areas
already locked in.
Achievement adjustment: the guideline achievement attained for
any preference guideline in a plan can be adjusted directly and
accurately with this capability whilst retaining the integrity of
other land use values. The vote profile consistent with the area
adjusted allocation is derived and retained. This feature can be
used for those occasions when specific guideline achievement
requirements need to be met either in percentage or real terms. Once
a guideline achievement requirement has been met this can be locked
in before turning to the next guideline, sound in the knowledge that
guidelines that have been locked in will not be altered in
subsequent achievement adjustment of other guidelines. Achievement
adjustment can be applied at any level in the guideline hierarchy.
However, once an achievement is locked in for a particular guideline
all further adjustments whether up or down the hierarchy are
constrained to being consistent with the guideline achievements
already locked in.
Pragmatic achievement interpretation: guideline
achievement is reported in percentage or absolute values where
absolute values reflect the idealised area equivalent that an
allocation has delivered. The guideline achievement of any
preference guideline can be reinterpreted into a number of more
pragmatic physical and economic measures (e.g. carrying capacity) to
assist in evaluating the environmental, economic, physical and
social consequences of any plan.
Temporal considerations: natural resource systems are not
static, data reflects a snap shot of conditions currently applying.
If dynamic changes in data are known then these can be taken into
account and a sequence of plans produced in accordance with the
fluctuating values of the dynamic variables. The sequence of plans
can then be displayed in relative real time. Any one of this
sequence of plans can be used as a seed plan for further change.
Mega units: mapping units having the same data or ratings
profile will be allocated to the same land use, by recognising
subsets of mapping units with the same profile time can be saved in
the allocation phase. In addition mega units offer a sampling frame
and an insight into the data and rating diversity for the area. The
particular data and/ or ratings on which mega units are formed is
under user control.
Proprietary data file structures: the capabilities of
other software packages can be used to increase the efficiency with
which LUPIS is used or enhance the output from LUPIS. To facilitate
this links have been made to allow seamless use of other products
both in-house and commercial. To date the two commercial products
are Excel and IDRISI. In addition information can be transferred to
an ASCII file for importing to other packages.
Plan blending: individual stakeholders can generate a
series of plans each of which may have desirable features.
Alternatively the preferred land use plans of individual
stakeholders need to be reconciled. Plan blending allows these
component plans to be combined (several methods are provided) to
form a single plan. This single plan can then become the seed plan
for subsequent refinement as required.
Mediation: the resolution of differences in the land use
preferred by individual stakeholders is gained with a period of
interactive mediation of the conflicts. To assist in this phase a
number of negotiation aids are available which can be used in a
flexible form determined by the user(s) to assist resolving
differences and develop a consensus plan.
Relative land value: the relative land value applies to a
plan and is the relative value of each mapping unit should the
preferred use be implemented. As such it reflects the price that the
plan developer would be prepared to pay for adoption of the
preferred use should a land market exist for the land. There is a
constant adjustment in relative land values as stakeholders
progressively refine their plans. Similarly relative land values
differ between the allocations preferred by different stakeholders.
Hotspot: while differences in relative land value exist
between competing stakeholders there are different degrees of
significance. Hotspot analysis allow the stakeholders to
collectively identify at what level the difference between their
individual relative land values is of sufficient significance to
warrant further analysis and negotiation.
Tradeoff: the allocation of a land use as preferred also
identifies what land values have been forgone and therefore the
implied tradeoff involved should the preferred use be implemented.
In addition the achievement level of each guideline monitonically
increases or declines in moving incrementally from one plan to
another. Comparing the trace of this change across targeted
guidelines gives insight into gains and losses associated with any
Consensus plan: the objective of a planning exercise where
a number of stakeholders are competing for the land resources is to
arrive at an efficient allocation which has enabled each stakeholder
to maximise their individual objectives mindful of the competing
objectives of other stakeholders and their relative political
importance. This is the objective of the consensus plan which is
arrived at by combining the preferred land use plans of each
stakeholder into a single plan which is then adjusted further in
light of the insight offered by the negotiation aids. The full
capabilities of the package are available for adjusting the plan at
the discretion of the stakeholders.
A Stylised layout of LUPIS: