[Geodata] Re: [georss] KML into OGC - OpenSearch for SWE

[Stefan F. Keller]

Pat, Marc, all: Great thread! I've few thoughts here:

GeoRSS fits well for purpose for geotagging. KML too but for vector data
visualization and especially for exchanging GE contexts (as Josh said).

To me most of the use cases mentioned here regarding exchanging geonames,
time and multipoints belong to some "purified GML" standard which would be
surprisingly smaller than it's predecessors?

Remains discovery (KML search): This leads to questions of
(self-)registration and (auto)discovery... and to metadata! Here, I would
separate concerns between the multiple roles of stakeholders:
1. Users
2. Data and Service providers
3. Metadata (catalog network) providers
4. Search engine and Directory providers

OpenSearch is between 4 and 1. GML and WFS are related to Data providers,
GeoRSS and KML more to Service providers (more comparison below behind the
OAI-PMH link).

But the biggest issue here is the interface between and within 3) and 4) -
and that's about pulling and pushing metadata around! It's related to the
metadata debate (c.f. also the
http://wiki.osgeo.org/index.php/Geodata_Discovery_Working_Group).


Let's take a mass market perspective and a look beyond GIS: Perhaps there
are already other best practices around? One of them was especially made for
harvesting and is now part of Google sitemaps(!): It's called OAI-PMH (
http://gis.hsr.ch/wiki/OAI-PMH).

Technically it's a small step to put some bbox inside dc:coverage and
make OAI Dublin Core (DC) attributes more machine readable and to me the
dozen DC are enough. But it seems to be the harder to reach consensus the
few(er) geometry types and object attributes must be (see also Jo Walch's
"Reading the INSPIRE metadata draft")...!

=> Now, if we reach consensus about a minimal metadata information model
before negotiation with Google KML begins OGC could propose to include this
also in OGC-KML!!

-- Stefan

Disclaimer: I've accompanied GIS standardization a dozen years ago and I'm
now involved a bit in geo-information retrieval.

2007/3/4, Pat Cappelaere <pat at cappelaere.com>:

> Marc,
>
> Great comment.  Got the same problem.  Let's envision a searchable world
> that also contains many SensorWeb Enabled Data nodes (I am kinda selfish
> here).
>
> These nodes are starting to understand and output GeoRSS (and potentially
> KML).
>
> I want to do a distributed [spatio-temporal] search query.  What are the
> options?
>
> 1) I probably could extend the WFS filter and use it in an ad-hoc
> distributed way.  But this will only be at best understood by the SWE
> nodes.
> I would be loosing the other stuff.
> 2) KML Search?
> 3) OpenSearch but how to do the geospatial query?  What about time span
> queries?
> http://www.opensearch.org
> It does return Atom/RSS so it could potentially return GeoRSS!
>
> So, has anyone considered a geospatial extension to OpenSearch?  Or has
> anyone another approach to the problem?
> Would this be something to consider under georss.org?
> Thanks,
> Pat.
>
>
> > From: Marc <marc at geonames.org>
> > Date: Sun, 04 Mar 2007 08:11:41 +0100
> > To: Carl Reed OGC Account <creed at opengeospatial.org>
> > Cc: <georss at lists.eogeo.org>
> > Subject: Re: [georss] KML into OGC
> >
> > Carl -
> >
> > I guess I should have had a look at the OGC members listing before
> > asking about other search engines. Now it is clear why you can only
> > speak for one single search engine.
> >
> > I from my side cannot be happy with this process. I want all of them to
> > sit together at a table and agree on a common format. They have managed
> > to do this for the sitemap protocol why can't they do it for geospatial
> > formats?
> > As a webmaster I don't want to become an expert in many competing
> > standards and I don't want to implement the same stuff in many formats.
> > I want my clients, my users be able to find my data with whatever search
>
> > engine they are using and I want them to be able to see and browse my
> > data with whatever geobrowsing tool they are using. This is all I want
> > and I don't care about how the markup looks like as long as I have to
> > learn and implement one and only one markup format.
> >
> > Cheers
> >
> > Marc
> >
> > Carl Reed OGC Account wrote:
> >> Marc -
> >>
> >> Thanks for the email with your questions and expression of concerns.
> >> The following are my thoughts and may not reflect what the OGC member
> >> consensus process eventually decides.
> >>
> >> In terms of geospatial search/indexing, apologies if I appeared to be
> >> endorsing a single approach. This was not my intention. I believe that
> >> there is actually quite an open field in terms of geospatial search
> >> and indexing. Some of this work is being done in standards
> >> organizations (ISO Metadata, OGC Catalogue, OASIS ebXML/RIM, IETF geo)
> >> and other work is being done in a variety of commercial and government
> >> organizations. In terms of KML, if we as a community can agree that
> >> some elements of ISO 19139 (metadata) can be incorporated into KML,
> >> then there would a much higher level of consistency with SDI best
> >> practices for geospatial Metadata (such as policy in Australia, Chile,
> >> India, most of Europe, Canada, and the US).
> >>
> >> As to the speed of the process, the OGC has been modifying our
> >> policies and procedures in order to reduce process complexity and
> >> improve "through-put" without impacting quality. Over the last two
> >> years, we have modified our P&P such that it is now possible to get a
> >> new spec through the entire process in less than a year as opposed to
> >> the 18 months it used to take. Further, for profiles of existing OGC
> >> specifications, it is possible to get the profile approved in 6 months
> >> or less. In terms of KML, the process would be the same as for any
> >> other specification moving through the consensus process - no faster
> >> for sure. At the end of the day, the speed with which a candidate
> >> specification moves through the process is based on the "will" of the
> >> membership.
> >>
> >> As to stifling innovation, interestingly enough, numerous studies have
> >> shown that standards enable innovation - even to the extent of
> >> creating competing standards and then letting the market determine the
> >> "winner". This situation has occurred numerous times in the past as
> >> well as in the current IT environment. I am not saying that this is
> >> good or bad - just a statement of fact. That said, we are sensitive to
> >> this issue and this is one reason I spend considerable time liaising
> >> with other standards organizations. As a result of these
> >> collaborations, the IETF and OASIS both now have formal GML profiles
> >> for their respective standards work that involves expressing location.
> >> In both these cases, the profiles are consistent with GeoRSS GML.
> >> There are only so many ways to express a point, linestring, and
> >> polygon in GML :-)
> >>
> >> Regards
> >>
> >> Carl
> >>
> >> ----- Original Message ----- From: "Marc" <marc at geonames.org >
> >> To: "Carl Reed OGC Account" <creed at opengeospatial.org>
> >> Cc: <georss at lists.eogeo.org >
> >> Sent: Friday, March 02, 2007 11:18 PM
> >> Subject: Re: [georss] KML into OGC
> >>
> >>
> >>> Hi Carl
> >>>
> >>> Thanks for giving us some background information about this process.
> >>> It is very much appreciated. What I am wondering is whether and how
> >>> other search engines and geobrowser vendors are involved in this and
> >>> what they say about it. You speak about spatial indexing and you
> >>> explicitly mention one single search engine. To be frank I would love
> >>> to see some competition in this field. I don't think a monopoly of a
> >>> single geospatial search engine is going to help us in the long run.
> >>> Is there any activity from other search engines and geobrowsers or
> >>> have they been completely taken by surprise and this is going to be a
> >>> single vendor standard?
> >>>
> >>> An other point I am flabbergasted about is the speed of this process.
> >>> I have the impression the OGC is in an incredible hurry to have this
> >>> thing standardized and I don't really understand why. The geospatial
> >>> web is at its very beginning and nobody can tell in which direction
> >>> it is going, what kind of new applications are going to be built on
> >>> top of it, how the information is going to be searchable, how it is
> >>> indexed and also how it will be visualized in the future. Isn't there
> >>> a risk that a premature specification may stifle innovation and we
> >>> end up with some legacy stuff?
> >>>
> >>> Cheers
> >>>
> >>> Marc
> >>>
> >>>
> >>> Carl Reed OGC Account wrote:
> >>>> Mike et. al.
> >>>> A bit on the submission by Google of KML into the OGC process.
> >>>> At the December San Diego meetings, Michael Jones, John Hanke, and
> >>>> Brian McClendon collectively spoke to the OGC Technical Committee in
> >>>> a Plenary session. One of the topics they discussed was a proposal
> >>>> to submit KML into the OGC standardization process. The next day at
> >>>> the OGC Planning Committee meeting, the PC members in attendance had
> >>>> a very open and frank discussion regarding Google's proposal. We
> >>>> covered such topics as how to best (and to what extent) KML should
> >>>> be harmonized with other OGC standards, the standardization
> >>>> timeline, intellectual property and copyright, how to make sure that
> >>>> the current (and future) KML developer community can remain engaged
> >>>> in the process without being OGC members, backwards compatibility
> >>>> issues, and so forth.
> >>>> The motion as approved by the OGC membership with endorsement by
> >>>> Google:
> >>>>
> >>>>     * KML will be submitted to the OGC by the 3 week rule for the
> >>>>       April meetings for consideration as an OGC Best Practices paper
>
> >>>>     * The new Mass-Market Geo Working Group will be the home for
> >>>>       discussions related to KML.
> >>>>     * That a new OGC public discussion list (.dev) will be started
> for
> >>>>       KML to allow coordination and engagement with the KML developer
> >>>>       community.
> >>>>     * That the OGC members will begin work on an initial, but
> limited,
> >>>>       harmonization of KML with existing OGC and ISO standards.
> Stated
> >>>>       work items include coordinate reference systems and geometry.
> >>>>       The results of this work will be a candidate specification for
> >>>>       consideration by the OGC membership for approval as an adopted
> >>>>       OpenGIS specification. (Target date: end of 2007 early 2008)
> >>>>     * Staff will work with Google and Mass Market Geo WG to
> facilitate
> >>>>       this process.
> >>>>     * There needs to be a position paper that clearly defines the
> >>>>       problem domain that GML solves and the problem domain that KML
> >>>>       solves.
> >>>>
> >>>> I am currently in the process of putting the KML reference guide
> >>>> into the OGC document format (including maintaining all links). This
> >>>> document will be posted to the OGC pending documents archive for
> >>>> discussion at the April meetings sometime next week.
> >>>> The key short term item beyond document formatting is developing the
> >>>> position paper that clearly defines the problem domain that GML
> >>>> solves and the problem domain that KML solves. I believe that there
> >>>> is a fair amount of confusion in the community as to what KML is
> >>>> best suited for and what GML is best suited for. The issue is doubly
> >>>> interesting given that the geometry elements in KML are identical to
> >>>> GML 2.1.2. We will be working on this position paper over the next
> >>>> month or so.
> >>>> Borrowing from Ron Lake and from discussions with GE staff, we think
> >>>> KML and GML are targeted at solving different problems. This has
> >>>> nothing to do with complexity vs simplicity ­ but rather just
> >>>> different objectives and requirements. KML is fundamentally focused
> >>>> on Geographic Visualization ­ meaning visualization of places on the
> >>>> earth ­ and annotating or describing places. It is not intended to
> >>>> model geographic objects. KML could even contain additional GML
> >>>> elements. KML, because it is connected to the description of place
> >>>> is also (KML Search) a means of providing spatial indexing ­ and
> >>>> this is being done through the Google robot.
> >>>> And for additional reflections on the legal aspects of this topic, I
> >>>> would suggest visiting Raj Singh's blog
> >>>> http://www.rajsingh.org/blog/?p=18 . If anyone on this list has any
> >>>> thoughts, suggestions, or concerns regarding the Google submission
> >>>> of KML into the OGC process, please let me know.
> >>>> Regards
> >>>> Carl
> >>>>
> >>>>     ----- Original Message -----
> >>>>     *From:* Mike Liebhold <mailto:mnl at well.com>
> >>>>     *To:* georss at lists.eogeo.org <mailto:georss at lists.eogeo.org>
> >>>>     *Sent:* Thursday, February 22, 2007 10:59 AM
> >>>>     *Subject:* [georss] kml reference placemarks v/ georss?
> >>>>
> >>>>
> >>>>     I'm wondering what impact on georss adoption, will be from google
> >>>>     and michael jones advocacy ( below) for using "kml reference
> >>>>     placemarks" as standard format for located geo information.
> >>>>
> >>>>     On a related point, I'd be very interested if Carl and OGC or
> >>>>     anyone else cares to comment here on the scope and implications
> of
> >>>>     google's efforts re: OGC adoption of KML
> >>>>
> >>>>     Google KML Search: What Does it Mean for Geospatial
> Professionals?
> >>>>     By Adena Schutzberg
> >>>>     <http://www.directionsmag.com/author.php?author_id=49> ,
> >>>>     Directions Magazine < http://www.directionsmag.com>
> >>>>     February 16, 2007
> >>>>
> >>>>     http://www.directionsmag.com/article.php?article_id=2409&trv=1
> >>>>
> >>>>     (DM = Directions magazine - Adena Schutzberg)
> >>>>
> >>>>     There's been a lot of coverage of Google's recent announcement
> via
> >>>>     a blog of a KML search capability from Google Earth and Google
> >>>>     Search. Michael Jones, Google's Chief Technologist for Google
> >>>>     Earth, Maps, Local answered some questions to clarify what it
> >>>>     does, how it works and explored some of its implications for
> >>>>     searching for geodata.
> >>>>
> >>>>     DM:Are all publicly accessible KML files on the Web indexed by
> >>>>     Google? Do their creators have to do something for them to be in
> >>>>     the index?
> >>>>
> >>>>     MJ: Every KML & KMZ file on the web that is found by the Google
> >>>>     web crawl is noted and indexed. The crawl honors include/exclude
> >>>>     guidance from robots.txt files and is educated by site maps to
> >>>>     find content that would otherwise be difficult to locate. Every
> >>>>     resulting KML & KMZ file found by the crawl is indexed by its
> >>>>     name, location, and by the contents of the KML description.
> >>>>     Through KML Search, all of these files are now searched by the
> >>>>     text string entered in the Google Earth search box.
> >>>>
> >>>>     Creators need only place their KML/KMZ on a publicly accessible
> >>>>     web site and their geospatial data will be universally
> >>>> discoverable.
> >>>>
> >>>>     People and program agents can also search directly using Google
> >>>>     Web Search. For example, visit www.google.com and try the
> >>>>     following search:
> >>>>
> >>>>     filetype:kmz adena
> >>>>
> >>>>     This will show you all seven (do not suppress duplicates) of the
> >>>>     KMZ files containing 'adena' in their descriptions. ;-)
> >>>>
> >>>>     DM: Does the search have a geographic part and a text part? How
> do
> >>>>     those work? Based on where you are in GE? Based on text in KML?
> >>>>
> >>>>     MJ: We show the 'best' result subset of all the results. The
> >>>>     details are subtle, but the idea is that the list of textual
> >>>>     matches is also scored geospatially to produce a conflated score
> >>>>     representing a good match. A perfect text match right where you
> >>>>     are looking is a perfect score, a great match nearby or a so-so
> >>>>     match on screen would be next, followed by great matches far away
>
> >>>>     and poor matches on-screen. Then the best 'N' of these are
> >>>>     selected and presented as the results in such a way that the
> >>>>     Google Earth client zooms in/over/out to encompass the set of
> >>>>     selected results. Users can explore these or follow the provided
> >>>>     "more..." link to get more results, which is just like going to
> >>>>     page 2, 3, and subsequent pages in Google Web search results.
> >>>>
> >>>>     DM: Might this be a way for all geo data to be found ­ both for
> >>>>     advertising needs and for the sort of geodata search folks might
> >>>>     currently do at GOS, etc? I'm thinking a small bit of KML in a
> >>>>     page could make it geosearchable in a way "local searches" are
> not
> >>>>     today.
> >>>>     Could this be the answer to the old .geo idea?
> >>>>
> >>>>     MJ: yes, Yes, YES!
> >>>>
> >>>>     You are right on target with the "small bit of KML" comment.
> >>>>
> >>>>     [Pre-KML-Search]
> >>>>
> >>>>     If you want your county's fire plug Shape file to be findable on
> >>>>     the WEB OF PAGES, you would have made an HTML reference page and
> >>>>     decorated that with text that made searchers notice it when
> >>>>     traversing your website, text that made it findable by web search
> >>>>     tools like www.google.com, and added a hyperlink on the page
> >>>>     referencing the Shape-file collection.
> >>>>
> >>>>     [Post-KML-Search]
> >>>>
> >>>>     Now, you have an additional choice. If you want your county's
> fire
> >>>>     plug Shape file to be findable on the WEB OF PLACES (using an
> >>>>     Earth browser such as Google Earth), then you make a KML
> reference
> >>>>     placemark and load it's description with text so that searchers
> >>>>     notice it when looking at the placemark (even when part of a
> >>>>     collection), find it when using tools like Google Earth Search
> >>>>     (aka KML Search), and you'd add a hyperlink in the description of
> >>>>     the placemark that references the Shape-file collection.
> >>>>
> >>>>     This simple step of creating a KML placemark (and waiting for the
> >>>>     next web crawl) is all you need to let every one of the 200+
> >>>>     million users of Google Earth who flies nearby and types "fire
> >>>>     plug" into the search box find your KML and be presented with the
> >>>>     hyperlink to the Shape file (and by extension, MapInfo TAB files,
> >>>>     Autodesk formats, NITFs, etc., all based on desired audience.)
> >>>>
> >>>>     Note that it is the author's option to also convert the
> referenced
> >>>>     data into KML too. They would do this if their goal is to have
> >>>>     those who browse, search, and explore the planet using Google
> >>>>     Earth see the results (such as the fire plug locations) right
> >>>>     there in Google Earth. This is an option, but is separate from
> >>>>     using what you correctly describe as a small bit of KML to make
> >>>>     the original data discoverable. This is the application of the
> >>>>     world's most popular search technique to the task of finding data
> >>>>     on a geospatial, view- based basis ­ addressing in many ways the
> >>>>     goals of GOS and SDI efforts both past and present.
> >>>>
> >>>>     DM: How does standard geo metadata play into such a search? I'm
> >>>>     thinking not at all now, but maybe in the future?
> >>>>
> >>>>     MJ: Everything in the KML is indexed. If the metadata are placed
> >>>>     into the KML description, then they are searchable. However, this
> >>>>     is not a smart search in the sense of "select fire plugs painted
> >>>>     more than 6 years ago", so there is much more to be done in this
> >>>>     area. You¹ll note that Google started out indexing
> page-describing
> >>>>     HTML, and then moved to index other popular document formats such
>
> >>>>     as PDF and Word¹s ³.DOC²; likewise, we¹re indexing
> >>>>     place-describing KML and may later understand a larger collection
> >>>>     of geospatial formats. If so, we¹ll be in a better position to
> >>>>     deal structurally with important metadata at that time.
> >>>>
> >>>>     DM: So this is part of Google larger search vision?
> >>>>
> >>>>     MJ: When I present a slide with the web browser on one side and
> >>>>     Google Earth and Maps on the other, and say "everything you can
> do
> >>>>     on the web of pages you will be able to do on the web of places
> >>>>     (via a browser such as Google Maps or Google Earth)", the launch
> >>>>     of KML Search is what has been on my mind as the most significant
> >>>>     move in that direction.
> >>>>
> >>>>     The Google Earth and Maps teams work to geolocate all information
>
> >>>>     and help users find that information geospatially. While users
> >>>>     need both halves, the finding part is a core Google skill and one
> >>>>     that is very useful even when what is found is not hosted at
> >>>>     Google, as is famously the case with Google Web Search. The
> launch
> >>>>     of Google KML Search initiates this Google Earth Search
> capability
> >>>>     for all of the world's spatially organizable data.
> >>>>
> >>>>
> >>>>
> >>>>
> ------------------------------------------------------------------------
> >>>>
> >>>>     _______________________________________________
> >>>>     georss mailing list
> >>>>     georss at lists.eogeo.org
> >>>>     http://lists.eogeo.org/mailman/listinfo/georss
> >>>>
> >>>>
> ------------------------------------------------------------------------
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> georss mailing list
> >>>> georss at lists.eogeo.org
> >>>> http://lists.eogeo.org/mailman/listinfo/georss
> >>>>
> >>
> >>
> > _______________________________________________
> > georss mailing list
> > georss at lists.eogeo.org
> > http://lists.eogeo.org/mailman/listinfo/georss
>
>
> _______________________________________________
> georss mailing list
> georss at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/georss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/geodata/attachments/20070305/e476a02f/attachment-0001.html