Partner’s Rover format is a binary vector format optimized for small size and fast rendering.

It isn’t capitalized as such, but was originally an acronym: Read-Only Vector Engine for Rendering.

Rover Design Principles

Rover is optimized for rendering and data access speed. Maps are drawn and queried far more often than they are edited. So, it is optimized for reading rather than for editing.

Rover is optimized for small size. One of the optimizations is to reduce the precision of coordinates.

Rover is not a GIS format, and not intended to be the “data of record”. It should not be depended upon for accuracy or for fidelity with the original source of published data.

Rover Formats

There are three different formats for Rover, each with advantages and disadvantages designed to fit types of use.

The ‘’rover file’’ format is a set of files in a highly-optimized, proprietary binary format. It is read-only, must be published via batch process, but can handle virtually unlimited amounts of data. We have tested it with tens of millions of shapes with no performance degradation.

The ‘’rover database’’ format uses database tables, generally in an embedded database such as SQLite, to store shapes and associated data. This data can be published and replaced incrementally, which has advantages for interactive mapsets where individual items may be modified by the user. It can handle hundreds of thousands of shapes before degrading significantly. If it is editable, the file system must be editable as well.

The ‘’rover memory’’ format uses in-memory objects to store the data. It doesn’t use the file system at all, so is appropriate for read-only installations where interactive mapsets are required. It’s also very simple and efficient for small dynamic mapsets. However, large mapsets consume large amounts of memory and have poor performance; tens of thousands of shapes are about the limit for this format.

Table Of Contents

Previous topic


Next topic

Domain Analysis

This Page