#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 , 18 years ago
| Triage Stage: | Unreviewed → Accepted |
|---|
comment:2 by , 18 years ago
| Description: | modified (diff) |
|---|
comment:3 by , 17 years ago
comment:4 by , 17 years ago
| milestone: | → 1.0 beta |
|---|---|
| Status: | new → assigned |
comment:5 by , 17 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.Feedwithitem_locationandlocationparameters 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
georssnamespace 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 takekwargswhich 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 , 17 years ago
comment:7 by , 17 years ago
comment:9 by , 17 years ago
| milestone: | 1.0 beta → 1.0 |
|---|
by , 17 years ago
| Attachment: | georss_syndication_patch.diff added |
|---|
Patch for GeoRSS; also includes some internal changes to Feed
comment:11 by , 17 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 , 17 years ago
| Attachment: | georss_syndication_patch_v2.diff added |
|---|
Version 2; uses W3C Geo for RSS points.
by , 17 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 , 17 years ago
| Attachment: | georss_syndication_patch_v4.diff added |
|---|
Less intrusive patch to contrib.syndication.
comment:12 by , 17 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.