It'd be useful to have support for (OpenLayers?)WKT input format.
This would allow exposing as WFS the data which is edited using OpenLayers CCK.

Is there a plan for that ?
I've heard one plan is for spatial_tools to implement an OL-based widget for GEO, anything on the WFS side ?

CommentFileSizeAuthor
#13 gml2.patch11.07 KBstrk
#12 gml2.patch11.11 KBstrk
#9 wkt2gml.tgz3.89 KBstrk
#7 logWKTParsingLimit.patch579 bytesstrk

Comments

tmcw’s picture

tmcw commented

The WFS module already has support for a subset of the OpenLayers WKT input, although, because it parses WKT into GML, it doesn't support the entire spec (yet). Patches are certainly accepted in this area.

strk’s picture

strk commented

Here's a snapshot of what I get with WFS head: http://strk.keybit.net/tmp/WFS_style.png

tmcw’s picture

tmcw commented

Sorry, development is actually happening in DRUPAL-6--1.

strk’s picture

strk commented

Ah! that explains, will try ASAP and let you know any limitations I find.
Great to know :)

strk’s picture

strk commented

Am I right that the current wkt_to_gml only accepts POLYGON typed WKT ?
I belive the OpenLayers module forces you to have a GEOMETRYCOLLECTION, at least I tried manually setting things like POINT(0 0) and got an error from the OpenLayerCCK widget...

tmcw’s picture

tmcw commented

Currently, yes. The conversion will eventually be built out further, and patches are accepted in that area, but doing WKT->GML conversion is kind of a second priority of the module, behind actually implementing the very picky WFS protocol.

strk’s picture

strk commented
StatusFileSize
new logWKTParsingLimit.patch579 bytes

Attached patch logs an error when an unsupported WKT is found by wkt_to_gml.

strk’s picture

strk commented

I've found a nice GPL script doing WKT to GML2, working on it to make into a class for easier reuse
and allow specifying a GML version (2 or 3).

I see you're doing GML3, is that _required_ by WFS1.1 ?
Does Geoserver support WFS1.0 ?
My plan is to use mapserver, which supports 1.0, not sure about 1.1.

strk’s picture

strk commented
StatusFileSize
new wkt2gml.tgz3.89 KB

Attached the WKTParser implementation in its current state.
It is able to produce GML2 for any kind of WKT.
Comes with testcase.

tmcw’s picture

tmcw commented

I see you're doing GML3, is that _required_ by WFS1.1 ?

Ha, yes. The WFS standard sucks is picky.

GeoServer supports 1.0, and it might work to just transition the entire module over to it.

strk’s picture

strk commented

+1
GML3 also wants to swap lat/long values...
OpenLayers itself should also be fine with GML2.

strk’s picture

strk commented
StatusFileSize
new gml2.patch11.11 KB

The attached patch includes the WKTParser into gml.inc and keeps the currently exposed wkt_to_gml.
the tests/wfs.test file should be updated to check for GML2 rather than GML3.

strk’s picture

strk commented
StatusFileSize
new gml2.patch11.07 KB

Sorry, the previous contained a spurious include

tmcw’s picture

tmcw commented

So, the current status of this ticket is that WFS 1.0 should be the target of this module, but that I don't have time to transfer everything over to it right now (as I'm not currently developing/using this code).

strk’s picture

strk commented

If WFS-1.1 is already implemented, how about trying to keep support for both WFS-1.0 _and_ WFS-1.1 ?

That way if you have any working setup for WFS-1.1 (geoserver?) we can incrementally add WFS-1.0 w/out breaking
working systems. For example, the patch attached to this ticket add a class which is able to do both GML2 and GML3
which would be needed each for each WFS version, if I got it right.

tmcw’s picture

tmcw commented

It's certainly possible to have this module support both, but I simply don't have any time to invest on it or will to work on this bit for weekends, etc. Bummer indeed, but if there's anyone who is using WFS actively, then it's in a good place for anyone else to drop in patches, etc.