What is difference between GEOMETRY and GEOGRAPHY in SQL Server 2008?
GEOMETRY is for planar spatial data (that is, data on a flat surface)
GEOGRAPHY is for terrestrial spatial data (that is, data on the (curved) surface of the Earth)
See eg here, here for more.
Read the wonderful manual at:
http://msdn.microsoft.com/en-us/library/bb933790.aspx
The geometry Data Type
The geometry data type (planar)
supported by SQL Server conforms to
the Open Geospatial Consortium (OGC)
Simple Features for SQL Specification
version 1.1.0.
For more information on OGC
specifications, see the following:
* OGC Specifications, Simple Feature Access Part 1 - Common
Architecture
* OGC Specifications, Simple Feature Access Part 2 – SQL Options
The geography Data Type
The geography data type (geodetic)
stores ellipsoidal (round-earth) data,
such as GPS latitude and longitude
coordinates.
It comes down to what model of the earth you're using - a planar or geodetic one.
Related
Why is the classification of multiple geographies a geometry type? For example:
SELECT ST_GeogFromText('POINT(0 1)') AS geography UNION ALL
SELECT ST_GeogFromText('GEOMETRYCOLLECTION(MULTIPOINT(-1 2, 0 12), LINESTRING(-2 4, 0 6))')
In other words, the string itself is GEOMETRYCOLLECTION instead of GEOGRAPHYCOLLECTION or FEATURECOLLECTION. Why is that so?
These things come from different standards / industry practices.
First, the spatial concepts and their WKT names like POINT and GEOMETRYCOLLECTION come from OGC and SQL/MM standards:
https://www.ogc.org/standards/sfs
https://www.iso.org/standard/60343.html
These standards describe spatial objects, and define WKT representation for POINT, LINESTRING, POLYGON, GEOMETRYCOLLECTION.
Second, once users realized the planar world of GEOMETRY type is not enough, various databases invented ways to handle spherical / geodesic geometries. The most popular way the industry uses to define spherical geometry is a different SQL type GEOGRAPHY. Note that GEOGRAPHY is not a standard thing, but rather a common industry practice. Some databases, like MySQL, does not use GEOGRAPHY type, but use spherical math with geographic SRID. Anyway, when GEOGRAPHY type is written to WKT, it still uses GEOMETRYCOLLECTION name for compatibility. So GEOGRAPHY comes from SQL type, GEOMETRY from WKT standard.
Finally, FeatureCollection is used sometimes to represent sets of object that have a geometry property and additional properties, e.g. in GeoJson format. You'll rarely see it used with SQL databases - the FeatureCollection simply corresponds to a table.
I'm developing rest api (with postgresql data base and postgis) method to get point in requested srid.
There's a method in Postgis which is transforming geometry from current srid to another.
geometry ST_Transform(geometry g1, integer srid);
https://postgis.net/docs/ST_Transform.html
So I want to know which SRIDs are supported by the method? The official documentation doesn't provide answer.
So I added geometry columns to a spatial table and using some of the msdn references I ended up specifying the SRID as 0 like so:
update dbo.[geopoint] set GeomPoint = geometry::Point([Longitude], [Latitude], 0)
However, I believe this was a mistake, but before having to update the column, is 0 actually the default = 4326? The query works as long as I specify the SRID as 0 on the query, but I'm getting weird results in comparison to the geography field I have... SRID 0 does not exist in sys.spatial_reference_systems and I haven't been able to dig up any information on it. Any help would be appreciated.
A SRID of 0 doesn't technically exist, it just means no SRID -- ie, the default if you forget to set it. So, technically, you can still perform distance, intersection and all other queries, so long as both sets of geometries have a SRID of 0. If you have one field of geometries with a SRID of 0 and another set with a SRID that actually exists, you will most likely get very strange results. I remember scratching my head once when not getting any results from a spatial query in exactly this situation and SQL Server did not complain, just 0 results (for what is is worth Postgis will actually fail, with a warning about non-matching SRIDs).
In my opinion, you should always explicitly set the SRID of your geometries (or geographies, which naturally will always be 4326), as not only does it prevent strange query results, but it means you can convert from one coordinate system to another. Being able to convert on the fly from lat/lon (4326), to Spherical Mercator (3857), as used in Google Maps/Bing, which is in meters, or some local coordinate system, such as 27700, British National Grid, also in meters, can be very useful. SQL Server does not to my knowledge support conversion from one SRID to another, but as spatial types are essentially CLR types, there are .NET libraries available should you ever need to do so, see Transform/ Project a geometry from one SRID to another for an example.
If you do decide to change you geometries, you can do something like:
UPDATE your_table SET newGeom = geometry::STGeomFromWKB(oldGeom.STAsBinary(), SRID);
which will create a new column or to do it in place:
UPDATE geom SET geom.STSrid=4326;
where 4326 is just an example SRID.
There is a good reference for SRIDs at http://spatialreference.org/, though this is essentially the same information as you find in sys.spatial_reference_systems.
SRIDs are a way to take into account that the distances that you're measuring on aren't on a flat, infinite plane but rather an oblong spheroid. They make sense for the geography data type, but not for geometry. So, if you're doing geographic calculations (as your statement of "in comparison to the geography field I have"), create geography points instead of geometry points. In order to do calculations on any geospatial data (like "find the distance from this point to this other point"), the SRID of all the objects involved need to be the same.
TL;DR: Is the point on the Cartesian plane? Use geometry. Is the point on the globe? Use geography.
I have a large collection of checkins for products manufactured at a distinct geographic location. I'd like to create a summary metric used to rank these products by how far, globally, they have traveled from their point of origin. For example, a product produced in Maine that is found in California, Florida, and Dublin, Ireland should rank higher than a product made in California that hasn't been seen outside of California.
What kind of algorithms should I be looking at? How would you approach this?
MS SQL Server (which I've just spotted may not be relevant to you) includes spatial data types that allow you to calculate (among other things) the distance between two points defined by their latitude and longitude. So this code:-
DECLARE #p1 geography = geography::Point(#lat1, #long1, 4326);
SELECT #distance=#p1.STDistance(geography::Point(#lat2, #long2, 4326))
would load #distance with the distance in metres between the two points. I lifted the code from a scalar valued in line function that I wrote - but it could also be targeting table columns directly. The 4326 magic number is a reference to the Spatial Reference System Identifier (SRID) that provides answers in metres. This calculation doesn't take into account altitude and the distortion of the globe (other functions/SRIDs are available for this) but it's probably accurate enough for most purposes.
Unfortunately, if you are restricted to postgresql, this answer is of no use (though it may point you in a direction for further investigation).
A reference for Sql Server can be found here : http://technet.microsoft.com/en-us/library/bb933790.aspx
I have a database, which uses the GGRS87 reference system, and contains x-y coordinates of objects. I need to convert them to lat/lon, so that I can store them in SQL Server 2012 using Geography data type.
Or is there a way I can use those x-y coordinates directly to create a geography data? Please let me know.
You can use the xy value directly to create the geometry objects, as long as you know the SRID code for the GGRS87 co-ordinate system (I think it's 4121).
Then use the STGeomFromText method to create your features. E.g.
INSERT INTO SpatialTable (GeogCol1)
VALUES (geography::STGeomFromText('POINT(122 47)', 4121));