[Java-collab] Enums and Switch Statements; ID and URN Resolvers; attached properties

[Jody Garnett]

On 12/08/2009, at 3:58 AM, Markus Schneider wrote:

>
>>> - 1 ObjectProperties interface (org.osgeo.commons.ObjectProperties):
>>> Placeholder interface for properties that can be attached to  
>>> Geometry
>>> objects. One important use case are the GML standard properties that
>>> each GML geometry object allows for (e.g. multiple  
>>> gml:metaDataProperty
>>> elements, gml:name and gml:description properties).
>>
>> I assume these are going to be lazily created as needed in order to
>> avoid the memory overhead?
>
> Sure. It could also be attached only if needed, so  
> #getAttachedProperties() just returns null if the geometry has no
> such properties.
>
>>> - 1 PrecisionModel interface
>>> (org.osgeo.geometry.precision.PrecisionModel): Placeholder  
>>> interface for
>>> a precision definition that can be attached to geometries. It's  
>>> not 100%
>>> clear to me yet how this should be defined and how to interoperate  
>>> with
>>> topological operators, spatial analysis and the exporting of  
>>> geometries.
>>
>> They amount to "rounding" with a bit of metadata to tell what kind of
>> numeric field we are working ontop of (floating point; or fixed
>> point). This information would really like to be stored with the CRS;
>> indeed if I was in a greenfield situation I would record this
>> information for each Axis. When you are implementing an operation you
>> use the precision model to round the answer as you go; when you have
>> performed "enough" recursion your rounded answer is the same as the
>> rounded answer of the previous iteration. This sanity check is used  
>> to
>> avoid doing more work then needed (ie why calculate to twenty decimal
>> places if the WFS output format is only going to print out eight
>> significant digits? It is also used to ensure that the resulting
>> geometry is actually valid at the indicated precision - it is easy to
>> make a geometry that is valid; and then serve it up with the correct
>> precision and have it be invalid. Usual example is a line string that
>> when served up has both the start and end point in the same location.
>> This concept also effects intersection; where the lines are produced.
>> Internally it can notice that the start and end point are the same;
>> and provide a Point as a result rather then a LineString.
>
> O.k.
>
>>
>>> - 2 beans that represent parameter sets needed for the definition of
>>> certain curve segments:
>>> org.osgeo.geometry.primitive.segments.AffinePlacement and
>>> org.osgeo.geometry.primitive.Knot. I think that it doesn't make  
>>> sense to
>>> allow different implementations here, and therefore these are  
>>> classes,
>>> not interfaces.
>>
>> Small comment:
>> - KnotType is an enum - we may need an open set of types here? Rather
>> then a closed set up enumerations. Do you have anything similar to a
>> CodeList? Basically before Java 5 Enum provided syntactic sugar it  
>> was
>> always possible to set up an object like an Enum; and when you do it
>> yourself you have the option of adding more constants over time.
>
> IMHO, we don't need an open set here. Is there any difference  
> between the other enums (e.g. CurveType) and KnotType? If
> there's coming more in GML 4, we just would have to extend the enum  
> types. I think with open enums you lose the main
> benefit: the certainty that you are really handling all possible  
> cases in a switch.
>
>> - Just for consistency refactor KnotType into an internal class (ie
>> Knot.Type) in order not to pollute the file system with what is an
>> detail of the Knot class.
>> - Geometry.GeometryType can also be changed to Geometry.Type - and
>> should also be an open ended set?
>> - MultiGeometry.MultiGeometryType?
>> - Curve.CurveType? especially this one
>
> Agreed.
>
>> - Primitive.PrimitiveType - this one is especially interesting as it
>> should be the D in your DIM-9 matrix; as such I would be tempted to
>> supply my own ordinal values here in order to make any relate code
>> much easier to read.
>
> Interesting. How would this look like?
>
>> For many of these "types" I am wondering why they are required as  
>> they
>> seem to duplicate information already present in the class hierarchy?
>> Example Geometry.GeometryType.ENVELOPE is duplicated by the Envelope
>> class is it not?
>
> Correct. It's a convenience thing, but there's also a very important  
> technical problem that they solve:
>
> In order to cope with xlinked geometries (e.g. a MultiGeometry that  
> references it's member's contents by xlinks), we
> wrote Proxy geometry types:
>
> https://svn.wald.intevation.org/svn/deegree/deegree3/core/trunk/src/org/deegree/geometry/gml/refs/
>
> These allow for easy handling of document internal xlinks and the  
> lazy resolving of external xlinks -- e.g. if a
> geometry containing xlinks is traversed, the referenced external  
> geometries can parsed on the fly. However, if we only
> know that a reference is of type gml:_Geometry, we can only use an  
> unspecific GeometryReference proxy. And this makes
> instanceof-switching impossible here. And this is solved by using  
> the #getType() methods for discriminating the geometry
> types. However, if we find any better way to deal with that  
> challenge, we could of course remove them.

I get the use case; the suggestion to use class is equivalent (and  
probably me just being lazy and not wanting to write the same  
documentation once). Here would be an example ...

class MultiGeometryImpl  implements MultiGeometry {
   ...
   Class getType(){
       return MultiGeometry.class;
   }
}

And then do the switch statement using the getType() method:

switch( g.getType() ){
case MultiGeometry.class:
...
}

In anycase it is probably a stupid idea ... moving on :-)

When defining these Enums it would be nice to load them up with  
additional information to help with encoding / decoding using  
annotations or otherwise. I hate writing switch statements in order to  
"lookup" gml mapping element names; when that is kind of our starting  
point.

>>> - #getId() / #setId(). As ids are very integral to GML, I provided
>>> methods for working with the identifier.
>>
>> We have been forced to make up or own Identifier - in response to
>> GMLObjectIdentifier in order to handle namespace issues. Will a  
>> simple
>> string be sufficient here?
>
> Interesting. Can you elaborate why a string does not suffice here?  
> In GML, they are just defined as XML IDs, so the only
> restriction is that they must match the NCName production rule (and  
> are unique in a document).

I did not follow this development completely;  I think it was more  
related to the WFS getGMLObject method or something? Basically the  
idea of having a unqiue identifier that would last for more then a  
single document.

Ben's crew has done some magic with a URN resolver or something that  
allows them to negotiate the difference between IDs in a single  
document and a subsequent request for more information. I did not  
pretend to keep up with their work so we may need to ask him for  
details.
>>
>>> - #getAttachedProperties() / #setAttachedProperties(...) for  
>>> coping with
>>> the GML standard properties that each GML geometry object allows for
>>> (e.g. multiple gml:metaDataProperty elements, gml:name and
>>> gml:description properties).
>>
>> Commented above about lazy creation; I would consider leaving this as
>> an implementation details (ie the creation of an internal Properties
>> object and/or Map) and adding methods for getName(), getDescription()
>> etc... although it depends on how many of these we expect to ahve?
>
> Just would like to throw in that we should avoid to make this too  
> GML (and especially GML-version) centric.

Oh - I thought we were making this specific to GML (from the IRC  
meeting).

In any case can I ask if "attached properties" is part of GML; or is  
it just a scratch pad for extra information associated with a geometry?

> Thanks for the valuable input, Jody. For the details on interface  
> vs. class see above.

No worries; I am sure I missed a couple sections in your email. If you  
are expecting more; or would like to discuss something I glossed over  
please just start up another email thread.

I am also happy with using Interface/Factory/Builder rather than Class  
but I want us to go into that decision with our eyes open. I recognize  
the enormous cost in complexity; and feel I too often go with  
interfaces.

Jody