[georss] Transport of Toponyms with GeoRSS
Carl Reed OGC Account
creed at opengeospatial.org
Thu Aug 17 21:32:02 EDT 2006
Which brings us back around to the discussions on how (or if) we should handle addresses in georss. Addresses are a very human readable form of location reference. So, as Ron points out, are meets and bounds (start at the corner of oak and main and go one block west). This is why the IETF supports both coordinates (lat-long) and civil addresses (which include placenames) in all of their new standards that deal with location - especially those for emergency services. Folks on a phone will speak in addresses. The GPS enabled phone speaks in lat-long (WGS 84 2D)
Which brings me again to the xAL example in KML. There is no reason (according to Ram Kumar, editor of xAL) that this could not be expressed in a GML or as a GML reference in other schemas, such as ATOM.
As to whether this information should be serialized as XML or RDF, that is another discussion. I will say that the internet folks dealing with location do nothing in RDF. They use either either binary (such as for DHCP) or XML (such as using GML in PIDF-LO). I only bring this up because many of the sources of location information that are beginning to permeate the net are generating XML. So what is important is the information model (as we did with the current version of GeoRSS) and then developing the serializations. Let's not put the cart before the horse.
More food for thought.
Carl
<address>
This tag can contain an unstructured address written as a standard Street, City, State address, and/or as a postal code. You can use the <address> tag to specify the location of a point instead of using latitude and longitude coordinates. For example, Google Earth can compute the position of:
<address>1600 Amphitheater Pkwy, Mountain View, CA</address>Note: This feature currently works only for U.S., Canada, and United Kingdom addresses.
Values
A string value representing the street address or postal code of the desired placemark. For example:
<address>1600 Amphitheater Pkwy, Mountain View, CA</address>Parents
a.. <Placemark>
<AddressDetails>
A structured address, formatted as xAL, or eXtensible Address Language, an international standard for address formatting. <AddressDetails> is used by KML in the Google Maps API. For details, see the Google Maps API documentation.
<?xml version="1.0" encoding="UTF-8"?><kml xmlns="http://earth.google.com/kml/2.1"> <Response> <name>95008</name> <Status> <code>200</code> <request>geocode</request> </Status> <Placemark> <address>Campbell, CA 95008, USA</address> <AddressDetails> <Country> <CountryNameCode>US</CountryNameCode> <AdministrativeArea> <AdministrativeAreaName>CA</AdministrativeAreaName>
<Locality> <LocalityName>Campbell</LocalityName> <PostalCode> <PostalCodeNumber>95008</PostalCodeNumber> </PostalCode> </Locality> </AdministrativeArea> </Country> </AddressDetails> <Point> <coordinates>-121.955390,37.280007,0</coordinates> </Point> </Placemark> </Response></kml>Values
A structured address, formatted as xAL, or eXtensible Address Language.
Parents
a.. <Placemark>
----- Original Message -----
From: "Ron Lake" <rlake at galdosinc.com>
To: "noiv" <noiv11 at gmail.com>; <georss at lists.eogeo.org>
Sent: Thursday, August 17, 2006 3:10 PM
Subject: Re: [georss] Transport of Toponyms with GeoRSS
> Hi,
>
> Coordinates provide part of the story. In many problems this means
> using more than one way to specify where something is. For some problems
> coordinates relative to the earth's surface make sense and in many
> problems that an accommodated with sufficient accuracy by a geographic
> coordinate system (lat,lon). For many other problems coordinates need
> to be specified relative to some other known/identified point. These
> might be (x,y,z) relative to some origin point (e.g. corner of a room,
> corner of a building) or they might be coordinates along something -
> like km from a road intersection. Now these can be expressed
> (sometimes) in geographic coordinates but it may not be sufficiently
> accurate, nor easy to understand. I don't tell you my house location in
> (lat,lon) not just because of accuracy issues - but also because it is
> easier to understand my postal address or that I am 2 km from the
> intersection of 11th and Folk Street.
>
> Note also that coordinates are not a safe way in many cases to identify
> something - since when you make data transformations the values of the
> coordinates are effected by computational errors. A small adjustment of
> the coordinates might in some cases "move" the point in question so that
> it is no longer inside the object of interest.
>
> These issues are handled in GML (on which geoRSS is based) by supporting
> any number of coordinate systems. Tools can then perform coordinate
> conversions as required. In a great number of circumstances, data will
> be transformed into a single coordinate system for viewing and user
> interaction - so that there is a coordinate system that means something
> in the users context. For "global" problems this is typically some kind
> of geographic system - for more local problems (think about navigating
> inside a building) other systems are more natural and easier to relate
> to.
>
> The other key element in the story, and one that is only partly
> addressed in geoRSS thus far is that of features. Features are entities
> that people relate to in a specific problem domain - so are easy to
> understand - things like bridges, buildings, restaurants and parks.
> Sometimes all we want to know is that we are "inside" or "near" to the
> feature in question - without really knowing where it is. At other
> times we are more concerned with other properties of the thing - like
> how large it is - is the road paved - what kind of food does the
> restaurant have. Since geoRSS is built on GML - once create GML features
> that represent these things that matter to us, along with their location
> (in various coordinate systems), there size and shape and other
> properties of interest.
>
> So coordinates yes - features too.
>
> Cheers
>
> R
>
> -----Original Message-----
> From: georss-bounces at lists.eogeo.org
> [mailto:georss-bounces at lists.eogeo.org] On Behalf Of noiv
> Sent: August 17, 2006 11:38 AM
> To: georss at lists.eogeo.org
> Subject: Re: [georss] Transport of Toponyms with GeoRSS
>
> I'd like to add a point from the view of a user and/or application
> designer to the discussion. Years ago coordinates have been useful for
> geographers and machines, (only). But since interactive maps pop up
> everyday, coordinates gets a meaning for end users as well.
>
> Now there are programs helping him to consult a map
> and he easily can see where in the world a given coordinate
> points to and how it belongs to himself.
>
> I would say, the coordinates in a feed have turned from a
> data element into an action element. The procedure
> or problem of position a map in way the given point
> is visible at best is now solved by programs for everybody.
>
> The question is simple: What's the text on the button starting
> this procedure?
>
> Everybody is talking about Globalization, Global Warming, etc.
> and there is a need for a method of linking a resource, a message
> or an event to a point on this planet in an end user friendly way
> And there are end users at both endings of communication.
>
> Isn't GeoRSS the most nearest concept that
> matches a solution to this challenge?
>
> If GeoRSS will not go this way, what else do you plan?
>
>
> Regards
>
> --
> Torsten Becker - ExploreOurPla.net
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.eogeo.org/pipermail/georss/attachments/20060817/99e34dbb/attachment.html
More information about the georss
mailing list