Hi again, sorry for the long wait. I have been working on some slightly easier tasks for the time being, but have now returned to this :) So, i'm still having issues where when querying the data from the #ask parser is not showing any data (empty table cell). Please take a look at the polygons branch on SMW and SM if you have the time. But anyways, back to the response i recieved from you.
Did you register your new datatype (DV class) to use containers? This is done in the hook smwInitDatatypes; see SMW_DatavalueFactory for docuemntation (it's similar to the property registration, using registerDatatype and registerDatatypeAlias). Without this, SMW won't know that you need a container and it will just give you the subobject (wikipage DI) when retireving data from the store; this would then be rejected by your DV, and no values would be created.

Yes i believe i have so, i have registered the datavalue through calling:
SMWDataValueFactory::registerDatatype( '_gpo', 'SMGeoPolygonValue', SMWDataItem::TYPE_GEOPOL ); 

in the SemanticMaps extension which is in a method that is called on the smwInitDatatypes hook. 

In the SemanticMediaWiki extension i have registered through adding:

'_gpo'  => SMWDataItem::TYPE_GEOPOL, // Geographical polygon

to the self::$mTypeDataItemIds array in the function initDataTpes in SMWDataValueFactory.

Is there anyway i can verify if i have registered this datavalue properly? for example adding a breakpoint to a method that SMW would call in the datavalue?

Now for the first issue (which may not be your problem yet, but will probably come up later). Container-type data values need to be queried differently. Every datavalue has its own code for deciding what to query when a user enters some string in #ask. This is implemented in the SMWDataValue's method getQueryDescription(). The default handling is to interpret initial comparators (<, >, ...) first, and then parse the rest like a user input. The result is used for querying. This does not work for containers, since, IIRC, SMW does not currently support the use of container DIs in queries (i.e., in the PHP level description of queries). I might be wrong here.

So far i have just added a stub method getQueryDescription in the datavalue class, however it's not being called (yet), however i'm guessing that is because of my issue above.

The pedestrian solution for now is to implement something like in SMW_DV_Record.php. The code there has two modes during parsing: either construct a DIContainer or construct a query description. This is actually needed there because Records also support comparators (<, >, ...) for *each* of their component values in queries; so the parsing is sightly different (it must allow comparators in front of each value, not just at the very beginning). If this is not desired, then one could also have the same parsing and just turn the container into a query (this might already have code somewhere; not sure). The only thing to do differently would be to use an anonymous subject for the Container in this case -- otherwise the query will search for exactly the subject name that you have given, which is not correct.

I will have to get back to you on this one when i get that far.

This thread is getting into the most comprehensive documentation of SMW internals ever written ;-)