OL is now able to manage projections but OL Views is not using this feature. For example, is not possible to create a data overlay with data stored in a projection different from 4326.

With the attached patch is possible to select the projection of the stored data to create data overlays from data with a projection different from 4326.

EDIT: There is still problem with existing (pre-commit) views with OpenLayers Data Overlay display. If you have this problem, please try patch from #17.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

basvredeling’s picture

Status: Active » Needs review
FileSize
2.5 KB

Yes, this is a problem. EPSG:4326 is hardcoded in the data overlay. I've tested your solution. It works fine.
I've altered your patch to apply cleanly to the latest dev. Also I've changed the variable naming to conform to Drupal coding standards.

This needs testing.

Also, I'd like to suggest that we change the order of the options form so the projection is hidden by default and in an "advanced" fieldset. Just to keep things simple for end users.

Pol’s picture

Good for me !

Is the patch ready to be committed already ?

basvredeling’s picture

If the patch survives testing and someone else can have a second opinion, I'd say it's good to go.

  • Pol committed 7e3678d on 7.x-2.x authored by basvredeling
    Issue #2127071 by basvredeling, azuledu: Added Allow different...
Pol’s picture

Status: Needs review » Fixed

I just changed it a bit.

Thanks !

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

milos.kroulik’s picture

Status: Closed (fixed) » Needs work

Sorry, this patch breaks existing views of many users (see https://www.drupal.org/node/2390989). The patch should be reverted and new one should be created, that will include a DB upgrade code, so that existing views would continue working without problem.

milos.kroulik’s picture

The commit made in response to https://www.drupal.org/node/2378725 should also be reverted, as it seems to depend on this one.

basvredeling’s picture

I agree. Let's make a new patch with db update

milos.kroulik’s picture

FileSize
2.58 KB

Maybe it would be sufficient to add some checks and default values. I think I almost succeeded - the errors mentioned in related issue are gone, the remaining are:

Warning: in_array() expects parameter 2 to be array, string given in in_array() (line 229 of /home/milhaus/devel/pasporty_production_postgis/profiles/cartaro/modules/contrib/openlayers/openlayers.module).
Warning: reset() expects parameter 1 to be array, string given in reset() (line 234 of /home/milhaus/devel/pasporty_production_postgis/profiles/cartaro/modules/contrib/openlayers/openlayers.module)

Please review the attached patch (which based on beta11) and help me to correct my (probably stupid) mistakes. Thanks.

basvredeling’s picture

I only had a quick look. Patch doesn't apply cleanly to 7.x-2.x-dev. I did a manual merge and the extra checks look sound.

Regarding your other errors: perhaps you should return all instances of "EPSG:4329" as array("EPSG:4329").
I had a quick reroll of the patch against 2.x-dev. With said suggestion. Try if it helps.

Pol’s picture

Make sense to me.

milos.kroulik’s picture

Thanks. Unfortunately, #11 still doesn't work for me. All I got is an well-known exception:

Error message
Exception: Projection lacks an authority code. Read http://drupal.org/node/1944074 for hints. in openlayers_get_projection_by_identifier() (line 1066 of /home/milhaus/devel/pasporty_production_postgis/profiles/cartaro/modules/contrib/openlayers/openlayers.module).

openlayers_get_projection_by_identifier() assumes projection as string, so I don't think, that we should return all projections as arrays. Also, this function already creates array from that string:

$records = ctools_export_load_object('openlayers_projections', 'names', array($identifier));

milos.kroulik’s picture

Bump. Can you, please, correct my patch?

basvredeling’s picture

@milos.kroulik Could you export an old view for us to test the changes on? Or give a short description on how to reproduce your errors?

milos.kroulik’s picture

It can be reproduced like this:

  1. Create OpenLayers Data Overlay with OpenLayers 2.0 beta9 and use it as layer in some map
  2. Upgrade to latest 2.x-dev (e.g. with Drush)
  3. The error can be seen on every map where that layers is used, also in OpenLayers admin interface (e.g. when editing map).

Is this enough? I will gladly provide more info if needed.

basvredeling’s picture

FileSize
1.75 KB

Actually all you need to do is resave the views that don't have the projection specified.

Here's a db update to add a default projection to all affected views.
Just run database updates via drush or /update.php and your problems should be resolved.
The module openlayers_views should be version 7201 afterwards.

basvredeling’s picture

Status: Needs work » Needs review
milos.kroulik’s picture

Status: Needs review » Reviewed & tested by the community

Thanks, it seems to be working fine. I will also update the other issue and mark it as duplicate of this one.

EDIT: Unfortunately, the error still appears in OpenLayers admin interface. When I display list of maps, i get:

Notice: Undefined index: data_source in openlayers_views_openlayers_layers() (line 128 of .../openlayers/modules/openlayers_views/openlayers_views.module). =>

When I try to display a map, I still also get Exception: Projection lacks an authority code. error.

milos.kroulik’s picture

Status: Reviewed & tested by the community » Needs work
deggertsen’s picture

New to this issue. Can someone update the issue summary to explain the current status of this issue and what patches should be used and tested at this point?

milos.kroulik’s picture

Issue summary: View changes
deggertsen’s picture

#17 fixed the problem for me. Thank you! I did have to go into my maps to select which layers would appear, but that's a small price to pay to have it working again. =)

basvredeling’s picture

@milos.kroulik I cannot reproduce the reported errors from #19.
Did you clear the cache after updating the db?
And the "Exception: Projection lacks an authority code. error." could point to setting the projection to 4326 instead of EPSG:4326.

I don't feel this patch needs more work really. Can you convince me otherwise? Try resaving the views and see which projection options you have.

milos.kroulik’s picture

Status: Needs work » Reviewed & tested by the community

Yes, I cleared the cache. I also think, that something might be wrong with my installation, as I also got some errors when creating new Views Data Overlays. And because it works for @deggertsen, I think, this can be marked as RTBC.

milos.kroulik’s picture

Looking at the openlayers_views.module source: is it possible, that source of the problem is the detection of OpenLayers Vector Data Overlay displays. If I understand it right, the code around line 128 tries to operate on all displays of a view, if there's at least one display with openlayers_data style plugin. Is it possible? I have some views with multiple displays, which use different style plugins.

basvredeling’s picture

It might be possible. But it's really hard to say. Maybe you can export your view using features so others can check it. If it is in any sense related to this issue and not to something in your local installation we'll need to solve it.
However, since we cannot reproduce the issue, it seems unrelated. I think the best thing you can do is go back to square 1. Recreate the view, recreate the layer, install the same view in a clean install by using export / import via features for instance. Also rerun the relevant database updates, or make sure they've all been executed properly. Including the supplied patch.

milos.kroulik’s picture

Thanks, I as finally able to solve my issue. As you expected, the problem was with the faulty view. For others with similar problems: I'm sorry, I didn't discover any clever debugging method. I just went through all the layers, checking projection field. There were two of them - I had to delete the corresponding view to get rid of all the errors.

basvredeling’s picture

Good to hear you solved your problems... now let's try to get this patch committed. Status is unchanged. Still RTBC

mikeytown2’s picture

I needed #17 and #11. Only map that works currently is open street map. This is moving in the correct direction so RTBC!

mikeytown2’s picture