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.garn...@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@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
                _disc...@lists.osgeo.org
                http://lists.osgeo.org/mailman/listinfo/discuss
                _






            _______________________________________________
            Discuss mailing list
            _disc...@lists.osgeo.org
            http://lists.osgeo.org/mailman/listinfo/discuss
            _


        _______________________________________________
        Discuss mailing list
        _disc...@lists.osgeo.org
        http://lists.osgeo.org/mailman/listinfo/discuss
        _




_______________________________________________
Discuss mailing list
Discuss@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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Reply via email to