none
Projected Coordinate System Support RRS feed

  • Question

  • I checked out the sys.spatial_reference_systems view to see what reference systems were supported by Katmai.  I noticed only GCS was supported and no projected coordinate systems were existed in the view.  Are these going to be added in the official release of SQL Server 2008?






    Thursday, January 10, 2008 9:41 PM

Answers

  •  

    The coordinate systems in sys.spatial_reference_systems are for the geography type only as it contains information about the ellipsoid that is required to perform calculations.  No such information is required to perform calculations for projected coordinate systems on the plane used by the geometry type, so you are free to use any reference system you like.  For the calculations done by the geometry type, it is the same no matter what you use.
    Friday, January 11, 2008 7:48 AM
    Moderator

All replies

  •  

    The coordinate systems in sys.spatial_reference_systems are for the geography type only as it contains information about the ellipsoid that is required to perform calculations.  No such information is required to perform calculations for projected coordinate systems on the plane used by the geometry type, so you are free to use any reference system you like.  For the calculations done by the geometry type, it is the same no matter what you use.
    Friday, January 11, 2008 7:48 AM
    Moderator
  • I would suggest to add future support for projected coordinate systems for the following reasons:

    1. GCS overlay functions currently check Geographic types for identical coordinate systems and return null when different.  Geometry types aren't checked so you could potentially overlay UTM Zone 15 NAD83 geometries on a Lambert Conformal Conic geometry. 
    2. Katmai already adopts the EPSG coordinate system standards.  The EPSG projected coordinate systems could easily be included in sys.spatial_reference_systems in addition to the geographic crs already populated. 
    3. The Geometry type has a placeholder to store the CRS already (Geometry.SRID).  Why is it there if it just is going to default to a value of 0?
    4. For pure metadata reasons it would beneficial to store the CRS for geometry types in Geometry.SRID.  I suppose a developer could populate it with the EPSG projected CRS id, but I'd still look to have those id's prepopulated in sys.spatial_reference_systems and have the SRID validated when doing overlays. 


    Friday, January 11, 2008 2:11 PM
  • Hi,

     

    I think there's a slight misconception.  Although we don't enforce any particular scheme for SRIDs in the Geometry type, they aren't semantically irrelevant.  In particular, we do (1) above: if two items have different SRIDs, then operations between them will return null.  The SRID defaults to 0, but can be set to anything.  We recommend following EPSG numbering.

     

    Cheers,

    -Isaac

     

    Friday, January 11, 2008 3:19 PM
    Moderator
  • MapInTheBox: No one is saying that you can't add the extra CRS's to sys.spatial_reference_systems. I took the SQL script for PostGIS and adjusted it to work with SQL Server so it fills in the missing CRS's.

     

    Katmai doesn't have any reprojection support, so the whole sys.spatial_reference_systems table is more or less useless anyway.

     

    As far as I can tell, there is only one use for that table. Geography uses it to figure out which linear unit it should use for buffer, distance, area, etc., but technically a linear unit has absolutely nothing to do with a geographic datatype, and it's a mystery to me why they chose to link a linear unit to a geographic CRS (why not just make the output be consistent in SI units, so I don't have to join on the SRID and multiply with the scale factor to get a consistent unit for the output)

    Saturday, January 12, 2008 6:55 AM
    Answerer