Çetin CÖMERT
KTU, Geodesy and Photogrammetry Department, 6108 Trabzon, Turkey ccomert@ktu.edu.tr
Commission IV, WG IV/4
Spatial Data Infrastructures , TS
Keywords : Spatial Infrastructures, Data, Interoperability , Databases, National
ABSTRACT :
“Web Services” have gathered a great interest from various communities including business, industry, academia, and government.
Many successful implementations of Web services for business to business (B2B), government to business (G2B), and government to citizen (G2C) applications are already in place. “Web Services” is a new paradigm where every different system or provider offers some “services” for certain user groups. Any user does its job by just calling or combining proper services over Internet. If one is to derive an analogy from the philosophical point of view, it should be the one between Web Services and Object-Orientation. Although it has some weaknesses, Web Services seems to have a great potential for wherever there is a need for cooperation or
“interoperability”. This need had long been felt in spatial data management communities. These communities have also directed their work towards the adoption of Web Services for their clear advantages over traditional models of interoperability. On the other hand,
National Spatial Data Infrastructures (NSDI) have traditionally been based on these interoperability models. In other words, as their names imply, they have been “data-centric”. Whereas, it should not be difficult to predict the business models and supporting technologies which will shape the future of spatial data communities considering the related developments in such areas as B2B.
From this respect, Web services have great potentials for NSDI. The purpose of this work is to examine this potential. To this end, the paper will first introduce the current status of Web services. It will then present some implementations of web services within the context of NSDI. Finally it will present a web services based infrastructure for the NSDI of Turkey.
1. INTRODUCTION
The need for interoperating applications has never been this strong. This is felt rather strongly in the business-to-business
(B2B) sector, where every different company has applications in their particular area of specialization. Nokia (2003) highlights this need for the mobile community. The business model of today necessitates the cooperation among these applications.
Consider different parties involved in a business trip reservation for instance; at the requestors side there might be desktops, mobile phones, or PDAs, while at the providers side there would be airline, car rental, and hotel reservation systems. The ultimate business goal here is to provide the requestor with a high quality service that would enable him to effect his bookings in a quick and an easy way. For this to happen, all the systems involved should be able to “talk” to each other. And the provision of this “talk” should be easy and cost-effective for businesses to profit.
Interoperability can be defined as the ability by which different applications can talk and cooperate with each other. The differences may be in the hardware, software or the data formats. To date, spatial data interoperability solutions have been inefficient, proprietary, and complex. National Spatial
Data Infrastructures (NSDI) has emerged as the way enabling interoperability throughout a country. NSDI would cut down data production costs, improve spatial data access and use in a country. To achieve this, a NSDI connects all the parties that somehow use or produce spatial data via a computer network, namely Internet. Although there have been achievements concerning NSDIs in some developed countries, there are still more to be done. This fact and the emergence of Web services implicate improvements in NSDI implementations. That is why some of the NSDI undertakings such as Canadian Geospatial
Data Infrastructure (CGDI) and major bodies such as Open GIS
Consortium (OGC) have directed their work towards Web services (CGDI, 2001; Reed, 2002). Hence, NSDI implementations have to be re-considered to adopt Web
Services technology. Although CGDI seems to pioneer in this respect, there does not seem any implementation of web services currently in CGDI (2004).
Web services have recently emerged as the next generation of the Web. Two significant developments have made Web
Services a reality. One of them is Java which has provided software and platform independence. The other one is XML, which has enabled software and data independence (Nagappan et al, 2003). Web Services has its roots on distributed systems and it is an evolution of the work on that area. The philosophy behind is the same, which is “distributed but cooperating” systems. But the way that the “cooperation” takes place is different. While the stress has been on the distribution of “data" in distributed systems, it is on the distribution of the “tasks” in
Web services. In the Web Services view, every different system or component offers some services for some others. And any system does its job by just calling or combining suitable services over Internet.
NSDI needs an interoperabilty infrastructure. Web services seem to satisfy this need. Moving from this point on, we, in our ongoing work, have designed and implemented a number of
Web Services for the Trabzon Municipality in Turkey. In doing this, some of the activities of the Municipality have been examined in detail in ahin (2003). Then a number Web
Services have been identified and specified. Finally some of these services were implemented using Cape Clear (Cape Clear,
2003) Web Services development and deployment software. We

have also designed a toolbox for additional client side functionality.
2. WEB SERVICES
Web services may be realized as the next generation of Webbased technology for interoperability. Web services enable constructing Web-based applications using any platform, object model, and programming language (Barefoot, 2002). A service is a collection of operations accessible through an applicationprogramming interface that allows users to invoke a service, which could be a response to a simple request to create a map or a complicated set of image-processing operations running on several computers (Hecht, 2002). Web services are for application-to-application communication over Internet. Web services are based on open standards such as XML to enable interoperability. required services.
Service
Broker the job” is the user-Web interaction. What usually happens is the user browses through many web pages, spending plenty of his time and hopefully gets some useful information. However this is not the end of the story, he might also need to use an application program to do the job. This means that the user might have to go through many lengthy searches and then transfer the results to the application programs. Besides being error-prone, this is an unacceptably time consuming process. In the “application-centric” Web, it is the applications that discovers and manipulates the information. In short, in “humancentric” Web it is the human who controls the processes and does the job, whereas in “application-centric” it is the applications that control and do the job by interacting with each other over the Internet and present the results to the users. Web services have emerged from the need for such applications.
There are other names for the “application-centric” Web in the
There are three components of the Web services architecture
(fig. 1). These are service provider, service broker and service requestor. Service broker is sometimes referred to as service registry (Cerami, 2002). The interactions among these components involve publishing, finding and binding Web services. In a typical scenario, a service provider hosts a Web service. It provides service description and publishes it to a service broker. The service requestor uses a find operation to retrieve the service description locally or from the service broker and uses the service description to bind with the service provider and invoke the Web service implementation (Kreger,
2001). Service broker is responsible for service registration and discovery of the Web services. The broker lists various service types, descriptions, and locations of the services that help the service requestors find
Service
Requester
Find
Invoke
Publish
Service
Provider
Figure 1. Web services architecture (Nagappan et al., 2003)
Web services mean a shift from “human-centric” Web to a
“application-centric” Web (Cerami, 2002). In its widespread use today, Web is human-centric, where the Web has been perceived as the means of merely disseminating information to as large an audience as possible. This view falls short in meeting the expectations of Today, in which users of the Web do not only want to get information but also want to do business or develop applications over the Web. There are three components of “human-centric” Web; The Web, user, and the application programs. The way of achieving a goal or “doing and subscribe to the literature. For instance, Ryman (2000) uses the term “Service
Web”. Tim Berners-Lee, the original inventor of the Web, has coined the term “Semantic Web” and envisioned the Web services as an actualization of the Semantic Web vision Cerami
(2002). See Berners-Lee et al. (2001) for more on Semantic
Web.
3. NATIONAL SPATIAL DATA INFRASTRUCTURE
(NSDI)
Interoperability can be defined as the ability by which different applications can talk and cooperate with each other. The differences may be in the hardware, software or the data formats. To date, spatial data interoperability solutions have been inefficient, proprietary, and complex. Nevertheless, it has been well accepted that the organizational problems are more difficult to overcome than the technical ones (MSC, 1993).
National Spatial Data Infrastructure (NSDI) has been proposed to provide the legal framework in which institutional problems would be solved by law.
NSDI has originally been envisioned in the US for “sharing data” to cut down the data production cost, improve spatial data access and use throughout networked systems in the country.
Public and private sectors, local governments, universities, and finally citizens would have been connected to each other via

NSDI (figure 2). One of the key components of NSDI is the
National Spatial Data Clearinghouse. OMB (1992) defines the
National Spatial Data Clearinghouse as an electronic service providing access to documented spatial data and metadata from distributed data sources. These sources include a network of data producers, managers, and users, linked through the Internet
Services data
Figure
Public sector and other communications means, and accessible through a common interface. All spatial data collected by federal agencies or their agents, will be made available through the
Clearinghouse. Spatial data users will have access to the NSDI through the National Spatial Data Clearinghouse.
O t h e r s
N S D I
O t h e r s
Servic es
Services data data
Academia
Figure 2. Components of NSDI.
One of the very first countries with an NSDI initiative was the
US. Altough there had been related works before, the US NSDI has been officially started in 1994 by the famous executive order of Clinton [FR, 1994]. NSDI has gained a great interest since then. The NSDI is now a well documented and highly active research area. There are plenty of Web sites such as
FGDC (2004) and CGDI (2004), and numerous studies such as
MSC (1993) and McLaughlin and Nichols (1994). Furthermore,
NSDIs are underway in may countries.
Being the way to interoperability, NSDI is valuable in many respects. One On the other hand, NSDI will create new market and job opportunities, which is crucial for the countries of a high unemployment rate like Turkey. There are many projects underway for Canadian Geospatial Data Infrastructure (CGDI,
2004) and for the US NSDI. And these projects are just for building NSDI. There will also be market opportunities and projects of high economical and social value which will be viable via NSDI. One such project is the new real estate taxation system envisioned by Cömert and Akinci (2002). Another one is the e-local government which has also been implemented
(Cömert and Akinci, 2003). As already implied, NSDI is a must for the recently popular e-government and e-business. NSDI will be a major component of e-government. Because, almost
80 percent of all the information is spatial. Consider the involvement of Land Title and Cadastre data for instance.
3.1.1 A scenario in the current implementation
Imagine a scenario of generating a Zoning Plan Form (ZPF).
ZPFs are one the most popular documents since they are the
3.1 Current NSDI implementations
Current NSDI implementations can be categorized as either
“data-cenrtric“ or “human-centric”. They are data-centric in that they are designed to locate and transfer the desired data.
They are “human-centric” because they are designed in a way that the user controls the workflow. It is not easy, for instance, to locate some data from the US Clearinghouse [FGDC, 2004] and make it “usable” for a client system. The same is true for the Canadian CGDI (Geoconnections, 2004) and United
Kingdom’s National Geospatial Data Framework (NGDF)
(Gigateway, 2004). US NSDI has recently initiated Geospatial
One-Stop, an E-Gov initiative providing access to geospatial data and information. GOS was operational in June 2003.
However even GOS is a “human-centric” implementation.
Actually, CGDI intents to employ Web services in its implementation (CGDI, 2001) and there are around 200 K
Canadian projects like “smartbroker” (CGDI, 2004) to adopt web services. However the services envisioned are rather general, they have to be detailed.
How one carries out his job in a “human-centric” web is explained below with the help of a scenario. very first step of many activities. For instance, obtaining a
ZPF is the first step in getting a building permit. ZPFs are given by the Zoning Plan Offices (ZPO) of municipalities upon the request of the “interested” which might be citizens,

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 search to discover the data and
CO Server
Web Services getParcelGeometry
ZPO Server
ZPO Database
Municipality
ZPO GUI
Web Services getParcelZoningPlan getZoningPlanID getZoningPlanBlock vextorSuperImpose getZoningPlanBlockAttributes
CO Database
LTO Server
LTO Database
Web Services getParcelAttribute
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.

As explained above, in the Web services view, users do not go through the Web to search data for their applications. Instead, web services search for and fetch the data to the application. For example, what the ZPO officer has to do in a Web services based ZPF generation is to just initiate the related service. He initiates the service from his internet browser. And that is it;
ZPF gets ready in seconds. That is, the nine steps of the above
ZPF workflow is reduced to just one step in this case. Naturally, all the processing go on in the background but the user does not have to worry about it. This is shown in Fig. 2: ZPO officer initiates the getParcelZoningPlan service from his internet browser. Then this service calls the related services of the others to do its job. As shown in Fig. 2, the getParcelZoningPlan service calls the services of three servers which are ZPO, CO, and LTO servers.
It is our belief that NSDI may be implemented with the same vision. With the intention to show the way that the NSDI might be implemented with Web services we have designed and implemented a number of Web Services for the Trabzon
Municipality in Turkey. In doing this, some of the activities of the Municipality have been examined in detail in ahin (2003).
Then a number Web Services have been identified and specified. Finally some of these services were implemented using Cape Clear (Cape Clear, 2003) Web Services development and deployment software. We currently use static binding of the services for service composition (Systinet, 2002).
We have also designed a toolbar for the client side using
Javascript, SVG (Scalable Vector Graphics) elements, and
Document Object Model (DOM). Using this toolbar, a user on the client can perform client-side specific functions such as measuring distances, computing line intersections, computing intersecting areas, displaying x, y coordinates, displaying information about objects, move objects. Different departments of municipalities would have different toolbars due to their differing needs.
Thus, a user on a municipality department will be able to call web services of remote servers and perform certain tasks on his machine using the same program which is the internet browser.
He uses the browser as in Fig.3 to call the Web Services and upon the implementation of Web services he gets the toolbar of
Fig. 4 to carry out client side specific tasks. There is no need to have GIS and other proprietary software unlike the current situation in many municipalities in Turkey, where generally there exists different GIS or CAD software sitting, in isolation, in different units. Shown also in Fig. 4, is the resulting ZPF of the getParcelZoningPlan service.
Figure 4. Response of getParcelZoningPlan (imarDurumuGetir) Web service
4. CONCLUSION
NSDIs need an interoperabilty infrastructure. Current NSDI implementations do not satisfy this need. We, in our ongoing work, have designed and implemented a number of Web
Services for the Trabzon Municipality in Turkey. Our intention was indeed to show that the interoperabilty infrastructure.needed for NSDI might be build upon the Web
Services. Services were implemented using Cape Clear TM
Web Services development and deployment software. We have also designed a toolbox for additional client side functionality. Thus, a user on a municipality department will be able to call web services of remote servers and perform certain tasks on his machine using the same program which is

the internet browser. As the conclusion, Web services seem to satisfy the need for the interoperabilty infrastructure of
NSDI. There are two major implications of this: First, NSDI implementations which have already been in place have better to be re-considered. Second, NSDIs which will be newly built, have to be designed by the Web services vision.
REFERENCES
Berners-Lee, T, Hendler J., ve Lassila, O., 2001. The
Semantic Web A new form of Web content that is meaningful to computers will unleash a revolution of new possibilities, Scientific American, May.
Cerami E. , 2002. Web Services Essentials ,
O’Reilly&Associates Inc., Sebastopol.
CGDI, 2001. Canadian Geospatial Data Infrastructure
(CGDI), version 1, CGDI Architecture Working Group.
CGDI, 2004. Canadian Geospatial Data Infrastructure Web site, http://www.geoconnections.org/
Cömert, Ç., Akinci, H., 2002. Application Development in an interoperable GIS environment: A new system for real estate taxation in Turkey, Proceedings, Vol. I, p.200-205, 3rd
International Symposium on Remote Sensing of Urban
Areas, June 11-13, stanbul, Turkey.
Cömert, Ç, Akinci, H., 2003. Web Services: An e-
Government Perspective, 2 nd FIG Regional Conference,
Marrakech, Morocco, December 2-5.
FGDC, 2004.
Federal Geographic Data Committee (FGDC)
Web site, http:// www.fgdc.gov
FR, 1994. Executive Order 12906, Published in the April 13,
1994, edition of the Federal Register, Volume 59, Number
71, pp. 17671-17674.
Gigateway, 2004, UK http://www.gigateway.org.uk/
NGDF web site,
McLaughlin, J., Nichols, S., 1994. Developing a National
Spatial Data Infrastructure, Journal of Surveying
Engineering, 120(2), p.62-76.
MSC, 1993. Toward a coordinated spatial data infrastructure for the Nation, Mapping Scince Committee, National
Academy Press, Washington, DC.
Nagappan, R., Skoczylas, R. and Sriganesh, R.P, 2003.
Developing Java Web Services, Wiley Publishing Inc.,
Indiana.
Nokia, 2003 Web Services Interfaces – engine of innovation, http://Searchwebservices.techtarget.com
.
OMB, 1992. Office of Management and Budget, Circular A-
16, http://www.whitehouse.gov/omb/
Reed, 2002. Reed C., A framework for web-based Geospatial
Services, The OGC View on Web Services, GIM
International, 30-33.
Ryman, A., 2000. Understanding web services, IBM,
December.
Systinet, 2002. Introduction to Web Services Architecture,
Systinet Corp. ahin N, (2003). Designing Web services for e-municipality,
MSc. Thesis, KTU Geodesy and Photogrammetry
Department, August 2003, Trabzon, Turkey (in Turkish).