Parse WKT strings effectively

[iannesbitt]

Found while investigating #14:
Currently, WKT strings are parsed to get the last EPSG code from the string, rather than query the object to get the code from the correct field. This results in issues with COMPD_CS (compound coordinate system) WKT strings. For example, the following resolves to 3855 rather than the anticipated 32603. This should be handled pythonicly, ideally by reading the string to nested objects and addressing them structurally rather than by the brute force method currently used.

COMPD_CS["WGS 84 / UTM zone 3N + EGM2008 height",PROJCS["WGS 84 / UTM zone 3N",GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS 84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","4326"]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",-165],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",500000],PARAMETER["false_northing",0],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AXIS["Easting",EAST],AXIS["Northing",NORTH],AUTHORITY["EPSG","32603"]],VERT_CS["EGM2008 height",VERT_DATUM["EGM2008 geoid",2005,AUTHORITY["EPSG","1027"]],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AXIS["Gravity-related height",UP],AUTHORITY["EPSG","3855"]]]

[iannesbitt]

Solved by implementation of pyproj.