This section describes the object model for the Rover system.
The general classes of cartographic shapes stored by Rover.
These geometric types of shape are available:
Image shapes are defined by:
Area shapes are defined by:
Line shapes are defined by:
Point shapes are defined by:
Text shapes are defined by:
The data portion of a rover element.
A rover data item has:
An individual geographic data element, composed of typed data, shapes, and parts. Each of these is optional; there may be no data set, or no shapes, or no parts.
Parts are just pointers to other rover elements that are considered to be associated with and comprise the one containing the pointers.
This is called map data item in v4.4, but in v5.0 rover element is preferred since data is just part of its function.
A collection of Rover data, largely independent from other Rover sets.
Rover sets contain this descriptive metadata:
this data:
and this rendering configuration:
A geographic shape.
Rover shapes have this data:
A grid of tiles, configured to be appropriate for a certain scale range.
An LOD has:
A tile in an LOD grid.
Rover tiles cover a specific area in map units, and contain some number of rover shapes. They have their own internal coordinate representation since those coordinates only have to represent points within the area.
Tiles have a cell coordinate value (cellX and cellY), which provides the identifier for the tile and also, along with the LOD configuration, provides the numbers needed to convert from tile coordinates to map
A set of numbers describing a location within a coordinate system.
The definition and valid values of the numbers depend upon the coordinate system itself.
Refer to the definitions here for these:
A coordinate system specifies the framework for locating something in space.
We deal with a lot of different coordinate systems during rendering, so this can be confusing. See the definition to coordinate and thence the various types of coordinate.
An XY or XYZ coordinate inside a tile, using the internal tile coordinate system.
In the version 4.4 format, 2-byte unsigned integers are used for x and y inside a tile.
Ratio of geographic size in map units (e.g. feet) to screen size in pixels. Also called display scale.
Display scale should generally note the units (feet/pixel) if used outside of the system. Note that this differs from the cartographic scale.
Ratio of the printed size to the geographic size.
E.g. 1/100 or 1:100 scale refers to a scale where an object 100 feet long is 1 foot long on a printed map. This a pure ratio since the same units are used for both parts of the ratio (e.g. feet/feet).
This is problematic with computer displays, since computer displays are measured in pixels and the “real world” size of a rendered image can vary enormously depending on the monitor or projector used. Consider the projector in particular; you could modify the cartographic (apparent) scale of the display by simply moving the projector closer or further from the screen or wall, without the software having any idea that the apparent scale has changed. Thus, there is no “right” conversion between screen scale and cartographic scale.
Partner uses the convention that a pixel is 1/144 inches square. This roughly corresponds to apparent size on most screens and works well when printed. The standard printing unit “pica” is 1/72 inch, and this is half that size, which has other advantages when dealing with printing frameworks.
Thus, in Partner, cartographic scale can be calculated as
cartographic_scale = 1 / (display_scale * units_to_inches * 144)
So, a display scale 10 feet per pixel corresponds to a cartographic scale of 1:17280, and a cartographic scale of 1:1 corresponds to a display scale of approximately 0.0005787 feet/pixel.
Minimum size representable, in map units.
Usage depends on context. On screen, a pixel is the minimum display unit, so the granularity on a display is the current display scale (size of a pixel in map units).
In a rover tile, the granularity is determined by the distance between two consecutive tile coordinates. In version 4.4, tile coordinates are 2-byte unsigned integers, so the tile granularity is limited by the format to 1/65535 the width of the tile. During publishing, this is either configured manually or automatically calculated to the minimum zoom scale configured. Whichever it is, that’s the minimum representable distance between drawn points or line vertices, and if it’s substantially larger than the display scale, graphics may appear strange or disconnected.
Non-tiled rovers, such as those used for highlighting a selection, also have a granularity. In 4.4, these are stored using 4-byte single-precision IEEE floats, which are not particularly accurate. Their granularity depends on the map coordinate system itself, since single-precision gives 6-9 decimal points of accuracy. So, if your map coordinates are in the millions, you would have a granularity somewhere between 0.001 and 1.0.