Opinions? Do you let 2003s camp out in spacious 2007s?

Question

Hi Everyone,
Just out of curiosity, am I the only one late to the game in discovering that the definition of sdo_gtype 2007 allows single polygons, what I would call a "2003" to validly live inside a geometry defined as sdo_gtype 2007? When you see a gtype of 2007 in a geometry do you absolutely expect a multipolyon, or does your shop follow the documentation:
"Geometry can have multiple, disjoint polygons (more than one exterior boundary). (MULTIPOLYGON is a superset of POLYGON.) "
http://download.oracle.com/docs/html/B14255_01/sdo_objrelschema.htm#sthref208
That word "can" in the documentation is a sticky one. Looks like this guy has been wondering about this since (the year) 2003 , but I don't see any other discussion:
See: shp2sdo multipolygons
It's not a big deal to switch all sdo_gtype code to sdo_util.getnumelem when this sort of thing matters. Like I said, just curious if anyone enforces internal standards that are a little more strict than the documentation.
Thanks in advance for your opinions,
Matt

Answer 1

A pig is a pig, a herd is a herd. If your data model says the business object is a single polygon then make it so. If it can be both, then use both forms as the entity being modelled is written to the database.
A single polygon (with holes) is 2003, a multi-part polygon (with holes) is 2007.
If you put singles into 2007 then the front end client will probably have to do a bit more work in unpacking the polygon(s) that is doesn't have to do for 2003.
I have seen, in PostGIS, a column defined as multipolygon into which has been written 100% multipolygons all composing a single part! But that's because PostGIS doesn't implement the SQL/MM, OGC standard incorrectly because of the way it writes metadata to the GEOMETRY_COLUMNS table.
The standard says that, for the GEOMETRY_TYPE column, the “use of a non-leaf Geometry class name from the Geometry Object Model for a geometry column
implies that domain of the column corresponds to instances of the class and all of its subclasses” [OGC 06-104r3, 7.1.3.3 Field description, Page 29]
regards
Simon