关 键 词：

毕业设计论文

资源描述：

JSJ06-258@VB教材管理系统设计与实现(论文+源代码+开题报告),毕业设计论文

内容简介：

AUTHORITY密码：*nts- 1 - OpenGIS What is OpenGIS? OpenGIS is defined as transparent access to heterogeneous geodata and geoprocessing resources in a networked environment. The goal of the OpenGIS Project is to provide a comprehensive suite of open interface specifications that enable developers to write interoperating components that provide these capabilities. The OGIS Project Technical Committee of the Open GIS Consortium, Inc. (OGC) has completed the first in a series of documents that will comprise the Open Geodata Interoperability Specification (OGIS). This first book, the Open GIS Interoperability Guide, explains OGIS comprehensively but at a high level. Subsequent OGIS documents will contain precise technical language, written for unambiguous implementation, not explanation. The explanatory Guide will be published early in 1996 by GIS World, Inc. This is good news, but OGIS is not OGCs overriding goal, and completion of the Guide is not OGCs first major milestone. The true function of OGC is to provide leadership in the field of geographic information, unifying our industry and bringing it into a wider sphere of technology and markets so that it can fulfill its destiny of becoming an integral part of the global information infrastructure - for mundane activities as well as for solving critical environmental and infrastructure problems. Similar efforts have succeeded in other industries. At GIS Worlds Geographic Technology in Government 95 conference held in September in Reston, Virginia, Robert Scace of SEMATECH described how the U.S. semiconductor industry engaged in a collaborative R&D process that was instrumental in restoring U.S. competitiveness. But national competitiveness is not the issue for OGC. Our issue is our industrys isolation from the larger Information Technology industry. For a long time, GIS was almost a cottage industry, a small industry limited in much the same way that mechanical production was limited prior to the industrial revolution. That has changed. GIS software development is now moving in the direction of components, following one of the basic principals that has powered technologys ascendance in the last two centuries: Engineering analysis succeeds by breaking a large problem into smaller, more tractable component problems, and manufacturing succeeds by maximizing use of existing parts and materials. This becomes more true as the set nts- 2 - of available standardized, commoditized parts and materials increases. Historically, engineering disciplines tend to evolve from art and craft toward established procedures and professionalism. Innovators and inventors use intuition and brute force to give birth to unique new products or processes; but progress is haphazard, materials are used inefficiently, and commercialization is slow. Often the initial phase is followed by a period of craftsmanship in which individuals imitate innovators and become adept practitioners. But as good as the craftsmen are, their industry is limited to the degree that it lacks standardization, specialization, and infrastructure. As science and engineering bring discipline and a theoretical framework to an area of endeavor, progress becomes more predictable, people gravitate to their areas of special strength, variety and quality increase, uses proliferate, standards and other aspects of infrastructure support expansion, and overall market value and size increase. Standards enable commerce in existing technologies and interchangeable parts, which become the stuff of an engineers work, or in our case, a GIS developers or an information analysts work. By re-envisioning GIS in a modern software standards framework that supports distributed computing, object technology, componentware, middleware, multimedia, and a software backplane model, OGC has brought GIS up to the level of established software procedures and professionalism, and the market is already responding. Current GIS users are impatient to see OGIS- enabled products. Strategists, decision makers, and implementors who are not GIS people - in businesses such as telecommunications, enterprise information systems, and data visualization - now see GIS as an important business consideration. A new Information Communities concept introduced in the Guide will play an important role in the universalization of GIS. The first public release of OGIS will specify definitions of common types of spatial features and services shared by virtually all Information Communities. Following that, OGIS will provide a standard means by which Information Communities (the industrys technology enablees) can codify semantics, discovery methods, and authority for spatial data used in their disciplines or enterprises. That is, the basic OGIS will be augmented by definitions of semantics provided by academic review boards and committees of professional organizations who will establish for their constituencies the semantics and rules of translation that will define their Information Communities interfaces to the basic OGIS and to the spatial semantics of other disciplines. Many existing spatial data standards efforts will fold nicely into the process. FGDC will almost certainly play an important role, perhaps through the existing fourteen domain-specific schema committees which nts- 3 - FGDC established to address the particular spatial data requirements of hydrographers, soils scientists, facilities mappers, transportation planners, etc. Our collective efforts will yield a coherent, extensible spatial language scheme robust enough to encompass all the spatial data generated to date; all the spatial data that will be collected in the next few years (equal to all that has been collected to date) and beyond, into the terabytes and petabytes of the imaginable future. We only introduce the Clients and Service ports in open GIS environment here 1. Introduction The OpenGIS Services Model is a client-server model. That is, it is described in terms of interfaces that client programs or client objects use to communicate with service providers, which are programs or objects that respond to client requests by returning requested data or by providing a processing function. Not all OpenGIS implementations will be client-server in the traditional sense of establishing a one-to-one relationship between client process and server process. Some servers, for example, might be capable of providing multiple different services, and some clients will access multiple servers across the network. Given this situation, it is useful to use the term service provider instead of server. The lexicon of the Open Geodata Model provides the basis for a common geodata transfer and geoprocessing interface between clients and service providers. In looking at the technology foundations of distributed geoprocessing, we concentrate on data access as a special and important case of distributed geoprocessing, because:Geodatabases often contain huge amounts of data.The current need for distributed access to these heterogeneous (and previously isolated) databases is great.Database access is an important special case of general client/server computing.General purpose corporate databases contain, typically through street address fields, a huge amount of data that can be treated as geodata. Recent powerful general purpose relational and post-relational database products include facilities for managing spatial data, a development which, among other things, moves some traditional GIS functions down into the domain of operations that can be performed extremely well by the database itself. nts- 4 - The OpenGIS data access paradigm needs to be flexible enough to provide a common interface to different storage systems, including legacy systems. Geodata stored under a storage mechanism is likely to stay there for reasons of data integrity, performance, storage availability, budget, and ownership. Databases that contain geocoded information should not have to be replicated in order to provide separate access via an OpenGIS data access server. 2. Distributed Computing Definitions Clients - Clients are components, within a client-server context, that require a service. Even though clients may also provide service to higher order clients in the client-server model, the fundamental aspect of clients in all of the following discussion is that they are the requesters of some service. Service Providers - Service providers are components, within a client-server context, that provide a response to a specific client request for service. Even though service providers can also be clients in the client-service provider model, the fundamental aspect of service providers in this discussion is that they are suppliers of some service. Data Access Servers - Data access servers are components, within a client-server context, that provide data access in response to a specific client request. Even though data access servers can also be clients in the client-service provider mode, the fundamental aspect of data access servers in this discussion is that they are suppliers of access to data. In all client-server environments, a client makes a request for service to a server or service provider. The server or service provider then provides its service in a response. In the case of transactions between OpenGIS conformant clients and servers, client and server components interfaces conform to data types and software interfaces described in the OpenGIS Specification. The request must be made and response returned in a vocabulary, syntax, and protocol that both the client and service provider understand. Underlying request-response mechanisms are already provided by the distributed computing platforms (DCPs). DCPs have a syntax and protocol which, when combined with the vocabulary of the OpenGIS Specification, provide the complete request-response capability necessary for implementing interoperable geoprocessing. Similarly, database management capability is typically accessed via a database language, which, when combined nts- 5 - with the vocabulary of the OpenGIS Specification, provides the syntax and protocol for common geodata access services. 3. The OpenGIS Specification in the Context of Evolving Client-Server Models The client-server model enables application developers to isolate the requirements and capabilities of applications and identify the roles and relationships of components that meet requirements at various levels. Components proliferate (bringing more choice of functionality) and interoperability improves as layers of open-interfaced services emerge. In general, this happens as it becomes clear that most products in a generation of software products from multiple vendors redundantly provide lower-level services to the higher-level, or are differentiated functions available in the products. These common, lower-level services migrate downward into a service provider layer with a standard interface that becomes a platform for the now leaner, more portable highly differentiated functions. Figure 4-2 illustrates the evolution of geoprocessing service providers in the context of the evolving Distributed Computing Platform situation.Figure 4-2 With the OpenGIS Specification, geoprocessing can track progress in distributed computing.Figure 4-2 shows the evolution from monolithic geoprocessing toward distributed object-based geoprocessing. 3.1 Taking a vertical view, looking at each scenario: In the monolithic system, all layers are tightly coupled and not open to other systems, except through the very elemental means of exchanging data with identical monolithic systems or translating data from other systems. This kind of data exchange is referred to as data transfer. There are literally hundreds of formats, proprietary and open, and there are hundreds of filters and conversion utilities to perform the format conversions. There are also many interchange formats such as SDTS, SAIF, GeoTIFF, the National Image Format Transfer Standard, and DXF, which represent the pre-OpenGIS approach to geodata interoperability. The most common interchange format, a recent survey shows, is simple ASCII text files. In DCP Scenario 1, the DCP manages communication between the geoprocessing Application and the user interface above it (perhaps X nts- 6 - Window System or Visual Basic), but the other interfaces are still internal and proprietary. The Spatial Data Access Provider understands the Applications geodata model and can translate geodata model-based queries into queries that can be understood by the database software, but in this scenario this service layer is bound to a database. Communication is provided by sockets and/or remote procedure calls, which are not as easy to use as a DCP. In 1995, such Spatial Data Access Providers were introduced commercially to provide specific GISs with new access to specific relational database management systems whose relational model and speed offer benefits over proprietary spatial database solutions. The interface between Spatial Data Access Provider and Generic Database is proprietary, but sufficiently modular to be easily adapted by the vendor for integration with other databases. The OpenGIS interfaces in the diagram reflect OpenGIS-based Applications and Spatial Data Access Providers that vendors are developing now and will market after basic parts of the OpenGIS Specification have been codified in final implementation specifications. OpenGIS interfaces will make this service level open to other vendors and integrators. In DCP Scenario 2, we see that Applications have split off some of their common services into Application Servers. In this scenario, the Application is now more niche-focused, designed for careful nesting into a particular workflow. Dozens of functions redundantly provided in monolithic GIS systems are available here in the distributed computing environment as application servers and spatial data access providers for open use by the more focused and/or custom applications comprising the GIS vendors highest value-added functions. The same progress applies in geoprocessing areas other than GIS. To show that there is more than one way for geodata to be served, the figure shows a Spatial Data Access Provider accepting queries to extract data from either a Generic Database or a Generic Data Store, which is typically a group of data files and metadata files that are not contained or managed by a full-featured relational or object-based database management system. OpenGIS interfaces will provide the common language that enables inter-layer communication. DCP Scenario 3 depicts the thoroughly object-oriented future that many experts predict, in which applications are temporary collaborations of applets, services of all kinds are always available to nts- 7 - clients, and database management systems are superseded by swarms of queryable objects and querying objects populating a vast Net space. 3.2 Taking a horizontal view of Figure 4-2, looking at how the OpenGIS Specification fits into each layer: Presentation Layer: Applications increasingly rely on user interface resources in the operating environment (X Window System, Visual Basic and Controls, etc.) instead of a user interface that is proprietary and tightly coupled to the application. To manage a variety of cartographic and interactive data manipulation issues, this layer will need OpenGIS interfaces. Even if the underlying services that the user interface invokes, such as a region function or a viewscape function, are located on different platforms and operating systems, the portion of the application closest to the glass will need a particular OpenGIS interface. For example, if a developer wants to include and exclude certain classes of geographic features or labels for display while the user is viewing a geographic image and zooming in and out, the user interface will need to communicate with the Application Server Layer or other underlying layers that store or manipulate these features. In this book, we will call user interface and associated process management the human-technology interface. Application Layer and Application Server Layer: Applications in general, even in desktop computing environments, are becoming increasingly component-based, shedding direct responsibility for common functions such as graphic display and user interaction, as well as printing, faxing and online help. Such common functions become available as Application Servers, always available in the operating environment to any application request that conforms to their service interfaces. As explained above, geoprocessing applications are just beginning to go through this change, giving up common geoprocessing functions into a shared pool of Application Servers available in the computing environment. Geoprocessing applets and the geoprocessing middleware below them will communicate through OpenGIS interfaces. These lightweight applications are easy to write because they can provide services through easily written interfaces instead of integral subroutines. The user benefits because an abundant selection of niche products appear, geoprocessing applets appear in previously geoprocessing-barren application domains, and integrators nts- 8 - can inexpensively and quickly integrate applications into workflow solutions. Spatial Data Access Provider Layer: Spatial Data Access Providers bidirectionally translate application semantics and database semantics. For example, an application sending a query to a database will likely send the query in terms of a particular geodata model, whereas the database understands only SQL or a proprietary query language. In addition to mediating queries and responses, this layer enables Applications and Application Servers to access other database management services related to security, version control, etc. Included in this layer are currently a