As a warm up, from Sunday we have 2 days of tutorials at the bargain price of £70. To close there will be sprints from Friday 3rd July, and in case any Django coders get home sick it all coincides with the Birmingham International Jazz Festival.

My talk on ArcGIS and IronPython has been approved. So I’ll see you there.

Vector formats hold refined, discrete data, which has been manually traced or otherwise derived other data sources. Examples include building outlines, contours, road routes, pipe networks land land parcels and locations. Vector data is usually traced or derived, at great expense from raster data, to encode business information – as a result it’s usually highly valuable.

Unfortunately, there are many GIS vector file formats,  and most are proprietary. They can only be used to their full in their native software. Three of the biggest are AutoCAD DXF, MapInfo TAB and ArcGIS Personal Geodatabase. One vector format is unique – both an open standard, and in wide use: Shapefile

Shapefile is publicly documented in ESRI Shapefile Technical Description by ESRI Inc., it’s creator. Any GIS software worth it’s salt can read and write to the format, so it’s become the least common denominator. It is the format for storing and exchanging vector data between teams, departments, businesses and government. In my opinion this makes Shapefile the best thing ever to happen to GIS, without it the GIS market would be a fraction of it’s current size.

Despite it’s popularity, Shapefile does have some serious limitations, mainly due to it’s DBF heritage:

• A shapefile is limited to 2 4 GB or 65535 4 billion/len(record) records.
  Where len(record) is greater of either the average feature length in bytes, or the length of a DBF record.
• Records are limited to 1000 65536 bytes or 32 between 257 & 2038 fields.
• Field names are limited to 8 10 characters, character fields can hold up to 254 bytes.
• Unicode is not supported not widely supported.

Currently the only real alternative, for data exchange, is Geography Markup Language (GML) as defined by the Open Geospatial Consortium (OGC). An XML dialect, GML has none of the limitations of Shapefile this is why Ordnance Survey use GML to supply MasterMap, a highly detailed vector map of Great Britain. Support for GML in software is growing, but  it’s unsuitable as a storage format.

Viewing and editing vector data requires support for random access by attribute and by spatial extent. As an XML dialect GML cannot do this, to find one record, the entire file must be parsed from beginning to end. GML is almost always converted to another format, or loaded into a spatial database before it is used.

A spatial database is a database with data types and functions able to handle geospatial data. For the major databases there is Oracle Spatial, PostgreSQL PostGIS, SQL Server Spatial, MySQL Spatial and DB2 Spatial Extender. All are based on Simple Features for SQL an open standard, meaning spatial data can be queried and updated with SQL like any other data type.

I believe that a portable, standalone spatial database, would make a very good successor to Shapefile.  Such a format would drive the GIS market forward, increasing usage of GIS by making it easier to share edit, publish and share GIS data. A portable spatial database would negate the need for the import, view, edit, export cycle that GML imposes.

At the moment I see 3 contenders for the crown:

1. File Geodatabase is a format from ESRI, it is natively supported by ArcGIS. ESRI proclaim it “Allow[s] users to easily exchange geodatabases.” That is true only if both users are running ESRI’s ArcGIS software. File Geodatabase is a proprietary format, despite promises by ESRI when it was launched.
2. Spatial Data Format (SDF) is a format from Autodesk, it is native support . Support is included as part of their Feature Data Objects library, released as Open Source. SDF is based on the popular SQLite embedded database engine.
3. Spatialite is another format based on SQLite, by an Alessandro Furieri. Spatialite is in it’s infancy still, it’s first release was 11 months ago.

Unfortunately none of these looks like it will become a clear winner any time soon. Each is supported by only one application currently. If ESRI releases the specification for File Geodatabase, I expect it will quickly gain widespread support due to their position as market leader. As open source applications such as QGIS gain Spatialite support, it could slowly achieve dominance in a grass roots fashion. SDF seems to be going nowhere.

So ESRI, please publish the details of File Geodatabase. At it’s launch, during the 2006 ESRI User Conference, you promised that File Geodatabase would be an interoperable format. You promised to release a software library, so we  could read and write them without ArcGIS. Neither has happened. So File Geodatabase is just another closed format, another pretender to the throne that’s achieved only 1% of it’s true potential.

Publish File Geodatabase, or we’ll take the Shapefile crown by force.

Update 27 Mar 2009: Corrected Shapefile limits, based on Xbase file structure rather than dBASE software specifications.

Once done, MXDPERFSTAT writes an html report, of the time taken and features retrieved to display each layer at each scale. Since it runs in situ, network delays and other real world bottlenecks are accounted for. It even highlights layers that are abnormally slow, or that fetch an excessive number of features. Perfect for diagnosing a slow map, or guiding a tune up of the infrastructure.

Supporting ArcGIS installations, I’m a regular searcher on ArcScripts. How did I miss this for the last 4 years, and what other gems are there? What GIS utilities do you find indispensable?

Last week I tried again, using the newly released IronPython 2.0. This time it worked better.

create_sde_conn_file.py is based on CreateSDEConnFile.java, from Creating ArcSDE connection files on the fly using Python and ArcObjects on ESRI’s Geoprocessing blog.

For those not already familiar, ArcGIS is by accounts the market leader for Geographic Information System (GIS) software. The core of the suite comprises ArcGIS Desktop, and ArcGIS Server.

On the desktop ArcMap is used to create map documents (.mxd file), whilst ArcCatalog is used to manage data sources. ArcGIS Server can (amongst other things) serve a map document, as a service for web client, Google Earth or remote ArcMap users.

ArcGIS may be automated to an extent, through an interface known as ArcGIS Geoprocessing. But this covers only some cases, delving deeper provides much greater opportunities.

ArcGIS is built on a COM object library named ArcObjects. Native ArcGIS files, such as an ArcSDE connection (.sde file) are the in memory COM object, serialised to disk as binary. It is difficult to edit or create such files in an automated fashion, without calling ArcObjects.

So, like the Java code CreateSDEConnFile.py calls ArcObjects directly. It can produce an ArcSDE connection file, suitable for ArcCatalog. It works by calling the .NET bindings, through Interop assemblies. Anything that can be done through VBA, or C# should be possible through IronPython.

There are a couple of rough edges. ArcObjects is verbose, and IronPython requires some boilerplate to deal with interfaces. Instead of writing

conn_props['SERVER'] = sys.argv[2]

or even

conn_props.SetProperty('SERVER', sys.argv[2])

one needs to write:

esriSystem.IPropertySet.SetProperty(conn_props, 'SERVER', sys.argv[2])

This is explained properly in IronPython bug 1506 and 4538.

To run the script call it as:

"c:Program FilesIronPythonipy.exe" create_sde_conn_file.py
filename.sde hostname 5151 username password SDE.DEFAULT ""


My intention is to take this proof of concept further. To do the same with layer files and map documents. Ultimately to create a build system, able to automatically generate a complete ArcMap document, from textual source files (e.g. json2mxd.py, mxd2xml.py).  This would allow proper version control of the source material, and automatic deployment of ArcGIS Server map services.

In the wider scheme, it should be possible to create custom GIS applications with Python, using the full capabilities ArcObjects and ArcGIS.

Updated 29 Jan 2009: Added some context, for those coming to this post from a Python background. Expanded goals.

To load raster data as a continuous layer one typically mosaics many images, using ArcGIS Desktop or the sderaster command. ArcGIS Desktop is more flexible, it accepts many image formats and can resample images that don’t perfectly align, but it’s slow and struggles with large jobs. The sderaster command is faster and scriptable, but it accepts only tiffs and it’s very fussy about them.

What follows are some notes that will remind me the next time and possibly help others.

1. If the real world pixel size (i.e. units m/px or ft/px) on lines 1 & 4 of the world file are not exactly equalt to the value you calculate then correct the world files. If present also correct the geotiff headers. Ordnance Survey 10K tiles may need this correction.
2. Pyramidding is only visually effective if it can create pixels with averaged colour values. Monochrome or colour mapped images do not satisfy this requirement.
3. The documentation states that ArcSDE cannot mosaic images with a colour map. This also applies in some cases where no colourmap is present, such as 4 bit greyscale. Use the -N switch to be safe and then reapply the colour map with sderaster -o colormap, once all images are mosaiced.
4. Geotiff headers are tricky to remove in place, en masse. When preprocessing images be sure that either the world file and/or geotiff tags are correct, or generate your tiffs without getiff tags.
5. GDAL is much faster than ImageMagick for altering bit depth. The libtiff utilities are faster yet.
6. Until ArcSDE 8.3 SP, sderaster required that the top left image be loaded into a raster first, or it wouldn’t mosaic anything.

Those wishing to save the effort of loading images into ArcSDE, might wish to look into ArcGIS ImageServer or a WMS server.

To update world files in a batch try the following python script:

import os
import sys
import fileinput
import re
import glob

def replace_in_files(filenames, pattern, rterm):
    '''Replace all occurances of regex pattern with rterm in sequence of filenames'''
    regex = re.compile(pattern)
    for line in fileinput.input(filenames, inplace=True):
        sys.stdout.write(re.sub(rterm, line))

if __name__ == '__main__':
    pattern = sys.argv[1]
    rterm = sys.argv[2]
    filenames = glob.glob(sys.argv[3])

    replace_in_files(filenames, pattern, rterm)