Converting coordinates to a local SRS

I am currently doing some work for a small junior mining company which requires that a number of data sets be translated between UTM NAD83 Zone 11 and a local coordinate system. If you have never had any dealings with mining projects you may not know that it is common practice to create a local coordinate system aligned to the estimated ore body (sometimes called a mine grid). In some cases this CS may have been developed many years previous when the mine was originally developed and, often times, there is no adequate documentation to help define the system. If you are lucky you may be able to establish shift, rotation and scale values but this will likely require the assistance of a surveyor.
In this case, however, I was lucky enough to have the translation parameters. As it is very difficult to use traditional methods to convert from a earth centered to non-earth reference system I decided it would be much easier to do the transformation in a more manual fashion. By this I mean an x/y shift and rotation (no scaling required). Now having said that I also realized that this was a task that would be required many more times as the project progressed. For this reason I decided to roll up my sleeves and create a little stand alone utility. This is always a little daunting during an active project but I felt it could be accomplished fairly quickly and for very little additional cost to the client as I was going to utilize the open source ActiveX MapWinGIS and SharpMap dlls to do most of the work for me. After some fairly basic survey geometry calculations I had an algorithm that could be applied to convert all UTM coordinates to the local grid and vise versa.
Now to put it into a utility that would convert the features in a shapefile using this algorithm. As I am very familiar with MapWinGIS and SharpMap, I decided these would be the ideal ActiveX libraries to perform this task. It was fairly simple as the MapWinGIS dll provides read/write access to many of the attributes of features (shapes) such as the x and y coordinates of the individual vertices (points). The conversions can be applied to the vertices very simply such as:
MapWinGIS.Shape s = osf.Shape(shpindex);
string[] xy = toMine(s.Point(k).x, s.Point(k).y);

Where toMine is a Private Function within the VB.NET class that performs the conversion and s is the current feature (shape). The string array xy() will then hold the converted coordinates that can be applied to the shape point as follows:
s.Point(k).x = xy[0]

When all is complete you will have a new data set with all the features "projected" to the local coordinate system. Now the geologists and engineers using sophisticated modeling software (that apparently cannot easily do this kind of conversion) can quickly and easily convert the data for use in resource estimates and mine design applications.
One other issue lay in the fact that many of the data sets might be provided in other data types (i.e. MapInfo TAB files). For this reason I chose to use the open source GIS ActiveX dll SharpMap. This allowed me to convert these files into a common format (ESRI Shapefile).
This example illustrates how easy it is to create a versatile tool box using open source applications and libraries without having to bother with expensive licensing. MapWinGIS has been developed to work seamlessly within the .NET framework so, once you have referenced the dll, you can easily access all of these calls. I suggest downloading all the files from http://www.mapwindow.org or http://www.codeplex.com/SharpMap and try it out. I think you will find they will become an invaluable tool in your GIS toolbox.

Who needs ArcMap?

Over the past month I have been working on a Python plugin for Quantum GIS (QGIS) that allows the user to access the geoprocessing functionality of PostGIS without leaving the QGIS environment. I call it PgQuery for QGIS for anyone that might care. I have tried to make the plugin easy and intuitive to use with some click/double click functionality to insert PostGIS functions and tables into the query statements. That is the end of my sales pitch for this open source application, it is currently being tested by some associates and I will release it to the OS community very soon.

I mention this application because it illustrates how powerful open source GIS applications have become. I thought I would make a brief comparison here to give a sense of how many of the traditionally ArcGIS functions are actually "doable" in QGIS with one of the myriad plugins available such as GRASS or PostGIS.

This table illustrates a few of the geoprocesses that both the ESRI stack and the OS stack handle very well. The only real difference is the cost. The ESRI stack above represents about $25,000 (requires ArcInfo for Linear Referencing and Spatial Analyst for LOS) where as the OS stack is free. I am a firm believer in the right tool for the job and I believe that ESRI still has an advantage in cartographic output but what I think this illustation shows is that you MUST make a proper needs assessment before deciding on a GIS implementation. You may find that your current and future requirments will fit well with an open source deployment that will potentially save you thousands of dollars.

Don't get me wrong, I am not averse to an ESRI or any other commercial vendor deployment. I am only saying that, when looking at developing a GIS, it is worth considering open source as part of that strategy. In fact larger commercial developers such as ESRI and Safe are starting to support open source platforms such as PostgreSQL/PostGIS.

I will be posting a link to the QGIS plugin I mentioned at the begining on this site very soon so check back often. I will also be announcing it's release on Twitter and in a number of LinkedIn formus such as GIS, Geomatics and GIS Professionals so stay tuned.