[GRASS-dev] developing a GUI wxgrass-based

[Martin Landa]

Hi,

2008/4/8, Markus Neteler <neteler at osgeo.org>:
>  >  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 <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
>
> _______________________________________________
>  grass-dev mailing list
>  grass-dev at lists.osgeo.org
>  http://lists.osgeo.org/mailman/listinfo/grass-dev
>


-- 
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *