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

[Markus Schneider]

Hi Jody,

some comments:

Jody Garnett wrote:

> > 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  :-)

I liked it, because it's short and describes what it does precisely. But I also see your "Point" (haha!), so I would
suggest something like PointSequence instead.

> > - 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...)

You're correct, we didn't work out this one yet. This is why the GeometryFactory doesn't provide methods for creating
Points/PointSequence instances. If we want to add this to the duties of GeometryFactory, we probably should distinguish
between the two important types of PointSequences that occur during the construction of geometries:

- (Large) number of anonymous points: create-method that gets an ordinate-array
- Points (with identifiers): create-method based on a collection/array of Point objects

However, I feel that some Points implementations are mostly interesting to internal operations: e.g. PointsPoints. And
for PointsPoints (implementation that aggregates the members from a sequence of {@link Points} objects), multiple
implementations actually don't make sense (as it can be used aggregate any type of concrete Points objects), so there's
no real need to put a method for this type into the factory.

> > - 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.

I am sorry, but I don't understand this. Can you please elaborate?

> > 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).

Thanks for the proposal. Yes, our schedule is rather tight until the end of the year. But now and then I probably would
find the time to participate and contribute -- especially as some more aspects related to geometries have to be working
for d3 during this time (most important: storing non-linear curves in PostGIS) and I would like to discuss some ideas.

Unfortunately, we probably have to get back to the SVN question again. As we discussed during the chat (and in private
mail), there's still the problem that we don't fully understand the legal implications of the copyright assignment paper
and cannot overlook the consequences of that paper for a non-US legal institution (as our company is). Therefore I
cannot sign it at the moment.

I would really like to be able to put an end to these legal issues holding back the technical collaboration. Can we
maybe move the code to an independent SVN location?

Best regards,
Markus

P.S.: Sorry again for the trouble I am causing here -- especially considering that I was fine with the GeoTools SVN at
first...

-- 
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/20091028/c8415bed/signature.bin