[OpenLayers-Dev] What is right format for WKT in OpenLayers (comma white space vs. comma)?

[Tim Schaub]

On 6/9/11 2:24 AM, Noli Sicad wrote:
> Hi,
>
> I ask this question a few hours ago about why the comma white space
> format of my LINESTRING would not work  in Openlayers WKT example and
> I got the answer that my LINESTRING has wrong format i.e comma white
> space format.
>
> What is the right format?  It seems that Openlayers is not using the
> right standard format for WKT, comma white instead it only use comma
> in this example.
>
> http://dev.openlayers.org/releases/OpenLayers-2.6/examples/wkt.html
>
> This is standard WKT as result of Spatialite query. This one does not
> work in the example
>
> LINESTRING(7.120068 43.583917, 7.120154
> 43.583652, 7.120385 43.582716, 7.12039 43.582568, 7.120712 43.581511,
> 7.120873 43.580718)

The WKT parser is flexible with whitespace as long as you don't use 
multi-line strings.  The string above looks like it contains newline 
characters.

It looks like the WKT "spec" is not specific with regard to newlines (or 
tabs).  Our parser can be made more lenient with a simple change.

http://trac.osgeo.org/openlayers/attachment/ticket/3365/3365.patch

> According to Robert in Openlayers-user one should use this format i.e
> without white space.

Again, it is not whitespace in general that is the problem, it is line 
breaking characters that are the problem.

Tim

> This format.
>
> LINESTRING(7.120068 43.583917,7.120154 43.583652,7.120385
> 43.582716,7.12039 43.582568,7.120712 43.581511,7.120873 43.580718)
>
> However, according to Sandro, the author of Spatialite,  the format is
> not standard for WKT (Please see the forwarded mail below).
>
> Now, how can OpenLayers can use the standard WKT?  My WKT  i.e
> LINESTRING is not hand written it is a result of  Spatial query in
> Spatialite.
>
> Any recent example to use the Standard WKT?
>
> Regards, Noli
>
>
> ---------- Forwarded message ----------
> From: "a.furieri"<a.furieri at lqt.it>
> Date: Thu, 9 Jun 2011 00:59:40 -0700 (PDT)
> Subject: [SpatiaLite-Users] Re: Is AsText result Spatialite query the
> right format for WKT?
> To: SpatiaLite Users<spatialite-users at googlegroups.com>
>
> Hi Noli,
>
> interesting question; and a really puzzling one.
> as a general rule, any text parser I know simply
> handles any whitespace as a "token delimiter",
> thus allowing to insert an (infinitive) number
> of whitespaces at any arbitrary position.
>
> So I always assumed that "number-comma-number" and
> "number-[whitespace*]-comma-[whitespace*]-number"
> would be exactly the same.
>
> And I found this in the MySQL Spatial own documentation:
> http://dev.mysql.com/doc/refman/5.0/en/gis-wkt-format.html
> LINESTRING(0 0, 10 10, 20 25, 50 60)
> MULTIPOINT(0 0, 20 20, 60 60)
> MULTILINESTRING((10 10, 20 20), (15 15, 30 15))
>
> And on Wikipedia I found:
> http://en.wikipedia.org/wiki/Well-known_text
> LINESTRING (30 10, 10 30, 40 40)
> POLYGON ((30 10, 10 20, 20 40, 40 40, 30 10))
> MULTIPOINT (10 40, 40 30, 20 20, 30 10)
>
> This is from OsGEO documentation:
> http://www.osgeo.org/files/mapguide/docs/2.0/da/dc0/group___agf_text.htm
> MULTIPOINT XY (
>     0 0 , 1 1
> )
> POLYGON XY (
>     (1 -3, 4 -3, 4 -6, 1 -6, 1 -3),
>     (2 -4, 3 -4, 3 -5, 2 -5, 2 -4)
> )
>
> And this is what I found while reading the 'Holy Bible',
> i.e. the official OGC-SFS 1.1 spec:
> http://portal.opengeospatial.org/files/?artifact_id=13228
> 'LINESTRING( 67 13, 67 18, 59 18, 59
> 13, 67 13 )'
> 'POLYGON( ( 67 13, 67 18, 59 18, 59
> 13, 67 13) )'
> *** please note: this document in the most authoritative
> *** of them all. For sure this one is the unique *real*
> *** WKT specification, because it's the international
> *** reference standard
>
> Accordingly to all the above examples, the "comma-whitespace"
> notation absolutely seems to be a fully legitimate one.
> So I suppose the issue you are noticing simply has to be
> correctly classified as an OpenLayers own bug ;-)
>
> bye Sandro
>


-- 
Tim Schaub
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.