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

[Jody Garnett]

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

I was thinking PointString to be consistent with all the other
"String" classes in the API. I also wanted to ask if we had imagined a
PointString that could have contents added / removed? Or are we
strictly a write once affair.

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

Okay let us stay simple; we will provide implementations of "Points"
and trust users to choose the correct one based on what they want to
do; we may end up needing some kind of "copy" or "prototype" method in
order to account for editing or resampling code.

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

Owe - my brain!  Okay we have reached the same conclusion; concrete
implementations that users know by name.
My story for a "prototype" method allows people to copy and keep the
same implementation that was passed in.
- points.create() - creates an empty instance
- points.create( Iteratable<Point> ) - creates a populated instance;
may optimize itself to detect Points parameter

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

Class binding = GeometryFactory.binding( GeometryType.POLYGON );

This allows us to know what to do when faced with an implementation
that does not support compound curve; it can return a normal curve and
simply linearize the input as it is read in. I need this sort of thing
when writing a hibernate user type for example. Based on the factory
used I would like to be specific about how the content is made
available to java code.

If this is outside of the geometry api I will look at creating a
wrapper for this functionality.

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

I think the WKTReader we used supports reading the WKT for Curve; Mark
was going to look at porting the WKB for postgis curve; so there is
room for collaboration on this one.

Jody