Did you get a chance to talk with Erik Wilde (Berkeley) about this?
He's also very interested in gazetteer support. More below ...
On Mar 24, 2009, at 10:16 AM, Doug Nebert wrote:
> Andrew Turner wrote:
>> Hi Doug - it's amazing. There is no internet in the conference
>> location. I guess Geographers just aren't interested in the web. ;)
>> Here are the links on the proposals I put out last year:
>> http://georss.org/proposals/external_geometry >> http://georss.org/proposals/multiple_locations >> Raj also put up this proposal:
>> http://georss.org/node/31 >> The primary difference between the two is whether it's explicitly a
>> GeoRSS element, or implicit via a <link> tag.
>
> I would love to see a less-verbose solution that could be resolved
> by the right interpreter individually by coordinate at run-time, or
> perhaps resolved (sed-like) by search and replace in a viewer/parser:
>
> Case 1:
> <gml:Point>
> <gml:pos>xlink:http://webservice.org/GetGeometry?1234&georss=simple>ype=pos > </gml:pos>
> </gml:Point>
GML already has a mechanism for "remote" properties, and I don't think
the about is it. But since gml:Point is already foreign markup in
Atom, you're free to use remote properties in GML. Probably not the
most user-friendly approach.
>
>
> <georss:polygon>
> xlink:http://webservice.org/GetGeometry?50203&georss=simple>ype=poslist > </georss:polygon>
>
> Should a property on the gml:pos be added? Or would that mean going
> back to the GML schemas to make that legal? I am assuming that
> "simple" is more under the control of GeoRSS and not of the full GML
> spec, so I am inferring more latitude here.
Let's not combine the simple profile with XLink. In fact, let's not
use the simple profile at all anymore. The KML phenomenon has proven
that the simplicity of "georss simple" isn't something that developers
need. We're all capable of encoding using georss:where/gml:foo.
>
>
> Case 2:
> <georss:polygon type="GeomByID">
> xlink:http://webservice.org/GetGeometry?50203&georss=simple>ype=poslist > </georss:polygon>
>
> This could be resolved in server-side or client-side applications
> with a direct replacement of received content, rather than munging
> through multiple properties and attributes. KISS.
>
> I think I could demonstrate the first case quickly - find and
> replace all occurrences and create the 'normal' Atom feed. What
> would be more interesting in the long-run would to be able to have
> these resolved by clients at runtime. Ideally, this could be
> targeted at feeds with a polite number of resolvable locations (say
> <100) and that a brute force search and replace could be done on
> larger feeds.
>
> What do you guys think?
>
> Doug.
Your second case is not quite Atom style. Better would be
Another idea that I batted around with Andrew last year (or maybe
early) was to make a link from the feed to a KML gazetteer document,
and then have entries point to elements within that gazetteer document.
I'm playing fast and loose with the content types there, apologies.
Sean
>
>
>
>> Andrew
>> On Mon, Mar 23, 2009 at 12:05 PM, Douglas Nebert <ddnebert@... >> <mailto:ddnebert@...>> wrote:
>> I have just today been detailed to the Recovery.gov team for
>> several
>> months in order to be sure that stimulus funding projects (all
>> disbursed through fed agencies, and tracked by them) are geo-
>> enabled.
>> At present the MIS data only report address, zip, county, and
>> similar info, as you might expect from a financial reporting
>> system.
>> We don't want to burden the agencies with an extra inserting of
>> coordinates, but need to facilitate the transformation and
>> visualization.
>> Fortunately, they are expecting at least some of the reporting to
>> be
>> done by Atom, so the possibility of georss is real, where one has
>> coordinates. Since this is not the case I am thinking that maybe an
>> extension to georss is needed to provide support for a resolvable
>> place-by-id function in lieu of a coordinate that could be
>> traversed
>> to perform the substitution for visualization, or even get
>> swapped-out in a xform service.
>> So imagine, in the place of a position or list you basically
>> embed a
>> stored function with the ID to send to a resolver to send back. Or
>> you submit/filter the coded Atom feed to do all the substitutions.
>> This is a very focused form of a gazetteer or geocoder service,
>> were
>> such a standard API to exist, but one that could be prototyped very
>> rapidly.
>> Let's brainstorm this and any other simple, standards-based
>> solution.
>> Doug.
>> Cell: 703 459 5860
>> Douglas Nebert, FGDC Secretariat; t: +1 703 648 4151, f: +1 703 648
>> 5755, m: +1 703 459 5860; Sent by T-Mobile G1
>> --
>> Andrew Turner
>> mobile: 248.982.3609
>> andrew@... <mailto:andrew@...>
>> http://highearthorbit.com >> http://geocommons.com Helping build the Geospatial Web
>> Introduction to Neogeography - http://oreilly.com/catalog/ >> neogeography
>
>
> --
> Douglas D. Nebert
> Senior Advisor for Geospatial Technology, System-of-Systems Architect
> FGDC Secretariat Phone: +1 703 648 4151 Fax: +1 703 648-5755
>
The appearance of xlink:href on a property in GML means that value of
the property is found by resolving the link. This may be a URI and in
some cases a URL - i.e. it is intended as a resource reference.
This is more or less a copy of rdf:resource = " .. some URI .." from
which it was borrowed.
Cheers
Ron
-----Original Message-----
From: georss-bounces@... [mailto:georss-bounces@...] On Behalf Of Sean Gillies
Sent: March 24, 2009 9:45 AM
To: GeoRss georss@... Subject: Re: [georss] GeoRSS and implicit geometries
Doug,
Did you get a chance to talk with Erik Wilde (Berkeley) about this?
He's also very interested in gazetteer support. More below ...
On Mar 24, 2009, at 10:16 AM, Doug Nebert wrote:
> Andrew Turner wrote:
>> Hi Doug - it's amazing. There is no internet in the conference
>> location. I guess Geographers just aren't interested in the web. ;)
>> Here are the links on the proposals I put out last year:
>> http://georss.org/proposals/external_geometry >> http://georss.org/proposals/multiple_locations >> Raj also put up this proposal:
>> http://georss.org/node/31 >> The primary difference between the two is whether it's explicitly a
>> GeoRSS element, or implicit via a <link> tag.
>
> I would love to see a less-verbose solution that could be resolved
> by the right interpreter individually by coordinate at run-time, or
> perhaps resolved (sed-like) by search and replace in a viewer/parser:
>
> Case 1:
> <gml:Point>
>
GML already has a mechanism for "remote" properties, and I don't think
the about is it. But since gml:Point is already foreign markup in
Atom, you're free to use remote properties in GML. Probably not the
most user-friendly approach.
>
>
> <georss:polygon>
>
xlink:http://webservice.org/GetGeometry?50203&georss=simple>ype=poslis t
> </georss:polygon>
>
> Should a property on the gml:pos be added? Or would that mean going
> back to the GML schemas to make that legal? I am assuming that
> "simple" is more under the control of GeoRSS and not of the full GML
> spec, so I am inferring more latitude here.
Let's not combine the simple profile with XLink. In fact, let's not
use the simple profile at all anymore. The KML phenomenon has proven
that the simplicity of "georss simple" isn't something that developers
need. We're all capable of encoding using georss:where/gml:foo.
> </georss:polygon>
>
> This could be resolved in server-side or client-side applications
> with a direct replacement of received content, rather than munging
> through multiple properties and attributes. KISS.
>
> I think I could demonstrate the first case quickly - find and
> replace all occurrences and create the 'normal' Atom feed. What
> would be more interesting in the long-run would to be able to have
> these resolved by clients at runtime. Ideally, this could be
> targeted at feeds with a polite number of resolvable locations (say
> <100) and that a brute force search and replace could be done on
> larger feeds.
>
> What do you guys think?
>
> Doug.
Your second case is not quite Atom style. Better would be
Another idea that I batted around with Andrew last year (or maybe
early) was to make a link from the feed to a KML gazetteer document,
and then have entries point to elements within that gazetteer document.
I'm playing fast and loose with the content types there, apologies.
Sean
>
>
>
>> Andrew
>> On Mon, Mar 23, 2009 at 12:05 PM, Douglas Nebert <ddnebert@... >> <mailto:ddnebert@...>> wrote:
>> I have just today been detailed to the Recovery.gov team for
>> several
>> months in order to be sure that stimulus funding projects (all
>> disbursed through fed agencies, and tracked by them) are geo-
>> enabled.
>> At present the MIS data only report address, zip, county, and
>> similar info, as you might expect from a financial reporting
>> system.
>> We don't want to burden the agencies with an extra inserting of
>> coordinates, but need to facilitate the transformation and
>> visualization.
>> Fortunately, they are expecting at least some of the reporting to
>> be
>> done by Atom, so the possibility of georss is real, where one has
>> coordinates. Since this is not the case I am thinking that maybe an
>> extension to georss is needed to provide support for a resolvable
>> place-by-id function in lieu of a coordinate that could be
>> traversed
>> to perform the substitution for visualization, or even get
>> swapped-out in a xform service.
>> So imagine, in the place of a position or list you basically
>> embed a
>> stored function with the ID to send to a resolver to send back. Or
>> you submit/filter the coded Atom feed to do all the substitutions.
>> This is a very focused form of a gazetteer or geocoder service,
>> were
>> such a standard API to exist, but one that could be prototyped very
>> rapidly.
>> Let's brainstorm this and any other simple, standards-based
>> solution.
>> Doug.
>> Cell: 703 459 5860
>> Douglas Nebert, FGDC Secretariat; t: +1 703 648 4151, f: +1 703 648
>> 5755, m: +1 703 459 5860; Sent by T-Mobile G1
>> --
>> Andrew Turner
>> mobile: 248.982.3609
>> andrew@... <mailto:andrew@...>
>> http://highearthorbit.com >> http://geocommons.com Helping build the Geospatial Web
>> Introduction to Neogeography - http://oreilly.com/catalog/ >> neogeography
>
>
> --
> Douglas D. Nebert
> Senior Advisor for Geospatial Technology, System-of-Systems Architect
> FGDC Secretariat Phone: +1 703 648 4151 Fax: +1 703 648-5755
>
I know that everyone wants to invent new stuff, but there is a
gazetteer type of element already in georss 1.1:
<xs:element name="featureName" type="xs:QName">
<xs:annotation>
<xs:documentation>Additional georss property indicating
the name or identifier of the referenced geographic entity.</
xs:documentation>
</xs:annotation>
</xs:element>
This can be combined with a georss geometry element, or just used
alone. The QName type means it can reference a namespace scheme, such
as GNIS, from which additional information and positional information
could be drawn. It can be used with either Simple or GML.
xlink is not presently available in gmlgeorss, but it could be added
back for explicity referencing external geometries. The meaning of
xlink (import the contents of this link) is more to the point than
that of atom:link, which is usually a link to follow. Usage of xlink
should be reasonably clear to any application which deals with GML, in
fact most XML applications, although I don't think the action
attributes are particularly well standardized.
Josh
On Mar 24, 2009, at 12:44 PM, Sean Gillies wrote:
> Doug,
>
> Did you get a chance to talk with Erik Wilde (Berkeley) about this?
> He's also very interested in gazetteer support. More below ...
>
> On Mar 24, 2009, at 10:16 AM, Doug Nebert wrote:
>
>> Andrew Turner wrote:
>>> Hi Doug - it's amazing. There is no internet in the conference
>>> location. I guess Geographers just aren't interested in the web. ;)
>>> Here are the links on the proposals I put out last year:
>>> http://georss.org/proposals/external_geometry >>> http://georss.org/proposals/multiple_locations >>> Raj also put up this proposal:
>>> http://georss.org/node/31 >>> The primary difference between the two is whether it's explicitly a
>>> GeoRSS element, or implicit via a <link> tag.
>>
>> I would love to see a less-verbose solution that could be resolved
>> by the right interpreter individually by coordinate at run-time, or
>> perhaps resolved (sed-like) by search and replace in a viewer/parser:
>>
>> Case 1:
>> <gml:Point>
>> <gml:pos>xlink:http://webservice.org/GetGeometry?1234&georss=simple>ype=pos >> </gml:pos>
>> </gml:Point>
>
> GML already has a mechanism for "remote" properties, and I don't think
> the about is it. But since gml:Point is already foreign markup in
> Atom, you're free to use remote properties in GML. Probably not the
> most user-friendly approach.
>
>>
>>
>> <georss:polygon>
>> xlink:http://webservice.org/GetGeometry?50203&georss=simple>ype=poslist >> </georss:polygon>
>>
>> Should a property on the gml:pos be added? Or would that mean going
>> back to the GML schemas to make that legal? I am assuming that
>> "simple" is more under the control of GeoRSS and not of the full GML
>> spec, so I am inferring more latitude here.
>
> Let's not combine the simple profile with XLink. In fact, let's not
> use the simple profile at all anymore. The KML phenomenon has proven
> that the simplicity of "georss simple" isn't something that developers
> need. We're all capable of encoding using georss:where/gml:foo.
>
>>
>>
>> Case 2:
>> <georss:polygon type="GeomByID">
>> xlink:http://webservice.org/GetGeometry?50203&georss=simple>ype=poslist >> </georss:polygon>
>>
>> This could be resolved in server-side or client-side applications
>> with a direct replacement of received content, rather than munging
>> through multiple properties and attributes. KISS.
>>
>> I think I could demonstrate the first case quickly - find and
>> replace all occurrences and create the 'normal' Atom feed. What
>> would be more interesting in the long-run would to be able to have
>> these resolved by clients at runtime. Ideally, this could be
>> targeted at feeds with a polite number of resolvable locations (say
>> <100) and that a brute force search and replace could be done on
>> larger feeds.
>>
>> What do you guys think?
>>
>> Doug.
>
> Your second case is not quite Atom style. Better would be
>
> <georss:where
> type="gml"
> src="http://webservice.org/GetGeometry?50203&georss=simple>ype=poslist >>
> </georss:where>
>
> That's the same approach used for atom:content.
>
> Another idea that I batted around with Andrew last year (or maybe
> early) was to make a link from the feed to a KML gazetteer document,
> and then have entries point to elements within that gazetteer
> document.
>
> <feed ...>
> <link rel="?" href="http://example.com/gazetteer.kml"/>
> ...
>
> <entry>
> <georss:where
> type="kml"
> src="http://example.com/gazetteer.kml#placemark1 >>
> </georss:where>
> ...
>
> </feed>
>
> I'm playing fast and loose with the content types there, apologies.
>
> Sean
>
>>
>>
>>
>>> Andrew
>>> On Mon, Mar 23, 2009 at 12:05 PM, Douglas Nebert <ddnebert@... >>> <mailto:ddnebert@...>> wrote:
>>> I have just today been detailed to the Recovery.gov team for
>>> several
>>> months in order to be sure that stimulus funding projects (all
>>> disbursed through fed agencies, and tracked by them) are geo-
>>> enabled.
>>> At present the MIS data only report address, zip, county, and
>>> similar info, as you might expect from a financial reporting
>>> system.
>>> We don't want to burden the agencies with an extra inserting of
>>> coordinates, but need to facilitate the transformation and
>>> visualization.
>>> Fortunately, they are expecting at least some of the reporting to
>>> be
>>> done by Atom, so the possibility of georss is real, where one has
>>> coordinates. Since this is not the case I am thinking that maybe an
>>> extension to georss is needed to provide support for a resolvable
>>> place-by-id function in lieu of a coordinate that could be
>>> traversed
>>> to perform the substitution for visualization, or even get
>>> swapped-out in a xform service.
>>> So imagine, in the place of a position or list you basically
>>> embed a
>>> stored function with the ID to send to a resolver to send back. Or
>>> you submit/filter the coded Atom feed to do all the substitutions.
>>> This is a very focused form of a gazetteer or geocoder service,
>>> were
>>> such a standard API to exist, but one that could be prototyped very
>>> rapidly.
>>> Let's brainstorm this and any other simple, standards-based
>>> solution.
>>> Doug.
>>> Cell: 703 459 5860
>>> Douglas Nebert, FGDC Secretariat; t: +1 703 648 4151, f: +1 703 648
>>> 5755, m: +1 703 459 5860; Sent by T-Mobile G1
>>> --
>>> Andrew Turner
>>> mobile: 248.982.3609
>>> andrew@... <mailto:andrew@...>
>>> http://highearthorbit.com >>> http://geocommons.com Helping build the Geospatial Web
>>> Introduction to Neogeography - http://oreilly.com/catalog/ >>> neogeography
>>
>>
>> --
>> Douglas D. Nebert
>> Senior Advisor for Geospatial Technology, System-of-Systems Architect
>> FGDC Secretariat Phone: +1 703 648 4151 Fax: +1 703 648-5755
>>
>
> --
> Sean Gillies
> sean.gillies@... > http://sgillies.net >
> _______________________________________________
> georss mailing list
> georss@... > http://lists.eogeo.org/mailman/listinfo/georss
I know that everyone wants to invent new stuff, but there is a gazetteer type of element already in georss 1.1:
<xs:element name="featureName" type="xs:QName"> <xs:annotation> <xs:documentation>Additional georss property indicating the name or identifier of the referenced geographic entity.</ xs:documentation> </xs:annotation> </xs:element>
This can be combined with a georss geometry element, or just used alone. The QName type means it can reference a namespace scheme, such as GNIS, from which additional information and positional information could be drawn. It can be used with either Simple or GML.
xlink is not presently available in gmlgeorss, but it could be added back for
explicity referencing external geometries. The meaning of xlink (import the contents of this link) is more to the point than that of atom:link, which is usually a link to follow. Usage of xlink should be reasonably clear to any application which deals with GML, in fact most XML applications, although I don't think the action attributes are particularly well standardized.
Josh
On Mar 24, 2009, at 12:44 PM, Sean Gillies wrote:
> Doug, > > Did you get a chance to talk with Erik Wilde (Berkeley) about this? > He's also very interested in gazetteer support. More below ... > > On Mar 24, 2009, at 10:16 AM, Doug Nebert wrote: > >> Andrew Turner wrote: >>> Hi Doug - it's amazing. There is no internet in the conference >>> location. I guess Geographers just aren't interested in the web. ;) >>> Here are
the links on the proposals I put out last year:
>> </gml:pos> >> </gml:Point> > > GML already has a mechanism for "remote" properties, and I don't think > the about is it. But since gml:Point is already foreign markup in > Atom, you're free to use remote properties in GML. Probably not the > most user-friendly approach. > >> >> >> <georss:polygon>
>> </georss:polygon> >> >> Should a property on the gml:pos be added? Or would
that mean going >> back to the GML schemas to make that legal? I am assuming that >> "simple" is more under the control of GeoRSS and not of the full GML >> spec, so I am inferring more latitude here. > > Let's not combine the simple profile with XLink. In fact, let's not > use the simple profile at all anymore. The KML phenomenon has proven > that the simplicity of "georss simple" isn't something that developers > need. We're all capable of encoding using georss:where/gml:foo. > >> >> >> Case 2: >> <georss:polygon type="GeomByID"> >> xlink:http://webservice.org/GetGeometry?50203&georss=simple>ype=poslist >> </georss:polygon> >> >> This could be resolved in server-side or client-side
applications >> with a direct replacement of received content, rather than munging >> through multiple properties and attributes. KISS. >> >> I think I could demonstrate the first case quickly - find and >> replace all occurrences and create the 'normal' Atom feed. What >> would be more interesting in the long-run would to be able to have >> these resolved by clients at runtime. Ideally, this could be >> targeted at feeds with a polite number of resolvable locations (say >> <100) and that a brute force search and replace could be done on >> larger feeds. >> >> What do you guys think? >> >> Doug. > > Your second case is not quite Atom style. Better would be > > <georss:where > type="gml" > src="http://webservice.org/GetGeometry?50203&georss=simple>ype=poslist >> > </georss:where> > > That's the same approach used for atom:content. > > Another idea that I batted around with Andrew last year (or maybe > early) was to make a link from the feed to a KML gazetteer document, > and then have entries point to elements within that gazetteer > document. > > <feed ...>
>> > </georss:where> > ... > > </feed> > > I'm playing fast and loose with the content types there, apologies. > > Sean > >> >> >> >>> Andrew >>> On Mon, Mar 23, 2009 at 12:05 PM, Douglas Nebert <ddnebert@... >>> <mailto:ddnebert@...>> wrote: >>> I have just today been detailed to the Recovery.gov team for >>> several >>> months in order to be sure that stimulus funding projects
(all >>> disbursed through fed agencies, and tracked by them) are geo- >>> enabled. >>> At present the MIS data only report address, zip, county, and >>> similar info, as you might expect from a financial reporting >>> system. >>> We don't want to burden the agencies with an extra inserting of >>> coordinates, but need to facilitate the transformation and >>> visualization. >>> Fortunately, they are expecting at least some of the reporting to >>> be >>> done by Atom, so the possibility of georss is real, where one has >>> coordinates. Since this is not the case I am thinking that maybe an >>> extension to georss is needed to provide support for a resolvable >>> place-by-id function in lieu of a coordinate that could
be >>> traversed >>> to perform the substitution for visualization, or even get >>> swapped-out in a xform service. >>> So imagine, in the place of a position or list you basically >>> embed a >>> stored function with the ID to send to a resolver to send back. Or >>> you submit/filter the coded Atom feed to do all the substitutions. >>> This is a very focused form of a gazetteer or geocoder service, >>> were >>> such a standard API to exist, but one that could be prototyped very >>> rapidly. >>> Let's brainstorm this and any other simple, standards-based >>> solution. >>> Doug. >>> Cell: 703 459 5860 >>> Douglas Nebert, FGDC Secretariat; t: +1 703 648 4151, f: +1 703 648 >>>
5755, m: +1 703 459 5860; Sent by T-Mobile G1 >>> -- >>> Andrew Turner >>> mobile: 248.982.3609 >>> andrew@... <mailto:andrew@...>
I would agree with Josh's statement of not inventing something new. How much burden can be asked from a reinvestment recipient to associate a geography with the projects they get funded in terms of point/line/poly? It will be equally difficult for a project recipient to browse through gazetteers to find that location of their project to refer to as it is to geolocate the project directly.
While on this topic, a key aspect of the recovery and reinvestment act will be the accuracy of the location of projects. A congressional district or city name will not be enough to pinpoint that particular road improvement project. Any thoughts on that?
Marten
-----Original Message-----
From: georss-bounces@... [mailto:georss-bounces@...] On Behalf Of Joshua Lieberman
Sent: Tuesday, March 24, 2009 11:23 AM
To: GeoRss georss@... Cc: ddnebert@... Nebert
Subject: Re: [georss] GeoRSS and implicit geometries
I know that everyone wants to invent new stuff, but there is a
gazetteer type of element already in georss 1.1:
<xs:element name="featureName" type="xs:QName">
<xs:annotation>
<xs:documentation>Additional georss property indicating
the name or identifier of the referenced geographic entity.</
xs:documentation>
</xs:annotation>
</xs:element>
This can be combined with a georss geometry element, or just used
alone. The QName type means it can reference a namespace scheme, such
as GNIS, from which additional information and positional information
could be drawn. It can be used with either Simple or GML.
xlink is not presently available in gmlgeorss, but it could be added
back for explicity referencing external geometries. The meaning of
xlink (import the contents of this link) is more to the point than
that of atom:link, which is usually a link to follow. Usage of xlink
should be reasonably clear to any application which deals with GML, in
fact most XML applications, although I don't think the action
attributes are particularly well standardized.
Josh
On Mar 24, 2009, at 12:44 PM, Sean Gillies wrote:
> Doug,
>
> Did you get a chance to talk with Erik Wilde (Berkeley) about this?
> He's also very interested in gazetteer support. More below ...
>
> On Mar 24, 2009, at 10:16 AM, Doug Nebert wrote:
>
>> Andrew Turner wrote:
>>> Hi Doug - it's amazing. There is no internet in the conference
>>> location. I guess Geographers just aren't interested in the web. ;)
>>> Here are the links on the proposals I put out last year:
>>> http://georss.org/proposals/external_geometry >>> http://georss.org/proposals/multiple_locations >>> Raj also put up this proposal:
>>> http://georss.org/node/31 >>> The primary difference between the two is whether it's explicitly a
>>> GeoRSS element, or implicit via a <link> tag.
>>
>> I would love to see a less-verbose solution that could be resolved
>> by the right interpreter individually by coordinate at run-time, or
>> perhaps resolved (sed-like) by search and replace in a viewer/parser:
>>
>> Case 1:
>> <gml:Point>
>> <gml:pos>xlink:http://webservice.org/GetGeometry?1234&georss=simple>ype=pos >> </gml:pos>
>> </gml:Point>
>
> GML already has a mechanism for "remote" properties, and I don't think
> the about is it. But since gml:Point is already foreign markup in
> Atom, you're free to use remote properties in GML. Probably not the
> most user-friendly approach.
>
>>
>>
>> <georss:polygon>
>> xlink:http://webservice.org/GetGeometry?50203&georss=simple>ype=poslist >> </georss:polygon>
>>
>> Should a property on the gml:pos be added? Or would that mean going
>> back to the GML schemas to make that legal? I am assuming that
>> "simple" is more under the control of GeoRSS and not of the full GML
>> spec, so I am inferring more latitude here.
>
> Let's not combine the simple profile with XLink. In fact, let's not
> use the simple profile at all anymore. The KML phenomenon has proven
> that the simplicity of "georss simple" isn't something that developers
> need. We're all capable of encoding using georss:where/gml:foo.
>
>>
>>
>> Case 2:
>> <georss:polygon type="GeomByID">
>> xlink:http://webservice.org/GetGeometry?50203&georss=simple>ype=poslist >> </georss:polygon>
>>
>> This could be resolved in server-side or client-side applications
>> with a direct replacement of received content, rather than munging
>> through multiple properties and attributes. KISS.
>>
>> I think I could demonstrate the first case quickly - find and
>> replace all occurrences and create the 'normal' Atom feed. What
>> would be more interesting in the long-run would to be able to have
>> these resolved by clients at runtime. Ideally, this could be
>> targeted at feeds with a polite number of resolvable locations (say
>> <100) and that a brute force search and replace could be done on
>> larger feeds.
>>
>> What do you guys think?
>>
>> Doug.
>
> Your second case is not quite Atom style. Better would be
>
> <georss:where
> type="gml"
> src="http://webservice.org/GetGeometry?50203&georss=simple>ype=poslist >>
> </georss:where>
>
> That's the same approach used for atom:content.
>
> Another idea that I batted around with Andrew last year (or maybe
> early) was to make a link from the feed to a KML gazetteer document,
> and then have entries point to elements within that gazetteer
> document.
>
> <feed ...>
> <link rel="?" href="http://example.com/gazetteer.kml"/>
> ...
>
> <entry>
> <georss:where
> type="kml"
> src="http://example.com/gazetteer.kml#placemark1 >>
> </georss:where>
> ...
>
> </feed>
>
> I'm playing fast and loose with the content types there, apologies.
>
> Sean
>
>>
>>
>>
>>> Andrew
>>> On Mon, Mar 23, 2009 at 12:05 PM, Douglas Nebert <ddnebert@... >>> <mailto:ddnebert@...>> wrote:
>>> I have just today been detailed to the Recovery.gov team for
>>> several
>>> months in order to be sure that stimulus funding projects (all
>>> disbursed through fed agencies, and tracked by them) are geo-
>>> enabled.
>>> At present the MIS data only report address, zip, county, and
>>> similar info, as you might expect from a financial reporting
>>> system.
>>> We don't want to burden the agencies with an extra inserting of
>>> coordinates, but need to facilitate the transformation and
>>> visualization.
>>> Fortunately, they are expecting at least some of the reporting to
>>> be
>>> done by Atom, so the possibility of georss is real, where one has
>>> coordinates. Since this is not the case I am thinking that maybe an
>>> extension to georss is needed to provide support for a resolvable
>>> place-by-id function in lieu of a coordinate that could be
>>> traversed
>>> to perform the substitution for visualization, or even get
>>> swapped-out in a xform service.
>>> So imagine, in the place of a position or list you basically
>>> embed a
>>> stored function with the ID to send to a resolver to send back. Or
>>> you submit/filter the coded Atom feed to do all the substitutions.
>>> This is a very focused form of a gazetteer or geocoder service,
>>> were
>>> such a standard API to exist, but one that could be prototyped very
>>> rapidly.
>>> Let's brainstorm this and any other simple, standards-based
>>> solution.
>>> Doug.
>>> Cell: 703 459 5860
>>> Douglas Nebert, FGDC Secretariat; t: +1 703 648 4151, f: +1 703 648
>>> 5755, m: +1 703 459 5860; Sent by T-Mobile G1
>>> --
>>> Andrew Turner
>>> mobile: 248.982.3609
>>> andrew@... <mailto:andrew@...>
>>> http://highearthorbit.com >>> http://geocommons.com Helping build the Geospatial Web
>>> Introduction to Neogeography - http://oreilly.com/catalog/ >>> neogeography
>>
>>
>> --
>> Douglas D. Nebert
>> Senior Advisor for Geospatial Technology, System-of-Systems Architect
>> FGDC Secretariat Phone: +1 703 648 4151 Fax: +1 703 648-5755
>>
>
> --
> Sean Gillies
> sean.gillies@... > http://sgillies.net >
> _______________________________________________
> georss mailing list
> georss@... > http://lists.eogeo.org/mailman/listinfo/georss
Yes. Using fully explicit georss polygon geometry! But unfortunately
we have to work with the practical reality of dealing with fed. govt.
MIS departments. :(
---
Raj
On Mar 24, at 2:40 PM, Marten Hogeweg wrote:
> While on this topic, a key aspect of the recovery and reinvestment
> act will be the accuracy of the location of projects. A
> congressional district or city name will not be enough to pinpoint
> that particular road improvement project. Any thoughts on that?
>
> Marten
I too missed the 1.1 memo and didn't know about "featurename". And now
that I see it, I don't like its semantics very much.
Sean
On Mar 24, 2009, at 12:37 PM, Mikel Maron wrote:
> Excuse me if I've been out of the loop BUT GEORSS 1.1??!
>
> I don't ever recall discussion of moving 1.1, or even of these
> specific elements.
>
> What the heck is going on? I thought nothing, but apparently things
> have been moving with little discussion on the list, or proper web
> documentation.
>
> I'm all for moving forward, but it's clear we need some governance
> in place, and at least a properly working wiki.
>
> Mikel
>
> From: Joshua Lieberman <josh@...>
> To: "GeoRss georss@..." <georss@...>
> Cc: "ddnebert@... Nebert" <ddnebert@...>
> Sent: Tuesday, March 24, 2009 2:23:13 PM
> Subject: Re: [georss] GeoRSS and implicit geometries
>
> I know that everyone wants to invent new stuff, but there is a
> gazetteer type of element already in georss 1.1:
>
> <xs:element name="featureName" type="xs:QName">
> <xs:annotation>
> <xs:documentation>Additional georss property indicating
> the name or identifier of the referenced geographic entity.</
> xs:documentation>
> </xs:annotation>
> </xs:element>
>
> This can be combined with a georss geometry element, or just used
> alone. The QName type means it can reference a namespace scheme, such
> as GNIS, from which additional information and positional information
> could be drawn. It can be used with either Simple or GML.
>
> xlink is not presently available in gmlgeorss, but it could be added
> back for explicity referencing external geometries. The meaning of
> xlink (import the contents of this link) is more to the point than
> that of atom:link, which is usually a link to follow. Usage of xlink
> should be reasonably clear to any application which deals with GML, in
> fact most XML applications, although I don't think the action
> attributes are particularly well standardized.
>
> Josh
>
> On Mar 24, 2009, at 12:44 PM, Sean Gillies wrote:
>
> > Doug,
> >
> > Did you get a chance to talk with Erik Wilde (Berkeley) about this?
> > He's also very interested in gazetteer support. More below ...
> >
> > On Mar 24, 2009, at 10:16 AM, Doug Nebert wrote:
> >
> >> Andrew Turner wrote:
> >>> Hi Doug - it's amazing. There is no internet in the conference
> >>> location. I guess Geographers just aren't interested in the
> web. ;)
> >>> Here are the links on the proposals I put out last year:
> >>> http://georss.org/proposals/external_geometry > >>> http://georss.org/proposals/multiple_locations > >>> Raj also put up this proposal:
> >>> http://georss.org/node/31 > >>> The primary difference between the two is whether it's
> explicitly a
> >>> GeoRSS element, or implicit via a <link> tag.
> >>
> >> I would love to see a less-verbose solution that could be resolved
> >> by the right interpreter individually by coordinate at run-time, or
> >> perhaps resolved (sed-like) by search and replace in a viewer/
> parser:
> >>
> >> Case 1:
> >> <gml:Point>
> >> xlink:http://webservice.org/GetGeometry?
> 1234&georss=simple>ype=pos
> >> </gml:pos>
> >> </gml:Point>
> >
> > GML already has a mechanism for "remote" properties, and I don't
> think
> > the about is it. But since gml:Point is already foreign markup in
> > Atom, you're free to use remote properties in GML. Probably not the
> > most user-friendly approach.
> >
> >>
> >>
> >> <georss:polygon>
> >> xlink:http://webservice.org/GetGeometry?50203&georss=simple>ype=poslist > >> </georss:polygon>
> >>
> >> Should a property on the gml:pos be added? Or would that mean going
> >> back to the GML schemas to make that legal? I am assuming that
> >> "simple" is more under the control of GeoRSS and not of the full
> GML
> >> spec, so I am inferring more latitude here.
> >
> > Let's not combine the simple profile with XLink. In fact, let's not
> > use the simple profile at all anymore. The KML phenomenon has proven
> > that the simplicity of "georss simple" isn't something that
> developers
> > need. We're all capable of encoding using georss:where/gml:foo.
> >
> >>
> >>
> >> Case 2:
> >> <georss:polygon type="GeomByID">
> >> xlink:http://webservice.org/GetGeometry?50203&georss=simple>ype=poslist > >> </georss:polygon>
> >>
> >> This could be resolved in server-side or client-side applications
> >> with a direct replacement of received content, rather than munging
> >> through multiple properties and attributes. KISS.
> >>
> >> I think I could demonstrate the first case quickly - find and
> >> replace all occurrences and create the 'normal' Atom feed. What
> >> would be more interesting in the long-run would to be able to have
> >> these resolved by clients at runtime. Ideally, this could be
> >> targeted at feeds with a polite number of resolvable locations (say
> >> <100) and that a brute force search and replace could be done on
> >> larger feeds.
> >>
> >> What do you guys think?
> >>
> >> Doug.
> >
> > Your second case is not quite Atom style. Better would be
> >
> > <georss:where
> > type="gml"
> > src="http://webservice.org/GetGeometry?50203&georss=simple>ype=poslist > >>
> > </georss:where>
> >
> > That's the same approach used for atom:content.
> >
> > Another idea that I batted around with Andrew last year (or maybe
> > early) was to make a link from the feed to a KML gazetteer document,
> > and then have entries point to elements within that gazetteer
> > document.
> >
> > <feed ...>
> > http://example.com/gazetteer.kml"/>
> > ...
> >
> > <entry>
> > <georss:where
> > type="kml"
> > src="http://example.com/gazetteer.kml#placemark1 > >>
> > </georss:where>
> > ...
> >
> > </feed>
> >
> > I'm playing fast and loose with the content types there, apologies.
> >
> > Sean
> >
> >>
> >>
> >>
> >>> Andrew
> >>> On Mon, Mar 23, 2009 at 12:05 PM, Douglas Nebert
> <ddnebert@... > >>> <mailto:ddnebert@...>> wrote:
> >>> I have just today been detailed to the Recovery.gov team for
> >>> several
> >>> months in order to be sure that stimulus funding projects (all
> >>> disbursed through fed agencies, and tracked by them) are geo-
> >>> enabled.
> >>> At present the MIS data only report address, zip, county, and
> >>> similar info, as you might expect from a financial reporting
> >>> system.
> >>> We don't want to burden the agencies with an extra inserting of
> >>> coordinates, but need to facilitate the transformation and
> >>> visualization.
> >>> Fortunately, they are expecting at least some of the reporting to
> >>> be
> >>> done by Atom, so the possibility of georss is real, where one has
> >>> coordinates. Since this is not the case I am thinking that
> maybe an
> >>> extension to georss is needed to provide support for a resolvable
> >>> place-by-id function in lieu of a coordinate that could be
> >>> traversed
> >>> to perform the substitution for visualization, or even get
> >>> swapped-out in a xform service.
> >>> So imagine, in the place of a position or list you basically
> >>> embed a
> >>> stored function with the ID to send to a resolver to send back.
> Or
> >>> you submit/filter the coded Atom feed to do all the
> substitutions.
> >>> This is a very focused form of a gazetteer or geocoder service,
> >>> were
> >>> such a standard API to exist, but one that could be prototyped
> very
> >>> rapidly.
> >>> Let's brainstorm this and any other simple, standards-based
> >>> solution.
> >>> Doug.
> >>> Cell: 703 459 5860
> >>> Douglas Nebert, FGDC Secretariat; t: +1 703 648 4151, f: +1 703
> 648
> >>> 5755, m: +1 703 459 5860; Sent by T-Mobile G1
> >>> --
> >>> Andrew Turner
> >>> mobile: 248.982.3609
> >>> andrew@... <mailto:andrew@...>
> >>> http://highearthorbit.com > >>> http://geocommons.com Helping build the Geospatial Web
> >>> Introduction to Neogeography - http://oreilly.com/catalog/ > >>> neogeography
> >>
> >>
> >> --
> >> Douglas D. Nebert
> >> Senior Advisor for Geospatial Technology, System-of-Systems
> Architect
> >> FGDC Secretariat Phone: +1 703 648 4151 Fax: +1 703 648-5755
> >>
> >
> > --
> > Sean Gillies
> > sean.gillies@... > > http://sgillies.net > >
> > _______________________________________________
> > georss mailing list
> > georss@... > > http://lists.eogeo.org/mailman/listinfo/georss >
> _______________________________________________
> georss mailing list
> georss@... > http://lists.eogeo.org/mailman/listinfo/georss > _______________________________________________
> georss mailing list
> georss@... > http://lists.eogeo.org/mailman/listinfo/georss
It's a version of the schema which has been posted unchanged for a couple of years now, and also documented in the W3C Geo update - http://www.w3.org/2005/Incubator/geo/XGR-geo-20071023. I agree the site and docs need to be updated. In some cases the diagrams, etc seem to have regressed. More of us need to find the time for it.
Josh
On Mar 24, 2009, at 2:37 PM, Mikel Maron wrote:
Excuse me if I've been out of the loop BUT GEORSS 1.1??!
I don't ever recall discussion of moving 1.1, or even of these specific elements.
What the heck is going on? I thought nothing, but apparently things have been moving with little discussion on the list, or proper web documentation.
I'm all for moving forward, but it's clear we need some governance in place, and at least a properly working wiki.
I know that everyone wants to invent new stuff, but there is a gazetteer type of element already in georss 1.1:
<xs:element name="featureName" type="xs:QName"> <xs:annotation> <xs:documentation>Additional georss property indicating the name or identifier of the referenced geographic entity.</ xs:documentation> </xs:annotation> </xs:element>
This can be combined with a georss geometry element, or just used alone. The QName type means it can reference a namespace scheme, such as GNIS, from which additional information and positional information could be drawn. It can be used with either Simple or GML.
xlink is not presently available in gmlgeorss, but it could be added back for explicity referencing external geometries. The meaning of xlink (import the contents of this link) is more to the point than that of atom:link, which is usually a link to follow. Usage of xlink should be reasonably clear to any application which deals with GML, in fact most XML applications, although I don't think the action attributes are particularly well standardized.
Josh
On Mar 24, 2009, at 12:44 PM, Sean Gillies wrote:
> Doug, > > Did you get a chance to talk with Erik Wilde (Berkeley) about this? > He's also very interested in gazetteer support. More below ... > > On Mar 24, 2009, at 10:16 AM, Doug Nebert wrote: > >> Andrew Turner wrote: >>> Hi Doug - it's amazing. There is no internet in the conference >>> location. I guess Geographers just aren't interested in the web. ;) >>> Here are the links on the proposals I put out last year: >>>http://georss.org/proposals/external_geometry >>>http://georss.org/proposals/multiple_locations >>> Raj also put up this proposal: >>>http://georss.org/node/31 >>> The primary difference between the two is whether it's explicitly a >>> GeoRSS element, or implicit via a <link> tag. >> >> I would love to see a less-verbose solution that could be resolved >> by the right interpreter individually by coordinate at run-time, or >> perhaps resolved (sed-like) by search and replace in a viewer/parser: >> >> Case 1: >> <gml:Point> >>xlink:http://webservice.org/GetGeometry?1234&georss=simple>ype=pos >> </gml:pos> >> </gml:Point> > > GML already has a mechanism for "remote" properties, and I don't think > the about is it. But since gml:Point is already foreign markup in > Atom, you're free to use remote properties in GML. Probably not the > most user-friendly approach. > >> >> >> <georss:polygon> >> xlink:http://webservice.org/GetGeometry?50203&georss=simple>ype=poslist >> </georss:polygon> >> >> Should a property on the gml:pos be added? Or would that mean going >> back to the GML schemas to make that legal? I am assuming that >> "simple" is more under the control of GeoRSS and not of the full GML >> spec, so I am inferring more latitude here. > > Let's not combine the simple profile with XLink. In fact, let's not > use the simple profile at all anymore. The KML phenomenon has proven > that the simplicity of "georss simple" isn't something that developers > need. We're all capable of encoding using georss:where/gml:foo. > >> >> >> Case 2: >> <georss:polygon type="GeomByID"> >> xlink:http://webservice.org/GetGeometry?50203&georss=simple>ype=poslist >> </georss:polygon> >> >> This could be resolved in server-side or client-side applications >> with a direct replacement of received content, rather than munging >> through multiple properties and attributes. KISS. >> >> I think I could demonstrate the first case quickly - find and >> replace all occurrences and create the 'normal' Atom feed. What >> would be more interesting in the long-run would to be able to have >> these resolved by clients at runtime. Ideally, this could be >> targeted at feeds with a polite number of resolvable locations (say >> <100) and that a brute force search and replace could be done on >> larger feeds. >> >> What do you guys think? >> >> Doug. > > Your second case is not quite Atom style. Better would be > > <georss:where > type="gml" > src="http://webservice.org/GetGeometry?50203&georss=simple>ype=poslist >> > </georss:where> > > That's the same approach used for atom:content. > > Another idea that I batted around with Andrew last year (or maybe > early) was to make a link from the feed to a KML gazetteer document, > and then have entries point to elements within that gazetteer > document. > > <feed ...> > http://example.com/gazetteer.kml"/> > ... > > <entry> > <georss:where > type="kml" > src="http://example.com/gazetteer.kml#placemark1 >> > </georss:where> > ... > > </feed> > > I'm playing fast and loose with the content types there, apologies. > > Sean > >> >> >> >>> Andrew >>> On Mon, Mar 23, 2009 at 12:05 PM, Douglas Nebert <ddnebert@... >>> <mailto:ddnebert@...>> wrote: >>> I have just today been detailed to theRecovery.govteam for >>> several >>> months in order to be sure that stimulus funding projects (all >>> disbursed through fed agencies, and tracked by them) are geo- >>> enabled. >>> At present the MIS data only report address, zip, county, and >>> similar info, as you might expect from a financial reporting >>> system. >>> We don't want to burden the agencies with an extra inserting of >>> coordinates, but need to facilitate the transformation and >>> visualization. >>> Fortunately, they are expecting at least some of the reporting to >>> be >>> done by Atom, so the possibility of georss is real, where one has >>> coordinates. Since this is not the case I am thinking that maybe an >>> extension to georss is needed to provide support for a resolvable >>> place-by-id function in lieu of a coordinate that could be >>> traversed >>> to perform the substitution for visualization, or even get >>> swapped-out in a xform service. >>> So imagine, in the place of a position or list you basically >>> embed a >>> stored function with the ID to send to a resolver to send back. Or >>> you submit/filter the coded Atom feed to do all the substitutions. >>> This is a very focused form of a gazetteer or geocoder service, >>> were >>> such a standard API to exist, but one that could be prototyped very >>> rapidly. >>> Let's brainstorm this and any other simple, standards-based >>> solution. >>> Doug. >>> Cell: 703 459 5860 >>> Douglas Nebert, FGDC Secretariat; t: +1 703 648 4151, f: +1 703 648 >>> 5755, m: +1 703 459 5860; Sent by T-Mobile G1 >>> -- >>> Andrew Turner >>> mobile: 248.982.3609 >>>andrew@...<mailto:andrew@...> >>>http://highearthorbit.com >>>http://geocommons.com Helping build the Geospatial Web >>> Introduction to Neogeography -http://oreilly.com/catalog/ >>> neogeography >> >> >> -- >> Douglas D. Nebert >> Senior Advisor for Geospatial Technology, System-of-Systems Architect >> FGDC Secretariat Phone: +1 703 648 4151 Fax: +1 703 648-5755 >> > > -- > Sean Gillies >sean.gillies@... >http://sgillies.net > > _______________________________________________ > georss mailing list >georss@... >http://lists.eogeo.org/mailman/listinfo/georss
Not that it matters too much, but I'll just clear something up
here--there is a slight correction to the sample GML Point usage
below--xlink:href cannot be used on gml:pos, but can be used on
gml:pointProperty so the GML example would be:
As Josh already mentioned, the xlink:href attribute was dropped in
GML-GeoRSS (because gml:pointProperty was dropped).
David.
-----Original Message-----
From: georss-bounces@... [mailto:georss-bounces@...] On Behalf Of Ron Lake
Sent: March-24-09 9:53 AM
To: Sean Gillies; georss@... Subject: Re: [georss] GeoRSS and implicit geometries
Hi Sean:
In GML this would be: (id's, srsName attributes suppressed)
The appearance of xlink:href on a property in GML means that value of
the property is found by resolving the link. This may be a URI and in
some cases a URL - i.e. it is intended as a resource reference.
This is more or less a copy of rdf:resource = " .. some URI .." from
which it was borrowed.
Cheers
Ron
-----Original Message-----
From: georss-bounces@... [mailto:georss-bounces@...] On Behalf Of Sean Gillies
Sent: March 24, 2009 9:45 AM
To: GeoRss georss@... Subject: Re: [georss] GeoRSS and implicit geometries
Doug,
Did you get a chance to talk with Erik Wilde (Berkeley) about this?
He's also very interested in gazetteer support. More below ...
On Mar 24, 2009, at 10:16 AM, Doug Nebert wrote:
> Andrew Turner wrote:
>> Hi Doug - it's amazing. There is no internet in the conference
>> location. I guess Geographers just aren't interested in the web. ;)
>> Here are the links on the proposals I put out last year:
>> http://georss.org/proposals/external_geometry >> http://georss.org/proposals/multiple_locations >> Raj also put up this proposal:
>> http://georss.org/node/31 >> The primary difference between the two is whether it's explicitly a
>> GeoRSS element, or implicit via a <link> tag.
>
> I would love to see a less-verbose solution that could be resolved
> by the right interpreter individually by coordinate at run-time, or
> perhaps resolved (sed-like) by search and replace in a viewer/parser:
>
> Case 1:
> <gml:Point>
>
GML already has a mechanism for "remote" properties, and I don't think
the about is it. But since gml:Point is already foreign markup in
Atom, you're free to use remote properties in GML. Probably not the
most user-friendly approach.
>
>
> <georss:polygon>
>
xlink:http://webservice.org/GetGeometry?50203&georss=simple>ype=poslis t
> </georss:polygon>
>
> Should a property on the gml:pos be added? Or would that mean going
> back to the GML schemas to make that legal? I am assuming that
> "simple" is more under the control of GeoRSS and not of the full GML
> spec, so I am inferring more latitude here.
Let's not combine the simple profile with XLink. In fact, let's not
use the simple profile at all anymore. The KML phenomenon has proven
that the simplicity of "georss simple" isn't something that developers
need. We're all capable of encoding using georss:where/gml:foo.
> </georss:polygon>
>
> This could be resolved in server-side or client-side applications
> with a direct replacement of received content, rather than munging
> through multiple properties and attributes. KISS.
>
> I think I could demonstrate the first case quickly - find and
> replace all occurrences and create the 'normal' Atom feed. What
> would be more interesting in the long-run would to be able to have
> these resolved by clients at runtime. Ideally, this could be
> targeted at feeds with a polite number of resolvable locations (say
> <100) and that a brute force search and replace could be done on
> larger feeds.
>
> What do you guys think?
>
> Doug.
Your second case is not quite Atom style. Better would be
Another idea that I batted around with Andrew last year (or maybe
early) was to make a link from the feed to a KML gazetteer document,
and then have entries point to elements within that gazetteer document.
I'm playing fast and loose with the content types there, apologies.
Sean
>
>
>
>> Andrew
>> On Mon, Mar 23, 2009 at 12:05 PM, Douglas Nebert <ddnebert@... >> <mailto:ddnebert@...>> wrote:
>> I have just today been detailed to the Recovery.gov team for
>> several
>> months in order to be sure that stimulus funding projects (all
>> disbursed through fed agencies, and tracked by them) are geo-
>> enabled.
>> At present the MIS data only report address, zip, county, and
>> similar info, as you might expect from a financial reporting
>> system.
>> We don't want to burden the agencies with an extra inserting of
>> coordinates, but need to facilitate the transformation and
>> visualization.
>> Fortunately, they are expecting at least some of the reporting to
>> be
>> done by Atom, so the possibility of georss is real, where one has
>> coordinates. Since this is not the case I am thinking that maybe an
>> extension to georss is needed to provide support for a resolvable
>> place-by-id function in lieu of a coordinate that could be
>> traversed
>> to perform the substitution for visualization, or even get
>> swapped-out in a xform service.
>> So imagine, in the place of a position or list you basically
>> embed a
>> stored function with the ID to send to a resolver to send back. Or
>> you submit/filter the coded Atom feed to do all the substitutions.
>> This is a very focused form of a gazetteer or geocoder service,
>> were
>> such a standard API to exist, but one that could be prototyped very
>> rapidly.
>> Let's brainstorm this and any other simple, standards-based
>> solution.
>> Doug.
>> Cell: 703 459 5860
>> Douglas Nebert, FGDC Secretariat; t: +1 703 648 4151, f: +1 703 648
>> 5755, m: +1 703 459 5860; Sent by T-Mobile G1
>> --
>> Andrew Turner
>> mobile: 248.982.3609
>> andrew@... <mailto:andrew@...>
>> http://highearthorbit.com >> http://geocommons.com Helping build the Geospatial Web
>> Introduction to Neogeography - http://oreilly.com/catalog/ >> neogeography
>
>
> --
> Douglas D. Nebert
> Senior Advisor for Geospatial Technology, System-of-Systems Architect
> FGDC Secretariat Phone: +1 703 648 4151 Fax: +1 703 648-5755
>
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Sure I remember reading the results of the Incubator, and was pleased the W3C got on board the GeoRSS train .. giddy up!
But where does that Incubator report say anything about 1.1? Or anything about changes to featureName?
I don't really think including that change in a schema is sufficient way to get community concensus. (A schema, anyway, which has been in an out of date many times as we've struggled with just keeping a drupal instance up and running (can we please PLEASE move to MEDIAWIKI?!))
It's a version of the schema which has been posted unchanged for a couple of years now, and also documented in the W3C Geo update - http://www.w3.org/2005/Incubator/geo/XGR-geo-20071023. I agree the site and docs need to be updated. In some cases the diagrams, etc seem to have regressed. More of us need to find the time for
it.
Josh
On Mar 24, 2009, at 2:37 PM, Mikel Maron wrote:
Excuse me if I've been out of the loop BUT GEORSS 1.1??!
I don't ever recall discussion of moving 1.1, or even of these specific elements.
What the heck is going on? I thought nothing, but apparently things have been moving with little discussion on the list, or proper
web documentation.
I'm all for moving forward, but it's clear we need some governance in place, and at least a properly working wiki.
I know that everyone wants to invent new stuff, but there is a gazetteer type of element already in georss 1.1:
<xs:element name="featureName" type="xs:QName"> <xs:annotation> <xs:documentation>Additional georss property indicating the name or identifier of the referenced geographic entity.</ xs:documentation> </xs:annotation> </xs:element>
This can be combined with a georss geometry element, or just used alone. The QName type means it can reference a namespace scheme, such as GNIS, from which additional information and positional
information could be drawn. It can be used with either Simple or GML.
xlink is not presently available in gmlgeorss, but it could be added back for explicity referencing external geometries. The meaning of xlink (import the contents of this link) is more to the point than that of atom:link, which is usually a link to follow. Usage of xlink should be reasonably clear to any application which deals with GML, in fact most XML applications, although I don't think the action attributes are particularly well standardized.
Josh
On Mar
24, 2009, at 12:44 PM, Sean Gillies wrote:
> Doug, > > Did you get a chance to talk with Erik Wilde (Berkeley) about this? > He's also very interested in gazetteer support. More below ... > > On Mar 24, 2009, at 10:16 AM, Doug Nebert wrote: > >> Andrew Turner wrote: >>> Hi Doug - it's amazing. There is no internet in the conference >>> location. I guess Geographers just aren't interested in the web. ;) >>> Here are the links on the proposals I put out last year:
>> </gml:pos> >> </gml:Point> > > GML already has a mechanism for "remote" properties, and I don't think > the about is it. But since gml:Point is already foreign markup in > Atom, you're free to use remote properties in GML. Probably not the > most user-friendly approach. > >> >> >> <georss:polygon>
>> </georss:polygon> >> >> Should a property on the gml:pos be added? Or would that mean going >> back to the GML schemas to make that
legal? I am assuming that >> "simple" is more under the control of GeoRSS and not of the full GML >> spec, so I am inferring more latitude here. > > Let's not combine the simple profile with XLink. In fact, let's not > use the simple profile at all anymore. The KML phenomenon has proven > that the simplicity of "georss simple" isn't something that developers > need. We're all capable of encoding using georss:where/gml:foo. > >> >> >> Case 2: >> <georss:polygon type="GeomByID"> >> xlink:http://webservice.org/GetGeometry?50203&georss=simple>ype=poslist >> </georss:polygon> >> >> This could be resolved in server-side or client-side applications >> with a direct replacement of
received content, rather than munging >> through multiple properties and attributes. KISS. >> >> I think I could demonstrate the first case quickly - find and >> replace all occurrences and create the 'normal' Atom feed. What >> would be more interesting in the long-run would to be able to have >> these resolved by clients at runtime. Ideally, this could be >> targeted at feeds with a polite number of resolvable locations (say >> <100) and that a brute force search and replace could be done on >> larger feeds. >> >> What do you guys think? >> >> Doug. > > Your second case is not quite Atom style. Better would be > > <georss:where > type="gml" > src="http://webservice.org/GetGeometry?50203&georss=simple>ype=poslist >> > </georss:where> > > That's the same approach used for atom:content. > > Another idea that I batted around with Andrew last year (or maybe > early) was to make a link from the feed to a KML gazetteer document, > and then have entries point to elements within that gazetteer > document. > > <feed ...>
>> > </georss:where> > ... > > </feed> > > I'm playing fast and loose with the content types there, apologies. > > Sean > >> >> >> >>> Andrew >>> On Mon, Mar 23, 2009 at 12:05 PM, Douglas Nebert <ddnebert@... >>> <mailto:ddnebert@...>> wrote: >>> I have just today been detailed to theRecovery.govteam for >>> several >>> months in order to be sure that stimulus funding projects (all >>> disbursed through fed agencies, and tracked by them) are geo- >>> enabled. >>> At present the MIS data only report address, zip, county, and >>> similar info, as you might expect from a financial reporting >>> system. >>> We don't want to burden the agencies with an extra inserting of >>> coordinates, but need to facilitate the transformation and >>> visualization. >>> Fortunately, they are expecting at least some of the reporting to >>> be >>> done by Atom, so the possibility of georss is real, where one has >>>
coordinates. Since this is not the case I am thinking that maybe an >>> extension to georss is needed to provide support for a resolvable >>> place-by-id function in lieu of a coordinate that could be >>> traversed >>> to perform the substitution for visualization, or even get >>> swapped-out in a xform service. >>> So imagine, in the place of a position or list you basically >>> embed a >>> stored function with the ID to send to a resolver to send back. Or >>> you submit/filter the coded Atom feed to do all the substitutions. >>> This is a very focused form of a gazetteer or geocoder service, >>> were >>> such a standard API to exist, but one that could be prototyped very >>> rapidly. >>> Let's brainstorm this and any
other simple, standards-based >>> solution. >>> Doug. >>> Cell: 703 459 5860 >>> Douglas Nebert, FGDC Secretariat; t: +1 703 648 4151, f: +1 703 648 >>> 5755, m: +1 703 459 5860; Sent by T-Mobile G1 >>> -- >>> Andrew Turner >>> mobile: 248.982.3609 >>>andrew@...<mailto:andrew@...>
The 1.0 to 1.1 change was basically moving the additional attributes out of georss:where to work better with rdf and have a cleaner connection with GML, i.e. http://www.w3.org/2005/Incubator/geo/XGR-geo-20071023/#model but the diagram on georss.org just hasn't been updated.
This was all discussed extensively a long time ago. It needs to be properly documented as the point of departure for future extensions / practices / tweaks.
Regards,
Josh
On Mar 24, 2009, at 2:58 PM, Mikel Maron wrote:
Sure I remember reading the results of the Incubator, and was pleased the W3C got on board the GeoRSS train .. giddy up!
But where does that Incubator report say anything about 1.1? Or anything about changes to featureName?
I don't really think including that change in a schema is sufficient way to get community concensus. (A schema, anyway, which has been in an out of date many times as we've struggled with just keeping a drupal instance up and running (can we please PLEASE move to MEDIAWIKI?!))
It's a version of the schema which has been posted unchanged for a couple of years now, and also documented in the W3C Geo update - http://www.w3.org/2005/Incubator/geo/XGR-geo-20071023. I agree the site and docs need to be updated. In some cases the diagrams, etc seem to have regressed. More of us need to find the time for it.
Josh
On Mar 24, 2009, at 2:37 PM, Mikel Maron wrote:
Excuse me if I've been out of the loop BUT GEORSS 1.1??!
I don't ever recall discussion of moving 1.1, or even of these specific elements.
What the heck is going on? I thought nothing, but apparently things have been moving with little discussion on the list, or proper web documentation.
I'm all for moving forward, but it's clear we need some governance in place, and at least a properly working wiki.
I know that everyone wants to invent new stuff, but there is a gazetteer type of element already in georss 1.1:
<xs:element name="featureName" type="xs:QName"> <xs:annotation> <xs:documentation>Additional georss property indicating the name or identifier of the referenced geographic entity.</ xs:documentation> </xs:annotation> </xs:element>
This can be combined with a georss geometry element, or just used alone. The QName type means it can reference a namespace scheme, such as GNIS, from which additional information and positional information could be drawn. It can be used with either Simple or GML.
xlink is not presently available in gmlgeorss, but it could be added back for explicity referencing external geometries. The meaning of xlink (import the contents of this link) is more to the point than that of atom:link, which is usually a link to follow. Usage of xlink should be reasonably clear to any application which deals with GML, in fact most XML applications, although I don't think the action attributes are particularly well standardized.
Josh
On Mar 24, 2009, at 12:44 PM, Sean Gillies wrote:
> Doug, > > Did you get a chance to talk with Erik Wilde (Berkeley) about this? > He's also very interested in gazetteer support. More below ... > > On Mar 24, 2009, at 10:16 AM, Doug Nebert wrote: > >> Andrew Turner wrote: >>> Hi Doug - it's amazing. There is no internet in the conference >>> location. I guess Geographers just aren't interested in the web. ;) >>> Here are the links on the proposals I put out last year: >>>http://georss.org/proposals/external_geometry >>>http://georss.org/proposals/multiple_locations >>> Raj also put up this proposal: >>>http://georss.org/node/31 >>> The primary difference between the two is whether it's explicitly a >>> GeoRSS element, or implicit via a <link> tag. >> >> I would love to see a less-verbose solution that could be resolved >> by the right interpreter individually by coordinate at run-time, or >> perhaps resolved (sed-like) by search and replace in a viewer/parser: >> >> Case 1: >> <gml:Point> >>xlink:http://webservice.org/GetGeometry?1234&georss=simple>ype=pos >> </gml:pos> >> </gml:Point> > > GML already has a mechanism for "remote" properties, and I don't think > the about is it. But since gml:Point is already foreign markup in > Atom, you're free to use remote properties in GML. Probably not the > most user-friendly approach. > >> >> >> <georss:polygon> >> xlink:http://webservice.org/GetGeometry?50203&georss=simple>ype=poslist >> </georss:polygon> >> >> Should a property on the gml:pos be added? Or would that mean going >> back to the GML schemas to make that legal? I am assuming that >> "simple" is more under the control of GeoRSS and not of the full GML >> spec, so I am inferring more latitude here. > > Let's not combine the simple profile with XLink. In fact, let's not > use the simple profile at all anymore. The KML phenomenon has proven > that the simplicity of "georss simple" isn't something that developers > need. We're all capable of encoding using georss:where/gml:foo. > >> >> >> Case 2: >> <georss:polygon type="GeomByID"> >> xlink:http://webservice.org/GetGeometry?50203&georss=simple>ype=poslist >> </georss:polygon> >> >> This could be resolved in server-side or client-side applications >> with a direct replacement of received content, rather than munging >> through multiple properties and attributes. KISS. >> >> I think I could demonstrate the first case quickly - find and >> replace all occurrences and create the 'normal' Atom feed. What >> would be more interesting in the long-run would to be able to have >> these resolved by clients at runtime. Ideally, this could be >> targeted at feeds with a polite number of resolvable locations (say >> <100) and that a brute force search and replace could be done on >> larger feeds. >> >> What do you guys think? >> >> Doug. > > Your second case is not quite Atom style. Better would be > > <georss:where > type="gml" > src="http://webservice.org/GetGeometry?50203&georss=simple>ype=poslist >> > </georss:where> > > That's the same approach used for atom:content. > > Another idea that I batted around with Andrew last year (or maybe > early) was to make a link from the feed to a KML gazetteer document, > and then have entries point to elements within that gazetteer > document. > > <feed ...> > http://example.com/gazetteer.kml"/> > ... > > <entry> > <georss:where > type="kml" > src="http://example.com/gazetteer.kml#placemark1 >> > </georss:where> > ... > > </feed> > > I'm playing fast and loose with the content types there, apologies. > > Sean > >> >> >> >>> Andrew >>> On Mon, Mar 23, 2009 at 12:05 PM, Douglas Nebert <ddnebert@... >>> <mailto:ddnebert@...>> wrote: >>> I have just today been detailed to theRecovery.govteam for >>> several >>> months in order to be sure that stimulus funding projects (all >>> disbursed through fed agencies, and tracked by them) are geo- >>> enabled. >>> At present the MIS data only report address, zip, county, and >>> similar info, as you might expect from a financial reporting >>> system. >>> We don't want to burden the agencies with an extra inserting of >>> coordinates, but need to facilitate the transformation and >>> visualization. >>> Fortunately, they are expecting at least some of the reporting to >>> be >>> done by Atom, so the possibility of georss is real, where one has >>> coordinates. Since this is not the case I am thinking that maybe an >>> extension to georss is needed to provide support for a resolvable >>> place-by-id function in lieu of a coordinate that could be >>> traversed >>> to perform the substitution for visualization, or even get >>> swapped-out in a xform service. >>> So imagine, in the place of a position or list you basically >>> embed a >>> stored function with the ID to send to a resolver to send back. Or >>> you submit/filter the coded Atom feed to do all the substitutions. >>> This is a very focused form of a gazetteer or geocoder service, >>> were >>> such a standard API to exist, but one that could be prototyped very >>> rapidly. >>> Let's brainstorm this and any other simple, standards-based >>> solution. >>> Doug. >>> Cell: 703 459 5860 >>> Douglas Nebert, FGDC Secretariat; t: +1 703 648 4151, f: +1 703 648 >>> 5755, m: +1 703 459 5860; Sent by T-Mobile G1 >>> -- >>> Andrew Turner >>> mobile: 248.982.3609 >>>andrew@...<mailto:andrew@...> >>>http://highearthorbit.com >>>http://geocommons.com Helping build the Geospatial Web >>> Introduction to Neogeography -http://oreilly.com/catalog/ >>> neogeography >> >> >> -- >> Douglas D. Nebert >> Senior Advisor for Geospatial Technology, System-of-Systems Architect >> FGDC Secretariat Phone: +1 703 648 4151 Fax: +1 703 648-5755 >> > > -- > Sean Gillies >sean.gillies@... >http://sgillies.net > > _______________________________________________ > georss mailing list >georss@... >http://lists.eogeo.org/mailman/listinfo/georss
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Where was this discussed? I don't recall it. It seems reasonable, sure .. but I also don't know how we, as a community, authorize version changes.
I agree uppercase is totally obnoxious, but I just feel broadsided by this. The underlying, most importants point of community discussion and consensus, and proper documentation steps, have not addressed.
This was all discussed extensively a long time ago. It needs to be properly documented as the point of departure for future extensions / practices / tweaks.
Regards,
Josh
On Mar 24, 2009, at 2:58 PM, Mikel Maron wrote:
Sure I remember reading the results of the Incubator, and was pleased the W3C got on board the GeoRSS train .. giddy up!
But where does that Incubator report say anything about 1.1? Or anything about changes to featureName?
I don't really think including that change in a schema is sufficient way to get community concensus. (A schema, anyway, which has been in an out of date many times as we've struggled with just keeping a
drupal instance up and running (can we please PLEASE move to MEDIAWIKI?!))
It's a version of the schema which has been posted unchanged for a couple of years now, and also
documented in the W3C Geo update - http://www.w3.org/2005/Incubator/geo/XGR-geo-20071023. I agree the site and docs need to be updated. In some cases the diagrams, etc seem to have regressed. More of us need to find the time for it.
Josh
On Mar 24, 2009, at 2:37 PM, Mikel Maron wrote:
Excuse me if I've been out of the loop BUT GEORSS 1.1??!
I don't ever recall discussion of moving 1.1, or even of these specific elements.
What the heck is going on? I thought nothing, but apparently things have been moving with little discussion on the list, or proper web documentation.
I'm all for moving forward, but it's clear we need some governance in place, and at least a properly working wiki.
I know that everyone wants to invent new stuff, but there is a gazetteer type of element already in georss 1.1:
<xs:element name="featureName" type="xs:QName"> <xs:annotation> <xs:documentation>Additional georss property indicating the name or identifier of the referenced geographic entity.</ xs:documentation> </xs:annotation> </xs:element>
This can be combined with a georss geometry element, or just used alone. The QName type means it can reference a namespace scheme, such as GNIS, from which additional information and positional information could be drawn. It can be used with either Simple or GML.
xlink is not presently available in gmlgeorss, but it could be added back for explicity referencing external geometries. The meaning of xlink (import the contents of this link) is more to the point than that of atom:link, which is usually a link to follow. Usage of xlink should be reasonably clear to any application which deals with GML, in fact most XML applications, although I don't think the action attributes are particularly well standardized.
Josh
On Mar 24, 2009, at 12:44 PM, Sean Gillies wrote:
> Doug, > > Did you get a chance to talk with Erik Wilde (Berkeley) about this? > He's also very interested in gazetteer support. More below ... > > On Mar 24, 2009, at 10:16 AM, Doug Nebert wrote: > >> Andrew Turner wrote: >>> Hi Doug - it's amazing. There is no internet in the conference >>> location. I guess Geographers just aren't
interested in the web. ;) >>> Here are the links on the proposals I put out last year:
>> </gml:pos> >> </gml:Point> > > GML already has a mechanism for "remote" properties, and I don't think > the about is it. But since gml:Point is already foreign markup in > Atom, you're free to use remote properties in GML. Probably not the > most user-friendly approach. > >> >> >>
<georss:polygon>
>> </georss:polygon> >> >> Should a property on the gml:pos be added? Or would that mean going >> back to the GML schemas to make that legal? I am assuming that >> "simple" is more under the control of GeoRSS and not of the full GML >> spec, so I am inferring more latitude here. > > Let's not combine the simple profile with XLink. In fact, let's not > use the simple profile at all anymore. The KML phenomenon has proven > that the simplicity of "georss simple" isn't something that developers > need. We're all capable of encoding using georss:where/gml:foo. > >> >> >> Case 2: >>
<georss:polygon type="GeomByID"> >> xlink:http://webservice.org/GetGeometry?50203&georss=simple>ype=poslist >> </georss:polygon> >> >> This could be resolved in server-side or client-side applications >> with a direct replacement of received content, rather than munging >> through multiple properties and attributes. KISS. >> >> I think I could demonstrate the first case quickly - find and >> replace all occurrences and create the 'normal' Atom feed. What >> would be more interesting in the long-run would to be able to have >> these resolved by clients at runtime. Ideally, this could be >> targeted at feeds with a polite number of resolvable locations (say >> <100) and that a brute force search
and replace could be done on >> larger feeds. >> >> What do you guys think? >> >> Doug. > > Your second case is not quite Atom style. Better would be > > <georss:where > type="gml" > src="http://webservice.org/GetGeometry?50203&georss=simple>ype=poslist >> > </georss:where> > > That's the same approach used for atom:content. > > Another idea that I batted around with Andrew last year (or maybe > early) was to make a link from the feed to a KML gazetteer document, > and then have entries point to elements within that gazetteer > document. > > <feed
...>
>> > </georss:where> > ... > > </feed> > > I'm playing fast and loose with the content types there, apologies. > > Sean > >> >> >> >>> Andrew >>> On Mon, Mar 23, 2009 at 12:05 PM, Douglas Nebert <ddnebert@... >>> <mailto:ddnebert@...>> wrote: >>> I have just today been detailed to theRecovery.govteam for >>> several >>> months in order to be sure that stimulus funding projects (all >>> disbursed through fed agencies, and tracked by them) are geo- >>> enabled. >>> At present the MIS data only report address, zip, county, and >>> similar info, as you might expect from a financial reporting >>> system. >>> We don't want to
burden the agencies with an extra inserting of >>> coordinates, but need to facilitate the transformation and >>> visualization. >>> Fortunately, they are expecting at least some of the reporting to >>> be >>> done by Atom, so the possibility of georss is real, where one has >>> coordinates. Since this is not the case I am thinking that maybe an >>> extension to georss is needed to provide support for a resolvable >>> place-by-id function in lieu of a coordinate that could be >>> traversed >>> to perform the substitution for visualization, or even get >>> swapped-out in a xform service. >>> So imagine, in the place of a position or list you basically >>> embed a >>> stored function with the ID to send to a resolver to send
back. Or >>> you submit/filter the coded Atom feed to do all the substitutions. >>> This is a very focused form of a gazetteer or geocoder service, >>> were >>> such a standard API to exist, but one that could be prototyped very >>> rapidly. >>> Let's brainstorm this and any other simple, standards-based >>> solution. >>> Doug. >>> Cell: 703 459 5860 >>> Douglas Nebert, FGDC Secretariat; t: +1 703 648 4151, f: +1 703 648 >>> 5755, m: +1 703 459 5860; Sent by T-Mobile G1 >>> -- >>> Andrew Turner >>> mobile: 248.982.3609 >>>andrew@...<mailto:andrew@...>
as a newcomer to geoRSS, I have to agree to the remark that was made in an earlier thread that the georss.org site is confusing. For someone like me, who just needs to find the necesarry spec information to be able to write a webapp that consumes georss output from a catalog server and parse that to WFS, it is actually pretty useless. Many non-working links, confusing and contradictory information and no clear index or menu structure.
As an example, I have been trying to find out if there is a (.xsd) Schema for geoRSS Simple, and if so, what is the current version and where to find it. To no avail... Or is it just my wrong impression that georss.org is the place for this? Should I be looking in W3C or OGC sites? But also there I could not find a clear overview of the state of geoRSS things.
--
Barend Köbben
International Institute for Geo-information Sciences and Earth Observation (ITC)
PO Box 6, 7500AA Enschede (The Netherlands)
ph: +31-(0)534874253
International Institute for
Geo-Information Science and Earth Observation (ITC) Chamber of Commerce: 410 27 560
E-mail disclaimer
The information in this e-mail, including any attachments, is
intended for the addressee only. If you are not the intended recipient, you are
hereby notified that any disclosure, copying, distribution or action in relation
to the content of this information is strictly prohibited. If you have received
this e-mail by mistake, please delete the message and any attachment and inform
the sender by return e-mail. ITC accepts no liability for any error or omission
in the message content or for damage of any kind that may arise as a result of
e-mail transmission.
Going forward...it would be great to do some work reconstituting both the community and the website. Unfortunately, as Raj notes, it is rather a full week and a half. I'll see if there is any way I can make it down to DC Mon or Tues, but don't wait beer on my account.
I'll put in a small plug, that the OGC TC will be in Boston in June and Raj, Allan, and I (and others) would love to host some associated / spatiotemporally correlated get-togethers for anyone who could make it up here then.
Josh
On Mar 24, 2009, at 3:49 PM, Mikel Maron wrote:
Where was this discussed? I don't recall it. It seems reasonable, sure .. but I also don't know how we, as a community, authorize version changes.
I agree uppercase is totally obnoxious, but I just feel broadsided by this. The underlying, most importants point of community discussion and consensus, and proper documentation steps, have not addressed.
This was all discussed extensively a long time ago. It needs to be properly documented as the point of departure for future extensions / practices / tweaks.
Regards,
Josh
On Mar 24, 2009, at 2:58 PM, Mikel Maron wrote:
Sure I remember reading the results of the Incubator, and was pleased the W3C got on board the GeoRSS train .. giddy up!
But where does that Incubator report say anything about 1.1? Or anything about changes to featureName?
I don't really think including that change in a schema is sufficient way to get community concensus. (A schema, anyway, which has been in an out of date many times as we've struggled with just keeping a drupal instance up and running (can we please PLEASE move to MEDIAWIKI?!))
It's a version of the schema which has been posted unchanged for a couple of years now, and also documented in the W3C Geo update - http://www.w3.org/2005/Incubator/geo/XGR-geo-20071023. I agree the site and docs need to be updated. In some cases the diagrams, etc seem to have regressed. More of us need to find the time for it.
Josh
On Mar 24, 2009, at 2:37 PM, Mikel Maron wrote:
Excuse me if I've been out of the loop BUT GEORSS 1.1??!
I don't ever recall discussion of moving 1.1, or even of these specific elements.
What the heck is going on? I thought nothing, but apparently things have been moving with little discussion on the list, or proper web documentation.
I'm all for moving forward, but it's clear we need some governance in place, and at least a properly working wiki.
I know that everyone wants to invent new stuff, but there is a gazetteer type of element already in georss 1.1:
<xs:element name="featureName" type="xs:QName"> <xs:annotation> <xs:documentation>Additional georss property indicating the name or identifier of the referenced geographic entity.</ xs:documentation> </xs:annotation> </xs:element>
This can be combined with a georss geometry element, or just used alone. The QName type means it can reference a namespace scheme, such as GNIS, from which additional information and positional information could be drawn. It can be used with either Simple or GML.
xlink is not presently available in gmlgeorss, but it could be added back for explicity referencing external geometries. The meaning of xlink (import the contents of this link) is more to the point than that of atom:link, which is usually a link to follow. Usage of xlink should be reasonably clear to any application which deals with GML, in fact most XML applications, although I don't think the action attributes are particularly well standardized.
Josh
On Mar 24, 2009, at 12:44 PM, Sean Gillies wrote:
> Doug, > > Did you get a chance to talk with Erik Wilde (Berkeley) about this? > He's also very interested in gazetteer support. More below ... > > On Mar 24, 2009, at 10:16 AM, Doug Nebert wrote: > >> Andrew Turner wrote: >>> Hi Doug - it's amazing. There is no internet in the conference >>> location. I guess Geographers just aren't interested in the web. ;) >>> Here are the links on the proposals I put out last year: >>>http://georss.org/proposals/external_geometry >>>http://georss.org/proposals/multiple_locations >>> Raj also put up this proposal: >>>http://georss.org/node/31 >>> The primary difference between the two is whether it's explicitly a >>> GeoRSS element, or implicit via a <link> tag. >> >> I would love to see a less-verbose solution that could be resolved >> by the right interpreter individually by coordinate at run-time, or >> perhaps resolved (sed-like) by search and replace in a viewer/parser: >> >> Case 1: >> <gml:Point> >>xlink:http://webservice.org/GetGeometry?1234&georss=simple>ype=pos >> </gml:pos> >> </gml:Point> > > GML already has a mechanism for "remote" properties, and I don't think > the about is it. But since gml:Point is already foreign markup in > Atom, you're free to use remote properties in GML. Probably not the > most user-friendly approach. > >> >> >> <georss:polygon> >> xlink:http://webservice.org/GetGeometry?50203&georss=simple>ype=poslist >> </georss:polygon> >> >> Should a property on the gml:pos be added? Or would that mean going >> back to the GML schemas to make that legal? I am assuming that >> "simple" is more under the control of GeoRSS and not of the full GML >> spec, so I am inferring more latitude here. > > Let's not combine the simple profile with XLink. In fact, let's not > use the simple profile at all anymore. The KML phenomenon has proven > that the simplicity of "georss simple" isn't something that developers > need. We're all capable of encoding using georss:where/gml:foo. > >> >> >> Case 2: >> <georss:polygon type="GeomByID"> >> xlink:http://webservice.org/GetGeometry?50203&georss=simple>ype=poslist >> </georss:polygon> >> >> This could be resolved in server-side or client-side applications >> with a direct replacement of received content, rather than munging >> through multiple properties and attributes. KISS. >> >> I think I could demonstrate the first case quickly - find and >> replace all occurrences and create the 'normal' Atom feed. What >> would be more interesting in the long-run would to be able to have >> these resolved by clients at runtime. Ideally, this could be >> targeted at feeds with a polite number of resolvable locations (say >> <100) and that a brute force search and replace could be done on >> larger feeds. >> >> What do you guys think? >> >> Doug. > > Your second case is not quite Atom style. Better would be > > <georss:where > type="gml" > src="http://webservice.org/GetGeometry?50203&georss=simple>ype=poslist >> > </georss:where> > > That's the same approach used for atom:content. > > Another idea that I batted around with Andrew last year (or maybe > early) was to make a link from the feed to a KML gazetteer document, > and then have entries point to elements within that gazetteer > document. > > <feed ...> > http://example.com/gazetteer.kml"/> > ... > > <entry> > <georss:where > type="kml" > src="http://example.com/gazetteer.kml#placemark1 >> > </georss:where> > ... > > </feed> > > I'm playing fast and loose with the content types there, apologies. > > Sean > >> >> >> >>> Andrew >>> On Mon, Mar 23, 2009 at 12:05 PM, Douglas Nebert <ddnebert@... >>> <mailto:ddnebert@...>> wrote: >>> I have just today been detailed to theRecovery.govteam for >>> several >>> months in order to be sure that stimulus funding projects (all >>> disbursed through fed agencies, and tracked by them) are geo- >>> enabled. >>> At present the MIS data only report address, zip, county, and >>> similar info, as you might expect from a financial reporting >>> system. >>> We don't want to burden the agencies with an extra inserting of >>> coordinates, but need to facilitate the transformation and >>> visualization. >>> Fortunately, they are expecting at least some of the reporting to >>> be >>> done by Atom, so the possibility of georss is real, where one has >>> coordinates. Since this is not the case I am thinking that maybe an >>> extension to georss is needed to provide support for a resolvable >>> place-by-id function in lieu of a coordinate that could be >>> traversed >>> to perform the substitution for visualization, or even get >>> swapped-out in a xform service. >>> So imagine, in the place of a position or list you basically >>> embed a >>> stored function with the ID to send to a resolver to send back. Or >>> you submit/filter the coded Atom feed to do all the substitutions. >>> This is a very focused form of a gazetteer or geocoder service, >>> were >>> such a standard API to exist, but one that could be prototyped very >>> rapidly. >>> Let's brainstorm this and any other simple, standards-based >>> solution. >>> Doug. >>> Cell: 703 459 5860 >>> Douglas Nebert, FGDC Secretariat; t: +1 703 648 4151, f: +1 703 648 >>> 5755, m: +1 703 459 5860; Sent by T-Mobile G1 >>> -- >>> Andrew Turner >>> mobile: 248.982.3609 >>>andrew@...<mailto:andrew@...> >>>http://highearthorbit.com >>>http://geocommons.com Helping build the Geospatial Web >>> Introduction to Neogeography -http://oreilly.com/catalog/ >>> neogeography >> >> >> -- >> Douglas D. Nebert >> Senior Advisor for Geospatial Technology, System-of-Systems Architect >> FGDC Secretariat Phone: +1 703 648 4151 Fax: +1 703 648-5755 >> > > -- > Sean Gillies >sean.gillies@... >http://sgillies.net > > _______________________________________________ > georss mailing list >georss@... >http://lists.eogeo.org/mailman/listinfo/georss
On Mar 24, at 4:44 PM, Chris Beaudette wrote:
> The GeoRSS schema allows for adding srsName and srsDimension to
> either the geometry element (e.g., gml:Point) or to the gml:pos
> element.
>
> QUESTIONS:
> - If it’s included in both gml:Point and gml:pos, does one
> override the other?
The one "closest" to the geometry wins, so the srsName attribute on
<gml:pos> would apply to <gml:pos>'s child geometry element.
> - Under what conditions would it make sense to use srs*
> with gml:pos rather than at the geometry level?
If you had multiple <gml:pos>es with different srses. This case only
comes up in complex GML, and doesn't apply to GeoRSS GML since we
restrict it to one geometry element.
_______________________________________________
georss mailing list
georss@... http://lists.eogeo.org/mailman/listinfo/georss
Schemalocation links need to be fixed. As does the website.
On Mar 24, 2009, at 3:55 PM, Barend Köbben wrote:
Hi,
as a newcomer to geoRSS, I have to agree to the remark that was made in an earlier thread that the georss.org site is confusing. For someone like me, who just needs to find the necesarry spec information to be able to write a webapp that consumes georss output from a catalog server and parse that to WFS, it is actually pretty useless. Many non-working links, confusing and contradictory information and no clear index or menu structure.
As an example, I have been trying to find out if there is a (.xsd) Schema for geoRSS Simple, and if so, what is the current version and where to find it. To no avail... Or is it just my wrong impression that georss.org is the place for this? Should I be looking in W3C or OGC sites? But also there I could not find a clear overview of the state of geoRSS things.
--
Barend Köbben
International Institute for Geo-information Sciences and Earth Observation (ITC)
PO Box 6, 7500AA Enschede (The Netherlands)
ph: +31-(0)534874253
International Institute for Geo-Information Science and Earth Observation (ITC) Chamber of Commerce: 410 27 560
E-mail disclaimer The information in this e-mail, including any attachments, is intended for the addressee only. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or action in relation to the content of this information is strictly prohibited. If you have received this e-mail by mistake, please delete the message and any attachment and inform the sender by return e-mail. ITC accepts no liability for any error or omission in the message content or for damage of any kind that may arise as a result of e-mail transmission.
_______________________________________________ georss mailing list georss@... http://lists.eogeo.org/mailman/listinfo/georss
I'm totally confused. A gml:pointProperty should contain a gml:Point,
not the other way around. You appear to be right, though, that GeoRSS
doesn't include any part of GML which allows xlink attributes, since
georss:where is already a geometric property. Have to use another
approach for remote geometries. I suppose we should just add xlink
attributes to georss:where. It is probably the cleanest approach. Just
have to constrain it to clearly be a remote link to the same
geometries which could be included locally.
Josh
On Mar 24, 2009, at 2:52 PM, David Burggraf wrote:
> Not that it matters too much, but I'll just clear something up
> here--there is a slight correction to the sample GML Point usage
> below--xlink:href cannot be used on gml:pos, but can be used on
> gml:pointProperty so the GML example would be:
>
> <gml:Point>
> <gml:pointProperty xlink:href =
> "http://...etc... "/>
> </gml:Point>
>
> As Josh already mentioned, the xlink:href attribute was dropped in
> GML-GeoRSS (because gml:pointProperty was dropped).
>
> David.
>
> -----Original Message-----
> From: georss-bounces@... > [mailto:georss-bounces@...] On Behalf Of Ron Lake
> Sent: March-24-09 9:53 AM
> To: Sean Gillies; georss@... > Subject: Re: [georss] GeoRSS and implicit geometries
>
> Hi Sean:
>
> In GML this would be: (id's, srsName attributes suppressed)
>
> <gml:Point>
> <gml:pos xlink:href =
> "http://webservice.org/GetGeometry?1234&georss=simple>ype=pos"/>
> </gml:Point>
>
> The Polygon case would be similar:
>
> The appearance of xlink:href on a property in GML means that value of
> the property is found by resolving the link. This may be a URI and in
> some cases a URL - i.e. it is intended as a resource reference.
>
> This is more or less a copy of rdf:resource = " .. some URI .." from
> which it was borrowed.
>
> Cheers
>
> Ron
>
>
> -----Original Message-----
> From: georss-bounces@... > [mailto:georss-bounces@...] On Behalf Of Sean Gillies
> Sent: March 24, 2009 9:45 AM
> To: GeoRss georss@... > Subject: Re: [georss] GeoRSS and implicit geometries
>
> Doug,
>
> Did you get a chance to talk with Erik Wilde (Berkeley) about this?
> He's also very interested in gazetteer support. More below ...
>
> On Mar 24, 2009, at 10:16 AM, Doug Nebert wrote:
>
>> Andrew Turner wrote:
>>> Hi Doug - it's amazing. There is no internet in the conference
>>> location. I guess Geographers just aren't interested in the web. ;)
>>> Here are the links on the proposals I put out last year:
>>> http://georss.org/proposals/external_geometry >>> http://georss.org/proposals/multiple_locations >>> Raj also put up this proposal:
>>> http://georss.org/node/31 >>> The primary difference between the two is whether it's explicitly a
>>> GeoRSS element, or implicit via a <link> tag.
>>
>> I would love to see a less-verbose solution that could be resolved
>> by the right interpreter individually by coordinate at run-time, or
>> perhaps resolved (sed-like) by search and replace in a viewer/parser:
>>
>> Case 1:
>> <gml:Point>
>>
> <gml:pos>xlink:http://webservice.org/GetGeometry?1234&georss=simple>yp > e=pos
>> </gml:pos>
>> </gml:Point>
>
> GML already has a mechanism for "remote" properties, and I don't think
> the about is it. But since gml:Point is already foreign markup in
> Atom, you're free to use remote properties in GML. Probably not the
> most user-friendly approach.
>
>>
>>
>> <georss:polygon>
>>
> xlink:http://webservice.org/GetGeometry?50203&georss=simple>ype=poslis > t
>> </georss:polygon>
>>
>> Should a property on the gml:pos be added? Or would that mean going
>> back to the GML schemas to make that legal? I am assuming that
>> "simple" is more under the control of GeoRSS and not of the full GML
>> spec, so I am inferring more latitude here.
>
> Let's not combine the simple profile with XLink. In fact, let's not
> use the simple profile at all anymore. The KML phenomenon has proven
> that the simplicity of "georss simple" isn't something that developers
> need. We're all capable of encoding using georss:where/gml:foo.
>
>>
>>
>> Case 2:
>> <georss:polygon type="GeomByID">
>>
> xlink:http://webservice.org/GetGeometry?50203&georss=simple>ype=poslis > t
>> </georss:polygon>
>>
>> This could be resolved in server-side or client-side applications
>> with a direct replacement of received content, rather than munging
>> through multiple properties and attributes. KISS.
>>
>> I think I could demonstrate the first case quickly - find and
>> replace all occurrences and create the 'normal' Atom feed. What
>> would be more interesting in the long-run would to be able to have
>> these resolved by clients at runtime. Ideally, this could be
>> targeted at feeds with a polite number of resolvable locations (say
>> <100) and that a brute force search and replace could be done on
>> larger feeds.
>>
>> What do you guys think?
>>
>> Doug.
>
> Your second case is not quite Atom style. Better would be
>
> <georss:where
> type="gml"
>
> src="http://webservice.org/GetGeometry?50203&georss=simple>ype=poslist >>
> </georss:where>
>
> That's the same approach used for atom:content.
>
> Another idea that I batted around with Andrew last year (or maybe
> early) was to make a link from the feed to a KML gazetteer document,
> and then have entries point to elements within that gazetteer
> document.
>
> <feed ...>
> <link rel="?" href="http://example.com/gazetteer.kml"/>
> ...
>
> <entry>
> <georss:where
> type="kml"
> src="http://example.com/gazetteer.kml#placemark1 >>
> </georss:where>
> ...
>
> </feed>
>
> I'm playing fast and loose with the content types there, apologies.
>
> Sean
>
>>
>>
>>
>>> Andrew
>>> On Mon, Mar 23, 2009 at 12:05 PM, Douglas Nebert <ddnebert@... >>> <mailto:ddnebert@...>> wrote:
>>> I have just today been detailed to the Recovery.gov team for
>>> several
>>> months in order to be sure that stimulus funding projects (all
>>> disbursed through fed agencies, and tracked by them) are geo-
>>> enabled.
>>> At present the MIS data only report address, zip, county, and
>>> similar info, as you might expect from a financial reporting
>>> system.
>>> We don't want to burden the agencies with an extra inserting of
>>> coordinates, but need to facilitate the transformation and
>>> visualization.
>>> Fortunately, they are expecting at least some of the reporting to
>>> be
>>> done by Atom, so the possibility of georss is real, where one has
>>> coordinates. Since this is not the case I am thinking that maybe an
>>> extension to georss is needed to provide support for a resolvable
>>> place-by-id function in lieu of a coordinate that could be
>>> traversed
>>> to perform the substitution for visualization, or even get
>>> swapped-out in a xform service.
>>> So imagine, in the place of a position or list you basically
>>> embed a
>>> stored function with the ID to send to a resolver to send back. Or
>>> you submit/filter the coded Atom feed to do all the substitutions.
>>> This is a very focused form of a gazetteer or geocoder service,
>>> were
>>> such a standard API to exist, but one that could be prototyped very
>>> rapidly.
>>> Let's brainstorm this and any other simple, standards-based
>>> solution.
>>> Doug.
>>> Cell: 703 459 5860
>>> Douglas Nebert, FGDC Secretariat; t: +1 703 648 4151, f: +1 703 648
>>> 5755, m: +1 703 459 5860; Sent by T-Mobile G1
>>> --
>>> Andrew Turner
>>> mobile: 248.982.3609
>>> andrew@... <mailto:andrew@...>
>>> http://highearthorbit.com >>> http://geocommons.com Helping build the Geospatial Web
>>> Introduction to Neogeography - http://oreilly.com/catalog/ >>> neogeography
>>
>>
>> --
>> Douglas D. Nebert
>> Senior Advisor for Geospatial Technology, System-of-Systems Architect
>> FGDC Secretariat Phone: +1 703 648 4151 Fax: +1 703 648-5755
>>
>
> --
> Sean Gillies
> sean.gillies@... > http://sgillies.net >
> _______________________________________________
> georss mailing list
> georss@... > http://lists.eogeo.org/mailman/listinfo/georss > _______________________________________________
> georss mailing list
> georss@... > http://lists.eogeo.org/mailman/listinfo/georss > _______________________________________________
> georss mailing list
> georss@... > http://lists.eogeo.org/mailman/listinfo/georss
Sorry for the confusion, especially since I was trying to clear things
up :-) You are right that a gml:pointProperty should contain a gml:Point
or reference one using xlink:href. The example I gave should have been
applied to other geometries such as gml:LineString and gml:LinearRing:
As you noted, by following the GML pattern, the xlink:href should be
placed on the element (property) containing the geometry, i.e. the where
element.
David
-----Original Message-----
From: Joshua Lieberman [mailto:josh@...]
Sent: March-24-09 8:02 PM
To: David Burggraf
Cc: Ron Lake; Sean Gillies; georss@... Subject: Re: [georss] GeoRSS and implicit geometries
Dave,
I'm totally confused. A gml:pointProperty should contain a gml:Point,
not the other way around. You appear to be right, though, that GeoRSS
doesn't include any part of GML which allows xlink attributes, since
georss:where is already a geometric property. Have to use another
approach for remote geometries. I suppose we should just add xlink
attributes to georss:where. It is probably the cleanest approach. Just
have to constrain it to clearly be a remote link to the same
geometries which could be included locally.
Josh
On Mar 24, 2009, at 2:52 PM, David Burggraf wrote:
> Not that it matters too much, but I'll just clear something up
> here--there is a slight correction to the sample GML Point usage
> below--xlink:href cannot be used on gml:pos, but can be used on
> gml:pointProperty so the GML example would be:
>
> <gml:Point>
> <gml:pointProperty xlink:href =
> "http://...etc... "/>
> </gml:Point>
>
> As Josh already mentioned, the xlink:href attribute was dropped in
> GML-GeoRSS (because gml:pointProperty was dropped).
>
> David.
>
> -----Original Message-----
> From: georss-bounces@... > [mailto:georss-bounces@...] On Behalf Of Ron Lake
> Sent: March-24-09 9:53 AM
> To: Sean Gillies; georss@... > Subject: Re: [georss] GeoRSS and implicit geometries
>
> Hi Sean:
>
> In GML this would be: (id's, srsName attributes suppressed)
>
> <gml:Point>
> <gml:pos xlink:href =
> "http://webservice.org/GetGeometry?1234&georss=simple>ype=pos"/>
> </gml:Point>
>
> The Polygon case would be similar:
>
> The appearance of xlink:href on a property in GML means that value of
> the property is found by resolving the link. This may be a URI and in
> some cases a URL - i.e. it is intended as a resource reference.
>
> This is more or less a copy of rdf:resource = " .. some URI .." from
> which it was borrowed.
>
> Cheers
>
> Ron
>
>
> -----Original Message-----
> From: georss-bounces@... > [mailto:georss-bounces@...] On Behalf Of Sean Gillies
> Sent: March 24, 2009 9:45 AM
> To: GeoRss georss@... > Subject: Re: [georss] GeoRSS and implicit geometries
>
> Doug,
>
> Did you get a chance to talk with Erik Wilde (Berkeley) about this?
> He's also very interested in gazetteer support. More below ...
>
> On Mar 24, 2009, at 10:16 AM, Doug Nebert wrote:
>
>> Andrew Turner wrote:
>>> Hi Doug - it's amazing. There is no internet in the conference
>>> location. I guess Geographers just aren't interested in the web. ;)
>>> Here are the links on the proposals I put out last year:
>>> http://georss.org/proposals/external_geometry >>> http://georss.org/proposals/multiple_locations >>> Raj also put up this proposal:
>>> http://georss.org/node/31 >>> The primary difference between the two is whether it's explicitly a
>>> GeoRSS element, or implicit via a <link> tag.
>>
>> I would love to see a less-verbose solution that could be resolved
>> by the right interpreter individually by coordinate at run-time, or
>> perhaps resolved (sed-like) by search and replace in a viewer/parser:
>>
>> Case 1:
>> <gml:Point>
>>
>
> e=pos
>> </gml:pos>
>> </gml:Point>
>
> GML already has a mechanism for "remote" properties, and I don't think
> the about is it. But since gml:Point is already foreign markup in
> Atom, you're free to use remote properties in GML. Probably not the
> most user-friendly approach.
>
>>
>>
>> <georss:polygon>
>>
>
> t
>> </georss:polygon>
>>
>> Should a property on the gml:pos be added? Or would that mean going
>> back to the GML schemas to make that legal? I am assuming that
>> "simple" is more under the control of GeoRSS and not of the full GML
>> spec, so I am inferring more latitude here.
>
> Let's not combine the simple profile with XLink. In fact, let's not
> use the simple profile at all anymore. The KML phenomenon has proven
> that the simplicity of "georss simple" isn't something that developers
> need. We're all capable of encoding using georss:where/gml:foo.
>
>>
>>
>> Case 2:
>> <georss:polygon type="GeomByID">
>>
>
> t
>> </georss:polygon>
>>
>> This could be resolved in server-side or client-side applications
>> with a direct replacement of received content, rather than munging
>> through multiple properties and attributes. KISS.
>>
>> I think I could demonstrate the first case quickly - find and
>> replace all occurrences and create the 'normal' Atom feed. What
>> would be more interesting in the long-run would to be able to have
>> these resolved by clients at runtime. Ideally, this could be
>> targeted at feeds with a polite number of resolvable locations (say
>> <100) and that a brute force search and replace could be done on
>> larger feeds.
>>
>> What do you guys think?
>>
>> Doug.
>
> Your second case is not quite Atom style. Better would be
>
> <georss:where
> type="gml"
>
>
>>
> </georss:where>
>
> That's the same approach used for atom:content.
>
> Another idea that I batted around with Andrew last year (or maybe
> early) was to make a link from the feed to a KML gazetteer document,
> and then have entries point to elements within that gazetteer
> document.
>
> <feed ...>
> <link rel="?" href="http://example.com/gazetteer.kml"/>
> ...
>
> <entry>
> <georss:where
> type="kml"
> src="http://example.com/gazetteer.kml#placemark1 >>
> </georss:where>
> ...
>
> </feed>
>
> I'm playing fast and loose with the content types there, apologies.
>
> Sean
>
>>
>>
>>
>>> Andrew
>>> On Mon, Mar 23, 2009 at 12:05 PM, Douglas Nebert <ddnebert@... >>> <mailto:ddnebert@...>> wrote:
>>> I have just today been detailed to the Recovery.gov team for
>>> several
>>> months in order to be sure that stimulus funding projects (all
>>> disbursed through fed agencies, and tracked by them) are geo-
>>> enabled.
>>> At present the MIS data only report address, zip, county, and
>>> similar info, as you might expect from a financial reporting
>>> system.
>>> We don't want to burden the agencies with an extra inserting of
>>> coordinates, but need to facilitate the transformation and
>>> visualization.
>>> Fortunately, they are expecting at least some of the reporting to
>>> be
>>> done by Atom, so the possibility of georss is real, where one has
>>> coordinates. Since this is not the case I am thinking that maybe an
>>> extension to georss is needed to provide support for a resolvable
>>> place-by-id function in lieu of a coordinate that could be
>>> traversed
>>> to perform the substitution for visualization, or even get
>>> swapped-out in a xform service.
>>> So imagine, in the place of a position or list you basically
>>> embed a
>>> stored function with the ID to send to a resolver to send back. Or
>>> you submit/filter the coded Atom feed to do all the substitutions.
>>> This is a very focused form of a gazetteer or geocoder service,
>>> were
>>> such a standard API to exist, but one that could be prototyped very
>>> rapidly.
>>> Let's brainstorm this and any other simple, standards-based
>>> solution.
>>> Doug.
>>> Cell: 703 459 5860
>>> Douglas Nebert, FGDC Secretariat; t: +1 703 648 4151, f: +1 703 648
>>> 5755, m: +1 703 459 5860; Sent by T-Mobile G1
>>> --
>>> Andrew Turner
>>> mobile: 248.982.3609
>>> andrew@... <mailto:andrew@...>
>>> http://highearthorbit.com >>> http://geocommons.com Helping build the Geospatial Web
>>> Introduction to Neogeography - http://oreilly.com/catalog/ >>> neogeography
>>
>>
>> --
>> Douglas D. Nebert
>> Senior Advisor for Geospatial Technology, System-of-Systems Architect
>> FGDC Secretariat Phone: +1 703 648 4151 Fax: +1 703 648-5755
>>
>
> --
> Sean Gillies
> sean.gillies@... > http://sgillies.net >
> _______________________________________________
> georss mailing list
> georss@... > http://lists.eogeo.org/mailman/listinfo/georss > _______________________________________________
> georss mailing list
> georss@... > http://lists.eogeo.org/mailman/listinfo/georss > _______________________________________________
> georss mailing list
> georss@... > http://lists.eogeo.org/mailman/listinfo/georss
Going forward...it would be great to do some work reconstituting both the community and the website. Unfortunately, as Raj notes, it is rather a full week and a half. I'll see if there is any way I can make it down to DC Mon or Tues, but don't wait beer on my account.
I'll put in a small plug, that the OGC TC will be in Boston in June and Raj, Allan, and I (and others) would love to host some associated / spatiotemporally correlated get-togethers for anyone who could make it up here then.
Josh
On Mar 24, 2009, at 3:49 PM, Mikel Maron wrote:
Where was this discussed? I don't recall it. It seems reasonable, sure .. but I also don't know how we, as a community, authorize version changes.
I agree uppercase is totally obnoxious, but I just feel broadsided by this. The underlying, most importants point of community discussion and consensus, and proper documentation steps, have not addressed.
This was all discussed extensively a long time ago. It needs to be properly documented as the point of departure for future extensions / practices / tweaks.
Regards,
Josh
On Mar 24, 2009, at 2:58 PM, Mikel Maron wrote:
Sure I remember reading the results of the Incubator, and was pleased the W3C got on board the GeoRSS train .. giddy up!
But where does that Incubator report say anything about 1.1? Or anything about changes to featureName?
I don't really think including that change in a schema is sufficient way to get community concensus. (A schema, anyway, which has been in an out of date many times as we've struggled with just keeping a drupal instance up and running (can we please PLEASE move to MEDIAWIKI?!))
It's a version of the schema which has been posted unchanged for a couple of years now, and also documented in the W3C Geo update - http://www.w3.org/2005/Incubator/geo/XGR-geo-20071023. I agree the site and docs need
to be updated. In some cases the diagrams, etc seem to have regressed. More of us need to find the time for it.
Josh
On Mar 24, 2009, at 2:37 PM, Mikel Maron wrote:
Excuse me if I've been out of the loop BUT GEORSS 1.1??!
I don't ever recall
discussion of moving 1.1, or even of these specific elements.
What the heck is going on? I thought nothing, but apparently things have been moving with little discussion on the list, or proper web documentation.
I'm all for moving forward, but it's clear we need some governance in place, and at least a properly working wiki.
I know that everyone wants to invent new stuff, but there is a gazetteer type of element already in georss 1.1:
<xs:element name="featureName" type="xs:QName"> <xs:annotation> <xs:documentation>Additional georss property indicating the name or identifier of the referenced geographic entity.</ xs:documentation> </xs:annotation> </xs:element>
This can be combined with a georss geometry element, or just used alone. The QName type means it can reference a namespace scheme, such as GNIS, from which additional information and positional information could be drawn. It can be used with either Simple or GML.
xlink is not presently available in gmlgeorss, but it could be added back for explicity referencing external geometries. The meaning of xlink (import the contents of this link) is more to the point than that of atom:link, which is usually a link to follow. Usage of xlink should be reasonably clear to any application which deals with GML, in fact most XML applications, although I don't think the action attributes are particularly well standardized.
Josh
On Mar 24, 2009, at 12:44 PM, Sean Gillies wrote:
> Doug, > > Did you get a chance to talk with Erik Wilde (Berkeley) about this? > He's also very interested in gazetteer support. More below ... > > On Mar 24, 2009, at 10:16 AM, Doug Nebert wrote: > >> Andrew Turner wrote: >>> Hi Doug - it's amazing. There is no internet in the conference >>> location. I guess Geographers just aren't interested in the web. ;) >>> Here are the links on the proposals I put out last year:
>> </gml:pos> >> </gml:Point> > > GML already has a mechanism for "remote" properties, and I don't think > the about is it. But since gml:Point is already foreign markup in > Atom, you're free to use remote properties in GML. Probably not the > most user-friendly approach. > >> >> >> <georss:polygon>
>> </georss:polygon> >> >> Should a property on the gml:pos be added? Or would that mean going >> back to the GML schemas to make that legal? I am assuming that >> "simple" is more under the control of GeoRSS and not of the full GML >> spec, so I am inferring more latitude here. > > Let's not combine the simple profile with XLink. In fact, let's not > use the simple profile at all anymore. The KML phenomenon has proven > that the simplicity of "georss simple" isn't something that developers > need. We're all capable of encoding using georss:where/gml:foo. > >> >> >> Case 2: >> <georss:polygon type="GeomByID"> >> xlink:http://webservice.org/GetGeometry?50203&georss=simple>ype=poslist >> </georss:polygon> >> >> This could be resolved in server-side or client-side applications >> with a direct replacement of received content, rather than munging >> through multiple properties and attributes. KISS. >> >> I think I could demonstrate the first case quickly - find and >> replace all occurrences and create the 'normal' Atom feed. What >> would be more interesting in the long-run would to be able to have >> these resolved by clients at runtime. Ideally, this could be >> targeted at feeds with a polite number of resolvable locations (say >> <100) and that a brute force search and replace could be done on >> larger
feeds. >> >> What do you guys think? >> >> Doug. > > Your second case is not quite Atom style. Better would be > > <georss:where > type="gml" > src="http://webservice.org/GetGeometry?50203&georss=simple>ype=poslist >> > </georss:where> > > That's the same approach used for atom:content. > > Another idea that I batted around with Andrew last year (or maybe > early) was to make a link from the feed to a KML gazetteer document, > and then have entries point to elements within that gazetteer > document. > > <feed ...>
>> > </georss:where> > ... > > </feed> > > I'm playing fast and loose with the content types there, apologies. > > Sean > >> >> >> >>> Andrew >>> On Mon, Mar 23, 2009 at 12:05 PM, Douglas Nebert <ddnebert@... >>> <mailto:ddnebert@...>> wrote: >>> I have just today been detailed to theRecovery.govteam for >>> several >>> months in order to be sure that stimulus funding projects (all >>> disbursed through fed agencies, and tracked by them) are geo- >>> enabled. >>> At present the MIS data only report address, zip, county, and >>> similar info, as you might expect from a financial reporting >>> system. >>> We don't want to burden the agencies with an extra
inserting of >>> coordinates, but need to facilitate the transformation and >>> visualization. >>> Fortunately, they are expecting at least some of the reporting to >>> be >>> done by Atom, so the possibility of georss is real, where one has >>> coordinates. Since this is not the case I am thinking that maybe an >>> extension to georss is needed to provide support for a resolvable >>> place-by-id function in lieu of a coordinate that could be >>> traversed >>> to perform the substitution for visualization, or even get >>> swapped-out in a xform service. >>> So imagine, in the place of a position or list you basically >>> embed a >>> stored function with the ID to send to a resolver to send back. Or >>> you
submit/filter the coded Atom feed to do all the substitutions. >>> This is a very focused form of a gazetteer or geocoder service, >>> were >>> such a standard API to exist, but one that could be prototyped very >>> rapidly. >>> Let's brainstorm this and any other simple, standards-based >>> solution. >>> Doug. >>> Cell: 703 459 5860 >>> Douglas Nebert, FGDC Secretariat; t: +1 703 648 4151, f: +1 703 648 >>> 5755, m: +1 703 459 5860; Sent by T-Mobile G1 >>> -- >>> Andrew Turner >>> mobile: 248.982.3609 >>>andrew@...<mailto:andrew@...>
Some parts of this message have been removed.
Learn more about Nabble's security policy.
