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.furi...@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-us...@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.
_______________________________________________
Dev mailing list
d...@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/openlayers-dev
