Thanks for the tip.<div><br></div><div>Basically I'm looking to make advantage of the GWT by having a single API that I can use on both client and server.</div><div>We could indeed have 2 implementations (one using JTS one using JSTS), but what I'm mainly looking for, is what model should the API ideally follow.<br>
<br><div class="gmail_quote">2011/7/13 Andreas Hocevar <span dir="ltr"><<a href="mailto:ahocevar@opengeo.org">ahocevar@opengeo.org</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi Pieter,<br>
<br>
this may not directly answer your question, but you could use the<br>
existing JSTS library: <a href="https://github.com/bjornharrtell/jsts" target="_blank">https://github.com/bjornharrtell/jsts</a> - this is<br>
basically a port of the Java Topology Suite. The advantage would be<br>
that you don't need a JS wrapper - you could use JTS on the server and<br>
JSTS on the client. And if things you need are missing in JSTS, you<br>
could contribute them.<br>
<br>
Just my 2¢ - sorry if they are inappropriate.<br>
Andreas.<br>
<div><div></div><div class="h5"><br>
On Wed, Jul 13, 2011 at 10:36 AM, Pieter De Graef <<a href="mailto:piedere@gmail.com">piedere@gmail.com</a>> wrote:<br>
> Hi everyone,<br>
> for the Geomajas project, we are looking into separating the Geometry<br>
> functionality into an independent project. In other words, I am talking<br>
> about a Geometry project for the Web. This code would be written in Java for<br>
> GWT and thus be available on Java backends as well as client environments<br>
> (we intend to add a JavaScript wrapper around the GWT code).<br>
> Now the problem that I'm facing here, is which model to follow....<br>
> On one hand there is the Simple Feature Specification which is clearly an<br>
> Object Oriented model with the advantage that it is well known but is also<br>
> more difficult to implement the JavaScript wrapper around.<br>
> On the other hand we could follow a service based model (more like SFS for<br>
> SQL) which is easier to get up and running, easier to create a JavaScript<br>
> wrapper for and easier to translate into web services.<br>
> As it's difficult for us to chose and as it's a pretty crucial decision for<br>
> the future of the Geomajas project, I as wondering how you guys feel about<br>
> this.<br>
> Kind regards,<br>
> Pieter De Graef<br>
</div></div>> _______________________________________________<br>
> Discuss mailing list<br>
> <a href="mailto:Discuss@lists.osgeo.org">Discuss@lists.osgeo.org</a><br>
> <a href="http://lists.osgeo.org/mailman/listinfo/discuss" target="_blank">http://lists.osgeo.org/mailman/listinfo/discuss</a><br>
><br>
><br>
<font color="#888888"><br>
<br>
<br>
--<br>
Andreas Hocevar<br>
OpenGeo - <a href="http://opengeo.org/" target="_blank">http://opengeo.org/</a><br>
Expert service straight from the developers.<br>
_______________________________________________<br>
Discuss mailing list<br>
<a href="mailto:Discuss@lists.osgeo.org">Discuss@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/discuss" target="_blank">http://lists.osgeo.org/mailman/listinfo/discuss</a><br>
</font></blockquote></div><br></div>