Jody: You wrote: "Landon you may look at the API provided by geoscript as a more suitable target. "
I'd never head of GeoScript, that is something I will definitely have to check our for my work in both Python and Javascript. 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. 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. Landon PS - Would it be inappropriate to host something like JUMP Lib as a GeoTools module or set of modules? On Fri, Oct 5, 2012 at 2:13 AM, Jody Garnett <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 > 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 > 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
