[gdal-dev] zmap format

Mon Jun 27 15:44:55 EDT 2011

Nikolaos,

The ZMapPlus is an old format used to store gridded data in an ASCII line format for transport and storage.  It is Landmark Corp. format that many of the Landmark products, including GeoGraphix, use for data exchange.  Because it has been around for a while, many industry (Oil and Gas Exploration) applications read and write the format.

It is for gridded data. The format can also support point and polygon data, but only one data type is allowed in each file.  There are a specific set of header rows that define how the data is written in the file.

If the first character is a "!" the line is a comment.
The header section is starts with the first line that has an "@" symbol.  The data starts on the first line after the last "@" symbol, and there may only be two.  Header fields are comma delimited.

On the same line as the first "@" there are three fields.  The first is user defined but many times is just "GRID FILE", the second, for a grid file, must be "GRID", the third is an integer that indicates the number of grid nodes per physical line.

After the file description line are three more header lines that must exist for a grid file.

The first of these three lines has five fields.  The first field is the field width of each grid node as stored in the data section below the last "@".  The second field is the missing or null data value as it will be found in the data section.  The third field is a user defined text value used to indicate a missing or null value.  The text value is used if field two is blank.  If field two is defined, then the third field is left blank.  The forth field indicates the number of decimal places to use if no decimal point is found in the data nodes.  (Historical note: when disk and tape space was at a premium, this field made it possible to save some space in the file by not having to store a "." for each data node.)  If the data values are written to the file with decimals, this value is ignored.  The fifth field indicates the starting column of the first grid node on each line in the data section of the file.

The second of the three lines has six fields.  The first field is the number of rows in the grid.  The second field is the number of columns in the grid.  The third is the minimum grid X node value.  The forth is the maximum grid X node value.  The fifth is the minimum grid Y node value.  The sixth is the maximum grid Y node value.  The last four fields define the bounding box of the grid, and implies, for example, the lower left corner of the of the grid is the lower left corner of the lower left node in the grid.  The projection and or datum of the bounding box value is not defined.

The third of the three lines is always "0,0, 0.0, 0.0".

After the last header line, there is a single line with a single "@", the line after which is the first line of data in the data section of the file.  The data section has fixed field widths each field being a single grid node, and is generally right justified.  There will be no more nodes on any physical line than that defined in third field of the first header line.  A data field may or may not have a decimal point.  If none is found, it is implied, and the decimal places are as defined in the second header line in the forth field.

The grid nodes in the data section are stored in column major order.  That is the first column of data is written first, starting at the upper left corner of the grid.  For example, if the grid has 7 rows and three columns, and the number of nodes per line is 4, the first line of the data section will have 4 nodes, the first four grid nodes going down from the upper left.  The second line will have three nodes, the last three nodes of the first column.  Then the next column is written, four nodes then three.  Then the last column is written in the same pattern.

Here is an example of a 6 row x 4 column ZMapPlus grid file:

!
! File created by DMBTools2.GridFileFormats.ZmapPlusFile
!
@GRID FILE, GRID, 4
20, -9999.0000000, , 7, 1
6, 4, 0, 200, 0, 300
0.0, 0.0, 0.0
@
       -9999.0000000       -9999.0000000           3.0000000          32.0000000
          88.0000000          13.0000000
       -9999.0000000          20.0000000           8.0000000          42.0000000
          75.0000000           5.0000000
           5.0000000         100.0000000          35.0000000          50.0000000
          27.0000000           1.0000000
           2.0000000          36.0000000          10.0000000           6.0000000
           9.0000000       -9999.0000000

I hope this helps and maybe someday we can see it as a supported format in GDAL/OGR.

David M. Baker
Senior Geologist - Chief Technology Advisor
Chesapeake Energy Corporation
405-935-3715 office
405-496-5373 cell
david.m.baker at chk.com

-----Original Message-----
From: gdal-dev-bounces at lists.osgeo.org [mailto:gdal-dev-bounces at lists.osgeo.org] On Behalf Of Even Rouault
Sent: Monday, June 27, 2011 12:34 PM
To: gdal-dev at lists.osgeo.org
Subject: Re: [gdal-dev] zmap format

Nikolaos,

>
> There is a format called zmap format and it has Zmap Plus grid
> does anybody know more info about this format?

Well, here's a few interesting links what I've found with the help of a search
engine :
* http://pubs.usgs.gov/of/2003/ofr-03-230/DATA/ : several datasets in zmap
format (.dat) and also the same datasets but in other formats that are already
recognized by GDAL, such as .gxf, .ers, .xyz and .tif  --> Very useful to
check that a decoder for zmap works
* http://lists.directionsmag.com/discussion/read.php?f=19&i=30467&t=30467&v=t
: contains some bits of zmap content similar to the one of the previous link
* http://arcscripts.esri.com/details.asp?dbid=13093 : import/export zmap
plugin for ArcGrid with source code in visual basic

> mostly it is used for DEM and petroleum and according to my
> opinion it is descried by a rectangular kind of cells but it might not,
> that's why I am asking for some reference for zmap format and
> of course if it is possible to be adopted by gdal :)

Although none of those links is a formal specification of the format, that
should be sufficient for someone to write a decoder. But I'm not sure to
understand your needs: do you have some zmap datasets that you need to read
with GDAL ?

Best regards,

Even
_______________________________________________
gdal-dev mailing list
gdal-dev at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

This email (and attachments if any) is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law.  If the reader of this email is not the intended recipient, or the employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by return email and destroy all copies of the email (and attachments if any).