views:

251

answers:

4

I am designing an application that needs to save geometric shapes in a database. I haven't choosen the database management system yet.

In my application, all database queries will have an bounding box as input, and as output I want all shapes within that database. I know that databases with a spatial index is used for this kind of application. But in my application there will not be any queries of type "give me objects nearby x/y" or other more complex queries that are useful in a GIS application.

I am planning of having a database without a spatial index and have queries looking like:

SELECT * FROM shapes WHERE x < max_x AND x > min_x AND y < max_y AND y > min_y

And have an index on the columns x (double) and y (double). As long I can see, I don't really need a database with an spatial index, howsoever my application is close to that kind of applications.

And even if I would like to have nearby queries, then I could create a big enough bounding box around that point. Or will this lead to poor performance?

Do I really need a spatial database? And when is a spatial index needed?

EDIT: The search queries will actually be a little bit more advanced than the one I wrote above, since I deal with geometric shapes I will input an Bounding box that will return multiple shapes (with bounding box) that are inside or interfere with the box in the query. But I still think I can do this without a spatial index, after been reading all good answers.

+2  A: 

No, you don't need a spatial index for this.

Spatial indices are needed for calculating distance between objects, seeing if a point is within a certain radius of another point, etc... mostly when you need to take geographical coordinates into consideration with. Southern hemisphere, northern hemisphere, etc... it all changes the distance a bit when you have to take the curve of the earth into consideration.

If you're always looking for both x and y than you would benefit from having an index on both items at the same time. So... not an index on column x and an index on column y, but an index on column x and y combined.

WoLpH
Thanks for the explanation and the suggestion of a combined index.
Jonas
+1  A: 

If you do not go beyond what you are already doing, you do not need a spatial index nor a GIS for that matter. However, I would carefully consider what your requirements are and chances of the application growing to need a GIS system. It is better than plan earlier than later for this transition.

GIS gives you several advantages. First, a GIS has special shape column for storing everything needed about a geometry. It manages spatial reference, coordinate metadata, etc. A GIS provides powerful methods for querying the data based on spatial relationships and modifying the geometries (unions, extractions, buffers, etc). It handles points, lines, polygons, etc. You can derive new shapes from topological operations. Additionally, almost all GIS systems provide means for rendering the data (this really depends on what GIS you choose but when it is present it saves you TONS of work).

You will only need spatial indexes if you have a true GIS environment. If you do choose a GIS environment, yes, use spatial indexes - you just really don't want to work without them.

j0rd4n
Thanks! I will design my application carefully. I will try to keep the advanced procedures in the front-end software and keep the back-end storage simple, so I can scale easy.
Jonas
+1  A: 

Do I really need a spatial database?

It looks like what you are doing will work fine for your application.

And even if I would like to have nearby queries, then I could create a big enough bounding box around that point.

You may want to consider creating an index on a Geohash instead. This method is recommended for indexing geo-spatial points on the Google App Engine, for example, where the indexing features are limited. (Source)

And when is a spatial index needed?

There are many scenarios where a spatial index is useful. First of all, spatial indexes can deal with not just points, but with polylines, polygons, and other shapes. In addition, as you already mentioned, there are many complex query operations that can be applied on spatial data, where a proper spatial index would be essential.

Daniel Vassallo
Thanks! The Geohash looks very good, thanks for the link. Yes, my database will also deal with not only points, but polygons and lines too. But the search-queries will only be on bounding boxes.
Jonas
+1  A: 

To add to existing excellent answers, performance might or might be not important here.

If you simulate a spatial index range query by doing two range queries for x and y axes and taking the intersection of results, you are, well, doing two queries which might return much more data than needed before the intersection.

On the other hand, such query is natively supported by a spatial index and as such will be answered efficiently.

All in all, if your spatial queries are the bottleneck, you will need to use a spatial index.

Laurynas Biveinis