Monthly Archives: May 2012

The new GPlates rotation file format

The new GPlates rotation file format (*.grot) will be a major step to take the dreaded rotation files into the 21st century. The format description is part of a paper submitted by Micheal Chin (Xiao Qin et al.) and can be accessed here. The linked page also contains a syntax highlighting bundle for TextMate (this is still under development).

GROT Rotation file format standard

The document describes the new GROT rotation file format (for GPlates Rotation file, pronounced g-rot) and allows for a much richer set of metadata attributes to be incorporated in the file standard. The proposed standard is based on ideas sourced from the OGR GMT format, Python, MultiMarkdown and is self-consistent, plain text based and human-readable. Further, it will allow GPlates to source advanced information such as DOI’s, individual bibliographic information and Dublin Core Document Metadata from the files.

The new *.grot file format uses a specific @Attribute"Value" and comment syntax which allows for:

  • Simple commenting/uncommenting of rotation poles using # (previously: 999)
  • the inclusion of Hellinger/Chang rotation statistics
  • the inclusion of bibliographic and reference data for the whole rotation file and individual rotations
  • information on Geological Time Scales and converting between them
  • Self-consistent tagging of rotation data
  • New “Moving plate rotation sequences” and associated metadata

GIS and p(l)ain text

So you are working with geospatial data. You are  collaborating with several people on the same dataset. People in your team are on different OS (Mac, Win or Linux) and want to use different geospatial tools, like QGIS, GPlates, GMT, OpenJUMP or ArcGIS or Matlab as they all have different requirements and  used to different workflows in their geoscientific research. You would like to keep track of the changes made to that specific dataset and snapshot it at different stages — ideally through SVN, git or any other revisioning tool. You don’t have any money and probably even less time.

So (unless I am mistaken) there are some options right at hand:

  1. Who cares about money: stuff all that open source software (who uses that anyway…), convert everyone to M$ Windoze and force them to use the one and only mighty ESRI ArcGIS. Yeah…NOT really.
  2. Put a lot of effort into setting up PostGIS plus versioning and then spend the rest of your life on figuring out how to connect ArcGIS in a way that you can read and write to that DB.
  3. Put the good old shp file into a a revisioning system. Hm, not too great for binary files and if you’d like to check differences on a single feature between two versions…
  4. Give up on the idea of revisioning and just make every user to save snapsots manually and store them in a central location?
Strangely, in 2012 there seems to be not a single “open”, non-binary file format which can be edited and read across the whole FOSS and proprietary GIS world – at least to my knowledge. A potential candidate, with little overhead is the GMT OGR format (see the documentation in the GMT5 cookbook – PDF file link here, which is produced by ogr2ogr, when converting shapefiles to GMT’s plain text format. So I guess this is what I will be doing:
  • Set up the common dataset as shapefile, add all attributes and geometries so far
  • Modify it in your GIS application of choice
  • Once you have done your changes, save the shapefile.
  • Convert the shapefile to GMT OGR using ogr2ogr
  • Put the GMT OGR file into the revisioning system.
  • Revert the process when needing to modify the data.
One could potentially write a Python script to do this in Arc but running ogr2ogr on the command line once shouldn’t be too hard…