[mapserver-commits] r10582 - trunk/docs/en/development/rfc
svn at osgeo.org
svn at osgeo.org
Thu Oct 7 21:57:56 EDT 2010
Author: warmerdam
Date: 2010-10-08 01:57:56 +0000 (Fri, 08 Oct 2010)
New Revision: 10582
Added:
trunk/docs/en/development/rfc/ms-rfc-62.txt
Modified:
trunk/docs/en/development/rfc/index.txt
Log:
preliminary writeup for RFC 62
Modified: trunk/docs/en/development/rfc/index.txt
===================================================================
--- trunk/docs/en/development/rfc/index.txt 2010-10-07 19:42:44 UTC (rev 10581)
+++ trunk/docs/en/development/rfc/index.txt 2010-10-08 01:57:56 UTC (rev 10582)
@@ -71,4 +71,6 @@
ms-rfc-59
ms-rfc-60
ms-rfc-61
+ ms-rfc-62
+
Added: trunk/docs/en/development/rfc/ms-rfc-62.txt
===================================================================
--- trunk/docs/en/development/rfc/ms-rfc-62.txt (rev 0)
+++ trunk/docs/en/development/rfc/ms-rfc-62.txt 2010-10-08 01:57:56 UTC (rev 10582)
@@ -0,0 +1,205 @@
+.. _rfc62:
+
+===============================================================
+ MS RFC 62: Support Additional WFS GetFeature Output Formats
+===============================================================
+
+:Date: 2010/10/07
+:Author: Frank Warmerdam
+:Contact: warmerdam at pobox.com
+:Last Edited: $Date: 2010-09-28 17:40:49 -0400 (Tue, 28 Sep 2010) $
+:Status: Development
+:Id: $Id$
+
+Description: This RFC proposes to extend the ability of the WFS GetFeature
+request to support formats other than GML. Support for template query
+formatting (aka RFC 36) is introduced as well as support for output to
+OGR outputs. Control of output formats is managed via appropriate
+OUTPUTFORMAT declarations.
+
+WFS GetFeature Changes
+~~~~~~~~~~~~~~~~~~~~~~
+
+1) If the WFS OUTPUTFORMAT value is not one of the existing supported values,
+then the set of outputFormatObj's for the map will be searched for one with
+a matching name or mime type and an image mode of MS_IMAGEMODE_FEATURE.
+
+2) If the wfs_formats metadata exists on the layer, it should be a comma
+delimited list of output formats permitted for this layer. Any other will not
+be selectable with the OUTPUTFORMAT parameter to GetFeature.
+
+3) The existing GML2/GML3 generation support will be retained in essentially
+it's current form within mapwfs.c, but it's preamble and postfix generation
+will be moved into separate functions to reduce the "gml clutter" in the
+main msWFSGetFeature() function.
+
+4) If an outputFormatObj is being used instead of GML output, it will be
+generated by a call to msReturnTemplateQuery() which already supports output
+via the new template engine (RFC 36) as well as call outs for other renderers.
+
+outputFormatObj
+~~~~~~~~~~~~~~~
+
+A new image mode value will be added, MS_IMAGEMODE_FEATURE, intended to
+be approriate for formats that are feature oriented, and cannot be meaningfully
+seen as an image. RFC 36 style template output format declarations will now
+default to this imagemode. The WFS GetFeature() directive will only
+support output formats of this image mode.
+
+As well a new renderer value, MS_RENDER_WITH_OGR, will be added for OGR
+output.
+
+OGR OUTPUTFORMAT Declarations
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The OGR renderer will support the following FORMATOPTION declarations:
+
+DSCO:*
+ Anything prefixed by DSCO: is used as a dataset creation option with the
+ OGR driver.
+
+
+LCO:*
+ Anything prefixed by LCO: is used as a layer creation option.
+
+
+FORM=simple/zip/multipart
+ Indicates whether the result should be a simple single file (single), a
+ mime multipart attachment (multipart) or a zip file (zip). "zip" is
+ the default.
+
+
+STORAGE=memory/filesystem/stream
+ Indicates where the datasource should be stored while being written.
+ "file" is the default.
+
+ If "memory" then it will be created in /vsimem/ - but this is only suitable
+ for drivers supporting VSI*L which we can't easily determine automatically.
+
+ If "file" then a temporary directory will be created under the IMAGEPATH
+ were the file(s) will be written and then read back to stream to the
+ client.
+
+ If "stream" then the datasource will be created with a name "/vsistdout"
+ as an attempt to write directly to stdout. Only a few OGR drivers will
+ work properly in this mode (ie. CSV, perhaps kml, gml).
+
+
+COMPRESSION=none/gzip
+ Should gzip compression be applied as the result is returned? This is
+ generally not suitable for use with FORM=zip which is already compressing
+ the image. "none" is the default.
+
+
+FILENAME=name
+ Provides a name for the datasource created, default is "result.dat".
+
+Examples::
+
+ OUTPUTFORMAT
+ NAME "CSV"
+ DRIVER "OGR/CSV"
+ MIMETYPE "text/csv"
+ FORMATOPTION "LCO:GEOMETRY=AS_WKT"
+ FORMATOPTION "STORAGE=memory"
+ FORMATOPTION "FORM=simple"
+ FORMATOPTION "FILENAME=result.csv"
+ END
+
+ OUTPUTFORMAT
+ NAME "OGRGML"
+ DRIVER "OGR/GML"
+ FORMATOPTION "STORAGE=filesystem"
+ FORMATOPTION "FORM=multipart"
+ FORMATOPTION "FILENAME=result.gml"
+ END
+
+ OUTPUTFORMAT
+ NAME "SHAPEZIP"
+ DRIVER "OGR/ESRI Shapefile"
+ FORMATOPTION "STORAGE=memory"
+ FORMATOPTION "FORM=zip"
+ FORMATOPTION "FILENAME=result.zip"
+ END
+
+
+OGR Renderer Implementation
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The OGR Renderer will be implemented as the function msOGRWriteFromQuery()
+in the new file mapogroutput.c. It will create a new OGR datasource based
+on the information in the output format declaration. It will then
+create an output layer for each map layer with an active, non-empty
+query resultcache. Those resultcache shapes will be written.
+
+- The gml_include_items rules will be used to decide what attributes should
+ be written to the output layers.
+- the gml field name aliasing mechanism will be supported for OGR output.
+- Layers will be created with a geometry type based on the type of the layer
+ with POINT as wkbPoint, LINE as wkbLineString, and POLYGON as wkbPolygon.
+- Currently all output fields will be created with a type of OFTString since
+ we do not have a mechanism to know the real types of source fields.
+- Some features, such as zip output, will only be supported with GDAL/OGR 1.8.
+ These features will be made conditional on the GDAL/OGR version.
+
+
+Use of CPL Services
+~~~~~~~~~~~~~~~~~~~
+
+Support for WFS OGR output is dependent on USE_OGR being defined. But
+when available it implies that GDAL/OGR CPL (Common Portability Library)
+services are also available. These include the virtual file system
+interface (VSI*L) which provides services like "in memory" files. The
+/vsimem services will be used to avoid writing intermediate files to disk
+if STORAGE=memory, the default configuration.
+
+Note that the /vsimem/ service is already being used for WMS layers to
+avoid having to write images from remove WMS servers to disk, in WCS
+to avoid writing GDAL-written images to disk and in WMS when using GDAL
+based outputformats. So this isn't really new.
+
+As well, CPL includes support for gzip compression via the /vsigzip
+virtual filesystem handler.
+
+In the past GDAL has *not* had support for writing zip files; a feature
+that is very desirable as a mechanism for both compressing and grouping
+multi-file sets produced by many OGR drivers. As part of the development
+undertaken for this RFC it is intended that GDAL will be extended with
+a CPL API for writing zip files, or alternatively a /vsizip/ virtual file
+system mechanism to write files.
+
+
+Backwards Compatibilty Issues
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+
+
+Further Considerations
+~~~~~~~~~~~~~~~~~~~~~~
+
+- It should be noted that the DescribeFeatureType WFS operation will still only
+ support GML formatted description for feature types.
+- A prototype implementation has been developed (by Frank Warmerdam) and is
+ working though it is not quite feature complete, and will need some refinement
+ before it can be committed.
+
+
+Outstanding Issues
+~~~~~~~~~~~~~~~~~~
+
+- How do we alter msReturnTemplate() to support the WFS limit on number
+ of features, and offset to the first feature?
+- What are the implications if queries in other circumstances than WFS
+ GetFeature pick an OGR output format?
+- Do we need to support multipoint, multilinestring and multipolygon generation?
+- Are there other mechanisms than gml_include_items we need to consult to
+ decide on fields to write?
+- Do we want to introduce a mechanism to apply stronger typing to fields in
+ the output files?
+
+
+Voting history
+~~~~~~~~~~~~~~
+
+
+
More information about the mapserver-commits
mailing list