[GRASS-dev] improving v.in.wms

[Štěpán Turek]

Hello Hamish,

I have some suggestions for improvement of v.in.wfs module.

It would be good when parameters and flags would be same for all OGC 
modules in GRASS.

I would suggest:
url -> mapserver (original r.in.wms module had mapserver parameter, 
maybe url is better name but for compatibility reason I would stick to 
mapserver)

-l  -> -c
or in r.in.wms -c -> -l

I would suggest to use similar design of the module as r.in.wms. This 
allows usage of various drivers for getting data from server. Currently 
r.in.wms  supports GDAL WMS driver and own driver. The structure allows 
to add other drivers easily (e. g. OWSlib).

Also some parts of source code of r.in.wms can be usable for v.in.wfs 
(e. g. transformation of bbox). This makes implementation of e. g. 
transformation of downloaded data into projection of location relatively 
easy.

I know r.in.wms well so if you would agree with these suggestions I can 
modify code of r.in.wms to be usable for v.in.wfs module.

Stepan


On 09/16/2012 10:16 AM, Hamish wrote:
> Luca wrote:
>> For me +1 to use OWSlib,i already thought to use it for wms/wfs client.
>> if we add this dependency we could also add others clients (wcs,sos etc)
>> in a easy way.
>
> Hi,
>
> since it is just a couple characters to += onto the URL to support data
> layer names, bounding boxes, etc. I stuck with the current method for now.
> Added functionality in r53180:
>
> New flags:
>    -l   Download server capabilities to 'wms_capabilities.xml' in the current directory and exit
>    -r   Restrict fetch to features which touch the current region
>
> New/changed parameters:
>                 url   Base URL starting with 'http' and ending in '?'
>                name   Comma separated names of data layers to download
>                 srs   Specify alternate spatial reference system (example: EPSG:4326)
>                        The given code must be supported by the server, consult the capabilities file
>    maximum_features   Maximum number of features to download
>                        (default: unlimited)
>         start_index   Skip earlier feature IDs and start downloading at this one
>                        (default: start with the first feature)
>
>
> There is still lots of room for improvement and better methods, I just
> went with the quick solution. (But it works) Please do improve it further
> if you like..
>
>
> Since the data layer Name is not always very meaningful as the Title, and
> the xml capabilities file is often hard to browse, even with xml2 parsing,
> I was thinking perhaps to put the OWSlib magic for WFS into an owslib
> based interactive GUI browser tool, somewhat similar to QGIS 1.8.0's nice
> qbrowser* but with a search/filter function as the grass location wizard
> has, allow to limit by current g.region bounds, etc.
>
> [*] qgis 1.8.0's main WFS add layer dialog seems like it is still under
> construction; the qbrowser side of things worked a bit better for me.
>
>
> .. I'm not too worried since WFS is a lot cleaner than WMS data to deal
> with, just trying to think of how not to fall into the same traps as we
> did for the grass 6 r.in.wms, where the low-level module tried to do too
> much itself.
>
>
> Hamish
>
> ps- the Hannover grass user map wfs in the module's example returns a 404.
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev