[Java-collab] invokeOperation and Jody's stupid idea

[Jody Garnett]

Hi Jorge and Matthias:

I was inspired by a couple of excellent email's you sent this week.  
The difference between inspiration and stupid ideas is a thin line -  
thus I would like to ask your help and clarity in either bringing  
these ideas home; or tossing them out.

>> Indeed I would rather *not* have the "invokeOperation" as part of  
>> the Geometry; since I expect to have a switch board of operations  
>> to choose from based on the geometry involved; CRS being used and  
>> so on.
>>
>> Jorge are you familiar with the operation split in JTS? The recent  
>> operation for  PrepairedGeometry construct? It is used to hold onto  
>> intermediate results (edge graphs and so on).  This is what I  
>> envision for a GeometryOperationContext ...
> No, I'm not familiar but I'm going to have a look.

This first one is for Jorge as you have identified the all important  
boundary between the geometry and the operations. I do hope you have a  
chance to review JTS PrepairedGeometry and consider that in relation  
to the "GeometryOperationContext" you talked about in your email.

The second aspect of this idea is the Design Pattern "Half Object" (or  
Half Object Plus protocol when it is being distributed).  I could not  
find much by way of good links (http://www.eventhelix.com/RealtimeMantra/HalfCallDesignPattern.htm 
, http://javadesktop.org/articles/canoo/ , http://www.c2.com/cgi/wiki?HalfObjectPlusProtocol) 
. These all seem to focus on using the "half object" technique to sort  
out networking between N different protocols. By splitting things in N  
half objects they have 2 N implementations and some runtime cost to  
"wire" them together. If they did it as complete objects they would  
need NxN implementations.

I feel this "half object" approach could be used to provide a the  
"edge graph" from one geometry; and another half object could be used  
to supply the edge graph from the other geometry. Then using both edge  
graphs we can implement an operation and produce an answer.

The PrepairedGeometry construct represents *one* half object in my  
thinking. Martin Davis motivation was an optimization - to vastly  
increase performance in JTS and GEOS (http://lin-ear-th-inking.blogspot.com/2007/08/preparedgeometry-efficient-batch.html 
).

I would like to stick two of these objects together into a "context"  
for the operation to run - so is this a stupid idea? what do you think?

> It looks an interesting approach the usage of the CRS. But there is  
> a small detail that I hid in my last email to simplify the example.  
> Really we don't use "2" to define the dimension. We use a set on  
> constants in our application to classify our geometries:
>
> - GEOM2D
> - GEOM2DZ
> - GEOM2M
> - GEOM3D
> - GEOM3DM
>
> "M" means the "M coordinate". In a future we also can add geometries  
> with Time or other classes of geometries. If you only uses the CRS  
> is not possible to specify if you want a geometry with support for  
> the M coordinate.

The set of constants above is much more sane/readable (indeed I I  
found a set of constants for the different dimensions in the code  
Markus provided as well). Aside: I would like to account for  
additional measurements (beyond those tracked by the CRS - ie xyz and  
measures).

However this idea - combined with Markus's CRSInfo idea...

> I put a low of thoughts in this, but finally came up with a simple,  
> clean solution I am very happy with. I simple created an immutable  
> wrapper around the immutable GeoAPI CRS object. I called it CRSInfo.
>
> CRSInfo has several methods for getting the actual CRS, computing  
> axis order, lenient axis order, CRS dimensions, computing 2D CRS  
> from 3D CRS and others. All computed information is cached. When  
> queried for its CRS, the geometry just returns myCRSInfo.getCRS().

Results in Jody's Stupid Idea # 2

Define "CRS" as per a the crs info idea as a wrapper / adapter between  
the CoordinateReferenceSystem or CoordinateSystem choice and the  
geometry implementation. We would need to provide enough information  
here like Matthias indicates; and we could also include a Enum like  
GEOM2D, GEOM2DZ etc... since both Jorge and Markus like Enums to  
quickly make choices.

Thanks for your patience on this one,
Jody