[Java-collab] Re: Collab on Geometry

Andrea Aime aaime at opengeo.org
Sat Jul 4 11:05:07 EDT 2009


Markus Schneider ha scritto:
> Hello Jody and others,
> 
> sorry for the delay. I am all ears now.
> 
> I guess we could start with a breakout IRC session -- preferrably at the beginning of next week, when Rutger Bezema from
> deegree is available again.
> 
> It may however be worthwhile to present our ideas of the target requirements on the mailing list first. Here's our side
> of the story (for now):
> 
> - Support every (vector?!) geometry-construct from GML 3.1.1 (and GML 3.2.1), so it's for example possible to read in
> arbitrary GML (geometry) documents and have a faithful in-memory representation.

Agreed

> - Support 2D and 3D space. Andrea said he is keen of having support for measures as well. Would 4D be enough? Or should
> we just keep this unconstrained?

I would say, let's just keep that unconstrained. Is there any 
simplification by limiting the code to 4D?

> - Keep the overhead (compared to using JTS directly) as low as possible: for simple geometries the geometry model would
> probably just act as a thin wrapper around JTS.

So for simple geometries the ISO geometry will actually contain a JTS
one?
One thing that I would like to make sure about is that the JTS 
geometries can be created with a custom GeometryFactory (both as fields,
and also when the ISO geometries are being turned into their JTS
equivalent).

> - Support topological predicates using JTS. For not-natively supported geometries, a linearized version (curves) would
> be used for the predicate evaluation. For 3D geometries, this has it limitations, but it should be possible to support
> tests on the footprint and provide a full-3D bbox operator.

Agreed

> - Represent referenced geometries (xlink) as in the following example ). Note the pointProperty elements in the
> LineString element:
> 
> <MultiGeometry srsName="EPSG:4326" xmlns="http://www.opengis.net/gml"
>   xmlns:gml="http://www.opengis.net/gml" xmlns:xlink="http://www.w3.org/1999/xlink"
>   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>   xsi:schemaLocation="http://www.opengis.net/gml http://schemas.opengis.net/gml/3.1.1/base/gml.xsd">
>   <geometryMembers>
>     <Point gml:id="P1">
>       <coord>
>         <X>0.0</X>
>         <Y>0.0</Y>
>       </coord>
>     </Point>
>     <Point gml:id="P2">
>       <coord>
>         <X>1.0</X>
>         <Y>1.0</Y>
>       </coord>
>     </Point>
>     <LineString gml:id="L1">
>       <pointProperty xlink:href="#P1" />
>       <pointProperty>
>         <Point>
>           <pos>1.0 0.0</pos>
>         </Point>
>       </pointProperty>
>       <pointProperty xlink:href="#P2" />
>       <pointProperty>
>         <Point>
>           <pos>0.0 1.0</pos>
>         </Point>
>       </pointProperty>
>     </LineString>
>   </geometryMembers>
> </MultiGeometry>
> 
> Note that the xlinks could also be pointing to external resources.

Ok

> - Design an efficient binary format so the complex geometries can be stored in today's spatial backends (e.g. PostGIS).
> As already mentioned, the trick would be to delegate predicates to the (linearized) native geometry column and use the
> BLOB for reconstructing the original one.

I'll be interested in discussing the details of the BLOB format, but 
yep, agreed it's a good idea.

> The existing codebase already implements some of the mentioned requirements (except predicates and backend format).
> There's also a quite comprehensive test suite for all kinds of GML geometry constructs.
> 
> Ready for your comments / additions.

A few extra concerns:
- compact in memory representation. It would be nice if all the 
geometries could use an as efficient as possible in memory
representation of coordinates (just say no to Coordinate[] :-) )
- low overhead access to the single ordinates making up the geometry
- shall we consider code turning the Geometry into a Java2D shape?
- validation. Should we provide method to evaluate the proper
   construction of a geometry? (probably yes?) Shall we enforce the
   validity in the constructors? (probably not?)

Cheers
Andrea


-- 
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.


More information about the Java-collab mailing list