it depends on the Version of Qgis Lisboa you use.
There is a bug in Qgis standalone installer for Windows which prevents the synchronisation of Qgis own CRS database with that of Gdal, if the installation path contains blanks (which is default). The Osgeo4w Installer does it correct by now, and supplies EPSG:3814 from GDAL to qgis:
+proj=tmerc +lat_0=32.5 +lon_0=-89.75 +k=0.9998335 +x_0=500000 +y_0=1300000 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs
If Qgis is not sure whether the .prj file is identical to a EPSG, it rather creates its own CRS. Missing towgs84 parameters could be a reason. The .prj file contains a WKT formatted CRS definition.
spatialreference.org gives this WKT definition for 3814:
PROJCS["NAD83 / Mississippi TM",
GEOGCS["NAD83",
DATUM["North American Datum 1983",
SPHEROID["GRS 1980",6378137.0,298.257222101,
AUTHORITY["EPSG","7019"]],
TOWGS84[1.0,1.0,-1.0,0.0,0.0,0.0,0.0],
AUTHORITY["EPSG","6269"]],
PRIMEM["Greenwich",0.0,
AUTHORITY["EPSG","8901"]],
UNIT["degree",0.017453292519943295],
AXIS["Geodetic latitude",NORTH],
AXIS["Geodetic longitude",EAST],
AUTHORITY["EPSG","4269"]],
PROJECTION["Transverse Mercator",
AUTHORITY["EPSG","9807"]],
PARAMETER["central_meridian",-89.75],
PARAMETER["latitude_of_origin",32.5],
PARAMETER["scale_factor",0.9998335],
PARAMETER["false_easting",500000.0],
PARAMETER["false_northing",1300000.0],
UNIT["m",1.0],
AXIS["Easting",EAST],
AXIS["Northing",NORTH],
AUTHORITY["EPSG","3814"]]
The towgs84 parameters differ. EPSG notes 0;0;0 for mainland USA, and 1;1;-1 only for Hawaii.
The EPSG registry at http://www.epsg-registry.org/
has almost identical values vor EPSG:3813 and 3814.
I'm not sure if qspatialite uses the Qgis CRS database or that of spatialite itself for the input mask.
Can you insert the .prj and qgis made Custom CRS string here?
You're going to want to replace this construction
st_intersects(proj_shape, st_buffer(cary_proj_point, 5280))
with this one
st_dwithin(proj_shape, cary_proj_point, 5280)
(because otherwise you'll have a terrible scalability problem in the future) and it will won't give you the answer you want unless proj_shape and cary_proj_point both have SRID = 2264. Do they?
Best Answer
There is no EPSG SRID 102743. Note that EPSG is the authority, and 102743 is the SRID. If you look up SRID 102743 on spatialreference.org, the listing is for ESRI:102743, meaning that ESRI (the publishers of ArcGIS) is the authority, not EPSG (European Petroleum Survey Group, now absorbed by the International Association of Oil & Gas Producers). The PostGIS database does not by default populate
spatial_ref_sys
with non-EPSG reference systems, so if you are using an ESRI one you have two choices:Add it manually
This is fairly easy. Each SRID page on spatialreference.org has a link for a PostGIS
INSERT
statement to add the code tospatial_ref_sys
. The statement for this SRID is:Use a "close enough" SRID
The PostGIS database includes a number of suitable SRIDs. As you have found, EPSG:3566 is a close match. In fact, 3566 (NAD83), 3569 (NAD83(HARN)), and 3677 (NAD83(NSRS2007)) are all extremely close matches. The only difference between 3566 and 102743 is the false easting and false northing parameters.
PARAMETER["false_easting",1640416.6667]
PARAMETER["false_northing",6561666.666700001]
PARAMETER["False_Easting",1640416.666666667]
PARAMETER["False_Northing",6561666.666666666]
So using the "wrong" one might lead to a misalignment of 3/100,000th of a foot.