[Thuban-devel] Re: Base class for Shapes?

[Bernhard Herzog]

Jan-Oliver Wagner <jan at intevation.de> writes:

> On Thu, Nov 25, 2004 at 10:08:44PM +0100, Bernhard Herzog wrote:
>> Jan-Oliver Wagner <jan at intevation.de> writes:
>> > on a train travel from Bonn to Osnabrück
>> > I worked out an idea about a Base Shape Class.
>> 
>> If it's there to reduce code duplication OK (The bounding box
>> computation has been copied several times already).  It should not be a
>> requirement for shape objects to be derived from that class, though.
>
> I had code reduction in mind.
>
> Why should not all Shape objects share the same base class?

The question is whether they should have to, not whether they are.  If
the base class doesn't offer any functionality for a specific shape
class it shouldn't have to be derived from the base class.

> I was not sure myself. In general, Interfaces would be nice,
> but as along as we keep compatibility with  Python 2.2.1 it is
> probably not good to introduce them.

The python version we're using has practically nothing to do with
whether we can use some kind of interface mechanism.  All
implementations I have seen are pure Python, basically, without any new
syntax.  Some implementations may work better with new style classes and
perhaps meta-classes, but that's not really a requirement for a simple
implementation.

I even have a simple working (IIRC :-) ) implementation for Thuban lying
around from last year.  That could be dusted off and checked in.  It
would only be good for documentation purposes and some simple test cases
that check whether an object conforms to the interfaces it claims to
support (only tests for the presence of methods at the moment).

> Aren't there any additional hard requirements all Shape object must have?

It has to conform to the shape interface.

> What about the RawData for example. Shouldn't there by a default method?

If the shape store the shape comes does not have a raw format (returned
by the shape stores RawShapeFormat() method) for which the renderer has
a low-level renderer, it doesn't need the RawData method.  The only raw
format for which low-level renderers exist is RAW_SHAPEFILE.

We could probably clarify the situation a bit by specifying that if the
raw format is RAW_PYTHON, then the RawData method will not be called by
Thuban.

Back when I was hacking on the interface stuff the Interface for shapes
was this:

class IShape(Interface):

    def ShapeID(self):
        """Return a unique integer that identifies the shape

        The integer only needs to be unique among the shapes in the same
        shapestore. It can later be used to reload the same shape
        with the shapestore's Shape() method.
        """

    def Points(self):
        """Return the coordinates of the shape as a list of lists of pairs.

        The coordinate system used is that of the shapestore the shape
        was obtained from.
        """

    def RawData(self):
        """Return the raw representation of the shape's coordinates

        The shapestore the shape was read from indicates what the format
        is with its RawShapeFormat method.
        """

    def compute_bbox(self):
        """Return the bounding box of the shape as a tuple

        The returned tuple has the form (minx, miny, maxx, maxy). The
        coordinate system used is that of the shapestore the shape was
        obtained from.
        """


It basically just describes the status quo of last summer.  The RawData
method should probably be optional, and the compute_bbox method should
be renamed.  It was added ad-hoc at some point.  When the
implementations are updated their bounding box methods should at least
do some caching as in your implementation or get the bounding box from
the shapestore which might be better for shapefiles for instance as it's
stored in the shapefiles.

>> It might be easier to promote bounding boxes to "real" objects.  Then
>> you could do that kind of bounding box arit
>
> not sure how to do that "arit".

I think I wanted to delete that unfinished paragraph before posting :).
IIRC, it would have said something along these lines:

It might be easier to promote bounding boxes to "real" objects.  Then
you could do that kind of bounding box arithmetic with the bounding box
objects.  In Skencil I have a C-object for that kind of thing[1].  That
doesn't fit what Thuban needs exactly, but it wouldn't be much work to
adapt it.

> This explanation could have helped me if in a default Shape.RawData()
> method ;-) Currently we do not have a suitable place in the code to
> put this text.

If we had Interfaces we would.

   Bernhard



[1] Skencil's Rect objects: http://www.skencil.org/Doc/devguide-6.html


-- 
Intevation GmbH                                 http://intevation.de/
Skencil                                           http://skencil.org/
Thuban                                  http://thuban.intevation.org/