Grouping functionality

sounded like same issue but original poster didnt state what the error was so hard to tell.. anyway, when i do Views grouping on openlayers items i get this error on the map page itself:

Fatal error: Call to a member function geometryType() on a non-object in /home/admin/public_html/habiter/sites/all/libraries/geoPHP/geoPHP.inc on line 177

and i am also getting lots of these elsewhere on site:

Warning: trim() expects parameter 1 to be string, array given in WKT->read() (line 16 of /home/admin/public_html/habiter/sites/all/libraries/geoPHP/lib/adapters/WKT.class.php).

patch abovedoes not fix the issue.

my post was re: rel 1.7; i just updated to latest -dev and when i ran update.php (even though there were none) it seems to have fixed the trim error.

the geometryType() on a non-object fatal error remains. i'll debug and see if i can track it down.

ok, i screwed up and patched the geophp that came with the module as opposed to the one that is actually used which is in libraries.. ughh... good way to confuse things.

anyway, now with the patch on the latest -dev geoPHP and then moved to the libraries folder; i no longer have errors. but i also do not have grouping working and it seems to have busted clustering from working correctly.

but possibly there are different goals here. this is what i have and what i am trying to get.

i have 2 categories of map items (25 of A, 37 of B) and i use clustering. before setting to group on category i have small clusters correctly positioned about my map: clusters of anywhere from 2 to 6 items. and they list items of type A or B ungrouped.

with updates here and enabling grouping on category i now have to big clusters, one that lists 25 A items and the other cluster which lists 37 B items.

not sure if that was intent of this patch; but this is not the correct functionality. i assume the common use case would be to have the small clusters as i had before; but with grouped items in each cluster.