bul 2004 
rough a 
agencies 
igh the 
ie NSDI 
  
S either 
ntric in 
ed data. 
1a way 
nstance, 
’, 2004] 
true for 
United 
NGDF) 
ospatial 
ospatial 
> 2003. 
ntation. 
in its 
200 K 
o adopt 
' rather 
web is 
ning a 
PFs are 
ipalities 
;itizens, 
International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Vol XXXV, Part B4. Istanbul 2004 
  
government agencies, private sector, or municipality 
departments. 
A ZPF geometrically shows the location of a land parcel in 
relation to the zoning plan, and includes construction 
conditions of the zoning plan block that covers the parcel. In 
other words, a ZPF includes both graphics and text data. 
Graphics data comes from the cadastral map and the zoning 
plan while text data comes from the zoning plan and land title 
data are graphics data. Laying out a ZPF, involves bringing 
all these data together. In Turkey, these data are maintained 
by different government and municipality offices. Cadastral 
and Land Title data are under the responsibility of Cadastre 
Offices (CO) and Land Title Offices (LTO), which are 
separate Central Government organizations. Zoning plan data 
is handled by the ZPO of municipalities. 
A ZPO officer who has access to a data-centric NSDI has to 
perform the following steps to generate a ZPF: 
1. Connect to the CO web site 
2. Search for the layer containing the parcel of 
interest. This can be eased by a query tool. 
3. Transfer the entire layer in an import format 
supported by the server site 
4. Add the imported layer to the client application. 
User has to browse through the windows explorer. 
So, he has to remember where he had put the 
imported file. 
5. Clip the parcel 
6. Connect to the LTO web site 
7. Search for the related LTO data. This can be eased 
by a query tool. 
8. Retrieve the related data. 
9. Combine the results of the steps 5 and 8 into the 
ZPF form. 
The ZPO officer would have to carry out each step, one after 
another, spending considerable amount of time to accomplish 
the task. This is in no ways an acceptable solution. 
3.2 Implementing NSDI with Web Services 
It is our view that the emergence of Web services has 
necessitated a major shift in both the vision and 
implementation of NSDIs. Because, NSDIs have originally 
been envisioned for “sharing data”. And they have been 
implemented with the existing Web technology which was 
the “human-centric” web. The idea was to provide users with 
a metadata based scarch to discover the data and 
  
  
~~ Municipality 
us GUI 
ZPO Server . Web Services 
t3  getParcelZoningPlan 
2 -  getZoningPlanID 
getZoningPlanBlock 
vextorSuperlmpose 
getZoningPlanBlockAttr) 
E 
i 
E 
^ 
ZPO Database == 
  
   
v 
  
  
   
       
   
    
   
     
   
  
     
     
  
  
  
  
CO Server 
Web Services 
getParcelGeometry 
  
    
  
  
   
    
—CO Database 
    
  
LTO Server 
Web Services 
F § Th getParcelAttribute 
   
     
A LTO Database 
  
Figure 3. Interoperating Web services of the ZPO, CO, and LTO servers. 
let them transfer the data in a data format. This is not an 
acceptable solution for mainly two reasons. First, as explained 
above, it is not easy to find what one wants in the human-centric 
Web. Second, it is not easy to transfer data from some other 
system and integrate it to the application at hand. This is also 
because of two reasons. First, spatial data exchange has always 
been problematic due to the disagreement over a single 
exchange format. Second, even if there is no problem in 
exchanging spatial data, attribute data integration is generally 
troublesome and therefore tackled separately from the spatial 
data. This can be. noticed from the workflow of the ZPF 
scenario above: Searches in the steps 4 and 7 are for spatial and 
attribute data respectively.