Idea how to improve ProjectionInfo.FromEsriString

Dec 12, 2011 at 3:50 AM

In DotSpatial.Projections, maintain a lookup table EPSG Code <--> Proj4String <--> EsriString <--> KnownCoordinateSystem

In ProjectionInfo.FromEsriString(), first look if there is an entry with a matching EsriString in the lookup table.

If the entry is found, then use the Proj4String in the lookup table to construct and return the correct ProjectionInfo object rather than trying to parse the parameters of the EsriString.

If the entry is not found, then use the current method (try to parse all parameters of the EsriString).


I suggest this change, because I think it would allow a more reliable and faster translation between the EPSG Code, Proj4String and EsriString projection info formats. Right now I'm trying to make DotSpatial read the [S_JTSK_Krovak_East_North] EsriString and it fails to read the correct parameters resulting in my Czech data being rotated and displayed west of Ireland. Using the lookup table would solve my issue.

Dec 12, 2011 at 3:48 PM

Right now, some of our coordinate systems that have been constructed from Proj4 don't result in the correct ESRI WKT.  I looked at the possiblity of fixing it in DotSpatial and it looked to be rather tedious.  My application is very ESRI WKT centric.  I am avoiding using KnownCoordinateSystems because they often generate bad ESRI WKT (KnownCoordinateSystems are constructed using Proj4).  I vote we have a way to get from EPSG to ESRI WKT without going thru Proj4.

Dec 12, 2011 at 4:21 PM

Thank you for this comment. Most of my users work with shapefiles that have ESRI WKT in the .prj file so this is a valid concern for me too.

Does constructing ProjectionInfo from ESRI WKT work for you in all your use cases?

How do you handle cases when a 7-parameter datum transform is required (the +towgs84 parameter in proj4)? Do you keep track of these parameters separately?

My suggestion is, to create a new class ProjectionLookup with three methods:

public string FindProjectionString(inputProjectionString, inputFormat, outputFormat)

public string FindProjectionString(inputEPSGCode, outputFormat)

public int FindEPSGCode(inputProjectionString, inputFormat)

where inputFormat and outputFormat would be an enum ProjectionFormat.EPSGCode, ProjectionFormat.EsriString, ProjectionFormat.Proj4. The lookup information is publicly available on the web for example on

These methods would allow to go directly from one format to another without using KnownCoordinateSystems.

Dec 12, 2011 at 5:59 PM

Q: Does constructing ProjectionInfo from ESRI WKT work for you in all your use cases?

A: Yes, so far.  We just recently released our s/w using DotSpatial and we are fixing issues as we find them and post back to DotSpatial Repo.  Our intent is to support all (or almost all) spatial references that ArcObjects support.  I think there may be one Projection (Transform) that DotSpatial does not recognize, but it is not used by any of our customers as far as I know.

Q: How do you handle cases when a 7-parameter datum transform is required (the +towgs84 parameter in proj4)? Do you keep track of these parameters separately?

A: We do not use the DotSpatial default datum transforms at all.  We keep track of those parameters separately.  There were several issues that made using/fixing the default DotSpatial datum transform method impractical for us:

  • There appeared to be some bugs at least when compared to the answers we got using ESRI products.
  • DotSpatial treated WGS84 and NAD83 datums as the same (this is probably OK for GIS work, but not for surveying)
  • DotSpatial took the Proj4 approach of using WGS84 as a "pivot datum".  We have some cases where there are direct transformations to go between datums where WGS84 is not involved.  This was actually the biggest deterrent to using the default datum transforms in DotSpatial.

You will notice that we have added an overload to the Reproject method that takes an IDatumTransform argument.  This is how we manage the datum transform parameters.  I wanted to put some documentation on DotSpatial wiki on how to use this but have not been able to get the time to do so.  An IDatumTransform can have multiple stages (IDatumTransformStage).  You have probably seen the concept of stages in other applications.  This provides a very flexible way to handle datum transforms that may not fit the limited Proj4 paradigm.

Your suggestions seem OK to me.  I would recommend we always (when available) use EPSG (including ESRI codes) code as the middle man when going between formats.  This would mean you need several tables to get you to/from ESRI and Proj4.  This can get tricky when comparing strings.  We have to be careful going forward to not change precision on how we generate ESRI or Proj4 strings for example, a value of 0.001 vs. 0.00099999999999 would fail in the lookup.  We also still need to support cases where a user has their own custom .prj file (or ESRI string, or Proj4 string) where a EPSG code does not exist.  In that case, you have to fall back to what we essentially have now (i.e. to go from ESRI to Proj4 you create a ProjectionInfo from ESRI then call the method to create the Proj4 string).

Hope this helps,