RFC 62: New WFS Output Formats

[warmerdam]

This ticket is intended to track issues related to the implementation of RFC 62 - Support Additional WFS GetFeature Output Formats.

​http://www.mapserver.org/trunk/development/rfc/ms-rfc-62.html

[warmerdam]

Primary implementation (r10598).

Build and other fixes (r10600, 10601)

GetCapabilities updates (r10603).

[rouault]

I think there's an issue with the marker at the end of the last multipart. It should be "--xxOGRBoundaryxx--" and not "--xxOGRBoundaryxx"

Proposed fix :

Index: mapogroutput.c
===================================================================
--- mapogroutput.c	(révision 10605)
+++ mapogroutput.c	(copie de travail)
@@ -724,7 +724,10 @@
                 msIO_fwrite( buffer, 1, bytes_read, stdout );
             VSIFCloseL( fp );
 
-            msIO_fprintf( stdout, "\n--%s\n", boundary );
+            if (file_list[i+1] == NULL)
+                msIO_fprintf( stdout, "\n--%s--\n", boundary );
+            else
+                msIO_fprintf( stdout, "\n--%s\n", boundary );
         }
     }

[rouault]

Attached a patch, fix_mapogroutput_memleaks.c.patch, that removes some memory leaks (mainly in error code path, but also in normal code path)

[rouault]

DSCO FORMATOPTION doesn't work. Here's the patch that fixes that :

Index: mapogroutput.c
===================================================================
--- mapogroutput.c	(révision 10613)
+++ mapogroutput.c	(copie de travail)
@@ -402,7 +402,7 @@
                                           format->formatoptions[i] + 4 );
         if( strncasecmp(format->formatoptions[i],"DSCO:",5) == 0 )
             ds_options = CSLAddString( ds_options, 
-                                       format->formatoptions[i] + 4 );
+                                       format->formatoptions[i] + 5 );
     }
     
 /* ==================================================================== */

[warmerdam]

Even, thanks - applied (r10617).

[warmerdam]

Part of Even's memory leak patch applied (r10625) along with some other stuff. I am not interested in avoiding small memory leaks in rare error cases - it seems more dangerous than valuable to me.

[warmerdam]

Implemented support for gml_types "auto" in postgis (r10651) and oracle (r10657).

[warmerdam]

Documentation updated, including the addition of a new OGR Output document (r10665), brief notes in the outputformat area of the mapfile reference, and brief updates to the WFS Server doc.

At this point I believe I have covered all the bases for this new feature so I'm closing this ticket.

[rouault]

I'm seeing failure on wfsogr10_twolayer.xml and wfsogr10_midmif.txt for a rather unexpected reason : the order in which the files are serialized for me is not the same as the expected result. This comes from the fact that the OUTPUTFORMAT in both cases depend on "STORAGE=filesystem", and as the order of files returned by readdir() is not deterministic, this explains why on different systems you get different results. Perhaps sorting the list after "file_list = msOGRRecursiveFileList( datasource_path );" might make sense to avoid this ?

I also have a failure with wfsogr_wms_getfeatureinfo.xml and I also see that it fails on Tamas windows machines (​http://vbkto.dyndns.org:1280/sdk/build-output/vc7-20101028-4-20-29-42-vc7-dev.txt). The result I get has weird coordinates :

Content-Disposition: attachment; filename=result.csv
Content-Type: text/csv

WKT,FNODE_,TNODE_,LPOLY_,RPOLY_,LENGTH,ROAD_ID,F_CODE,NAME_E,NAME_F
"LINESTRING (120.019932432432597 194.899503968253981 0, [snip]

[warmerdam]

I've noticed the file order thing one time before - I think I'll have to sort the filenames after reading them back from the directory and serializing the contents.

I'll see what I can figure out about the odd coordinates problem.

[warmerdam]

I have change mapogroutput.c to sort the files read from the directory (r10693) and updated the test (r10692). The ordering should now be consistent on all systems.

The other problem is about what projection the feature is returned in. I've come to the conclusion the problem is the issue in #3480. I've normally kept a patch in my local tree while waiting for it to be fixed which is why I produce different (correct) results.

I'm going to followup on that issues within #3480, perhaps tonight.

[sdlime]

Frank: Where there any msautotests added for this enhancement? I'm putzing with #3751 for Mike and was looking for a ready-made test case or two.

Steve