[OpenLayers-Dev] WKT support?

Christopher Schmidt crschmidt at metacarta.com
Mon Mar 26 07:51:20 EDT 2007


On Sun, Mar 25, 2007 at 08:38:25PM -0500, John R. Frank wrote:
> 
> Mostly out of curiousity, what, if any, support exists in the vector code
> for loading Well-Known Text?  I mean strings like this:

None at the moment. There are two reasons for this:
 * WKT is seldom used as an interchange format. Typically, for
   interchange, data is converted to GML, and GML has a seperate notion
   of how to describe geometry.

   This is actually most important, because there is no service to test
   support against. In almost every case, we've set up an example of our
   support for a particular format via a file in the examples/
   directory: if we have no service, we can't have an example/ file very
   easily, and that delays adoption into the source of OpenLayers.
   
 * The "Well-Known" part of WKT is not entirely clear to me. I have
   copied WKT from one supposed "Well-Known" text parser to another, and
   had that text break. Without a wide variety of samples -- or a
   constrained target -- WKT support could be confusing to users.  (I'd
   be glad to be told I was wrong on this, and that my description is
   wrong, and everyone uses the same WKT. Really glad. I just am not
   convinced with my limited experience.)
   
Utility functions for parsing WKT would be welcome, though. Since it
isn't a "format" per se -- it describes only geometries, not features --
they probably belong in ... hm. Perhaps Util, perhaps somewhere else?
Maybe OpenLayers.Geometry.createFromWKT() or something, a static
function in the geometry namespace. Other devs might have more opinions
on that.

> Also, tschaub:  should GeoJSON use WKT?

No, please God no :) 

 * GeoJSON is designed such that it can be dropped in a callback with
   *no parsing* and used to create feature objects in javascript.
   Parsing coordinate pairs out of long geometries for GML can
   take up to 30% of the time of working with WFS layers; GeoJSON's
   coordinate support removes this parsing time. (Up to another 30%
   can be attribute parsing: this removes that cost as well.) WKT to
   Javascript is basically unstructured content -- which is harder to
   parse. GeoJSOn is designed to fix that problem.
   
 * The above-mentioned "WKT isn't so well known" possibility still
   applies.    

Regards,
-- 
Christopher Schmidt
MetaCarta



More information about the Dev mailing list