Martin, Are my efforts to slowly integrate GeoTools into OpenJUMP misguided?
Markus mentioned using some of the code from the Deegree project. However, I don't know if the Deegree project contains the source code for things like data I/O and map projections. If the Deegree project does contain this code, perhaps Markus can let me know. My original desire to tap into GeoTools came from my desire to avoid writing new Shapefile drivers for JUMP. It looked like the GeoTools developers had done some good work in this area. However, it seems like there is a lot of opposition to this effort on my part. Perhaps I should tinker with GeoTools in my own work and quit discussing it on the mailing list? Is there any other OpenJUMP developer that is interested in tapping into GeoTools? If there isn't I'll back off on the whole idea. The Sunburned Surveyor On 6/4/07, Martin Davis <[EMAIL PROTECTED]> wrote: > Makes sense to me, Markus & Paolo. > > I have to admit, when I read Justin's and Jody's notes, I get a bad case > of EGO (Eyes Glaze Over...). Maybe I'm just dumb, but the GT & GeoAPI > work seems pretty complex. At the moment JUMP is providing a lot of > value to people with a pretty simple model. I'm not keen to dive in and > make a wholesale change to something which is much more complex and much > more volatile. I'd much rather see slow and steady incremental improvement. > > Maybe there will come a day when the GT/GeoAPI model has been stable for > a couple of years and it is blindingly obvious that it is the One True > Geospatial API - at that time JUMP can maybe migrate to it. > > If people really need a more complex Feature model etc - there's always > uDig! > > Martin > > > Markus Müller wrote: > > Folks, > > > > I try for another time... > > > > Paolo lists some of the same reasons why we (-> in deegree) decided to > > develop a separate Feature Model. Another reason was that we needed it > > sooner as GT, the cause for this seems to be that in Germany support of > > complex GML applications schemas was pretty soon pretty important. The > > deegree2 Feature Model was put to use in a number of projects and it is > > stable. So I propose (again): if OJ goes into the direction of support > > for complex features, please consider using the deegree Feature Model. > > > > Additionally I want to propose that if such a decision (regarding a > > complex feature model) is made, this should IMHO be done in a new, > > experimental branch of the OJ CVS, as (as Paolo says) a simple Feature > > Model has a number of advantages such as simplicity and stability. I > > would be good if this new development would go through some development > > stages, before a final decision is made. > > > > > > best regards, > > > > Markus > > > > > > P.Rizzi Ag.Mobilità Ambiente schrieb: > > > >> Maybe the situation has improved in the last year or so, > >> but one of the reason why we decided to abandon uDig and GeoServer > >> was indeed the GeoTools Feature model. > >> They keep changing it, adding more and more new functionalities, > >> without bothering for stability. > >> One of the best thing about JUMP is that it has a simple Feature model > >> and that it works!!! > >> If you want to move to a more complex model you should be aware that > >> you may end up losing simplicity and stability. > >> About using GeoTools DataStores (aka drivers) to access data, > >> that was one other reason why we abandoned it. > >> DataStores for PostGIS and Oracle had many bugs, but no one cared > >> to fix them. And the changing Feature model prevented us to fix them > >> on our own, without wasting a lot of time keeping in sync with the changes. > >> If you want to use GT DataStores, you could write a simple adapter > >> that converts between their Feture model and JUMP on the fly. > >> > >> Bye > >> Paolo Rizzi > >> > >> > >> > >> > >>> -----Messaggio originale----- > >>> Da: [EMAIL PROTECTED] > >>> [mailto:[EMAIL PROTECTED] conto di > >>> Sunburned Surveyor > >>> Inviato: martedì 5 giugno 2007 1.29 > >>> A: List for discussion of JPP development and use. > >>> Cc: Geotools-Devel list > >>> Oggetto: Re: [JPP-Devel] Common Feature model > >>> > >>> > >>> There is almost too much good stuff going on around here to > >>> keep up with. :] > >>> > >>> Paul wrote: "I agree if the open source GIS community can agree on a > >>> single in memory Java representation for geographic features that > >>> would make all the tools more interoperable." > >>> > >>> You should definitely get more involved with the GeoTools folks. We > >>> had some pretty extensive discussion about this very issue not to long > >>> ago on this mailing list. Some of the GeoTools folks participated, as > >>> did Frank Wammerdam. (Frank is no longer subscribed.) > >>> > >>> I think we identified some of the reasons why adopting the GeoTools > >>> feature model into OpenJUMP at "one time" isn't practical. However, we > >>> had some general agreement that it would be good to move OpenJUMP > >>> towards using the GeoTools feature model as we move forward. > >>> > >>> I will be using the GeoTools feature model in my FeatureCache > >>> implementation, which will allow me to store features from and data > >>> source for which there exists a GeoTools driver. One of my goals in > >>> the use of the GeoTools feature model in this project was to see how > >>> well it will play with OpenJUMP. It will give me a chance to get to > >>> know the GeoTools code that is involved, and will help me identify > >>> challenges that exist in our eventual migration of OpenJUMP to the > >>> GeoTools feature model. > >>> > >>> A key first step in making this migration is creating an class that > >>> can convert between GeoTools Feature objects and JUMP Feature objects. > >>> Edgar Soldin has already done some work in this area and I hope to > >>> continue it. > >>> > >>> In summary, we are a long ways towards sharing a common feature model > >>> with UDig, but I think we are starting to explore that possibility > >>> with some concrete steps. I think there is wisdom in this, because "if > >>> the open source GIS community can agree on a single in memory Java > >>> representation for geographic features" it will be the one in > >>> GeoTools. > >>> > >>> Paul wrote: "Here are the requirements I have. > >>> > >>> Ids can be any type not just an int > >>> Properties can contain complex objects including other > >>> features or POJO > >>> Properties can contain a collection (List or Set) value > >>> Features don't have to have a schema (useful when transforming a > >>> feature from one schema to another) " > >>> > >>> I'm almost positive that the GeoTools folks have already considered > >>> many of these issues. In the end developers have to find the balance > >>> between the ultimate flexibility and a system that can be used. By its > >>> very nature a system must have some structure to be usable, and > >>> structure means constraints. For example, the most flexible way to > >>> represent geographic features in Java would be to just have them > >>> extend of the Object class. But that doesn't do anyone a lot of good, > >>> does it? > >>> > >>> You need to be able to assume some things about the Feature you are > >>> working with, and that means it has to obey some rules. I think it > >>> would be foolish to debate again what has already been debated by some > >>> of the smart folks at GeoTools. I think they must have good reasons > >>> for settling on the feature model they chose. > >>> > >>> I really don't think the best solution is significantly changing > >>> OpenJUMP's feature model, but adopting and then working to improve the > >>> GeoTools feature model. > >>> > >>> The Sunburned Surveyor > >>> > >>> > >>> > >>> On 6/4/07, Paul Austin <[EMAIL PROTECTED]> wrote: > >>> > >>> > >>>> The reason I was thinking of Object type for Ids is that > >>>> > >>>> > >>> then you could use > >>> > >>> > >>>> a Long, Integer or String for the feature ID depending on > >>>> > >>>> > >>> the type of data. > >>> > >>> > >>>> I normally use Long but some models may use String based > >>>> > >>>> > >>> globally unique > >>> > >>> > >>>> ids, I wouldn't want to use String for numeric fields all the time. > >>>> > >>>> On the schema issue, I still like to have a schema > >>>> > >>>> > >>> associated with a feature > >>> > >>> > >>>> but not making it mandatory, having the schema there allows > >>>> > >>>> > >>> you to do > >>> > >>> > >>>> validation on the feature to make sure it conforms to the > >>>> > >>>> > >>> schema (e.g. type > >>> > >>> > >>>> and allowed values for enumerations). > >>>> > >>>> When I'm looking at a feature model I'm looking at it for > >>>> > >>>> > >>> passing around in > >>> > >>> > >>>> a processing pipeline for transformation, spatial > >>>> > >>>> > >>> processing and validation > >>> > >>> > >>>> rather than just for the display in JUMP. > >>>> > >>>> Paul > >>>> > >>>> > >>>> Michaël Michaud wrote: > >>>> Hi Paul, > >>>> > >>>> > >>> 1. Do you really need Object type for ids (I think ids are Strings > >>> > >>> > >>>> in > >>>> > >>>> > >>> GeoTools - don't know if there is performance penality compared to int > >>> > >>> ids, or some cases where a genaral Object type is needed) > >>> 2/3. If I can > >>> > >>> > >>>> remember, GeoTools complex feature model fulfill 2 and 3 > >>>> > >>>> > >>> requirements, and > >>> > >>> > >>>> define a subclass (SimpleFeature ?) looking like > >>>> > >>>> > >>> jump's feature model (more > >>> > >>> > >>>> or less) > >>>> > >>>> > >>> 4. I already thought that a feature should't have a schema. > >>> > >>> Fundamentally, I think a feature is like a map with attribute/value > >>> pairs, > >>> > >>> > >>>> and that feature schema belong to the feature collection level. > >>>> > >>>> > >>> It would be > >>> > >>> > >>>> interesting to know why jump's designers have choosen to > >>>> > >>>> > >>> include a > >>> > >>> > >>>> featureschema reference in each feature. > >>>> > >>>> > >>> Michaël > >>> > >>> Paul Austin a écrit : > >>> > >>> > >>> > >>> > >>>> I agree if the open source GIS community can agree on a single in > >>>> > >>>> > >>> memory > >>> > >>> > >>>> Java representation for geographic features that would make all > >>>> > >>>> > >>> the tools > >>> > >>> > >>>> more interoperable. Right now I'm using my own schema and > >>>> > >>>> > >>> feature model but > >>> > >>> > >>>> would prefer not to maintain that in the future. > >>>> > >>>> > >>> Here are the requirements > >>> > >>> > >>>> I have. > >>>> > >>>> > >>> 1. Ids can be any type not just an int > >>> 2. Properties can contain > >>> > >>> > >>>> complex objects including other features > >>>> > >>>> > >>> or POJO > >>> 3. Properties can contain > >>> > >>> > >>>> a collection (List or Set) value > >>>> > >>>> > >>> 4. Features don't have to have a schema > >>> > >>> > >>>> (useful when transforming a > >>>> > >>>> > >>> feature from one schema to > >>> > >>> > >>>> another) > >>>> > >>>> > >>> Paul > >>> > >>> > >>> -------------------------------------------------------------- > >>> ---------- > >>> > >>> -------------------------------------------------------------- > >>> ----------- > >>> 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 > >>> > >>> > >>>> > >>>> > >>> -------------------------------------------------------------- > >>> ----------- > >>> > >>> > >>>> 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 > >>> > >>> > >>> > >> ------------------------------------------------------------------------- > >> 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 > >> > >> > > > > > > > > -- > 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 > ------------------------------------------------------------------------- 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
