The methodologies in Table 1 are listed from top 
to bottom in rough correlation to system 
complexity. Shaded areas indicate that a property 
either does not exist or is irrelevant. To find a 
good methodology for a given application, 
consider each column corresponding to a system 
requirement and find the first row which has a 
check in every relevant column. 
If you need everything--that is, you need 
extended attributes in a system that supports 
topology with no redundant features and efficient 
use of attribute space--and you need an unlimited 
capacity to stack coincident features on the same 
graphic object, then you are not alone. User 
requirements for today's GIS systems are more 
demanding then every before. The time is fast 
approaching, if it is not already here, when all the 
system requirements we listed are assumed to be 
included in any current GIS. All the rows in 
Table 1 before the last two, therefore, should be 
considered viable only for temporary or interim 
products. 
4. USER INTERFACE ISSUES 
To manage coincident features effectively, 
a GIS system requires more than just the ability to 
store and manipulate attribute records with many- 
to-one relationships to graphic objects. The user 
interface must also present the relationship 
between real-world features and graphic objects in 
a manner which facilitates feature recognition and 
allows intuitive manipulation of feature attributes. 
4.1 The Feature Stack 
One tool we found useful in the 
An important property of the coincident 
feature stack, as we have defined it, it that it does 
not replace existing tools for editing details in a 
feature's attribute pattern. Our convention is that 
whichever feature is on the top of the stack is 
what is the current feature affected by all editing 
tools. The only editing appropriate in the feature 
stack is to Push the stack down to make room for 
a new feature, to Pop an existing feature off of 
the stack, or to Rotate the stack to provide 
random access to any feature in the stack. These 
limitations in the scope of feature stack editing 
have been found to be critical in achieving a 
consistent, generic interface which does not 
disturb existing product-specific editing tools. 
4.2 FIFO or LIFO Stack Behavior 
One property of the coincident feature 
stack which was debated for some time was the 
stack’s Push/Pop behavior. Should it behave as a 
LIFO (Last In, First Out) stack, or as a FIFQ 
(First In, First Out) stack. Our first inclination 
was to follow LIFO conventions since these were 
considered to be more intuitive: the stack would 
act as a physical stack of papers or books lying 
flat on a table--the last object placed on the stack 
would be the first to be picked off. When, 
however, we determined that system we used for 
programming was naturally inclined for FIFO 
behavior, we began to question the value of LIFO 
behavior. 
In fact, we could find two reasons the 
coincident feature stack is a more serviceable 
generic tool when it behaves as a FIFO stack. 
First, we wanted to discourage users from 
      
  
  
Geonex Corporation for visualizing 
coincident features is called the Feature 
Stack. The stack does not necessarily 
correspond with any physical data structure, 
but is a conceptual object which can be 
standardized across applications. From the 
user’s perspective, the feature stack is a 
menu, the main part of which is a scrolling 
list of relevant attributes--one row per real- 
world feature (See Figure 9). The user 
defines which attributes are relevant for 
feature discrimination from pop-up lists of 
all available attributes, and can manipulate 
features in the stack via Push and Pop 
operations. 
       
   
150 
   
Coincident Feature Manager 
        
  
  
  
  
  
pon 322 tT m - 
2 x Ie — ; : — oo : fon E 
Select | List Update | Define | Push | Pop _ 
#: F CODE 
  
: ANO10 
  
  
  
  
      
i| Dismiss 
B1 arc selected with 2 feature(s) present. 
  
  
  
Figure 9. The Feature Stack 
thinking th 
in itself. | 
be accessil 
the top fe 
moment. 
change fre 
significanc 
that the nu 
feature sta 
than with : 
Pop opera 
Rotate ope 
randomly ; 
requiremer 
accomplish 
4.3 Thel 
Mc 
insignifical 
coincident 
automated 
be affected 
that a feat 
came befoi 
an exampl 
discarded 
oriented da 
properties : 
storage sec 
Sir 
drawing or 
overall apr 
especially 
polygon fil 
green colo 
vegetation 
for exampl 
it is drawn 
Th 
features in 
The impor 
for drawin 
attributes, 
data storag 
area shoul 
recognizes 
to draw ve, 
vegetation 
city tint po 
Th 
the process 
discussed I 
Auxiliary '