Andrea Peri wrote: > Hi, >>If GetFeatureInfo would produce GML with different schema than WFS >>GetFeature, how the users are supposed to read it? WMS does not have request >>"DescribeGetFeatureInfoSchema" and building such for Mapserver does not feel >>optimal. So the GetFeatureInfo GML should have a link to a static >>schema file that could be accessed through the web.
> Yes this was an option, but it is not the only. > Another option could be an "Inline XML". It is an XML with it xsd embedded. > http://www.herongyang.com/XML/XSD-Statements-Embedded-in-XML-File.html GDAL/OGR can write such GML files but documentation warns that they may not be valid. You can try with ogr2ogr for example with the following command. If there is some troubles with my WFS you can use any other vector format as input. ogr2ogr -f GML -dsco XSISCHEMA=INTERNAL test.gml "wfs:http://hip.latuviitta.org/cgi-bin/tinyows"; -sql "select * from municipalities where kunta_ni1='Helsinki'" If the resulting GML seems good to you I would guess that someone here can tell how to configure Mapserver to use that kind of output for GetFeatureInfo. Formatoptions in OGR output settings seem promising to me http://mapserver.org/output/ogr_output.html >>How about forgetting GML and use something that does not need separate schema >>file, perhaps GeoJSON? > I guess GeoJSon is no a consolidated standard. > So I guess the GeoJSON generated from geoServer is different from the GeoJSON > of MapServer or of other products. > Our goal is to write routines able to speak with MapServer mainly with > MapServer but also with GeoServer or others WMS systems. > The routins must be able to retrieve attributes and geometry. > We don't want use the WFS because it is too much oriented to a download. It > is not lockable to give one only instance (one only > geometry) I am not a specialist with standards but if GeoJSON and JSON standards together take something like 430 pages less than GML it is possible that there are less possibilities for different interpretations. http://geojson.org/geojson-spec.html http://www.ietf.org/rfc/rfc4627.txt http://www.opengeospatial.org/standards/gml If you are going to discuss with servers which are not managed by yourself you may meet some troubles with WMS GetFeatureInfo. WMS standard says very little about GetFeatureInfo output formats. Mainly it is just that the formats must be advertised in the WMS GetCapabilities. Limiting results from WFS to only one result is not a problem, you need just add &MAXFEATURES=1 to the request. The main problem when it comes to interactive web mapping use is that WFS does not have request for getting the closest feature from a given coordinate. -Jukka Rahkonen- >>2012/8/10 Rahkonen Jukka <jukka.rahko...@mmmtike.fi> >>Hi, >>DescribeFeatureType is compulsory part of WSF so it is no wonder that it >>works automatically. >>I try to think what could be done. DecribeFeatureType must match with WFS >>GetFeature. It you would like to use DFT with WMS GetFeatureInfo then >>GetFeatureInfo could not be separately configurable. It should always use the >>schema defined for WFS. I suppose that this is how Geoserver works. I also believe that there are Mapserver users who want to get different GML from WFS GetFeature and WMS GetFeatureInfo. >>If GetFeatureInfo would produce GML with different schema than WFS >>GetFeature, how the users are supposed to read it? WMS does not have request >>"DescribeGetFeatureInfoSchema" and building such for Mapserver does not feel >>optimal. So the GetFeatureInfo GML should have a link to a static schema file >>that could be accessed through the web. >>OGR GML driver seems to be able to create such schema file automatically with >>XSISCHEMA=EXTERNAL option http://gdal.org/ogr/drv_gml.html. Problem is that >>probably you do not want to send two files for the WMS client doing >>GetFeatureInfo calls (xml + xsd), not even zipped into one archive file. So >>OGR should generate .xsd file, store it into some place on the server and >>write a corresponging URL into the GML part of response so that client could >>read the file through the web. It feels complicated but probably it could be >>done. XSISCHEMA=INTERNAL would be much more simple both on the server and >>client side but documentation tells that it does not work. >>How about forgetting GML and use something that does not need separate schema >>file, perhaps GeoJSON? -Jukka- Andrea Peri wrote: Hi Jukka, That option ask the user to produce itself all the schemas for all the layers I see instead that a getFeature request on the WFS section will produce automatically an xsd of the GML it return using the DescribeFeatureType request. I hope to find a solution to have this automatically produce also on the GetFeatureInfo. 2012/8/10 Rahkonen Jukka <jukka.rahko...@mmmtike.fi> Hi, Would it work as you hope if the creation option "XSISCHEMAURI" could be set as described in the OGR GML driver page http://gdal.org/ogr/drv_gml.html? "XSISCHEMAURI: If provided, this URI will be inserted as the schema location. Note that the schema file isn't actually accessed by OGR, so it is up to the user to ensure it will match the schema of the OGR produced GML data file." -Jukka Rahkonen- Andrea Peri wrote: Hi, doing a GetFeatureInfo of GML type I see the MapServer send this kind of response. <msGMLOutput xmlns:gml="http://www.opengis.net/gml"; xmlns:xlink="http://www.w3.org/1999/xlink"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";> <rt_cat.idcatbdfog.rt_layer> Unfortunately this response don't has a schemaLocation with a xsd for validation available. I try with the DescribeFeatureType, but it return an xsd for a featureCollection (for GML from WFS) don't for the msGMLOutput. Is possible to set the GetFeatureInfo from mapserver to have a GML response validable with the xsd from DescribeFeatureType ? Thx, -- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users -- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users -- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
