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

[Pieter De Graef]

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/


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/discuss/attachments/20110714/494b9fc0/attachment-0002.html>