[georss] KML into OGC
Marc
marc at geonames.org
Sun Mar 4 02:11:41 EST 2007
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
>>>
>
>
More information about the georss
mailing list