[mapserver-dev] RFC 62: Support Additional WFS GetFeature Output Formats

[Lime, Steve D (DNR)]

If I recall correctly gml_exclude_items can be quite convenient if you have lots of items. Much easier to include all and then exclude a few than explicitly including all of them. -steve
________________________________________
From: mapserver-dev-bounces at lists.osgeo.org [mapserver-dev-bounces at lists.osgeo.org] On Behalf Of Frank Warmerdam [warmerdam at pobox.com]
Sent: Friday, October 08, 2010 4:43 PM
To: Yewondwossen Assefa
Cc: mapserver-dev
Subject: Re: [mapserver-dev] RFC 62: Support Additional WFS GetFeature Output   Formats

Yewondwossen Assefa wrote:
>  Hi Frank,
>
>  Couple of questions that I had reading the RFC:
>
>   - would a user need to define always the OGR outputs in a map file or
> does it make sense to have some that are commonly used defined by
> default in MapServer (I am thinking of a json output with an
> application/json output format)?

Assefa,

An interesting question.  For GDAL I think the only output
format we predefine was GeoTIFF.  If I was to predefine an
output format I'd likely pick Shapefiles, but due to their
limits on geometry types and peculiarities of the .dbf file
they aren't a particularly problem free format.  For now I'm
not inclined to pre-define an OGR output formats.

>   - Just to clarify, would the user needs to add a IMAGEMODE FEATURE in
> his output block for an ogr driver or is it implied?

It is implied. No other value would be meaningful for OGR output
formats.

>  - there is also the use the format option ATTACHEMENT used for the
> template drivers to set the "Content-disposition: attachment", is that
> similar to FORMATOPTION "FILENAME..."? If that is the case we should
> change the ATTACHEMENT to FILENAME to have consistency.

The FILENAME is intended to set the datasource output name.  In
the case of FORM=simple returns, this name would get put into
"Content-Disposition: attachment; filename=%s" header.  If the
FORM=zip then presumably the file(s) inside the zip would be named
by it.  In the case of FORM=multipart it would presumably set
the name of some or all of the attached files.  So it isn't always
going to appear in the filename= of an attachment content disposition
header.  However, I was unaware of the attachment format option for
templates.

Because the behavior is somewhat different, I'd like to avoid
using the same format option name.

>  - out of curiosity, will you  introduce a zip library like minzip in
> this work? I was looking into this for kmz output.

GDAL already had io infrastructure for minizip "unzip", so I added
minizip "zip" in GDAL and GDAL exports a simple API to use it.
That's what I'm using in mapogroutput.c, but the downside is that
it is only available if using GDAL 1.8 or newer.

One benefit of using minizip from GDAL is that it can easily
assemble the zip in memory using the /vsimem/ stuff instead of
having to write it to disk.  Of course that could be accomplished
with appropriate io hooks for minizip "zip" if it was incorporated
directly in mapserver too.

>  - Regarding the outstanding issues:
>     *  I am not sure I understand the first one "..support the WFS limit
> on number of features": wouldn't the query be done prior to getting to
> the msReturnTemplate, and thus respecting things line maxfeatures set on
> the layer?

In the old GML case, the index of the start feature, and the
maximum number of features to return are passed into
msGMLWriteWFSQuery().  I'm assuming this is because the
actual query result has all the features and it is up to
the code that converts it to a particular format to enforce
WFS start/maxfeature restrictions.

>    *  re. gml_include_items: are you thinking also of using
> gml_exclude_items and aliases? I am not sure I can think of other
> mechanisms to get the list of attributes.

Yes, I'd like to implement the aliasing capability.

I'm not so sure about gml_exclude_items.  I got the impression that
this was a leftover from before gml_include_items was added and only
supported for backward compatibility.  I suppose for completeness I
should do the same.

>   * re strong tying: would the gml_[item_name]_type be enough to do a
> valid output (if It is defined), or were you thinking have having the
> types in MapServer at read time?

I'll have to look into the gml_[item]_type.

OK, having looked it over a bit, it does seem like it should be
sufficient for setting field types, though obviously it would be
preferable to have a way of getting this information from the
original driver itself.

Perhaps in some circumstances we should allow the feature source
implementations to set this metadata if it isn't already set?
What downsides do you see to that?  Perhaps "gml_types=auto"
would request the source driver to supply the types if it can?

We might also get into issues of wanting to carry through field
widths, precision and needing more field types than currently
supported.

I'll try and update the RFC based on your feedback - but I'd appreciate
more feedback on the idea of automatic type detection before I incorporate
that.  I can at least support gml_[item]_type if it is present.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

_______________________________________________
mapserver-dev mailing list
mapserver-dev at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-dev