Re: [JPP-Devel] [Geotools-devel] Requesting some thoughts on GeoTools...
Hello all, I've programmed using both GeoTools and JUMP-OpenJUMP APIs. I think it's a great idea to make a converter between OpenJUMP and GeoTools feature model, in fact, it had been very useful to me a few months ago... and sure it will be very useful in the future. But, in my opinion, OpenJUMP is very good right now... it's stable, very easy to use, small, quite fast, runs in low performance computers, etc. Compatibility: yes (but without damaging in these aspects). It is just my modest point of view. Nacho. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] [Geotools-devel] Requesting some thoughts on GeoTools...
Justin, Your comments will be very helpful to me. I think it would be prudent to stick with the stable version of GeoTools for my work on a converter between OpenJUMP and GeoTools feature. The Sunburned Surveyor On 4/20/07, Justin Deoliveira [EMAIL PROTECTED] wrote: Hi Edgar, PS: aren't there projects using geotools libraries? how do they handle interface changes etc.? In GeoServer, we always make sure our stable branch is on a geotools stable branch. For example, GeoServer 1.5.x is based on Geotools 2.3.x. We do not allow any changes to api on stable geotools branches, or any major changes in functionality, strictly bug fixes. We generally stay on one of these stable branches from 6 to 8 months. This has effectively shielded us from the instability, however does really help all that much we make a minor version change. Undoubtedly one of the reasons why we stay on a stable branch for so long. -Justin -- Justin Deoliveira The Open Planning Project [EMAIL PROTECTED] - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] [Geotools-devel] Requesting some thoughts on GeoTools...
Thanks for the email Frank - your comments are spot on. It often seems are run out of time and push something bad out the door - and then spend years sorting out what is right. I kind of wish we would do more gradual changes and set ourselves up to improve over time. It often seems we struggle until we cannot take it anymore, and the people that cannot take it anymore end up forking in order to do something that should be easy. There are lots of examples - but this shapefile one is a good start. Open Jump uses some shapefile code, that was forked off JUMP which was forked off an early cut in GeoTools. It would of been more fun if improvements (stability is an improvement) were fed back in. Landon thanks for bringing this conversation to the GeoTools-devel list; I will do my best to answer your questions. And if you have any suggestions on how we can work together better please let me know. If difference in FeatureModel is a trouble for you please let me know; I would like to set things up so you can supply a factory to the shapefile code to produce instances that are exactly to your liking. Cheers, Jody Frank Warmerdam wrote: Sunburned Surveyor wrote: David (and other OpenJUMP developers), I should add that the GeoTools folks did quickly respond to my inquiry on their mailing list about the Shapefile code. One of their developers mentioned that their are no current plans to Feature interface. They also seem to be open to the idea of accepting documentation I prepare on the use of the Shapefile code. Perhaps the wise thing would be to develop and use the converter. This would allow us to see what changes happen to the GeoToolsfeature model API over the course of the next few months and would give us a chance to see how OpenJUMPers and the GeoTools folks work together. I'll wait on some input from the GeoTools developers, if they're interested in the conversation. :] Landon, I feel a bit out of place participating in this thread, since I am neither an OpenJUMP developer, nor a GeoTools developer nor really a user of either. However, from the C/C++ open source geospatial community I have frequently been amazed (in a negative way) at the failure of the OSGIS Java community to gel around common libraries. In the C/C++ world, components like GDAL/OGR, PROJ and GEOS are very widely used in packages including GRASS, MapServer, MapGuide, OSSIM, OpenEV, and Thuban. It seems to be accepted that re-inventing file format io, or projections for each package is silly and a drain of resources from the specific things that set these applications apart. And yet, from my limited view, it seems that code sharing in the OS Java world is not as ubiquitous. GeoServer and uDig are the obvious major applications built on GeoTools. But major Java packages such as OpenJUMP, deegree and gvSig seem to make only modest or no use of GeoTools - essentially re-inventing all sorts of stuff from scratch. Over the years I have kept a bit of an eye on GeoTools and the Java community at large. I have been both amazed (in a positive way!) and also dismayed at the enthusiasm for refactoring found in the GeoTools community. I think David Zwiers is right to raise stability as a concern with regard to GeoTools. The cardinal rule of GDAL/OGR is I may get the interface wrong the first time, but at least I don't change it!. Quite the opposite for GeoTools who seem keen to revisit core interface design every major rev in the interest of getting a cleaner or more general design. But I think OpenJUMP and other teams interested in GeoTools can absolutely have a positive effect on the GeoTools team in this regard. I think it is important that you and others get involved and stress the importance of stability rather than just giving up and duplicating things. I was keen on GeoTools being an OSGeo project because I think the Java community needs a strong library or set of libraries to build on. GeoTools seems the clear and obvious choice for this role. Now what can we do to help it live up to that role? While I think there would be some benefits to actually changing out the OpenJUMP feature model for the one in GeoTools, I can understand why that would be a high risk step. In the meantime I'd like to strongly encourage you build some sort of adapter so that any geotools feature source can be used as an OpenJUMP feature source, even if there is a bit of extra conversion between feature models always going on. And then stop work on any data access code of your own, and throw in with GeoTools for this functionality! Get involved, help out, etc. Just using parts of the low level shapefile code on the other hand is essentially next to no cooperation at all. I don't know what OpenJUMP uses for coordinate system transformations, but I will stress that GeoTools is quite sophisticated in this realm and this would be another obvious aspect to
Re: [JPP-Devel] [Geotools-devel] Requesting some thoughts on GeoTools...
Hello Frank, Jody, Landon and all ... this is exactly what my problem was back in 2004! .. imagine an impressible powerful graphic user interface for editing (jump) but not using the all the power of geotools ... still things were/are not that different, for my thesis i wrote a (simple) converter (for the differences between data models) simply to have _all_ geotools input modules working using just _one_ extension (gt2_readwrite extension) geometries (based on jts) were compatible in 2004 and are till date i think, so my cts extension (reprojection/cts) for jump was not that difficult to realize as i had to use geotools code on the compatible geometries only .. I wonder why Vivid Solutions .. and other contributors too (since 2004! when i got involved into osgis) are not using the readily available power of geotools2 to implement useful features like reprojection or geotools datasource modules ... why is that so? in between i came aware of an alternate implementation to reproject/transform in vivid's jump ... why didn't you use the geotools code? ... maybe somebody wants to explain this issues to me .. kind regards .. ede PS: aren't there projects using geotools libraries? how do they handle interface changes etc.? -- Let me respond to Frank and Jody's comments below: Frank wrote: I feel a bit out of place participating in this thread, since I am neither an OpenJUMP developer, nor a GeoTools developer nor really a user of either. We are a pretty informal list and your comments are always welcome. :] Frank wrote: However, from the C/C++ open source geospatial community I have frequently been amazed (in a negative way) at the failure of the OSGIS Java community to gel around common libraries. Yup. We could do a lot better job of that. I'm not sure why it is so difficult for us. Frank wrote: GeoServer and uDig are the obvious major applications built on GeoTools. But major Java packages such as OpenJUMP, deegree and gvSig seem to make only modest or no use of GeoTools - essentially re-inventing all sorts of stuff from scratch. I think I can provide an explanation, but not an excuse, for this. UDig was built on GeoTools, while OpenJUMP, degree, and gvSig use JUMP's original featuer mode. So you could sort of say there are 2 main branches of Java geospatial code from which all the derivatives spring. I hope I can start two pull the two branches back together with OpenJUMP development as the vehicle, but I don't think a complete merge will ever be possible. Frank wrote: But I think OpenJUMP and other teams interested in GeoTools can absolutely have a positive effect on the GeoTools team in this regard. I think it is important that you and others get involved and stress the importance of stability rather than just giving up and duplicating things. I was keen on GeoTools being an OSGeo project because I think the Java community needs a strong library or set of libraries to build on. GeoTools seems the clear and obvious choice for this role. Now what can we do to help it live up to that role? Now you are making me feel guilty. :] This is the most excellent point in your post Frank. If I'm screaming at the GeoTools folks because they keep chainging the Feature interface they'll be less prone to change it. :] (I wouldn't really scream, but I'd complain enthusiastically.) I recognize that it is important for projects like OpenJUMP to get involved in GeoTools so the project can make improvements. It's not fair to criticize without making an effort to solve the problems. Frank wrote: In the meantime I'd like to strongly encourage you build some sort of adapter so that any geotools feature source can be used as an OpenJUMP feature source, even if there is a bit of extra conversion between feature models always going on. This is the direction that I am leaning in. I need to think about it a little more, and perhaps bounce a couple of more things off of the OpenJUMP community. Frank wrote: I don't know what OpenJUMP uses for coordinate system transformations, but I will stress that GeoTools is quite sophisticated in this realm and this would be another obvious aspect to take advantage of. I've already talked a little to the GeoTools folks about this. I'm going to need to work on a homegrown map projection for a Forest Service project, and I hope to use the GeoTools code for this. Jody wrote: Landon thanks for bringing this conversation to the GeoTools-devel list; I will do my best to answer your questions. And if you have any suggestions on how we can work together better please let me know. If difference in FeatureModel is a trouble for you please let me know; I would like to set things up so you can supply a factory to the shapefile code to produce instances that are exactly to your liking. Thanks for the offer Jody. I'll be digging into the
Re: [JPP-Devel] [Geotools-devel] Requesting some thoughts on GeoTools...
Edgar wrote: wonder why Vivid Solutions .. and other contributors too (since 2004! when i got involved into osgis) are not using the readily available power of geotools2 to implement useful features like reprojection or geotools datasource modules ... why is that so? I think the reason for this problem is 1/3 stupidity, 1/3 lack of cooperation and communication between the various development teams, and 1/3 technical challenges. It sounds like I'll be working on a converter to move between the GeoTools Feature Model and the JUMP Feature Model. This thread has made me realize how important it is to make sure that projects like DeeJUMP , Sigle, Kosmo, OpenJUMP, and SkyJUMP keep the same Feature interface, or at least agree when changes to that interface need to be made. Remember it is an interface, so you can always wrap customizations in a new implementation. The Sunburned Surveyor On 4/19/07, Edgar Soldin [EMAIL PROTECTED] wrote: Hello Frank, Jody, Landon and all ... this is exactly what my problem was back in 2004! .. imagine an impressible powerful graphic user interface for editing (jump) but not using the all the power of geotools ... still things were/are not that different, for my thesis i wrote a (simple) converter (for the differences between data models) simply to have _all_ geotools input modules working using just _one_ extension (gt2_readwrite extension) geometries (based on jts) were compatible in 2004 and are till date i think, so my cts extension (reprojection/cts) for jump was not that difficult to realize as i had to use geotools code on the compatible geometries only .. I wonder why Vivid Solutions .. and other contributors too (since 2004! when i got involved into osgis) are not using the readily available power of geotools2 to implement useful features like reprojection or geotools datasource modules ... why is that so? in between i came aware of an alternate implementation to reproject/transform in vivid's jump ... why didn't you use the geotools code? ... maybe somebody wants to explain this issues to me .. kind regards .. ede PS: aren't there projects using geotools libraries? how do they handle interface changes etc.? -- Let me respond to Frank and Jody's comments below: Frank wrote: I feel a bit out of place participating in this thread, since I am neither an OpenJUMP developer, nor a GeoTools developer nor really a user of either. We are a pretty informal list and your comments are always welcome. :] Frank wrote: However, from the C/C++ open source geospatial community I have frequently been amazed (in a negative way) at the failure of the OSGIS Java community to gel around common libraries. Yup. We could do a lot better job of that. I'm not sure why it is so difficult for us. Frank wrote: GeoServer and uDig are the obvious major applications built on GeoTools. But major Java packages such as OpenJUMP, deegree and gvSig seem to make only modest or no use of GeoTools - essentially re-inventing all sorts of stuff from scratch. I think I can provide an explanation, but not an excuse, for this. UDig was built on GeoTools, while OpenJUMP, degree, and gvSig use JUMP's original featuer mode. So you could sort of say there are 2 main branches of Java geospatial code from which all the derivatives spring. I hope I can start two pull the two branches back together with OpenJUMP development as the vehicle, but I don't think a complete merge will ever be possible. Frank wrote: But I think OpenJUMP and other teams interested in GeoTools can absolutely have a positive effect on the GeoTools team in this regard. I think it is important that you and others get involved and stress the importance of stability rather than just giving up and duplicating things. I was keen on GeoTools being an OSGeo project because I think the Java community needs a strong library or set of libraries to build on. GeoTools seems the clear and obvious choice for this role. Now what can we do to help it live up to that role? Now you are making me feel guilty. :] This is the most excellent point in your post Frank. If I'm screaming at the GeoTools folks because they keep chainging the Feature interface they'll be less prone to change it. :] (I wouldn't really scream, but I'd complain enthusiastically.) I recognize that it is important for projects like OpenJUMP to get involved in GeoTools so the project can make improvements. It's not fair to criticize without making an effort to solve the problems. Frank wrote: In the meantime I'd like to strongly encourage you build some sort of adapter so that any geotools feature source can be used as an OpenJUMP feature source, even if there is a bit of extra conversion between feature models always going on. This is the direction that I am leaning in. I need to think about it a little more, and perhaps bounce a couple of more things off of the OpenJUMP community. Frank wrote: I don't
Re: [JPP-Devel] [Geotools-devel] Requesting some thoughts on GeoTools...
Well, perhaps you're right, Frank. These days a few meg one way or the other doesn't make much difference. At least GDAL has a nice stable API, which encourages people to commit to depending on it. Certainly the idea of having One core API to rule them all is appealing. Perhaps someone will have time to sit down and look at the implications of moving JUMP closer to GeoTools. The API instability is a huge issue, however, and IMO would have be addressed in a pragmatic way. I'm guessing OJ would have to target a fixed version of GT for migration, and would not move quickly to new versions, even if there were important bug fixes. The fixes would have to patched into the JUMP version of GT, I think. So this means a fork of GT, in a minor, controlled way. If there's a better strategy, it would be very interesting to hear it. And then there's the issue of how close to stay to Vivid's branch of JUMP, and how to migrate all those plugins out there... Tough issues. So perhaps the first step is to look at CT and/or I/O, using converters to paper over the Feature model difference. Frank Warmerdam wrote: Martin, The same can certainly be said of GDAL ... that using the least of it's services means you have to buy into several megabytes of .so/DLL. Yet this hasn't been a big barrier in the C world. I would encourage accepting GeoTools as a prereq. I will conceed the JAI is an unpleasant requirement. I have been frustrated by this every time I have made a feeble effort to work with GeoTools myself - and get the Java environment setup properly. I think your point about keeping the JUMP API approachable and stable is quite reasonable. Best regards, -- Martin Davis Senior Technical Architect Refractions Research, Inc. (250) 383-3022 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
