[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