[Java-collab] gvSIG and the geometry model

Sat Jul 25 23:24:13 EDT 2009

Hi Jorege - and welcome.

Thank you for the background information. We tried something similar
and did not manage to get any development momentum behind the idea. I
look forward to hearing about your success and how it effects the
codebase and developers.

We have a slightly different take on isolating GeoTools from the
Geometry model used. Stratagy objects that can perform the
filter/expression operations required for OGC Filter 1.1; and
converters that will convert the geometry object to a Java 2D shape
for rendering.  The next step for us is to define the a factory which
we can supply our reader code allowing it to create the different
geometry objects.

As such we are keen to work on this existing GML based Geometry model
and are confident we will be able to use the result.

It sounds like you are also in a position to make use of the result
(although I suspect you will need wrappers to implement your expected
interface?).

Jody

On Tue, Jul 21, 2009 at 10:10 PM, Jorge Piera<jorge.piera at iver.es> wrote:
> Thanks a lot Markus.
>
> Your description about the Deegree implementation looks pretty interesting.
> But before to make a similar description I would like to make some comments
> about gvSIG 2.0 (the next release).
>
> One of the main goals that we have on gvSIG 2.0 is to separate both API and
> implementation of all our code. Our current geometry model has an API based
> on the ISO 19107 and all our projects have a dependence with the API (and
> not with the implementation). Now it is possible to create your own geometry
> model implementation in gvSIG.
>
> Other of our goals is separate all the components of our application and
> stablish dependences between components using its API's. We have separated
> the geometry model of the drawing operations, topological operations,
> encodings... And at this moment we have a minimal geometry model that is
> able to represent some of the geometries defined on ISO 19107 but it is not
> able to execute any operation by itself.
>
> For the execution of operations we have created a component that is used to
> execute operations (topological or not). This  component uses the geometry
> model and it has a dependency with it, but it is a different component. It
> only uses the geometry model API.
>
> For reading/writing data we have created readers and writers that are able
> to read/write different formats (GML, DWG...) and create objects of our
> model. These readers/writer have a dependency with the geometry model API.
>
> If we want to have a common geometry model, we think that we have to
> separate all the system in different layers and we have to start by the
> bottom layer that in this case is the geometry model based on ISO 19107. We
> think that the creation of a huge component that implements the geometry
> model, operations, CRS's... is not a good idea.
>
> A great point to start could be define the minimal geometry model. Obviously
> we can not lose the perspective that we have to execute operations on it or
> we have to save the geometries is a concrete format, but all this issues are
> not topics about the model.
>
> I hope that you make comment about this.
>
> Regards,
> Jorge.
>
> Markus Schneider wrote:
>>
>> 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
>>>
>>>
>>>
>>
>>
>>  ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Java-collab mailing list
>> Java-collab at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/java-collab
>>
>
>
> --
> Jorge Piera Llodrá
> Especialista en Servicios OGC
> Equipo de desarrollo gvSIG
> IVER TI S.A.
> C/ Lérida, 20
> 46009-Valencia (Spain)
> Tlf.+34902252540
> www.iver.es
> www.gvsig.com
> _______________________________________________
> Java-collab mailing list
> Java-collab at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/java-collab
>