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));
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 looking at the freely available Solar potential dataset on Google BigQuery that may be found here: https://bigquery.cloud.google.com/table/bigquery-public-data:sunroof_solar.solar_potential_by_censustract?pli=1&tab=schema
Each record on the table has the following border definitions:
lat_max - maximum latitude for that region
lat_min - minimum latitude for that region
lng_max - maximum longitude for that region
lng_min - minimum longitude for that region
Now I have a coordinate (lat/lng pair) and I would like to query to see whether or not that coordinate is within the above range. How do I do that with BQ Standard SQL?
I've seen the Geo Functions here: https://cloud.google.com/bigquery/docs/reference/standard-sql/geography_functions
But I'm still not sure how to write this query.
Thanks!
Assuming the points are just latitude and longitude as numbers, why can't you just do a standard numerical comparison?
Note: The first link doesn't work without a google account, so I can't see the data.
But if you want to become spatial, I'd suggest you're going to need to take the border coordinates that you have and turn them into a polygon using one of: ST_MAKEPOLYGON, ST_GEOGFROMGEOJSON, or ST_GEOGFROMTEXT. Then create a point using the coords you wish to test ST_MAKEPOINT.
Now you have two geographies you can compare them both using ST_INTERSECTION or ST_DISJOINT depending on what outcome you want.
If you want to get fancy and see how far aware from the border you are (which I guess means more efficient?) you can use ST_DISTANCE.
Agree with Jonathan, just checking if each of the lat/lon value is within the bounds is simplest way to achieve it (unless there are any issues around antimeridian, but most likely you can just ignore them).
If you do want to use Geography objects for that, you can construct Geography objects for these rectangles, using
ST_MakePolygon(ST_MakeLine(
[ST_GeogPoint(lon_min, lat_min), ST_GeogPoint(lon_max, lat_min),
ST_GeogPoint(lon_max, lat_max), ST_GeogPoint(lon_min, lat_max),
ST_GeogPoint(lon_min, lat_min)]))
And then check if the point is within particular rectangle using
ST_Intersects(ST_GeogPoint(lon, lat), <polygon-above>)
But it will likely be slower and would not provide any benefit for this particular case.
How would I create a table that contains a geography point (lat/long) using PostGIS? Then also, what would the format be for inserting into this table (Using SQL/PostgreSQL)?
Would it just the following for table creation:
CREATE TABLE x (geog geography(point, 4326))
If so, what is the point and when would you instead use ST_Point(X,Y)
Should this column have an index?
Note: Many questions previously answered detail how to convert. But I want to create an empty table from scratch that supports storing latitude and longitude.
Yes, the Syntax for Creating a table with Geography is as simple as CREATE TABLE x (geog geography(POINT,4326) );
In this Command, POINT is the type of shape that this table will be storing. Other possibilities are :
LINESTRING
POLYGON
MULTIPOINT
MULTILINESTRING
MULTIPOLYGON
GEOMETRYCOLLECTION
The reason why storing a Geography in a table makes sense in some cases, is that it gives you the ability to run several functions which would give you results as if you are calculating on a Spherical Earth. So for example I could have two points stored as Geography (knowing only lat-long of each), and I could easily find the distance between them in Meters
ST_Point(X,Y) is just a function that takes in two numbers, and then creates a point which has X as the first number and Y as the second number. It need not be a Lat-long pair. Infact this Point has not concept of which Coordinate reference system it is in.
Once you create the table, inserting records in it, is as simple as:
INSERT INTO X (geog) VALUES (ST_GeographyFromText('POINT(2.5559 49.0083)'));
Here You are are creating a Geography point for Paris, with latitude of 49.0083N and longitude of 2.5559 E
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'm working with postgresql with postgis.
I have few questions:
trying to insert into a table with polygon column using the following syntax:
ST_GeomFromText('POLYGON((long1 lat1, long2 lat2, long3 lat3))')
fails with the following error: function geomfromtext(unknown) does not exist
what is the difference between
CREATE TABLE my_table (my_polys polygon);
and
CREATE TABLE my_table2 (my_polys GEOGRAPHY(POLYGON));
and why does the following:
INSERT INTO my_table (my_polys) VALUES ('
(51.504824, -0.125918),
(51.504930, -0.122743),
(51.504930, -0.110297),
(51.504824, -0.102229),
(51.503435, -0.099311)'
);
work fine with my_table and not with my_table2 (I've changed the table name to my_table2)
what is the maximum number of points a polygon can have?
The geography data type is mostly useful when your geometry might wrap around the date line. If it does not, you are better off using normal geometry data types, as most functions in Postgis are designed to work on planar geometries. If your data are lat/lon, you can explicitly set this when you create your column with:
create table foo geom geometry(POLYGON, 4326);
Explicitly setting the coordinate reference system is useful if you want to convert between one coordinate system and another and helps prevent suprises if you attempt to run an intersection, say, between geometries in different coordinate systems.
It is hard to imagine your insert fragment above working with any table, not only is there a trailing comma, but there is no st_geomfromtext, st_makepolygon or anything else to convert what you have written into any geometry.
I have no idea what the maximum size for a polygon is, although, as Chris has already said, you are likely to have performance issues with polygons of 1gb in size, when you try and do spatial queries on them.
Your polygon size is limited by the max storage size. I believe this is limited to 1gb for a toasted column, though my guess is that you are likely to run into performance issues long before you exceed the maximum number of points.
Polygon is a built in type in PostgreSQL, and PostGIS offers additional types for geometry and geography. As I understand it the built-in-types only work for 2d Euclidean space, while PostGIS offers additional options there.
As for why your query fails, I wonder which version of PostGIS you are running and why st_geomfromtext is calling geomfromtext.