SDO_UTIL.EXTRACT fail when single item in geometry collection

Question

Hi folks,
Didn't we have a discussion a while back on whether geometry collections are valid when they only contain a single item? Darned if I can find it with the OTN search function. I think back then the issue was either a multipolygon or multistring with a single item.
Anyhow this time around I have a 2004 geometry collection that for no particular reason happens to only contain a single point. This collection geometry with one item validates TRUE. Just like with multipolygons and multistrings when I attempt to EXTRACT the result I just get back the input geometry (the 2004 in this case) rather than the component part (the 2001). I think this is because there is a test in the EXTRACT routine that checks if there is but one element and if so then returns the original input assuming the original input was gtype 1,2 or 3. Unlike a multipolygon or multistring where I can just assume the output is a polygon or string respectively, with a geometry collection I am rather stumped to figure it out short of inspecting the SDO_ELEM_INFO array. At that point I am kind of writing my own EXTRACT function. I guess I have to do that.
Anyhow, this would lead one to believe that a geometry collection with only one element is not really valid for Oracle Spatial. Or is this a bug in SDO_UTIL.EXTRACT? I have no recollection if that previous conversation ever decided this question. I might humbly suggest that either SDO_UTIL.EXTRACT should successfully unpack the single item or SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT should report an error for this type of collection.
I looked over metalink and cannot find anything logged on the issue. The results are the same on 10gR2 and 11gR2.
If anyone remembers the previous discussion please post the link.
Cheers,
Paul
SELECT
SDO_UTIL.EXTRACT(
   SDO_GEOMETRY(
      2004,
      8265,
      NULL,
      SDO_ELEM_INFO_ARRAY(
         1,
         1,
         1
      SDO_ORDINATE_ARRAY(
         -100.515216953125005261426849756389856339,
         39.98440002562352191262107226066291332245
   1
FROM
dual

Answer 1

Ok,
Let's make a quick distinction between the SDO_GTYPE (all four digits) and the lower-case "gtype" meaning the last digit - e.g. the "type of geometry" per the Oracle Spatial book.
I submitted the above SDO_UTIL.EXTRACT issue to Oracle support yesterday and as I rather expected the response was that this is "expected behavior". The analyst noted that my what I called a collection per its gtype was not a collection but a point. He made the distinction between the gtype and the "geometry definition". I assume by that he means the elem_info_array. So in fact djonio (user 633187) back in November 2009 under Matt's thread had the best answer. I don't see anyway to credit him. :) Hey djonio if you post a response I will give this answer to you.
So the gtype is in truth a kind of convenience marker or fancy hat "hinting" at the contents of the geometry object, but by no means defining it. A point wearing a 2004 hat is still a point and a valid Oracle Spatial point at that. If you want to "really" know what a geometry is you need to unpack and inspect the elem_info_array. So those of us writing code which is only inspecting the gtype are going down the wrong road particularly when our data might be of suspect quality. As djonio says the gtype is a performance shortcut. In my defense I think lots of folks (e.g. certain software from California) work off the gtype alone. So its not like we can just set the gtypes all to be "9999" and say the heck with it all. :) So incorrect gtypes are bad as they hose the performance shortcut that the gtype allows (and certain software demands) but a bad gtype is NOT an invalid geometry. I am not sure I am entirely sold on that idea as VALIDATE_GEOMETRY certainly looks at the gtype when doing its evaluation. Alas, I suppose its all shades of gray here as validate geometry is just responding to my gtype "hint" to give me the best feedback on my input. Perhaps there is a distinction between "good", "bad" and "imprecise" gtypes.
My next question is if the gtype system is just a fancy hat, then how best to catalog basic geometry types? Both multi-points and point clouds share gtype 5 but the elem_info marks them as being unique data types that really require unique handling (I never use point clouds so feel free to argue that point). So rather than just mumbling "5" over and over to myself, what vocabulary might be used? Is it GML time? Hmm, does GML even have a point cloud datatype? I suppose I just make something up? Does anyone else have a system they are using?
Thanks for reading this rambling, feel free to shoot down everything I say. I clearly need more coffee this morning.
Paul