[gdal-dev] Namespaces in GMLAS

[Ari Jolma]

Even Rouault kirjoitti 16.10.2017 klo 13:25:

> On lundi 16 octobre 2017 13:03:32 CEST Ari Jolma wrote:
>> Thanks,
>>
>> After fixing srsName attribute in the returned gml (the HTTP errors i
>> mention below) I can now read the features in the file (GetNextFeature
>> on the dataset object).
>>
>> As a second step I try to make the download implicit (assuming the
>> srsName would be ok) and use the /vsicurl mechanism, i.e., open
>>
>> /vsicurl/https://opaskartta.turku.fi/TeklaOGCWeb/WFS.ashx?request=GetFeature
>> &typename=akaava:Suojelualue
>>
>> directly.
> You can use GMLAS:/vsicurl/...

Thanks, good to know.

>
> The following works for me:
> ogrinfo "GMLAS:/vsicurl/https://opaskartta.turku.fi/TeklaOGCWeb/WFS.ashx?request=GetFeature&typename=akaava:Suojelualue&version=1.1.0"

Also the version seems to be important in this case. Without it the 
server seems to use GML 2.1.2, which conflicts with the rest of the GML 
application which uses GML 3.1.1. Also in GML 2.1.2 it adds the 
erroneous (I think, at least it fails in GDAL) srsName to geometries.

>
> Not however that for a large file (> 16 MB), /vsicurl/ will not manage to cache the whole file. As the GMLAS driver requires multiple parsing passes,
> this will cause the document to be re-downloaded several times.
> You can workaround that by setting VSI_CACHE=YES and increasing the  VSI_CACHE_SIZE value. Or downloading it entirely in a local file.
>
> Hum, actually for such files, /vsicurl/ will probably not work since it issues GET range requests that WFS servers are unlikely to honour.
> /vsicurl_streaming/ should be used, as it does a standard HTTP GET request, and reading XML file is purely a sequential operation that doesn't require random seeking.

ok, thanks. Best to download the file separately before reading it with 
GDAL.

Ari

>
>> That seems difficult (impossible?) since GMLAS driver expects the name
>> to start with GMLAS prefix. I don't see any obvious way to go around
>> that. I can force GDAL to try only GMLAS but that does not help. Would
>> it be possible to make OGRGMLASDriverIdentify return true using some option?
> The Identify() method could potentially look at poOpenInfo->papszAllowedDrivers, and if
> it is made of a single entry that is GMLAS, it could remove the requirement for the GMLAS: prefix
> There would be probably a few other changes since some code must expect the GMLAS: prefix
>
> Even
>