[OSGeo-Discuss] Geomajas Geometry Project [SEC=UNCLASSIFIED]

[Jody Garnett]

It follows the SFSQL spec.

The only problem in this space is money. Frankly with out Martin being stubborn and the hard math we would not have an open source spatial industry. 

We see many ports of jts but what is needed is commitment. 



On 14/07/2011, at 5:22 PM, Pieter De Graef <pieter.degraef at geosparc.com> wrote:

> Thanks for your insights guys.
> 
> I have also noticed that a lot of Java based projects use the JTS library for geometries, while this library does not really follow any specs (afaik). Do you guys feel that this is becoming a problem?     I'm asking this because there is also a JTS4GWT project out there.
> 
> On 07/14/2011 01:42 AM, Bruce Bannerman wrote:
>> 
>> Pieter,
>> 
>> I agree with Jody.
>> 
>> I’m seeing increasing demand for clients that can utilise vector data constrained by an application schema.
>> 
>> Europe is probably most advanced in this work with Inspire.
>> 
>> In Australia we have a lot of work currently at research and at implementation stage trying to work with Simple Features 1 (aka Complex Features).
>> 
>> Some examples are WaterML 2.0 and GeoSciML. We will also be looking seriously at CSML 3.0.
>> 
>> Bruce Bannerman 
>> 
>> 
>> On 13/07/11 10:52 PM, "Jody Garnett" <jody.garnett at gmail.com> wrote:
>> 
>> 
>>  It is the ISO 19107 specification; the same one that lurks behind GML Ready to leap out from under a surface and foist trans finite set on an unsuspecting world.  It is worth while getting the ISO 19107 document (ie pay for it) as it is much easier to read and follow then learning this information second hand.
>> 
>> We had a brief code sprint with deegree (compatible LGPL license) in order to see if multiple project would be interested in attacking the problem. GeoAPI was the first attempt (which has now been released last month), we have a couple of implementations in GeoTools (mostly ports or wrappers of JTS). deegree has an implementation that is closer to the GML constructs etc....
>> 
>> If you are interested in pursuing this I recommend talking to Tisham who has been more active research. I am afraid I am interested in using a Geometry library and enthusiasm goes as far as setting one up with a good design so that it can be completed successfully.
>> 
>> -- 
>> Jody Garnett
>> 
>>   
>> 
>> On Wednesday, 13 July 2011 at 9:54 PM, Pieter De Graef wrote:
>> 
>>  
>> Hi Jody,
>> 
>> that's the GeoApi specification no?
>> 
>> At first we would be using it on the GWT client we where hoping to also include curves, as those can be directly drawn in SVG/VML. At a later stage we could switch the backend to make use of it as well.
>> 
>> Jody, you have been looking into creating you own Geometry library for some time now I understand. How would you approach this? I was hoping to start with something simple, that can grow at it's own pace. Important for me is that I can use the same objects on both client and server (meaning Java with some GWT restrictions).
>> 
>> I am also afraid to be re-inventing the wheel, but using 2 different libraries on client and server would be a shame               when using GWT...
>> 
>> 
>> 2011/7/13 Jody Garnett <jody.garnett at gmail.com>
>> 
>>  There is a third model; the ISO19107 model that deals with a few more things; it is however object oriented in nature....
>>   
>> -- 
>> Jody Garnett
>> 
>>  
>> 
>> On Wednesday, 13 July 2011 at 6:36                   PM, Pieter De Graef wrote:
>> 
>>  
>> Hi everyone,
>> 
>> for the Geomajas project, we are looking into separating the Geometry functionality into an independent project. In other words, I am talking about a Geometry project for the Web. This code would be written in Java for GWT and thus be available on Java backends as well as client environments (we intend to add a JavaScript wrapper around the GWT code).
>> 
>> Now the problem that I'm facing here, is which model to follow....
>> 
>> On one hand there is the Simple Feature Specification which is clearly an Object Oriented model with the advantage that it is well known but is also more difficult to implement the JavaScript wrapper around.
>> 
>> On the other hand we could follow a service based model (more like SFS for SQL) which is easier to get up and running, easier to create a JavaScript wrapper for and easier to translate into web services.
>> 
>> As it's difficult for us to chose and as it's a pretty crucial decision for the future of the Geomajas project, I as wondering how you guys feel about this.
>> 
>> Kind regards,
>> 
>> Pieter De Graef
>> _______________________________________________
>> Discuss mailing list
>> Discuss at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/discuss
>>     
>> 
>>  
>>  
>>  
>> 
>> _______________________________________________
>> Discuss mailing list
>> Discuss at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/discuss
>> 
>> 
>> _______________________________________________
>> Discuss mailing list
>> Discuss at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/discuss
>>     
>> 
>>  
>> 
>> _______________________________________________
>> Discuss mailing list
>> Discuss at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/discuss
> 
> -- 
> Pieter De Graef
> 
> Community Manager
> GeoSparc nv.
> http://www.geosparc.com/
> 
> Chairman of the Geomajas project
> http://www.geomajas.org/
> 
> _______________________________________________
> Discuss mailing list
> Discuss at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/discuss/attachments/20110714/7b06dce9/attachment-0002.html>