I'd like to create a spatialite database and load it with shapefiles using the Mississippi Transverse Mercator (MSTM) projection, but it doesn't have an EPSG definition in the spatialite library of projections.
When loaded into a QGIS session, it correctly projects the shapefiles, automatically building a custom proj4 code for it from the ESRI prj files that come along with the data. I checked that QGIS accurately reprojects this data, on the fly, to online WGS84 Orthophoto (Bing Maps) and it does.
I'm using qspatialite to load these shapefiles into a single newly created db.sqlite; I try to populate the mandatory SRID field with the custom projection code definition number that QGIS generates, for example SRID= "100003" etc, which is on the dropdown picklist to choose from in the qspatialite plugin. Qspatialite can't load the shapefiles with any custom codes stored in QGIS though; it issues an error and fails to load the data–I figure because that isn't in the Spatialite EPSG library of projections. To double check that the plugin installation works, I did load the shapefiles successfully using a standard EPSG number, but my shapefiles are really in a custom projection CRS.
Is there a way I can copy/paste QGIS's custom proj4 definition to the spatialite EPSG library and create a brand new custom SRID definition, then load my data using that new SRID number in the mandatory data loader field? Or, would spatialite-gui be better than qspatialite?
These are the MSTM projection parameters (not Proj4):
Scale Factor: 0.9998335
Central Meridian: -89 45' 00''
Central Latitude: 32 30' 00''
False Northing: 1,300,000 meters
False Easting: 500,000 meters
Projection Units: meters
Spheroid: GRS80
Datum: NAD83
–EDIT OF POST 1/24/2013 BELOW–
I just wanted to add a workaround method for bulk-batch importing shapefiles into a spatialite database, using Qspatialite's bulk load OGR-file button. This would be useful if the IMPORT OGR FILE command won't accept a custom EPSG number that you need to use. For myself, I just entered a similar but commonly used EPSG number using that also uses the same DATUM. For example, my custom EPSG: 3814 apparently gets little use and hasn't yet been included in QGIS spatial reference database (Lisboa 1.8.0). I found that the "custom" coordinate system uses NAD83. Instead of entering the SRID of 3814 that causes an import failure, I just used a similar NAD83, in this case EPSG:26995, that's preloaded into QGIS. They import just fine like that. Of course the imported shapefiles will not be projected correctly in QGIS relative to a basemap.
To fix that I created a custom coordinate system in QGIS using the +proj code that QGIS generates to correctly project the individual shapefiles that are now importing to a spatialite database, that also included a 3814.prj spatial reference file. THEN after creating that CUSTOM CRS, I was able to load the files from my spatialite database and individually set the projection under the of each layer to my custom spatial reference code that I saved in QGIS. Presto, everything aligns perfectly with my basemap while using spatialite layers. And, I was able to use Qspatialite to bulk-batch over a hundred shapefiles and then a couple of hundred dbf tables of additional information. One by one would have been time consuming.
Best Answer
You could add a custom SRID in a spatialite database (adding a row into spatial_ref_sys table), with a simple request, but here, it looks like the CRS you want to add (based on the information you give ) is already in the database :
It's SRID/EPSG 3814/3815/3816 (they all looks like the same to me :/).
HTH.