[georss] Photographs

Sat May 20 07:30:42 EDT 2006

(sorry if you already knew any of this, this is just what I know ;)

EXIF, does have a standard for encoding a 'GPS' location,
http://www.w3.org/2003/12/exif/
for one see: http://www.flickr.com/services/api/flickr.photos.getExif.html
and see an example GPS as part of overall EXIF data,
http://www.drewnoakes.com/code/exif/sampleOutput.html

There are camera's available that have GPS inbuilt
http://www.geospatialexperts.com/ricoh.html
 (or can connect to a GPS) to record the location at shooting time. Plus 
there are software
http://www.robogeo.com/
 that attempts to match up a GPS tracklog and encode the most likely 
location in the EXIF data.

Even though flickr supports this GPS/EXIF standard, I believe its not well 
supported and/or used, and in fact lead to the whole geobloggers scene using 
tags to encode the lat/long (mainly because it could be done much easier by 
the user)
http://geobloggers.com/blog1/2006/03/13/geobloggers-changes-direction/

As for RSS, I recently combined GeoRSS and PhotoRSS, to create feeds from 
geograph.org.uk, so as you get the photo as well as the location in one 
feed, couldn't at the time find a better way than just using the two 
extensions together, eg
http://www.geograph.org.uk/feed/recent/GeoPhotoRSS
Wasn't then considering the 'direction', but since have starting recording 
it in the site, can't remember offhand if GeoRSS has support for a 
direction, or if it needs to be implemented in another way.

Also I have seen mentions of various moves to instead encode the EXIF like 
data as an XML fragment in the image, in a very similar format to RSS, so 
the GeoRSS standard might be useful there?

Hope that helps,

Barry

- www.nearby.org.uk - www.geograph.org.uk - www.trigtools.co.uk -

----- Original Message ----- 
From: "Raj Singh" <raj at rajsingh.org>
To: <georss at lists.eogeo.org>
Sent: Saturday, May 20, 2006 6:58 AM
Subject: [georss] Photographs

> This discussion got me thinking about photographs. Is anyone doing this in 
> a
> standard way? Of course it would be best to get the geographic information
> closer to the source, e.g. in the EXIF info, but getting it in the RSS
> entry/item is also a useful alternative.
>
> Over the years I've seen a few research projects in this area and the best
> way to describe this is to encode the point location of the camera, the
> direction it was pointing, and the camera's field of view. Then you can
> compute (if you know more math than I do) what the camera actually "saw".
>
> ...any flickr or mappr people on this list want to chime in???
>
> refs:
> http://mappr.com/about/#how_it_works
> http://www.flickr.com/groups/mappr/
>
> --
> Raj
>
> On 5/19/06 11:33 AM, "Jeroen Ticheler" <Jeroen.Ticheler at fao.org> wrote:
>
>> Hi,
>> Not sure if I understand this, its Friday 5:30PM so my brain is
>> shutting down for the weekend ;-)
>>
>> Anyway, I just wanted to say I think Mike's idea is interesting. I
>> see 1 problem and that is that in my GeoRSS the RSS contains an image
>> that is just a thumbnail. I would be very interested in seeing the
>> footprints of the related metadata be correctly displayed with a
>> simple (non-filled) box and than see the thumbnail when selecting a
>> BBOX. At the same time I could see another URL in the feed doing just
>> what Mike mentioned (even a simple GetMap request URL could be part
>> of the RSS and function as an image as mentioned by Mike :-) )
>>
>> Ciao,
>> Jeroen
>>
>> On May 19, 2006, at 4:15 PM, Josh at oklieb wrote:
>>
>>> Thinking about this, I can see cases for two alternatives:
>>>
>>> 1) Allow / suggest optional rss:enclosure or atom:link element(s)
>>> inside of georss:where so that the link to be associated with the
>>> location is clear. This could also be used to reference a web map
>>> context document or the map view most useful for interpreting the
>>> located content of the item / entry. This makes sense where the
>>> handler for the linked resource has to be geo-aware anyway. The
>>> atom:link element is more useful here since it includes "rel"
>>> attribute which can identify what the resource represents. It does
>>> have the complication of requiring rss and atom schemas to be
>>> referenced from georss (complicated in that normative XML Schema
>>> for these does not exist).
>>>
>>> 2) Allow / suggest georss:where or more likely georss:point /
>>> georss:box as content for  rss:enclosure or atom:link elements.
>>> This would more clearly provide an optional location for existing
>>> media references, easier for a non-geo feed processor to deal with.
>>> This does require a somewhat "non-standard" extension to rss or
>>> atom, since content for the enclosure or ink elements is undefined
>>> and extension points are only defined in atom for the feed, entry,
>>> and person elements.
>>>
>>> These are probably not exclusive alternatives, but are valuable for
>>> different situations.
>>>
>>> -Josh
>>>
>>> On May 19, 2006, at 9:04 AM, Josh at oklieb wrote:
>>>
>>>> Interesting idea. Could you provide an example of a feed using
>>>> this? People are clearly using RSS to reference a variety of media
>>>> resources (e.g. podcasts) and it would be important to support
>>>> interoperable ways of clearly associating a location to the
>>>> referenced resource so that a client can throw them on a map with
>>>> both an interpretable style and the right links.
>>>>
>>>> BTW, the tag in the georss schema is named "relationshipTag"...
>>>>
>>>> Cheers,
>>>>
>>>> Josh Lieberman
>>>>
>>>> On May 19, 2006, at 6:26 AM, Mikel Maron wrote:
>>>>
>>>>>
>>>>> Anselm Hook and I were talking here at XTech about rasters in
>>>>> GeoRSS, and came up with a use for the "relationshiptype" tag, to
>>>>> specify that a box geometry designates the bounding box of an
>>>>> image refernced in a RSS item. For example..
>>>>>
>>>>> <entry>
>>>>>   <title>Georeferenced Image</title>
>>>>>   <id>#1234</id>
>>>>>
>>>>>   <georss:where relationshiptype="image-extent">
>>>>>     <gml:Envelope>
>>>>>        <gml:lowerCorner>42.943 -71-32</gml:lowerCorner>
>>>>>        <gml:upperCorner>43.039 -69.856</gml:upperCorner>
>>>>>     </gml:Envelope>
>>>>>   </georss:where>
>>>>>  </entry>
>>>>>
>>>>> This seems like it could be pretty useful, but not something I've
>>>>> thought of before. For example, many people were sharing aerial
>>>>> images of New Orleans post-hurricane in KML. Imagine being able
>>>>> to subscribe to a feed in a disaster zone, containing polygons
>>>>> and points of affected areas, locations of aid delivery points,
>>>>> and up to date imagery.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> -Mikel
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> georss mailing list
>>>>> georss at lists.eogeo.org
>>>>> http://lists.eogeo.org/mailman/listinfo/georss
>>>>
>>>> _______________________________________________
>>>> georss mailing list
>>>> georss at lists.eogeo.org
>>>> http://lists.eogeo.org/mailman/listinfo/georss
>>>
>>> _______________________________________________
>>> georss mailing list
>>> georss at lists.eogeo.org
>>> http://lists.eogeo.org/mailman/listinfo/georss
>>
>> _______________________________________________
>> georss mailing list
>> georss at lists.eogeo.org
>> http://lists.eogeo.org/mailman/listinfo/georss
>
>
> _______________________________________________
> georss mailing list
> georss at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/georss
> 