[georss] KML into OGC-still called "Keyhole"?
Jeff Harrison
jharrison at thecarbonproject.com
Mon Mar 5 11:14:04 EST 2007
I guess the really stupid question is - If KML goes into OGC does the "K"
still stand for "Keyhole"?
Or should it be changed to a "G" - for the "Google Markup Language" ;)
Regards,
Jeff
Jeff Harrison | CEO | The Carbon Project | www.thecarbonproject.com
-----Original Message-----
From: georss-bounces at lists.eogeo.org [mailto:georss-bounces at lists.eogeo.org]
On Behalf Of Allan Doyle
Sent: Saturday, March 03, 2007 3:53 PM
To: georss at lists.eogeo.org
Subject: Re: [georss] KML into OGC
On Mar 3, 2007, at 15:15, Jeff Harrison wrote:
> Have to agree with Marc - "I don't think a monopoly of a single
> geospatial
> search engine is going to help us in the long run,"
>
> Creating a single geospatial search engine is part of Google's stated
> business goal to make "all of the world's geographic information -
> discoverable by users worldwide." See Chikai's comment at
> http://googlemapsapi.blogspot.com/2007/02/search-for-kml-in-google-
> earth.htm
> l
Making all the world's information, geographic or not, discoverable
by users worldwide can be done with one search engine, or many times
over with many search engines.
Google seems to have a lead, but there are many search engines out
there.
<http://searchenginewatch.com/showPage.html?page=links>
If KML is open <http://earth.google.com/kml/kml_tags_21.html> then
anyone can find and index KML files.
The key for non-Google people seems to be that they don't want KML to
change in some way that compromises this ability. Thus some people
seem to be welcoming the move of working with OGC. However, we've
seen quite clearly that OGC does not always change specs for the
better. WMS 1.3 was a big step backward in many respects, with the
bad changes pretty much overshadowing the good changes. So what's to
prevent OGC from publishing KML as a best practices paper (I guess
that's the new term for what used to be a recommendation paper) and
then later resurfacing with some undesirable changes?
That's the "smoke-filled room" problem that people have cautioned
against.
>
> KML into OGC is a savvy business power play to support this objective.
I'm personally mystified why Google is willing to push KML into OGC.
They are totally new to the OGC process, they have no experience with
how the process is actually carried out within OGC, and they really
hold all the aces with respect to KML. I think this is simply an
experiment by Google.
I wonder whether they could do better with an ISO International
Workshop Agreement, based on what I've heard about it - <http://
www.iso.org/iso/en/stdsdevelopment/whowhenhow/proc/deliverables/
iwa.html>
Allan
>
> I am not saying it is right or wrong - I'm just saying it is what
> it is.
>
> Regards,
> Jeff
>
> Jeff Harrison | CEO | The Carbon Project | www.thecarbonproject.com
>
> -----Original Message-----
> From: georss-bounces at lists.eogeo.org [mailto:georss-
> bounces at lists.eogeo.org]
> On Behalf Of Carl Reed OGC Account
> Sent: Saturday, March 03, 2007 1:25 PM
> To: Marc
> Cc: georss at lists.eogeo.org
> Subject: Re: [georss] KML into OGC
>
> 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
--
Allan Doyle
+1.781.433.2695
adoyle at eogeo.org
_______________________________________________
georss mailing list
georss at lists.eogeo.org
http://lists.eogeo.org/mailman/listinfo/georss
More information about the georss
mailing list