locked
2 Questions on Geometry -v- Geography RRS feed

  • Question

  • Hi there,

    Just started using the Feb 2008 CTP, and very interested to get more stuck into the spatial methods. I've come across a few questions which I'd be really grateful if anybody could answer:

    1.) Given the relative simplicity of the flat-earth planar model compared to the round-earth ellipsoidal model, is it fair to assume that methods performed against geometry data types will perform better than the equivalent method against a geography data type?

    2.) What is the difference between instantiating a geometry datatype compared to instantiating a geography datatype with an SRID of 0?

    Any help would be gratefully appreciated.

    a.
    Sunday, February 24, 2008 3:46 PM
    Answerer

Answers

  • You cannot create a geography datatype with SRID=0. Only Geometry allows you to create features with no spatial reference (but of course you don't do something messy like that right? :-))

    You can find the valid SRIDs you can use for geography types in the sys.spatial_reference_systems catatog view..

     

    The basic reason for this constraint is that Geography uses the SRID to figure out how to do its distance and area calculations (the SRID defines the unit and size/shape of Earth).

     

    This leads me to the first question. Doing correct distance measurements in the planar coordinate system is more tricky, especially over large distances, where you have to accommodate for scale reductions, distortions etc. So if you need these type of operations, I think you are better of with using Geography. I can't say whether it is slower, but doing a distance/area calculation in spheric coordinates takes a few more operations than using basic euclidean formulas. I wouldn't know with the spatial index, but it's been designed for use with geographic datatypes, so I doubt that it would be much different.

    Also note that Geography has fewer spatial operations available.

     

    Another thing you could do is have both a geometry and a geography row in your table, and take the best from each (comparing performance should also be pretty straight forward then)

    Sunday, February 24, 2008 7:48 PM
    Answerer
  • The big difference here is spherical geometry vs. planar geometry. The math behind the two are completely different, and one can never be a special case of the other. I recently wrote a blogpost that partially covers some of these aspects:

    http://www.sharpgis.net/post/2008/01/12/Straight-lines-on-a-sphere.aspx

     

    The SRID is not really enforced on geometry (or used for anything, except that they have to match for most of the spatial operations), but its a good idea to remember to use it anyway. There might very well soon be 3rd party clients out there that will make use of it, and it's also a good idea to keep a unit on your values. You can say that the Spatial Reference ID is to geometry what for instance 'meter' is to distance. Without a unit, the values doesn't make any sense.

     

    I also like to put a SRID constraint on my table to ensure that all geometries in the table has the same SRID. You can do that using:

    ALTER TABLE [tablename] ADD CONSTRAINT [enforce_srid_geometrycolumn] CHECK (geometrycolumn.STSrid = 4326);

     

    Btw. most samples I've seen use -1 for unknown ID (not 0)

    Sunday, February 24, 2008 11:19 PM
    Answerer

All replies

  • You cannot create a geography datatype with SRID=0. Only Geometry allows you to create features with no spatial reference (but of course you don't do something messy like that right? :-))

    You can find the valid SRIDs you can use for geography types in the sys.spatial_reference_systems catatog view..

     

    The basic reason for this constraint is that Geography uses the SRID to figure out how to do its distance and area calculations (the SRID defines the unit and size/shape of Earth).

     

    This leads me to the first question. Doing correct distance measurements in the planar coordinate system is more tricky, especially over large distances, where you have to accommodate for scale reductions, distortions etc. So if you need these type of operations, I think you are better of with using Geography. I can't say whether it is slower, but doing a distance/area calculation in spheric coordinates takes a few more operations than using basic euclidean formulas. I wouldn't know with the spatial index, but it's been designed for use with geographic datatypes, so I doubt that it would be much different.

    Also note that Geography has fewer spatial operations available.

     

    Another thing you could do is have both a geometry and a geography row in your table, and take the best from each (comparing performance should also be pretty straight forward then)

    Sunday, February 24, 2008 7:48 PM
    Answerer
  • Thanks very much for taking the time to write a detailed answer. I realise now that I didn't phrase my first question very well and so, whilst your answer was a totally appropriate response to what I wrote, it's not quite what I meant!

    All of the example code for the geometry datatype I have seen so far (e.g. any of the static geometry methods at http://msdn2.microsoft.com/en-us/library/bb933894(SQL.100).aspx) have used an SRID of zero, so I had (wrongly)
    assumed that the geometry datatype actually didn't account for spatial references (since it does not need it in order to calculate the ellipsoidal model). As such, I couldn't understand why the geometry datatype couldn't simply be a special case of the geography model, using SRID 0.
    I now see that geometry does support SRIDs, but not enforce them, so that answers my question.

    As for performance testing of geography -v- geometry, I'll set up some tests when I get some free time and post the results back here if anybody's interested.
    Sunday, February 24, 2008 11:01 PM
    Answerer
  • The big difference here is spherical geometry vs. planar geometry. The math behind the two are completely different, and one can never be a special case of the other. I recently wrote a blogpost that partially covers some of these aspects:

    http://www.sharpgis.net/post/2008/01/12/Straight-lines-on-a-sphere.aspx

     

    The SRID is not really enforced on geometry (or used for anything, except that they have to match for most of the spatial operations), but its a good idea to remember to use it anyway. There might very well soon be 3rd party clients out there that will make use of it, and it's also a good idea to keep a unit on your values. You can say that the Spatial Reference ID is to geometry what for instance 'meter' is to distance. Without a unit, the values doesn't make any sense.

     

    I also like to put a SRID constraint on my table to ensure that all geometries in the table has the same SRID. You can do that using:

    ALTER TABLE [tablename] ADD CONSTRAINT [enforce_srid_geometrycolumn] CHECK (geometrycolumn.STSrid = 4326);

     

    Btw. most samples I've seen use -1 for unknown ID (not 0)

    Sunday, February 24, 2008 11:19 PM
    Answerer
  • Hi,

     

    I just thought I'd touch on the perf issue briefly.  The way this is coded---I'll have to blog on this at some point---there will be a small performance hit for geography over geometry, but I would be very surprised if it is large for any non-metric geometry operation.  Metrics---areas/lengths/distances---will probably have a larger hit.  Anything that doesn't really do any gometric calculation---STNumPoints, e.g.---should show approximately zero difference.

     

    Cheers,

    -Isaac

    Monday, February 25, 2008 1:34 AM
  • Thanks - thinking of the SRID as the way of defining the units in the geometry type is helpful - since I couldn't really see why it was needed otherwise for planar operations. Nice code snippet for enforcing specific SRIDs in a column too.

     

    Sorry if these seem like simple questions. I'm an experienced T-SQL developer, but will admit I only have a limited exposure to some of the fundamental issues involved in using spatial data.... but am very keen to do more. As such, I'd say I'm pretty much exactly the sort of person for whom the new spatial support in SQL2008 is intended!

     

    Thursday, February 28, 2008 9:49 AM
    Answerer
  • This is exactly why I'm so exited about the spatial support in sql server. Now we finally get all this spatial stuff much more exposed to "real" developers and not just us spatial geeks.
    Friday, April 25, 2008 5:08 PM
    Answerer