[GRASS-dev] improving v.in.wms

[Štěpán Turek]

On 09/17/2012 04:26 AM, Hamish wrote:
> 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.
>
It is good point I would suggest change mapserver to url in GRASS 7 
r.in.wms?
>> -l  -> -c
>> or in r.in.wms -c -> -l
>   -l for list of names, -c for full capabilities
>   t
It makes sense to me.
>> 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.
I would leave capabilities parsing for WxGUI. I did already some work in 
this field before GSoC started.

>> 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)
>
Yes, I mean implement just one method with structure  of module which 
allows to add other methods in future.
>> 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.

The r.in.wms module was developed with intend to be used for integration 
of WMS into WxGUI which should enable on the fly transformation.
Transformation functionality in r.in.wms uses GDAL and transforms raster 
before it is imported into GRASS. It seemed  to be better solution than 
create some temporary location and transform data already imported into 
GRASS.

R.in.wms does not have flag for avoiding reprojection but it compares 
proj.4 definitions of downloaded data and location projections. It is 
not the ideal solution and it may not work in 100 % possible cases 
however when I tested it, it worked.

>> 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.
>
After GSoC I was enjoying holidays and avoiding computer as much as 
possible.
This could force me to start doing something for GRASS again.

I have thought about working on integration of WMS into wxGUI however it 
would be good to have v.in.wfs module which would be possible to use for 
integration of WFS into WxGUI and  integrate WMS and WFS together.

Stepan