Attached is an initial attempt at getting Openlayers support back into Geo. The first attachment (geo_openlayers.patch), adds some modifications to geo that I needed to make in order to get geo_field working without locking up. The second is a standalone module (geo_openlayers), which contains a standalone module that provides an openlayers v2 widget to geo.

This is very much a work in progress and only marginally works on my dev environment, but I wanted to get some code out today to start some discussion/collaboration on getting this done.

CommentFileSizeAuthor
#11 geo-openlayers_v2-804878-11.patch748 bytesagileware
#5 geo_openlayers-0.0.1.tgz3.04 KBstrk
#1 geo_openlayers.patch3.88 KBBrandonian
#1 geo_openlayers.zip6.43 KBBrandonian

Comments

Brandonian’s picture

Brandonian commented
StatusFileSize
new geo_openlayers.zip6.43 KB
new geo_openlayers.patch3.88 KB

This time, with attachments... ;-)

strk’s picture

strk commented

Looks like the patch addresses http://drupal.org/node/820000, is that correct ?
I'll test in the afternoon

strk’s picture

strk commented

Yeah, confirmed ! (earlier :P)

strk’s picture

strk commented

The widget module doesn't correctly update the text input.
Is there any new version for it ?

strk’s picture

strk commented
StatusFileSize
new geo_openlayers-0.0.1.tgz3.04 KB

geo_openlayers_map_element_process in geo_openlayers.module is referencing the wrong #parents index.
Attached is a version of the geo_openlayers that fixes that problem (which consists in the WKT textarea not being updated while
editing).

Also, this version drops the __MACOSX dirs and CVS dirs.
Does _not_ include the patch, which I belive shoule be dealt with in http://drupal.org/node/820000.
Finally, it drops use of a global variable.

strk’s picture

strk commented

Just a note: the widget module is not complete yet, fails to retain the GEOMETRYCOLLECTION() part in the WKT (looks like)

strk’s picture

strk commented

ok, I see the problem being with support for GEOMETRYCOLLECTION types.
The widget allows you to create collections, but the parser doesn't like them.

I think we want geo_field to allow any geometry type as long as user asks for it, from
generic (collection) to specific (including multi*).

Then the widget should check geo_field configuration and present an interface to only allow
what matches the preference.

kika’s picture

kika commented

subscribe

bpeter’s picture

bpeter commented

subscribing

nicolash’s picture

nicolash commented

subscribe

agileware’s picture

agileware commented
StatusFileSize
new geo-openlayers_v2-804878-11.patch748 bytes

Here is an updated version of the patch in #1.

The difference is that parts related to the issue #820000: PHP Fatal error: Call to undefined method GeoSimple::sqlFieldDefinition() in geo/modules/geo_field/geo_field.module on line 59 have been removed so we are only doing things related to openlayers support.

See #820000-12: PHP Fatal error: Call to undefined method GeoSimple::sqlFieldDefinition() in geo/modules/geo_field/geo_field.module on line 59 for the patch that has the parts that were removed from the patch in #1.

The patch is against CVS HEAD.

imDhaval’s picture

imDhaval commented

love to sub

mbria’s picture

mbria commented

subscribing

Lemontonix’s picture

Lemontonix commented

subscribing