I'm completely new to this awesome module and have been having some teething problems. I'm using the latest 7.x-2.x branch from git along with other modules (as per http://tinyurl.com/cj5c2c9 ) - This includes ol_locator and geofield modules.

When I create a content type with a geofield in it and set the display of that field to OpenLayers I get a blank panel with the settings icon in the top right corner. If I choose edit I get the error "Exception: Projection 900913 requested but not supported in openlayers_get_projection_by_identifier() (line 967 of /var/www/drupal7/htdocs/sites/default/modules/contrib/openlayers/openlayers.module).)
I then discovered that I got the same error by clicking the 'edit' option against any of the maps under admin/structure/openlayers/maps

I took a backtrace at that point and saw that getProjections() was calling openlayers_get_projection_by_identifier($projection);
Dumping out '$this' inside the getProjections() functions I spotted that the first requested layer ( openlayers_layer_type_google ) had a projection of 'EPSG:4326' and succeeded while the next one ( openlayers_layer_type_raw / name: geofield_formatter ) just had a projection of '900913' .

Once I'd overridden the geofield_formater under the layers menu, so that it used projection == 'EPSG:900913' , I could then use the edit link on all maps under admin/structure/openlayers/maps - However I still got the same blank panel for my content and the same error when attempting to edit it.

I've looked through my various modules and I found that openlayers/docs/RAW_LAYERS.txt includes examples where projection is set to just '900913'. Both geofields and ol_locator have such definitions in them:
./openlayers/docs/RAW_LAYERS.txt: 'projection' => array('900913'),
./ol_locator/ol_locator.openlayers_maps.inc:80: 'projection' => '900913',
./ol_locator/ol_locator.openlayers_maps.inc:164: 'projection' => '900913',
./geofield/geofield.openlayers.inc:80: 'projection' => '900913',
./geofield/geofield.openlayers.inc:156: 'projection' => '900913',
./geofield/geofield.openlayers.inc:203: 'projection' => array('900913'),

As the above modules appear to be based on an example from the openlayers module (perhaps outdated, but the API version appears to still be 1) - I'm wondering if there are other modules out there which will break for similar reasons.

I know absolutely nothing about Projections, in fact I only learnt what they were when researching the bug, but given that all the many default projections in openlayers have 'EPSG' as the projection authority, I wonder if perhaps it is safe to assume that if the authority isn't explicitly set, then it should default to 'EPSG' ??
I've added a one-liner to this which sets the authority to EPSG if the projection is purely numeric and I'll attach a patch to this bug shortly.

I've still got a completely blank panel for a map on my 'Location' content with a geofield (Setting the display to 'Geofield Map' gives me a correct google maps display).

CommentFileSizeAuthor
#9 openlayers-projection_900913_exception-1943968-9.patch615 bytesandrewmacpherson
#1 openlayers-projection_900913_exception-1943968-1.patch596 bytesOvation1357
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Ovation1357’s picture

Ovation1357 CreditAttribution: Ovation1357 commented
FileSize
openlayers-projection_900913_exception-1943968-1.patch596 bytes

This patch prepends 'EPSG:' to any projections passed into openlayers_get_projection_by_identifier() where the projection id is purely numeric.

Pol’s picture

Pol
the/that
Location Brussels
CreditAttribution: Pol commented

Hello Ovation,

We are aware that this patch will fix most of the problem.

Augustus and me are currently busy working on providing good code and cleaning old stuff from the module.

Adding such code will fix the problem but will add 'crufts' into our code, and will not force other developers to update their module.
That's not what we want.
Of course, that's my point of view, maybe Augustus think something else, we'll see in the thread.

We want developpers to update their module to get them working with the latest version of OpenLayers.
We will probably release a new beta by the end of March and we know that it will break some site, but it's for a better world later.

Thanks for providing the patch though, I'm sure it will help people in the meantime.

augustus.kling’s picture

augustus.kling CreditAttribution: augustus.kling commented
Status: Active » Needs work

I can agree with Pol in every aspect mentioned and I want to detail a bit further.

We could choose to silently rewrite numeric projections by prepending "EPSG:" but this might shadow other issues (say a third-party simply forgets about the authority code). I want to avoid to rely on assumptions whenever possibly and make the code more reliable instead. This means that modules that depend on the openlayers module need to be updated. I'm convinced to have more reliable code in the long run this way – meanwhile you should use more stable releases instead of the development builds in case you want to avoid trouble.

The update script migrates layers that are saved in the database already in the same way you are doing in your patch. However I think we can require users to add the authority code to the modules of their choice if they are keen enough to run on development builds.

You've well spotted that the example in RAW_LAYERS.txt is wrong and I will amend it. The exception could use more hints, too.

In my option the following aspects are desirable:

  • Avoid if clauses as they introduce complexity.
  • Fail as early as possible with a exception. This makes it relatively easy to track down the root cause of an issue by making a stack trace available.
  • Use a wording in such exceptions that allows the ordinary user to fix the problem or at least submit a bug report that is precise enough for developers to give pointed hints.

Thanks a lot for taking the time to write a detailed report. I'm sorry I'm unable to help with the geofield module.

augustus.kling’s picture

augustus.kling CreditAttribution: augustus.kling commented
Status: Needs work » Closed (works as designed)

You've well spotted that the example in RAW_LAYERS.txt is wrong and I will amend it. The exception could use more hints, too.

Fixed in 6d2091b566076b4c19e8ddcffa02729c84afce78.

Ovation1357’s picture

Ovation1357 CreditAttribution: Ovation1357 commented

Thank you both for your prompt updates. I completely accept your point of view about requiring 3rd party modules to update in order to work with the latest OpenLayers. Hopefully the information I've put in this bug, combined with the changes you've committed to RAW_LAYERS.txt will help highlight this, but if I get time I'll also raise issues against the two modules I named above.

It's a pity that Drupal doesn't have more stringent module versioning as perhaps it might then be able to auto-disable incompatible modules (or refuse an upgrade that will introduce incompatibility)...

Anyway - for the moment I've gone back to the released versions of this little cluster of modules as I ultimately want to use these features in a production site where anonymous users can search for registered users within a proximity of a UK Postcode... Wish me luck :-D

kingfisher64’s picture

kingfisher64 CreditAttribution: kingfisher64 commented

@Ovation1357 is there anyway to get your patch working with openlayers beta5?

I'm aware your patch was against dev openlayers, i'd really like to use the http://drupal.org/project/ol_locator feature

patching file openlayers.module
Hunk #1 FAILED at 960.
1 out of 1 hunk FAILED -- saving rejects to file openlayers.module.rej

Unless there is a better solution now available

Many thanks :)

Ovation1357’s picture

Ovation1357 CreditAttribution: Ovation1357 commented

Hi @Kingfisher64,
I'm afraid that I'm not really using the OpenLayers module at the moment - After trying loads of solutions I discovered that I could do everything I needed just using the latest version of GeoField (I only need proximity based on UK postcode for search purposes - no maps at the moment)....

The patch I made makes an incredibly simple change so you should be able to find a similar point in your version of OpenLayers an inject the one line change there. Just search the openlayers.module file for a function called 'openlayers_get_projection_by_identifier' and if you successfully locate that function then insert the following line at the beginning of it (not including the php tags!!):
if (is_numeric($identifier)) { $identifier = "EPSG:".$identifier; }

The authors of this module have concluded that we shouldn't really be hard-coding an assumption into this module and that the 3rd party modules which might specify a projection as just a number, should be updated to make sure they they also specify an 'Authority' too.

Hope this helps

kingfisher64’s picture

kingfisher64 CreditAttribution: kingfisher64 commented

Thank you for taking the time to respond, that's kind of you. :)

That sounds a very similar use case to me. I'm looking to return places of interest (registered businesses via profile2) in the form of a simple html list when a user types in a postcode. I was trying the ol_locator feature as a test to see if the client preferred with or without the map.

Many thanks again.

andrewmacpherson’s picture

andrewmacpherson CreditAttribution: andrewmacpherson commented
FileSize
openlayers-projection_900913_exception-1943968-9.patch615 bytes

Patch in comment 1 no longer applies cleanly. This is just a re-roll against the latest dev release. (7.x-2.0-beta7+44-dev, 2014-02-27).

No review needed, works-as-designed status of the issue is fine. I'm just uploading it here because I'm using this fix on a project, and this is a convenient way to keep track of it.

  • augustus.kling committed 6d2091b on 7.x-3.1.x 
    Update example code
Provide more pointed exception message
bug #1943968