> 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 <jody.garn...@gmail.com
> (mailto:jody.garn...@gmail.com)> 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
> > deegree-de...@lists.sourceforge.net
> > (mailto:deegree-de...@lists.sourceforge.net)
> > 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
> > deegree-de...@lists.sourceforge.net
> > (mailto:deegree-de...@lists.sourceforge.net)
> > 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
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
