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