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.
Thanks,
Jaime
Jaime, all,
On Tue, Apr 8, 2008 at 12:05 AM, Jaime Carrera <jaime.carrerah@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@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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss
Hi,
2008/4/8, Markus Neteler <neteler@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@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@lists.osgeo.org
> 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 *