I've been slow to catch up with Microsoft's OData initiative, but saw a link to geographic OData in the blog of Michael Hausenblas: Edmonton bus stops.
It's an Atom feed with extensions, including location,
<content type="application/xml"> <m:properties> <d:PartitionKey>1000</d:PartitionKey> <d:RowKey>3b57b81c-8a36-4eb7-ac7f-31163abf1737</d:RowKey> <d:Timestamp m:type="Edm.DateTime">2010-01-14T22:43:35.7527659Z</d:Timestamp> <d:entityid m:type="Edm.Guid">b0d9924a-8875-42c4-9b1c-246e9f5c8e49</d:entityid> <d:stop_number>1000</d:stop_number> <d:street>Abbottsfield</d:street> <d:avenue>Transit Centre</d:avenue> <d:region>Edmonton</d:region> <d:latitude m:type="Edm.Double">53.57196999</d:latitude> <d:longitude m:type="Edm.Double">-113.3901687</d:longitude> <d:elevation m:type="Edm.Double">0</d:elevation> </m:properties> </content>
but the location is tied up inside an OData payload. A GeoRSS processor (such as GMaps) has no clue [map].
Pleiades is also taking an Atom-based approach to data, but does use GeoRSS. There were no bus stops back in the day, but there were bridges [map].
Comments on Michael's blog post indicate that OData is designed around "rectangular" rather than "linked" data. Atom as an envelope for tabular, CSV-like, data (like KML's extended data). Atom's content element was designed to accomodate this, but it seems clear to me that data, especially standard stuff like geographic location, is more visible outside the payload.