Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
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.
Comment | File | Size | Author |
---|---|---|---|
#31 | openlayers-2127071-31-update-smart-defaults.patch | 4.18 KB | mikeytown2 |
| |||
#17 | openlayers_2127071-17.patch | 1.75 KB | basvredeling |
#10 | projection.patch | 2.58 KB | milos.kroulik |
#1 | allow_different-2127071-1.patch | 2.5 KB | basvredeling |
openlayers-openlayers_views_projections.patch | 3.02 KB | azuledu | |
Comments
Comment #1
basvredelingYes, 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.
Comment #2
PolGood for me !
Is the patch ready to be committed already ?
Comment #3
basvredelingIf the patch survives testing and someone else can have a second opinion, I'd say it's good to go.
Comment #5
PolI just changed it a bit.
Thanks !
Comment #7
milos.kroulik CreditAttribution: milos.kroulik commentedSorry, 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.
Comment #8
milos.kroulik CreditAttribution: milos.kroulik commentedThe commit made in response to https://www.drupal.org/node/2378725 should also be reverted, as it seems to depend on this one.
Comment #9
basvredelingI agree. Let's make a new patch with db update
Comment #10
milos.kroulik CreditAttribution: milos.kroulik commentedMaybe 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:
Please review the attached patch (which based on beta11) and help me to correct my (probably stupid) mistakes. Thanks.
Comment #11
basvredelingI 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.
Comment #12
PolMake sense to me.
Comment #13
milos.kroulik CreditAttribution: milos.kroulik commentedThanks. Unfortunately, #11 still doesn't work for me. All I got is an well-known exception:
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));
Comment #14
milos.kroulik CreditAttribution: milos.kroulik commentedBump. Can you, please, correct my patch?
Comment #15
basvredeling@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?
Comment #16
milos.kroulik CreditAttribution: milos.kroulik commentedIt can be reproduced like this:
Is this enough? I will gladly provide more info if needed.
Comment #17
basvredelingActually 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.
Comment #18
basvredelingComment #19
milos.kroulik CreditAttribution: milos.kroulik commentedThanks, 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.Comment #20
milos.kroulik CreditAttribution: milos.kroulik commentedComment #21
deggertsen CreditAttribution: deggertsen commentedNew 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?
Comment #22
milos.kroulik CreditAttribution: milos.kroulik commentedComment #23
deggertsen CreditAttribution: deggertsen commented#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. =)
Comment #24
basvredeling@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.
Comment #25
milos.kroulik CreditAttribution: milos.kroulik commentedYes, 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.
Comment #26
milos.kroulik CreditAttribution: milos.kroulik commentedLooking 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 withopenlayers_data
style plugin. Is it possible? I have some views with multiple displays, which use different style plugins.Comment #27
basvredelingIt 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.
Comment #28
milos.kroulik CreditAttribution: milos.kroulik commentedThanks, 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.
Comment #29
basvredelingGood to hear you solved your problems... now let's try to get this patch committed. Status is unchanged. Still RTBC
Comment #30
mikeytown2 CreditAttribution: mikeytown2 commentedI needed #17 and #11. Only map that works currently is open street map. This is moving in the correct direction so RTBC!
Comment #31
mikeytown2 CreditAttribution: mikeytown2 commented#11 & #17 in one patch