If anyone has ever seen any of Paul's presentations or slides, you'll remember his famous
Intro To PostGIS
and slide Is MySQL a spatial database?, answer: Not Really. The functions only work against bounding boxes.. (page 5). And Paul's They keep on threatening us.
Well Paul, I'm afraid you'll have to change that slide. They have finally made good on their threats and we PostGIS folks need to now keep a watchful eye.
We've lost interest for the most part in what MySQL does these days, except for the few customers we have that are still running MySQL that the migration to something else isn't worth the bother. We've lost interest mostly because MySQL movement in areas we care about have been so slow and PostgreSQL movement has been so fast. I did come across this tidbit reading
Comparing Open Source GIS Implementations and to my shock Oh my god! Stop the presses, MySQL 5.6 has true Spatial relationship support.
The other thought I had is thank goodness PostGIS legacied all those non-ST functions like Contains(), Intersects etc, as that would cause people who use both databases even more confusion. Here are some important take-away points from MySQL 5.6 Spatial support:
- The old MBR alias functions Contains, Overlaps, etc, still only work against the bounding box. To get true checks, you need to use the ST_ variants
- While you can create geometries on InnoDb tables now, you can only create R-tree spatial indexes on MyISAM tables.
- I could be missing something, but don't see an ST_Distance function or anything like it. I don't have 5.6 handy to test, so if anyone knows, please correct me if I am wrong.
- General footnote, MariaDb also supports this new functionality in its 5.3+ versions