Use MySQL Spatial Functionality

[grass-svn2git]

Reported by justinzane on 6 Feb 2014 23:22 UTC https://dev.mysql.com/doc/refman/5.0/en/spatial-extensions.html

It appears that MySQL >= 5.0 supports spatial data natively. It would be very nice to have GRASS leverage that since MySQL has a wider preinstalled base than PostgreSQL.

GRASS GIS version and provenance

svn-trunk

Migrated-From: https://trac.osgeo.org/grass/ticket/2190

[grass-svn2git]

Comment by hamish on 7 Feb 2014 01:16 UTC Hi,

fwiw in spatial circles PostGIS heavily dominates the market for spatially enabled DBs, even when proprietary systems are considered. That is not to say there's anything wrong with MySQL's spatial support (I've no experience with it), just that the popularity argument isn't going to convince many GIS programmers.

also note that GRASS is a topologically enabled GIS, and spatially-enabled DBs are generally much simpler beasts.

see also the sqlite offering: spatialite.

http://live.osgeo.org/en/overview/postgis_overview.html http://live.osgeo.org/en/overview/spatialite_overview.html

Meanwhile, GRASS's native vector format remains heavily favored support-wise.

regards, Hamish

[grass-svn2git]

Comment by justinzane on 7 Feb 2014 01:47 UTC I've used postgresql + grass years ago, and I know that it is somewhat of the "industry standard". By installed base, I was referring more to those people like me -- technical or scientific people outside the GIS profession who have occassion to use GIS tools as part of their work.

For me, this came up as a result of a need to do viewshed analyses for fixed wireless deployment. As a KDE user, MySQL (MariaDB, actually), is forced upon me by Akonadi/Nepomuk. And lots of organizations have MySQL running for non-GIS purposes. The convenience of being able to push data to an existing DB, expecially one that is already familiar is a boon.

I'm only suggesting that it might make GRASS more approachable for some users.

[grass-svn2git]

Comment by @mlennert on 7 Feb 2014 13:01 UTC Replying to [ticket:2190 justinzane]:

https://dev.mysql.com/doc/refman/5.0/en/spatial-extensions.html

It appears that MySQL >= 5.0 supports spatial data natively. It would be very nice to have GRASS leverage that since MySQL has a wider preinstalled base than PostgreSQL.

What exaxtly do you mean by "leverage" in terms of native spatial data support. Generally, GRASS uses its own data format and you can easily import from MySQL to GRASS using OGR with v.in.ogr.

You can also link spatial data in a MySQL database to GRASS via v.external (also via OGR).

If you are speaking about attribute data management, there is a mysql driver available in GRASS.

So AFAIK, the only difference between PostgreSQL and MySQL in their treatment by GRASS is the PostGIS direct access driver in GRASS7, which only allows to read and write data directly from/to PostGIS (without going through OGR), but it does not use any of the other spatial data functionalities in PostGIS http://grasswiki.osgeo.org/wiki/PostGIS#Direct_access_to_PostGIS_data_.28GRASS_7_only.29 1.

So are you pleading for a similar driver for MySQL, or what exactly are you looking for ? I do agree with Hamish, though, that within the GIS world, PostGIS is lightyears ahead of MySQL in terms of its adoption for spatial data handling.

Moritz

[grass-svn2git]

Comment by @landam on 22 Dec 2015 09:41 UTC I do not expect that GRASS would support MySQL spatial extension natively in GRASS 7. Changing milestone to GRASS 8.