Re: [JPP-Devel] [deegree-devel] JUMP Lib

[Landon B. <sun...@gm...>]

Jody wrote: "I am interested in your take on their alternative to the
feature model  (note this project is born out Justin's frustration
with the GeoTools feature model so you are in good company)."

I need to take a closer look at the API. From the bit I saw today, it
looks like they are headed in the direction I want.

You wrote: "We have good practice now creating wrappers around simple
feature and mapping over to the much more scary GeoTools feature
model. So I am sure that approach is possible."

I'm going to think out loud for a bit here...

There are two possible approaches to using a wrapper:

1) Create a wrapper for the GeoScript simple feature class (Java
implementation) that looks and acts like a JUMP feature class. The
disadvantage of this approach is tools I write would work with only
JUMP features, requiring GeoScript users to use the JUMP wrapper class
when they don't need to. (Or have the tool classes with methods that
accept both types of fetaure classes, and only use one type internal
to the class.)

2) Create a wrapper for the JUMP feature class that wraps the
GeoScript simple feature class (Java implementation). Tools would
transparently work with this wrapper and the "regular" GeoScript
simple feature class.
The disadvantage to this approach is tools would need to be tweaked to
be usable directly in OpenJUMP plug-ins.

Neither one of these methods is as simple as just using JUMP lib,
although 2 is probably the better way to go. Maybe the extra cost of
tool integration in OpenJUMP is worth the gains from the increased
collaboration. (If someone writes a tools to work with a GeoScript
simple feature (Java implementation) we could use the wrapper code to
integrate that tool into OpenJUMP.)

I will need to think some more about this.

Jody wrote: "There is always an opportunity to collaborate, what we
find is often their is a lack of budget / commitment."

I'm only a poor surveyor. However, my recent application of OpenJUMP
at KSN has increased my interest in creating a stand-alone library for
geospatial tool chains independent of JUMP. I really NEED to make time
to get this done.

Jody wrote: "So what you are doing here (talking to different Java
communities is exactly what is needed). I am sorry I "jump"ed in as
now you have not gotten any feedback from deegree developers."

I suppose a better place to have started the discussion was on the
OSGeo Java mailing list. I will do that next time. Don't worry about
the lack of feedback. I have a reputation for being long on ideas and
shhort on actions. That is my fault, not yours. :]

You wrote: "I would encourage you to join the location tech email list
and introduce yourself, and your idea."

I will do that tonight, and we will see where things head.

Landon


However I would recommend only doing that for compatibility, and encouraging

developers to go for the more simple API. "

On Fri, Oct 5, 2012 at 4:29 PM, Jody Garnett <jod...@gm...> wrote:
> I'd never head of GeoScript, that is something I will definitely have
> to check our for my work in both Python and Javascript.
>
> I am interested in your take on their alternative to the feature model
> (note this project is born out Justin's frustration with the GeoTools
> feature
> model so you are in good company).
>
> If the API was too different from the existing JUMP simple feature
> model, it would be hard to push changes back to the OpenJUMP SVN,
> which would be one of my goals from the library. I'm not sure how we'd
> work around that challenge, unless we used some type of wrapper class.
>
> We have good practice now creating wrappers around simple feature and
> mapping over to the much more scary GeoTools feature model. So I am sure
> that approach is possible.
>
> However I would recommend only doing that for compatibility, and encouraging
> developers to go for the more simple API.
>
> You wrote: "As an aside: This is also the general direction I will
> encourage LocationTech to move in."
>
> Is there an opportunity here to collaborate? I don't know much about
> LocationTech or your work with them. I was going to start the work of
> code migration for JUMP lib this weekend or early next week, but I can
> wait if you think there is enough common ground to work together. I'm
> an advocate of consolidation and cooperation, not further
> fragmentation of our JAVA FOSS GIS community.
>
> There is always an opportunity to collaborate, what we find is often their
> is
> a lack of budget / commitment.
>
> So what you are doing here (talking to different Java communities is exactly
> what is needed). I am sorry I "jump"ed in as now you have not gotten any
> feedback
> from deegree developers.
>
> I would encourage you to join the location tech email list and introduce
> yourself, and your idea.
>
> Landon
>
> PS - Would it be inappropriate to host something like JUMP Lib as a GeoTools
> module or set of modules?
>
> Ideally you would implement as part of GeoScript.
> a) A java implementation of the core "Record" (i.e. not feature) class
> b) A seperate module adapting to Jump code
>
> GeoScript is in the process of joining LocationTech (it is an MIT license so
> code can be shared between projects
> as required).
>
> Jody
>
>
>
>
>
> On Fri, Oct 5, 2012 at 2:13 AM, Jody Garnett <jod...@gm...> wrote:
>
> Landon you may look at the API provided by geoscript as a more suitable
> target.
>
> It does forgo the usual GIS terminology in order to try and reach a wider
> range of developers. (i.e. records rather then features)
>
> While they have implementations in several languages, if you did an
> implementation in Java
> it would very much resemble the simple feature model you are talking about.
>
> As an aside: This is also the general direction I will encourage
> LocationTech to move in.
> --
> Jody Garnett
>
> On Friday, 5 October 2012 at 1:16 AM, Landon Blake wrote:
>
> We've talked before about submitting OpenJUMP as a OSGeo Project. This
> hasn't happened yet, for a number of reasons. I wanted to put forward
> an alternative idea and discuss it as a community. I've copied the
> deegree Project on this e-mail, since I believe they share some code
> with us and may have an interest in the discussion.
>
> I've recently reached an important milestone in my own use of
> OpenJUMP. We've started applying it to the management of small sewer
> utilities at my employer, KSN. I'm in the process of developing some
> tools for OpenJUMP to enable expanded application of the program for
> these clients. These tools will include some plug-ins to work with
> LIDAR data, tools for advanced SVG export, network topology tools, and
> tools to integrate survey data and survey networks with OpenJUMP. It
> is very concievable that some of these tools could be used outside of
> OpenJUMP's GUI, as part of a separate geoprocessing toolkit. For
> example, you might use such a toolkit to set up a pipeline for LIDAR
> processing.
>
> I've always thought the core classes in OpenJUMP, especially the
> classes for its Simple Feature Model, were valuable as a stand-alone
> library. I think GeoTools attempted to create such a library, but in
> my humble opinion they may have choked library usability with too much
> complexity.
>
> I'd like to "separate" and maintain the Simple Feature model classes
> from OpenJUMP in a stand alone library. This library would be built
> piece by piece. The source code for each class would be reviewed,
> cleaned, documented, and unit tested before inclusion in the library.
> These improvements could be pushed back to the OpenJUMP code base. The
> library could support development of "modules" that use the simple
> feature core classes, as they do in the GeoTools system. For example,
> my GPX plug-in could become a module in the new stand alone library.
>
> I think this would provide us the opportunity to attract programmers
> that were looking for an open source geospatial library that is easier
> to understand and use than GeoTools, but still written in Java.
> Programmers that don't necessarily need a full-blown GIS application
> like OpenJUMP.
>
> We could then submit this library as an OSGeo Project. I believe this
> will be simpler than trying to subject OpenJUMP as a whole beast to
> the OSGeo incubation process. I recently started work on the OSGeo
> Inubation Committee, and I'm willing to guide our community through
> this process if we decide to collaboratively create the library.
>
> I was going to start the process of moving core classes into a library
> project on the SurveyOS SVN, but I then decided it would be better to
> discuss the concept here first. If there is support for this idea in
> our developer community, then I can start this work on the JPP SVN.
> Once the first few classes are migrated, I'd want to review the OSGeo
> incubation process requirements to make sure our library was
> structured in a way that facilitated meeting those requirements.
>
> If there isn't enough support for a stand alone library among our
> developers, I'll work in the SurveyOS SVN and will push up to OpenJUMP
> whatever changes the community decides are acceptable.
>
> I'm interested to hear what you guys think.
>
> Landon
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> deegree-devel mailing list
> dee...@li...
> https://lists.sourceforge.net/lists/listinfo/deegree-devel
>
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> deegree-devel mailing list
> dee...@li...
> https://lists.sourceforge.net/lists/listinfo/deegree-devel
>
>