Views 2.x support for KML module
geodaniel - September 10, 2008 - 15:22
| Project: | KML module |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
Description
The 6 port is now in a working state apart from Views 2.x support. In particular, we need to allow KML to be used as a style for Views 2.x.
#1
Hello,
I would love to have the Views 2.x support, if someone tells me where I can find information about porting a plugin from Views 1.x to Views 2.x, I can help !
Thanks in advance.
--
Jean-Pierre
#2
I'm interested in Views 2 functionality as well!
#3
Until this is updated; has anyone found a workaround to export a filtered (by content type?) list of locations as KML?
#4
Answering my own questions, XML to KML (http://drupal.org/project/xmltokml) can take a feed or XML view (views_datasource, from http://drupal.org/node/307223#comment-1040887 until the main code is updated (the July 2008 release is broken with the Views2) and output it as KML (to download, could probably work as a network link/feed with permissions set correctly, I haven't gotten back to that yet)
#5
I'm hoping to get back to this soon, sorry for the delay. The plan is to rewrite much of kml module to make it a views style plugin instead of re-implementing that functionality, so then we should be able to let it work with other modules too. The module should be much leaner when finished.
#6
dont mean to rush, but is there a new version soon?
cheers
#7
I'm going to try and devote some time to kick-starting this next week.
#8
cool thanks! cant wait
#9
+1 for this... will have a crack at a patch this weekend (erm... I hope).
#10
Tricky.
Hmmm... I looked at views2 for 3-4 hours last night. Got somewhere (see http://groups.drupal.org/node/23890) but no-where near enough. This morning decided this was going to take a long time to do properly so hard-coded a custom module solution for my D6 site.
Here's the .module file for those that are interested, it's a quick and dirty fix until views integration is working. Note the hook_load as part of named menu argument that checks the content type and only implements this menu for those node types. On our site 'node/%ride_story/tracks' is a standard view showing related nodes in a tab and works just fine. One could use
node_loadinside there but I believe the menu system calls that load function for each request to a matching path and didn't want to do a full load for those when checking the content type was all that was required.<?php
/* Temporary module until views integration is done */
function track_kml_menu() {
$items['node/%ride_story/tracks/kml'] = array(
'title' => 'KML',
'type' => MENU_CALLBACK,
'page callback' => '_track_kml_generate',
'page arguments' => array(1),
'access callback' => TRUE,
);
return $items;
}
function _track_kml_generate($nid) {
/* Just load a list of nodes and pass to KML module's functions */
$sql = "SELECT n.nid, n.changed FROM {content_field_ride_database_entry} c, {node} n WHERE c.field_ride_database_entry_nid = %d AND n.nid = c.nid AND n.type = 'track' and n.status = 1 order by n.title";
$result = db_query($sql, $nid);
$nodes = array();
$max_changed = 0;
while ($node = db_fetch_object($result)) {
$nodes[] = $node;
$hash_list[] = $node->nid;
if ($node->changed > $max_changed) {
$max_changed = $node->changed;
}
}
$attributes['title'] = 'Tracks';
$attributes['description'] = "Tracks for $nid";
sort($hash_list);
$cache_name = 'kml:tracks';
$cid = $cache_name .':'. md5(join('+', $hash_list));
_kml_feed_check_cache($nodes, $attributes, $cid, $max_changed);
}
?>
#11
The attached module provides barebones views integration for KML. It handles lat/lon point data from CCK fields provided by Location CCK or simple text/numeric fields.
Could be extended to work with lines/polygons, allow themable style output, generate linestrings from a list of rows within the view, and in a number of other directions but I wanted to post the simple version first to get feedback.
#12
+ 1 for views 2 ...
#13
Robert, thanks for posting that, and sorry for the delay in trying it out and giving feedback. Putting this in as a 2.x branch sounds like the best idea as it's quite a departure (and definitely a welcome one) from the original version.
Trying it out, it worked well, and I think it's ready for an initial dev release on a 2.x branch, though I did notice a couple of things I'd like to add to it to bring it back to the capabilities of the original, like:
Robert, Robin, and anyone else interested in this issue, what are your thoughts on these points?
#14
I've committed this initial version to HEAD, slightly modified to include $Id$ tags.
#15
Hi Dan,
Thanks for the review. Most of this stuff seems reasonable. I'd also add that I need to make sure grouping works (my guess is it doesn't at the moment but it's a quick fix).
In terms of default views - should we do something at admin/settings/kml that lets people pick their primary sources of geographic data and then run the defaults through hook_views_defaults_alter? This seems feasible with a limited amount of trickery.
What are the needs around icon styling? Lots of options here, how would we like this to work?
Will post patches for these requests when I can.
Cheers,
Robert
#16
The attached patch implements the default views via the approach discussed above. At admin/settings/kml you can choose fields as data sources for geo information as well as choose the relevant content types. The default view lives at /kml.
Frankly I think this is a lot of code for not that much win....
#17
Hit submit too fast.
Meant to end with I'd rather see this not committed, but am posting to give you a sense of what a default KML view feature would entail.
#18
+ 1 for views 2 ...
#19
I was taking another look at this yesterday and I agree with you Robert, adding that default view is probably overkill as it's likely to just be overridden by users anyway. As long as we explain to users how to set up their first KML feed(s), I think we should be good.
I think we may still want a settings page to let users choose their location source (e.g. lat/long fields, location module or geo module) so we can use it for non-views powered parts, like adding a link to the node to view a KML file of its location.
#20
Is this getting committed? The patch has been in the queue for a long time now.