locked
Combining geometry and geography datatype RRS feed

  • Question

  • I have with interest read Isaacs last blog entry about data types.

    What will be the effect if you use both datatypes in combination. E.g try to combine them (union) calculate the difference etc.?
    Wednesday, October 31, 2007 4:09 PM

Answers

  • Hi Anders,

     

    No, you can't really combine them in a meaningful way.  We don't natively support conversion between two different coordinate systems, so we can't make sense of such heterogeneous instances.  We do have partners, e.g. Safe Software, who have tools that do this kind of transformation, but these are largely targetted at ETL situations.  We are looking at what it would take to provide some basic transformation support in the future.

     

    Cheers,
    -Isaac

    Thursday, November 1, 2007 6:30 PM


  • Manifold can do this, since it can convert between different coordinate systems on the fly. For that matter, it can even convert different geometry types on the fly, and Manifold even supports using different geometry types using different coordinate systems within the same spatial DBMS simultaneously. 

    Given confidentiality obligations, I cannot use SQL Server 2008 spatial for a specific example, but I can use other spatial DBMS products for an example.  Manifold also works with Oracle, IBM DB2 and PostgreSQL spatial DBMS, so let's use those as an illustration:

    Suppose you have a layer of roads that's stored in Oracle using SDO_GEOMETRY (the native Oracle spatial geometry type) and you have a layer of real estate parcels that is stored in IBM DB2/IBM Spatial Extender using GEOMETRY (the native IBM type) and you have yet another layer of overlapping areas representing wetlands that is stored in PostgreSQL/PostGIS stored as OGC WKB geometry type.  Let's say all of the different layers use different coordinate systems with one being in lat/lon (like GEOGRAPHY, from what I read in the published public documents...), one being in some State Plane coordinate system and the last in, say, Mercator, because it was traced in from a Virtual Earth layer (as can be done with Manifold).  Note that these three different spatial DBMS products use three different ways of encoding coordinate systems, use significantly different approaches to encoding geometry within their geometry types and even use different connection technologies.

    In Manifold you can connect to those three different spatial DBMSs simultaneously, pop open dynamic editable windows for all three layers at once and even show all three layers simultaneously in the same map window (which could have yet a different projection in use), and you can do topological analytics or anything else you desire between them.  Use topology overlays to "cookie cut" the roads with parcels or use spatial SQL to select only those portions of roads that fall within the one set of parcels but not within a given distance of wetlands.  Nothing to it.  All the coordinate system conversion and geometry type conversion is done automatically on the fly so it all works right.  It doesn't matter at all that multiple different geometry types and coordinate systems are in use.

    You can even do things like visually select some parcels from the DB2 layer, Cut them and then Paste them into the PostgreSQL layer and all conversions (including attribute data and updating, if necessary, the table structure within the destination layer) will be done automatically for you, on the fly.

    Given that the above works perfectly between different geometry types from different spatial DBMS vendors using different coordinate systems and even different connection technologies, I think anyone familiar with Manifold's comprehensive approach to such things would expect that it would also work just as seamlessly between geometry and geography types in SQL Server 2008 spatial. :-)

    FME is great software, really quality stuff, but it is basically a format translator, not a GIS, and cannot do dynamic spatial analytics like the above.

    Cheers,

    Dimitri



    Thursday, November 1, 2007 8:32 PM

All replies

  • The question is what will happen if you combine a geography wtih a geometry?
    Thursday, November 1, 2007 9:42 AM
  • Hi Anders,

     

    No, you can't really combine them in a meaningful way.  We don't natively support conversion between two different coordinate systems, so we can't make sense of such heterogeneous instances.  We do have partners, e.g. Safe Software, who have tools that do this kind of transformation, but these are largely targetted at ETL situations.  We are looking at what it would take to provide some basic transformation support in the future.

     

    Cheers,
    -Isaac

    Thursday, November 1, 2007 6:30 PM


  • Manifold can do this, since it can convert between different coordinate systems on the fly. For that matter, it can even convert different geometry types on the fly, and Manifold even supports using different geometry types using different coordinate systems within the same spatial DBMS simultaneously. 

    Given confidentiality obligations, I cannot use SQL Server 2008 spatial for a specific example, but I can use other spatial DBMS products for an example.  Manifold also works with Oracle, IBM DB2 and PostgreSQL spatial DBMS, so let's use those as an illustration:

    Suppose you have a layer of roads that's stored in Oracle using SDO_GEOMETRY (the native Oracle spatial geometry type) and you have a layer of real estate parcels that is stored in IBM DB2/IBM Spatial Extender using GEOMETRY (the native IBM type) and you have yet another layer of overlapping areas representing wetlands that is stored in PostgreSQL/PostGIS stored as OGC WKB geometry type.  Let's say all of the different layers use different coordinate systems with one being in lat/lon (like GEOGRAPHY, from what I read in the published public documents...), one being in some State Plane coordinate system and the last in, say, Mercator, because it was traced in from a Virtual Earth layer (as can be done with Manifold).  Note that these three different spatial DBMS products use three different ways of encoding coordinate systems, use significantly different approaches to encoding geometry within their geometry types and even use different connection technologies.

    In Manifold you can connect to those three different spatial DBMSs simultaneously, pop open dynamic editable windows for all three layers at once and even show all three layers simultaneously in the same map window (which could have yet a different projection in use), and you can do topological analytics or anything else you desire between them.  Use topology overlays to "cookie cut" the roads with parcels or use spatial SQL to select only those portions of roads that fall within the one set of parcels but not within a given distance of wetlands.  Nothing to it.  All the coordinate system conversion and geometry type conversion is done automatically on the fly so it all works right.  It doesn't matter at all that multiple different geometry types and coordinate systems are in use.

    You can even do things like visually select some parcels from the DB2 layer, Cut them and then Paste them into the PostgreSQL layer and all conversions (including attribute data and updating, if necessary, the table structure within the destination layer) will be done automatically for you, on the fly.

    Given that the above works perfectly between different geometry types from different spatial DBMS vendors using different coordinate systems and even different connection technologies, I think anyone familiar with Manifold's comprehensive approach to such things would expect that it would also work just as seamlessly between geometry and geography types in SQL Server 2008 spatial. :-)

    FME is great software, really quality stuff, but it is basically a format translator, not a GIS, and cannot do dynamic spatial analytics like the above.

    Cheers,

    Dimitri



    Thursday, November 1, 2007 8:32 PM

  • Correcting an error... in "stored in IBM DB2/IBM Spatial Extender using GEOMETRY (the native IBM type)" that should be ST_GEOMETRY, which is the name IBM uses for their native geometry type.  Sorry about that!
    Monday, November 5, 2007 11:14 PM