Re: [JPP-Devel] FeatureInfo table on steroids
Hi Martin and all, I must admit I have trouble following the discussion on this list with this amount of activity going on. ;-) Martin Davis schrieb: > [snip] > > More generally, this is all moving in the direction of supporting a full > GML-like data model, where Features can contain FeatureCollections as > attributes. I think deegree might have already extended JUMP to > accomodate this - it would be nice to hear from them how well this > worked and what they had to do to make it work. > > We would definitely like to to that but we are still on the lookout for funding. Possibly we can start working on this pretty soon, but then we would like to do this as part of OpenJUMP and together with the community - if there is interest. Meanwhile: if there are plans on implementing a complex feature model in OpenJUMP, it might be a good idea to have a look at the deegree2 Feature Model. [snip] cheers Markus -- Dr. Markus Müller l a t / l o n GmbH (Hamburg) Gluckstr. 53a 22081 Hamburg, Germany phone ++49 +177 2470742 fax ++49 +228 18496-29 http://www.lat-lon.de http://www.deegree.org -- - 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] Unstable branch of the OpenJUMP CVS...
Hello Craig, SS, "A. Craig West" <[EMAIL PROTECTED]>, [20070604 - 22:22:16] > Normally, the head is the unstable code, and any changes which have > been tested get merged to the stable branch... Yes, that was my intention to tell as well. I strongly suggest to follow this schema in OJ-development as well. > On 6/4/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote: > > Stephan, > > > > You wrote: "I am more than happy to watch the process of getting a > > development trunk in OpenJUMP development." > > > > That is awesome. I don't think that anyone is going to argue with > > your volunterring. :] > > > > You wrote: "The so called trunk is the (current) CVS HEAD which gets > > branched into release-branches which can be kept separately." > > > > I think I am trying to describe the same thing, but not as well.I > > may have incorrectly referred to a "stable branch" and an "unstable > > branch" when what we really want is a stable code in the trunk or > > CVS HEAD and a branch for the unstable code. > > > > The Sunburned Surveyor > > > > P.S. - Are you a registered developer on SourceForge? You will need > > to be registered before we will be able to give you admin rights to > > the CVS repository at the JPP. Yes, I do have an account, I have access to CVS, at least to the modules WFSPlugin and PrintLayoutPlugin which I manage. [snip] Best Stephan -- Stephan Holl <[EMAIL PROTECTED]>, http://intevation.de/~stephan Tel: +49 (0)541-33 50 8 32 | Intevation GmbH | AG Osnabrück - HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner - 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] Unstable branch of the OpenJUMP CVS...
Normally, the head is the unstable code, and any changes which have been tested get merged to the stable branch... -Craig On 6/4/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote: > Stephan, > > You wrote: "I am more than happy to watch the process of getting a development > trunk in OpenJUMP development." > > That is awesome. I don't think that anyone is going to argue with your > volunterring. :] > > You wrote: "The so called trunk is the (current) CVS HEAD which gets > branched into release-branches which can be kept separately." > > I think I am trying to describe the same thing, but not as well.I may > have incorrectly referred to a "stable branch" and an "unstable > branch" when what we really want is a stable code in the trunk or CVS > HEAD and a branch for the unstable code. > > The Sunburned Surveyor > > P.S. - Are you a registered developer on SourceForge? You will need to > be registered before we will be able to give you admin rights to the > CVS repository at the JPP. > > > > On 6/4/07, Stephan Holl <[EMAIL PROTECTED]> wrote: > > Hello Sunburned, > > > > I am more than happy to watch the process of getting a development > > trunk in OpenJUMP development. As I am no dev (and therefor not able > > to voite) but a power-user I would second Saschas proposal of CVS > > structure: > > > > > > > > > > 1 monthn-month (n+1)-month > > > > > --\ devel-\...---\--\-\--> > > > > >\ \ \ \ \ > > > > > release 1.2 ---\ \ \ > > > > > \ \ \ > > > > > release 1.3> > > > > The so called trunk is the (current) CVS HEAD which gets branched into > > release-branches which can be kept separately. I am involved in several > > OS software development where this structure is quite common. > > > > To introduce this now would lead into adding a branch (release_1.2) of > > the current HEAD. Perhaps it is not so difficult to set up nightly > > builds from both HEAD and release-branch? > > > > Just my 0.02 ¢ > > > >Stephan > > > > > > "Sunburned Surveyor" <[EMAIL PROTECTED]>, > > [20070604-10:34:27]: > > > > > I took some time to read over the chapter in the CVS manual on > > > branching and merging. I have some comments now on the method I think > > > we should use for the development branch in the OpenJUMP CVS. > > > > > > I believe that we should use the method described in Michael's option > > > #3 in this thread. This is basically two branches in the CVS, one > > > stable and one unstable. Developers can work on and test changes and > > > new features in the development branch. When changes or new features > > > have been completed in the unstable branch they can be merged into the > > > stable branch, as long as they don't break the nightly build. (The > > > nightly build will continue to be built from the stable branch.) > > > > > > Sascha wrote: "I would vote for short merging intervals (1 month or > > > so). Such a merge brings the current release to a new second digit > > > after the stable version number (1.2 -> 1.2.1). If we think > > > its time for new major release we can increment the first > > > after dot (1.2 -> 1.3). Having the devel and the stable > > > branch coupled so tightly helps us to fix urgent bugs in time > > > and develop new features." > > > > > > I don't know how well this will work for our group of developers. I > > > may be mistaken, but under this type of system I believe all changes > > > or new features in the unstable branch would have to be working in a > > > month of less after they are commited, because they will be going into > > > the stable branch at 1 month intervals. I can forsee a situation under > > > this sytem where we are always holding back a merge of the stable and > > > unstable branches because one or more developers (probably me) doesn't > > > have his stuff "working" and ready to commit. Then the other > > > developers are upset because they have to wait for their changes to > > > get into the stable brach via the merge. > > > > > > I would suggest this system as a possible alter
Re: [JPP-Devel] Support for non-spatial features...
Martin wrote: "...Actually, my original concept for JUMP was that there would be a Catalog concept, with a UI which showed all the spatial tables which were loaded and exposed as Layers in Task map views. Non-spatial tables would have just shown up in the Catalog window. Ideally you could drag'n'drop layers to Layer Lists... this will sound familiar to ArcGIS users 8^)" I like this idea of managing non-spatial features in a catalog as well. Martin wrote: "Or, you could use the current Load/Save Dataset dialog, but some Readers would create non-spatial tables which would appear in the Table View (Catalog)" This is a good idea as well. Why have a separate UI component to load data sources? (But if we tried to modify the existing datasources dialog we might not be able to use a plug-in. I'll have to think about this one.) Martin wrote: "We certainly don't want to re-invent the wheel, but there is a set of functionality which *has* to be in JUMP, since it isn't provided by any DB. This includes: - the UI components - single Feature model which is general enough to support both spatial and non-spatial tables/hierarchies - probably I/O drivers for some non-spatial formats AFAIK there's no way around building a model which replicates quite a bit of the model in an RDB. This is because JUMP cannot be tied to any one DB model - it needs to be more general if it is going to support more than one data source." I we used an embedded Java database to store non-spatial features in an OpenJUMP plug-in I only see the need for JUMP to include one of the elements you mentioned in your list: The UI components. I think I am taking a different approach. I wouldn't modify the Feature model at all. Instead I would create a separate model, with NonSpatialFeature at the top of the model's class diamgram. I think this would allow us to avoid making a lot of other changes to OpenJUMP. The plug-in would be built to independently manage non-spatial features and to track the relationships, if any, between spatial features and non-spatial features. I also think a smart plug-in developer (not me) would be able to "hide" the embedded Java database from the end user while gaining a lot of the features offered by the embedded database. But then again, if you want simplicity forget the embedded database all together and just create the code to work with the non-spatial features directly. I have no time to work on this concept in the near future, but it is enlightening to have the discussions. :] Martin wrote: "GeoTools has already trodden this path well... Check out their design if you want to see just how much a general-purpose framework has to include." I know we have a few GeoTools developers lurking on the list. Perhaps they will comment on this topic for me. (Then again, they may not be reading much of our list with all of the traffic lately.) The Sunburned Surveyor On 6/4/07, Martin Davis <[EMAIL PROTECTED]> wrote: > > > Sunburned Surveyor wrote: > > I still think you could encapsulate this functionality in a plug-in or > > set of plug-ins. This might not be the best way to go long term, but > > it could let us test out how things would work without messing with > > the core. > > > > For example, I wouldn't even mess with the Layer List. I'd create a > > separate UI component that could be used to manage non-spatial feature > > collections or tables. We could make it look similar to the Layer List > > for purposes of consistency. I think it would be a little confusing to > > include symbols for non-spatial feature collections in the Layer List. > > They wouldn't affect the display order for one thing, and we currently > > use the visual arrangement of layers in the Layer List to do this. > > > Good idea - this is probably a better way to do this. (Actually, my > original concept for JUMP was that there would be a Catalog concept, > with a UI which showed all the spatial tables which were loaded and > exposed as Layers in Task map views. Non-spatial tables would have just > shown up in the Catalog window. Ideally you could drag'n'drop layers to > Layer Lists... this will sound familiar to ArcGIS users 8^) > > > I imagined a plug-in that created a "Non-Spatial Feature" menu entry > > somewhere. This menu entry would pull up a UI that would allow the > > user to create, delete, modify, and import/export non-spatial feature > > collections. > > > Or, you could use the current Load/Save Dataset dialog, but some Readers > would create non-spatial tables which would appear in the Table View > (Catalog) > > Another related plug-in could be used to create associations between > > non-spatial feature collections and spatial feature collections. I > > think most of this functionality could be managed internally by the > > plug-in. > > > Sure, this could just be extra menu items somewhere, either on the main > menu bar or in a Catalog-only menu. > > These are just some ideas. :] > > > > I think one danger of walking dow
Re: [JPP-Devel] writing help for Openjump
Inkscape: http://www.inkscape.org/ Scribus: http://www.scribus.net/ OpenJUMP Basics Tutorial: http://superb-west.dl.sourceforge.net/sourceforge/jump-pilot/OpenJUMP1.0.1_Tutorial_englishBeta.pdf On 6/4/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote: > Giuseppe, > > We should definitely work together on the OpenJUMP documentation. I > can help you with the English translations of your work. > > Have you ever used the open source desktop publishing software > Scribus? How about the vector program Inkscape? Those are two of the > tools that I am using to write the OpenJUMP documentation. > > Even if you aren't intersted in using these tools, if you provide the > raw text I can work on editing the English version and the layout. > > Let me know if there are specific topics you are intersted in > documenting. I have started work on documenting the new features in > OpenJUMP, but it looks like you are systematically working your way > through the menu structure. I don't think it will be too hard to > combine our efforts. > > We could easily coordinate this on the wiki. > > Thanks for posting about your documentation efforts. > > The Sunburned Surveyor > > P.S. - I believe Ugo and Steve Tanner have worked on a version of an > English tutorial for OpenJUMP that may be some help to you. You can > download it from the JPP SourceForge site. > > > > On 6/4/07, Michaël Michaud <[EMAIL PROTECTED]> wrote: > > Hi Giuseppe, > > > > There is some JUMP's technical and user documentation on the original > > JUMP's site (a bit old but very nice), > > and a more recent tutorial for OpenJUMP you can download from > > http://sourceforge.net/project/showfiles.php?group_id=118054 > > This OpenJUMP tutorial has been translated from german to english and to > > french > > In my opinion, what are missing now are > > - online help > > - a manual for advanced features (ex. features from the Tool menu) > > > > Any help is welcome (Sunburned Surveyor already did some work for > > advanced feature documentation) > > > > Michaël > > > > Giuseppe Aruta a écrit : > > > > >Hi > > >I am new to this list so welcome to everybody > > > I am writing a sort of "Help" in English for > > >OpenJUMP. I am still at the beginning and it will take > > >a good month. > > >Since I need some ideas and advices I am sending the > > >part I wrote. Good advices for English are very > > >welcome. > > >I want to know if there is a similar project, > > >developed by some OpenJUMP user. > > > > > >Thanks > > > > > >Giuseppe > > > > > > > > > ___ > > >L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: > > >http://it.docs.yahoo.com/nowyoucan.html > > > > > > > > > > > >- > > >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
Re: [JPP-Devel] writing help for Openjump
Giuseppe, We should definitely work together on the OpenJUMP documentation. I can help you with the English translations of your work. Have you ever used the open source desktop publishing software Scribus? How about the vector program Inkscape? Those are two of the tools that I am using to write the OpenJUMP documentation. Even if you aren't intersted in using these tools, if you provide the raw text I can work on editing the English version and the layout. Let me know if there are specific topics you are intersted in documenting. I have started work on documenting the new features in OpenJUMP, but it looks like you are systematically working your way through the menu structure. I don't think it will be too hard to combine our efforts. We could easily coordinate this on the wiki. Thanks for posting about your documentation efforts. The Sunburned Surveyor P.S. - I believe Ugo and Steve Tanner have worked on a version of an English tutorial for OpenJUMP that may be some help to you. You can download it from the JPP SourceForge site. On 6/4/07, Michaël Michaud <[EMAIL PROTECTED]> wrote: > Hi Giuseppe, > > There is some JUMP's technical and user documentation on the original > JUMP's site (a bit old but very nice), > and a more recent tutorial for OpenJUMP you can download from > http://sourceforge.net/project/showfiles.php?group_id=118054 > This OpenJUMP tutorial has been translated from german to english and to > french > In my opinion, what are missing now are > - online help > - a manual for advanced features (ex. features from the Tool menu) > > Any help is welcome (Sunburned Surveyor already did some work for > advanced feature documentation) > > Michaël > > Giuseppe Aruta a écrit : > > >Hi > >I am new to this list so welcome to everybody > > I am writing a sort of "Help" in English for > >OpenJUMP. I am still at the beginning and it will take > >a good month. > >Since I need some ideas and advices I am sending the > >part I wrote. Good advices for English are very > >welcome. > >I want to know if there is a similar project, > >developed by some OpenJUMP user. > > > >Thanks > > > >Giuseppe > > > > > > ___ > >L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: > >http://it.docs.yahoo.com/nowyoucan.html > > > > > > > >- > >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
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 m
Re: [JPP-Devel] Common Feature model
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
Re: [JPP-Devel] Common Feature model
Stefan, POJO is a Plain Old Java Object so when you see that it means the property value can be any Java object, we don't have to know how to handle it but some models may require the data to be persevered. A feature without a schema is basically just a Map of property names to values, rather than the JUMP features where you have an array and it's the schema which maps from the array index to the property name. In some cases this is too rigid a model, consider the case where you want to rename from one schema to another or create additional properties e.g. a geometry from a lat/lon property values. This may need to be done in several steps, which you couldn't do easily with the fixed feature model in JUMP. Paul Stefan Steiniger wrote: hei.. i did not read all the stuff before until now... but.. your suggestions are nice.. but if i think what all need to be changed (especially in terms of avoiding errors).. i don't know? but maybe it is more simple than i thought if one can simply add some feature properties such as AttribtuteType.Collection or Feature.hasSchema()? Although i don't understand how a feature can not have a schema. Otherwise it is a geoemtry? BTW. what is a POJO? sorry guys stefan Paul Austin schrieb: 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
Re: [JPP-Devel] Common Feature model
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
Re: [JPP-Devel] Common Feature model
hei.. i did not read all the stuff before until now... but.. your suggestions are nice.. but if i think what all need to be changed (especially in terms of avoiding errors).. i don't know? but maybe it is more simple than i thought if one can simply add some feature properties such as AttribtuteType.Collection or Feature.hasSchema()? Although i don't understand how a feature can not have a schema. Otherwise it is a geoemtry? BTW. what is a POJO? sorry guys stefan Paul Austin schrieb: > 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
Re: [JPP-Devel] Support for non-spatial features...
Sunburned Surveyor wrote: > I still think you could encapsulate this functionality in a plug-in or > set of plug-ins. This might not be the best way to go long term, but > it could let us test out how things would work without messing with > the core. > > For example, I wouldn't even mess with the Layer List. I'd create a > separate UI component that could be used to manage non-spatial feature > collections or tables. We could make it look similar to the Layer List > for purposes of consistency. I think it would be a little confusing to > include symbols for non-spatial feature collections in the Layer List. > They wouldn't affect the display order for one thing, and we currently > use the visual arrangement of layers in the Layer List to do this. > Good idea - this is probably a better way to do this. (Actually, my original concept for JUMP was that there would be a Catalog concept, with a UI which showed all the spatial tables which were loaded and exposed as Layers in Task map views. Non-spatial tables would have just shown up in the Catalog window. Ideally you could drag'n'drop layers to Layer Lists... this will sound familiar to ArcGIS users 8^) > I imagined a plug-in that created a "Non-Spatial Feature" menu entry > somewhere. This menu entry would pull up a UI that would allow the > user to create, delete, modify, and import/export non-spatial feature > collections. > Or, you could use the current Load/Save Dataset dialog, but some Readers would create non-spatial tables which would appear in the Table View (Catalog) > Another related plug-in could be used to create associations between > non-spatial feature collections and spatial feature collections. I > think most of this functionality could be managed internally by the > plug-in. > Sure, this could just be extra menu items somewhere, either on the main menu bar or in a Catalog-only menu. > These are just some ideas. :] > > I think one danger of walking down the "non-spatial" feature path is > that we will begin to implement more and more traditional RDBMS > features. (For example: "Let's ass support for transactions to our > non-spatial feature collections."..."Let's add support for custom > datatypes to our non-spatial feature collections."..."Let's add > support for datatype constraints to our non-spatial feature > collections.") Perhaps the smart thing to do is to design a system for > non-spatial features that uses an embedded Java database that already > contains all of this functionality. I wouldn't have a problem with > this if we could access the database components directly without > having to mess with a JDBC layer. (Note: I'm not talking about storing > the attribute information for spatial features in an embedded > database. I think the Sigle team is already working on something like > this. I'm talking about storing the attributes of non-spatial > features. > > Then again, maybe it wouldn't be a big deal to implement some RDBMS > features if we have support for non-spatial features in OpenJUMP. It > just seems like a waste of effort with all the work that must be going > on in open source Java databases. > We certainly don't want to re-invent the wheel, but there is a set of functionality which *has* to be in JUMP, since it isn't provided by any DB. This includes: - the UI components - single Feature model which is general enough to support both spatial and non-spatial tables/hierarchies - probably I/O drivers for some non-spatial formats AFAIK there's no way around building a model which replicates quite a bit of the model in an RDB. This is because JUMP cannot be tied to any one DB model - it needs to be more general if it is going to support more than one data source. I was going to say that transactions at least should be left to the DB, but even then JUMP has to have a certain awareness of transactions (e.g. marking modified Features as dirty). (The ACID properties are best left to an underlying DB, however) GeoTools has already trodden this path well... Check out their design if you want to see just how much a general-purpose framework has to include. > Michael wrote: "And what about having a way to join a spatial layer in OJ to a > non-spatial db table or view, and to see the whole result as one flat > layer in OJ..." > > Good idea... > > Martin wrote: "Yes, definitely that would be cool. This would be > equivalent to a > defining a view in an RDBMS." > > See! That is what I was talking about. :] > > SS > > - > 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-dev
Re: [JPP-Devel] FeatureInfo table on steroids
Ok, sounds cool. One slight clarification/comment - I don't think you want to "switch on the fly the renderers in the registry". The whole idea behind the Registry is that it is a pretty much static container of components (or Strategy objects). Registry items can be added (by plugins or on startup) but they should never be deleted or modified after that. If you are looking for a single overall JUMP-wide preference for which text renderer to use for a given class, then how about making a TextRendererPreferences class with a singleton instance, and keep the users current preferences in that. (This should probably be generalized to an overall UserPreferences class which keeps track of everything a user wants to configure). Whether the text rendering for every class (or even just Geometry) should be controlled by a single user preference I'm not sure sure. My usage pattern is more that I want to be able to switch between different text renderings in whatever window or tool I'm currently looking at. Some tools need to be able to parse the text representation back in (such as the Geometry Edit view), so they will impose constraints on what rendering can be used. Paul Austin wrote: > Hi Martin, > > I'm just working on a concept of a HtmlRenderer that will take an > object and convert it to HTML for display in Swing HTML widgets. There > will then be a HtmlRendererRegistry that will map from a Java Class to > a renderer. When displayign features you would use the registry to get > a renderer for an object and use this to generate the HTML. > > We could then extend this concept for things like geometry where the > user can via the UI choose between a choice of renderers for that > class (e.g. WKT, GML), those plug-ins would switch on the fly the > renderer in the registry. > > The registry should also support the property change listener so that > UI's can refresh themselves if the registry changes. > > Paul > > Martin Davis wrote: >> Your suggestions for enhancing the FeatureInfoTable view all sound good >> to me, Paul. It's a nice idea to have different Geometry text >> renderers. I might even go further and define a simple framework for >> GeometryTextRenders, which could have different instantiations added in >> the Registry. The FeatureInfoTable view could display choices for all >> loaded renderers. >> >> As for the compound Feature idea, this seems to depend on having Readers >> which can actually create these things. It sounds like you have defined >> a custom reader for your need. I would be reluctant to build very much >> functionality for compound Features into the core until there is a >> clearer idea about the general use cases for them, and what would be >> required to make them usable throughout JUMP. For now hopefully adding >> some hooks to extend the FeatureInfoTable view will meet your need. >> >> BTW, the idea of having hum-readable names for FeatureSchemas is a nice >> one. I'd definitely support adding that functionality, even if it isn't >> exposed right now. >> >> More generally, this is all moving in the direction of supporting a full >> GML-like data model, where Features can contain FeatureCollections as >> attributes. I think deegree might have already extended JUMP to >> accomodate this - it would be nice to hear from them how well this >> worked and what they had to do to make it work. >> >> I think there might be some big UI challenges in accomodating a >> hierarchical Feature model, but it might be worth building the >> infrastructure (i.e. enhancing the feature package), and then gradually >> enhancing the UI to expose more and more of it. It should be possible >> to provide sensible default UI behaviour wherever necessary. >> >> >> Paul Austin wrote: >> >>> All, >>> >>> I have attached a screen shot of my new Feature InfoTable >>> implementation. As you can see I've added some CSS styling to the >>> table and where there are "nested" feature types have the feature type >>> name displayed and a nested table with their attributes. >>> >>> NOTE: The sub feature type name stuff won't work with regular JUMP >>> features as the FeatureSchema does not include the feature type name. >>> I'm using my own Feature implementation based on the model used in my >>> reader framework. It would be simple to add this to FeatureSchema if >>> required. >>> >>> After looking at the current implementation I would like to suggest a >>> change to the way the who feature info table view works. >>> >>>1. Under the view menu have sub menu to allow the user to select >>> the style for viewing geometry (WKT, EWKT, CL, GML) in addition >>> to the current approach and save that so the user always get >>> their preference. >>>2. Implement a FeatureInfoTable renderer which defines the style >>> for the info view (e.g. HTML table, v.s. GML v.s. Tab/CSV format >>>3. Roll the FID and geometry attribute into th
Re: [JPP-Devel] Streamlining Java2DConverter decimation
I don't have time to look at it closely right now, but it sounds like
a logical simplification. I hate that temp array too.
regards,
Larry
On 6/4/07, Michaël Michaud <[EMAIL PROTECTED]> wrote:
> Hi Sascha;
>
> Sounds interesting.
> Please, let me some more time to have a closer look and see how your
> code compare to the one in CVS.
> Note : I made a recent change in CVS to have the resolution as a
> property and modify it as needed (default=1/2 pixel) for special renderers.
>
> Michael
>
> Sascha L. Teichmann a écrit :
>
> >Hi Larry, hi Michaël,
> >
> >I had a look at the decimation code in Java2DConverter.
> >This is awesome! Congratulations! :-)
> >
> >But way not go step further and streamline the model to view
> >coordination transform. Why to create all this temporary
> >Coordinate[] stuff? In the end all what matters is a PathIterator
> >that can handle an AffineTransform coming from Java2D.
> >Instead of transform the data to a temporary Coordinate array
> >and used this to construct GeneralPaths we can write a PathIterator
> >that transforms and decimates the data on-the-fly.
> >All we have to do is to concatenate the model to view transform to the
> >incoming matrix.
> >
> >To archive this we must add a
> >
> >AffineTransform getModelToViewTransform();
> >
> >method to the Java2DConverter.PointConverter interface. This
> >does not hurt because Viewport already implements it.
> >
> >To see what I mean, look at the DirectPolygonShape that I've
> >attached. It handles the Polygon case of Java2DConverter.
> >Add this class to the sources and change the toShape(Polygon)
> >method to look as follow:
> >
> > private Shape toShape(Polygon polygon) throws
> > NoninvertibleTransformException
> > {
> >return new DirectPolygonShape(
> > polygon,
> > pointConverter.getModelToViewTransform(),
> > 1d / (2d*pointConverter.getScale()));
> > }
> >
> >Speaking of performance. On my computer
> >(very old 1.2 GHz AMD/Athlon-T-Bird running GNU/Linux, Java 6)
> >the burluc layer is rendered in full extend without the streamling
> >in about 9.x seconds, with the streamling in about 8.x secs, with
> >x varying a bit. It's just a second, but it's a second! ;-)
> >
> >What do you think?
> >
> >Regards, Sascha
> >
> >
> >
> >
> >
> >/*
> > * The Unified Mapping Platform (JUMP) is an extensible, interactive GUI
> > * for visualizing and manipulating spatial features with geometry and
> > attributes.
> > *
> > * Copyright (C) 2003 Vivid Solutions
> > *
> > * This program is free software; you can redistribute it and/or
> > * modify it under the terms of the GNU General Public License
> > * as published by the Free Software Foundation; either version 2
> > * of the License, or (at your option) any later version.
> > *
> > * This program is distributed in the hope that it will be useful,
> > * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > * GNU General Public License for more details.
> > *
> > * You should have received a copy of the GNU General Public License
> > * along with this program; if not, write to the Free Software
> > * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307,
> > USA.
> > *
> > * For more information, contact:
> > *
> > * Vivid Solutions
> > * Suite #1A
> > * 2328 Government Street
> > * Victoria BC V8T 5G5
> > * Canada
> > *
> > * (250)385-6040
> > * www.vividsolutions.com
> > */
> >
> >package com.vividsolutions.jump.workbench.ui.renderer.java2D;
> >
> >import com.vividsolutions.jts.geom.Coordinate;
> >import com.vividsolutions.jts.geom.Polygon;
> >
> >import java.awt.Rectangle;
> >import java.awt.Shape;
> >import java.awt.geom.AffineTransform;
> >import java.awt.geom.GeneralPath;
> >import java.awt.geom.PathIterator;
> >import java.awt.geom.Point2D;
> >import java.awt.geom.Rectangle2D;
> >
> >import java.util.Iterator;
> >import java.util.NoSuchElementException;
> >
> >// for more accurate (float instead of int) rendering.
> >// From larry becker's SkyJUMP code to OpenJUMP [mmichaud]
> >// Streamlined [s-l-teichmann]
> >public class DirectPolygonShape
> >implements Shape
> >{
> > private Polygon polygon;
> > private AffineTransform model2view;
> > private double halfPixel;
> >
> > protected DirectPolygonShape(){
> > }
> >
> > /**
> >* @param polygonthe JTS polygon
> >* @param model2view the affine transform from model to view
> >* @param halfPixel line segments shorter than halfPixel are ignored.
> >*/
> > public DirectPolygonShape(
> > Polygon polygon,
> > AffineTransform model2view,
> > double halfPixel
> > ) {
> > this.polygon= polygon;
> > this.model2view = model2view;
> > this.h
[JPP-Devel] Common Feature model
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. 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) 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
[JPP-Devel] Support for non-spatial features...
I thought I would start a new thread so we could split this apart from the discussion that Paul and Martin were having about the FeatureInfo tool. When I suggested that support for non-spatial features could be included in a plug-in Martin wrote: "I had similar thoughts a while back. In fact, the Feature concept easily supports non-spatial features. About all that is required is to get the UI to recognize non-spatial Feature Schemas and do sensible things with them (such as display a little table icon rather than the symbology icon in the Layer List panel, and not display the button for View/Edit Geometry). There's quite a few of these kinds of changes required to support this cleanly, but I don't think any of them are very difficult. This is more than just a single plugin, tho - it's a more of a generalization of the existing Feature framework." I still think you could encapsulate this functionality in a plug-in or set of plug-ins. This might not be the best way to go long term, but it could let us test out how things would work without messing with the core. For example, I wouldn't even mess with the Layer List. I'd create a separate UI component that could be used to manage non-spatial feature collections or tables. We could make it look similar to the Layer List for purposes of consistency. I think it would be a little confusing to include symbols for non-spatial feature collections in the Layer List. They wouldn't affect the display order for one thing, and we currently use the visual arrangement of layers in the Layer List to do this. I imagined a plug-in that created a "Non-Spatial Feature" menu entry somewhere. This menu entry would pull up a UI that would allow the user to create, delete, modify, and import/export non-spatial feature collections. Another related plug-in could be used to create associations between non-spatial feature collections and spatial feature collections. I think most of this functionality could be managed internally by the plug-in. These are just some ideas. :] I think one danger of walking down the "non-spatial" feature path is that we will begin to implement more and more traditional RDBMS features. (For example: "Let's ass support for transactions to our non-spatial feature collections."..."Let's add support for custom datatypes to our non-spatial feature collections."..."Let's add support for datatype constraints to our non-spatial feature collections.") Perhaps the smart thing to do is to design a system for non-spatial features that uses an embedded Java database that already contains all of this functionality. I wouldn't have a problem with this if we could access the database components directly without having to mess with a JDBC layer. (Note: I'm not talking about storing the attribute information for spatial features in an embedded database. I think the Sigle team is already working on something like this. I'm talking about storing the attributes of non-spatial features.) Then again, maybe it wouldn't be a big deal to implement some RDBMS features if we have support for non-spatial features in OpenJUMP. It just seems like a waste of effort with all the work that must be going on in open source Java databases. Michael wrote: "And what about having a way to join a spatial layer in OJ to a non-spatial db table or view, and to see the whole result as one flat layer in OJ..." Good idea... Martin wrote: "Yes, definitely that would be cool. This would be equivalent to a defining a view in an RDBMS." See! That is what I was talking about. :] SS - 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] FeatureInfo table on steroids
Good point, Michael, I should have mentioned the GeoTools Feature model as a possible direction as well. Definitely it would be a good thing to evolve in their direction. I'm not sure how stable or baked the GT Feature model design is, but as it happens I sit right next to one of the chief GT architects (Jody Garnett) so I will ask him! 8^) Michaël Michaud wrote: > Hi Paul, > > Your feature info frame looks nice. > The discussion you have with Martin is very interesting and very > important as it is about JUMP's feature model. > I just want to mention other discussions we had on this list about the > interest to write bridges between JUMP's feature model and GeoTool's one > or to make JUMP's feature model closer to GeoTool's one. > I think the last feature model of GeoTools or the one they are talking > about for next version include such things as nested attributes where > attributes may be features or feature collections. > > Michaël > > Paul Austin a écrit : > > >> All, >> >> I have attached a screen shot of my new Feature InfoTable >> implementation. As you can see I've added some CSS styling to the >> table and where there are "nested" feature types have the feature type >> name displayed and a nested table with their attributes. >> >> NOTE: The sub feature type name stuff won't work with regular JUMP >> features as the FeatureSchema does not include the feature type name. >> I'm using my own Feature implementation based on the model used in my >> reader framework. It would be simple to add this to FeatureSchema if >> required. >> >> After looking at the current implementation I would like to suggest a >> change to the way the who feature info table view works. >> >>1. Under the view menu have sub menu to allow the user to select >> the style for viewing geometry (WKT, EWKT, CL, GML) in addition >> to the current approach and save that so the user always get >> their preference. >>2. Implement a FeatureInfoTable renderer which defines the style >> for the info view (e.g. HTML table, v.s. GML v.s. Tab/CSV format >>3. Roll the FID and geometry attribute into the table >> FeatureInfoTable renderer so that the geometry render is just >> used when geometry values are detected to display the value >> portion. So for example there would be a position row in the >> table that would have the geometry formatted as WKT or GML >>4. Where multiple records are displayed use a database style paging >> display where one feature is displayed at a time but you have >> back/forward, first/last and jump to record number. Think >> MSAccess or FME style paging through selected features. >> >> Any comments/suggestions? >> >> Paul >> >> Martin Davis wrote: >> >> >>> Is your use case only for a property which contains a single Feature? >>> The general case would be to have a property which contains a >>> FeatureCollection (this is the full GML model, for instance). In this >>> case the UI gets a bit more complicated. >>> >>> How are you creating the Feature property? Do you need to spatially >>> visualize it? >>> >>> I'm asking these questions because while your use case may simply be to >>> view a single Feature property, it's nice to look a bit further down the >>> road at a more general design, in order to avoid making the >>> implementation overly specific and hard to extend. >>> >>> In general supporting a hierarchical feature model introduces tons of >>> issues all through JUMP... which is why we didn't go there at first. >>> The closest we got was to support a custom object hierarchy and expose >>> different classes of it as separate FeatureCollections. This allowed >>> treating the various classes as map layers, which worked pretty well. >>> But this was all custom code and hard to make general-purpose. >>> >>> As for the code-value entry plugin, the general concept would clearly be >>> nice to have. Would your entry screen only support that single >>> attribute, or would you make a general entry panel which showed all >>> attributes? This was talked about a week or two ago - it would be nice >>> to have this as another view in the Attribute View window. How would >>> you supply the code-value mapping? >>> >>> Paul Austin wrote: >>> >>> >>> I have a data set where a property of a feature is another feature object. In the schema it has the type Object but it's actually a Feature instance.What I would like to do is have the following. 1. A right click on the feature row to view the whole feature and have a view/edit feature frame that would display the list of property names and values with nested panels for each nested feature. 2. Use the feature display panel to display the feature on say roll over of a complex property value Has anyone worked on such a feature? If not I'll start writing o
Re: [JPP-Devel] R: FeatureInfo table on steroids
Yes, definitely that would be cool. This would be equivalent to a defining a view in an RDBMS. Michaël Michaud wrote: > Sounds good, > > And what about having a way to join a spatial layer in OJ to a > non-spatial db table or view, and to see the whole result as one flat > layer in OJ... > > my two cents > > Michaël > > P.Rizzi Ag.Mobilità Ambiente a écrit : > > >> Support for non-spatial DB tables would be a _great_ thing!!! >> You can do lots of thing with them (use attributes to theming other layers), >> or you can even create geometries on the fly using some of their attributes >> plus some BeanShell code, for example. >> Or they can be used to edit geometric layers (maybe they're ENUMs tables >> needed to decode things, ZIP for example). >> >> Bye >> Paolo Rizzi >> >> >> >> >> >>> -Messaggio originale- >>> Da: [EMAIL PROTECTED] >>> [mailto:[EMAIL PROTECTED] conto di >>> Martin Davis >>> Inviato: sabato 2 giugno 2007 0.36 >>> A: List for discussion of JPP development and use. >>> Oggetto: Re: [JPP-Devel] FeatureInfo table on steroids >>> >>> >>> I had similar thoughts a while back. In fact, the Feature concept >>> easily supports non-spatial features. About all that is >>> required is to >>> get the UI to recognize non-spatial Feature Schemas and do sensible >>> things with them (such as display a little table icon rather >>> than the >>> symbology icon in the Layer List panel, and not display the >>> button for >>> View/Edit Geometry). >>> >>> There's quite a few of these kinds of changes required to >>> support this >>> cleanly, but I don't think any of them are very difficult. We'd also >>> need a few non-spatial I/O drivers - CSV, text, maybe DBF. >>> And also a >>> way to set up joins between tables (this one is harder, I >>> think). This >>> is more than just a single plugin, tho - it's a more of a >>> generalization >>> of the existing Feature framework. >>> >>> As for the listener idea, if I understood what Paul was >>> wanting it would >>> be more like supporting adding an item to the existing popup >>> menu on the >>> Feature Info attribute table. >>> >>> Sunburned Surveyor wrote: >>> >>> >>> I'm not sure I totally understand what Paul is talking about, but I had a comment or two and I wanted to throw an idea out there. Paul wrote: " A right click on the feature row to view the whole feature and have a view/edit feature frame that would >>> display the list >>> >>> >>> of property names and values with nested panels for each nested feature." I like this idea. I have also thought about the issue that Paul highlighted in his example of the building address. For example, I might want to store information about the most recently recorded deed for a parcel. The problem with this is that there might be multiple items I'd like to know about the deed. (Date of Purchase, Date Recorded, Recording Number...) I had thought about solving this problem with a plug-in that would allows us to store "non-spatial" features. We could use something similar to the exixting Feature interface. The main difference would be that a non-spatial feature would not have a geometry associated with it. I think we could even display the non-spatial >>> features using >>> >>> >>> the same attribute table that we currently use for spatial features, with some changes. (You could think of a non-spatial feature collection as a table in a typical RDBMS.) This might be a simple alternative to embedding a database. I've always thought using an embedded database added an >>> additional layer of >>> >>> >>> complexity to OpenJUMP. I suppose as we consider more and >>> more advance >>> >>> >>> functionality for attribute information an embedded database option becomes more attractive. Still, it is something to consider >>> carefully. >>> >>> >>> One of the things that makes OpenJUMP so beautiful is its >>> simplicity. >>> >>> >>> :] I also wonder if we could accomodate some custom attribute table behavior by creating a "listener" system similar to what >>> was done with >>> >>> >>> the CursorTools. Plug-In developers would be able to add >>> listeners to >>> >>> >>> each attribute table. When a mouse interaction was detected we could forward an event to the registered listeners that contained a reference to the feature and attribute over which the mouse pointer was located when the event occured. In this type of system Paul could creat
Re: [JPP-Devel] writing help for Openjump
Hi Giuseppe, There is some JUMP's technical and user documentation on the original JUMP's site (a bit old but very nice), and a more recent tutorial for OpenJUMP you can download from http://sourceforge.net/project/showfiles.php?group_id=118054 This OpenJUMP tutorial has been translated from german to english and to french In my opinion, what are missing now are - online help - a manual for advanced features (ex. features from the Tool menu) Any help is welcome (Sunburned Surveyor already did some work for advanced feature documentation) Michaël Giuseppe Aruta a écrit : >Hi >I am new to this list so welcome to everybody > I am writing a sort of "Help" in English for >OpenJUMP. I am still at the beginning and it will take >a good month. >Since I need some ideas and advices I am sending the >part I wrote. Good advices for English are very >welcome. >I want to know if there is a similar project, >developed by some OpenJUMP user. > >Thanks > >Giuseppe > > > ___ >L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: >http://it.docs.yahoo.com/nowyoucan.html > > > >- >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] FeatureInfo table on steroids
Martin, You wrote: "Your suggestions for enhancing the FeatureInfoTable view all sound good to me, Paul. It's a nice idea to have different Geometry text renderers. I might even go further and define a simple framework for GeometryTextRenders, which could have different instantiations added in the Registry. The FeatureInfoTable view could display choices for all loaded renderers." Are you and Paul just talking about a way to allow custom rendering of a selected feature's attributes in the FeatureInfo tool? (For example, if the attribute was the full path to an image, the image could be rendered instead of the actual text value contained in the attribute.) Or are you guys talking about something else entirely? The Sunburned Surveyor On 6/4/07, Paul Austin <[EMAIL PROTECTED]> wrote: > Hi Martin, > > I'm just working on a concept of a HtmlRenderer that will take an object and > convert it to HTML for display in Swing HTML widgets. There will then be a > HtmlRendererRegistry that will map from a Java Class to a renderer. When > displayign features you would use the registry to get a renderer for an > object and use this to generate the HTML. > > We could then extend this concept for things like geometry where the user > can via the UI choose between a choice of renderers for that class (e.g. > WKT, GML), those plug-ins would switch on the fly the renderer in the > registry. > > The registry should also support the property change listener so that UI's > can refresh themselves if the registry changes. > > Paul > > > Martin Davis wrote: > Your suggestions for enhancing the FeatureInfoTable view all sound good to > me, Paul. It's a nice idea to have different Geometry text renderers. I > might even go further and define a simple framework for > GeometryTextRenders, which could have different instantiations added in > the Registry. The FeatureInfoTable view could display choices for all > loaded renderers. As for the compound Feature idea, this seems to depend > on having Readers which can actually create these things. It sounds like > you have defined a custom reader for your need. I would be reluctant to > build very much functionality for compound Features into the core until > there is a clearer idea about the general use cases for them, and what > would be required to make them usable throughout JUMP. For now hopefully > adding some hooks to extend the FeatureInfoTable view will meet your > need. BTW, the idea of having hum-readable names for FeatureSchemas is a > nice one. I'd definitely support adding that functionality, even if it > isn't exposed right now. More generally, this is all moving in the > direction of supporting a full GML-like data model, where Features can > contain FeatureCollections as attributes. I think deegree might have > already extended JUMP to accomodate this - it would be nice to hear from > them how well this worked and what they had to do to make it work. I think > there might be some big UI challenges in accomodating a hierarchical > Feature model, but it might be worth building the infrastructure (i.e. > enhancing the feature package), and then gradually enhancing the UI to > expose more and more of it. It should be possible to provide sensible > default UI behaviour wherever necessary. Paul Austin wrote: > All, I have attached a screen shot of my new Feature InfoTable > implementation. As you can see I've added some CSS styling to the table > and where there are "nested" feature types have the feature type name > displayed and a nested table with their attributes. NOTE: The sub feature > type name stuff won't work with regular JUMP features as the FeatureSchema > does not include the feature type name. I'm using my own Feature > implementation based on the model used in my reader framework. It would be > simple to add this to FeatureSchema if required. After looking at the > current implementation I would like to suggest a change to the way the who > feature info table view works. 1. Under the view menu have sub menu to > allow the user to select the style for viewing geometry (WKT, EWKT, CL, > GML) in addition to the current approach and save that so the user always > get their preference. 2. Implement a FeatureInfoTable renderer which > defines the style for the info view (e.g. HTML table, v.s. GML v.s. Tab/CSV > format 3. Roll the FID and geometry attribute into the table > FeatureInfoTable renderer so that the geometry render is just used when > geometry values are detected to display the value portion. So for example > there would be a position row in the table that would have the geometry > formatted as WKT or GML 4. Where multiple records are displayed use a > database style paging display where one feature is displayed at a time but > you have back/forward, first/last and jump to record number. Think > MSAccess or FME style paging through selected features. Any > comments/suggestions? Paul Martin Davis wrote: > Is your use case only fo
Re: [JPP-Devel] FeatureInfo table on steroids
Hi Paul, Your feature info frame looks nice. The discussion you have with Martin is very interesting and very important as it is about JUMP's feature model. I just want to mention other discussions we had on this list about the interest to write bridges between JUMP's feature model and GeoTool's one or to make JUMP's feature model closer to GeoTool's one. I think the last feature model of GeoTools or the one they are talking about for next version include such things as nested attributes where attributes may be features or feature collections. Michaël Paul Austin a écrit : > All, > > I have attached a screen shot of my new Feature InfoTable > implementation. As you can see I've added some CSS styling to the > table and where there are "nested" feature types have the feature type > name displayed and a nested table with their attributes. > > NOTE: The sub feature type name stuff won't work with regular JUMP > features as the FeatureSchema does not include the feature type name. > I'm using my own Feature implementation based on the model used in my > reader framework. It would be simple to add this to FeatureSchema if > required. > > After looking at the current implementation I would like to suggest a > change to the way the who feature info table view works. > >1. Under the view menu have sub menu to allow the user to select > the style for viewing geometry (WKT, EWKT, CL, GML) in addition > to the current approach and save that so the user always get > their preference. >2. Implement a FeatureInfoTable renderer which defines the style > for the info view (e.g. HTML table, v.s. GML v.s. Tab/CSV format >3. Roll the FID and geometry attribute into the table > FeatureInfoTable renderer so that the geometry render is just > used when geometry values are detected to display the value > portion. So for example there would be a position row in the > table that would have the geometry formatted as WKT or GML >4. Where multiple records are displayed use a database style paging > display where one feature is displayed at a time but you have > back/forward, first/last and jump to record number. Think > MSAccess or FME style paging through selected features. > > Any comments/suggestions? > > Paul > > Martin Davis wrote: > >>Is your use case only for a property which contains a single Feature? >>The general case would be to have a property which contains a >>FeatureCollection (this is the full GML model, for instance). In this >>case the UI gets a bit more complicated. >> >>How are you creating the Feature property? Do you need to spatially >>visualize it? >> >>I'm asking these questions because while your use case may simply be to >>view a single Feature property, it's nice to look a bit further down the >>road at a more general design, in order to avoid making the >>implementation overly specific and hard to extend. >> >>In general supporting a hierarchical feature model introduces tons of >>issues all through JUMP... which is why we didn't go there at first. >>The closest we got was to support a custom object hierarchy and expose >>different classes of it as separate FeatureCollections. This allowed >>treating the various classes as map layers, which worked pretty well. >>But this was all custom code and hard to make general-purpose. >> >>As for the code-value entry plugin, the general concept would clearly be >>nice to have. Would your entry screen only support that single >>attribute, or would you make a general entry panel which showed all >>attributes? This was talked about a week or two ago - it would be nice >>to have this as another view in the Attribute View window. How would >>you supply the code-value mapping? >> >>Paul Austin wrote: >> >> >>>I have a data set where a property of a feature is another feature >>>object. In the schema it has the type Object but it's actually a >>>Feature instance.What I would like to do is have the following. >>> >>> 1. A right click on the feature row to view the whole feature and >>> have a view/edit feature frame that would display the list of >>> property names and values with nested panels for each nested >>> feature. >>> 2. Use the feature display panel to display the feature on say roll >>> over of a complex property value >>> >>>Has anyone worked on such a feature? If not I'll start writing one. >>> >>>Also I was thinking that in databases you have the concept of code >>>lookup tables, I was thinking of a plugi-in that you can configure to >>>display the code value instead of the code ID and have a drop down for >>>changing the values instead of entering the codes. >>> >>>Paul >>> >>> >>>- >>>This SF.net email is sponsored by DB2 Express >>>Download DB2 Express C - the F
Re: [JPP-Devel] Unstable branch of the OpenJUMP CVS...
Stephan, You wrote: "I am more than happy to watch the process of getting a development trunk in OpenJUMP development." That is awesome. I don't think that anyone is going to argue with your volunterring. :] You wrote: "The so called trunk is the (current) CVS HEAD which gets branched into release-branches which can be kept separately." I think I am trying to describe the same thing, but not as well.I may have incorrectly referred to a "stable branch" and an "unstable branch" when what we really want is a stable code in the trunk or CVS HEAD and a branch for the unstable code. The Sunburned Surveyor P.S. - Are you a registered developer on SourceForge? You will need to be registered before we will be able to give you admin rights to the CVS repository at the JPP. On 6/4/07, Stephan Holl <[EMAIL PROTECTED]> wrote: > Hello Sunburned, > > I am more than happy to watch the process of getting a development > trunk in OpenJUMP development. As I am no dev (and therefor not able > to voite) but a power-user I would second Saschas proposal of CVS > structure: > > > > > > > > 1 monthn-month (n+1)-month > > > > --\ devel-\...---\--\-\--> > > > >\ \ \ \ \ > > > > release 1.2 ---\ \ \ > > > > \ \ \ > > > > release 1.3> > > The so called trunk is the (current) CVS HEAD which gets branched into > release-branches which can be kept separately. I am involved in several > OS software development where this structure is quite common. > > To introduce this now would lead into adding a branch (release_1.2) of > the current HEAD. Perhaps it is not so difficult to set up nightly > builds from both HEAD and release-branch? > > Just my 0.02 ¢ > >Stephan > > > "Sunburned Surveyor" <[EMAIL PROTECTED]>, > [20070604-10:34:27]: > > > I took some time to read over the chapter in the CVS manual on > > branching and merging. I have some comments now on the method I think > > we should use for the development branch in the OpenJUMP CVS. > > > > I believe that we should use the method described in Michael's option > > #3 in this thread. This is basically two branches in the CVS, one > > stable and one unstable. Developers can work on and test changes and > > new features in the development branch. When changes or new features > > have been completed in the unstable branch they can be merged into the > > stable branch, as long as they don't break the nightly build. (The > > nightly build will continue to be built from the stable branch.) > > > > Sascha wrote: "I would vote for short merging intervals (1 month or > > so). Such a merge brings the current release to a new second digit > > after the stable version number (1.2 -> 1.2.1). If we think > > its time for new major release we can increment the first > > after dot (1.2 -> 1.3). Having the devel and the stable > > branch coupled so tightly helps us to fix urgent bugs in time > > and develop new features." > > > > I don't know how well this will work for our group of developers. I > > may be mistaken, but under this type of system I believe all changes > > or new features in the unstable branch would have to be working in a > > month of less after they are commited, because they will be going into > > the stable branch at 1 month intervals. I can forsee a situation under > > this sytem where we are always holding back a merge of the stable and > > unstable branches because one or more developers (probably me) doesn't > > have his stuff "working" and ready to commit. Then the other > > developers are upset because they have to wait for their changes to > > get into the stable brach via the merge. > > > > I would suggest this system as a possible alternative: > > > > Each developer and/or development team would be responsible for moving > > its changes and new features from the unstable branch to the stable > > branch. (I believe we could accomplish this by using some good file > > structure organization.) If the different developers can coordinate a > > "universal merge" from the unstable branch to the stable branch that's > > great, but under this system it wouldn't be forced. > > > > Every six months we will shoot for a new release of the stable branch. > > At this point w
Re: [JPP-Devel] R: FeatureInfo table on steroids
Sounds good, And what about having a way to join a spatial layer in OJ to a non-spatial db table or view, and to see the whole result as one flat layer in OJ... my two cents Michaël P.Rizzi Ag.Mobilità Ambiente a écrit : >Support for non-spatial DB tables would be a _great_ thing!!! >You can do lots of thing with them (use attributes to theming other layers), >or you can even create geometries on the fly using some of their attributes >plus some BeanShell code, for example. >Or they can be used to edit geometric layers (maybe they're ENUMs tables >needed to decode things, ZIP for example). > >Bye >Paolo Rizzi > > > > >>-Messaggio originale- >>Da: [EMAIL PROTECTED] >>[mailto:[EMAIL PROTECTED] conto di >>Martin Davis >>Inviato: sabato 2 giugno 2007 0.36 >>A: List for discussion of JPP development and use. >>Oggetto: Re: [JPP-Devel] FeatureInfo table on steroids >> >> >>I had similar thoughts a while back. In fact, the Feature concept >>easily supports non-spatial features. About all that is >>required is to >>get the UI to recognize non-spatial Feature Schemas and do sensible >>things with them (such as display a little table icon rather >>than the >>symbology icon in the Layer List panel, and not display the >>button for >>View/Edit Geometry). >> >>There's quite a few of these kinds of changes required to >>support this >>cleanly, but I don't think any of them are very difficult. We'd also >>need a few non-spatial I/O drivers - CSV, text, maybe DBF. >>And also a >>way to set up joins between tables (this one is harder, I >>think). This >>is more than just a single plugin, tho - it's a more of a >>generalization >>of the existing Feature framework. >> >>As for the listener idea, if I understood what Paul was >>wanting it would >>be more like supporting adding an item to the existing popup >>menu on the >>Feature Info attribute table. >> >>Sunburned Surveyor wrote: >> >> >>>I'm not sure I totally understand what Paul is talking about, but I >>>had a comment or two and I wanted to throw an idea out there. >>> >>>Paul wrote: " A right click on the feature row to view the whole >>>feature and have a view/edit feature frame that would >>> >>> >>display the list >> >> >>>of property names and values with nested panels for each nested >>>feature." >>> >>>I like this idea. >>> >>>I have also thought about the issue that Paul highlighted in his >>>example of the building address. For example, I might want to store >>>information about the most recently recorded deed for a parcel. The >>>problem with this is that there might be multiple items I'd like to >>>know about the deed. (Date of Purchase, Date Recorded, Recording >>>Number...) >>> >>>I had thought about solving this problem with a plug-in that would >>>allows us to store "non-spatial" features. We could use something >>>similar to the exixting Feature interface. The main difference would >>>be that a non-spatial feature would not have a geometry associated >>>with it. I think we could even display the non-spatial >>> >>> >>features using >> >> >>>the same attribute table that we currently use for spatial features, >>>with some changes. (You could think of a non-spatial feature >>>collection as a table in a typical RDBMS.) >>> >>>This might be a simple alternative to embedding a database. I've >>>always thought using an embedded database added an >>> >>> >>additional layer of >> >> >>>complexity to OpenJUMP. I suppose as we consider more and >>> >>> >>more advance >> >> >>>functionality for attribute information an embedded database option >>>becomes more attractive. Still, it is something to consider >>> >>> >>carefully. >> >> >>>One of the things that makes OpenJUMP so beautiful is its >>> >>> >>simplicity. >> >> >>>:] >>> >>>I also wonder if we could accomodate some custom attribute table >>>behavior by creating a "listener" system similar to what >>> >>> >>was done with >> >> >>>the CursorTools. Plug-In developers would be able to add >>> >>> >>listeners to >> >> >>>each attribute table. When a mouse interaction was detected we could >>>forward an event to the registered listeners that contained a >>>reference to the feature and attribute over which the mouse pointer >>>was located when the event occured. >>> >>>In this type of system Paul could create a listener and attach it to >>>the attribute table with the address field. In this address field he >>>would store a primary key. When the user held the mouse pointer over >>>this address field an event would be sent to the listener with a >>>reference to the feature and the primary key stored in the address >>>field. He could then display a GUI with all of the information from >>>the address that he retrieves using the primary key stored in the >>>event. >>> >>>Perhaps this is what Paul was talking about and I didn't >>> >>> >>understand completely. >> >> >>>The
Re: [JPP-Devel] FeatureInfo table on steroids
Hi Martin, I'm just working on a concept of a HtmlRenderer that will take an object and convert it to HTML for display in Swing HTML widgets. There will then be a HtmlRendererRegistry that will map from a Java Class to a renderer. When displayign features you would use the registry to get a renderer for an object and use this to generate the HTML. We could then extend this concept for things like geometry where the user can via the UI choose between a choice of renderers for that class (e.g. WKT, GML), those plug-ins would switch on the fly the renderer in the registry. The registry should also support the property change listener so that UI's can refresh themselves if the registry changes. Paul Martin Davis wrote: Your suggestions for enhancing the FeatureInfoTable view all sound good to me, Paul. It's a nice idea to have different Geometry text renderers. I might even go further and define a simple framework for GeometryTextRenders, which could have different instantiations added in the Registry. The FeatureInfoTable view could display choices for all loaded renderers. As for the compound Feature idea, this seems to depend on having Readers which can actually create these things. It sounds like you have defined a custom reader for your need. I would be reluctant to build very much functionality for compound Features into the core until there is a clearer idea about the general use cases for them, and what would be required to make them usable throughout JUMP. For now hopefully adding some hooks to extend the FeatureInfoTable view will meet your need. BTW, the idea of having hum-readable names for FeatureSchemas is a nice one. I'd definitely support adding that functionality, even if it isn't exposed right now. More generally, this is all moving in the direction of supporting a full GML-like data model, where Features can contain FeatureCollections as attributes. I think deegree might have already extended JUMP to accomodate this - it would be nice to hear from them how well this worked and what they had to do to make it work. I think there might be some big UI challenges in accomodating a hierarchical Feature model, but it might be worth building the infrastructure (i.e. enhancing the feature package), and then gradually enhancing the UI to expose more and more of it. It should be possible to provide sensible default UI behaviour wherever necessary. Paul Austin wrote: All, I have attached a screen shot of my new Feature InfoTable implementation. As you can see I've added some CSS styling to the table and where there are "nested" feature types have the feature type name displayed and a nested table with their attributes. NOTE: The sub feature type name stuff won't work with regular JUMP features as the FeatureSchema does not include the feature type name. I'm using my own Feature implementation based on the model used in my reader framework. It would be simple to add this to FeatureSchema if required. After looking at the current implementation I would like to suggest a change to the way the who feature info table view works. 1. Under the view menu have sub menu to allow the user to select the style for viewing geometry (WKT, EWKT, CL, GML) in addition to the current approach and save that so the user always get their preference. 2. Implement a FeatureInfoTable renderer which defines the style for the info view (e.g. HTML table, v.s. GML v.s. Tab/CSV format 3. Roll the FID and geometry attribute into the table FeatureInfoTable renderer so that the geometry render is just used when geometry values are detected to display the value portion. So for example there would be a position row in the table that would have the geometry formatted as WKT or GML 4. Where multiple records are displayed use a database style paging display where one feature is displayed at a time but you have back/forward, first/last and jump to record number. Think MSAccess or FME style paging through selected features. Any comments/suggestions? Paul Martin Davis wrote: Is your use case only for a property which contains a single Feature? The general case would be to have a property which contains a FeatureCollection (this is the full GML model, for instance). In this case the UI gets a bit more complicated. How are you creating the Feature property? Do you need to spatially visualize it? I'm asking these questions because while your use case may simply be to view a single Feature property, it's nice to look a bit further down the road at a more general design, in order to avoid making the implementation overly specific and hard to extend. In general supporting a hierarchical feature model introduces tons of issues all through JUMP... which is why we didn't go there at first. The closest we got was to support a custom object hierarchy and expose different c
Re: [JPP-Devel] R: FeatureInfo table on steroids
All good points, Paolo. P.Rizzi Ag.Mobilità Ambiente wrote: > Support for non-spatial DB tables would be a _great_ thing!!! > You can do lots of thing with them (use attributes to theming other layers), > or you can even create geometries on the fly using some of their attributes > plus some BeanShell code, for example. > Or they can be used to edit geometric layers (maybe they're ENUMs tables > needed to decode things, ZIP for example). > > Bye > Paolo Rizzi > > > >> -Messaggio originale- >> Da: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] conto di >> Martin Davis >> Inviato: sabato 2 giugno 2007 0.36 >> A: List for discussion of JPP development and use. >> Oggetto: Re: [JPP-Devel] FeatureInfo table on steroids >> >> >> I had similar thoughts a while back. In fact, the Feature concept >> easily supports non-spatial features. About all that is >> required is to >> get the UI to recognize non-spatial Feature Schemas and do sensible >> things with them (such as display a little table icon rather >> than the >> symbology icon in the Layer List panel, and not display the >> button for >> View/Edit Geometry). >> >> There's quite a few of these kinds of changes required to >> support this >> cleanly, but I don't think any of them are very difficult. We'd also >> need a few non-spatial I/O drivers - CSV, text, maybe DBF. >> And also a >> way to set up joins between tables (this one is harder, I >> think). This >> is more than just a single plugin, tho - it's a more of a >> generalization >> of the existing Feature framework. >> >> As for the listener idea, if I understood what Paul was >> wanting it would >> be more like supporting adding an item to the existing popup >> menu on the >> Feature Info attribute table. >> >> Sunburned Surveyor wrote: >> >>> I'm not sure I totally understand what Paul is talking about, but I >>> had a comment or two and I wanted to throw an idea out there. >>> >>> Paul wrote: " A right click on the feature row to view the whole >>> feature and have a view/edit feature frame that would >>> >> display the list >> >>> of property names and values with nested panels for each nested >>> feature." >>> >>> I like this idea. >>> >>> I have also thought about the issue that Paul highlighted in his >>> example of the building address. For example, I might want to store >>> information about the most recently recorded deed for a parcel. The >>> problem with this is that there might be multiple items I'd like to >>> know about the deed. (Date of Purchase, Date Recorded, Recording >>> Number...) >>> >>> I had thought about solving this problem with a plug-in that would >>> allows us to store "non-spatial" features. We could use something >>> similar to the exixting Feature interface. The main difference would >>> be that a non-spatial feature would not have a geometry associated >>> with it. I think we could even display the non-spatial >>> >> features using >> >>> the same attribute table that we currently use for spatial features, >>> with some changes. (You could think of a non-spatial feature >>> collection as a table in a typical RDBMS.) >>> >>> This might be a simple alternative to embedding a database. I've >>> always thought using an embedded database added an >>> >> additional layer of >> >>> complexity to OpenJUMP. I suppose as we consider more and >>> >> more advance >> >>> functionality for attribute information an embedded database option >>> becomes more attractive. Still, it is something to consider >>> >> carefully. >> >>> One of the things that makes OpenJUMP so beautiful is its >>> >> simplicity. >> >>> :] >>> >>> I also wonder if we could accomodate some custom attribute table >>> behavior by creating a "listener" system similar to what >>> >> was done with >> >>> the CursorTools. Plug-In developers would be able to add >>> >> listeners to >> >>> each attribute table. When a mouse interaction was detected we could >>> forward an event to the registered listeners that contained a >>> reference to the feature and attribute over which the mouse pointer >>> was located when the event occured. >>> >>> In this type of system Paul could create a listener and attach it to >>> the attribute table with the address field. In this address field he >>> would store a primary key. When the user held the mouse pointer over >>> this address field an event would be sent to the listener with a >>> reference to the feature and the primary key stored in the address >>> field. He could then display a GUI with all of the information from >>> the address that he retrieves using the primary key stored in the >>> event. >>> >>> Perhaps this is what Paul was talking about and I didn't >>> >> understand completely. >> >>> The Sunburned Surveyor >>> >>> >>> >>> >>> On 6/1/07, Paul Austin <[EMAIL PROTECTED]> wrote: >>> >>> Hi Marti
Re: [JPP-Devel] FeatureInfo table on steroids
Agreed, I realize that you have to do some namespace mangling. It all comes down to how much coding you want to do to support your need. Supporting attributes which are lists of values is another story... It may be fine for your use case to simply display these as a String, but it would be nice to have a more general solution, since other JUMP users may have requirements for more functionality. Paul Austin wrote: > Hi Martin, > > I've never been a fan of doing automated flattening of hierarchical > data models as you either have to include a prefix on the attribute > names or some other form of name mangling to avoid name collisions, > also it doesn't cope well if you have parts of it that are optional or > contain lists/sets of values. > > I am using my own reader/feature framework for loading the features > and have defined a concrete implementation of my DataObject interface > which extends from the JUMP Feature class. The properties that contain > nested features are defined in the JUMP FeatureSchema to be of type > Object which JUMP supports and would just treat as a String when > displaying it. > > My Attribute view implementation just does an instanceof on the > attribute value and if it is a Feature renders it as a table using > recursion so you can go as many levels deep as you want. > > I'm thinking for the list style view of using roll overs on values to > do a pop up box with the full attributes (think like when you roll > over images on a HTML page it can display the name of the image in a > small pop up). > > Paul > > Martin Davis wrote: >> Paul, >> >> If this is a question of modelling a single complex attribute which is >> in 1-1 relation with the parent feature, why don't you just present the >> attributes as a set of attributes on the parent feature? Granted this >> increases the column namespace a bit, but it doesn't require any >> additional functionality in the UI and seems like it should provide you >> with effectively the same capability to display the attributes. >> >> If you want to support complex attributes which are in many-to-one >> relationship with a parent Feature set, that's a whole different story, >> and I think would require a lot more than just a change to the Attribute >> View presentation. >> >> By the way, how are you loading these compound Features? >> >> Paul Austin wrote: >> >>> Hi Martin, >>> >>> This case is where you have nested complex properties of an attribute >>> nature. For example building may have an address property that has the >>> attributes unit, number, street, city etc. >>> >>> I don't want to go down the whole nested feature collection route as >>> that can get pretty messy. In fact I would typically model these in >>> the database using either one-to-may or many-to-many foreign key >>> relationships that they really are. >>> >>> For the code table plug-in, this could be done from database layers by >>> following foreign key relationships that when you add the layer you >>> could select which ones are code tables and the columns to use from >>> the referenced tables. Initially I think I'd test out the concept by >>> manually creating the UI and config and see how it goes from there. >>> More of a prototyping approach. >>> >>> Paul >>> >>> Martin Davis wrote: >>> Is your use case only for a property which contains a single Feature? The general case would be to have a property which contains a FeatureCollection (this is the full GML model, for instance). In this case the UI gets a bit more complicated. How are you creating the Feature property? Do you need to spatially visualize it? I'm asking these questions because while your use case may simply be to view a single Feature property, it's nice to look a bit further down the road at a more general design, in order to avoid making the implementation overly specific and hard to extend. In general supporting a hierarchical feature model introduces tons of issues all through JUMP... which is why we didn't go there at first. The closest we got was to support a custom object hierarchy and expose different classes of it as separate FeatureCollections. This allowed treating the various classes as map layers, which worked pretty well. But this was all custom code and hard to make general-purpose. As for the code-value entry plugin, the general concept would clearly be nice to have. Would your entry screen only support that single attribute, or would you make a general entry panel which showed all attributes? This was talked about a week or two ago - it would be nice to have this as another view in the Attribute View window. How would you supply the code-value mapping? Paul Austin wrote: > I have a data set where a property of a feature is another feature > object. In
Re: [JPP-Devel] FeatureInfo table on steroids
Your suggestions for enhancing the FeatureInfoTable view all sound good to me, Paul. It's a nice idea to have different Geometry text renderers. I might even go further and define a simple framework for GeometryTextRenders, which could have different instantiations added in the Registry. The FeatureInfoTable view could display choices for all loaded renderers. As for the compound Feature idea, this seems to depend on having Readers which can actually create these things. It sounds like you have defined a custom reader for your need. I would be reluctant to build very much functionality for compound Features into the core until there is a clearer idea about the general use cases for them, and what would be required to make them usable throughout JUMP. For now hopefully adding some hooks to extend the FeatureInfoTable view will meet your need. BTW, the idea of having hum-readable names for FeatureSchemas is a nice one. I'd definitely support adding that functionality, even if it isn't exposed right now. More generally, this is all moving in the direction of supporting a full GML-like data model, where Features can contain FeatureCollections as attributes. I think deegree might have already extended JUMP to accomodate this - it would be nice to hear from them how well this worked and what they had to do to make it work. I think there might be some big UI challenges in accomodating a hierarchical Feature model, but it might be worth building the infrastructure (i.e. enhancing the feature package), and then gradually enhancing the UI to expose more and more of it. It should be possible to provide sensible default UI behaviour wherever necessary. Paul Austin wrote: > All, > > I have attached a screen shot of my new Feature InfoTable > implementation. As you can see I've added some CSS styling to the > table and where there are "nested" feature types have the feature type > name displayed and a nested table with their attributes. > > NOTE: The sub feature type name stuff won't work with regular JUMP > features as the FeatureSchema does not include the feature type name. > I'm using my own Feature implementation based on the model used in my > reader framework. It would be simple to add this to FeatureSchema if > required. > > After looking at the current implementation I would like to suggest a > change to the way the who feature info table view works. > >1. Under the view menu have sub menu to allow the user to select > the style for viewing geometry (WKT, EWKT, CL, GML) in addition > to the current approach and save that so the user always get > their preference. >2. Implement a FeatureInfoTable renderer which defines the style > for the info view (e.g. HTML table, v.s. GML v.s. Tab/CSV format >3. Roll the FID and geometry attribute into the table > FeatureInfoTable renderer so that the geometry render is just > used when geometry values are detected to display the value > portion. So for example there would be a position row in the > table that would have the geometry formatted as WKT or GML >4. Where multiple records are displayed use a database style paging > display where one feature is displayed at a time but you have > back/forward, first/last and jump to record number. Think > MSAccess or FME style paging through selected features. > > Any comments/suggestions? > > Paul > > Martin Davis wrote: >> Is your use case only for a property which contains a single Feature? >> The general case would be to have a property which contains a >> FeatureCollection (this is the full GML model, for instance). In this >> case the UI gets a bit more complicated. >> >> How are you creating the Feature property? Do you need to spatially >> visualize it? >> >> I'm asking these questions because while your use case may simply be to >> view a single Feature property, it's nice to look a bit further down the >> road at a more general design, in order to avoid making the >> implementation overly specific and hard to extend. >> >> In general supporting a hierarchical feature model introduces tons of >> issues all through JUMP... which is why we didn't go there at first. >> The closest we got was to support a custom object hierarchy and expose >> different classes of it as separate FeatureCollections. This allowed >> treating the various classes as map layers, which worked pretty well. >> But this was all custom code and hard to make general-purpose. >> >> As for the code-value entry plugin, the general concept would clearly be >> nice to have. Would your entry screen only support that single >> attribute, or would you make a general entry panel which showed all >> attributes? This was talked about a week or two ago - it would be nice >> to have this as another view in the Attribute View window. How would >> you supply the code-value mapping? >> >> Paul Austin wrote: >> >>> I ha
Re: [JPP-Devel] Unstable branch of the OpenJUMP CVS...
Hello Sunburned,
I am more than happy to watch the process of getting a development
trunk in OpenJUMP development. As I am no dev (and therefor not able
to voite) but a power-user I would second Saschas proposal of CVS
structure:
> > >
> > > 1 monthn-month (n+1)-month
> > > --\ devel-\...---\--\-\-->
> > >\ \ \ \ \
> > > release 1.2 ---\ \ \
> > > \ \ \
> > > release 1.3>
The so called trunk is the (current) CVS HEAD which gets branched into
release-branches which can be kept separately. I am involved in several
OS software development where this structure is quite common.
To introduce this now would lead into adding a branch (release_1.2) of
the current HEAD. Perhaps it is not so difficult to set up nightly
builds from both HEAD and release-branch?
Just my 0.02 ¢
Stephan
"Sunburned Surveyor" <[EMAIL PROTECTED]>,
[20070604-10:34:27]:
> I took some time to read over the chapter in the CVS manual on
> branching and merging. I have some comments now on the method I think
> we should use for the development branch in the OpenJUMP CVS.
>
> I believe that we should use the method described in Michael's option
> #3 in this thread. This is basically two branches in the CVS, one
> stable and one unstable. Developers can work on and test changes and
> new features in the development branch. When changes or new features
> have been completed in the unstable branch they can be merged into the
> stable branch, as long as they don't break the nightly build. (The
> nightly build will continue to be built from the stable branch.)
>
> Sascha wrote: "I would vote for short merging intervals (1 month or
> so). Such a merge brings the current release to a new second digit
> after the stable version number (1.2 -> 1.2.1). If we think
> its time for new major release we can increment the first
> after dot (1.2 -> 1.3). Having the devel and the stable
> branch coupled so tightly helps us to fix urgent bugs in time
> and develop new features."
>
> I don't know how well this will work for our group of developers. I
> may be mistaken, but under this type of system I believe all changes
> or new features in the unstable branch would have to be working in a
> month of less after they are commited, because they will be going into
> the stable branch at 1 month intervals. I can forsee a situation under
> this sytem where we are always holding back a merge of the stable and
> unstable branches because one or more developers (probably me) doesn't
> have his stuff "working" and ready to commit. Then the other
> developers are upset because they have to wait for their changes to
> get into the stable brach via the merge.
>
> I would suggest this system as a possible alternative:
>
> Each developer and/or development team would be responsible for moving
> its changes and new features from the unstable branch to the stable
> branch. (I believe we could accomplish this by using some good file
> structure organization.) If the different developers can coordinate a
> "universal merge" from the unstable branch to the stable branch that's
> great, but under this system it wouldn't be forced.
>
> Every six months we will shoot for a new release of the stable branch.
> At this point we can update the version number of the unstable branch.
>
> Here is an example:
>
> Let's say the that we create the unstable branch of OpenJUMP today.
> The current revision number of the OpenJUMP CVS is 1.3. Based on what
> I read in the CVS manual I think our unstable branch would receive a
> revision number of 1.3.2. At the end of the year we make a new stable
> release of OpenJUMP and update the revision number of OpenJUMP to 1.4.
> At this point we would also update the revision number of the unstable
> branch to 1.4.2.
>
> Under this system there would be 3 versions of OpenJUMP available at
> any one point in time:
>
> [1] The latest stable release. (An annual or biannual snapshot of the
> stable branch of the OpenJUMP CVS.)
> [2] The nightly build of the stable branch in the OpenJUMP CVS.
> [3] The development builds created by different development teams from
> the unstable branch of the OpenJUMP CVS.
>
> I'd say a month before a planned stable release we would freeze all
> merging of changes and new features from the unstable branch into the
> stable branch.
>
> Let me know what you guys think of the basic sys
Re: [JPP-Devel] Unstable branch of the OpenJUMP CVS...
I took some time to read over the chapter in the CVS manual on branching and merging. I have some comments now on the method I think we should use for the development branch in the OpenJUMP CVS. I believe that we should use the method described in Michael's option #3 in this thread. This is basically two branches in the CVS, one stable and one unstable. Developers can work on and test changes and new features in the development branch. When changes or new features have been completed in the unstable branch they can be merged into the stable branch, as long as they don't break the nightly build. (The nightly build will continue to be built from the stable branch.) Sascha wrote: "I would vote for short merging intervals (1 month or so). Such a merge brings the current release to a new second digit after the stable version number (1.2 -> 1.2.1). If we think its time for new major release we can increment the first after dot (1.2 -> 1.3). Having the devel and the stable branch coupled so tightly helps us to fix urgent bugs in time and develop new features." I don't know how well this will work for our group of developers. I may be mistaken, but under this type of system I believe all changes or new features in the unstable branch would have to be working in a month of less after they are commited, because they will be going into the stable branch at 1 month intervals. I can forsee a situation under this sytem where we are always holding back a merge of the stable and unstable branches because one or more developers (probably me) doesn't have his stuff "working" and ready to commit. Then the other developers are upset because they have to wait for their changes to get into the stable brach via the merge. I would suggest this system as a possible alternative: Each developer and/or development team would be responsible for moving its changes and new features from the unstable branch to the stable branch. (I believe we could accomplish this by using some good file structure organization.) If the different developers can coordinate a "universal merge" from the unstable branch to the stable branch that's great, but under this system it wouldn't be forced. Every six months we will shoot for a new release of the stable branch. At this point we can update the version number of the unstable branch. Here is an example: Let's say the that we create the unstable branch of OpenJUMP today. The current revision number of the OpenJUMP CVS is 1.3. Based on what I read in the CVS manual I think our unstable branch would receive a revision number of 1.3.2. At the end of the year we make a new stable release of OpenJUMP and update the revision number of OpenJUMP to 1.4. At this point we would also update the revision number of the unstable branch to 1.4.2. Under this system there would be 3 versions of OpenJUMP available at any one point in time: [1] The latest stable release. (An annual or biannual snapshot of the stable branch of the OpenJUMP CVS.) [2] The nightly build of the stable branch in the OpenJUMP CVS. [3] The development builds created by different development teams from the unstable branch of the OpenJUMP CVS. I'd say a month before a planned stable release we would freeze all merging of changes and new features from the unstable branch into the stable branch. Let me know what you guys think of the basic system that I have outline. If there are no major objections I can work on making the needed changes to the CVS this week. The Sunburned Surveyor On 6/3/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote: > Thanks for all of the suggestions about how we can manage a > development branch in the OpenJUMP CVS. I have downloaded the CVS > manual and the CVS book this morning. Please give me a few days to > read about branching and merging and then I will try to add something > intelligent to this conversation. > > Hopefully we can then make a decision about how to implement a > development branch, while preserving our nightly build. > > The Sunburned Surveyor > > On 6/3/07, Sascha L. Teichmann <[EMAIL PROTECTED]> wrote: > > I would prefer the following: > > > > 1 monthn-month (n+1)-month > > --\ devel-\...---\--\-\--> > >\ \ \ \ \ > > release 1.2 ---\ \ \ > > \ \ \ > > release 1.3> > > > > Have one current stable and one devel branch. No support > > for older versions. You can do this if you have enough man > > power. Which we don't have at the moment. > > I would vote for short merging intervals (1 month or so). > > Such a merge brings the current release to a new second digit > > after the stable version number (1.2 -> 1.2.1). If we think > > its time for new major release we can increment the first > > after dot (1.2 -> 1.3). Having the devel an
Re: [JPP-Devel] R: Multiple Layers from the same database connection
Stefan, Ignore my comment about SkyJump plugin's I was just using an older version of JUMP, now with the 1.2 pre release I see they are already there. Cheers, Paul Stefan Steiniger wrote: I did a one-to-one copy if i remember correctly (since i have no experiences with databases i would not touch it). But some improvements may have been added for bugfixing in between. anyway a question to Paul Austin: which plugins from Skyjump did you mean that should go into OpenJUMP? stefan Martin Davis schrieb: We made the Datastore API cache connections and reuse them if a user requested a connection with the same connection params. So when you load layers from a project file they will reuse already-open connections whereever they can. At least, this is how it's *supposed* to work... it's been a while since I wrote that code, and I don't know if anything changed during the port to OJ. Can someone report on this? P.Rizzi Ag.Mobilità Ambiente wrote: I can't completely understand what you're saying... Using the Datastore API you can open several layers from a single connection... You can try my PostGIS/Oracle plugin from: http://sourceforge.net/project/showfiles.php?group_id=118054&package_id=217237 But you pointed out something I never realized before, that inside a project/task file each layer has it's connection parameter repeated, does it mean that when a project/task is opened the Datastore API opens a separate connection for each layer??? I don't know that... But the connection dialog lists each connection only once, so there may be some smart code that "put together" identical connection opening them only once. I'll have to find the time to debug this... Anyway something able to "group" layers would be a great thing, so you can operate on a "group" (or may we call it a theme???) as a whole (hide/show, refresh, etc.). While I'm at it, even if it's not strictly related to this post, it would be great to be able to save inside a project/task file also a layer coming from Datastore query, otherwise you to manually recreate and restyle it every time you run OJ anew. Bye Paolo Rizzi -Messaggio originale- Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] conto di Paul Austin Inviato: martedì 29 maggio 2007 22.16 A: jump-pilot-devel@lists.sourceforge.net Oggetto: [JPP-Devel] Multiple Layers from the same database connection All, I've been looking at the existing database and file plugins and the com.vividsolutions.jump.io.datasource.DataSource class and from what I can tell there is a one to one relationship between a layer and a data source. What I would like to do for some of the file and database based data sources is to have the concept of a DataSource that can contain many different layers. Within a project you would be able to select which layers you wanted to view from that data source. In the database world this concept would relate to having a connection to the data base using a java.sql.Connection. When adding the database connection to a project there would be a UI that would list the available layers (database tables) and the user could select which layers they wish to view. This compares to the current PostGIS plug-in where you have to manually enter the connection and table details for each layer. When the project is closed then the "connection" must also be closed. In the Jump project file the "connection" parameters would be stored once, then the data sources used for each layer would reference the "connection" and have a different query for each table. Now if we look at a file based example, I have a file format which is basically a zip file that contains one file for each layer along with some metadata files. I would like to be able to open the zip file and create a layer for each of the layers in the zip file. To do this I would extract the file to the temp directory and as required load the data from the individual files in the temp directory. Then when you close the project the "connection" is closed by deleting the temporary files. Another file based example would be to open a directory of files, loading each layer file in that directory, this is basically the same as the zip file idea but without the temporary files. In both the file cases once the file is loaded the first time the user can select which of the layers to view. So the question is, does any of the existing functionality in JUMP allow for multi-layer data sources? If not I'm going to do some prototyping for the file format I have and then share this with the group for comment to see if it would be useful elsewhere. After that I have an interest in Oracle connections so would need to do the same kind of thing there. One other question, where would I find the code for writing out the project .jmp XML files as I'd need to add the "connection" definitions to this. Cheers, Paul -- --- This SF
Re: [JPP-Devel] FeatureInfo table on steroids
Paul, If this is a question of modelling a single complex attribute which is in 1-1 relation with the parent feature, why don't you just present the attributes as a set of attributes on the parent feature? Granted this increases the column namespace a bit, but it doesn't require any additional functionality in the UI and seems like it should provide you with effectively the same capability to display the attributes. If you want to support complex attributes which are in many-to-one relationship with a parent Feature set, that's a whole different story, and I think would require a lot more than just a change to the Attribute View presentation. By the way, how are you loading these compound Features? Paul Austin wrote: > Hi Martin, > > This case is where you have nested complex properties of an attribute > nature. For example building may have an address property that has the > attributes unit, number, street, city etc. > > I don't want to go down the whole nested feature collection route as > that can get pretty messy. In fact I would typically model these in > the database using either one-to-may or many-to-many foreign key > relationships that they really are. > > For the code table plug-in, this could be done from database layers by > following foreign key relationships that when you add the layer you > could select which ones are code tables and the columns to use from > the referenced tables. Initially I think I'd test out the concept by > manually creating the UI and config and see how it goes from there. > More of a prototyping approach. > > Paul > > Martin Davis wrote: >> Is your use case only for a property which contains a single Feature? >> The general case would be to have a property which contains a >> FeatureCollection (this is the full GML model, for instance). In this >> case the UI gets a bit more complicated. >> >> How are you creating the Feature property? Do you need to spatially >> visualize it? >> >> I'm asking these questions because while your use case may simply be to >> view a single Feature property, it's nice to look a bit further down the >> road at a more general design, in order to avoid making the >> implementation overly specific and hard to extend. >> >> In general supporting a hierarchical feature model introduces tons of >> issues all through JUMP... which is why we didn't go there at first. >> The closest we got was to support a custom object hierarchy and expose >> different classes of it as separate FeatureCollections. This allowed >> treating the various classes as map layers, which worked pretty well. >> But this was all custom code and hard to make general-purpose. >> >> As for the code-value entry plugin, the general concept would clearly be >> nice to have. Would your entry screen only support that single >> attribute, or would you make a general entry panel which showed all >> attributes? This was talked about a week or two ago - it would be nice >> to have this as another view in the Attribute View window. How would >> you supply the code-value mapping? >> >> Paul Austin wrote: >> >>> I have a data set where a property of a feature is another feature >>> object. In the schema it has the type Object but it's actually a >>> Feature instance.What I would like to do is have the following. >>> >>>1. A right click on the feature row to view the whole feature and >>> have a view/edit feature frame that would display the list of >>> property names and values with nested panels for each nested >>> feature. >>>2. Use the feature display panel to display the feature on say roll >>> over of a complex property value >>> >>> Has anyone worked on such a feature? If not I'll start writing one. >>> >>> Also I was thinking that in databases you have the concept of code >>> lookup tables, I was thinking of a plugi-in that you can configure to >>> display the code value instead of the code ID and have a drop down for >>> changing the values instead of entering the codes. >>> >>> 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 v
Re: [JPP-Devel] FeatureInfo table on steroids
Hi Martin, I've never been a fan of doing automated flattening of hierarchical data models as you either have to include a prefix on the attribute names or some other form of name mangling to avoid name collisions, also it doesn't cope well if you have parts of it that are optional or contain lists/sets of values. I am using my own reader/feature framework for loading the features and have defined a concrete implementation of my DataObject interface which extends from the JUMP Feature class. The properties that contain nested features are defined in the JUMP FeatureSchema to be of type Object which JUMP supports and would just treat as a String when displaying it. My Attribute view implementation just does an instanceof on the attribute value and if it is a Feature renders it as a table using recursion so you can go as many levels deep as you want. I'm thinking for the list style view of using roll overs on values to do a pop up box with the full attributes (think like when you roll over images on a HTML page it can display the name of the image in a small pop up). Paul Martin Davis wrote: Paul, If this is a question of modelling a single complex attribute which is in 1-1 relation with the parent feature, why don't you just present the attributes as a set of attributes on the parent feature? Granted this increases the column namespace a bit, but it doesn't require any additional functionality in the UI and seems like it should provide you with effectively the same capability to display the attributes. If you want to support complex attributes which are in many-to-one relationship with a parent Feature set, that's a whole different story, and I think would require a lot more than just a change to the Attribute View presentation. By the way, how are you loading these compound Features? Paul Austin wrote: Hi Martin, This case is where you have nested complex properties of an attribute nature. For example building may have an address property that has the attributes unit, number, street, city etc. I don't want to go down the whole nested feature collection route as that can get pretty messy. In fact I would typically model these in the database using either one-to-may or many-to-many foreign key relationships that they really are. For the code table plug-in, this could be done from database layers by following foreign key relationships that when you add the layer you could select which ones are code tables and the columns to use from the referenced tables. Initially I think I'd test out the concept by manually creating the UI and config and see how it goes from there. More of a prototyping approach. Paul Martin Davis wrote: Is your use case only for a property which contains a single Feature? The general case would be to have a property which contains a FeatureCollection (this is the full GML model, for instance). In this case the UI gets a bit more complicated. How are you creating the Feature property? Do you need to spatially visualize it? I'm asking these questions because while your use case may simply be to view a single Feature property, it's nice to look a bit further down the road at a more general design, in order to avoid making the implementation overly specific and hard to extend. In general supporting a hierarchical feature model introduces tons of issues all through JUMP... which is why we didn't go there at first. The closest we got was to support a custom object hierarchy and expose different classes of it as separate FeatureCollections. This allowed treating the various classes as map layers, which worked pretty well. But this was all custom code and hard to make general-purpose. As for the code-value entry plugin, the general concept would clearly be nice to have. Would your entry screen only support that single attribute, or would you make a general entry panel which showed all attributes? This was talked about a week or two ago - it would be nice to have this as another view in the Attribute View window. How would you supply the code-value mapping? Paul Austin wrote: I have a data set where a property of a feature is another feature object. In the schema it has the type Object but it's actually a Feature instance.What I would like to do is have the following. 1. A right click on the feature row to view the whole feature and have a view/edit feature frame that would display the list of property names and values with nested panels for each nested feature. 2. Use the feature display panel to display the feature on say roll over of a complex property value Has anyone worked on such a feature? If not I'll start writing one. Also I was thinking that in databases you have the concept of code lookup tables, I was thinking of a plugi-in that you can configure to display the code value instead of the code ID and have a drop down for changing the valu
[JPP-Devel] [ANN]: WFSPlugin 1.0.0 released
Hello OpenJUMP users, the development of a WFSPlugin has started in early april and a first version was given to the community recently. Now with this release we have have fullfilled the roadmap within this project and release the WFSPlugin as 1.0.0. There are lots of bugfixes and some new features included. The plugin is known to work with OJ 1.0.1 and OJ 1.2b as well as with the nightly builds. Download binary here: http://sourceforge.net/project/showfiles.php?group_id=118054&package_id=150819 Installing: 1. Copy the wfsplugin.jar into the lib/ext directory of your OpenJump installation. 2. Install additional libraries needed to run the plugin. Download the following jar files and put them into /lib/ext: http://jump-pilot.cvs.sourceforge.net/*checkout*/jump-pilot/WFSPlugin/lib/commons-codec-1.3.jar http://jump-pilot.cvs.sourceforge.net/*checkout*/jump-pilot/WFSPlugin/lib/commons-logging.jar http://jump-pilot.cvs.sourceforge.net/*checkout*/jump-pilot/WFSPlugin/lib/jaxen-1.1-beta-8.jar http://jump-pilot.cvs.sourceforge.net/*checkout*/jump-pilot/WFSPlugin/lib/deegree2.jar http://jump-pilot.cvs.sourceforge.net/*checkout*/jump-pilot/WFSPlugin/lib/commons-httpclient-2.0.2-deegreeversion.jar http://jump-pilot.cvs.sourceforge.net/*checkout*/jump-pilot/WFSPlugin/lib/vecmath.jar *IMPORTANT*: If you tried version < 0.2.0 of WFSPlugin, you need to update at least the deegree2.jar following the link below: http://jump-pilot.cvs.sourceforge.net/*checkout*/jump-pilot/WFSPlugin/lib/deegree2.jar 3. Start your OpenJUMP and you should use the WFSPlugin-icon Possible features for upcoming versions: - - make (poorly configured) UMN MapServer-WFS also available - integrate WFS-T against geoserver/deegree - more general SRS-integration (in deegree2) - create user-documentation Have fun and all the best Stephan Holl -- Stephan Holl <[EMAIL PROTECTED]>, http://intevation.de/~stephan Tel: +49 (0)541-33 50 8 32 | Intevation GmbH | AG Osnabrück - HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner - 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
[JPP-Devel] R: FeatureInfo table on steroids
Support for non-spatial DB tables would be a _great_ thing!!! You can do lots of thing with them (use attributes to theming other layers), or you can even create geometries on the fly using some of their attributes plus some BeanShell code, for example. Or they can be used to edit geometric layers (maybe they're ENUMs tables needed to decode things, ZIP for example). Bye Paolo Rizzi > -Messaggio originale- > Da: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] conto di > Martin Davis > Inviato: sabato 2 giugno 2007 0.36 > A: List for discussion of JPP development and use. > Oggetto: Re: [JPP-Devel] FeatureInfo table on steroids > > > I had similar thoughts a while back. In fact, the Feature concept > easily supports non-spatial features. About all that is > required is to > get the UI to recognize non-spatial Feature Schemas and do sensible > things with them (such as display a little table icon rather > than the > symbology icon in the Layer List panel, and not display the > button for > View/Edit Geometry). > > There's quite a few of these kinds of changes required to > support this > cleanly, but I don't think any of them are very difficult. We'd also > need a few non-spatial I/O drivers - CSV, text, maybe DBF. > And also a > way to set up joins between tables (this one is harder, I > think). This > is more than just a single plugin, tho - it's a more of a > generalization > of the existing Feature framework. > > As for the listener idea, if I understood what Paul was > wanting it would > be more like supporting adding an item to the existing popup > menu on the > Feature Info attribute table. > > Sunburned Surveyor wrote: > > I'm not sure I totally understand what Paul is talking about, but I > > had a comment or two and I wanted to throw an idea out there. > > > > Paul wrote: " A right click on the feature row to view the whole > > feature and have a view/edit feature frame that would > display the list > > of property names and values with nested panels for each nested > > feature." > > > > I like this idea. > > > > I have also thought about the issue that Paul highlighted in his > > example of the building address. For example, I might want to store > > information about the most recently recorded deed for a parcel. The > > problem with this is that there might be multiple items I'd like to > > know about the deed. (Date of Purchase, Date Recorded, Recording > > Number...) > > > > I had thought about solving this problem with a plug-in that would > > allows us to store "non-spatial" features. We could use something > > similar to the exixting Feature interface. The main difference would > > be that a non-spatial feature would not have a geometry associated > > with it. I think we could even display the non-spatial > features using > > the same attribute table that we currently use for spatial features, > > with some changes. (You could think of a non-spatial feature > > collection as a table in a typical RDBMS.) > > > > This might be a simple alternative to embedding a database. I've > > always thought using an embedded database added an > additional layer of > > complexity to OpenJUMP. I suppose as we consider more and > more advance > > functionality for attribute information an embedded database option > > becomes more attractive. Still, it is something to consider > carefully. > > One of the things that makes OpenJUMP so beautiful is its > simplicity. > > :] > > > > I also wonder if we could accomodate some custom attribute table > > behavior by creating a "listener" system similar to what > was done with > > the CursorTools. Plug-In developers would be able to add > listeners to > > each attribute table. When a mouse interaction was detected we could > > forward an event to the registered listeners that contained a > > reference to the feature and attribute over which the mouse pointer > > was located when the event occured. > > > > In this type of system Paul could create a listener and attach it to > > the attribute table with the address field. In this address field he > > would store a primary key. When the user held the mouse pointer over > > this address field an event would be sent to the listener with a > > reference to the feature and the primary key stored in the address > > field. He could then display a GUI with all of the information from > > the address that he retrieves using the primary key stored in the > > event. > > > > Perhaps this is what Paul was talking about and I didn't > understand completely. > > > > The Sunburned Surveyor > > > > > > > > > > On 6/1/07, Paul Austin <[EMAIL PROTECTED]> wrote: > > > >> Hi Martin, > >> > >> This case is where you have nested complex properties of > an attribute > >> nature. For example building may have an address property > that has the > >> attributes unit, number, street, city etc. > >> > >> I don't want to go down the whole nested feature > collection route as that > >> can get
Re: [JPP-Devel] new files changelog, changes and todo on CVS
Hi, Michaël Michaud schrieb: > Hi, > > Thanks Stefan, > Is there a way to use sourceforge cvs log to help completing the > changelog file you just added ? There are several tools for this out there. cvs2cl.pl [1] e.g is working fine. But ones again: Writing a ChangeLog this way is only for the lazy. ChangeLog changes should be checked in each time you do a check in. > About the todo list, we may have to choose a central place. There are > some todo lists on the wiki, there is the sourceforge feature request, > the sourceforge bug report and now here... What others think ? Central one in the source. Wikis are not reliable in the long term. It's not working off-line, depends on a internal data base structure not accessible to to user (migration issues). - Sascha [1] http://www.red-bean.com/cvs2cl/ - 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
