I am selecting a number of Geometry types from a SQL server database; when I reduce, I am having issues getting the most reduction without my polygons collapsing in on each other.
Select
Polygon.Reduce(#reduceAmount).ToString()
FROM
PolygonTable
Is there way to reduce to a specific type of Geometry (like a polygon)?
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.
For storing Geospatial data, Geometry field is used in SQL server or Oracle Spatial. I want to know is there any way where we can convert this geometry field into set of latitudes and longitudes.
I'm assuming that the data in your geometry column is expressed using a projected coordinate reference system? If so, you'll have to unproject and/or transform it into the appropriate geographic coordinate reference system first. For Google Maps, this needs to be EPSG:4326 (WGS84)
Simply converting between the geometry and geography columns via WKT or WKB as suggested by paulH will not change the type of coordinates in which your data is expressed, and SQL Server provides no in-built transformation functions. Instead, you must make use of a third-party library such as Proj.NET (http://projnet.codeplex.com) which provides both projection and datum transformation functions using 7-parameter Helmert transforms. It's relatively easy to import this library and then create a SQLCLR procedure based on it to convert data between different SRIDs.
Once you've got a column of geography coordinate data in the correct SRID, you can select the latitude/longitude coordinate values of a given point using the Lat and Long properties.
If you can convert the Geometry field to a Geography data type (this article has some examples of how to do that), then you can select GeographyValue.Lat and GeographyValue.Long.
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.
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.