permaculture

[lflondon@mindspring.com]

On Wed, 23 Jan 2002 12:14:38 +1100, in alt.permaculture Craig Ambrose
<bast@vurt.net> wrote:


Those are some hefty requirements there Ute. :) To date, I've been
more 
interested in the permaculture design of the site itself, rather than
the 
resources and actions required to achieve the design. So while I
haven't 
used CMS, it certainly looks a bit over the top for most people to use
(or 
afford) to get stuck into permaculture design. Your point 2 would 
definatelly be doable with my proposed software, amongst other things.

Since we have a livelly discussion going here, I'll describe our
current 
design in a little more detail.

Entity Database
---------------

The simplest and possibly most essential part of the program is a
database 
of entities. An entity is any type of "thing" which you might want to
use 
in a permaculture system, such as a particular species of plant or
animal, 
a water tank, a chicken tractor, and so forth. This database is not 
revolutionary in itself, there are excellent plant databases and so
forth 
out there, and I hope to make this database compatable with the most 
popular ones so that we can get some usefull data in there straight
away. 
The unique aspects of this, however, are that the database will be
designed 
to handle all different sorts of entities (not just plants), and that
a 
complex collection of entities can also become an entity in itself.
For 
example, a herb spiral contains many entities, but a pre-designed herb
spiral could also be treated as a single entity if the user wishes.

Other planned features include being able to wack any other types of 
information onto the entity (even if the program doesn't use or
understand 
it), so that other programs could use it. For example, you might
include 
cullinary uses, or medicinal uses, onto some of your plants, even
though 
that may not really relate to site design. Also, entities will be able
to 
be dragged out of the database which will export them as self
contained XML 
files which include all the required data and graphics to email them
to 
another person and share your interested data in that way.

One of the important sets of data attatched to each entity is their 
interactions with other entities. Interactions take the form of
"products", 
which are any component, action or yield, which an entity might
produce (or 
require). Entities can produce products, at certain times, in certain 
amounts, from certain locations, and distribute them in certain ways.
In a 
similar fasion, entities can require products. Part of the system
designer 
software's job (see below) will be to analyse the
production/requirement 
interactions based on entities in the system.

I envisage that people will want to share data, and use data from
known 
reliable sources, but will also want to experiment and slowly build up
some 
reliable local data through personal experience. The database will be
able 
to handle multiple sources of data, including rules for layering them 
together. For example, perhaps you download a database to use as your
basic 
information, but since you live in the tropics, you notice that tree X
takes only half as long to reach full height. In that case, you can
enter 
that data in your own layer within that database, and set that layer
to 
override other layers. So, you will use all the data provided in your 
existing database about tree X, including images and so forth, except
that 
it will override the single field (growth rate) that you have entered
data 
for with the value that you have specified.

Like I've said, the database itself is not entirelly revolutionary,
and may 
be usefull for many things other than permaculture, and we are hoping
to 
release everything required to use the database fairly early on in the
project, and free of charge. We also want to provide extensive support
for 
the database, and make improvements based on feedback, because we hope
to 
impress people enough with the quality of our database, and our
customer 
support, that they consider buying the full permaculture design
program 
when it is ready. 

System Designer
---------------

The aim of the system designer, is to let people apply some of the 
permaculture design principles to a permaculture system, using the
entities 
from their database, as well as information about the site. A system
can be 
a simple construct which does not take place in an environment, or it
could 
be a full site plan.

An example of the former case might be if you were attempting to come
up 
with a guild of companion herbs that would work well together. You can
use 
your database to try many different combinations of plants, and
analyse the 
relationships. The resulting system could be saved and then you could
place 
it on a real site to analyse how it might work for you in practice.
The 
companion planting aspects I'm describing here might sound simplistic,
but 
the idea is to present a system in varying degrees of abstraction
(levels 
of visible detail) so that you aren't bombarded with too much data at
once.

To visualise these systems, we envisage allowing systems to be viewed
and 
designed in one, two or three dimensions.

A one dimensional system is not at all usefull for actual site design,
but 
it is very simple and might help in determining guilds or simply
analysing 
how your current data behaved. In a one dimensional design, all
entities 
occupy the same point in space, so all possible interactions will
occur. 

A two dimensional view is a top down view of an actual site design.
Each 
entity is represented by a 2D image, which can be scaled, moved and 
rotated. There are some things which can't be represented in 2D as
well as 
they can in 3D, but many computer users become lost when attempting to
control a 3D viewpoint, may spend more time wrestling with the program
than 
actually using it. Also, by using a seperate 2D view (rather than just
a 
top down view using the 3D graphics engine), we have a few advantages.
Firstly, the 2D view can be run even on very old computers that
wouldn't be 
fast enough to render 3D graphics. Secondly, 2D views can easily be
printed 
and the result will be the same as what you see on the screen. And
thirdly, 
we hope to give the 2D view the look of an attractive colour
draftsperson's 
drawing (such as the front cover of Mollison's "Introduction to 
Permaculture") rather than attempt a more photo-realistic approach.

We hope that the three dimensional view will give a more realistic
use, and 
could be used to visualise your system from many different angles.
Most 
importantly, however, a 3D view lets you place your entities in 3D
space an 
analyse the results. This is much more like a real system, where
things are 
on top of each other, or on a steep hill. Obviously, importing 3D
terrain 
visualisation is usefull here, and compatability with existing terrain
visualisation and GIS software is important.


The Development Process
-----------------------

I'm the first person to admit that some of our goals are fairly lofty.
The 
3D graphics areas will be the most complex, not so much from a
technical 
standpoint (I used to write 3D computer games for a living), but from
the 
perspective of making it usable and usefull for the user.

Our goal then is not to attempt too much in one go, but to perform
cycles 
where we add a few new features, and then thoroughly test and debug
and 
ensure that we are still on track. At the moment, we haven't reached a
stage where we have a usefull program, but we intend to release
software at 
several points along the way.

Firstly the database, as I've mentioned, we want to release free and
then 
improve based on feedback.

We will then get the one dimensional view working, which tests the
data and 
much of the analysis areas of the program. There probably isn't any 
commercial demand for this by itself (feel free to tell me otherwise)
but 
we will certainly welcome testers at this stage.

The two dimensional view comes next, and when the program is working
well 
at this level, we plan to release version 1.0. 

Adding the 3D elements will probably bring us to the second commercial
release (2.0) and would probably take quite a while to do. 

Will will obviously release intermediary versions (1.1, 1.2 etc) when
they 
are stable, either as free updates or for a small price (bug-fixes
will 
always be free). 

Internally, our contributors are members of a co-operative who do not
get 
paid as they work, but we record all time spent on the project. Any
profits 
made get divided up according to this ratio. Our main strategy to
combat 
piracy is simply to provide very personal customer service (it's a
very 
small market), and also to publish records of our current net profit, 
labour input, average hourly wage and so forth, so that people can see
if 
we are succeeding in our effort to make a living out of it. It is
certainly 
unlikelly that anyone will become rich contributing to this software.

Target Audience
---------------

Our main target, at least with the version 1.0 release will probably
be 
owner-designers without a great deal of knowledge of land surveying,
GIS 
software or high tech site management stuff. Providing for the needs
of 
design consultants is much more difficult, and some of these people
might 
be willing to shell our a couple of grand for some of the existing
site 
management packages (although they aren't permaculture focused). 

I'm currently WWOOFing my way around australia as I work (thanks to a
solar 
powered laptop), and I've already talked to a few people about the 
software, including David Holmgren. David's views were cautiously
mixed, 
and I would certainly like to hear from other professional designers
as to 
whether this software could possibly meet their needs as opposed to 
existing programs.


--------

Well, that was rather a long rant. I didn't cover everything, by any
means, 
but hopefully I've provided plenty of fuel for more discussion.

thanks for listening

Craig




L.F.London ICQ#27930345 lflondon@mindspring.com
http://www.ibiblio.org/ecolandtech  london@ibiblio.org