May be we can discuss this more next week in St Louis?

Ian

Not being able to represent multiple locations hasbeen a major drwaback for representing our geocoded news (I’m working at the german news agency) within georss.

Since our main feed format is NITF (NewsIndustryTextFormat http://www.nitf.org) we first had to come up with a notation of our geocoded news in NITF. We choose to use georss:point within NITF (see example below)

<identified-content>
<location>
<state state-code=”07000000″ code-source=”AGS”>Rheinland-Pfalz<georss:point>8.27104591236
49.9966008543</georss:point></state>
<country iso-cc=”DEU”>Deutschland</country>
</location>
<location>
<region region-code=”10041000″ code-source=”AGS”>Stadtverband Saarbrücken<georss:point>6.
99763293966 49.2358453373</georss:point></region>
<state state-code=”10000000″ code-source=”AGS”>Saarland<georss:point>6.99763293966 49.2358
453373</georss:point></state>
<country iso-cc=”DEU”>Deutschland</country>
</location>
</identified-content>

From my experience an even more important freason or external references than the drawback of increasing the feed size is the fact that typically
license restrictions from commercial data providers do not allow to include the geometries of the counties, city, neighbourhood borders etc.

And at least in Germany there are only commercial providers for the geometries, since every city is selling the geometries for ridicolous prices and wven more ridicoulous licensing terms.

Hence we are only able to include the centroid (resp. some official representant designated by some authority) of the polygon within our feeds. But in order to enable our customers to identify which geometry to associate with the locations and do the computations you mentioned above we had to come up with a way to communicate an identifier for that geometry. To our advantage NITF already provides code-source and *-code attributes that we could use for these purposes.

I would like to be able to come up with similar possibilities in GeoRSS. IMHO, generalizing external references via src attributes from georss:polygon into a separate tag, e.g. georss:ref, georss:external or whatever it should be named seems to be a good idea for doing so. Given the rel attribute maybe using georss:link would be a good idea as a tag name. Having a separate tag would be similar to the handling of external images via the img tag as well as the link tag in HTML and allow for flexible representation schemes for the external data as well as coping with some shortcomings of your proposal. e.g. the result being not a polygon but a point or a line.

I’m also not sure if the attributes excerpt and featurename are really necessary and shouldn’t be handled via additional namespaces or tags. I definitely think that excerpt shouldn’t be an attribute. It also makes sense for me to rename featurename to name.

PS.: I’m attending Where2.0 and WhereCamp (and currently are still free on May 15-16th) and would be most interested to discuss these issues. Anybody else interested?

BTW.: I’m reporting on my efforts of becoming the dpa the first news agency worldwide to geoceode their news on by blog in a miniseries to be found at http://relations.ka2.de?tag=goingplaces and would be most interested in getting feedback.