Closed (fixed)
Project:
Openlayers
Version:
6.x-2.x-dev
Component:
OpenLayers API
Priority:
Minor
Category:
Task
Assigned:
Reporter:
Created:
6 Mar 2010 at 21:19 UTC
Updated:
17 Jun 2010 at 21:40 UTC
I was trying to create maps for the test page and in trying to create an example map with features, I realized the only way to do this is to use the layer_info() hook. This seems really convoluted and hindering for someone that wants to create maps with features that may not come from views or are dynamic.
I propose that the vector type layer should be an exception so that features can be made on the fly in a map without a hook. I understand that it means that the map is not fully exportable, but it will be in code, anyway.
This can be done fairly easily by putting in some exception logic in _openlayers_layers_process().
Comments
Comment #1
tmcw commentedYou can create a new layer type which takes features as a setting and then does the same thing as openlayers_views_vector in its render() hook. There's no reason to change any of the layer processing logic.
Comment #2
tmcw commentedAlso, I personally think that supporting random PHP-made maps isn't a high priority. There are good ways to store and display content in OpenLayers, and we should improve those ways. If people want to hack together a random_points layer type, anyway, this should be done at the layer type level - that way it isn't a huge hack but a moderate hack.
Comment #3
zzolo commentedThat is essentially what we are doing: supporting PHP made maps. This is what we loosely agreed upon. The idea, in my mind, has always been that the API comes first and the UI should go on top of that. That is pretty much approach of modules like Views, Imagecache, Context, etc. If we don't have a solid API with powerful data structures then the UI just becomes a hack anyway
And so, my point is that I think its a failing of the API to not provide an easier way to put features on a map. Yes, overall, most users will not be using the API directly, but that doesn't mean the API should not be more powerful and easier to use. A good use-case is a map with a single point on it for directions or an about page. It is very wasteful to have to go through all the parts to be able to put a single point on a map.
Supporting a "feature_vector" layer type would be a positive step, but it would still mean that someone has to provide a specific layer to put on a map, which is still kind of convoluted in my point.
I can concede to the idea of the core module providing the basic vector layer type that can support features (though I don't think this is the best idea).
Comment #4
tmcw commentedI'm not talking about the UI as being the only consumer here: I'm saying that we should focus, first and foremost, on making clean ways to use this module. Whether those are from views or from ctools down the line, or cck, these are the first and foremost uses of the module: not the API. And I think that, while it may require a little extra work to make a layer type than to hack together a map with a freeform backdoor, it is a better solution in all cases, and users who have the PHP knowledge to do one should be able to do the other, with decent documentation at hand. Not wanting to learn a tiny bit to use the module in advanced ways is not our problem.
Comment #5
tmcw commentedMarking this as by design for now, unless someone wants to open a ticket about making a new layer type for vector maps. I think that the openlayers_vector map behaviors introduced by the CCK module would fit this use case just fine.
Comment #6
zzolo commentedI still plan on doing this; assigning to me. It would just make sense to have a generic vector layer in the base module; this way one would not need have the CCK (or Views) module installed just have a vector layer.
Comment #7
zzolo commentedChange title to better reflect task.
Comment #8
tmcw commentedIs this still going to happen?
Comment #9
zzolo commentedSo, thinking about this some more. It does make sense to simply provide a generic vector layer behavior that allows for feature data, much like what is currently being done with views and cck. This is preferred because theres no easy way to store and attach features to a layer given current architecture. It does make it easy API wise to add features which is the main use-case, but there will be no real way to save and export this (but that is what the Views is for).
Comment #10
tmcw commentedRaw layer type and documentation added in http://drupal.org/cvs?commit=373272
Comment #11
zzolo commented@tmcw, thanks for the work on this. Some question I have about your implementation:
* Why is this called raw? We are only creating a vector layer with this.
* Why the use of layer_types instead of behaviors as what has been discussed above?
* This still needs to be changed for how Views and CCK add feature layers.
* Your use of "hack" in documentation seems really inappropriate and misleading.
Comment #12
tmcw commented* Why is this called raw? We are only creating a vector layer with this.
Yes: KML, OpenLayers Views, WFS, etc., all create Vector layers, with different data sources. Calling a new layer 'vector' would only make things more confusing: 'Vector' layers should be named after the data that they deal with, not the OpenLayers Layer class name.
* Why the use of layer_types instead of behaviors as what has been discussed above?
It seems to have many advantages - layers provided with the raw layer type can used with styles, behaviors, etc., in the 'traditional way', unlike behavior-layers, and they need about as much code.
* This still needs to be changed for how Views and CCK add feature layers.
What? Explain?
* Your use of "hack" in documentation seems really inappropriate and misleading.
Perhaps it is, feel free to rename.
Comment #13
tmcw commentedRenamed layer in documentation: http://drupal.org/cvs?commit=373794
Comment #14
zzolo commentedMy point about CCK and Views is just aimed at the fact that CCK and Views should be able to use any generic Vector layer mechanism that is created.