[Java-collab] Re: OSGeom code initiation

[Axel FRANCOIS]

Hello,

I introduce myself, Axel FRANCOIS, I'm currently in the first year of  
a PhD at LSIS laboratory of Marseille (www.lsis.org). My lab team  
works on "geometric modelling" and my PhD is co-managed by Geomatys.  
My special field is geometrical modelisation and multimodels analysis  
(2D/3D, curves, surfaces, volumic object,...) for Geographic  
Information Systems.
My job is based on the ISO 19107 norm. That's why I use GeoAPI  
interfaces. For CRS, I use Geotoolkit. The aim of my work is to be put  
at disposition of Geotoolkit library.


I have read in recent emails exchange that you are considering  
splitting interfaces from implementations, and that interfaces would  
follow ISO 19107 models.
This seems to be similar to GeoAPI goals. Are you considering working  
with GeoAPI? If not, what could be done for making it more attractive?


Regards,

Axel FRANCOIS



 > Thanks Markus - when you get a chance can you send contribution
 > agreement to osgeo; I think the contact details are in the form.

 > On the bright side; we accept your word that you have sent the
 > documentation in - and only check a couple times a year.

 > As for giving you commit rights - can you email your osgeo id? it is
 > the same "single sign on" as the rest of the osgeo facilities (wiki,
 > trac etc...).

 > Jody
 >
 > On Mon, Jul 27, 2009 at 7:42 PM, Markus Schneider<schneider at lat- 
lon.de> wrote:
 > Hello all,
 >
 > as we now agreed to host the collaboration code (temporarily) at http://svn.osgeo.org/geotools/trunk/spike/geometry 
, I
 > would like to start populating the SVN.
 >
 > As a first step, I can offer to import the interfaces of the  
deegree 3 geometry type hierachy
 > (https://wiki.deegree.org/deegreeWiki/deegree3/Geometry) into the  
SVN (of course refactored to org.osgeom.geometry).
 > This basically includes the (documented) geometry interfaces, curve  
segment interfaces and surface patch interfaces. I
 > would however omit any methods that are not relevant for structural  
aspects -- i.e. Curve#getSegments() goes in, but
 > #intersects(Geometry) does not.
 >
 > Afterwards, we should have a phase for discussing the structure  
(e.g.: "Are MultiCurve and MultiLineString both
 > needed?"), cleaning up and improving the JavaDoc.
 >
 > What do you think?
 >
 > Best regards,
 > Markus
 >
 >
 > PS: @Jody: can you provide me with commit rights?
 >
 > --
 > 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
 >
 >
 > _______________________________________________
 > Java-collab mailing list
 > Java-collab at lists.osgeo.org
 > http://lists.osgeo.org/mailman/listinfo/java-collab
 >
 >


----------------------
Axel FRANCOIS
Doctorant  - Equipe Image & Modèles
Laboratoire des Sciences de l'Information et des Systèmes (LSIS - UMR  
6168)
Université de la Méditerranée (U2)
ESIL - Case 925
163, Avenue de Luminy
13288 Marseille Cedex 9
Mail : axel.francois at lsis.org
Tel. : 04-90-52-24-10
Mobile : 06-23-22-21-75




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/java-collab/attachments/20090727/ba70d858/attachment-0001.html