Taking A Look At PgMap

When I blogged about the official end of zigGIS last week, I included a mention of PgMap, a free extension to ArcMap for direct read/edit of PostGIS data. Judging from outbound links, there seems to be a good bit of interest in it so I decided to take a look.

To recap, Abe decided to pull the plug on zigGIS due to the fact that ESRI will support direct read/edit of spatial databases (as simple features) in 10.1. In my opinion, this is a good development. With native support coming, there was no need to continue with zigGIS. That support, however, will only exist in ArcGIS 10.1. Users of older versions will need to find alternatives. Based on our experience with zigGIS (as well as download data I’ve seen for the WeoGeo toolbar), there are a lot of people (especially outside the US) still using ArcGIS 9.x so demand for an alternative will probably be high for some time.

A quick glance shows me that there are a lot of similarities between PgMap and zigGIS. This is not surprising as there are really only so many ways to approach the task of connecting directly to PostGIS from ArcMap. That said, there are some key differences that are very attractive. They are:

  1. Support for ArcGIS 10
  2. Support for PostgreSQL 9.x
  3. Support for PostGIS 1.5
  4. Availability of a companion product, QMap, for connecting to SQL Server 2008

These differences represent capabilities that were frequently requested by zigGIS users but that we simply hadn’t gotten to so it’s good to see that PgMap has been able to support them. While PgMap is free of charge, it does require a license key. Without the license key, the documentation says that you will only have access to the first 1000 rows of your data. I was only ever able to access the first 100 rows so I suspect there may be a typo in either the docs or the code.

Using ArcGIS 10.0 (ArcEditor), I gave it a very quick run-through. The capability I found is impressive. PgMap allows you to manage connections to PostGIS databases, add PostGIS tables as feature classes and set definition queries for those layers. It appears that PgMap reads the geometry_columns table to list layers. I will need to investigate further to see if it supports views or spatial tables that have not been registered in the geometry_columns table.

There is one key difference between zigGIS and PgMap that I did not mention above and which is quite powerful. PgMap supports the export of ArcGIS feature classes directly to PostGIS (and vice versa). It also appears to support appending to existing PostGIS tables but I have not tested that yet. I used PgMap to export a feature class from a file geodatabase to my PostGIS database and it went flawlessly.

PgMap export dialog

The resulting PostGIS table was displayed perfectly in QGIS, with all of the attributes coming over well. I have not delved in yet to to see what assumptions PgMap makes in terms of data type conversions between the geodatabase and PostgreSQL.

O Canada!

PgMap also integrates seamlessly with the ArcMap editor toolbar for editing. During my investigations, I noticed that layers are loaded into in-memory workspaces so they are natively supported for editing. Edits are then posted back to PostGIS when saved. This is similar to the approach that zigGIS used and is also similar to the behavior of other tools as well. When I get my license, I will need to test with larger data sets. zigGIS originally used in-memory workspaces but we noticed performance problems when loading large data sets so we switched to scratch workspaces. There are numerous ways to mitigate this but, until I can access full data sets, I can’t really test it.

Editing worked well. I was even able to use PgMap to do further testing on my notification system.

All in all, I think PgMap is an impressive tool that should be able to support the needs of ArcGIS 9.x and 10.0 users going forward. It’s good to know that a tool is out there to continue meeting that demand.