Graphic Formats for Mapping Applications

Besides others, a mapping application's task is it to display map data on a computer screen or mobile device. First and foremost this is about displaying the shape or image of the real world objects that are represented by map data. Two different ways exist for representing images in computer graphics. One of these representations is raster graphics. A raster graphic is a representation of images as a collection of pixels. Raster graphics are commonly used for photo realistic images such as satellite photos. Synonyms for the term raster graphics are raster images, raster maps, bitmaps, or pixel graphics. In this document those terms are used interchangeably. Subtle differences that might exist are beyond the context of this document.

The second way for image representation in computer graphics is the use of geometrical primitives such as points, lines, and polygons. When images are represented this way, the graphics are called vector graphics. Vector graphics are geometric models of objects and because of the existence of geometric information vector graphics are computational. Objects can be scaled up and down, stretched or compressed, moved or rotated. Figure 1.1 shows seamless zooming of a vector graphic.

Furthermore, objects of a vector graphic have a location that sets them in relation to a space. The location is expressed in latitude and longitude coordinates. Objects can be moved within the space by changing the coordinates of the object. Distances between two or more objects can also be calculated easily with the geometric information that a vector graphic provides.

These operations are not possible when objects are represented as a collection of pixels like they are in raster graphics. For example, scaling of raster graphics is not possible without loosing quality.

Geographical information systems (GIS) and digital map data providers store and distribute the map data in vector formats. That way, the geometric information for objects is maintained. Think of the objects geometry as being stored as lines, polygons, or points. There can be millions of objects belonging to one map. When objects are stored as vectors they also have a relationship to corresponding object attributes. This makes the map rich and full of valuable information.

The next three paragraphs compare different techniques for the interaction between mapping clients with mapping servers. The paragraphs show advantages and disadvantages of the techniques and show what to look for when choosing a mapping technology.

Figure 1.1: Seamless zooming of a vector map

Bitmap Servers

Mapping applications that are based on bitmaps follow a relatively simple protocol. The client requests a map from the map server by specifying a rectangular area and scale or zoom factor. The map server generates raster images from data out of a digital map database and sends the raster image back to the client. The image can easily be displayed by the client. No further client-side processing is necessary. The server either creates raster images on-the-fly for every request or raster images are pre-rendered and stored on the server. Using pre-rendered raster images reduces the processing time on the server and with that the waiting time for the client.

One drawback of the simple bitmap server protocol is that mapping applications can only provide limited interactivity to client users. For example, if the client user wants to zoom in to see details of an area, a new image has to be requested from the server. The server has to send a complete new image. A new raster image also has to be requested from the server if the client pans too far into any direction of the map. The network overhead with this solution can be quite large and results are slow performing client applications.

Vector Map Extraction

With the vector map extraction technique mapping clients receive vector data from the map server and render the data to images themselves. One advantage is that the server can send the vector data in a compressed format. This reduces the amount of data that a server sends and speeds up the process. Another advantage over the bitmap server approach is that it allows for more client interactivity because algorithms can be applied to the objects geometry. For example, seamless zooming is possible, distances between objects can be measured, and objects can be moved on the map. The extracted vector map can also be stored on the client's local file system. The client can then be taken offline and still interact with the extracted map.

Because of possible data compression the vector extraction approach requires less network traffic than the bitmap approach. But vector extraction can still be slow if the client application needs to swap out images frequently. If the client pans out too far into one direction where the display requires map data that are not available on the client yet then a new map is required. This is the same as with the bitmap server approach discussed previously. The transition from one image to the next will not always appear smooth on the client's display because network traffic is involved. A standard for vector extraction is Scalable Vector Graphics (SVG). SVG is created by the World Wide Web Consortium (W3C) as an open standard for two-dimensional vector graphics.

Vector Map Streaming Technology

Network traffic can be minimized if the client application continues to use the data that it has already available and only requests incremental updates from the server. For example, if a client application zooms into an area to show additional details, it will only require a request for the additional details, while the data already present on the client can still be accessed. The additional details that are commonly requested would be features such as minor streets, the shapes of buildings, or other features that were not displayed at the higher level.

Figure 1.2: Vector map streaming technology transfers incremental updates in small packages to mapping clients

Another example of functionality that takes advantage of data reuse and incremental updates is panning. If a client moves the visible map area continuously into one direction, then only that map data has to be sent from the server that appears in the visible area for the first time. All the other map data only needs to be repainted.

Mapsolute calls this approach vector map streaming technology. It is based on the map transfer protocol MapTP that combines vector data compression with incremental updates. The data packages sent from the server are much smaller and the server can send updates more frequently. Since the updates are so small, they will not be a burden on the network and will not affect the clients performance and responsiveness. A client application can also work asynchronous. It can start to display the data that is available on the client while it is waiting to receive more data from the server. For frequent moves this technique results in a constant stream of vector map data updates from the server. There is practically no delay visible on the client's display even for fast moves such as fast zooms or pans. Every action appears very smooth to the client, and provides a very interactive experience.

The technology makes it possible for mapping applications to offer continuous zooming for example from a continental view down to street level. Animated jumps from one location to another on the map can give users the impression to fly to the new location.

Mapping applications typically work in distributed environments where software clients from different network locations access map data and related information from a server. The network can be an intranet or the Internet and clients can be Web browsers, personal digital assistants (PDAs), or mobile phones. Many different architectures and configurations on different platforms are conceivable. But common for every distributed environment is the limiting factor of the network speed. While a 1000 Mbit/s LAN is much faster than a 50 kbit/s GPRS connection it is still slow compared to a local computers processing speed. Therefore, the system architect has to take the network limitations into consideration when designing the application. In any case it is crucial for distributed applications to limit the amount of data transferred between client and server. Otherwise slow performing client applications, which will not find acceptance in the user community, will be the result.

Service Interfaces

A service interface gives MapTP client applications access to services that go beyond operations performed on map data. Services build a gateway for mapping applications to spatial algorithms and to other functionality and data provided by existing infrastructure.

A service runs in its own process and communicates to a MapTP server using a protocol called MapTP Service. The goal of MapTP Services is it to allow the creation of an open, flexible, and distributed architecture. MapTP Services allow the utilization of existing application functionality and infrastructure without the need to upload or to convert any application specific, or business critical data. Uploading the data to a map server system could compromise data security. With MapTP Services the data stays secure on your servers.

MapTP provides a large number of spatial algorithms as services and provides Web service interfaces for those as well. Client applications use SOAP messages to send requests to the Web services. Web services give software architects the ultimate freedom to design real distributed systems.

Custom Data Integration

Besides basic map data, which is commonly provided by specialized map data vendors, every mapping application requires to work with all kinds of application and domain specific data. On a high level one can distinguish between client-side integration and server-side integration. There are some considerations that the application's architect should keep in mind when making design decisions.

If application specific data is only relevant to a specific user then client-side integration can be a fast and effective way to go. Client-side integration means that the client application loads the data from the local file system or connects to any other remote resource like a database server. Applications do not use any MapTP specific protocol to integrate the data. But MapTP does have programming interfaces that applications can use to display the data together with the map data.

An example for client-side data integration is a CRM system with integrated map that shows sales numbers such as revenue, sold products etc. per sales region. By selecting a sales region on the map the application reads the up-to-date sales information out of a relational database and displays the information on top of the selected region.

If the data is of interest for more than one client application or user or if the client application has no direct access to the data source then server-side data integration is preferred or is even required. For small amounts of data this can be done with a service that pushes data to clients. Chapter 2, MapTP Services, discusses this aspect.

If the amount of data is large then the most efficient way for client applications to access the data is to load custom maps from the server. Before a client application can load custom maps from the server a custom map service must build the maps and send them to the MapTP server. MapTP provides the programming interface for custom map services and the protocol for uploading the map to the server. The programming interface and protocol is called MapTP MapService.

A good example for a custom map is weather information. One application that has access to the weather data creates a custom map with it and uploads the map to a MapTP Server. From there many client applications request the custom map to display it on top of highways and city streets from the standard map.

Developer Support

MapTP is made for software developers. Evidence for this is the coverage of a variety of development platforms and development environments. The MapTP programming interface for building client applications is equally available for the Java and for the C++ programmer. A ActiveX component let the Visual Basic, Delphi, C++, or .NET programmer on Microsoft Windows operating systems develop mapping applications within the software development environments they are accustomed to. For the Web developer PHP and AJAX APIs provide full control over maps and map objects and just like for any other programming interface these APIs provide access to services such as routing and geocoding.

Scalability

Highly frequented Internet applications such as a portal for mapping and route planning receive thousands of requests within a short time frame. For those applications the workload at peek times can be too high for just a single MapTP server. Depending on the server load, clients can experience delays in response times. To increase the capacity, any number of MapTP servers can be placed behind a commercially available load balancer. In a load balanced environment a so called virtual server selects a physical server based on the current load. Those load balancers usually support a concept that is called persistence. If persistence is configured for the load balancer then subsequent client requests are all directed to the same physical server. That way it can make sense for the physical server to maintain session state that can be used for subsequent calls from the same client.

Maintaining client state is possible with the MapTP server due to the session-oriented MapTP protocol. The server holds session information for every client and remembers which map data was sent to a particular client already. Should the same client request the same data again then the server does not send anything. The server only sends additional details or map data of additional areas if a client requests it. This session-oriented protocol reduces network traffic tremendously and is essential for effective client-server communication.

Scalability was also an important factor for the design of the MapTP Services architecture discussed above. More than one instance of the same service can be connected to a MapTP server. The server dispatches client requests to the different service instances using its built-in load balancer. The MapTP Service protocol allows service instances to take advantage of session state even if they run in a load balanced environment. More details about session-orientation and load balancing services can be read in Chapter 2.4, Session-Orientation and Load Balancing of MapTP Services.

Openess

A frequently asked question to a software vendor is how open the software is. That is an important question because one thing customers don't want is to be locked-in with a vendor and its his technology. The following sections are meant to summarize openess that is characteristic for a mapping application implemented with MapTP. The answers touch on almost all aspects that have been discussed previously and that will be discussed in more depth in the coming sections.

While MapTP is not open in the sense of open source that is available under an open source license it is nevertheless in many regards an open system.

• MapTP is open to programmers. Extensive application programming interfaces (APIs) are provided that allow the tailoring of every aspect of mapping applications. All APIs are documented. In addition, a large part of the source code is available to the developer. The developer can use it as is, alter and customize it, or use it as example source code. Essential functionality that comprises the vector map processing, rendering, persistent maps, protocols and communication are not available in source code. But all these parts can be used to build mapping applications by using the API.
• MapTP is open to the integration with custom data. Custom data can be integrated client-side and rendered together with map data. This data will never be available on the server and thus will never be visible for other clients. It is always only local to the client application that loads the data.
• MapTP is open to functional integration. Service APIs allow access to spatial algorithms and to any existing information system or legacy application. MapTP provides a number of service implementations for spatial algorithms already. But mapping applications are not locked-in with the provided service implementations and can easily integrate services from other sources.
• MapTP is open to platform independent access via Web services. Web services are provided for services that run spatial algorithms and for a number of commands that control mapping clients from a remote client process.
• MapTP is open to a wide variety of map data formats. For customers this means that switching map data from one map data provider to another is not a problem. The mapping application and functionality does not need to be touched for this.

After this overview of the MapTP technology and environment the next chapters look at each of the subjects in more detail. Chapter 2, MapTP Services, shows how a services concept can be used to integrate with existing infrastructure. Chapter 3 shows different ways on how application or business specific custom data can be integrated into the mapping application.