I may have a little something to add to this discussion, although I don't know how helpful it would be. :]
A while back a company had hired me to do some work on one of the PostGIS Drivers. It sounds like they wanted something related to what Paul and Larry are discussing. They wanted to be able to refresh all Layers in a JUMP project that had been created from data stored in a PostGIS database. Paul had said that: "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." I guess my approach was a little different, but with the same end result. I came up with a class that allowed "association" of multiple Layers with a DataSource. I imagined that this association would be managed through a catalog of DataSources. For example, the user could select a datasource in the catalog, and then choose to perform an action on all of the Layers associated with that DataSource. An example would be to refresh all Layers associated with a DataSource, or delete all Layers associated with a DataSource, or turn off all Layers associated with a DataSource. The design incorporated interfaces, so you could implement custom refresh logic in a DataSource-Layer association, for example. I don't know if the concept of "associating" Layers and DataSources is better than that of DataSources "containing" Layers, but I thought I would throw it out there. It seemed more logical to me since, for example, you can create a Layer in OpenJUMP that has nothing to do with a DataSource. You could also import the same DataSource as different Layers. These behavior led me to view the DataSource-Layer relationship as less concrete that "DataSources contain Layers". But what do I know? I'm just a rookie. :] The Sunburned Surveyor P.S. - One of these days I think that we will logically have a mechanism like a catalog to manage data sources in OpenJUMP. On 5/29/07, Larry Becker <[EMAIL PROTECTED]> wrote: > Paul, > > The issue we are having with DataStore is that precisely what you > are referring to. Each layer is trying to do its own connection in a > separate thread to the server and Oracle is running out of > connections. Some kind of connection pooling would probably solve > this problem, but we haven't been focused on it for a while. It would > probably require some changes to the DataStore class and I wasn't sure > Vivid Solutions was finished with it yet. > > The connection information is persisted in workbench-state.xml > through the standard workbench blackboard method. > > Regarding the metadata list of layers concept, I basically felt that > that was a .jmp file and didn't see a need to reinvent it. Merge > Task/Archive just allows you to open multiple task files in the same > project. > > regards, > Larry > On 5/29/07, Paul Austin <[EMAIL PROTECTED]> wrote: > > > > Hi Larry, > > > > I've just downloaded SkyJump and seen how the DataStores work and it looks > > as if it is roughly what I'm looking for. > > > > I notice that when you save the Project to a .jmp file that the connection > > information is duplicated for each layer. Does this mean that each layer > > will connect directly to the database or do all the layers share a > > connection from the connection manager. What would be nice is if this > > information could be stored only once and referenced from the other layers. > > > > I see that the connection manager is preserved in the SkyJUMP installation, > > where is this information stored in a windows install. > > > > Any idea when these plug-ins will be rolled into the OpenJUMP release I see > > there is a difference in the version they have. > > > > For the file based concepts I was talking about, the list of layers is > > defined in the metadata file so what I'd want to do is point it at the > > directory then my plugin would generate the list of layers from the metadata > > instead of the files. So this is slightly different from the usual just > > selecting a bunch of files from a directory. > > > > I'm going to for now do an import of the "zip" based file type I have using > > your MergeProjectPlugin as an example, ultimately I'd like to be able to > > have it read directly from the file, but I think that may require some extra > > resource management. > > > > Cheers, > > Paul > > > > > > > > Larry Becker wrote: > > Hi Paul, > > > > As usual, you are interested in many of the same things that I am. > > The single DataSource multiple layer concept is currently only > > implemented in WMS and MrSID (which is based on WMSLayer) and you > > actually end up with only a single layer in JUMP, but you can manage > > it as multiples. > > > > SkyJUMP has implemented the zip file with multiple layers as Merge > > Task/Archive. It works much as you propose and even supports writing > > back to the zip file with Save Selected Datasets. Loading multiple > > files at one time is already supported in JUMP unless I don't > > understand your concept. > > > > For databases we also have ArcSDE support which allows browsing and > > loading multiple layers at once. > > > > We also support the DataStore concept in JUMP, but have had > > concurrency issues with it. > > > > regards, > > Larry > > > > On 5/29/07, Paul Austin <[EMAIL PROTECTED]> wrote: > > > > > > 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.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 > > > > > > > -- > http://amusingprogrammer.blogspot.com/ > > ------------------------------------------------------------------------- > 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
