[Java-collab] gvSIG and the geometry model

[Jorge Piera]

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