[georss] KML into OGC-still called "Keyhole"?
Jeff Harrison
jharrison at thecarbonproject.com
Mon Mar 5 14:30:06 EST 2007
Seriously now. As a long-term member of the open-geospatial community I
think it's not appropriate for an individual vendor's name to be integrated
in the Title of an open specification or a recommendation for technology
that could become an open specification.
Regards,
Jeff
Jeff Harrison | CEO | The Carbon Project | www.thecarbonproject.com
-----Original Message-----
From: Joshua Lieberman [mailto:josh at oklieb.net]
Sent: Monday, March 05, 2007 11:47 AM
To: Jeff Harrison
Cc: georss at lists.eogeo.org
Subject: Re: [georss] KML into OGC-still called "Keyhole"?
Jeff,
WKML - world's knowledge markup language...
--Josh
On Mar 5, 2007, at 11:14 AM, Jeff Harrison wrote:
> 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
>
> _______________________________________________
> georss mailing list
> georss at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/georss
More information about the georss
mailing list