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

[Markus Schneider]

If anybody is listening: I am on #geometry-collab right now.

Markus Schneider schrieb:
> 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
>>   
>>     
>
> _______________________________________________
> Java-collab mailing list
> Java-collab at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/java-collab
>   


-- 
Markus Schneider

l a t / l o n  GmbH
Aennchenstrasse 19            53177 Bonn, Germany
phone ++49 +228 18496-0       fax ++49 +228 18496-29 
http://www.lat-lon.de         http://www.deegree.org