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

[Markus Schneider]

Hi all,

here's my best wishes for the geometry code sprint tomorrow. If I got
this correct, then Sydney 10:00 am is 01:00 am here in Bonn. How about
having an irc chat then? Maybe you can already prepare a channel
(#geometry-collab?) as I will probably arrive just in time from a
birthday party :-)

Concerning the test data question: in the deegree 3 core repository,
there's a quite exhaustive test case that checks the correct
representation of most variants of GML 3.1.1 geometries / curve segments
/ surface patches [1]. Of course, we cannot just use this right away for
testing the current collab code, as we would need an implementation of
the geometry interfaces as well as a GML parser first... But maybe it
can be useful for deriving test factory calls from the GML snippets.

Another thing: you guys may stumble upon the usefulness of the enums
(e.g. GeometryType) again (at least I think that I would, as they
apparently just duplicate information that is already present in the
interface hierarchy). Besides I find using switch-statements for
differentiating between the individual types/subtypes of a complex type
hierarchies cleaner than doing instanceof tests, there are two important
use cases that the enums are related to:

1. In deegree 3, we have a class called GeometryReference [2] which is a
Geometry itself and acts as a lazy wrapper around another Geometry
object. It is used for representing GML geometries that are referenced
by local/remote xlinks. It allows the easy resolving of local xlinks to
geometries after parsing a GML document. And it should also be possible
to resolve remote xlinks to GML geometries and create Geometry objects
on-the-fly.
2. When dealing with the created geometry objects, the enum-based
switching eliminates the need to differentiate between standard geometry
objects and geometry references: e.g. in drawing code, it does not
matter if you're actually processing a Surface object or a reference to
a Surface. Note that this only works, because
GeometryReference#getType() can call #getType() of the wrapped geometry
object. However, with instanceof checks this won't work, as you usually
don't know the concrete type of a referenced geometry during parsing.

However, if you find this all to be too far off at the moment be my
guest to throw out the enums from the code during the sprint for now.

Best regards and see you later,
Markus

[1]
http://svn.wald.intevation.org/svn/deegree/deegree3/core/trunk/test/org/deegree/geometry/gml/GML311GeometryDecoderTest.java
[2]
http://download.deegree.org/deegree3/nightly/core/javadoc/org/deegree/geometry/gml/refs/GeometryReference.html
Jody Garnett schrieb:
>> Jody,
>>
>> what is the sample data that you were planning to use in the geometry code
>> sprint? Can I get it? Can we use it in unit tests?
>>     
>
> I was going to be focused on  the data structure / factory / builder
> relationship. And should be able to grab a WKReader and try the test
> cases from JTS. Sample data was not really discussed as of yet.
>
>   
>> The current module seems to contain only interfaces. Should we split it into
>> a public-interface module and an implementation module? Or keep it together
>> for simplicity?
>>     
>
> The idea is to have a separate package for implementation; not sure I
> want to have a maven multi project at this stage.
>
>   
>> I am not sure where you would like to lead us. Do we need the whole SPI
>> FactoryFactoryFactory pattern, or are we going to exercise restraint and
>> just have a few static factory methods?
>>     
>
> No factory spi; I already discussed avoiding interfaces/factory but
> the group wanted to stick with the split so that is how we are going.
>
> Jody
> _______________________________________________
> Java-collab mailing list
> Java-collab at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/java-collab
>