Multiple map arrays written in 'OpenLayers Map' view

This is really confusing from my perspective - the problem is that the documentation doesn't specify that you have to add the WKT field before using it in the style plugin configuration? And is there something that's getting blurred into here - Default Map? The documentation does go to great lengths to explain the difference between the OpenLayers Map and OpenLayers Data displays/styles.

The format for the WKT field? Is this WKT data coming from the geo module? I must be missing something huge, because I see no options for how to format individual fields in Views, unless Geo is adding a format option...

@strk can you describe the bug more. I am confused as I thought this issue was specifically about using the correct format in Views.

The problem is that you can both set CCK data to display as a map and then pull that data into a view, resulting in a map within a map. The solution might be stronger helptext for the CCK options, or preventing people from choosing that combination of options.

I don't really see why we should limit the formatter for the WKT field in Views. Yes, I can't really think of a use case, but someone might want a list of maps or something like that. I think there is a better way to solve this without limiting a built in feature.

My suggestion is just make documentation better, and, if possible, make the WKT the default formatter in Views (this was the case before we changed the default map to the default formatter).

I don't really see why we should limit the formatter for the WKT field in Views. Yes, I can't really think of a use case, but someone might want a list of maps or something like that. I think there is a better way to solve this without limiting a built in feature.

Huhwhat? We're talking about refusing the combination of the CCK map formatter and views output of maps. Reread?

I fully understand what is going on here. We are talking about the formatter for fields of OL CCK WKT, specifically for the Views Data Overlay display. By default, if we limit the formatter on this field, it would apply to any View that wants to use this field (this is where my comment was based). We could limit to just restricting the formatter options for the OL CCK WKT field specifically for the OL Views Data Overlay display (if this is possible), but this would encompass rendering a map in a popup as well (which I am not sure if this is possible anyway). We could also look at trying to only use the WKT value from the OL WKT CCK field, but this is a hack as well, IMO. Nonetheless, I think we need to ensure that we do not limit the format of this field in all Views displays, or even within a popup.

Uh. As I said, we're talking about preventing the combination of fields with the OpenLayers Map formatter and their usage in OpenLayers Data views as WKT data input.

There is no use case, theoretical or real, that would have you desiring a rendered map as your source of WKT data.

This does not conflict with the eventual odd goal of having maps in popups, it's per-field usage.

How is this hackish? Seriously? It's validating input in a views form for a legit reason. If hackish is applied to a thing, there should be an explanation, not just a word thrown out. Where's the hack in sensible validation? What are the big risks of doing this? How do these outweigh the benefit of avoiding a serious problem that can easily occur when people use both CCK Map formatters and views output on the same site? I mean, I just don't get it here, there's no opinion, I think this just requires a reread.

"There is no use case, theoretical or real, that would have you desiring a rendered map as your source of WKT data."

I agree. I think we are just missing each other as usual. There hasn't really been talk about how this will actually be implemented. Here is my train of thought that I got from reading the above comments.

* My initial assumption was that there was a desire to limit using the map formatters in the fields all together. I am against this.
* The second level assumption would be to do the same just for Data Overlay displays, but this is bad to as it removes the ability to render a map in a popup (or other way).
* My third thought was to dig into the WKT field that was chosen for data and get WKT data from it whether it was formatted as a map or not. This is definitely a hack in that it would require going against how Views is set and how fields get rendered as well
* And finally as you mention in the last ticket (and no where else) there is the idea of validating the field chosen in the Data Overlay display plugin settings, which does make lots of sense, but was never the impression I got from the discussion above. I am sorry for the confusion.

And finally as you mention in the last ticket (and no where else) there is the idea of validating the field chosen in the Data Overlay display plugin settings, which does make lots of sense, but was never the impression I got from the discussion above.

the first thing I said was

preventing people from choosing that combination of options.

Indeed, you disagree strongly bad ideas that weren't proposed, and didn't follow the same train of thought as strk and me. ...I'll roll a patch in a bit.

Fixed in: http://drupal.org/cvs?commit=408046