id,summary,reporter,owner,description,type,status,priority,milestone,component,version,severity,resolution,keywords,cc 5708,NAS driver does not identify correctly NAS documents,rkoblenzer,warmerdam,"The NAS driver interprets GML documents as NAS (german ""Normbasierte Austauschschnittstelle"") when it founds one of the following strings at the beginning of the file: ""AAA Fachschema.xsd"", ""NAS Operationen.xsd"" or ""NAS Operationen_optional.xsd"". This is not sufficient because it does not cover the case when the XML (GML) document does not contain an xsi:schemaLocation attribute or when the schema file names differ (from the above). On the other hand – which is actually even a bigger problem – this leads to a behavior that the NAS driver handles files which are not NAS documents at all (when they contain one of the above strings)! An example for the latter case: a WFS 2.0 (OGC Web Feature Service version 2.0) provides GML documents based on NAS: the NAS driver interprets these documents as NAS because they contain ""AAA-Fachschema.xsd"" in xsi:schemaLocation. The problem is that the NAS driver does not recognize any features because it expects them in gml:featureMember. But in fact they are embedded in gml:member elements (because it is a WFS 2.0 FeatureCollection). So as a result GDAL/OGR outputs no features at all. In environments like QGIS with a WFS Client Plugin, where the user has no influence on the WFS configuration, it is an issue. A possible solution can be to identify specific root elements and in the proper namespace only (e.g. AX_Bestandsdatenauszug and AX_NutzerbezogeneBestandsdatenaktualisierung_NBA in the namespace ""http://www.adv-online.de/namespaces/adv/gid/6.0""). Everything else should be handled by the standard GML driver. Or, if it is an intension to support NAS within OGC WFS FeatureCollections (which in fact could be interesting) then features in gml:member could be recognized additionally. ",defect,closed,normal,1.11.2,OGR_SF,svn-trunk,normal,fixed,nas,jef