PostGIS Classname "Wkt" conflicts with geoPHP class name "WKT"

We should really be using namespaces... Both projects are at fault for not doing so... I will be adding namespaces into a geoPHP 2.0 release sometime down the road.

Having said that, I would politely ask that the postGIS folks change their class name. The reason for this is that geoPHP is a library that is depended on downstream by many more folks (and not just in Drupal!) than the postGIS module. Changing the class name in geoPHP could have a lot of knock-on effects for a lot of people (it's an API breaking change), whereas I think this should be a fairly painless change for the postGIS module.

I agree that namespaces will be the solution. However with Drupal 7 and the underlying PHP 5.2.4 true namespaces are not supported. All we could do for now is adding a prefix to the class names. We do not really like this solution since it makes the code more difficult to read.

On the other hand we do not want to block a change into this direction if it is worth the effort.

Currently however we do not see why one would need geoPHP and the PostGIS module in parallel. Both have very similar functions, the main difference being that geoPHP does all geometry handling within PHP while the PostGIS module delegates it to the database. If you can describe a relevant use case when both libraries are needed we may decide to rename the classes in the PostGIS module.

I'm probably missing something (and maybe this should be its own issue), but I was using OpenLayers Views to render maps (which in turn requires geoPHP)? In reading the Cartaro documentation (here: http://drupal.org/node/1719078), the last part of on displaying a "Feature Collection" just says to add the GeoServer layer onto your OpenLayers map, but it doesn't say how to show that map in Drupal. Cartaro Frontmap theme includes a setting for an OpenLayers map, but if one isn't using this theme, what is the standard way of displaying/rendering a map in Cartaro if it isn't OpenLayers Views?

do not see why one would need geoPHP and the PostGIS module in parallel

In order to display postgis layers via OpenLayers module, this namespace conflict needs to be resolved since the OpenLayers module requires geoPHP. I think this is a pretty relevant use case.

Please advise,
r.b.

geoPHP is not a dependency of the openlayers module but only of the openlayers_views module. The openlayers module can actually be used without having geoPHP available.
For example the Cartaro demo does not use geoPHP but instead uses JavaScript (clustering) and SQL (filtering). SQL can be used for complex geometric calculations, too, but the demo does not currently show this.

When thinking about openlayers_views one should discuss why geoPHP is needed there at all. As far as I can see it only concatenates WKT (is this correct?).

This does not affect class naming though, so if anyone really needs to use postgis and geoPHP together we would integrate a patch to prefix the class name Wkt.

You can give this untested patch a try. If you use it please report back and explain your use case.

You can use the OpenLayers filter module and blocks to display a map anywhere in Cartaro.

Patch has been committed: http://drupalcode.org/project/postgis.git/commit/3f1e6d2

thanks @augustus.kling and @friedjoff

My use case is fairly simple, and I think perhaps a common one. I use openlayers, I also use views, and my backend is postgreSQL, and thus use postgis for geometry storage. Since openlayers_views requires geoPHP, well, I do too then by definition.

You raise an interesting point about openlayers_views and whether it needs geoPHP - I do not know how critical its useage. However, I would imagine that if your database storage solution did NOT use postgis that it would be necessary to have something that was capable of dealing with WKT - at the very least, the Feeds import module uses either GML or WKT as its means of moving data into the db from a feed (of course, since I only use postGIS, this might not be strictly true with other solutions - feeds import may use postgis for this?), thus the feeds import module would require a solution for a non-postgis install.

HTH,
r.b.