[mapserver-users] Generic geometry type in WFS

[Richard Greenwood]

FYIW - I used the GROUP clause on three layers with three different
geometry types and MapServer produced wfs output in both GML and GeoJSON
formats that was correctly consumed by OpenLyaers.

LAYER
  GROUP 'geoms'
  NAME 'pt'
  TYPE 'point'
  . . .
END

LAYER
  GROUP 'geoms'
  NAME 'ln'
  TYPE 'line'
  . . .
END

LAYER
  GROUP 'geoms'
  NAME 'poly'
  TYPE 'polygon'
  . . .
END

Some dis-aggregation in the database might address geometry collections.

Rich


On Mon, Dec 19, 2016 at 3:16 PM, Rahkonen Jukka (MML) <
jukka.rahkonen at maanmittauslaitos.fi> wrote:

> Now when I read the same page a bit longer I see that there are
> “gml_[geometry name]_type” and “ows/wfs_geomtype” and the latter supports
> generic “Geometry” and also that my use case with mixed polygons and
> multipolygons is understood. But I do not understand at all what I should
> do for making WFS 1.0.0, 1.1.0, and 2.0.0 to utilize OGR output so that
> users could still use the default GetFeatures without adding &outputformat
> parameter, and that DescribeFeatureType would advertise type='gml:
> GeometryPropertyType'
>
>
>
> From the documentation:
>
> gml_[geometry name]_type
>
>
>
>     When employing gml_geometries, it is also necessary to specify the
> geometry type of the layer. This is accomplished by providing a value for
> gml_[geometry name]_type, where [geometry name] is the string value
> specified for gml_geometries, and a value which is one of:
>
>
>
>         point
>
>         multipoint
>
>         line
>
>         multiline
>
>         polygon
>
>         multipolygon
>
>
>
> ows/wfs_geomtype
>
>
>
>     (Optional, metadata shared with OGR output). Set the geometry type of
> OGR layers created from this MapServer LAYER. One of “Point”, “LineString”,
> “Polygon”, “MultiPoint”, “MultiLineString”, “MultiPolygon”,
> “GeometryCollection”, “Geometry”, or “None”. Most are fairly obvious, but
> “Geometry” can be used to represent a mix of geometry types, and “None” is
> sometimes suitable for layers without geometry. Note that layers which are
> a mix of polygon and multipolygon would normally have to be described as
> “Geometry”. To produce 2.5D output append “25D” to the geometry type (ie.
> “Polygon25D”). Note that Z values are only carried by MapServer if built
> with USE_POINT_Z_M support.
>
>
>
> -Jukka Rahkonen-
>
>
>
> Even Rouault wrote:
>
>
>
> Re: [mapserver-users] Generic geometry type in WFS
>
>
>
> Hi,
>
>
>
> >
>
> > I read from http://mapserver.org/ogc/wfs_server.html this comment:
>
> >
>
> > "WFS spec. seems to require that features of a given feature type must
> all
>
> > be of the same geometry type (point, line, polygon). This works fine for
>
> > shapefiles, but some data source formats supported by MapServer allow
> mixed
>
> > geometry types in a single layer and this goes against the WFS spec.
>
> > Suggestions on how to handle this are welcome (send suggestions to the
>
> > mapserver-dev mailing list."
>
> >
>
> > Without seeing a reliable reference I do not quite believe that mixed
>
> > geometries are not allowed.
>
>
>
> Yes, that statement is really weird and IMHO wrong. The WFS spec doesn't
> care at all about a concept of layer geometry type.
>
>
>
> > Geoserver and probably also ArcGIS server
>
> > handle this case by advertising unknown/mixed geometries as
>
> > type='gml:GeometryPropertyType'
>
> >
>
> > The metadata item gml_[geometry name]_type could have one more option
>
> > "geometry" in addition to the documented list point
>
> > multipoint
>
> > line
>
> > multiline
>
> > polygon
>
> > multipolygon
>
>
>
> Another thing is that MapServer requires a precise geometry type (the TYPE
> keyword of a LAYER) to be declared, mostly for the needs of rasterization.
> The WFS server code doesn't really care about the value, except that it
> must be defined to one of POINT, LINE or POLYGON so as to check this is
> really a vector layer. But if your datasource is a mix of geometries, that
> should mostly work, except some tuning in the gmlWriteGeometry_GMLx
> functions though. So indeed we could imagine exposing a generic "geometry"
> type, although it is not clear how useful this would be.
>
>
>
> >
>
> > The list makes me think that don't we support GeometryCollections?
>
>
>
> Nope, and this would be harder since the mapserver shape object doesn't
> handle those. And this is a even more esoteric use case.
>
>
>
> Even
>
>
>
> --
>
> Spatialys - Geospatial professional services
>
> http://www.spatialys.com
>
> _______________________________________________
> mapserver-users mailing list
> mapserver-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-users
>



-- 
Richard W. Greenwood, PLS
www.greenwoodmap.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20161220/9fc74f11/attachment-0001.html>