[GRASS-dev] porting r.in.wms to python

[Hamish]

> > > 	v.in.gpsbabel/v.in.gpsbabel
> > > 	v.in.garmin/v.in.garmin
> > 
> > Certainly v.in.gpsbabel should survive in some form. v.in.garmin is
> > useful as the gpsbabel garmin filter does not pass through all fields.
> >
> > the XML stuff in v.in.gpsbabel is in desperate need of a python
> > replacement, otherwise it shouldn't be /too/ different from
> > v.in.mapgen.
> 
> Right. v.in.mapgen was another one that I was going to leave, but I
> ended up downloading some sample files. That made it much easier to
> see what the code was trying to do.

[v.in.gpsbabel]
For importing points it uses the style file grass_write_ascii.style to
create a flat "x|y|alt|time_str|label" file which can be fed to v.in.ascii
points mode. Easy enough but throws away some data.

For importing lines it exports to GPX format (XML) and parses that into
v.in.ascii's standard mode format. For each track it also calculates
start/end time+coords, as only the overall line may take an attribute
but each vertex has its own timestamp.

You can create a test GPX file with 'v.out.ogr format=GPX'.
.... which leads to the obvious idea of importing GPX with v.in.ogr instead
of parsing to v.in.ascii. Populating DBs will probably be a minor snag.

> It's just that trying to deduce the data structure
> from a sequence of grep/head/tail/cut commands is rather
> mind-numbing.

right. (& why I've stayed away from the GPX side of v.in.gpsbabel)
I can provide test files when the time comes.  wpt,trk,rte:
  (3x GPX, 3x gpstrans, 3x gardump files)

they are all highly simple ascii, the complication comes from v.in.ascii
wanting number of vertices prior to reading a line, and splitting off
attribute columns for DB insertion.


> > For a Python version r.in.wms, I defer the larger project to someone
> > else, but can try to add GDAL support to the existing sh/bash version
> > to demonstrate/verify the method.
> 
> That probably isn't much help.

The main goal there is not to create example code but to discover any
gotchas before investing too much effort into the method.

> It would probably be more useful to simply describe the process and
> provide some example URLs. I find English much easier to read than
> bash/grep/head/tail/cut/awk/sed.

Parsing the capabilities.xml file will still be a chore regardless of
v.in.ogr to read the actual data.

Tile merging parts of the code can be probably be replaced by the python
scripts that come with GDAL.

Most of the gratuitous magic can probably be abandoned.

 xml header setup:
http://www.gdal.org/frmt_wms.html

 example URLs:
http://grass.osgeo.org/grass64/manuals/html64_user/r.in.wms.html

 WMS spec in document #06-042:
http://www.opengeospatial.org/standards/wms
http://www.opengeospatial.org/standards/is


> So, r.reclass and r.recode each need a file=
> (G_OPT_F_INPUT) option.

better to make their existing rules= options interpret "-" to mean from
stdin (if they don't already) and keep the module interfaces that much
simpler.


> d.path.sh combines d.vect and d.path. The d.vect step was necessary
> when d.path used the mouse to obtain the coordinates, so that the user
> could see what they were supposed to be clicking on.
> That's no longer applicable.

if needed the full d.vect step could become a flag in d.path.


> More generally, is there any intention to fix up gis.m with regard to
> the various changes in 7.0, or are we going to abandon it and rely
> upon wxgui instead?

My vote for grass7 would be to finally focus our finite energy on
supporting a single (wx) GUI.


Hamish