The translation process follows a pipeline model. Raw shapes and data (meat) enter the pipeline, are processed by various stages until rover binary exits the end (sausage).
In general the flow is strictly linear. Labelling (derivation) is a little weird, but not too strange.
This is where shapes and data enter the pipeline. Some initial processing is done as well.
This includes: * coordinate system transformation * trimming to bounds * hole cutting * adding x and y fields
This is where data types are assigned.
This includes: * initial naming * splitting * merging * definition of new data types
This is where data transformations are applied based on our newly-identified datatypes.
Transforms are divided generally into merge transforms and scripted transforms. Configuration determines which ones are applied to objects of each datatype, and in what order they are applied.
This is where graphic types are assigned. What we now call “graphic type” used to be called “style” in the old translator, hence the name.
This process is just like data type assignment, and includes: * initial naming * splitting * merging * definition of new graphic types
In this stage, scripted shape transforms are applied to the shapes. Configuration determines which ones are applied to shapes of each graphic type, and in what order they are applied.
This stage is generally referred to as “labeling”. What we call labeling is very powerful and general purpose, however, and generates new map objects by deriving them from old ones in various ways.
The derivations (labels) to apply are based on graphic type, not data type.
This stage sets the values used to build the find item indexes.
This stage sets the connectivity values used to build electrical connectivity.
This stage tracks the data flowing through for reporting purposes and to drive parts of the publisher GUI.
This stage is optional. It’s generally on for publishing, and off for dynamic mapsets.
This stage applies the datatype field configuration to eliminate disabled fields. If no fields are enabled, all data for that shape is dropped (setting the dataId to zero and making it unselectable in the normal viewer).
This stage is only used by the publisher, not dynamic mapsets.
This stage tosses out the “chaff” - shapes and data that are empty, degenerate, or otherwise invalid or useless.
Currently, the only things thrown out are text shapes that have no text. Everything else passes.
This stage exports data for datatypes where it is configured. Currently there are two exports - shapefile and csv. However, as of 4.5.14 this facility allows pluggable exports, so we may see more options in the future.
The output stage is configurable based on how the mapset is run. For publishing, it is always a TiledRoverBuilder object.
At this point, the data is more or less massaged and in its final abstract form.
The TiledRoverBuilder’s job is to convert it to binary format, write it to files on disk, and sort and index the files as needed.