So, it's time to start talking about the 3.x version. The 2.x version is just about to go into beta (just those style plugins), and @nod_ has been putting a lot of time and effort on Behaviors and testing, and it will have API changes, and I don't want to delay that work, so, its time to start the 3.x version (slowly).

The following are the goals thatwe have thought about for the 3.x version. The aim of this issue is to get a set of goals for 3.x; there's no need to go too far into details, and this issue will not remain open ended.

  1. Seriously consider moving to the (unfinished) Mapping module. The aim of this module is to abstract out all the Drupal parts of this module, so that other mapping libraries can have the same sort of integration as the rest.
  2. Map level event system for behaviors. This is mostly about making a system similar to Drupal behaviors, but specifically for maps. Work being done here: #1332836: Behavior re-architecting, use map level event system
  3. Serious JS level testing. This module is too JS heavy to not have better tests. This should utilize the QUnit module, unless something else better comes up. Some work started here: #1339864: Serious JS Testing Base
  4. Our own display mechanism. Though its nice to utilize Views, but it confuses users so much. We don't have to make this overly robust; at least provide pages and blocks.
  5. Address user experience issues. It's hard to pinpoint what exactly the issues are here, but its clear that people find the module confusing. We need to identify and fix these sorts of things.
  6. Projections. Projections suck, but our implementation sucks even more. We need to make projections more a real object with options. We also should default to Spherical Mercator, and treat other projections as the exceptions. Spherical Mercator is not the best, but most users don't care and most free tiles are in this format.
  7. Rendering process needs streamlining. Rendering, along with lots of the API, has been just added to and not really revisited. It's time.
  8. Seriously improve Views Data Overlays (consider using GeoJSON instead). Our Views integration is not horrible, but its pretty hacked together. Consider using the GeoJSON module as the only option.
  9. Overall cleanup. It's been a while and its time to clean things up overall.
  10. Documentation. I really want documentation to be a part of the development process (just like Testing). I also want to make sure that Documentation gets pushed over to Drupal.org and thats it. Anything that is in the module, should be end-user help that is contextual (field descriptions, etc).
  11. OL Library management. We can probably do this in current version. But we should be using the libraries module to manage this.
  12. Theme management. How can we manage the themes which are sets of CSS and images.
  13. Automatic build profiles. Put only the used features, layers, format and behaviors in OpenLayers.js file. I went from 900k to 300k building my own file. we could have a 'build this map profile' or a 'build a profile for all maps'.

What else?

Comments

zzolo’s picture

zzolo CreditAttribution: zzolo commented

Some more ideas.

* Better management of library. We can probably do this in current version. But we should be using the libraries module to manage this.
* Think about OL themes. How can we manage the themes which are sets of CSS and images.

nod_’s picture

nod_
Primary language French
Location Lille
CreditAttribution: nod_ commented

on my whishlist :

  • Automatic build profiles: put only the used features, layers, format and behaviors in OpenLayers.js file. I went from 900k to 300k building my own file. we could have a 'build this map profile' or a 'build a profile for all maps'.
dasjo’s picture

dasjo
he/him
Primary language German
Location Zurich
CreditAttribution: dasjo commented

+1 for Automatic build profiles :)

maybe we could use ctools page manager for parts of the display mechanism

Brandonian’s picture

Brandonian CreditAttribution: Brandonian commented

All of these sound like great ideas. Thoughts...

  • Projections - Would this make more sense on the data end? As in, should Geofield take this on in the next version, or does this make more sense in the display area?
  • Mapping Module - I second. Although we'd basically be starting from scratch, I think taking our data structure and making it easier for non-Openlayers libraries to interact with a common stack would be immensely beneficial.

    Correct me if I'm wrong, but I'm assuming that if we decide that Mapping is the way forward, then the Openlayers module would stick around to provide the actual library/implementation. Mapping would abstract out the data structures and whatnot, while Openlayers would handle library calls, rendering and other stuff.

  • UX Issues - Second.
  • 7.2.0 full release - It's great that we've hit beta, but let's not lose sight of getting a full release out in the wild. Nothing hurts credibility like perpetual alpha/beta status.

    @zzolo, care to coordinate full releases for Geofield and Openlayers? There's a few minor tweaks I'd like to get finished for the Openlayers map widget (along with the unit tests I keep procrastinating), but otherwise, I think I feel confident that I could get a full release out in quick order.

zzolo’s picture

zzolo CreditAttribution: zzolo commented

Hey @Brandonian. In response to your comments:

  • Projections will need to be handled by both display and data. It may make sense to maybe put this in a separate module, though I am not sure how this looks? Overall, I just know we need to do something that is more extendable.
  • Yeah, when Mapping module moves forward, OpenLayers would still be around to implement the OL library.
  • The 7.2.0 release is still the highest priority. But, I just did not want to stop people, like @nod_, from doing good work because my lack of time.

Another goal I would like to add, is the following:

Documentation. I really want documentation to be a part of the development process (just like Testing). I also want to make sure that Documentation gets pushed over to Drupal.org and thats it. Anything that is in the module, should be end-user help that is contextual (field descriptions, etc).

nod_’s picture

nod_
Primary language French
Location Lille
CreditAttribution: nod_ commented

Support big datasets Provide options and tools to work with big datasets. Switching to geojson is going to help but we need to at lest warn users where big datasets will be a problem and give pointers on how to deal with it. See #1370536: Display thousands of entries.

nod_’s picture

nod_
Primary language French
Location Lille
CreditAttribution: nod_ commented

How about prioritizing the list ? I'm all for a stable 2.x first.

zzolo’s picture

zzolo CreditAttribution: zzolo commented

Hey @nod_. I'd love to hear your ideas on prioritization.

nod_’s picture

nod_
Primary language French
Location Lille
CreditAttribution: nod_ commented

Here we go, all in the right order :

  1. 7.2.0 full release: yep as a 3.x goal :).
    1. #1247756: Undefined Label in Clustered Data Points (Port Style Plugins)
    2. Documentation
  2. #1339864: Serious JS Testing Base I have a new branch for that, it's way to big to have useful patches,
  3. Switch to GeoJSON: and probably help make it awesomer,
  4. UX and DX issues: cleanup rendering process (my personal issue is reducing JS settings size),
  5. Support big datasets and Search API integration: like search_api_location
  6. #1331410: Better Handling of Projections,
  7. Library management,
  8. Theme management: see how they're going to do that in core.

After all of this in no particular order :

  • Mapping Module,
  • Automatic build profiles.

That's pretty much how i'd go.

Brandonian’s picture

Brandonian CreditAttribution: Brandonian commented

Can't argue with #1. :-)

I personally think pushing a dependence on mapping should be a higher priority because it will affect the overall architecture of the module. I can also understand why we wouldn't want to do that, since we'd basically be committing to be reliant on untested code. As someone who enjoys user other mapping libraries, though, I'm all for helping stabilizing/strengthening the Mapping module into something we can use here.

Dale Baldwin’s picture

Dale Baldwin CreditAttribution: Dale Baldwin commented

Modifications required to make maps friendly with themes that use responsive design.

Patroclas’s picture

Patroclas CreditAttribution: Patroclas commented

Apologies if this is not appropriate here but can something be done to remove the huge amount of code that gets into the httml head with every layer being defined even if it's not displayed? Every map and layer adds more and this has performance issues.

nod_’s picture

nod_
Primary language French
Location Lille
CreditAttribution: nod_ commented

I know I actually hate that too. But that must be because you have lots of results on your map? When we'll get to using views_geojson all the results code will be moved away from head so It'll leave only the styling informations which is still manageable.

Patroclas’s picture

Patroclas CreditAttribution: Patroclas commented

Good to know - and yes, I have many maps and all with multiple overlays. Can't say I know much about GeoJson but will look forward to testing any developments.

Thanks for the reply

mgifford’s picture

mgifford
he/him
Primary language English
CreditAttribution: mgifford commented

+1 to #9-5

mgifford’s picture

mgifford
he/him
Primary language English
CreditAttribution: mgifford commented
Issue summary: View changes

Including otheres' ideas.

czigor’s picture

czigor CreditAttribution: czigor commented

What's the status of the 3.x branch? Has it been abandoned? I can see it's not really been worked on lately while the 2.x branch is quite active.

Pol’s picture

Pol
the/that
Location Brussels
CreditAttribution: Pol commented
Status: Active » Fixed

Hello czigor,

I would like to work on it but I have no free time to do it since these last month.
Also, I would also like to have a bit of help of the community to make this huge things evolve in the right direction.

If you're willing to help, you're very welcome!

Status: Fixed » Closed (fixed)

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