On 01/10/15 05:17, Stefano Costa wrote: > To implement Ben's suggestion, I had to parse the mapping file and inspect > the declared namespaces, looking for either "http://www.opengis.net/gml" > (aka GML 3.1.1) or "http://www.opengis.net/gml/3.2" (aka GML 3.2) was > defined.
Stefano, this is not going to work for all cases. The problem is that mapping files only need to declare one of these namespaces if the prefix is used a targetElement xpath. I am sure that I have seen valid mapping files that do not either. GML is used only via import in the target schema. One way to be sure is to use AppSchemaDataAccess.getSchema to get the feature type, then get the XSD type smuggled in the user data map, and then walk up parent XSD types until you find either GML 3.1 or GML 3.2 AbstractFeatureType. The WFS standard states that feature types must be subtypes of gml:AbstractFeatureType. > 1) The code so far is not pretty, as I'm basically doing if-else logic on > the feature type's datastore connection parameters directly inside the > org.geoserver.web.demo.PreviewLayer class. It would have been better to > setup some extension mechanism, like defining a GMLLinkProvider interface > for which modules like app-schema could provide implementations, that the > preview page would then look up via Spring and use to create the GML link. > Considering that so far, as I understand, app-schema layers are the only > one that need special treatment, do you think it is worth the effort > required to setup such mechanism? In my view no. A little ugly may be more maintainable than a new interface that is only used in one case. > 2) How am I going to test this? Ben, do you have any suggestions as to how > to quickly setup some app-schema layers to test? There are test fixtures in GeoServer gs-app-schema-test. I do not think there are any Wicket test fixtures, but you should be able to add some based on those in the GeoServer gs-web-* modules. > 3) I believe that for app-schema layers all WFS output formats which don't > support complex features (i.e. all but GML 3.1.1/3.2) should either not be > added to the list of available formats or return a nice error message, like > the KML output format does: "The KML output format can only be applied to > simple features" Sounds good to me. > 4) I believe the OpenLayers, KML and all WMS output formats should be > hidden if the published layer is geometryless, or the lat/lon bbox is > null/empty: should I prepare a second PR with this improvement as well? Sure, that sounds sensible. Kind regards, -- Ben Caradoc-Davies <b...@transient.nz> Director Transient Software Limited <http://transient.nz/> New Zealand ------------------------------------------------------------------------------ _______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel