[GRASS-dev] developing a GUI wxgrass-based

[Markus Neteler]

Jaime, all,

On Tue, Apr 8, 2008 at 12:05 AM, Jaime Carrera <jaime.carrerah at gmail.com> wrote:
> Hi,
>
>  I was wondering if someone could give me some kind of orientation on
>  how wxgrass accesses the list of raster/vector maps and both the
>  tables and columns for the latter.  I've gone through the code a
>  couple of times, but I'm missing something.

I have no answer for you but I report an email from Howard Butler
here (GDAL Python guru) which might be (partially) relevant to improve
our code documentation. Perhaps I am wrong and it's all fine.. no idea :-)

Here we go:

[ http://lists.osgeo.org/pipermail/discuss/2008-April/003345.html ]

On Mon, Apr 7, 2008 at 4:26 PM, Howard Butler <hobu.inc at gmail.com> wrote:
> > Markus Neteler wrote:
> > > Hi OSGeo,
> > > I would like to propose another idea which might be a (long term) goal
> > > of OSGeo software development:
> > >    OSGeo Python Library
> > >    http://wiki.osgeo.org/wiki/OSGeo_Python_Library
> > > Currently it is quite complex to set up a Python based OSGeo software
> > > environment without knowing well the individual projects. It would be great
> > > to have a common abstraction layer/API which contains binding to several
> > > relevant OSGeo and related software projects with Python bindings to
> > > simplify programming.
> > > Hacks to the Wiki page and comments welcome,
...
>  I think the most fruitful way to make it easier for folks to be able to use
> Python for geo stuff is to ensure that projects do the following:
>
>  1) Embrace PyPI.  I made a major push with GDAL 1.5 to allow it to be built
> from *outside* the GDAL source tree.  This means that a user can install
> gdal-bin and gdal-devel with their favorite package management system and
> then do "easy_install GDAL" and have working bindings.  I would like to get
> Python MapScript to this point as well, but doing so will require a bit more
> effort than GDAL to get MapServer's source tree in shape (MapServer isn't
> really split into -devel and -bin, it's all just a big ball right now).
> Projects that aspire to be on PyPI and be easier to use from a Python
> perspective should ensure they're using Python distutils/setuptools and not
> require that an entire source tree of dependencies be available to build
> themselves.
>
>  2) Leverage Python docstrings.  I also made a lot of effort to include
> Python docstrings in the OGR 1.5 release.  I haven't gotten to GDAL's yet,
> but I hope to in the future.  doctests, which are Python's name for
> combining documentation with regression testing, are also an excellent way
> to provide leverage.  Python users have been heavily conditioned to look for
> doctests/docstrings in other Python libraries, and the OSGeo camp should
> follow suit.
>
>  3) Support things like __geo_interface__ and numpy's array interface.
> Python makes it so easy for everyone to write their own that everyone does.
> There are bits that everyone can agree on, and those are the points at which
> easy integration of the various libraries can be made.
>
>  Howard
>  _______________________________________________
>  Discuss mailing list
>  Discuss at lists.osgeo.org
>  http://lists.osgeo.org/mailman/listinfo/discuss