search

MapServer / MapServer-import

3 stars 2 forks source link

[WFS-Server] DescribeFeatureType output with ows_metadataurl_type #1903

Open tbonfort opened 12 years ago

tbonfort commented 12 years ago

Reporter: tomkralidis Date: 2006/09/07 - 18:58

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.]).
tbonfort commented 12 years ago

Author: tomkralidis Date: 2007/08/10 - 14:38 Steve: any comments here?

tbonfort commented 12 years ago

Author: sdlime Date: 2007/08/10 - 19:50 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

tbonfort commented 12 years ago

Author: tomkralidis Date: 2007/08/10 - 19:54 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

tbonfort commented 12 years ago

Author: sdlime Date: 2007/08/14 - 06:05 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?

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

tbonfort commented 12 years ago

Author: tomkralidis Date: 2007/08/14 - 13:20

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?

tbonfort commented 12 years ago

Author: tomkralidis Date: 2007/08/14 - 13:21 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?

tbonfort commented 12 years ago

Author: sdlime Date: 2007/08/14 - 16:27 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

tbonfort commented 12 years ago

Author: sdlime Date: 2007/08/14 - 16:42 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 (a954632e10a9baf92155d241a3b0bdacfc0dba08 (r6579)) and let me know?

Steve

tbonfort commented 12 years ago

Author: tomkralidis Date: 2007/08/14 - 16:43 Replying to [comment:7 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.

tbonfort commented 12 years ago

Author: sdlime Date: 2007/08/14 - 16:51 Replying to [comment:9 tomkralidis]:

Replying to [comment:7 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.

tbonfort commented 12 years ago

Author: tomkralidis Date: 2007/08/14 - 16:52 Replying to [comment:8 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 (a954632e10a9baf92155d241a3b0bdacfc0dba08 (r6579)) and let me know?

Steve

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

tbonfort commented 12 years ago

Author: sdlime Date: 2007/08/14 - 16:56 I think the docs are up-to-date, the code was wrong... Check and see if you agree.

Steve

tbonfort commented 12 years ago

Author: tomkralidis Date: 2007/08/14 - 17:07 Replying to [comment:12 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.