#6547 closed (fixed)
Support GeoRSS in syndication of Geographic Models
Reported by: | jbronn | Owned by: | jbronn |
---|---|---|---|
Component: | GIS | Version: | gis |
Severity: | Keywords: | gis georss feed rss | |
Cc: | jbronn@… | Triage Stage: | Accepted |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
There should be a django.contrib.gis.syndication
module, that will contain a subclass of Feed
, that will include GeoRSS information for geographic models.
GeoRSS support for Django was discussed earlier in django-users. The solution should be simple, and be familiar to those who have used Django's syndication feeds -- in other words, keep the API consistent with what Django already has. See also [browser:django/trunk/django/utils/feedgenerator.py].
Attachments (4)
Change History (17)
comment:1 by , 17 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:2 by , 17 years ago
Description: | modified (diff) |
---|
comment:3 by , 16 years ago
comment:4 by , 16 years ago
milestone: | → 1.0 beta |
---|---|
Status: | new → assigned |
comment:5 by , 16 years ago
I looked at this a bit tonight (because I want to generate some GeoRSS feeds)... comments are below. Mostly referring to Atom but similar concepts apply to RSS - noted in (brackets):
- creating a subclass of
django.contrib.syndication.feeds.Feed
withitem_location
andlocation
parameters won't be a problem to extract a geometry field from a model - the problem comes with respect to
django.utils.feedgenerator.SyndicationFeed
:- we want to add a
<georss:where>
clause to the feed(channel), each entry(item), or both. - we need to add the
georss
namespace declaration to<feed>
(<channel>
) - there are no hooks for extending either the feed or the entry, which means we'd have to reimplement/duplicate the entire
write()
andwrite_items()
for each feed format. :(
- we want to add a
Ok, so that's not gonna happen.
Extensions I think should be added to SyndicationFeed
& its implementations to allow us to GeoRSS-ify stuff:
SyndicationFeed.__init__()
andSyndicationFeed.add_item()
should takekwargs
which are added into the feed/item dictionaries respectively.extra_attrs()
: Add attributes to the rootfeed
(channel
) element. eg.xmlns:georss="http://..."
. Returns a dictionary. Called fromwrite()
extras(handler)
: Add elements within thefeed
(channel
) element. eg. a<georss:where>
for the feed. Called fromwrite()
item_extra_attrs(item)
: Add attributes to theentry
(item
) elements (called once for each item). Returns a dictionary. Called fromwrite_items()
item_extras(handler, item)
: Add elements within theentry
(item
) elements (called once for each item). Would be where the georss would be added. Called fromwrite_items()
Once we have those hooks we can do a mixin with each of the existing SyndicationFeed implementations and a GeoRSS implementation that knows how to turn a geometry object into a suitable GeoRSS clause. It would not just do georss then, but could also do media:
or any other extensions. Thats quite a sizeable set of changes though, so I guess we need to bring it up on django-dev, and who knows whether it'll get through pre-1.0. I think those hooks make things much more flexible without needing to go to the lengths of rewriting the whole framework.
See also:
Probably should be another ticket, but I thought i'd get some initial feedback first.
comment:6 by , 16 years ago
comment:7 by , 16 years ago
comment:9 by , 16 years ago
milestone: | 1.0 beta → 1.0 |
---|
by , 16 years ago
Attachment: | georss_syndication_patch.diff added |
---|
Patch for GeoRSS; also includes some internal changes to Feed
comment:11 by , 16 years ago
In my patch I added django.contrib.gis.feeds.Feed
, which has support for simple GeoRSS. You may specify a geometry element on the entire feed by defining a geometry
function; similarly, geometries in the feed may be specified by item_geometry
method -- both should return a WGS84 (GEOS|OGR)Geometry
.
Some big internal changes to the original Feed
class, specifically abstracting a lot to the (now) subclassable get_feed_kwargs
and get_item_kwargs
methods. Tests pass, but I want some input on whether it's OK to make some of those variables class-wide (e.g., self.current_site
, and the templates). This makes subclassing Feed
easier, granting access to the __get_dynamic_attr
magic.
by , 16 years ago
Attachment: | georss_syndication_patch_v2.diff added |
---|
Version 2; uses W3C Geo for RSS points.
by , 16 years ago
Attachment: | georss_syndication_patch_v3.diff added |
---|
W3C Geo is no longer default for points on RSS feeds, but is now its own subclass.
by , 16 years ago
Attachment: | georss_syndication_patch_v4.diff added |
---|
Less intrusive patch to contrib.syndication
.
comment:12 by , 16 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
There's no need to limit this to only GeoDjango. All that's needed is to add item_location to the base SyndicationFeed that adds a location (tuple?) to item, then change the syndictation-types to spit out a <georss:point>-line if item has a location.
Then pepole would override item_location in the exact same way they already do for links, authors, categories etc.
Now if growing feeds by adding extra xml-tags becomes common, there should probably be a generic way of adding such tags, especially if they are as undemanding as georss.