I have a Microsoft SQL Server database with a table of Locations. Each location has its address and latitude and longitude coordinates.
In my application, the user can input a zipcode and we return a list of close by locations.
This is my approach.
a) Using a zipcode DB I search the lat,lon for the zipcode (this is the center point).
b) I run a search like this
SELECT Position_ID, distance(pos_lon,pos_lat,zip_lon,zip_lat) dist
FROM Positions
ORDER BY dist
"distance" is a function that calculates the distance between two points.
The problem is that as my location DB increases the time to run these searches is starting to grow.
Is there a better approach?
If you're using SQL Server 2008, you probably want to look into the geography column type, the STDistance function and spatial indexes.
Spatial Indexing Overview
Geography Methods Supported by Spatial Indexes
How to: Create a Spatial Index
I would do a calculation of the box surrounding your zip code at the specified distance to get the lat/lon values for the four corners. Then do a simple comparison of your position values to select those which fall inside the square. This way, you don't have to calculate the distance from your zip code to every point in your db for every search.
Which version of SQL server? If 2008 have a look at the spatial type.
http://www.microsoft.com/sqlserver/2008/en/us/spatial-data.aspx
EDIT: Also limiting that query with a where would probably help as you likely don't want to go to far in any particular direction.
Related
Thanks in advance for any insight. I am new to using the spatial functions in SQL Server. I would appreciate it if someone could point me to the basic correct approach to solving a problem I have.
I am working with a client that monitors gas wells that are accessible from waterways. In a given day, a boat travels from point A to point B along the river. I have that "route" as a series of Lat/Long values that can be plotted on a map. I'm thinking that this would be used as a LineString in SQL Server.
I also have a list of known wells, along with their Lat/Long positions. I would like to store these records in a database, and index the Lat/Long with a spatial index of some sort. I'm not 100% sure how to index the table correctly, but it would contain the columns Lat/Long/WellName/Owner, etc.
The feature needs to do the following: Given the Lat/Long of the route the boat takes in a given day (the LineString and all of it's points), find all of the wells that are within 2000 feet of that line. The workers will get off of the boat and go to the well to perform maintenance on them. Each day they will work a different section of the river.
Again, I'm looking for directional advice on what the Wells table (tblWells) needs to be, and also create a stored procedure that accepts the Lat/Long of the line points as a nvarchar(MAX) input parameter. For now, it only needs to return all of the wells that are within 2000 feet of any point on the line.
Sincere thanks to anyone who takes the time to help.
Kindest regards...
First, you'd need a table of wells:
create table dbo.Wells (
WellId int identity not null,
Name varchar(50) not null,
Owner varchar(50) not null,
Location geography not null
)
And then a procedure to search for wells within a certain distance of a given path:
create procedure dbo.FindWells
(
#Path geography,
#Distance float
) as
begin
declare #buffer geography = #Path.STBuffer(#Distance);
select WellId
from dbo.Wells
where #buffer.STContains(Location);
)
If you really want to pass your path as a varchar, go for it; just make transforming it into a geography instance with geography::STLineFromText or something like that.
As for the indexing on the table, create a spatial index on the Location column. Play around with the resolution, but I'm guessing that given your use case, the first three resolutions will be low with the last being high. Play around with it, though.
I need some help, I have a stored procedure(SP) that contains NO parameters in SSMS. The SP generates spatial data by joining 2 tables one table containing two fields needed for labelling purposes and the other from a table that containsthe GEO field.
This SP populates spatial data in SSMS which I can view and interact with. All seems well so far...
I then use SSRS to create a data source and a dataset of the said stored procedure. Following this I create a new .rdl and insert a map choosing SQL Server spatial query as the source then selecting the stored procedure dataset. Following this SSRS attempts to join the data and I then receive the error from the Microsoft SQL Server Report Designer:
Unable to determine the spatial data type in the specified dataset field: GEO
I have searched the the internet for answers already and none suit predominately because they all refer to parameters causing the issue however my query does not contain nor pass any. I have tried the geo field as both a geography and geometry datatype no avail.
Any help or advice would be great.
I have just been playing with a Heat Map in SSRS using SQL Jason's example (http://www.sqljason.com/2012/03/heat-maps-for-ssrs-using-map-control.html).
It looks like your data doesn't have enough points. According to Teo Lachev (http://prologika.com/CS/blogs/blog/archive/2009/08/30/heat-maps-as-reports.aspx):
SQL Server describes polygons in Well-Known Text (WKT) standard
sponsored by Open Geospatial Consortium. For instance, a polygon is
described as five (surprise) points on the coordinate system, as
shown below. The fifth point is the same as the first point.
The example format you gave only had four points. The first and last are the same so there seems to be a missing point or you are not graphing rectangles. It doesn't look like the Spatial Data supports any other shapes. The Map wizard only shows rectangles in the Wizard when creating the map.
I'm looking around for any answer which I could for my purpose but I'm not able to find it, so I've decided to submit a question.
I have several tables with geography type fields inside and i need to define a where clause for finding all the records within an ellipse.
My ellipse properties are: minoraxis, majoraxis, point and rotation. I already have the where clause which look for a geography inside a circle shape. It's something like this:
select *
from locations
where shape.STIntersects(geography::STPointFromText('POINT(32.113, -81.3225)', 4326).STBuffer(10)) = 1
How could I do it?
Thanks in advance.
I have a table containing many SQL Server Geography Coordinates (geography datatype). The points are correctly ordered in the table. I want to combine these points to a line and calculate the total length of the polyline.
My idea was the following:
UNION the Geography Coordinates. (this creates a MULTI POINT.)
Convert the MULTI POINT to a LINE STRING.
Use .STLength() to get the length
Is there an efficient way to union existing point without constructing a LINESTRING from a string?
I am using SQL Server 2012.
I would like to cross-reference construct a distance chart similar to the one here (example is a road-distance cross-reference chart) and, ideally, store the data in SQL Server 2008 (preferably the Express version). It needs these properties / abilities
Every column has a corresponding row with the same name (ie. not misspelled like my example).
Changing the value at one Row-Column intersection would update the mirror intersection (Column-Row) or the mirror data could be ignored.
The distance-values would need to be end-user editable.
The end-user would need to be able to add, delete or rename a column/row pair.
The end-user needs to be able to sort the columns and have the rows move automatically.
There could be hundreds of pairs.
a look-up query needs to find a distance given a start & destination (Row & Column)
The distance chart is reasonably straightforward to implement in Excel. Considering this, am I better off...
Using Excel as the user editing UI and then updating an SQL 'thing' with the new data?
Using Excel as the data-source even if it means performance issues with querying the data?
Using an as-yet undiscovered stroke of genius detailed here in an answer?
Sure looks like an Excel application to me, start to end. (heh)
I can't imagine your users typing enough data in to make performance an issue. Excel will only take 32757 rows by ditto columns. If that's enough, I'd say you're golden.