I want to know how to convert a SQL database in to SQL spatial db.
I have a SQL database "Register" which contains some tables as cables, components, etc. How can I make this database Spatial database.
Can somebody help me with how to do it?
I forgot to say that the database is SQL Server 2008, version 10.50.1600.1
I'm trying to find a description on the Internet, how to do it, but unfortunately I can not find.
If your asking how to convert latitude and longitude coordinates into spatial data, Sql server 2008 has functions like STGeomFromText that can be utilized like
INSERT INTO SpatialTable (GeogCol1)
VALUES (geography::STGeomFromText('POLYGON((-122.358 47.653 , -122.348 47.649, -122.348 47.658, -122.358 47.658, -122.358 47.653))', 4326));
GO
Or if you want to add a spatial column, you could use a computed column and add
geography::STGeomFromText('Point('+LongitudeColumn+' '+LatitudeColumn+')', 4326)
to the default value. This would work well for a spatial point. If you needed to do more complex shapes like polygons and polylines, I would suggest searhing here and here
It would be great to know what types of spatial data are you looking to store in your "spatial" database. Point (cities as an example), line (streets), polygons (sales areas) . Nothing makes a database spatial but tables that contain geometry and geography datatype fields make tables spatial. Create a table with a field of datatype geometry or geography and think about what you want to store in it (Points, Lines, Polygons) is a good start.
Related
Do we need spatial index for point type geometry in SQL Server?
If yes, how Tessellation and grid selections work in point type geometry?
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 was working with SQL Server 2008 Spatial Data, but I got a weird problem that the Spatial Index created for the tables doesn’t work when I query them with the view which is created based on this table. Following is the scripts I was using:
declare #Geometry1 geometry = geometry::STGeomFromText(
'POINT(937767.89433333278 -230404.864666667)', 102003)
exec sp_executesql
N'SELECT shape FROM view WHERE (#Geometry1.STIntersects(SHAPE)=1);',
N'#Geometry1 geometry', #Geometry1
I googled a lot and found an workaround at http://www.sqlskills.com/blogs/bobb/how-to-ensure-your-spatial-index-is-being-used/ , but seems like this workaround just works when the queried geometry is point type, for polygons, like the script as following:
declare #Geometry2 geometry = geometry::STGeomFromText(
'POLYGON((-2079214.0399 1392052.275,-2079214.0399 -1156112.025,
1981332.1069 -1156112.025,1981332.1069 1392052.275,
-2079214.0399 1392052.275))', 102003)
exec sp_executesql
N'SELECT shape FROM view WHERE (#Geometry2.STIntersects(SHAPE)=1);',
N'#Geometry2 geometry', #Geometry2
The spatial still doesn’t work. Anybody knows how to deal with this situation? Seems like the Microsoft doesn’t give a good instructions about this.
Any response will be appreciated.
Please use the diagnostics stored procedure sp_help_spatial_geography_index_xml and look at its' output.
This is the primary stored procedure you can use to get an idea of how your geospatial index could be used.
Given that your query is so simple, the #query_sample argument to sp_help_spatial_geography_index_xml can be the same as your #geometry parameter. This will tell you some fairly useful information, such as whether the spatial index needs a full scan to evaluate the question.
Another thing to point out: The dynamic management object view sys.dm_db_missing_index_details explicitly states in the documentation that it does not support spatial indexes, ergo SQL Server does not instrument a lot of intelligence around these indexes.
I have a SQL Server instance that I've added a linked server to another SQL instance. The table I'm accessing on the linked server contains spatial types. When I try to query the table I receive an error:
Objects exposing columns with CLR types are not allowed in distributed
queries. Please use a pass-through query to access remote object.
If I use OPENQUERY with the same query I get another error:
A severe error occurred on the current command. The results, if any,
should be discarded.
Is there any way to query tables that contain spatial types via linked servers?
One way to work around this is to pass spatial data as NVARCHAR(MAX)
select go=geometry::STGeomFromText(go,0)
from openquery([other\instance],
'select go=convert(nvarchar(max),go) from tempdb.dbo.geom')
note: go is a column name, short for geometry-object
Or using the function instead of explicit cast
select go=geometry::STGeomFromText(go,0)
from openquery([other\instance],
'select go=go.STAsText() from tempdb.dbo.geom')
I came across the same problem, but accepted solution wasn't an option in my case, due to many applications that couldn't be changed to expect a totally different query.
Instead, I think I found a way to cheat the system. On local server run:
CREATE VIEW stage_table
AS
SELECT *
FROM OPENQUERY([REMOTESERVER],'SELECT * FROM [REMOTEDB].[SCHEMA].TARGET_TABLE');
GO
CREATE SYNONYM TARGET_TABLE FOR stage_table;
GO
Voila, you can now simply use
SELECT * FROM TARGET_TABLE;
Which is probably what your applications expect.
Tried the above scenario with local server: SQLEXPRESS 2008 R2, and remote server SQL EXPRESS 2014.
I have another workaround. It doesn't apply to the OP's question since they were trying to select the spatial data. Even if you are not selecting the columns containing spatial data, you'll still get this error. So if you need to query such a table, and do not need to retrieve the spatial data, then you could create a view for the table (selecting only the columns you need, excluding the spatial data columns), then query against that view instead.
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.