[Java-collab] Re: geometry next steps

[Markus Schneider]

Hi all,

Jody Garnett wrote:

> I was hoping to write code examples in order to compare how easy the
> code is to read / use / understand. I don't need the classes to work for
> that; only to define the factory interfaces. Many of the trade-offs I
> would like to make at this stage are about making the work accessible to
> java programmers (and if we are keen - reducing the number of keystrokes
> they need to type). I also should check that the "mvn javadoc:javadoc"
> target works and review the resulting javadocs.

Looking at the amount of emails and subjects, I got the feeling that we should focus on the representation and creation
aspects first. Especially the integration of operations appears to be quite a subject and we will need time to check the
different approaches (e.g. the one proposed by Jorge). And there seem to be enough issues to be solved first. Therefore
I would suggest the following next steps:

1. Remove all topological and spatial analysis methods in the interfaces from the SVN for now, so we can focus on
sanitizing the model. Of course we would take on the operations subject again, when we find consensus here.

2. Add factories. I would like to add two factories similar to the ones in the deegree 3 SVN:

SFS geometries:

- http://download.deegree.org/deegree3/nightly/core/javadoc/org/deegree/geometry/SimpleGeometryFactory.html

ISO 19107/GML 3

- http://download.deegree.org/deegree3/nightly/core/javadoc/org/deegree/geometry/GeometryFactory.html

In deegree 3, these factories are bound to a JTS-based implementation. As we only have interfaces for the geometry types
in the osgeom repository for now (and no implementations), I would create interfaces from the factories.

3. Add a basic implementation that is just a bean representation without operations. We could finally start to add JUnit
tests then.

4. Add GML parsers/exporters. I understood that one may want to keep this aspect out of the repository, but I don't see
how we could test the difficulties in representing GML geometries (e.g external xlinks) without this. It also would make
setting up geometries for testing much easier. Maybe we could keep the GML parsing/exporting isolated from the rest of
the code.

A huge benefit would be people can actually start to put the library to use -- and this will most likely add momentum to
the whole project.

> Actually do we have a place where we could publish the javadocs; we
> would get more feedback from this email list if there was a link to
> javadocs to review.

Can you make sure that the javadoc target works? We can set up an automated build process and publishing of the javadocs
(probably next week). BTW, the deegree 3 geometry javadocs can be found here:
http://download.deegree.org/deegree3/nightly/core/javadoc/

Best regards,
Markus

-- 
Markus Schneider

l a t / l o n  GmbH
Aennchenstrasse 19           53177 Bonn, Germany
phone ++49 +228 184960       fax ++49 +228 1849629
http://www.lat-lon.de        http://www.deegree.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
Url : http://lists.osgeo.org/pipermail/java-collab/attachments/20090820/ae43d03f/signature.bin