GIS meets e-Business: Web Pricing & Ordering Service (WPOS)

GIS meets e-Business: Web Pricing & Ordering Service (WPOS)

Roland M. Wagner, Rüdiger Gartmann
Fraunhofer Institute for Software and System Engineering (ISST) Berlin/Dortmund
Mollstraße 1, 10178 Berlin, Germany
Joseph-von-Fraunhofer-Straße 20, 44227 Dortmund, Germany
roland.wagner@isst.fhg.de
gartmann@do.isst.fhg.de

Abstract

With the great success of introducing the OGC Web Map Server and the OGC interoperability activities, the GIS world moves towards easy and quick availability with Web Services. Web Services will merge and manipulate vector and bitmap data. Much data sources are available for free. However, data of high value will not be accessible in the WWW without any payment. E-Business Services are needed for an automated processing. The pricing of geodata and location-based services is still complex. Selling geodata means in the majority of cases selling license rights, which leads to complicated price models, as it is also known from other branches. Both, ISO and OGC, do not define a price model on a level of detail, which is sufficient for e-Business applications. An approach to handle e- Business information in a distributed environment is the new Web Pricing & Ordering Service (WPOS). The ability to configure geo products by user requires a more complex pricing mechanism. On the other hand, the lack of common accepted pricing rules in the branch requires a flexible pricing mechanism to cover many different pricing methods. The lowest common denominator for marketing in every company is the mathematical pricing formula. The Web Pricing & Ordering Service interface to price models is defined by an OGC Basic Service Model-like set of Internet services. Therefore, the handling of pricing information in a distributed environment is covered in detail in our paper.

Introduction

The business situation of the newly developing market for geodata is still divergent. Every data supplier has developed his own pricing formula because of a lack of commonly accepted rules. The idea of a portal is to connect as many as possible data suppliers and to transfer necessary data for business transactions not depending of their concrete product and price models. Flexible product definition, pricing and licensing is a core module of an e-commerce platform. New transaction mechanisms are required.

Currently, Fraunhofer Institute for Software and System Engineering (ISST), Berlin/Dortmund, Germany, is implementing these new developments within the project GeoMarkt.NRW, a part of “Geographic Data Infrastructure”-project (GDI NRW). In 1999 the German state North-Rhine Westphalia launched this project in order to push forward the GeoInformation market in North-Rhine Westphalia by providing an open network for GeoInformation and geodata based services (Brox, Kuhn, Bishr 2000; Brüggemann 2000).

Portal Architecture in a Distributed Environment

Distributed Sources
GeoInformation is describing the world. The information is collected and stored in different ways, because everybody has a different view. The data description varies from sector to sector and from institution to institution. It is often, that a different sector uses a quite different terminology, because of its viewpoint. There are many disadvantages with the fact of distributed data sources. But an important advantage is the possibility to maintain data by its owner. The world is changing quickly and therefore maintenance of geodata is essential for its value. Copyrights and value are as well an important factor. Therefore, there is a need to support a communication in a distributed environment. This interoperability is only possible, if standards are used to exchange data.

Merging geo-referenced Information
GeoInformation can be often visualized as maps. With the new OGC Web Map Server specification (Jeff de La Beaujardière, 2001), different layers from different sources can be merged. A typical example is the visualization of weather and road information. Another example would be marketing GeoInformation and the position of shops.

Trading Player
Higher value geodata, like marketing data, will not be free available. If there is a demand, there will be an offer. A typical relationship is a 1:1, supplier and customer. The geo-sector has the great advantage, that the digital geo-data can be distributed via the internet on-demand. With the introduction of cascaded OGC Web Services, like the WebMapServer, the three-tier portrayal architecture is common. There is a 1:1:n relationship between customer, portal and many data supplier.

A primary goal of the OGC Web interoperability program is a low level of necessary installation effort for user. Professional GIS Software is not required, which reduces costs and makes it easier for nonprofessionals to use geo-referenced data. Less maintenance is required, if most logic is concentrated on a server. The User is known in a professional B2B relationship. The portal is the entry point for every user. It serves a unique Look&Feel over all applications. It manages the user-administration. In the case of cascaded services, it acts as an assembly layer. An example is the OGC Web Map Server, which provides a map with a set of layers from different sources. Another task of a portal is to organise different data supplier and their sources. A way is to set up a search application for the user. Another goal in the commercial scenario are negotiations and contracts about prices, licensing and other conditions. The user has the advantage to get much more data within the same, known system and perhaps with a harmonised licensing.

A Service is designed for a special task. This software package has an internet interface based on the HTTP protocol. Modern service communication is based on a HTTP request and XML response protocol. An enhanced protocol with a XML request is SOAP (Box, Ehnebuske, Kakiyaya, 2001). Web Services offer an organizational advantage. They may be run on the same webserver as the portal (internal) or on the supplier site (external). The configuration is changed by another URL.

Portal Architecture With Distrubuted Services

Figure 1 shows a typical three-tier architecture with some services. In this example, a OGC WebCoverage Service (WCS), WebMap Service (WMS) and a WebFeature Service (WFS) is used as a known services. The WPOS service is Web Pricing & Ordering Service, which manages pricing and ordering communication. A necessary data format to exchange pricing information like metadata is described in Chapter 4.

Fig 1. Three-tier portal architecture

Methods Of Complex Pricing and Licensing Used Today

The trade of geo data is in a time of change. The classical product was a map. It was not configurable and could not be easily processed to another product or service. With the introduction of digital data as a product to be traded, most pricing and licensing models were useless. Some of the new price models for digital data are quite complex, because they take many configuration parameters into account. The absolute prices per unit are in many European states quite high. Therefore only necessary data will be configured and used. There are some general approaches:

Licensing Models
The property GeoInformation cannot be purchased. It is only possible to buy a license for this product. Trading GeoInformation is in many cases similar like trading software. But GeoInformation as data can be used by different specialized applications. Therefore, the pricing is different. This list of elements are preselected. Other elements may be common as well. A processing fee is very typical. It will be charged for each order for general efforts. Some data suppliers have a fixed fee as a result of the full automated production. This part of the general package is a fee for the use of the data. In some cases it is limited by time or by the number of workstations. Private or educational use will be treated very often much different than commercial use. The commercial license is an additional fee for a product. An example is a software on CD-ROMS with a commercial fee of 3 % of its selling price in the stores. The commercial component is very irregular. It is often part of negotiations.

Pricing Models
The market with geo-referenced Information is still developing. Therefore many different pricing models are in use today. In general, there is a certain relationship between the selected price model and the history of the data supplier. Some data suppliers have their roots in other branches or are founded a few years ago. In this paper some popular methods are described and discussed to focus the large variety to be supported by a common data format.

After introducing the first CAD Systems in the geo branch, vector graphics could be used to express georeferenced objects. The determination of the number of objects or lines in selected area is very easy by using a CAD System. In some cases the number of lines is taken as a main pricing parameter. In some other cases it is the number of objects. There is a close relationship between the density of geodata, the effort to survey, the effort to maintain and their price. To give an example, each line could cost 0.1 cent. The price of the same number of square-kilometer once in the city center will be much higher than in the forest. The number of inhabitants in a selected area is another approach for the main price parameter. A high concentration of people requires more infrastructures. On the other hand, geo-referenced Information in a high-populated area has a higher value, because more people could use it.

Another approach is the pre-definition of datasets by administrative borders. Each unit has an own price. A pre-configured product has the classical disadvantage that potential applications, which are situated at the border, are forced to purchase two or more datasets. To reduce this fact, small units like cities or even vote districts are used. On the other hand, administrative borders are quite known and often used.

For the basic definition of a spatial object in a reference system, co-ordinates are used. Three or more coordinates easily define an area and with it a price. This approach is universal. It does not depend on any other parameter. The disadvantage is, that it does not include any densities. The zone model pre-defines zones with a different coefficient and a basic price per area. Typical zones are center of cities, urban areas with lower population density and open landscape, e.g. forests. The zone model is a compromise. Different average efforts are expressed with different price coefficients per zone. This approach has several advantages:

A potential user is able to determine a price without any direct supplier contact.
Due to the fact that the price model does not need a direct access, it can be printed on paper and distributed.
It is often accepted, that a price increases from low populated land to center of cities.
A chain of co-ordinates (polygon) and a priority list of zones can easily define and exchange the pricing zones.

Model Characteristics
Two principle distinctions are characteristic for all price models approaches: The models “Pricing by number of Objects or Lines”(3.2.1) and “Pricing by number of Inhabitants”(3.2.2) presume a direct access to the geo-database. Without an online access, it is impossible to offer a price. It is impossible for potential user to get a price out of off-line brochures or printouts. Pricing information is a kind of meta data, which should be treated independently from the GeoInformation. The other pricing models are independent. The complete model can be stored in a format and distributed by email or printed like meta data.

A Generic Formalised Price Model

A flexible Approach
A simple data format is not able to cover a different pricing system for each supplier. The pricing system of some data suppliers is based on the covered area. Other data suppliers calculate a price by the number of concerned objects. Other may use the usage to determine a price. Most data exchange standards for pricing are divided into data formats and into an extensive and fixed process description. The process is described in the specification. Software processes the data exchange along this documentation. BMEcat (Schmitz, Kelkar, Pastoors, 2001) and InGeo MDF (InGeoForum, 2000) are examples for this kind of product and price models.

A common example is the consideration of a net price N and the VAT percentage V. In the exchange format, there are two data fields, but no instruction how to handle these. The specification gives an (informal) instruction, for example: multiply value N and value V to get the gross price. This way is quite simple and effective. It reduces the exchange volume. It is very effective for developed, almost static and accepted standards.

The disadvantages are possible changes. If the specification needs to be changed, the software has to be rewritten and newly installed. Take for example a price model where different rebates apply for different parts of a product. This above-mentioned kind of exchange standard cannot cope with the enhanced requirements of a flexible price model in the geo sector. The solution is a much more general approach. Mathematical operations are important information for a price exchange. They are expressed as mathematical formula with variables. The result of the solved equation is the end price. An equation contains all required information for a price offer. With this approach all general business prices can be covered. By exchanging the price formula and some additional data, all required information could be transferred.

Basic Price Configuration Model
The basic model represents the price variety of all configurations of a product. The buyer is required to specify the configuration of the product he/she wants to acquire (see fig. 2). Theme layers and areas are examples for possible configurations in the geodata sector.

Fig 2. Basic Price Configuration Model

Each product may have an own price model. Therefore a product identifier organizes all pricing information. A set of data is necessary to describe a price. General information mainly includes texts. The calculation block contains product specific parameter and a mathematical price formula (see fig. 3). Each block is described in the following:

Fig 3. Structure of Basic Price Configuration Model

General Information. This block contains a number of basic data, like creation date/time and editor, version, title, valid territories and other data. The licensing information block contains the issue of wording, like right of use, copyright, devolution, duties, warranty and jurisdiction.

Calculation. The calculation block contains the functional pricing elements. It is divided into a list of parameter declarations, predefined-parameter formulae and the price formula itself.

Parameter. A parameter declaration consists of a unique name, a informal description in one or more languages and its units. The type system of parameter is based on physical and currency units. They are either basic units, e.g. [m], or combined by multiplication with other units, e.g. [$ / km²]. The configuration parameters are options for a product configuration. The customer defines his product by the selection or by the specification of values. An example is the choice of layers and the part-area to be bought, A = 10 [km²]. The pre-defined parameters are values excluded from the general pricing formula. Examples for pre-defined parameter are taxes or rebates.

Formulae. The predefined-parameter formulae define the values of the predefined parameter. Predefined parameter may depend on configuration parameter or other predefined parameter: For each predefined parameter p exactly one formula of form p = f exists, where the formula f is built of configuration parameter, predefined parameter, constant values and the usual mathematical operations. A simple example is the formula t = 1.16, which denotes a VAT of 16 %. The price formula is the core formula to calculate the price depending on the configuration parameter and the predefined parameter. The result of the price formula is the price of the product as specified by the user. The type system of formulae, i.e. the unit system for formulae, is derived by the parameter unit system. For all formulae the unit of the left side has to be equal to the unit of the right side. This condition may be used for an additional type check of a price model. Clearly, in this type system the usual cancel down rule must apply, e.g. ( [$] · [km²])/[km²] = [$]. A pricing system is valid if and only if the price is uniquely defined for all possible values of the configuration parameters. An efficiently computable criterion to check this condition has still to be defined by applying laws from algebra.

Including external Web Services
In some case, additional information cannot be stored in the data format. Examples are the data-depending pricing models (3.3.1). They depend on the number of objects, which cannot be determined without an online access to a database-service. Another example is the calculation of the covered area, which could be stored inside the pricing model. But a solution with specialized (open) Web service may be much more suitable.

Fig 6. Price Model with Web Service Call

The pricing format needs some more structure to cover the target URL request and the resulting parameter. A Web Service Call should be requested before the final calculation for a better internal processing.

XML Representations of Price Models
The XML standard is quite suitable to express this generic formalized pricing model because of its hierarchic characteristics. Another reason to use XML is that pricing data is a kind of Meta data. The geographic Meta data standard ISO19115 is expressed in XML. The mathematical markup language, MathML, may be use to express the price formula. MathML is based on the XML standard. It offers a large variety with over 50 mathematical operations and it is a w3c standard. However XML does not include a type system for his formulae. XML Schema may help to express different data types like currencies much more exactly.

Outlook

The introduction of a Web Pricing & Ordering Service (WPOS) is an approach to solve the simple Question “How much does it cost” in a distributed environment. But the pricing models are still very divergent and new proposals for 2002 are not less complex than current models. The exchange needs an effort.

Currently, the Fraunhofer ISST is planing the web Testbed 2.0 with five or more other companies and universities to prove a distributed network, based on OGC and WPOS draft specification. The test period will last until the INTERGEO exhibition 2002 (September) in Köln, Germany. There will be a public demonstration on the fair.

References

Box, Ehnebuske, Kakiyaya, 2001. Don Box, David Ehnebuske, Gopal Kakiyaya: SOAP 1.1. Simple Object Access Protocol. World Wide Web Consortium (W3C), Note, May 8th 2000 (www.w3c.org)
Brox, Kuhn, Bishr, 2000. Christoph Brox, Werner Kuhn, Yaser Bishr: Conception of a Geospatial Infrastructure in Northrhine-Westphalia, Germany, Urban and Regional Data Management Symposium (UDMS) , Delft, The Netherlands, September 13-15, 2000
Holtkamp, 2000. Bernhard Holtkamp: Fraunhofer ISST: GEOMARKT.NRW – Eine E-Commerce-Lösung für Geodaten. In: NÖV – Nachrichten aus dem öffentlichen Vermessungsdienst Nordrhein-Westfalen, Heft 2/2000, Innenministerium des Landes Nordrhein-Westfalen, Düsseldorf (An e-Commerce-Solution for Geodata. In: „NÖV“ – land surveying office North-rhine Westphalia news, 2/2000, Ministry of the Interior, Düsseldorf)
InGeoForum, 2000. InGeo-MDF 2.1. InGeoForum, July 2000 (www.ingeoforum.de)
ISO/TC 211, 2001. ISO Technical Committee 211: 19115 final, Geographic information – Metadata, January 30th 2001
Jeff de La Beaujardière, 2001. Web Map Server Interface Implementation Specification. Open GIS Consortium, June (www.opengis.org)