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 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 GeoTools Shapefile
> code some more over the next couple of weeks, and I know I will have
> more questions. Any code I write to convert between the GeoTools and
> JUMP feature models will be released under the SurveyOS Project. I
> would normally use the GPL, but I think someone mentioned the GeoTools
> folks would prefer the LGPL. I don't think this will be a problem.
>
> The Sunburned Surveyor
>
>
>
>
>
>
>
>
> On 4/19/07, *Jody Garnett* <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
> 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 take advantage of.
> >
> > You mentioned the difference in GUI toolkits between OpenJUMP and
> > GeoTools (uDig?). I don't think you should focus on sharing GUI
> > components at this time. This is another whole ball of wax, and
I'd
> > claim that the C/C++ world has shown that a huge amount of sharing
> > and leverage can be accomplished without sharing GUI components.
> >
> > Anyways, this email is really my plea to OpenJUMP and indirectly
> to other
> > projects in the FOSS4G community to treat GeoTools as a building
> block,
> > to get involved and to provide strong feedback on the importance
> for
> > stability if that is important to you.
> >
> > The Java world has a quite reasonable desire for "pure java"
> solutions,
> > but make that work I think it is important to share labour on a
> lot of
> > common low level components.
> >
> > Best regards,
> >
>
>
>
-------------------------------------------------------------------------
> 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
> <mailto:Jump-pilot-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> <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
>
--
public class WhoDidIt{ // A comment. I love comments
private static Person sender;
public static void main (String[] foo){
sender = new Person();
sender.setName(new String[]{"Edgar", "Soldin"});
Address address = new Address();
address.setStreet("Stadtweg 119");
address.setZip(39116);
address.setCity("Magdeburg");
address.setCountry("Germany");
sender.setAddress(address);
sender.setMobilePhone(" +49(0)171-2782880 ");
sender.setWebSiteUrl(" http://www.soldin.de ");
sender.setEmail(" [EMAIL PROTECTED] ");
sender.setPGPPublicKey(" http://www.soldin.de/edgar_soldin.asc ");
sender.setGender(true);
System.out.println(sender.toString());
}
}
-------------------------------------------------------------------------
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
