©The Rothwell Group, L. P. 2011. All rights reserved.
PaleoGIS™ for ArcGIS™
The Rothwell Group, L. P.
PaleoGIS Plate Modeler Manual Version 4.2
This guide provides advanced users with the information required to create, import, and configure plate models for use with PaleoGIS for ArcGIS™. This guide assumes the user already has the spatial component of your plate model in an ESRI-compatible format (usually as a shapefile), and that the non-spatial rotation data are in a format that can be imported into MS Access (usually as a tab, comma, or space-delimited text file). The following instructions will specify how to convert your existing plate model into the PaleoGIS “Plate Model File” format and make this file work within PaleoGIS.
There are two important files in this process of creating a plate model for PaleoGIS: the Plate Model File and the PaleoGIS Settings File. Both of these files are Personal Geodatabases and end in the .mdb file extension. This file format is a Microsoft Access Database file format, which is used by ArcGIS to create a Personal Geodatabase. PaleoGIS uses these Personal Geodatabases to store both the spatial and non-spatial plate model data and settings in single mdb files on your system. The easiest way to convert your existing plate model into the PaleoGIS format is to use Plate Model File template as a starting point so you will not need to create the personal geodatabase and all the tables that are needed from scratch. The template is called Published Plate Model Template, and it can be downloaded from the www.paleogis.com website under the User’s Manual link. To access the template you will first need to register on www.paleogis.com website. Once you have successfully created you custom Plate Model File, we will discuss adding a link to the Plate Model File from the PaleoGIS Settings File. The PaleoGIS Settings File contains all the application specific settings and needs to know where the Plate Model Files are located. Note: the PaleoGIS Settings File is installed by PaleoGIS and you will not need to create a new one.
Once you have a copy of the template Plate Model File you will want to follow the steps outlined below. Each of these steps is discussed in more detail following the overview section below.
The Plate Model File can be placed anywhere on the computer or network and it can be named anything as long as the path and name are referenced correctly in the PaleoGIS Settings File. (This will be explained in detail in a later section of this document.) The Plate Model File, like the PaleoGIS Settings File, is simply a Personal geodatabase file that contains a number of extra tables. Most of these tables, including the ones prefixed with “GDB_” are tables created by ArcGIS in order to make the file operate as a Personal Geodatabase. DON NOT MODIFY THESE TABLES. This document describes only the process for modifying the tables that are important to importing and configuring Plate Model File(s) in PaleoGIS. It is easiest to use Microsoft Access in order to open and edit this file, although you can use ArcMap to view and modify it as well.
The Plate Model File contains four important items: 1) the spatial data that makes up the geographic expression of the model, 2) the Rotation Table, 3) a Model Settings Table, and 4) the Timescale table.
The spatial data associated with a Published Plate Model for the PaleoGIS are stored in the Plate Model File in the form of one or more ESRI feature classes. To make your spatial data available to PaleoGIS in the Published Plate Model, simply import all the shapefiles into the personal geodatabase file that is your “Plate Model File” using the standard ArcToolbox Tools like “FeatureclassToFeatureClass” in the “Conversion Tools” Toolbox. In the personal geodatabase, these feature classes will appear as two tables. In the image above, the spatial data for this example Published Plate Model are stored in a single feature class called “PlatePolygons” that is represented in the personal geodatabase as a table called “PlatePolygons” and another table called “PlatePolygons_Shape_Index”. The plate polygon feature class can be named anything as long as it is referenced correctly in the Settings Table in this file. Do NOT modify these feature class tables directly from Microsoft Access; only use ArcCatalog or ArcMap to create and ArcMap to modify feature classes in a Personal geodatabase.
The absolute minimum amount of spatial data required by the PaleoGIS for a Published Plate Model is a single polygon feature class, commonly called the “Cookie Cutter” or the “Plate Polygons”. This feature class is called the “Cookie Cutter” because it used internally by the PaleoGIS to assign plate numbers and appearance/disappearance ages to external data sets that do not have them using an intersection process. The “Cookie Cutter” can also be the one and only layer displayed by the PaleoGIS by default to the user, but commonly there are additional layers provided to enhance the model, like coastline layers, city locations, and any other point, line, or polygon data you wish to provide the user.
The minimum attribute columns for the Cookie Cutter feature class to function correctly for PaleoGIS are columns that provide the age of plate appearance (Ma), age of plate disappearance (Ma), and the plate number. The Model Settings Table section below allows the names of these columns to be configurable, but they are usually named “APPEARANCE”, “DISAPPEARA”, and “PLATE_CODE”. During the intersection (or “Cookie Cutter”) process, these attributes are transferred to whatever data does not already contain plate, appearance, and disappearance data. If any additional columns are present, they will also be transferred. The most common additional column is a “plate name” column.
The Rotation Table contains records that define the motion history of the plates in the Published Plate Model. This table can be named anything as long as it is referenced properly in the Model Settings Table. This table must contain columns which are usually named “PLATEID”, “AGE”, “LAT”, “LON”, “ANGLE”, “REF_PLATE”, and “COMMENT”. These names are configurable in the “T_Model_Settings” table, which is described in Step 4. In addition, the table must contain an auto-numbered “ID” column. This column MUST be called “ID” (not “OBJECTID”) or it will not work with PaleoGIS. The task for this step in the process is to simply import your rotation data into the table in MS Access using the built-in “Get external data…” MS Access wizard. The end result should look something like the table below.
The PaleoGIS assumes that every plate model has one timescale associated with it, to which all the ages are referenced. This timescale MUST be embedded as a simple MS Access table using the table structure defined below. A timescale table (DNAG99) exists in the template Plate Model File. You can use it or import your own timescale using this format. The table must include 3 columns: the name of the time interval, a column for the start of the time interval and and a column for the end of the time interval. The actual names of these columns are configurable in the “T_Model_Settings” table, which is described in Step 4, but they are usually called “NAME”, “OLDER”, and “YOUNGER. The table may also contain “ID” and/or “OBJECTID” columns but these are not required.
Every Published Plate Model understood by the PaleoGIS must contain a table called “T_Model_Settings”. This name is hard-wired and is not configurable. the T_Model_Settings table contains sets of name/value pairs which provide a number of configuration options for your plate model. The plate model will not work correctly unless these values are configured properly.
Settings that end in an underscore and then a number (i.e. APPEARS_COLUMN_1) can actually be added any number of times to the table with a sequential incremented numeric suffix. In other words there would be three valid possible values for the age of appearance column in the plate polygon attribute table if these three settings existed: APPEARS_COLUMN_1, APPEARS_COLUMN_2, and APPEARS_COLUMN_3.
In some of the settings you will notice the string $PGD$. PaleoGIS simply replaces this string with the file system path to the PaleoGIS Settings File itself. This tells the application to look inside this file instead of an external file. It is also acceptable to use any standard operating system environmental variables like %TEMP% or %USERPROFILE% or any environmental variables set by the user. The values of %TEMP% and %USERPROFILE% will be replaced by the system values of “C:\Documents and Settings\<user profile>\Local Settings\Temp” and “C:\Documents and Settings\<user profile>”, respectively.
Many of the settings contain a couple of values separated by a pipe character (“|”). This is often a connection string and table name or a file path and table name. Be especially careful not to introduce typos when modifying these settings. Also, notice that the connection string settings contain a “DataSource” value that often utilizes the environmental variables discussed above. Please see Appendix C in this document for a complete list of Published Plate Model Settings.
The most common way that a user will make the PaleoGIS aware of a newly prepared Published Plate Model is to use the PaleoGIS “Configuration Window”. Plate model files can also be added to the PaleoGIS using the Register Model button in the Configuration window, as seen below.
Alternatively, a user can manually edit the PaleoGIS Settings File, which stores all PaleoGIS configuration settings and “points” to other resources that may be needed by the application including any number of Plate Model File(s) you have built or purchased. By default, the PaleoGIS Settings File is named “PaleoGIS_settings.mdb” and is placed in the installation directory at C:\Program Files\EIMT\PaleoGIS\PaleoGIS_settings.mdb. This file is installed by PaleoGIS and you will not need to create a new one.
It is easiest to use the Microsoft Access software in order to open and edit this table, although you can use ArcCatalog or ArcMap to view and ArcMap to modify this file as well. When opened, you will see that it contains many of the same tables as the Plate Model File, mostly created by ESRI when the personal geodatabase was created.
Ignore these tables. This guide documents the actions required to make the PaleoGIS aware of a new plate model – it requires the updating of just one table. This table is called “T_PaleoGIS_Models”.
The PaleoGIS can work with any number of Published Plate Models, as long as they adhere to this standard. The T_PaleoGIS_Models table contains a list of Plate Model File(s) loaded into the PaleoGIS. The “Name” column is simply a friendly name for the plate model, which appears in many places within PaleoGIS. The “Value” column is a connection string and a table name separated by the pipe (|) character. Just copy and paste an existing connection string and make sure that the table name is in fact the name of the model settings table in the Plate Model File, called “T_MODEL_SETTINGS”, and which was discussed above.
Finally, you need to have two additional tables present in the Plate Model File. These tables are in the template plate model file and can be imported using MS Access tools if you did not build your plate model from the template. The tables are normally called PLATENAM and DATATYPE, but can be named anything as long as the T_Model_Settings table references correctly using the setting values called DATATYPE_NAME_MAPPING and NUMBER_NAME_MAPPING (see section 5 for details). These tables do not need to contain any data, but they must be present.
If you have completed all of these steps correctly, you will be able to select your imported plate model from the dropdown list in PaleoGIS and press the “Load” button. If you receive an error message, then you should review the settings again to ensure that everything is configured properly. Once everything is configured correctly, it is common practice to us the standard Windows File Property dialog box to mark the Published Plate model as ‘read-only”. This should discourage others from messing up your hard work!
This section contains tips and tricks for the advanced plate modeler that make plate models run better in PaleoGIS. Common problems that we see with plate models in PaleoGIS are documented as well as suggestions on custom settings to include in your plate model. Please review each of these items before releasing a demo plate model to The Rothwell Group, L.P. or a full plate model to your customers.
Try not to create multipart polygons in your plate model unless they are donut hole polygons. Plate Models must contain polygons that only contain 1 exterior ring. Multipart polygons cause problems conceptually and programmatically in plate modeling. Raster reconstructions will fail in PaleoGIS if multipart polygons are encountered. It is fine to include polygons with interior rings (often called donut holes).
You can use the ArcToolbox tool called "Multipart To Singlepart" in order to remove existing multipart polygons. You can also find and remove multipart polygons individually using the editing toolbar. Start the editor and open the "Sketch Properties" window (button on far right of editor toolbar). Then open the attribute table for the plate layer and select a record. When you select a record you will see the Sketch Properties window populate with the vertice information of the feature. You will see multiple "parts" if it is multipart or has donuts. Don't worry about the donuts they are fine. Just fix the multipart (ones with multiple exterior rings).
Make sure to run the "Check Geometry" and "Repair Geometry" tools from ArcToolbox > Data Management Tools > Features or the Repair Layer tool from the PaleoGIS context menu tools before releasing a new plate model. Bad geometry of any kind can cause problems in plate modeling.
Do not add unnecessary vertices to your plate model polygons or any additional display layers because they will only slow the reconstruction and animation process down in PaleoGIS. You can use the generalization tools in PaleoGIS to perform this task on feature classes or individual geometries.
Make sure that the plate model feature classes contain an OBJECTID field. If it is named something else like OBJECTID_1 (which may happen during some geoprocessing tasks) then PaleoGIS may throw errors for some functionality.
Make sure to remove unnecessary attributes from the plate model layers that you distribute. These attributes will slow down tasks in PaleoGIS and confuse your clients.
Make sure that the T_Model_Settings table has a unique autonumber id called "ID", not "OBJECTID". This is a common mistake that keeps the model from working with the Plate Moving Toolbar.
Poles of rotation are handled a bit differently in PaleoGIS than in some other plate modeling software packages. We support storing all plate model information (features and poles of rotation) as records in relational database tables, instead of simple text files. This is an important improvement over the traditional sequence based text file format because it allows for improved performance, workflows, backups, collaboration, etc. All the benefits of storing any type of data in a database are now extended to plate modeling.
A crossover is used to perform a transition between reference plates for a given plate at a given age. Each crossovers is represented in the rotation table by two poles of rotation: one containing the reference plate for before the transition and one containing the reference plate for after the transition.
There are two methods (described in detail below) for implementing crossovers in the rotation table that are compatible with PaleoGIS:
Method 1) Make age values on both sides of the crossover unique.
Method 2) Use the same age value for both sides of the crossover.
Making the age values on both sides of the crossover unique is the most robust method for implementing crossovers. With this method, the age on the younger side of the crossover should be very slightly less than the age on the older side of the crossover, or the age on the older side of the crossover should be very slightly greater than the age on the younger side of the crossover. The age values can be carried out to up to 15 decimal places in order to minimize the age delta between the two poles.
This method provides complete control over when the reference plate transition occurs. For example, for a plate with a crossover at 20 Ma, if the if the age for the pole on the younger side of the crossover is 19.9999 Ma, and the age for the older side is 20 Ma, reconstructions at 19.9999 Ma and younger will use the younger pole (and its reference plate) to calculate the reconstructed location for the plate and reconstructions to 20 Ma and greater will use the older pole.
Note: For consecutive crossovers (i.e., two more crossovers occurring at ages which are not separated by at least one age with a non-crossover pole) this method must be used to insure that the correct reference plate is being use for reconstructions at or between the consecutive crossover ages. This is especially important for plates where the reference plate before and after the two crossovers is the same, such as in the example below where the reference plate before 124 Ma and after 132.09999 Ma is 702.
Method 1 for implementing crossovers is illustrated in the figure below where there are three crossovers for plate 501 at 83.5, 124, and 132.1 Ma. The age value of the first record in each crossover pair has been set to be 0.00001 smaller than the second record.
In this method for handling crossovers, the same age value is used for both poles in the crossover pair. In this case, reconstructions to ages younger than the crossover will use the younger pole in the calculation of the interpolated reconstruction pole for the plate, and reconstructions to ages older than the crossover will use the older pole. However, for reconstructions to the exact crossover age, either of the crossover poles might be used for the reconstruction because PaleoGIS uses the first pole it encounters when one or more poles exist for an exact age (i.e., if no pole interpolation is required). The ID column numbering of the two poles relative to each other in the table does not guarantee which of the two poles will be selected first during reconstructions to the exact crossover age due to the nature of database queries. As a result, if it is important in your model to have precise control over which pole is used at the exact crossover age, then crossovers should be implemented using Method 1.
Note that crossovers using Method 2 are the only case in PaleoGIS where a plate is allowed to have more than one pole at the same age.
Note: For consecutive crossovers (i.e., two more crossovers occurring at ages which are not separated by at least one age with a non-crossover pole) this Method 1 must be used to insure that the correct reference plate is being use for reconstructions at or between the consecutive crossover ages. This is especially important when there are more than two consecutive crossovers and for cases where the reference plate before and after two crossovers is the same, such as in the example shown in the Method 1 where the reference plate before 124 Ma and after 132.09999 Ma is 702.
Method 2 for implementing crossovers is illustrated in the figure below where there is a crossover for plate 501 at 83.5 Ma.
All crossovers in PaleoGIS must be implemented with a pair of poles using either Method 1 or Method 2 described above. Transitions between reference plates using only a single pole at the crossover age will not work correctly in PaleoGIS. For example, in the figure below plate 203 changes reference plate from 701 to 926, however, the oldest pole with reference plate 701 is at age 160 Ma, while the youngest pole with reference plate 929 is at age 180 Ma. Therefore, PaleoGIS cannot determine if the reference plate transition was supposed to occur at 160 Ma or 180 Ma, and as a result, for reconstructions to ages between 160 Ma and 180 Ma the reference frame is ambiguous so the reconstruction pole cannot be correctly interpolated. In these cases PaleoGIS defaults to no rotation for the plate.
Contains name of age column in the rotation table, normally set to “age”
Normally set to “APPEARANCE”
This is a comma separated list of plate codes that will be ignored when performing reconstructions
The text in this setting will be displayed as a label at the bottom of each reconstruction window. This normally contains the copyright notice for the data, if one is required. You can also add some additional values separated by pipe characters to customize the citation format. <Citation (String)>|<Font Name (string)>|<Font Size (integer)>|<bold (Boolean)>|<Underline (Boolean)>|<Red (integer)>|<Green (integer)>|<Blue (integer)>
The Red, Green, and Blue values must be integers between 0 and 255, inclusive.
This setting value contains a connection string and feature class name separated by a pipe character. The path to a polygon layer that will be used to intersect features and assign plate codes to them. Then these features can be rotated according to the motion history of the intersected plate. This is almost always set to the path and name of the Plate Polygons feature class in this file so the value is normally “$PGD$|PlatePolygons”
Obsolete but table must exist in the plate model for now (see section 6)
Used by deformable plates algorithm and documented elsewhere
Used by deformable plates algorithm
Normally set to “DISAPPEARA”
These settings contains a path and feature class name separated by a pipe character. The path and name correspond to a feature class that should be loaded when the user presses the “Load” button in the configuration window. This must be set for the Plate Polygons feature class, but often other settings are added for additional feature classes of interest. It is also possible to add the “DATABASE_LAYERS” prefix to the feature class name if you have saved .lyr files in the plate model personal geodatabase for this feature class (ex. $PGD$|DATABASE_LAYERS\PlatePolygons). If a .lyr is saved in the plate model personal geodatabase and the value is set like the example then the display layer will load using the renderer stored in the .lyr file instead of using random colors. This parameter supports vector based feature classes only and does not support any raster formats. Below is a list of example values that can be used for this parameter.
C:\Documents and Settings\Arwen Vaughan\Application Data\ESRI\ArcCatalog\MySDEInstance.sde|MyFeatureclass
This is the oldest age that the plate model should be reconstructed to. PaleoGIS will not reconstruct to ages greater than this value. PaleoGIS will also display a message warning the user that this is the case.
This is the youngest age that the plate model should be reconstructed to. PaleoGIS will not reconstruct to ages less than this value.
Name of angle column, normally set to “angle”.
Normally set to “comment”.
Name of an optional column in the rotation table. If this column is present, then rows in the rotation data can be selectively made active and inactive by changing the Boolean value associated with each row. By default, a row should be active (inactive set to false), and should be set to true only when the user wants to inactivate that pole for that time.
Normally set to “lat”.
Normally set to “lon”.
Path to a website or document on the intranet that contains plate model information, metadata, or company marketing information.
Normally set to “plateid”.
PaleoGIS >= Version 4.0 uses the projection constant strings as found on the ESRI website below...
Geographic Coordinate Systems:
Projected Coordinate Systems:
PaleoGIS <= Version 4.0 uses the projection files as described below...
This is the path to an ESRI projection file (ex. %ARCGISHOME%\Coordinate Systems\Projected Coordinate Systems\World\Plate Carree (world).prj). We use the ESRI installation directory environmental variable here to start the path.
Normally set to “ref_plate”.
This setting value contains a connection string and table name separated by a pipe character. This table contains a mapping of the plate id numbers to actual names for these plates. You do not need to populate this table but it allows PaleoGIS to present the added information(see section 6).
Normally set to “PLATE_CODE”.
This setting value contains a connection string and table name separated by a pipe character. It points to the Rotation table discussed in step 2. By default, this table exists in the Plate Model File, so it often uses the $PGD$ variable to reference the table ii the same file. You can have multiple pole sources as well. Simply create a copy of the Rotation table and name it something different, then add a POLE_SOURCE_2 setting that points to the new table.
This allows the user to enter a valid SQL query as a string that will control what records will be selected from the rotation table. If the rotation table contained an extra true/false column called “obsolete”, then you might want to change this SQL query to “obsolete = false” which will then use poles from the rotation table where the obsolete flag is set to false.
Normally set to “NAME”.
Normally set to “OLDER”.
Set to the name of the actual table in the .mdb file”.
This setting value contains a connection string and table name separated by a pipe character. The connection string and table name allow you to connect to the timescale in any database, but by default it is right here in the Plate Model File.
Normally set to “YOUNGER”.
This is a place for the creator of the plate model to express the relative version of the data.
The Rothwell Group, L. P. provides PaleoGIS product support for all users. For any questions concerning PaleoGIS, please contact us:
The Rothwell Group, L.P. www.paleogis.com