[WFS-Server] DescribeFeatureType output with ows_metadataurl_type

[tomkralidis]

I have a database in which one of the column names is called "metadataurl".

When exposing via OGC:WFS, invoking a DescribeFeatureType against the typename
with this column returns an invalid XML document:

http://devgeo.cciw.ca/cgi-bin/mapserv/owscat?service=WFS&version=1.0.0&request=DescribeFeatureType&typename=service_resources

Invalid XML element:

<element name="metadataurl" type="FGDC"/>

In my mapfile MAP/LAYER/METADATA object, I have defined:

"ows_metadataurl_type" "FGDC"

If I change to:

"ows_metadataurl_type" "fooFGDC"

The same request responds with:

Invalid XML element:

<element name="metadataurl" type="fooFGDC"/>

So that is telling me that somewhere in mapwfs.c, around line 632, the code
somehow maps to ows_metadataurl_type because I have it defined in my mapfile,
and it's a column in my database.

Infact, as a test, I have a column in my DB called "srs".  If I define in my
mapfile an element called "ows_srs_type", this gets output in the same way.

So, if a column name in a datatype is defined in the mapfile like:

"ows_COLUMN_NAME_type" "foooo"

...then this ends up in :

<element name="COLUMN_NAME" type="foooo"/>

...when it should be "string" (or, even better, if there is a way we can figure
out what the datatype really is [integer, etc.]).

[tomkralidis]

Steve: any comments here?

[sdlime]

This is an interesting one, tripped up by my own naming conventions. What does the whole metadata block look like? What are all the column names in this case?

Steve

[tomkralidis]

The column names look like as per DescribeFeatureType output:

Metadata block looks like this:

  METADATA
   "ows_title"    "Service Resources"
   "ows_abstract" "Service Resources"
   "ows_keywordlist" "environment,air pollution,acid rain,climate,greenhouse effect,ecosystems,environment impact assessment,emergency preparedness,pollution,biological diversity,environmental protection,water,wildlife,weather,waste,environmental management,environmental technology,recycling,climate change,environmental emergency,pollution prevention,sustainable development,science and technology,environmental action,smog,ozone,ec,cise,ogc,cgdi"
   "wms_opaque" "0"
   "ows_extent" "-141.089000 36.392987 -52.089000 89.784987"
   "ows_metadataurl_type" "FGDC"
   "wms_metadataurl_format" "text/html"
   "ows_metadataurl_href" "http://devgeo.cciw.ca/owscat/docs/index.jsp"
   "wms_dataurl_format" "text/html"   "wms_dataurl_href" "http://devgeo.cciw.ca/cgi-bin/mapserv/owscat?version=1.0.0&service=WFS&request=GetFeature&typename=service_resources&outputFormat=GML3"
   "wfs_metadataurl_format" "TXT"
   "gml_include_items" "all"
   "gml_featureid" "resource_id"
  END

Columns are (this is a !PostGIS table, but could have been anything I guess):

 resource_id | integer              | not null default nextval('service_resources_resource_id_seq'::regclass)
 service_id  | bigint               | 
 name        | text                 | 
 title       | text                 | 
 abstract    | text                 | 
 keywords    | text                 | 
 dataurl     | text                 | 
 metadataurl | text                 | 
 legendurl   | text                 | 
 scale_min   | text                 | 
 scale_max   | text                 | 
 srs         | text                 | 
 style_list  | text                 | 
 time_extent | text                 | 
 queryable   | character varying(1) | 
 the_geom    | geometry             | 

...which gets marshalled to:

​http://devgeo.cciw.ca/cgi-bin/mapserv/owscat?service=WFS&version=1.0.0&request=DescribeFeatureType&typename=service_resources

[sdlime]

This is a pretty unique situation. The software is behaving as expected. I'm not sure how to resolve (as the code sits). Seems to me that the WFS metadata handling/naming is more a problem than the GML transformation code. It's easier to avoid conflicts there than with the GML processor. If metadataurl is going to be a common column name then we should avoid that as a key name.

Solutions?

• provide alternative ways to set metadataurl information (e.g. ows_metadata_url_type)
• change the _type extension for GML tranformation to something like _datatype
• restrict the namespace (e.g. ows, gml, wfs) for gml transformations to just gml, so gml_metadataurl_type would set the datatype for the metadataurl column

I guess I like the last one the best. That way we have a clearer seperation of metadata that impacts data presentation as opposed to those that affect service configuration. Now's the time to make those changes.

Thoughts?

Steve

[tomkralidis]

Why are we hard coding the data type anyway? Can we not get this type of info (i.e. integer, string, etc.) when handling a given table and push it out?

[tomkralidis]

Sorry, I meant hard coding and fetching from mapfile metadata. MapServer, via maybe OGR, etc., should be able to fetch the data type dynamically, no?

[sdlime]

Ideally yes, but that's not fool proof. Lot's of people store int's as strings plus you have customtypes (enumerations) that might be represented in the database as a string. You really do need the ability to explicitly set a type even if you do pull definitions from a database. I'm going to limit data transformations to gml_... metadata prefixes. Shouldn't be a big deal since the documentation does that now.

Steve

[sdlime]

All GML transformations (e.g. inclusion/exlusion, aliases, types, grouping, constants) are now restricted to the gml_ metadata prefix. So now ows_metadata_type and gml_metadata_type have distictly different meanings.

Could someone test (r6579) and let me know?

Steve

[tomkralidis]

Replying to sdlime:

Ideally yes, but that's not fool proof. Lot's of people store int's as strings plus you have customtypes (enumerations) that might be represented in the database as a string. You really do need the ability to explicitly set a type even if you do pull definitions from a database. I'm going to limit data transformations to gml_... metadata prefixes. Shouldn't be a big deal since the documentation does that now.

Steve

OK, sounds good. Maybe custom defined types in the mapfile override what a default column datatype is.

[sdlime]

Replying to tomkralidis:

Replying to sdlime:

Ideally yes, but that's not fool proof. Lot's of people store int's as strings plus you have customtypes (enumerations) that might be represented in the database as a string. You really do need the ability to explicitly set a type even if you do pull definitions from a database. I'm going to limit data transformations to gml_... metadata prefixes. Shouldn't be a big deal since the documentation does that now.

Steve

OK, sounds good. Maybe custom defined types in the mapfile override what a default column datatype is.

Agreed. It does seem silly to have to define an integer type. However, one might still have to define things like the number of occurances through the mapfile. Hopefully we can polish off referencing external application schemas rather than producing them with MapServer. That way all that metadata is defined elsewhere and your job becomes configuring a layer to match that output. The MapServer schema would simply import the external schema.

[tomkralidis]

Replying to sdlime:

All GML transformations (e.g. inclusion/exlusion, aliases, types, grouping, constants) are now restricted to the gml_ metadata prefix. So now ows_metadata_type and gml_metadata_type have distictly different meanings.

Could someone test (r6579) and let me know?

Steve

Tested. Works. Reassigning to docs, as this should be outlined on the WFS-Server howto.

[sdlime]

I think the docs are up-to-date, the code was wrong... Check and see if you agree.

Steve

[tomkralidis]

Replying to sdlime:

I think the docs are up-to-date, the code was wrong... Check and see if you agree.

Steve

Just checked. True. Sorry for the fuss. Closing.