[postgis-devel] Oracle SDO_GEOMETRY vs PostGIS WKT

Jorge Arévalo jorge.arevalo at deimos-space.com
Wed Aug 25 03:29:50 PDT 2010


Hello,

On Wed, Aug 25, 2010 at 12:47 AM, Paul Ramsey <pramsey at opengeo.org> wrote:
> First, be careful to not mistake internal representation for external
> serialization. People ask "do you store geometries in OGC format", to
> which I answer "why do you care?" (the answer is, of course "sort of"
> (until 2.0, when the answer will be "less so"), but is still
> irrelevant to end users).
>

Yes, sorry. My mistake. I was talking about what I can retrieve from
database using a query. That format. Not the way the bytes are stored.
I don't care about that.


> Now, regarding the text serialization of SDO_GEOMETRY (a) it predates
> the OGC SFSQL specification and (b) it includes some extra information
> like curve interpolation types that are not representable in WKT. So
> it's not a completely arbitrary ignoring of OGC standards.
>

Ok. So, they simply go beyond the standard, and doesn't seem very
concerned about them.


> That said, it took Oracle a very very long time to provide utility
> methods for creating geometries from WKT and writing them out as WKT,
> so I wouldn't count Oracle as a particularly fervent follower of the
> standards base.
>

Yep, like other companies developing propietary software. The point is
I don't understand why using a mix of numbers and arrays whose
elements index tables to simply represent a polygon. Saving storage
space? I don't know. The PostGIS way, closer to OGC standard, is much
easier, IMHO.


> The standards are a good starting point, in my opinion. Certainly they
> give you an open door into PostGIS, DB2, SQLServer and ESRI's new SQL
> support. The mappings from the standards SQL into Oracle spatial SQL
> are murky but doable, which is testament to the fact that Oracle must
> at least give a sidelong glance at the standards from time to time.
> You find things like the DE9IM model in Oracle, and the semantics of
> valid polygons match the OGC scheme, so that's all good.
>

Thanks for the info. The more I know, the more things I realize I don't know :-)

Best regards,
Jorge


> 2010/8/24 Jorge Arévalo <jorge.arevalo at deimos-space.com>:
>> Hello,
>>
>> I'm studying Oracle SDO_GEOMETRY type [1], and I find it really
>> tangled. But, AFAIK, the SFS standard [2] ST_Geometry is implemented
>> too, provided by ESRI [3]. And even a third ST_Geometry object,
>> provided by Oracle and basically equal to SDO_GEOMETRY type, is
>> available [4].
>>
>> On the other hand, and please correct me if I'm wrong, PostGIS simply
>> implements the standard ST_Geometry type. I'm reading the SFS
>> documents [2], and the PostGIS documentation [5], and I find it
>> simpler to specify if the geometry is compound or not, if it has
>> holes... this is: the geometry's properties.
>>
>> So, my questions, as a beginner, are:
>> - Why does Oracle use a tangled format like SDO_GEOMETRY, if they
>> could simply implement the easier standard? Any obvious reason I'm
>> missing? Apart from "we are a private company and define our own
>> formats".
>> - If I want to really understand spatial formats used in Oracle
>> Spatial, PostGIS... are the [2] standards the best source? I think
>> they are THE source... Am I right?
>>
>> Thanks in advance, and best regards
>>
>> --
>> Jorge Arévalo
>> http://gis4free.wordpress.com
>>
>> [1] http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28400/sdo_objrelschema.htm#i1004087
>> [2] http://www.opengeospatial.org/standards/sfs
>> [3] http://webhelp.esri.com/arcgisdesktop/9.3/index.cfm?id=2709&pid=2704&topicname=The_ST_Geometry_storage_type
>> [4] http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28400/sdo_sql_mm.htm#CHDJHAFA
>> [5] http://postgis.refractions.net/docs/ch04.html
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>



-- 
Jorge Arévalo
DEIMOS Space
Internet & Mobilty Division
Ronda de Poniente 19. Edificio Fiteni VI, portal 2, 2º
28760 Tres Cantos (Madrid)
Tel: +34 91 806 34 50 - ext: 155
jorge.arevalo at deimos-space.com
http://gis4free.wordpress.com



More information about the postgis-devel mailing list