2

I have shapefile (from the local government gis office of a town in Massachusetts) that contains, in the corresponding .shp.xml file, the following WKT projection:

PROJCS["NAD_1983_StatePlane_Massachusetts_Mainland_FIPS_2001",
    GEOGCS["GCS_North_American_1983",
        DATUM["D_North_American_1983",
            SPHEROID["GRS_1980",6378137.0,298.257222101]],
        PRIMEM["Greenwich",0.0],
        UNIT["Degree",0.0174532925199433]],
    PROJECTION["Lambert_Conformal_Conic"],
    PARAMETER["False_Easting",200000.0],
    PARAMETER["False_Northing",750000.0],
    PARAMETER["Central_Meridian",-71.5],
    PARAMETER["Standard_Parallel_1",41.71666666666667],
    PARAMETER["Standard_Parallel_2",42.68333333333333],
    PARAMETER["Latitude_Of_Origin",41.0],
    UNIT["Meter",1.0]]

Loading the shapefile into QGIS results in a null CRS ("This layer appears to have no projection specification..."). I've tried converting the above projection into proj4 syntax, but I'm running into some problems caused by the fact that I have no idea what I am doing.

The above projection is awfully close to the standard projection used by MassGIS (epsg:26986), although "Standard_Parallel_1" and "Standard_Parallel_2" are swapped. Trying to convert this to proj4 syntax using the Python osgeo.osr module results in:

ERROR 6: No translation for Lambert_Conformal_Conic to PROJ.4 format is known.

I can replace Lambert_Conformal_Conic with Lambert_Conformal_Conic_2SP (as suggested elsewhere), which results in a successful export in proj4 syntax, but (a) it's not clear to me that's the right thing to do, and in any case (b) the resulting projection still doesn't place the features where they belong.

How do I get this data in the right place?

Edit: I have tried just using epsg:29686 as well, which didn't work either. The shapefile in question is here.

2

The shapefile you linked has this .prj file content:

PROJCS["NAD_1983_StatePlane_Massachusetts_Mainland_FIPS_2001_Feet",
 GEOGCS["GCS_North_American_1983",DATUM["D_North_American_1983",
  SPHEROID["GRS_1980",6378137.0,298.257222101]],
  PRIMEM["Greenwich",0.0],
  UNIT["Degree",0.0174532925199433]],
 PROJECTION["Lambert_Conformal_Conic"],
  PARAMETER["False_Easting",656166.6666666665],
  PARAMETER["False_Northing",2460625.0],
  PARAMETER["Central_Meridian",-71.5],
  PARAMETER["Standard_Parallel_1",41.71666666666667],
  PARAMETER["Standard_Parallel_2",42.68333333333333],
  PARAMETER["Latitude_Of_Origin",41.0],
  UNIT["Foot_US",0.3048006096012192]]

which is equivalent to EPSG:2249 NAD83 / Massachusetts Mainland (ftUS) but has units in feet instead of the meter-based CRS in the .shp.xml file (that QGIS ignores).

If you drag and drop the file into QGIS, it builds this custom CRS:

 +proj=lcc +lat_1=41.71666666666667 +lat_2=42.68333333333333 +lat_0=41 +lon_0=-71.5 +x_0=199999.9999999999 +y_0=750000 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=us-ft +no_defs

which gets misplaced in northern Africa, whereas the built-in EPSG CRS has

 +proj=lcc +lat_1=42.68333333333333 +lat_2=41.71666666666667 +lat_0=41 +lon_0=-71.5 +x_0=200000.0001016002 +y_0=750000 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=us-ft +no_defs

Assigning the EPSG code 2249 to the layer with Set Layer CRS places it to the right spot compared to an Openstreetmap background:

enter image description here

This should work the same way for the meter-based CRS.

  • That was it, thanks! For what it's worth, when I import the file into qgis (Layer -> Add Layer -> Add Vector Layer) it shows up as having no CRS, rather than building the custom one you show in this answer. I wonder why you are seeing different behavior? I'm running qgis 2.18.14. – larsks Nov 28 '17 at 13:21
  • Yes, QGIS seems to behave a bit strange with CRS it can not recover. In another try, I got the CRS in meters instead of feet. – AndreJ Nov 28 '17 at 13:56
2

You can find the Proj.4 string with gdalsrsinfo.

gdalsrsinfo voting_precincts.prj -o proj4
+proj=lcc +lat_1=41.71666666666667 +lat_2=42.68333333333333 +lat_0=41 +lon_0=-71
.5 +x_0=199999.9999999999 +y_0=750000 +datum=NAD83 +units=us-ft +no_defs

This variant is a bit different than what we have seen in your question and other answers with +datum=NAD83. However, it should be possible to put data into correct place in QGIS by using just the menus.

1) Open the shapefile, go to Set Layer CRS. You should find an entry for Generated CRS under the User Defined Coordinate Systems.

enter image description here

There can be many automatically generated CRS definitions, be sure to select the one that was built for the VOTING_PRECINCTS and press OK. With my QGIS 2.18.10 data appear near to Boston.

enter image description here

The order of lat_1 and lat_2 does not seem to play a role here, nor the missing -datum=NAD83

  • When I open this file in QGIS 2.18.14, it shows up as having no CRS and there are no entries under "user defined coordinate systems". Odd. – larsks Nov 28 '17 at 13:23
  • Can you add your own CRS through Settings - Custom CRS with the provided Proj4 string and then use that for voting_precincts? – user30184 Nov 28 '17 at 13:28
  • Based on @AndreJ's answer, it seems as if EPSG:2249 is the correct SRID. – larsks Nov 28 '17 at 13:29
  • Man, this just saved me after a couple hours of fiddling. Thanks! – ryanjdillon Jun 25 '18 at 21:40
0

I would just use EPSG:26986 which is listed as

PROJCS["NAD83 / Massachusetts Mainland",
    GEOGCS["NAD83",
        DATUM["North_American_Datum_1983",
            SPHEROID["GRS 1980",6378137,298.257222101,
                AUTHORITY["EPSG","7019"]],
            TOWGS84[0,0,0,0,0,0,0],
            AUTHORITY["EPSG","6269"]],
        PRIMEM["Greenwich",0,
            AUTHORITY["EPSG","8901"]],
        UNIT["degree",0.0174532925199433,
            AUTHORITY["EPSG","9122"]],
        AUTHORITY["EPSG","4269"]],
    PROJECTION["Lambert_Conformal_Conic_2SP"],
    PARAMETER["standard_parallel_1",42.68333333333333],
    PARAMETER["standard_parallel_2",41.71666666666667],
    PARAMETER["latitude_of_origin",41],
    PARAMETER["central_meridian",-71.5],
    PARAMETER["false_easting",200000],
    PARAMETER["false_northing",750000],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]],
    AXIS["X",EAST],
    AXIS["Y",NORTH],
    AUTHORITY["EPSG","26986"]]

I don't think the order of the standard parallels matters but you could swap them if you wanted.

  • You'll note that I mentioned that very same CRS in my question. Using it does not correctly place the features. Maybe the shapefile is bad? I've updated the question with a link to the shapefile in question. – larsks Nov 27 '17 at 19:32
  • But you changed it in the question – Ian Turton Nov 27 '17 at 19:33
  • Well, no, but perhaps my question is unclear. I've also updated it to indicate that I did try using epsg:29686 without success. – larsks Nov 27 '17 at 19:35
  • By reading community.esri.com/thread/49519 the order of standard parallels do not matter in ESRI software. It may make a difference for Proj.4. If it does it is perhaps a bug. – user30184 Nov 28 '17 at 7:09
  • It might be the absence of _2SP in the PROJECTION parameter that causes the trouble for PROJ.4. – AndreJ Nov 28 '17 at 14:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.