[Java-collab] gvSIG and the geometry model

Markus Schneider schneider at lat-lon.de
Tue Jul 21 06:03:52 EDT 2009


Hello Jorge,

very nice. I guess, I can speak for me and the others that you're very welcome :-) I browsed over the linked pages a
bit, and this looks pretty interesting. Can you describe what works in practice at the moment?

The deegree 3 implementation is currently here:

- Represent any ISO 19107 vector geometry (2D/3D)
- Encode / decode from GML 3.1.1
- Represent referenced subgeometries (in GML: xlinks)
- Topological operators in 2D for Envelopes, Points, LineStrings (also Curves made up of LineStringSegments), Polygons
(also Surfaces made up of PolygonPatches), Multi* and Composite*, this works using JTS
- Linearization of Arcs, ArcStrings and Circles

Next steps:

- Implement geometry-creating operators (union, convex hull, buffer) by delegating them to JTS
- Transform geometries on the fly when executing operators on geometries that use different CRS
- Unit-of-measure support for buffer and isWithinDistance
- Linearization control

I think that our implementation approach is quite pragmatic -- it tries to be a most comfortable, but thin wrapper
around JTS (for simple geometries) that adds support for representing non-simple geometries and specialities like ids
and references.

Would be nice to hear about your implementation.

Best regards,
Markus

Jorge Piera wrote:

> My name is Jorge Piera and I'm a member of the gvSIG development team.
> I've answered this thread a little bit late and I apologize about it.
> 
> The gvSIG team is working at these moment on the 2.0 version and one of
> the main goals of this release is the new geometric model based on ISO
> 19107. We are refactoring our old geometric model with the purpose to be
> ISO compliant in a future. This refactoring is under development and the
> current status of this work can be found here [1] (it is not a
> definitive version).
> 
> One of the main tasks in gvSIG 2.0 has been to separate the API and the
> implementation of all our projects and we have made a big effort to
> document the API. The geometric model has been not an exception and we
> have a documented API [2] and a development documentation [1]. Other
> important task has been the migration to maven of all our projects.
> 
> We have been reading all the previous threads in this list (including
> the IRC log) and we think that the goals of these three projects
> (Deegree, Geotools and gvSIG) are very similar. If it is not late we
> would like to participate on this group to define a common geometric model.
> 
> Regards,
> Jorge.
> 
> [1]
> https://gvsig.org/web/docdev/docs/v2_0/org.gvsig.fmap.geom/view?set_language=en
> 
> [2]
> http://downloads.gvsig.org/pub/gvSIG-desktop/docs/reference/org.gvsig.fmap.geom/2.0.0
> 
> 


-- 
Markus Schneider

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
Url : http://lists.osgeo.org/pipermail/java-collab/attachments/20090721/33dde8fb/signature.bin


More information about the Java-collab mailing list