I've looked at the question: How to import SpatiaLite data into GRASS? already. The links there talk about two separate tasks: Passing SQL to a Spatialite DB from GRASS and connecting to Spatialite from GRASS. That is fine, but the point of Spatialite is to generate geometry metadata. So to get specific, let me explain what I am aiming to achieve.
I create an SQLite database containing crime statistics with State Plane California Zone II (ft) projected coordinates (X_Coord and Y_Coord). All of that is done in R. I then run an SQL script that initializes the Spatialite script and adds geometry columns to the crime table, populates them, and then imports a couple of shapefiles.
Now, my table still has the original X_Coord and Y_Coord fields, but it also has a SHAPE field that contains the geometry. I can import the data into GRASS because I have the coordinates, but it cannot recognize, as far as I can tell, the Point geometry contained in SHAPE. If I'm going through all of this to store geometry in Spatialite, it seems redundant (and time consuming) to then recreate geometry in GRASS.
My aim is to use this database and have GRASS quickly extract the geometry and create a v.kernel raster for a density surface. It would also be nice to define the GRASS bbox based off the geometry stored in Spatialite (because it's easy to get that information from SHAPE instead of X_Coord and Y_Coord with Spatialite functions). But if GRASS currently cannot interface Spatialite geometry, there's an obvious disconnect.
Is this just a feature GRASS is currently lacking or am I missing where on the web this is documented? I've spent the past couple of weeks looking into this and find the only solution is to redundantly create the geometry in GRASS based off X_Coord and Y_Coord, making the SHAPE field superfluous to this part of my analysis. (It's still useful for directly pulling into QGIS.)