support georss and gml namespaces

[GoogleCodeExporter]

Attached is a patch to the feedparser trunk that adds support for simple
GeoRSS (http://georss.org/simple) and GeoRSS + GML locations (or "where")
in feeds. Tests for point, line, polygon, and box geometries are also
attached. The geospatial location of an entry is accessed via a "where"
key, the value of which is a dict with "type" and "coordinates" items
(following http://wiki.geojson.org/GeoJSON_draft_version_2).

Examples:

  <feed
    xmlns="http://www.w3.org/2005/Atom"
    xmlns:georss="http://www.georss.org/georss"
    >
    <entry>
      <georss:point>36.9382 31.1732</georss:point>
    </entry>
  </feed>

yields:

  >>> entry['where']['type']
  'Point'
  >>> entry['where']['coordinates']
  (31.1732, 36.9382)

Feedparser coordinate tuples are always in (longitude, latitude) order.
Users might specify an optional third elevation value, but almost never do.
The default elevation is 0 meters above ground level (AGL).

Line example:

  <feed 
    xmlns="http://www.w3.org/2005/Atom"
    xmlns:georss="http://www.georss.org/georss"
    >
    <entry>
      <georss:line>
        33.338611 52.566592 32.537546 52.527238 31.744196 52.409555
      </georss:line>
    </entry>
  </feed>

yields:

  >>> entry['where']['type']
  'LineString'
  >>> entry['where']['coordinates'][0]
  (52.566592, 33.338611)

I hope that you'll find this useful.

Original issue reported on code.google.com by sean.gil...@gmail.com on 7 Sep 2007 at 11:17

Attachments:

• georss-gml.patch
• georss-gml-tests.tar.gz

[GoogleCodeExporter]

is there a patch for geo:lat and geo:long geo:alt (eg
http://www.prh.noaa.gov/ptwc/feeds/ptwc_rss_hawaii.xml)?

Cheers

Original comment by sampe...@gmail.com on 29 May 2008 at 2:49

[GoogleCodeExporter]

I think "geo" is already included with feedparser. For me, it's not expressive
enough. I want lines and polygons too, hence georss.

Original comment by sean.gil...@gmail.com on 29 May 2008 at 3:29

[GoogleCodeExporter]

Is there an updated patch this, or any chance this can make it into the 
codebase?  I
think this would be a valuable addition.

Original comment by tom.kral...@gmail.com on 19 Nov 2008 at 1:35

[GoogleCodeExporter]

I patched this to r291 without any trouble.

$ svn export http://feedparser.googlecode.com/svn/trunk/feedparser/feedparser.py
A    feedparser.py
$ curl
'http://feedparser.googlecode.com/issues/attachment?aid=-5035140636427960669&nam
e=georss-gml.patch'
|patch -p1
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  6905  100  6905    0     0  41747      0 --:--:-- --:--:-- --:--:--  181k
patching file feedparser.py
Hunk #1 succeeded at 401 (offset 4 lines).
Hunk #2 succeeded at 462 (offset 4 lines).
Hunk #3 succeeded at 1271 (offset 11 lines).
Hunk #4 succeeded at 3425 with fuzz 1 (offset 25 lines).

Original comment by thecap...@gmail.com on 5 Jan 2009 at 6:24

[GoogleCodeExporter]

Is this patch distributed in the zip file yet?

I having a hard time patching. I want to use feedparser in my project but looks 
like
I will have to distribute a patched version instead of the current version....

Are the authors still maintaining this project or is it being passed on?

Original comment by sampe...@gmail.com on 5 Jun 2009 at 4:27

[GoogleCodeExporter]

So I finaly was able to apply the patch.

1. I did an SVn checkout for revision 291. (which in hind site was not needed
2. Applied patch (remember it has to reside in the parent directory.
3. This fetched revision 263 and applied the patch.
4. When I did an update afterward it merged with the current revision of trunk
revision 295.

I have attached a new patch that should work against revision 295. Although not
thoroughly tested I figure it should be a good place to start. 

Original comment by sampe...@gmail.com on 5 Jun 2009 at 4:41

Attachments:

• georss-gml-r295.patch

[GoogleCodeExporter]

Alright, here the last post for a while....

is KML considered a feed?  I so then perhaps it would be a good addition, 
especially
if the above patches made their way to trunk.

ref: http://www.mapfarmer.com/geofeed/geofeed_101

Cheers

Original comment by sampe...@gmail.com on 5 Jun 2009 at 4:54

[GoogleCodeExporter]

Some KML documents are feed-like (placemarks in a document without folders), 
but KML
allows arbitrarily deep hierarchies of folders. It's not feasible, therefore, to
parse all KML documents as feeds.

Original comment by sean.gil...@gmail.com on 5 Jun 2009 at 5:09

[GoogleCodeExporter]

Issue 58 has been merged into this issue.

Original comment by adewale on 1 Dec 2010 at 11:45

[GoogleCodeExporter]

Comment copied over from Issue 58

This seems a little confusing.

- The Georss schema: http://www.georss.org/xml/1.1/georss.xsd use latitude then 
longitude for describing a 
point. Since Feedparser does not parse JSON I'm not sure why we'd follow the 
GeoJSON style. Please explain.
- The geometry entry you'd added differs from the way Feedparser usually 
handles namespaced elements. We 
try to avoid special-casing namespaced elements. Instead you should be able to 
access the element in a 
structure that resemble the original input feed. See this: 
http://code.google.com/p/feedparser/source/browse/trunk/feedparser/tests/wellfor
med/namespace/atomth
readingwithentry.xml for an example.
- The examples here: http://georss.org/simple for featureName, featureTypeTag 
and relationshipTag don't 
match the case used in the schema: http://www.georss.org/xml/1.1/georss.xsd

Original comment by adewale on 1 Dec 2010 at 11:47

[GoogleCodeExporter]

Original comment by kurtmckee on 19 Jan 2011 at 4:49

• Changed title: support georss and gml namespaces
• Added labels: Type-Enhancement
• Removed labels: Type-Defect, Priority-Medium

[GoogleCodeExporter]

I'm not currently planning to add this to feedparser core. All is not lost, 
however: when I have time it's my intention to make it easier for developers to 
add their own custom namespace support as well as provide sample 
implementations. This seems like a reasonable future candidate for such a 
"sample pack".

Original comment by kurtmckee on 18 Jun 2011 at 10:16

• Changed state: WontFix

[GoogleCodeExporter]

I have come back to the project with a need to parse atom feeds which is 
proving to be successful. As usual though there will be geo tags in these atom 
feeds, likely georss format.

I noticed that there is a section in feedparser.py that has the following 
comment # GEO (geographical information).

Can anyone provide context. Is this to support georss in part?

I will likely test the patch provided above but it seems to be getting pretty 
old. Any progress in adding our own schemas?

Cheers

Original comment by sampe...@gmail.com on 27 Sep 2011 at 7:42

[GoogleCodeExporter]

No, unfortunately. :( I'm currently working extended hours, but I hope to have 
a new release of feedparser out next month, and then begin working on some 
big-picture ideas such as more easily extending feedparser.

Original comment by kurtmckee on 28 Sep 2011 at 6:49

[GoogleCodeExporter]

My old georss/gml patch applied fairly cleanly to 
https://github.com/kurtmckee/feedparser (5.2). I've forked and branched 
feedparser, adding my georss/gml parser and its tests (which all pass) to

  https://github.com/sgillies/feedparser/tree/georss

I'm sending a pull request to https://github.com/kurtmckee/feedparser now. With 
tests! Did I mention that my small, uncomplicated patch comes with tests? And 
that it lets people parse fantastic feeds like those of earthquake locations 
(http://earthquake.usgs.gov/earthquakes/catalogs/1hour-M1.xml)?

Original comment by sean.gil...@gmail.com on 29 Sep 2012 at 9:58

[GoogleCodeExporter]

I am +1 on this patch, background I use feedparser to parse Atom and RSS 
results of geo OpenSearch feeds and need a clean and predictable interface to 
the geoinformation in the results. As __geo_interface__ is the lingua franca  
for python geo interchange https://gist.github.com/2217756 this is IMHO a great 
addition

Original comment by christian.ledermann on 1 Oct 2012 at 2:47

[GoogleCodeExporter]

This issue was closed by revision aa06a0a0d20d.

Original comment by kurtmckee on 13 Jan 2013 at 7:15

• Changed state: Fixed