Moving from: http://drupal.org/node/609092#comment-2659126

I too am also still experiencing this issue.
I'm using the 6.x-1.x-dev (Feb 19th) version with the OpenLayers source: http://openlayers.org/api/OpenLayers.js

I've attached a screenshot of this issue with the error message showing (my site with this issue is: http://brat.info)
The map itself doesn't show, but takes up the right amount of the screen (width & height), and the controls show but not properly.

Tested in IE8 (with and without compatibility mode) (screenshot is from IE8 without compatibility mode):
http://drupal.org/files/issues/openlayers_ie8.png

CommentFileSizeAuthor
#4 Map_array.txt75.55 KBAnonymous (not verified)

Comments

zzolo’s picture

The geometry that this error is saying is undefined is part of the feature object that OpenLayers provides. So, either you are not actually using the right library or somehow your map array is off. Can you post your map array that provides this error?

Anonymous’s picture

What do you mean by 'map array'? My maps get their data from Views and as far as I know the only customisations I've made to the maps have been changing the marker icons from the orange circles to taxonomy images...

zzolo’s picture

The map array is the array that creates the map. You can use the debugging options in the Settings page to output the map array before and after rendering.

Also, if you are doing some variable styling, please provide any of that code.

Anonymous’s picture

StatusFileSize
new75.55 KB

I've attached the map array (from the 'post render' option) and my custom styling is below.

<?php
/**
 * Assign custom map icons to markers
 */
function brat_custom_assign_map_icons($feature) {
  $files_directory = url(file_directory_path() .'/'. variable_get('taxonomy_image_path', 'map_icons') .'/', array('absolute' => TRUE));
  $styles = brat_custom_set_default_styles();

  switch ($feature->node_type) {
    case 'airport':
    case 'accommodation':
    case 'activity':
    case 'tour':
    case 'vehicle_hire':
      $image = taxonomy_image_get_object($feature->term_image_tid);
      $styles['externalGraphic'] = $image->url;
    break;
    case 'city':
      $styles['externalGraphic'] = $files_directory .'bigcity.png';
    break;
    case 'country':
      $styles['externalGraphic'] = $files_directory .'world.png';
    break;
    case 'internet_cafe':
      $styles['externalGraphic'] = $files_directory .'workoffice.png';
    break;
  }

  return $styles;
}

/**
 * Set default marker styles
 */
function brat_custom_set_default_styles() {
  $styles = array();

  $styles['cursor'] = 'pointer';
  $styles['graphicWidth'] = 32;
  $styles['graphicHeight'] = 37;
  $styles['graphicOpacity'] = 1;
  $styles['graphicXOffset'] = -16;
  $styles['graphicYOffset'] = -34;

  return $styles;
}
?>
Anonymous’s picture

Any luck deciphering this?

floretan’s picture

I've had this bug too. The error actually refers to line 133 of openlayers.layers.js :

newFeature.geometry.transform(featureProjection,mapProjection);

What happens is that when IE iterates over newFeatureSet, it counts the function indexOf() as an array element, and the code tries to treat that function as a feature, which gives the error above about 'geometry' being invalid (because of course indexOf.geometry doesn't make any sense).

I was able to resolve the problem by wrapping the body of the loop with a check for the type of newFeatureSet[i] like this:

// Go through new features
for (var i in newFeatureSet) {
  if (typeof(newFeatureSet[i]) == 'object') {
  ...

This solves this specific issue, but now I'm running into other errors that are actually located inside of the openlayers library... so I can't close my Windows virtual box yet. I'll post a proper patch when I've got something working.

Credit: I wouldn't have made it so far without firebug lite: http://getfirebug.com/firebuglite

floretan’s picture

I finally tracked this issue down to a conflict with the ShadowBox plugin (it was adding the "indexOf" function to all arrays), but combined with other issues (xmlns prefix, etc) it made it hard to debug.

tmcw’s picture

Category: support » bug

That's kind of weak, especially when it's clear that they didn't read the jQuery docs. Anyway, I've found it's a better idea to use the full for(var i = blah; i < blah; i++) in Javascript - the other notation does better with string indexes, but has problems with methods, like this, and is usually slower by about 5 times.

zzolo’s picture

Status: Active » Closed (fixed)

Maybe I am missing something, but this sounds like it is resolved and was actually a problem caused by another module. Closing for now.