At 01:42 PM 7/21/2003 +0200, Andreas Poth wrote:
>during the weekend I had a closer look at the current state of the geoapi
>sources and found that there has been no or just a few changes in the
>geometry package for some month. So I created a coarse list of things that
>should be changed and/or have to be elaborated in my opinion. I hope this
>will initialzing a new discussion to continue the development of the
Sorry for the delay in responding to this, I've had to cut back on OGC
involvement for a while recently but I should be ok to dig into things
I should say at this point that John Davidson has a new version of the
conversion scripts out and a new set of java classes built from them. The
major difference, as far as I know, it that it now combines geometry, cts
and a lot of other OGC specs. The packages have changed as well. I've not
looked into them properly, but as far as I know the scripts are essentially
the same, just the UML the classes came from have been unified. (JohnD if
your still reading this list, feel free to elaborate!)
That said, I will comment on your comments, as the key points are still valid.
>GeometryRoot getTransform( String newCRS );
>GeometryRoot transform( String newCRS );
>because the method doesn't return an attribute of a GeometryRoot instance
>but it performs a transformation
Agreed, there are a few derived values like this, I think in the UML some
of them were marked as such whilst others were hard to separate, I'll take
>GeometryRoot getBuffer( Distance radius );
>GeometryRoot getBuffer( Distance distance );
>because only for a point geometry the buffer is a circle that has a radius
ISO19107 calls it radius, but my understanding is that the name is
unimportant (as far as the standard goes) so we should be free to change it
in our version.
>I would like to suggest of two additional methods:
>/** returns the number of segments building the curve */
>/** returns the curve segment at the passed index */
>CurveSegment getCurveSegmentAt(int index);
OK, that throws open a more general discussion. Convenience methods are
clearly a big win that makes our life easier and everyone who uses the
interfaces life easier. Additional methods do not stop something being ISO
complaint so in that sense there is no 'harm' in adding them.
>why do we need 'setXXX'-methods since the boundary of a curve is
>represented by its start- and end-point (which are not mutable)?
This is a mistake in the scripts, I was having trouble telling what was and
was not mutable from the UML automatically, I'll check JohnD's latest
scripts and see if the situation is any better.
>why do we need a 'void setPrimitive( Primitive primitive );' method?
>A lot of classes have setXXX-methods for parameters that only shall be set
>when constructing/initializing an instance of the class. So these
>parameters shall be passed calling the classes constructor. E.g. if the
>'setCoordinateReferenceSystem(String)' will be called not just an new CRS
>will be set but the coordinates of the DirectPosition must be transformed.
>So if we need that kind of method we should call it 'transform(String)'
>like in GeometryRoot.
>There are many other examples like this. For some classes and attributes a
>public setXXX-method makes sense but in my opinion for most it don't.
Agreed, again this was a problem telling them apart from the XML that was
generated from the UML.
>I suggest four additional methods. Because simple topological operations
>on envelops are very frequent and can be implemented to be very fast it
>seems to be a good idea to implement them directly to avoid the overhead
>of using general topology-classes
>/** returns true if the bounding box contains the passed point */
>boolean contains(Point point);
>/** returns true if passes envelope is within this envelope */
>boolean contains(GM_Envelope bb);
>/** returns true if this envelope intersects the passed envelope */
>boolean intersects(Envelope env);
>/** returns a new Envelope object representing the intersection of this
>* Envelope with the passed Envelope. */
>Envelope intersection(Envelope env);
Ok, we need to resolve the mechanism by which we add methods, but they are
indeed very handy.
Actually, this reminds me of a more general point....
You will note however that none of the geomtery objects have contains,
intersects, overlaps etc methods this is because, although ISO19107 talks
about them they are not formally part of the UML model.
My understanding, from talking to JohnH, is that it is expected that these
would be carried out by helper objects.
i.e. rather than a.overlaps(b);
This actually separates quite neatly the storage of geometries from the
operations we perform on them. Normaly in OO design I'd say combine the
two (as JTS does for example). But we may gain a lot by separating the two
out. What are your thoughts on this.
>I think aggregates and multi geometries should have mutator methods like
>'addXXX' and 'removeXXX'.
I'll be in the CITE telecon shortly and I'll try and post further comments,
ideas as they come to me.
All the best