Opened 11 years ago

Last modified 9 years ago

#2190 new enhancement

Use MySQL Spatial Functionality

Reported by: justinzane Owned by: grass-dev@…
Priority: normal Milestone: 8.0.0
Component: Database Version: svn-trunk
Keywords: MySQL, spatial, geometry Cc:
CPU: All Platform: All

Description

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.

Change History (4)

comment:1 by hamish, 11 years ago

Version: unspecifiedsvn-trunk

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

comment:2 by justinzane, 11 years ago

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.

in reply to:  description comment:3 by mlennert, 11 years ago

Replying to 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 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

comment:4 by martinl, 9 years ago

Milestone: 7.0.08.0.0

I do not expect that GRASS would support MySQL spatial extension natively in GRASS 7. Changing milestone to GRASS 8.

Note: See TracTickets for help on using tickets.