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
