[Gvsig_english] Development Tutorial

[Benjamin Ducke]

Could you elaborate a bit on how you would envision that?

Ben

michael gould wrote:
> And in the medium-long term, aim at connecting to Grass, Ilwis, sextante,
> etc. routines as remote WPSs.
> 
> ______________________________________________
> Michael Gould
> Dept. Information Systems (LSI)
> Universitat Jaume I, 12071 Castellón, Spain.
> email: gould (at) lsi.uji.es
> www.geoinfo.uji.es
> 
> -----Mensaje original-----
> De: gvsig_internacional-bounces at runas.cap.gva.es
> [mailto:gvsig_internacional-bounces at runas.cap.gva.es] En nombre de michael
> gould
> Enviado el: martes, 14 de octubre de 2008 12:55
> Para: 'Users and Developers mailing list'
> Asunto: RE: [Gvsig_english] Development Tutorial
> 
> The short/medium-term solution seems to be continued development of the
> excellent Sextante tools within the gvSIG Framework.
> 
> ______________________________________________
> Michael Gould
> Dept. Information Systems (LSI)
> Universitat Jaume I, 12071 Castellón, Spain.
> email: gould (at) lsi.uji.es
> www.geoinfo.uji.es
> 
> -----Mensaje original-----
> De: gvsig_internacional-bounces at runas.cap.gva.es
> [mailto:gvsig_internacional-bounces at runas.cap.gva.es] En nombre de Benjamin
> Ducke
> Enviado el: martes, 14 de octubre de 2008 12:43
> Para: Users and Developers mailing list
> Asunto: Re: [Gvsig_english] Development Tutorial
> 
>> 2) Is there any distinct possibility that GRASS GIS could be embedded 
>> with GvSIG. 
> 
> Technically, it is feasible. GRASS is GUI-independent and all modules
> could be launched from within a Java-based GUI. GRASS is now also
> cross-platform and if this would be based on version 6.4, then we could
> have the same functionality on Linux/Windows and the Mac.
> 
> There is also a project that has come up with a JAVA API for GRASS:
> 
> http://jgrass.wiki.software.bz.it/jgrass/JGrass_Wiki
> 
> It does have, however, a very peculiar way of storing data in
> "locations". All necessary data structures could, however, be created
> on the fly in a temporary location as needed.
> 
> The final hurdle would be the GRASS topology model which is very strict
> and refuses to accept messy data (such as overlapping polygons
> in the same layer) that many other GIS tolerate (at least to a certain
> point).
> 
> I agree that it would be brilliant to have the GRASS tools available
> under gvSIG. There are now more than 400 geoprocessing modules in
> GRASS and they are *very* powerful.
> 
> Ben
> 
> 
>> Rgds.
>>
>> Abhay.
>>
>> PS. I have visited http://www.gvsig.org/web/docdev/ but could not make 
>> anything out of it as it not in english. Also I find that the Image 
>> linked on the site are broken. 
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Gvsig_internacional mailing list
>> Gvsig_internacional at runas.cap.gva.es
>> http://runas.cap.gva.es/mailman/listinfo/gvsig_internacional
> 
> 


-- 
Benjamin Ducke
Senior Applications Support and Development Officer

Oxford Archaeology Ltd
Janus House
Osney Mead
OX2 0ES
Oxford, U.K.

Tel: +44 (0)1865 263 800 (switchboard)
Tel: +44 (0)1865 980 758 (direct)
Fax :+44 (0)1865 793 496
benjamin.ducke at oxfordarch.co.uk




------
Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information.