Re: [JPP-Devel] New Attribute View
Hi, The sceenshot you sent looks nice ;-) I just have a question related to user requests we read recently on this list. Do you intend to manage differently attribute views of editable features and attribute views of non editable features. I don't know if it is feasable (and if it is a good idea), but I think it is important to consider both cases and to have an idea about how we want to manage them on the long run. my 2c Michaël Paul Austin a écrit : >Hi Martin, > >The Spot Elevation is the layer name, I will change this to be in the >colour of the layer > >The Geometry view would be the current GeometryTab where you can view >different geometry text encodings, I'd like to change that icon to be >the (G) icon on the main tab. > >I'm still thinking over the best way to merge the geometry in with the >attribute tab, I decided not to mess around with the GeometyTab as is >now and implement a new view from the ground up. > >The new attribute view uses the HtmlRendererRepository for displaying >attributes values which is setup on plug-in init. As I mentioned I was >thinking of having a similar repository that allows you to override >settings for a FeatureSchema, this same approach could also be >implemented on a view page to allow the user to select the geometry >representation. > >For the layer drop down it would act as a quick filter just so you can >concentrate on one layer so it won't show the current layer for the >feature. It will either display (All) if any features can be displayed. > >Paul > >Martin Davis wrote: > > >>Most of this sounds very good. >> >>But do we lose the current HTML View, which shows a combination of >>Geometry and/or Attributes, and allows the user to choose different text >>renderings for the Geometry? Or is this what you mean by "Geometry View"? >> >>I would also suggest a different icon for the Attribute tab - so as not >>to confuse this with the attribute button on the HTML View. >> >>It would be nice if you could display the colour coding which appears on >>the other two views, to provide a visual clue about what Layr the >>displayed feature is from. Also, the Layer name should be shown - or is >>this the "Spot Elevation" string in your picture? Perhaps your idea of >>a dropdown showing the layers is the way to accomplish this. >> >> >> >>Paul Austin wrote: >> >> >> >>>All, >>> >>>I have done some more work on a new attribute view page which will work >>>with simple and nested features. The new view will be a new Tab on the >>>InfoFrame, I'm going to propose that we have three top level tabs, >>>Table, Geometry and Attribute. >>> >>>When you select the Attribute tab it will show one feature at a time and >>>have the usual database style first, previous,next and last navigation >>>buttons along with a record x of n display. >>> >>>I think I also want to have a drop down of the feature types (layers) so >>>you can select just to view a subset. >>> >>>As part of this I had to add an extension point to the InfoFrame to >>>allow you to register factories that can add new tabs when the frame is >>>created. >>> >>>For the rendering of property values I have implemented a renderer >>>repository so you can customize how values for a specific class are >>>rendered (e.g. date format). I'm thinking of extending this so you can >>>override this for a particular FeatureSchema, this will allow custom >>>plug-ins to do some fancy rendering of their properties. >>> >>>As we don't have an unstable branch I'll post a CVS diff of my changes >>>for people to review in the next few days. >>> >>>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
Re: [JPP-Devel] Comments on FeatureCache & the JUMP DataStore API
Sunburned, Just curious - how many parcels are in your county? How many MB and how long does it take to load, if it does? I've loaded the data from several Texas counties into just 512 MB in a fairly short time. regards, Larry On 6/6/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote: > Martin wrote: "It sounds to me like you are trying to build the same > functionality that currently exists in spatially-enable DBs - that is, > fast access to > ranges of features." > > Sort of, but not exactly. I'm really creating something that > accomplishes the same thing as GeoTools indexed Shapefile reader, but > with a slightly different approach. Instead of using the Shapefile > itself to store the data I read the Shapefile and separate it into > "chunks". Each chunk is either a set of attributes for a Feature or a > Feature geometry. There are two reasons why I took this approach, > instead of either using (A) the GeoTools indexed Shapefile reader, or > (B) an embedded database. The reasons are: > > [1] I hope to eventually break away from the limitations of ESRI's > shapefile specification. To do this I need a system that supports > Shapefiles, but that has its own internal storage format. I was going > to use an xml format for this initially, but after talking with some > of the OpenJUMP developers I realized a binary data format would be > much quicker. So I'm going to store the features inside the > FeatureCache using a simplified form of BOFF. (Binary Open Feature > Format) This will allow me to kill two birds with one stone. I get my > fast binary storage format, and I've taken a serious step towards a > file format that can replace Shapefiles. (I know that is an ambitious > goal for a closet developer like myself, but I always dream bigger > than my britches.) :] > > [2] I want to support other data formats in the future, not just > Shapefiles or BOFF. That's why I couldn't use GeoTools indexed > Shapefile reader. The FeatureCahce will be able to import Features > from any data source that supports Single-Feature-Access. > > [3] I want to avoid the complexity of JDBC that must come with the use > of a embedded database. I realize I loose some of the rich feature set > offered by a RDBMS with this move, but for me the extra work isn't > worth what is gained. (Besides, I think some other teams, at least > Sigle, are working on this technique.) > > Martin wrote: "That's fine - it's appealing to have a lightweight, > free FeatureCache implementation, which is perfectly matched to the job > of storing JUMP Features (unlike most SDB's, which all have their own > idiosyncracies of storage model)." > > That's my goal with the FeatureCahce. > > Martin wrote: "My point about the DataStore is that you need to expose > your great new Cache to JUMP in some way. The DataStore API is > designed to do just > this - it let's the JUMP renderer query a range of features from a > datastore in a streaming fashion." > > I guess that I am taking a totally different approach to the > FeatureCache design. (Maybe I need to rethink this.) I'm not even > messing with the DataStore API. I'll be exposing the FeatureCache to > OpenJUMP as an implementation of the FeatureCollection interface. > Internally, OpenJUMP won't be able to tell the difference between a > FeatureCollection backed by my FeatureCache and a normal "in-memory" > FeatureCache. (Except that it will be a little slower. I'm trying to > work in a buffer to help with this. The user will be able to control > the size of the buffer depending on their computer's RAM and their > need for speed.) I will need to expose some UI components so that > users can manage FeatureCahche's, but other than that they'll act just > like a normal FeatureCollection. > > Martin wrote: "This is a good discussion - I'll be interested to hear other's > comments." > > Yup. You know me. All talk and no real work. :] (Just ask Stefan...) > All joking aside, I've laid out the class diagram for the FeatureCache > and have started coding the low-level interfaces. I just need to > decide on the source of my Shapefile code and then I'l start cranking > away on this thing. It has been my pet peeve in OpenJUMP for a long > time. > > Martin wrote: "My main goal is to have a single API/framework for accessing > large datastores. That way, all additional work benefits everyone." > > This is a good goal. I'll do whatever I can to avoid introducing a new > DataStore API to OpenJUMP. When I implement Single-Feature-Access to > Shapefiles using GeoTools or Deegree I will try to make this available > under the DataStore API. > > I'm really looking for a good way to read in a Shapefile of all the > parcels in my County without OpenJUMP choking. Even Autodesk Map has a > hard time with that task! :] > > The Sunburned Surveyor > > > On 6/6/07, Martin Davis <[EMAIL PROTECTED]> wrote: > > > > > > Sunburned Surveyor wrote: > > > > > > I guess I envision the FeatureCache as more of an internal data > > > manager tha
[JPP-Devel] When does the PlugIn.execute() method get called?
I've just figured out an intersting part of JUMP/OpenJUMP's plug-in management and I wanted to share it with others. This might also be intersting for those working with OpenJUMP's rendering system. The intialize method of the InstallRendererPlugIn class adds a listener to the JUMPWorkbench. This listener notifies the plug-in whenver a new component is added to the Workbench. When this event occurs the plug-in checks to see if the component that was added was a TaskFrame. If it was a TaskFrame the plug-in adds any renderers encapsulated in a plug-in to that TaskFrames RenderingManager. This is some really ingenious code. It is a great way to get access to a TaskFrame and its public members. This is tricky because you never know when a TaskFrame is going to be created. (That is, the user can create multiple TaskFrames, and can create a TaskFrame at any point during JUMP's existence.) This means I will be able to use a modified form of the InstallRendererPlugIn class for my pluggable rendering system. This will allow us to add any custom renderer using JUMP's normal plug-in class, instead of using the funky hack I had come up with, which basically involved reading a text file with a name of custom renderers from within the constructor of the RenderingManager class. I've now got some major tweaking to do in my pluggable rendering code, but the end result will be a much better system. At any rate, if you ever need to access the public members of a TaskFrame during or shortly after its creation from within a standard JUMP plug-in, the code in the initialize method of the InstallRendererPlugIn is the way to do it! I'm always humbled at the Java wizardry that I discover in JUMP. It makes me realize that I will always be just a closet programmer. :] The Sunburned Surveyor P.S. - I really need to take some notes on how all this works and get it on the wiki. - 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] New Attribute View
Hi Martin, The Spot Elevation is the layer name, I will change this to be in the colour of the layer The Geometry view would be the current GeometryTab where you can view different geometry text encodings, I'd like to change that icon to be the (G) icon on the main tab. I'm still thinking over the best way to merge the geometry in with the attribute tab, I decided not to mess around with the GeometyTab as is now and implement a new view from the ground up. The new attribute view uses the HtmlRendererRepository for displaying attributes values which is setup on plug-in init. As I mentioned I was thinking of having a similar repository that allows you to override settings for a FeatureSchema, this same approach could also be implemented on a view page to allow the user to select the geometry representation. For the layer drop down it would act as a quick filter just so you can concentrate on one layer so it won't show the current layer for the feature. It will either display (All) if any features can be displayed. Paul Martin Davis wrote: > Most of this sounds very good. > > But do we lose the current HTML View, which shows a combination of > Geometry and/or Attributes, and allows the user to choose different text > renderings for the Geometry? Or is this what you mean by "Geometry View"? > > I would also suggest a different icon for the Attribute tab - so as not > to confuse this with the attribute button on the HTML View. > > It would be nice if you could display the colour coding which appears on > the other two views, to provide a visual clue about what Layr the > displayed feature is from. Also, the Layer name should be shown - or is > this the "Spot Elevation" string in your picture? Perhaps your idea of > a dropdown showing the layers is the way to accomplish this. > > > > Paul Austin wrote: > >> All, >> >> I have done some more work on a new attribute view page which will work >> with simple and nested features. The new view will be a new Tab on the >> InfoFrame, I'm going to propose that we have three top level tabs, >> Table, Geometry and Attribute. >> >> When you select the Attribute tab it will show one feature at a time and >> have the usual database style first, previous,next and last navigation >> buttons along with a record x of n display. >> >> I think I also want to have a drop down of the feature types (layers) so >> you can select just to view a subset. >> >> As part of this I had to add an extension point to the InfoFrame to >> allow you to register factories that can add new tabs when the frame is >> created. >> >> For the rendering of property values I have implemented a renderer >> repository so you can customize how values for a specific class are >> rendered (e.g. date format). I'm thinking of extending this so you can >> override this for a particular FeatureSchema, this will allow custom >> plug-ins to do some fancy rendering of their properties. >> >> As we don't have an unstable branch I'll post a CVS diff of my changes >> for people to review in the next few days. >> >> 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] New Attribute View
Most of this sounds very good. But do we lose the current HTML View, which shows a combination of Geometry and/or Attributes, and allows the user to choose different text renderings for the Geometry? Or is this what you mean by "Geometry View"? I would also suggest a different icon for the Attribute tab - so as not to confuse this with the attribute button on the HTML View. It would be nice if you could display the colour coding which appears on the other two views, to provide a visual clue about what Layr the displayed feature is from. Also, the Layer name should be shown - or is this the "Spot Elevation" string in your picture? Perhaps your idea of a dropdown showing the layers is the way to accomplish this. Paul Austin wrote: > All, > > I have done some more work on a new attribute view page which will work > with simple and nested features. The new view will be a new Tab on the > InfoFrame, I'm going to propose that we have three top level tabs, > Table, Geometry and Attribute. > > When you select the Attribute tab it will show one feature at a time and > have the usual database style first, previous,next and last navigation > buttons along with a record x of n display. > > I think I also want to have a drop down of the feature types (layers) so > you can select just to view a subset. > > As part of this I had to add an extension point to the InfoFrame to > allow you to register factories that can add new tabs when the frame is > created. > > For the rendering of property values I have implemented a renderer > repository so you can customize how values for a specific class are > rendered (e.g. date format). I'm thinking of extending this so you can > override this for a particular FeatureSchema, this will allow custom > plug-ins to do some fancy rendering of their properties. > > As we don't have an unstable branch I'll post a CVS diff of my changes > for people to review in the next few days. > > 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 > -- Martin Davis Senior Technical Architect Refractions Research, Inc. (250) 383-3022 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] GridRenderer and ScaleBarRenderer
It appears that the default behavior of the InstallRendererPlugIn class is to cycle trough all TaskFrames that are present in the WorkbenchFrame adding its Renderer to the RenderingManager. (This would take place for each extension of the Install RendererPlugIn class, like the InstallGridRendererPlugIn and the InstallScaleBarRendererPlugIn.) It appears that JUMP already had a way to add custom Renderers, as long as you didn't mind that it could only paint above or below Layerable objects. The disadvantage of this system is that you couldn't add custom renderers that could be selected for Layerable objects. This can be done with my pluggable rendering system. I'm not sure just yet, but I think that I will be able to eliminate the InstallRendererPlugIn class and its extensions, since you can now add custom renderers using my pluggable rendering system. One of my original challenges with the pluggable rendering system was determining how I could add custom Renderer objects to each RenderingManager via the existing plug-in system. I ended up avoiding the existing plug-in system altogether because I didn't see a way to do this. It looks like the JUMP wizards found a way to do this. Maybe I need to mimic thir logic as it exists in the InstallRendererPlugIn class. I will consider this as well. The Sunburned Surveyor On 6/6/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote: > I managed to find the answer to this question using the "open call > hierarchy" tool in Eclipse on the constructor of the GridRenderer > class. It looks like there is a plug-in that performs the isntallation > of the GridRenderer. > > This adds a layer of complexity that I wasn't prepared for. I'll have > to study this class so I can figure out how to incoporate it into my > pluggable rendering system. > > Just when I thought I was close to getting this thing finished. :] > > I imagine the same thing is done for the ScaleBarRenderer. > > Thanks, > > The Sunburned Surveyor > > On 6/6/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote: > > I noticed that only 4 of the 6 special renderers for the Strings > > stored in the list of ContentIDs are added in the contructor of the > > RenderingManager class. The GridRenderer and the ScaleBarRenderer are > > not added in this constructor. > > > > Does anyone know where and when they are added to the > > RenderingManager? I find it odd that they aren't added in the > > constructor. > > > > I note that the ScaleBarPlugIn class adds the String to the list of > > ContentIDs in its execute method, but does not add the > > ScaleBarRenderer itself. > > > > Thanks for the help with this. > > > > The Sunburned Surveyor > > > - 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] GridRenderer and ScaleBarRenderer
I managed to find the answer to this question using the "open call hierarchy" tool in Eclipse on the constructor of the GridRenderer class. It looks like there is a plug-in that performs the isntallation of the GridRenderer. This adds a layer of complexity that I wasn't prepared for. I'll have to study this class so I can figure out how to incoporate it into my pluggable rendering system. Just when I thought I was close to getting this thing finished. :] I imagine the same thing is done for the ScaleBarRenderer. Thanks, The Sunburned Surveyor On 6/6/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote: > I noticed that only 4 of the 6 special renderers for the Strings > stored in the list of ContentIDs are added in the contructor of the > RenderingManager class. The GridRenderer and the ScaleBarRenderer are > not added in this constructor. > > Does anyone know where and when they are added to the > RenderingManager? I find it odd that they aren't added in the > constructor. > > I note that the ScaleBarPlugIn class adds the String to the list of > ContentIDs in its execute method, but does not add the > ScaleBarRenderer itself. > > Thanks for the help with this. > > The Sunburned Surveyor > - 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] GridRenderer and ScaleBarRenderer
I noticed that only 4 of the 6 special renderers for the Strings stored in the list of ContentIDs are added in the contructor of the RenderingManager class. The GridRenderer and the ScaleBarRenderer are not added in this constructor. Does anyone know where and when they are added to the RenderingManager? I find it odd that they aren't added in the constructor. I note that the ScaleBarPlugIn class adds the String to the list of ContentIDs in its execute method, but does not add the ScaleBarRenderer itself. Thanks for the help with this. The Sunburned Surveyor - 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] Comments on FeatureCache & the JUMP DataStore API
Martin wrote: "It sounds to me like you are trying to build the same functionality that currently exists in spatially-enable DBs - that is, fast access to ranges of features." Sort of, but not exactly. I'm really creating something that accomplishes the same thing as GeoTools indexed Shapefile reader, but with a slightly different approach. Instead of using the Shapefile itself to store the data I read the Shapefile and separate it into "chunks". Each chunk is either a set of attributes for a Feature or a Feature geometry. There are two reasons why I took this approach, instead of either using (A) the GeoTools indexed Shapefile reader, or (B) an embedded database. The reasons are: [1] I hope to eventually break away from the limitations of ESRI's shapefile specification. To do this I need a system that supports Shapefiles, but that has its own internal storage format. I was going to use an xml format for this initially, but after talking with some of the OpenJUMP developers I realized a binary data format would be much quicker. So I'm going to store the features inside the FeatureCache using a simplified form of BOFF. (Binary Open Feature Format) This will allow me to kill two birds with one stone. I get my fast binary storage format, and I've taken a serious step towards a file format that can replace Shapefiles. (I know that is an ambitious goal for a closet developer like myself, but I always dream bigger than my britches.) :] [2] I want to support other data formats in the future, not just Shapefiles or BOFF. That's why I couldn't use GeoTools indexed Shapefile reader. The FeatureCahce will be able to import Features from any data source that supports Single-Feature-Access. [3] I want to avoid the complexity of JDBC that must come with the use of a embedded database. I realize I loose some of the rich feature set offered by a RDBMS with this move, but for me the extra work isn't worth what is gained. (Besides, I think some other teams, at least Sigle, are working on this technique.) Martin wrote: "That's fine - it's appealing to have a lightweight, free FeatureCache implementation, which is perfectly matched to the job of storing JUMP Features (unlike most SDB's, which all have their own idiosyncracies of storage model)." That's my goal with the FeatureCahce. Martin wrote: "My point about the DataStore is that you need to expose your great new Cache to JUMP in some way. The DataStore API is designed to do just this - it let's the JUMP renderer query a range of features from a datastore in a streaming fashion." I guess that I am taking a totally different approach to the FeatureCache design. (Maybe I need to rethink this.) I'm not even messing with the DataStore API. I'll be exposing the FeatureCache to OpenJUMP as an implementation of the FeatureCollection interface. Internally, OpenJUMP won't be able to tell the difference between a FeatureCollection backed by my FeatureCache and a normal "in-memory" FeatureCache. (Except that it will be a little slower. I'm trying to work in a buffer to help with this. The user will be able to control the size of the buffer depending on their computer's RAM and their need for speed.) I will need to expose some UI components so that users can manage FeatureCahche's, but other than that they'll act just like a normal FeatureCollection. Martin wrote: "This is a good discussion - I'll be interested to hear other's comments." Yup. You know me. All talk and no real work. :] (Just ask Stefan...) All joking aside, I've laid out the class diagram for the FeatureCache and have started coding the low-level interfaces. I just need to decide on the source of my Shapefile code and then I'l start cranking away on this thing. It has been my pet peeve in OpenJUMP for a long time. Martin wrote: "My main goal is to have a single API/framework for accessing large datastores. That way, all additional work benefits everyone." This is a good goal. I'll do whatever I can to avoid introducing a new DataStore API to OpenJUMP. When I implement Single-Feature-Access to Shapefiles using GeoTools or Deegree I will try to make this available under the DataStore API. I'm really looking for a good way to read in a Shapefile of all the parcels in my County without OpenJUMP choking. Even Autodesk Map has a hard time with that task! :] The Sunburned Surveyor On 6/6/07, Martin Davis <[EMAIL PROTECTED]> wrote: > > > Sunburned Surveyor wrote: > > > > I guess I envision the FeatureCache as more of an internal data > > manager than I do a data source. The idea is that you suck in features > > from any of OpenJUMP's existing DataStores and store them in the > > FeatureCache. You'll only need to do this for Layers that will contain > > lots of features and might possible max out of your RAM. > > > > If you have suggestions on how I can implement this particular aspect > > of the FeatureCache I'd like to hear them. At this point I plan on > > using GeoTools or Deegree ESRI Shapefile code so th
[JPP-Devel] R: Comments on FeatureCache & the JUMP DataStore API
I agree with Martin!!! Also I can't understand Surveyor really well here... Are you thinking about using shapefiles to persist the FeatureCache??? If yes, it seems a little odd, given all the limits shapfiles have (field names length, data tyeps, etc.). If not, pardon me!!! Anyway, to do the persist, a Java DB would be better suited, like HSQL for example. There's no need for it to be spatial enabled, you can store Geometries as JTS Object inside a "normal" field, then you can read them all from the DB inside a JTS spatial index along with record IDs. But, as Martin suggests, this may be the job of a DataStore. One can simply load it's features from whatever sources they're stored in and then save them to this "smart" data store. Work on them as long as he wants, then save them back to the original format. If one has PostGIS or Oracle available, he doesn't even need it. All this is only needed if the original features are inside shapefiles or some other inefficient file format. If your original data are already inside PostGIS or Oracle, you don't need a FeatureCache at all (but isn't it already built-in inside OJ??? Doesn't it already caches fetures from data stores???). Yes, maybe I'm thinking about browsing now, less about editing...??? But maybe I didn't understand it at all...!!! Sorry for that...!!! Bye Paolo Rizzi > -Messaggio originale- > Da: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] conto di > Martin Davis > Inviato: mercoledì 6 giugno 2007 19.00 > A: Sunburned Surveyor > Cc: OpenJUMP Dev > Oggetto: [JPP-Devel] Comments on FeatureCache & the JUMP DataStore API > > > > > Sunburned Surveyor wrote: > > > > I guess I envision the FeatureCache as more of an internal data > > manager than I do a data source. The idea is that you suck > in features > > from any of OpenJUMP's existing DataStores and store them in the > > FeatureCache. You'll only need to do this for Layers that > will contain > > lots of features and might possible max out of your RAM. > > > > If you have suggestions on how I can implement this > particular aspect > > of the FeatureCache I'd like to hear them. At this point I plan on > > using GeoTools or Deegree ESRI Shapefile code so that I can > access one > > feature at a time from a Shapefile. (I can't do this with > the current > > Shapefile driver.) I can do this in an new Shapefile driver that is > > written and used just in my FeatureCache, or I can rewrite the > > exsiting Shapefile DataStore to provide this access. > > > > In the long run, I'd really like to see a DataStore interface that > > allowed single-feature-access. For example, at some point I may want > > to read in huge DXF files as well. > It sounds to me like you are trying to build the same > functionality that > currently exists in spatially-enable DBs - that is, fast access to > ranges of features. That's fine - it's appealing to have a > lightweight, > free FeatureCache implementation, which is perfectly matched > to the job > of storing JUMP Features (unlike most SDB's, which all have their own > idiosyncracies of storage model). If it was me I might > investigate the > possibility of using an existing Java DB, with possibly some spatial > enhancements. (You yourself suggested this in a different > context...). > You're going to develop most of the same functionality anyway, and > you'll never get the maturity of the existing DBs. > > My point about the DataStore is that you need to expose your > great new > Cache to JUMP in some way. The DataStore API is designed to do just > this - it let's the JUMP renderer query a range of features from a > datastore in a streaming fashion. I think you should target your > FeatureCache to be simply another kind of DataStore. That > way, you get > all the existing functionality of DataStores - streaming, > interruptible > drawing, querying by range, connection lifecycle, UI, etc. > Otherwise, > you're going to have to build all this yourself, in yet another new > framework. If you need more functionality exposed, this > should become > enhancements to the DS framework, since likely other use > cases will need > this as well. > > Now, one baby step in this direction is to expose the GT indexed > Shapefile as a DataStore. This should be easy to do, and > right away we > will have the ability to view large shapefiles. > > If you are wanting DXF as well, then you have a choice to make. DXF > doesn't have any indexing AFAIK, so you'll either have to > build this, or > move the data into some other format which does. > > This is a good discussion - I'll be interested to hear other's > comments. My main goal is to have a single API/framework for > accessing > large datastores. That way, all additional work benefits everyone. > > HTH - M > > > > > I'm not sure what the best way is to achieve this. If you have > > suggestions, please let me know. > > > > Thanks again for all of your help. > > > >
Re: [JPP-Devel] Bug in InfoModel/Listener on remove
Here is the patch to fix the issue, I had to move two lines to avoid a NPE.
Paul
Index: src/com/vividsolutions/jump/workbench/ui/InfoModel.java
===
RCS file:
/cvsroot/jump-pilot/openjump/src/com/vividsolutions/jump/workbench/ui/InfoModel.java,v
retrieving revision 1.1
diff -u -r1.1 InfoModel.java
--- src/com/vividsolutions/jump/workbench/ui/InfoModel.java 16 Jun 2005
22:11:46 - 1.1
+++ src/com/vividsolutions/jump/workbench/ui/InfoModel.java 6 Jun 2007
17:06:40 -
@@ -92,13 +92,13 @@
public void remove(Layer layer) {
LayerTableModel layerTableModel = getTableModel(layer);
-((LayerTableModel) layerToTableModelMap.get(layer)).dispose();
-layerToTableModelMap.remove(layer);
for (Iterator i = listeners.iterator(); i.hasNext();) {
InfoModelListener listener = (InfoModelListener) i.next();
listener.layerRemoved(layerTableModel);
}
+((LayerTableModel) layerToTableModelMap.get(layer)).dispose();
+layerToTableModelMap.remove(layer);
}
public void clear() {
Paul Austin wrote:
> In the current implementation of InfoModel.remove() it disposes of the
> LayerTableModel before it notifies the listener that it is going to be
> removed. This means that the listeners don't have access to the features
> that were being removed to do cleanup. The following line should be
> moved to the end of the method.
>
> ((LayerTableModel) layerToTableModelMap.get(layer)).dispose();
>
> What do people think?
>
> 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
[JPP-Devel] Comments on FeatureCache & the JUMP DataStore API
Sunburned Surveyor wrote: > > I guess I envision the FeatureCache as more of an internal data > manager than I do a data source. The idea is that you suck in features > from any of OpenJUMP's existing DataStores and store them in the > FeatureCache. You'll only need to do this for Layers that will contain > lots of features and might possible max out of your RAM. > > If you have suggestions on how I can implement this particular aspect > of the FeatureCache I'd like to hear them. At this point I plan on > using GeoTools or Deegree ESRI Shapefile code so that I can access one > feature at a time from a Shapefile. (I can't do this with the current > Shapefile driver.) I can do this in an new Shapefile driver that is > written and used just in my FeatureCache, or I can rewrite the > exsiting Shapefile DataStore to provide this access. > > In the long run, I'd really like to see a DataStore interface that > allowed single-feature-access. For example, at some point I may want > to read in huge DXF files as well. It sounds to me like you are trying to build the same functionality that currently exists in spatially-enable DBs - that is, fast access to ranges of features. That's fine - it's appealing to have a lightweight, free FeatureCache implementation, which is perfectly matched to the job of storing JUMP Features (unlike most SDB's, which all have their own idiosyncracies of storage model). If it was me I might investigate the possibility of using an existing Java DB, with possibly some spatial enhancements. (You yourself suggested this in a different context...). You're going to develop most of the same functionality anyway, and you'll never get the maturity of the existing DBs. My point about the DataStore is that you need to expose your great new Cache to JUMP in some way. The DataStore API is designed to do just this - it let's the JUMP renderer query a range of features from a datastore in a streaming fashion. I think you should target your FeatureCache to be simply another kind of DataStore. That way, you get all the existing functionality of DataStores - streaming, interruptible drawing, querying by range, connection lifecycle, UI, etc. Otherwise, you're going to have to build all this yourself, in yet another new framework. If you need more functionality exposed, this should become enhancements to the DS framework, since likely other use cases will need this as well. Now, one baby step in this direction is to expose the GT indexed Shapefile as a DataStore. This should be easy to do, and right away we will have the ability to view large shapefiles. If you are wanting DXF as well, then you have a choice to make. DXF doesn't have any indexing AFAIK, so you'll either have to build this, or move the data into some other format which does. This is a good discussion - I'll be interested to hear other's comments. My main goal is to have a single API/framework for accessing large datastores. That way, all additional work benefits everyone. HTH - M > > I'm not sure what the best way is to achieve this. If you have > suggestions, please let me know. > > Thanks again for all of your help. > > Landon > > > On 6/6/07, Martin Davis <[EMAIL PROTECTED]> wrote: >> First of all, I don't think you (or JUMP) has to commit to a single >> library for different pieces of functionality. I think the Feature >> model question is separate from the issue of which Shapefile I/O >> implementation to use. So if you like the deegree one, just use that. >> I don't really know which library is likely to be better quality or more >> stable. I guess for Shapefiles I'd probably vote for using GT, but not >> really for any hard reason. But I agree about your comment about >> deegree being more supportive of OJ - we probably want to encourage >> that! >> >> Another point in favour of deegree is that the GT change process seems >> very cumbersome and slow. I've always prefereed a smaller group to work >> with, so change can be made faster. >> >> The important thing is to isolate these various components behind >> well-defined interfaces in JUMP, so that they can be swapped out if >> need be. >> >> By the way, are you looking at using the DataStore framework as the API >> to your "Shapefile cache"? It doesn't make sense to use the existing >> DataSource Reader, since it only reads an entire collection at a time. >> Or are you making yet another API? In that case, I'd be concerned, since >> OJ would then have three different data access APIs. >> >> M >> >> Sunburned Surveyor wrote: >> > Martin, >> > >> > After poking around a little in the Javadoc for the Deegree project I >> > see that it has everything I need for single feature access to an ESRI >> > Shapefile. The library also seems a little more stable than GeoTools, >> > and I think the folks at Deegree are more supportive of the work in >> > OpenJUMP than the folks at GeoTools. (I don't even think any of the >> > GeoTools folks are subs
Re: [JPP-Devel] Bug in InfoModel/Listener on remove
Or the dispose method should notify the TableModelListeners that all rows have been removed. Paul Paul Austin wrote: > In the current implementation of InfoModel.remove() it disposes of the > LayerTableModel before it notifies the listener that it is going to be > removed. This means that the listeners don't have access to the features > that were being removed to do cleanup. The following line should be > moved to the end of the method. > > ((LayerTableModel) layerToTableModelMap.get(layer)).dispose(); > > What do people think? > > 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
[JPP-Devel] Bug in InfoModel/Listener on remove
In the current implementation of InfoModel.remove() it disposes of the LayerTableModel before it notifies the listener that it is going to be removed. This means that the listeners don't have access to the features that were being removed to do cleanup. The following line should be moved to the end of the method. ((LayerTableModel) layerToTableModelMap.get(layer)).dispose(); What do people think? 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
Re: [JPP-Devel] A really stupid question...
Not that I know of. It's been a while, but the inefficiency I think was that a new builder object is created for every geometry that is written. (Maybe this isn't actually so bad performance-wise, but it is unnecessary). Sunburned Surveyor wrote: > What about the Degree Shapefile support? How well does it work? (I > took a look at the Javadoc for their Shapefile code, and it looked > pretty simple.) > > Has there ever been any comparison of the Shapefile code in the two libraries? > > The Sunburned Surveyor > > On 6/6/07, Paul Austin <[EMAIL PROTECTED]> wrote: > >> Martin, >> >> What were the inefficiencies? >> >> 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 > > -- Martin Davis Senior Technical Architect Refractions Research, Inc. (250) 383-3022 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] A really stupid question...
What about the Degree Shapefile support? How well does it work? (I took a look at the Javadoc for their Shapefile code, and it looked pretty simple.) Has there ever been any comparison of the Shapefile code in the two libraries? The Sunburned Surveyor On 6/6/07, Paul Austin <[EMAIL PROTECTED]> wrote: > Martin, > > What were the inefficiencies? > > 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] A really stupid question...
Martin, What were the inefficiencies? 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
Re: [JPP-Devel] A really stupid question...
We did make some bug fixes in the Shapefile Reader & Writer in JUMP. These may have been made in the new GT code as well, however. The GT code in JUMP is very old - I think it's been completely re-written in GT now. It would be nice to have a set of unit tests for Shapefiles, to verify that some of these anomalies stay fixed. I wonder if GT has this? I also have observed that there is at least one major inefficiency in the current JUMP Shapefile code - maybe the new GT code will fix that too. Sunburned Surveyor wrote: > Roger that. > > Thanks David. > > SS > > On 6/6/07, David Zwiers <[EMAIL PROTECTED]> wrote: > >> The 'shapefile' code in Jump is a port of the geotools code, so this >> should be relatively painless -- I would port the indexed shapefile >> reader from GT to replace the existing shapefile reader. >> >> I you go ahead with these changes, I'd be interested in back porting >> this to Jump. >> >> David >> >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of >> Sunburned Surveyor >> Sent: June 6, 2007 8:07 AM >> To: List for discussion of JPP development and use. >> Subject: [JPP-Devel] A really stupid question... >> >> At some point should we rewrite the ESRI Shapefile I/O code in >> OpenJUMP to provide an indexed FeatureCollection by default? I'm >> thinking this could be used to speed up rendering of Layers, and I >> know it would speed up my processing of object snaps in the new >> CursorTool stuff. >> >> Has this already been done? If not, would there be any serious >> performance penalties for making this change? >> >> I'm just curious as I was looking at the Quadtree class in JTS this >> morning. >> >> (I'll be working with the ESRI Shapefile code from GeoTools or Deegree >> as part of the FeatureCache. I don't think it would be too much of a >> stretch to revamp the "regular" Shapefile driver in OpenJUMP while I >> am at it. If I do this I could make the change described above.) >> >> Thanks for the thoughts. >> >> The Sunburned Surveyor >> >> >> - >> This SF.net email is sponsored by DB2 Express >> Download DB2 Express C - the FREE version of DB2 express and take >> control of your XML. No limits. Just data. Click to get it now. >> http://sourceforge.net/powerbar/db2/ >> ___ >> Jump-pilot-devel mailing list >> Jump-pilot-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >> >> >> >> - >> This SF.net email is sponsored by DB2 Express >> Download DB2 Express C - the FREE version of DB2 express and take >> control of your XML. No limits. Just data. Click to get it now. >> http://sourceforge.net/powerbar/db2/ >> ___ >> Jump-pilot-devel mailing list >> Jump-pilot-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >> >> > > - > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > ___ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > -- Martin Davis Senior Technical Architect Refractions Research, Inc. (250) 383-3022 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] A really stupid question...
Roger that. Thanks David. SS On 6/6/07, David Zwiers <[EMAIL PROTECTED]> wrote: > The 'shapefile' code in Jump is a port of the geotools code, so this > should be relatively painless -- I would port the indexed shapefile > reader from GT to replace the existing shapefile reader. > > I you go ahead with these changes, I'd be interested in back porting > this to Jump. > > David > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Sunburned Surveyor > Sent: June 6, 2007 8:07 AM > To: List for discussion of JPP development and use. > Subject: [JPP-Devel] A really stupid question... > > At some point should we rewrite the ESRI Shapefile I/O code in > OpenJUMP to provide an indexed FeatureCollection by default? I'm > thinking this could be used to speed up rendering of Layers, and I > know it would speed up my processing of object snaps in the new > CursorTool stuff. > > Has this already been done? If not, would there be any serious > performance penalties for making this change? > > I'm just curious as I was looking at the Quadtree class in JTS this > morning. > > (I'll be working with the ESRI Shapefile code from GeoTools or Deegree > as part of the FeatureCache. I don't think it would be too much of a > stretch to revamp the "regular" Shapefile driver in OpenJUMP while I > am at it. If I do this I could make the change described above.) > > Thanks for the thoughts. > > The Sunburned Surveyor > > > - > 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] A really stupid question...
The 'shapefile' code in Jump is a port of the geotools code, so this should be relatively painless -- I would port the indexed shapefile reader from GT to replace the existing shapefile reader. I you go ahead with these changes, I'd be interested in back porting this to Jump. David -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sunburned Surveyor Sent: June 6, 2007 8:07 AM To: List for discussion of JPP development and use. Subject: [JPP-Devel] A really stupid question... At some point should we rewrite the ESRI Shapefile I/O code in OpenJUMP to provide an indexed FeatureCollection by default? I'm thinking this could be used to speed up rendering of Layers, and I know it would speed up my processing of object snaps in the new CursorTool stuff. Has this already been done? If not, would there be any serious performance penalties for making this change? I'm just curious as I was looking at the Quadtree class in JTS this morning. (I'll be working with the ESRI Shapefile code from GeoTools or Deegree as part of the FeatureCache. I don't think it would be too much of a stretch to revamp the "regular" Shapefile driver in OpenJUMP while I am at it. If I do this I could make the change described above.) Thanks for the thoughts. The Sunburned Surveyor - 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
[JPP-Devel] A really stupid question...
At some point should we rewrite the ESRI Shapefile I/O code in OpenJUMP to provide an indexed FeatureCollection by default? I'm thinking this could be used to speed up rendering of Layers, and I know it would speed up my processing of object snaps in the new CursorTool stuff. Has this already been done? If not, would there be any serious performance penalties for making this change? I'm just curious as I was looking at the Quadtree class in JTS this morning. (I'll be working with the ESRI Shapefile code from GeoTools or Deegree as part of the FeatureCache. I don't think it would be too much of a stretch to revamp the "regular" Shapefile driver in OpenJUMP while I am at it. If I do this I could make the change described above.) Thanks for the thoughts. The Sunburned Surveyor - 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] deegree Feature Model for OJ [was: Re: R: Common Feature model]
I took a look at the Javadoc for Deegree this morning. It does indeed appear that the Deegree project already contains code for input/output of various geospatial data formats and map projections. It looks like I would have to perform conversions of Deegree Features to JUMP Features just like I would in GeoTools. In summary, I don't see any real huge differences between using the Deegree code and using the GeoTools code. Deegree seems to be more stable, and OpenJUMP already benefits from the work of Deegree developers. On the other hand, I've already done quite a bit of talk with Jody from Refractions Research about using the code from GeoTools, and was leaning in that direction. All I really wanted to do was use some code for single feature accesss to Shapefiles for my FeatureCache. I only thought about closer collaboration with GeoTools because it seemed like the wise thing to do, not necessarily because I wanted to see a more complex Feature model being used in OpenJUMP. I find myself in agreement with Paul Austin. I really wish the folks at the different projects like Deegree and GeoTools could work more closely together. I'll need to think about this a bit more before I move forward. Any suggestions on this issue are always welcome. :] The Sunburned Surveyor On 6/6/07, Markus Müller <[EMAIL PROTECTED]> wrote: > Hi Stephan, > > Stephan Holl schrieb: > > [snip] > > Could you point us to the right direction inside the huge deegree-SVN? > > I think this will make the search easier and shows the relevant parts > > quickly. > > > The "real" sources can be found in /base/trunk/src. ;-) > Then go to org/deegree/model/feature. > > Does that help? > > > 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 > - 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] deegree Feature Model for OJ [was: Re: R: Common Feature model]
Hi Stephan, Stephan Holl schrieb: > [snip] > Could you point us to the right direction inside the huge deegree-SVN? > I think this will make the search easier and shows the relevant parts > quickly. > The "real" sources can be found in /base/trunk/src. ;-) Then go to org/deegree/model/feature. Does that help? 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] new files changelog, changes and todo on CVS
done. Stefan Steiniger schrieb: > ok, so lets move (Sascha could do that if he commits) > > stefan > > Stephan Holl wrote: > >> Hello Stefan, >> >> Stefan Steiniger <[EMAIL PROTECTED]>, [20070606 - 11:07:45] >> >> >> >>> if you wish, you can change it. >>> I thought it belongs rather to the src, and not to all the other etc >>> stuff. >>> >>> >> I wouls vote to include it in the top-folder so that we can also keep >> track of changes of other folders like lib/, etc/, docs/... >> >> Best >> >> Stephan >> >> >> > > > - > 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] new files changelog, changes and todo on CVS
ok, so lets move (Sascha could do that if he commits) stefan Stephan Holl wrote: >Hello Stefan, > >Stefan Steiniger <[EMAIL PROTECTED]>, [20070606 - 11:07:45] > > > >>if you wish, you can change it. >>I thought it belongs rather to the src, and not to all the other etc >>stuff. >> >> > >I wouls vote to include it in the top-folder so that we can also keep >track of changes of other folders like lib/, etc/, docs/... > >Best > > Stephan > > > - 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] new files changelog, changes and todo on CVS
Hello Stefan, Stefan Steiniger <[EMAIL PROTECTED]>, [20070606 - 11:07:45] > if you wish, you can change it. > I thought it belongs rather to the src, and not to all the other etc > stuff. I wouls vote to include it in the top-folder so that we can also keep track of changes of other folders like lib/, etc/, docs/... 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] new files changelog, changes and todo on CVS
if you wish, you can change it. I thought it belongs rather to the src, and not to all the other etc stuff. stefan Sascha L. Teichmann wrote: >BTW: Why do you hide ChangeLog & Co. in the src folder? >Nice place to be overseen. One level up it would be more >visual. But I can live with the current place. > >- Sascha > >Stefan Steiniger schrieb: > > >>that's pretty cool :) >> >>Sascha L. Teichmann schrieb: >> >> >>>Hi together, >>> >>>I've created a sample ChangeLog [1] for with cvs2cl.pl for >>>a fresh anonymous OpenJUMP CVS checkout. Please, have a look >>>at it. When committing the BasicStyle patch I would >>>like to add this for completeness to the src/ChangeLog. >>>After this I recommend to maintain it manually. >>> >>>the call of cvs2cl.pl was: >>> >>>cvs2cl.pl --no-times -U emails.txt --show-dead --utc >>> >>>emails.txt is a map of email addresses I took from >>>the JPP list. Spammmers already have these. >>> >>>Any, comments? >>> >>>- Sascha >>> >>>[1] http://intevation.de/~teichmann/printlayout/ChangeLog >>> >>> >>>Stefan Steiniger schrieb: >>> >>> Salut Michael (i currently cant follow the list - to much is going on) 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 ? > > i hope sascha's answer was sufficient.. i have not used it yet and did look only on the wfs and printplugin files for an example >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 ? > > i think the todo list in src folder is our personal (devel) thing and we shoudl also add here the improtant bugs that we receive at sourceforge. I also aggree with Sascha that it is somehow important not to rely on the wiki or webpages - thats rather for the publicity. Priority from now on should be on the comments in the new files (because i also have a personal todo list on my laptop related to ojump - which i can now move :o) bon nuit stefan >Michaël > >Sunburned Surveyor a écrit : > > > >>Thanks for taking care of this Stefan. Hopefully Sascha approves! >> >>SS >> >>On 6/2/07, Stefan Steiniger <[EMAIL PROTECTED]> wrote: >> >> >> >> >>>btw. to check the files out in eclipse I used: >>> >>>- cvs repository explorer view >>>- selected the src folder >>>- chosed "checkout as..." from the mouse menu >>>- disabled the "subfolder" checkbox >>>- selected "check out into existing project" >>> >>>- i chosed my openjump project (but i could not remove the folder name >>>"src", thus the change log files will be in that project sub-folder - >>>but a renaming to "changelog" should be possible) >>> >>>stefan >>> >>> >>>Stefan Steiniger schrieb: >>> >>> >>> >>> Hei Guys, i added to the cvs module openjump\src\ three log files. Please check them out to enable a better logging of changes. I hope it is what Sascha expected? stefan PS: i dont know why my eclipse now wants to update the complete openjump\src tree. I hope it is only a problem with my machine and not yours as well. - 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 Expres
Re: [JPP-Devel] new files changelog, changes and todo on CVS
BTW: Why do you hide ChangeLog & Co. in the src folder? Nice place to be overseen. One level up it would be more visual. But I can live with the current place. - Sascha Stefan Steiniger schrieb: > that's pretty cool :) > > Sascha L. Teichmann schrieb: >> Hi together, >> >> I've created a sample ChangeLog [1] for with cvs2cl.pl for >> a fresh anonymous OpenJUMP CVS checkout. Please, have a look >> at it. When committing the BasicStyle patch I would >> like to add this for completeness to the src/ChangeLog. >> After this I recommend to maintain it manually. >> >> the call of cvs2cl.pl was: >> >> cvs2cl.pl --no-times -U emails.txt --show-dead --utc >> >> emails.txt is a map of email addresses I took from >> the JPP list. Spammmers already have these. >> >> Any, comments? >> >> - Sascha >> >> [1] http://intevation.de/~teichmann/printlayout/ChangeLog >> >> >> Stefan Steiniger schrieb: >>> Salut Michael >>> >>> (i currently cant follow the list - to much is going on) >>> >>> 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 ? >>> i hope sascha's answer was sufficient.. i have not used it yet and did >>> look only on the wfs and printplugin files for an example >>> 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 ? >>> i think the todo list in src folder is our personal (devel) thing and we >>> shoudl also add here the improtant bugs that we receive at sourceforge. >>> I also aggree with Sascha that it is somehow important not to rely on >>> the wiki or webpages - thats rather for the publicity. Priority from now >>> on should be on the comments in the new files (because i also have a >>> personal todo list on my laptop related to ojump - which i can now move >>> :o) >>> >>> bon nuit >>> >>> stefan >>> Michaël Sunburned Surveyor a écrit : > Thanks for taking care of this Stefan. Hopefully Sascha approves! > > SS > > On 6/2/07, Stefan Steiniger <[EMAIL PROTECTED]> wrote: > > >> btw. to check the files out in eclipse I used: >> >> - cvs repository explorer view >> - selected the src folder >> - chosed "checkout as..." from the mouse menu >> - disabled the "subfolder" checkbox >> - selected "check out into existing project" >> >> - i chosed my openjump project (but i could not remove the folder name >> "src", thus the change log files will be in that project sub-folder - >> but a renaming to "changelog" should be possible) >> >> stefan >> >> >> Stefan Steiniger schrieb: >> >> >>> Hei Guys, >>> >>> i added to the cvs module openjump\src\ three log files. >>> Please check them out to enable a better logging of changes. >>> >>> I hope it is what Sascha expected? >>> >>> stefan >>> >>> PS: i dont know why my eclipse now wants to update the complete >>> openjump\src tree. I hope it is only a problem with my machine and not >>> yours as well. >>> >>> - >>> 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 > > > > -
[JPP-Devel] [ANN] PrintLayoutPlugin 1.0.1
Hello OpenJUMP users, the development of a new PrintLayout Plugin (replacing the old french-only version) has started in december. Now a bugfix-release of version 1.0.1 is released. Download here: http://sourceforge.net/project/showfiles.php?group_id=118054&package_id=219772&release_id=513623 We thank the funding organisation very much also for this bugfixing release. Of course, many more ideas came up. We hope for even more comments and will collect them in the wishlist of this plugin. Perhaps this motivates for further contributions. Changes: * New: Enable legends for Layerables (WMS) * New: Ability to print transparent maps * New: Enable legends for Layerables (WMS) * New: New factory model for SVG map generation * Fixed: removing some unneeded imports * Fixed: updated i18n-messages, typos fixed * Fixed: make fetching asynchron layers (WMS/DB) more reliably * various cleanups Installing: 1. Copy the printlayout.jar into the lib/ext directory of your OpenJump installation. ATTENTION: The next steps replace existing jar files. Be sure you don't get into trouble when you loose these files. Backups or a separate installation of OpenJump could help here. NOTE: OpenJUMP 1.2b: You don't need to update batik, xml-apis and xml-apis-ext anymore, because the version included in OpenJUMP 1.2b is already sufficient. 2. [OpenJump 1.0] Remove the batik libraries coming with OpenJump and replace them: rm -rf /lib/batik 3. [OpenJump 1.0] Download these jar files and place them into /lib http://jump-pilot.cvs.sourceforge.net/*checkout*/jump-pilot/openjump/lib/batik/batik-all.jar http://jump-pilot.cvs.sourceforge.net/*checkout*/jump-pilot/openjump/lib/xml-apis-ext.jar http://jump-pilot.cvs.sourceforge.net/*checkout*/jump-pilot/openjump/lib/xml-apis.jar 4. [OpenJump 1.0 and 1.2] Download these jar files and place them into /lib/ext http://jump-pilot.cvs.sourceforge.net/*checkout*/jump-pilot/PrintLayoutPlugin/lib/js.jar http://jump-pilot.cvs.sourceforge.net/*checkout*/jump-pilot/PrintLayoutPlugin/lib/pdf-transcoder.jar 5. Only on Windows, likely for OpenJUMP 1.0, maybe for other releases: You need to use the .bat start file and fix CLASSPATH there. The orginal openjump.bat adds all old batik jars to the CLASSPATH explicitly. You have to remove all %LIB%/batik/foobar.jar and add %LIB%/batik-all.jar Have fun and all the 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] new files changelog, changes and todo on CVS
that's pretty cool :) Sascha L. Teichmann schrieb: > Hi together, > > I've created a sample ChangeLog [1] for with cvs2cl.pl for > a fresh anonymous OpenJUMP CVS checkout. Please, have a look > at it. When committing the BasicStyle patch I would > like to add this for completeness to the src/ChangeLog. > After this I recommend to maintain it manually. > > the call of cvs2cl.pl was: > > cvs2cl.pl --no-times -U emails.txt --show-dead --utc > > emails.txt is a map of email addresses I took from > the JPP list. Spammmers already have these. > > Any, comments? > > - Sascha > > [1] http://intevation.de/~teichmann/printlayout/ChangeLog > > > Stefan Steiniger schrieb: >> Salut Michael >> >> (i currently cant follow the list - to much is going on) >> >> 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 ? >> i hope sascha's answer was sufficient.. i have not used it yet and did >> look only on the wfs and printplugin files for an example >> >>> 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 ? >> i think the todo list in src folder is our personal (devel) thing and we >> shoudl also add here the improtant bugs that we receive at sourceforge. >> I also aggree with Sascha that it is somehow important not to rely on >> the wiki or webpages - thats rather for the publicity. Priority from now >> on should be on the comments in the new files (because i also have a >> personal todo list on my laptop related to ojump - which i can now move >> :o) >> >> bon nuit >> >> stefan >> >>> Michaël >>> >>> Sunburned Surveyor a écrit : >>> Thanks for taking care of this Stefan. Hopefully Sascha approves! SS On 6/2/07, Stefan Steiniger <[EMAIL PROTECTED]> wrote: > btw. to check the files out in eclipse I used: > > - cvs repository explorer view > - selected the src folder > - chosed "checkout as..." from the mouse menu > - disabled the "subfolder" checkbox > - selected "check out into existing project" > > - i chosed my openjump project (but i could not remove the folder name > "src", thus the change log files will be in that project sub-folder - > but a renaming to "changelog" should be possible) > > stefan > > > Stefan Steiniger schrieb: > > >> Hei Guys, >> >> i added to the cvs module openjump\src\ three log files. >> Please check them out to enable a better logging of changes. >> >> I hope it is what Sascha expected? >> >> stefan >> >> PS: i dont know why my eclipse now wants to update the complete >> openjump\src tree. I hope it is only a problem with my machine and not >> yours as well. >> >> - >> This SF.net email is sponsored by DB2 Express >> Download DB2 Express C - the FREE version of DB2 express and take >> control of your XML. No limits. Just data. Click to get it now. >> http://sourceforge.net/powerbar/db2/ >> ___ >> Jump-pilot-devel mailing list >> Jump-pilot-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >> >> >> >> > - > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > ___ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > > - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>> - >>> This SF.net email is sponsored by DB2 Express >>> Download DB2 Express C - the FREE version of DB2 express and take >>> control of your XML. No limits. Just data. Click to get it now. >>> http://sourceforge.net/powerbar/db2/ >>> ___ >>> Jump-pilot-devel mailing list >>
Re: [JPP-Devel] new files changelog, changes and todo on CVS
Hi together, I've created a sample ChangeLog [1] for with cvs2cl.pl for a fresh anonymous OpenJUMP CVS checkout. Please, have a look at it. When committing the BasicStyle patch I would like to add this for completeness to the src/ChangeLog. After this I recommend to maintain it manually. the call of cvs2cl.pl was: cvs2cl.pl --no-times -U emails.txt --show-dead --utc emails.txt is a map of email addresses I took from the JPP list. Spammmers already have these. Any, comments? - Sascha [1] http://intevation.de/~teichmann/printlayout/ChangeLog Stefan Steiniger schrieb: > Salut Michael > > (i currently cant follow the list - to much is going on) > > 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 ? > i hope sascha's answer was sufficient.. i have not used it yet and did > look only on the wfs and printplugin files for an example > >> 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 ? > > i think the todo list in src folder is our personal (devel) thing and we > shoudl also add here the improtant bugs that we receive at sourceforge. > I also aggree with Sascha that it is somehow important not to rely on > the wiki or webpages - thats rather for the publicity. Priority from now > on should be on the comments in the new files (because i also have a > personal todo list on my laptop related to ojump - which i can now move > :o) > > bon nuit > > stefan > >> Michaël >> >> Sunburned Surveyor a écrit : >> >>> Thanks for taking care of this Stefan. Hopefully Sascha approves! >>> >>> SS >>> >>> On 6/2/07, Stefan Steiniger <[EMAIL PROTECTED]> wrote: >>> >>> btw. to check the files out in eclipse I used: - cvs repository explorer view - selected the src folder - chosed "checkout as..." from the mouse menu - disabled the "subfolder" checkbox - selected "check out into existing project" - i chosed my openjump project (but i could not remove the folder name "src", thus the change log files will be in that project sub-folder - but a renaming to "changelog" should be possible) stefan Stefan Steiniger schrieb: > Hei Guys, > > i added to the cvs module openjump\src\ three log files. > Please check them out to enable a better logging of changes. > > I hope it is what Sascha expected? > > stefan > > PS: i dont know why my eclipse now wants to update the complete > openjump\src tree. I hope it is only a problem with my machine and not > yours as well. > > - > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > ___ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > > > - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>> - >>> This SF.net email is sponsored by DB2 Express >>> Download DB2 Express C - the FREE version of DB2 express and take >>> control of your XML. No limits. Just data. Click to get it now. >>> http://sourceforge.net/powerbar/db2/ >>> ___ >>> Jump-pilot-devel mailing list >>> Jump-pilot-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>> >>> >>> >>> >> >> - >> This SF.net email is sponsored by DB2 Express >> Download DB2 Express C - the FREE version of DB2 express and take >> control of your XML. No limits. Just data. Click to get it now. >> http://sourceforge.net/powerbar/db2/ >> ___ >> Jump-pilot-devel mailing list >> Jump-pilot-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >> >> > > - > This SF.n
