I have been working on a web project that stores locations for users. The project uses currently MySql 5.5 and JPA 2 for mapping the relation database, together with EJB 3.1 as the middle tier. I store longitude and latitude data in Decimal data types in MySql.
I want to expand the project so the user can search for Points (GPS coordinates) near the location he/she marks out (through using Google Map API 3) on the map.
I need some hints and suggestions before starting transforming or changing components in my project. If possible with tutorial and how to achieve the changes and what tools (library, dev tools, etc.) to use. Here are my questions.
Can I use the Spatial extension in MySql (using data types like Point) and map this to entities that are supported by JPA 2 (like DataNucleus library, if they are supported by JPA 2). That are light weight and can persist them self through the persistent layer.
Is it better to move to PostGIS and Postgres (which seem to have better spatial support) with all the pain and effort needed to change database and using hibernate instead. Netbeans has Hibernate support but when trying with the JDBC for PostGis I stumble upon problems. Need a good tutorial to follow to get started if I go down this road.
Using the infrastructure that is already in-place and compute the distance from lactation A and B. Similar to the way done in this article by Jan Philip Matuschek
Excuse me for clustering the questions.
Regards Chris
MySQL's Spacial extension is usually OK if you only have point locations, but it starts to get overwhelmed if you want to find points in polygons (i.e., query by region), or use fancy indices and search algorithms. There is a really good cross comparison to help show the differences between the different spatial DBs.
I'd see that there are many more benefits to migrating to PostgreSQL and PostGIS. There are also many more GIS applications that work naively with PostGIS, such as QGIS, Geoserver, etc. The most recent version of PostGIS has a KNN nearest neighbor search operator to quickly find, for example, the nearest 25 points out of several million rows to a particular point on your map (see also here).
See the manual for JDBC and PostGIS. As for JPA, see PostGIS and JPA 2.0
As for distance calculations, see ST_Distance and ST_Distance_Spheroid.
I'm currently using MySQL and Solr, but considering making some changes. Should I keep on using Solr for location-based search, or move the entire thing over to MongoDB?
I did some experiments with both MongoDB & Solr. Don't have many data points to share, but from what I remember Solr had a much better performance than mongoDB when combining queries including both location and text.
Overall, since MongoDB does not have full-text search capability, and you are already using Solr, I would recommed to continue using it for search.
You can compute a geohash on your own. I've wrote a php library to lookup point of sales based on lat-lng pairs and spatial index. I also used it for a hierarchical cluster. It makes you indepedent from the database vendor and you have much more choice of the spatial index. You can grab my library at phpclasses.org (hilbert-curve).
I'm new to the concept of GIS in databases and am looking for a solution that allows me to do the following:
- store polygon areas in a record field
- Store geographical points. These points will contain latitude and longitude coordinates (GPS).
- query database for all records, whose polygons intersect with a given point.
- query database for all records, whose points intersect with a given area
Any recommendations?
thanks,
Fbr
PostGreSQL with the PostGIS extension. Free open source, very mature.
SQL Server 2008 has built-in Spatial Extensions. Even in the free Express Edition.
Oracle
MySQL 5.6.1 or later has built-in spatial extensions.
More information here on different spatial databases and here on learning about spatial databases
I'm about to start a GIS project, and I want to know if I really need PostGIS or if MySQL's Spatial Extensions are sufficient?
PostGIS is a complete spatialdb and has been for a while. MySQL continues to only implement the Minimum Bounding Rectangle functions
http://dev.mysql.com/doc/refman/5.5/en/functions-for-testing-spatial-relations-between-geometric-objects.html
If you want to do spatial work on FOSS DB your only real choices at this point are
1) PostGIS
2) Spatialite
There are community editions of the other DBs that have spatial extensions as well that you can use.
Has any of you had any experience with using NoSQL (non-relational) databases to store spatial data? Are there any potential benefits (speed, space, ...) of using such databases to hold data for, say, a desktop application (compared to using SpatiaLite or PostGIS)?
I've seen posts about using MongoDB for spatial data, but I'm interested in some performance comparison.
graphs databases like Neo4j are a very good fit, especially as you can add different indexing schemes dynamically as you go. Typical stuff you can do on your base data is of course 1D indexing (e.g. Timline or B-Trees) or funkier stuff like Hilbert Curves etc, see Nick's blog. Also, for some live demonstration, look at the AWE open source GIS desktop tool here, the underlying indexed graph being visible around time 07:00 .
Currently, MongoDB uses geohashing with B-trees which will be slower than the R-trees of PostGIS (I can't give exact numbers, I'm afraid, but there is plenty of theoretical literature on the differences). However, in these slides, http://www.slideshare.net/nknize/rtree-spatial-indexing-with-mongodb-mongodc the author talks about adding R-trees to MongoDB and sharding on a geo key. You talk about desktop use, so geosharding may not be of interest, as sharding's benefits will be felt more on massive datasets.
Ultimately, it probably comes down more to what you want to do with your spatial data. Postgis has vastly more functions and support for topology, rasters, 3D, conversions between coordinate systems, so if this is what you are looking for, PostGIS would still be the best option. If you are interested in storing billions/trillions of spatial objects and just running basic find all points near/inside this point based on some criteria, then MongoDB is likely a very good choice.
Couchdb also has a simple spatial extension
http://vmx.cx/cgi-bin/blog/index.cgi/category/CouchDB
I've been storing spatial data with ZODB. There's some inherent performance advantage in accessing local file data (spatialite) or unix socket (PostGIS) compared to TCP or HTTP requests (CouchDB etc), surely, but having an spatial index makes the biggest difference. I'm using the same R-trees mentioned in the MongoDB article, but there are plenty of good options. The JTS topology suite has various spatial indexes for Java.
Cassandra is also an option for spatial data:
http://www.readwriteweb.com/cloud/2011/02/video-simplegeo-cassandra.php
Tarantool supports spatial two-dimensional index (RTREE) with nearest neighbor search, overlaps, contains, and other spatial operators. Tarantool maintains the entire data set in RAM, making it the only OSS in-memory database with spatial index support.
https://github.com/tarantool/tarantool/wiki/R-tree-index-quick-start-and-usage
MarkLogic(Enterprise NoSQL) provides spatial functionality. This NoSQL product provides GIS applications the ability to conflate multiple objects into one entity. This provides support for managing relationships across structured and unstructured content, provenance and pedigree information about the data, historic and timeline information, etc. in a single entity.