[GRASS-dev] improving v.in.wms

[Hamish]

Štěpán wrote:
> I have some suggestions for improvement of v.in.wfs module.

great

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

consistency is good. it means that once the user learns things
once they can re-use that knowledge across all the parts of the
GIS, versus having to learn all the different 400-500 modules
individually. (at the same time though, you don't have to be a
complete slave to that if the fit is wrong somewhere.. there
is strength in flexibility)

> 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)

don't worry too much about breaking compatibility with the grass
6 names if the change is demonstrably better. That's why it will
be called grass 7 and not grass 6.6.

wrt "mapserver", my main concern is that it shares the same name-
space with the software project, so may be confusing in some
usage contexts. other than that I don't really mind much.


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

 -l for list of names, -c for full capabilities
 
> 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.

fwiw originally the idea for the flag was 'list layers' not
show full capabilities. I didn't want to go to the complications
of parsing xml, so for a shortcut I just saved out the full xml
to a local file. (it's a quick hack, feel free to improve...
maybe there is a python tool to reformat the xml in a pretty
way instead of the no-whitespace padding that often the
capabilities download file has?)
I don't know which is better, probably have the back-end module
save the xml file* and the GUI run that in the background and
present the results in a nice gui table for interactive prep.

[*] would need to be able to set the filename to save it to a
temp dir/file.

> Currently r.in.wms supports GDAL WMS driver and own driver. The
> structure allows  to add other drivers easily (e. g. OWSlib).

is that really needed? or would it be better to just support one
method well? (I don't mind a flexible back-end, just wondering)

> 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.

fwiw I am not much of a fan of on-the-fly reprojections, they
can get a bit muddy. e.g. if using gdal/ogr with +nadgrids datum
transform NTv2 files which are located in places with spaces in
the path name, some of the gdal tools fail as they don't parse
the srs as a single argument and it's impossible to fix that
without a change to the gdal tool and broken compatibility for
all gdal users.  (search for the bug report in trac system(s))
Too many headaches maintaining v.in.gpsbabel and r.in.wms make
me prefer to just import into native location and project with
full r.proj/v.proj now ... k.i.s.s. principle.
any module which did try to reproject on the fly should have
a flag to avoid that part of the process completely.

> 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.

I have no further plans to develop v.in.wfs myself; my current
itch is scratched. if someone else would like to do that by all
means take it up and make it great.


cheers,
Hamish