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
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
