[Java-collab] Re: Data for FOSS4G geometry code sprint, modules,
jody.garnett at gmail.com
Sat Oct 24 17:48:11 EDT 2009
Almost time. Exciting.
On 24/10/2009, at 10:08 PM, Markus Schneider <schneider at lat-lon.de>
> 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
> / surface patches . Of course, we cannot just use this right away
> 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
> hierarchies cleaner than doing instanceof tests, there are two
> use cases that the enums are related to:
> 1. In deegree 3, we have a class called GeometryReference  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
> geometries after parsing a GML document. And it should also be
> to resolve remote xlinks to GML geometries and create Geometry objects
> 2. When dealing with the created geometry objects, the enum-based
> switching eliminates the need to differentiate between standard
> objects and geometry references: e.g. in drawing code, it does not
> matter if you're actually processing a Surface object or a reference
> a Surface. Note that this only works, because
> GeometryReference#getType() can call #getType() of the wrapped
> object. However, with instanceof checks this won't work, as you
> 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,
> Jody Garnett schrieb:
>>> 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
>>> 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.
>> Java-collab mailing list
>> Java-collab at lists.osgeo.org
> Java-collab mailing list
> Java-collab at lists.osgeo.org
More information about the Java-collab