What is Zmap Plus file format?

What is Zmap Plus file format?

Listen to this article

How to interpret Zmap Grid format?

Trying to grasp Zmap Plus file format is not an easy task. It involves a comprehensive procedure pertaining to breakdown of codes into grid file format. The way I see it, commonly used in applications in the Oil and Gas Exploration fields in RW format,   Zmap Plus is an old format used to store gridded data in an ASCII line format especially for transport and storage.

In my opinion,

it is actually meant for gridded data. This format is also capable of supporting point and polygon data, but each file allows only one data type. A specific set of header rows define how data is written in a file and actual data followed by the header.

Below is sample of Zmap+ file:

! File created by DMBTools2.GridFileFormats.ZmapPlusFile



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

Comments are usually denoted by ‘!’ at the start of line. Hence, if the first character is a ‘!’, then the line is a comment.

ZMAP+ grid files in Python are divided into two sections the header section and the data section. Let us get cracking then, one at a time.

Deconstructing the Header of ZMAP+ grid files in Python

So this is the first thing you see, and this section starts and ends with an ‘@’ symbol. So the first line, after the @ is where your data starts.

Note: You can’t keep adding @ as you please, you need only two – one at the start and one at the end.


20, -9999.0000000,   , 7, 1

6, 4, 0, 200, 0, 300

0.0, 0.0, 0.0


You have seen what a header looks like. Let me deconstruct it for you.

The header fields are comma delimited. So going line by line now:

The Three fields on Line 1:

  • The first is user defined but many times it is just ‘GRID FILE’.
  • The second one is for a grid file, must necessarily be ‘GRID’.
  • The third is an integer that indicates the number of grid nodes per physical line. So in the example above it shows 4.

The Five fields on Line 2:

  • The first field shows the field width of each grid node of in the data section (this part comes after the header section closes with the @)
  • The second has the missing or null data value from the data section
  • A user defined text value goes in the third field. It indicates a missing or null value. It is blank in this case. This value gets used only if the second field is either blank or missing.
  • On number four, we have the number of decimal places that need to be used, if there are no decimal points in the data nodes that is.
  • Number five, shows the first column of the first grid node appearing on each line in the data section

The Six fields on Line 3:

  • First is the number of rows in the grid
  • Second, the number of columns in the grid
    (And on a side note, the total number of values in the data section must necessarily be equal to rows * columns)
  • Third has the minimum grid X node value. (x-min)
  • Number four has x-max or the maximum grid X node value
  • Five, is y-min that is minimum grid Y node value
  • And finally six is y-max or the maximum grid Y node value

The Three fields on Line 4:

They are always ‘0,0, 0.0, 0.0’.

Not sure why that really happens, but if you get some sort of an epiphany, then be my guest, and write back to us.

Decoding the Data Section of Zmap Grid format

So heading to the second section and that is the data section. And here goes,


-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

In case you were wondering where that @ came from, that is what I’d like to call the separator. This one comes right at the end of the header line and denotes that what comes after is where the real job is getting done.

The data section begins after this very @.

There are fixed field width in the data section. Since each field is a single grid node it is usually justified right.

On any physical line, you can have more than the ones that you defined in line 1 field 3 of the header section. (Yes, I heard you, I will hyperlink it here, so you know what I am talking about.)

So a data field may or may not have a decimal point. If there are none, then it is implied, and the decimal points, goes without saying, should be the same as when you defined them in the header section 0n Line number 2, Field number 4. (There you have it, again)

So usually, in the data section, the grid nodes are stored in what is known as the ‘column major order’. Where is that? – The first column of data, starting at the upper left corner of the grid. (You will have to scroll up for this, nah just kidding, hyperlinked)


So let me make it easier for you, if a grid has seven rows and three columns, and each line has 4 nodes:

Data section Line 1 – Will have 4 nodes. The  first four grid nodes will be on the upper left, going down.

Data section Line 2 – Will have 3 nodes i.e. the last three nodes of the first column.

Data section Line 3 – Will have 4 nodes

Data section Line 4 – Will have 3 nodes.

I guess you are getting the picture, this goes all the way till line number seven is reached.  The last column is written in the very same pattern.

Newton said – what we know is a drop, what we don’t know is an ocean. (That line got even more popular thanks to Netflix’s Dark, but I digress. I have deconstructed the process of ZMAP+ file formatting to the best of my knowledge. Write to us, if you wish to know more about our services, or if you want our experienced engineering team to resolve your queries related to ZMAP+ file formatting.


About Saurabh Kukade

Haskell Programmer

  • Functional Programming
  • Application Development
Saurabh has been in the software development field for a little over 3 years and is a language/platform agnostic programmer. He is passionate about functional programming especially Haskell. A software developer by day and a bibliophile at night, Saurabh loves to read. An Emacs fanatic, he writes technical essays, and has a penchant problem solving and algorithm designs.