2

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.)

Improve this question
1
  • Per the answer, I wanted to update the results. I used v.external to link to the spatialite. If I understand it correctly, it basically created a link to its attribute table and generated its own topology. I then used v.extract to subset my data within GRASS. I hoped to work under a spatial DB system with spatialite and GRASS as a tool, but it appears to me GRASS requires a hybrid DB system and to operate on its own entities. I basically had to make a GRASS hybrid DB branch and my Spatialite spatial DB branch. Easy to combine their results in QGIS, though.
    – Bryan Goodrich
    Commented May 2, 2012 at 23:26

2 Answers 2

Reset to default
4

It's possible to read SpatiaLite databases using the v.external module, provided that your OGR is built with SpatiaLite support, see OGR's SQLite driver.

Improve this answer
6
  • Thanks webrian. That lets me make a logical link from GRASS (with a pseudo-topology?) to my data in Spatialite. I can then subset that using v.extract, set my region parameters, and run various analysis (v.kernel, v.neighbors, etc.). It still bothers me that it isn't stored natively. GRASS 7 is supposed to use SQLite as its backend. I hope this will make using Spatialite geometry more natural within GRASS (like it is with QGIS). For GRASS 6 I'm still expanding my data within GRASS, not my intended backend (Spatialite). They need to be more tightly connected!
    – Bryan Goodrich
    Commented Apr 16, 2012 at 21:14
  • To expand on my last comment, QGIS lets me just connect and subset/query my spatial features. I am still new to this, but it doesn't seem that I can then just use GRASS on my QGIS layers in this way. I hope GRASS 7 will make this more integrated, because it would be fantastic if I can just connect to my backend with QGIS, use GRASS in QGIS and use its functions on those layers. That integration would take open-source GIS (viz., QGIS) many great steps forward.
    – Bryan Goodrich
    Commented Apr 16, 2012 at 21:17
  • 1
    Yes, GRASS 7 supports SQLite as backend but only for attribute data but not for geometries. The reason is that GRASS uses its own topological geometry format that is more complex than the usual simple feature geometries used e.g. in SpatiaLite and Shapefiles.
    – webrian
    Commented Apr 17, 2012 at 6:20
  • Do you know of any resources (urls) that discuss how GRASS geometry is managed? Is there any change to that in GRASS 7? I really don't see much about this stuff on Google searches. Their wikis seems scattered and incomplete or too vague!
    – Bryan Goodrich
    Commented Apr 17, 2012 at 21:58
  • To elaborate on my own question above, I did find this link: grass.osgeo.org/wiki/Vector_Data which details the vector data model GRASS uses. I wonder how much GRASS depends on that model or if they may eventually work on simple features: en.wikipedia.org/wiki/Simple_Features because then it would have the advantage of being able to operate over something like PostGIS or Spatialite directly. This would move a QGIS+GRASS+PostGIS more closely to an integrated solution like ArcGIS+ArcSDE+SQL Server, if that makes sense. OTOH, maybe a topology addition to Spatialite is in order?
    – Bryan Goodrich
    Commented Apr 17, 2012 at 22:13
1

Sorry to come late to the party. But it's worth adding that GRASS can certainly import spatialite based spatial features with a recent GDAL. v.in.ogr recognizes an sqlite spatial DB in the 'dsn=' parameter and the table name is put into the 'layer=' parameter.

Still, as mentioned in the comments, you have to let GRASS handle the vectors in its own way. The GRASS vector model is more strict than spatialite or shapefiles, etc. So the workflow will always require importing a spatialite based vector into GRASS, doing any required analysis, and exporting results back out to spatialite.

Improve this answer
0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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