[georss] KML into OGC - OpenSearch for SWE

Pat Cappelaere pat at cappelaere.com
Sun Mar 4 09:47:21 EST 2007


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





More information about the georss mailing list