Re: [location-iwg] JUMP Lib and GeoScript: Opportunities to Collaborate?

[Landon Blake <sunburned.surveyor@xxxxxxxxx>]

Thanks for all of the responses.

Tim wrote: "While I like the idea of sharing an API, I'm not
immediately impressed
 that the extra abstraction would make things much easier for all of
 us."

I agree.

Tim wrote: "Anyway, my guess is that even if there were a common lib
that provided
 another Feature interface, in GeoScript at least, we'd end up wrapping
 it again to provide signatures and syntax that make sense for the
 specific language."

This is not ideal. I don't want to provide another layer of complexity
to GeoScript. If the GeoScript Javascript implementation wraps
GeoTools already, the appropriate way to implement GeoScript in Java
would be by exposing the GeoTools code that is already being wrapped
in other language implementations.

My intent was mostly to poke around the open source community before I
started JUMP Lib. After digesting Tim's comments, it sounds like the
JUMP/GeoTools schism still makes it very difficult to join forces.

For the time being, I think I will move forward on JUMP Lib without
trying to integrate into GeoScript.

I am interested in a pure Javascript or Python simple feature
implementation. Would there be interest in an implementation of the
GeoScript interfaces in "pure" Python or Javascript?

Landon

On Mon, Oct 8, 2012 at 12:36 PM, Tim Schaub <tschaub@xxxxxxxxxxx> wrote:
> Interesting idea.
>
> While I like the idea of sharing an API, I'm not immediately impressed
> that the extra abstraction would make things much easier for all of
> us.  I've found the GeoTools simple features fairly straightforward to
> work with, and in my experience, the majority of the GeoScript
> specific code is in implementing constructors and methods with
> signatures that make sense for the specific language.  While it might
> be a surprise, most of GeoScript JS is actually written in Java.  See
> the following for the GeoScript JS Feature (that implements the Rhino
> Wrapper interface and wraps GeoTools SimpleFeature):
>
> https://github.com/tschaub/geoscript-js/blob/master/src/main/java/org/geoscript/js/feature/Feature.java
>
> That ends up providing this API in JavaScript:
> http://geoscript.org/js/api/feature/feature.html
>
> Which is (intentionally) a very close cousin to GeoJSON features:
> http://geojson.org/geojson-spec.html#feature-objects
>
> Anyway, my guess is that even if there were a common lib that provided
> another Feature interface, in GeoScript at least, we'd end up wrapping
> it again to provide signatures and syntax that make sense for the
> specific language.
>
> I'm happy to continue the conversation.
> Tim
>
>
>
> On Fri, Oct 5, 2012 at 6:01 PM, Landon Blake
> <sunburned.surveyor@xxxxxxxxx> wrote:
>> I recently posted a message to the OpenJUMP and deegree Project
>> mailing lists about organizing an effort to extract core parts of
>> OpenJUMP (especially the simple feature model) into a stand alone
>> library called JUMP Lib. (My original message is here:
>> http://sourceforge.net/mailarchive/forum.php?thread_name=CALJ1OBUVo3AtKykAP6MqX%2BuO5d--pMDZdFq0cFPizJ2HZoJSCw%40mail.gmail.com&forum_name=jump-pilot-devel
>> ).
>>
>> Jody Garnett was listening in. He mentioned the simple feature model
>> in OpenJUMP was fairly close to the one in GeoScript, and suggested
>> that GeoScript would benefit from a Java implementation of its API. I
>> know very little about LocationTech, but with Jody's encouragement I'm
>> trying to explore common ground and opportunities for collaboration.
>>
>> I was ready to start work on JUMP Lib this weekend or early next week.
>> Before I go crazy, I thought it would be good to post here.
>>
>> Is it possible to set-up a GeoScript Java implentation based on, or
>> wrapping the JUMP simple feature model? Is there room to combine
>> efforts?
>>
>> Ultimately I can set-up JUMP Lib with no ties to GeoScript, but if we
>> can share a simple feature model, that would be much better.
>>
>> Let me know what you guys think, and the best way to move forward if
>> we should work together.
>>
>> Landon
>>
>> PS - My message to Jody about the challenges to this approach,
>> including the use of wrappers, is here:
>> http://sourceforge.net/mailarchive/message.php?msg_id=29929818
>> _______________________________________________
>> location-iwg mailing list
>> location-iwg@xxxxxxxxxxx
>> http://dev.eclipse.org/mailman/listinfo/location-iwg
>
>
>
> --
> Tim Schaub
> OpenGeo http://opengeo.org/
> Expert service straight from the developers.
> _______________________________________________
> location-iwg mailing list
> location-iwg@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/location-iwg