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

Thu Jul 14 06:17:54 PDT 2011

Jody,

> Frankly with out Martin being stubborn and the hard math we would not
have an open source spatial industry.

That is worth emphasizing !

Peter

________________________________

From: discuss-bounces at lists.osgeo.org
[mailto:discuss-bounces at lists.osgeo.org] On Behalf Of Jody Garnett
Sent: July 14, 2011 07:26
To: OSGeo Discussions
Cc: discuss at lists.osgeo.org
Subject: Re: [OSGeo-Discuss] Geomajas Geometry Project
[SEC=UNCLASSIFIED]

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

_______________________________________________
				Discuss mailing list
				Discuss at lists.osgeo.org

<http://lists.osgeo.org/mailman/listinfo/discuss>
http://lists.osgeo.org/mailman/listinfo/discuss

_______________________________________________
				Discuss mailing list
				Discuss at lists.osgeo.org

<http://lists.osgeo.org/mailman/listinfo/discuss>
http://lists.osgeo.org/mailman/listinfo/discuss

		_______________________________________________
		Discuss mailing list
		<mailto:Discuss at lists.osgeo.org> Discuss at lists.osgeo.org
		<http://lists.osgeo.org/mailman/listinfo/discuss>
http://lists.osgeo.org/mailman/listinfo/discuss

	-- 
	Pieter De Graef

	Community Manager
	GeoSparc nv.
	<http://www.geosparc.com/> http://www.geosparc.com/

	Chairman of the Geomajas project
	<http://www.geomajas.org/> 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/36fce03d/attachment-0002.html>