Hi Josh, Resurrecting JCS is a very interesting project, and the problem of choosing a feature model which is not bounded to a particular software a very interesting question. I have often considered this question for OpenJUMP as it would be a good way to share code with similar projects like geotools. If I had some times to explore this idea, my natural choice would be to try to implement the geoapi which is a set of interface definition guided by OGC standard (feature model of geoapi currently has a pending status).
http://www.geoapi.org/geoapi-pending/apidocs/org/opengis/feature/package-summary.html http://www.geoapi.org/geoapi-pending/apidocs/org/opengis/feature/simple/package-summary.html Both Geotools and GeoToolkit should have implementations of these interfaces. That said, I have no idea of how much work it would be, how many dependencies it would add... I have never considered java bindings for GDAL/OGR as I did not know them and try to avoid bindings to non java code where I know that good java code already exist, but it may be an alternative. Regards, Michaël > Hello, > I've never developed OpenJUMP, but I'm starting to use the Java > Conflation Suite (JCS) [0] which is dependent upon many JUMP classes, > and was started by Martin Davis (originator of JUMP and JTS as well). > JCS has not seen any (open) development since 2003, but it still > provides much of the functionality I'll need, and I'd like any > improvements I make to be usable for others. The application is a > plugin for JOSM [1], an OpenStreetMap [2] data editor, with an initial > goal to facilitate the conflating of "POIs" [3], such as upgrading the > geometry of a business from a point to a polygon, and merging the > attributes. > > JCS depends on quite a few JUMP (circa 2003) classes, such as for > features and utility functions. I'd rather not have a dependency on > JUMP, but I'm not sure the best way to accomplish this, other than > pulling out all the required functionality and putting it in the JCS > package, com.vividsolutions.jcs. However if there's any changes that > should be made to the API, such as the Feature/FeatureCollection > classes, to make JCS more usable by other applications, I'd like to do > that now. Perhaps I should adopt some of the API from the Java > bindings for GDAL/OGR [4]. > > A while ago I put the two available versions of JCS in a Git > repository [5], which is where I'll be publishing any changes. I > posted a related query on the JTS list which is worth checking out for > those interested [6]. > > -Josh > > [0]: http://www.vividsolutions.com/jcs/ > [1]: http://josm.openstreetmap.de/c > [2]: http://www.openstreetmap.org > [3]: http://wiki.openstreetmap.org/wiki/JOSM/Plugins/Conflation > [4]: http://gdal.org/java/ > [5]: https://github.com/joshdoe/jcs/ > [6]: http://sourceforge.net/mailarchive/message.php?msg_id=28969491 > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
