[Java-collab] Re: Data for FOSS4G geometry code sprint, modules, and factories

[Jody Garnett]

The separation of concerns is fine; and is working well. I will not be
in a position to evaluate the API until we can work on code examples.

It appears as if we have a short list of items from email discussion to apply.

I also ran into some interesting corner cases:
- naming of "Points" will need to change :-)
- Implementation of Points will need to be sorted out; do we add a
factory method:
  PRO: (to promote the use of a consistent set of Geometry+Points
together? Very useful to use a JTSCoordianteSequence based Points
implementation when working with a jts-wrapper geometry
implementation).
  CON: Points implementation usually chosen based on what
implementation provides (shapefile provides double[]; oracle provides
NUMBER[] etc...)
- data access needs to know the target interface; so we have a second
use case for your nice Enumerated types; pass in an enumerated type
for "Surface" and get back JTS Polygon when working with JTS; or
Surface when working with GML Geometry? This may be a geotools only
concern; not sure what you think of the use-case.

Apparently we have more ideas then time, I would like to continue
working on this while you push for deegree3; and see if we can arrange
a second session based on your release schedule (although I am not
sure how the others feel about this).

Jody
On Wed, Oct 28, 2009 at 1:47 PM, Ben Caradoc-Davies
<Ben.Caradoc-Davies at csiro.au> wrote:
> I have attached a photo of the whiteboard. I got a WKTReader working for one
> type (LINESTRING). Support for other types is close.
>
> Thanks a lot, Markus, for your help. The API looks pretty sweet.
>
> Kind regards,
> Ben.
>
> On 25/10/09 15:48, Jody Garnett wrote:
>>
>> On 25/10/2009, at 10:06 AM, Markus Schneider wrote:
>>
>>> If anybody is listening: I am on #geometry-collab right now.
>>
>> Thanks to Markus for joining the geometry code sprint remotely. Here
>> are some notes; too sleepy for discussion / explanation... hopefully
>> Ben can fill in the blanks.
>>
>> Our List on the board was....
>>
>> 1. interface
>> - we went with what was there
>> - noticed a few things that we talked about on email that were not
>> there yet (naming of nested Enums for example)
>> - adjusted Points to have CRS; and to separate out number of
>> significant axis from the number of ordinates used (ie if there are
>> measures)
>> - the name "Points" messes me up when I try to talk to humans -
>> example sentence from today that confused Ben: The "Point"s from the
>> Points need to be copied into an ArrayList of "Point"s prior to
>> calling the factory method
>>
>> 2. implementation
>> - used deegree code as a start
>> - placeholder UOM, Angle, Length and CRS will work for compiling but
>> they really will not last us a very long time
>> - CRS<T>  looks like an okay way to offer a wrapper around geotools
>> CoordianteReferenceSystem; need to try code example to see if it is
>> terrible to program with or not -P
>>
>> 3. factory - done (revised through some use)
>> - removed the method create as in code example:   factory.point( null,
>> crs, coordinates ) is obvious; "create" and "factory" communicate the
>> same information
>> - removed helper methods in order to have minimal method exposure
>> (hopefully we can remove more)
>> - added method to create points
>> - handling of Points may require separate factory? At the very least
>> we need two create methods to capture the general (List<Point>) and
>> fast (double[]) case
>>
>> 3. builder
>> - SimpleGeometryBuilder is method compatible for deegree
>> SimpleGeometryFactory to ease transition
>> - GeometryBuilder is method compatible for deegree GeometryBuilder to
>> ease transition
>> - working on a jts method compatible builder now (ie method compatible
>> with JTS GeometryFactory )
>>
>> 4. extras
>> - wktreader - ported from jts w/ curve from geotools; accepts a
>> GeometryFactory and a CRS and gets to work
>> - DuplicateGeometry used to copy a geometry using a provided factory
>>
>> --------geotools branch ------
>>
>> 5. PropertyDataStore
>> - forked geotools in order to try out the interfaces / factories
>> - converters added to allow PropertyDataStore to read in a Geometry
>>
>> 6. Render
>> - need to add converter to JTS Geometry in order to get to a Shape to
>> render (we can go directly to Shape later when we get a decimate going)
>>
>> Jody
>> _______________________________________________
>> Java-collab mailing list
>> Java-collab at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/java-collab
>>
>
>
> --
> Ben Caradoc-Davies <Ben.Caradoc-Davies at csiro.au>
> Software Engineer, CSIRO Earth Science and Resource Engineering
> Australian Resources Research Centre
> 26 Dick Perry Ave, Kensington WA 6151, Australia
>