KML ... OGC compatible or monopoly format?
The news is there, and although it was more than a year ago that the kml format was considered a standard ... the moment it is approved generates much criticism about Google's intentions to monopolize a format that has very well positioned. That now it is said that kml is in the OGC Standards, generated different opinions.
The good
The standards are good; if they did not exist, interoperability between the different technological tools, mainly commercial ones, could not be sustained. The object of Open Gis Consortium (OGC) is to systematize spatial data standards that allow the creation of exchange protocols under documented schemas, such as entity definitions, relationships, and data dictionaries.
Looking at the list of technologies that several of their products have under the slogan "ogc standards" we see that the effort has been very well supported, including AutoDesk, ESRI, Bentley, Intergraph, Leica, Oracle, CadCorp, Mapinfo, Manifold... among others. others included Microsoft just last year. This table reflects the categories for which there are OGC standards, including KML, which would be an XML geolocation data standard.
Until now it has been difficult to interact with a kml without having to import it (kml to dxf), and to date Google has not wanted to give its Google Earth capacity to open directly a .shp or a .dxf; the fact that the kml is standard could suppose that these things could change because it is assured that the evolution that has taken place will not obey the crazy criterion of Google and the creativity of the geospatial industry and the community in general will come into play.
So it is not bad, that Google releases its kml format and it is good that it does so under the "open" model, because in this way sustainability can be guaranteed to those who invest in developments. This implies the ease of creating applications without having to import or transform data, and although it seems very theoretical, the "open" criterion, apart from being collaborative, seeks neutrality, benefiting everyone without registering the formats with a particular program... except Google, of course. .
The bad
The problem is that this approval of the format by the OGC arrives at a sensitive moment in the big markets of technologies; And we refer precisely to the moment when Microsoft could not buy Yahoo! who has decided to flirt with Google.
Microsoft beats Google in desktop tools, Google beats everyone in Internet dominance, Yahoo! beats both in online advertising. Microsoft bets on captive licenses, Google tries to promote the use of "its" free applications, Yahoo! it dies every second. Virtual Earth is every day more attractive, Google Earth has more coverage, Yahoo maps ...
These slight conjunctures are the ones that raise doubts if Google tries to release the kml to the public, not because it is giving something to the world but because it wants everyone to work in a format that it has already managed to position ... similar when Microsoft offered .NET for anyone who wanted to develop desktop applications, ensuring compatibility with style of leading us to tremendous levels of suffering and seeking to overshadow Java. Also, a large part of the geospatial community has underestimated the potential of kml due to its limited capabilities, because although we admit that Google Earth and Google Maps have admirable achievements, kml does nothing more than show fucking locations, because the principle was ese: geographic simplicity over xml and always with a web focus. But the developments of the great desktop tools have not concerned more than importing and exporting the kml because of that crazy Google habit of nailing us their API at any place.
) GC Standards - The ugly
... and this may free the possibility of developing developments that connect to Google Maps data without having to go through its API? To date, if you want to do something you have to locate a Google executive, tell him what you want to do, what you want to show, how the data would look ... and then expect to be given conditions of the maximum resolution level to show, where you must put the Google logo and of course, the obligation to buy a Google Earth Enterprise Client at the price they can think of or in the extreme case mount a Google Earth Pro On the server conditioned to its whims.
While we applaud that the open alternative is being supported by well-positioned technologies, as is the case of Google and the thousands of domains that have developed over its API, we remember that not long ago MySQL, which received great collaboration from the community, a Day was bought by SUN for the modest sum of One billion dollars. And of that those who helped to solve the bugs of each version have not seen a penny.
At the Baltimore conference, I can already imagine the speech of Mark Reichardt, CEO of OGC who will give a plenary called: “The vision of the OGC“, and in which they will surely offer an altar to Google. Where will this novel end?
Agree. Thanks for the answer that seems very successful. That Google submits the kml to the standard would give it more stability with regard to capricious changes.
Hello,
Let's not mix merras churras, one thing is that Google has a map service on which they make a big business, and another thing very different is that OGC has given the accolade to the format in which Google transfers much of its information geographical area.
Let me explain: when defining KML as a standard, we make sure that it will be documented, then how we use it is very different. Google recently released a implementation free of a library to work with KML (which will be as good as Google wanted it to be, but that's another war). In gvSIG there is already support for KML without using this library and work is being done to improve it because it is a viable alternative to transmit information in a more or less simple format (which does not mean that it is intended to support GML 3.2, much more powerful and probably sized for other uses). Being able to bring to gvSIG a KML published by anyone, make analysis with it and generate another KML to publish it where you want (without going through the services of Google obviously) is really interesting right?
In short, we must not confuse Google's way of doing business with the definition of standards. Personally I think it's good that KML is standard because at least we make sure that we all use the same format.
All the best