[Java-collab] Re: geometry next steps

[Markus Schneider]

Fellow geometry collaborators,

I will be on vacation until September 21. I won't have internet access, so you won't see any posts or SVN commits from
me for a while.

But I will be eager to work on the announced steps when I am back.

Best regards,
Markus

Markus Schneider wrote:
> 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
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Java-collab mailing list
> Java-collab at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/java-collab


-- 
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/20090828/d4dc4ff0/signature.bin