Hi,
2008/4/8, Markus Neteler <[EMAIL PROTECTED]>:
> > 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
take a look at 'render' module (class 'Map' and 'Layer').
> > tables and columns for the latter. I've gone through the code a
you mean attribute data of vector map layers (?) ('dbm' module)
> > couple of times, but I'm missing something.
Markus:
> 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 :-)
For sure there are thousand of issues to be improved;-)
Martin
> Here we go:
>
> [ http://lists.osgeo.org/pipermail/discuss/2008-April/003345.html ]
>
> On Mon, Apr 7, 2008 at 4:26 PM, Howard Butler <[EMAIL PROTECTED]> 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
> > [EMAIL PROTECTED]
> > http://lists.osgeo.org/mailman/listinfo/discuss
>
> _______________________________________________
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
