Hello List,
how flexible is GRASS with regards to the DB where the GIS-data are
stored? I read in the docs that GRASS can now work with many popular
relational DB systems. But what about an entirely unconventional data
store like an object-oriented database implemented in lisp?
Is it just a question of correct data-types, that might be implemented
in any language or system, or do the programming language and the DB
system play an important role?
In other words, could I have a look at a data format GRASS works
with, define a class in an object-oriented lisp system that reflects
that format, and GRASS will be able to access and work with the data?
cheers
Thorsten
On 13/02/12 15:49, Thorsten wrote:
Hello List,
how flexible is GRASS with regards to the DB where the GIS-data are
stored? I read in the docs that GRASS can now work with many popular
relational DB systems.
This relates to storing attribute values, not the spatial feature information. GRASS has its own format for that.
You can work with spatial data stored in databases using v.external via OGR. So any system supported by OGR should work.
But what about an entirely unconventional data
store like an object-oriented database implemented in lisp?
Is it just a question of correct data-types, that might be implemented
in any language or system, or do the programming language and the DB
system play an important role?
In other words, could I have a look at a data format GRASS works
with, define a class in an object-oriented lisp system that reflects
that format, and GRASS will be able to access and work with the data?
Each database backend for attribute management has its own driver in the GRASS source code. If you can implement a similar driver for your system it should work. Or you can use the ODBC driver if it is easier for you to create an ODBC driver for your system.
See [1] and [2] and notably the READMEs for more info, as well as the GRASS Programmer's Manual, but that's currently offline...
Moritz
[1] http://trac.osgeo.org/grass/browser/grass/trunk/db/drivers
[2] http://trac.osgeo.org/grass/browser/grass/trunk/lib/db
Moritz Lennert <mlennert@club.worldonline.be> writes:
On 13/02/12 15:49, Thorsten wrote:
Hello Moritz,
how flexible is GRASS with regards to the DB where the GIS-data are
stored? I read in the docs that GRASS can now work with many popular
relational DB systems.
This relates to storing attribute values, not the spatial feature
information. GRASS has its own format for that.
You can work with spatial data stored in databases using v.external
via OGR. So any system supported by OGR should work.
thanks for your answer, I referred to spatial data too, probably the
most convenient solution would be to use the OGR driver that supports
CSV data, since it would not be very difficult to transform lisps nested
lists into the CSV format.
But what about an entirely unconventional data
store like an object-oriented database implemented in lisp?
Is it just a question of correct data-types, that might be implemented
in any language or system, or do the programming language and the DB
system play an important role?
In other words, could I have a look at a data format GRASS works
with, define a class in an object-oriented lisp system that reflects
that format, and GRASS will be able to access and work with the data?
Each database backend for attribute management has its own driver in
the GRASS source code. If you can implement a similar driver for your
system it should work. Or you can use the ODBC driver if it is easier
for you to create an ODBC driver for your system.
That might be a bit over my head.
See [1] and [2] and notably the READMEs for more info, as well as the
GRASS Programmer's Manual, but that's currently offline...
Thanks for the links, I will have a look.
Moritz
[1] http://trac.osgeo.org/grass/browser/grass/trunk/db/drivers
[2] http://trac.osgeo.org/grass/browser/grass/trunk/lib/db
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user