[georss] KML into OGC-still called "Keyhole"?
Allan Doyle
allan.doyle at gmail.com
Mon Mar 5 14:50:05 EST 2007
On Mar 5, 2007, at 14:30, Jeff Harrison wrote:
> 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.
You mean like "OpenGIS® Simple Features Implementation Specification
for OLE/COM" which I suspect you voted for as TC rep for USATEC? :)
Ok, so it wasn't named "OpenGIS® Simple Features Implementation
Specification for Microsoft" but it might as well have been.
Why deny history? If it started out as Keyhole, there's nothing wrong
with that.
Allan
>
> 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
>
> _______________________________________________
> georss mailing list
> georss at lists.eogeo.org
> http://lists.eogeo.org/mailman/listinfo/georss
--
Allan Doyle
allan.doyle at gmail.com
http://think.random-stuff.org/
More information about the georss
mailing list