Re: [JPP-Devel] Writing Openjump Help (Giuseppe Aruta)
Thanks SS, I think I wait for the template on Source forge. By Giuseppe ___ L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Progress on OpenJUMP CVS Unstable Branch
Sunburned Surveyor wrote: Hello, to the SVN. If you don't have write access currently but would like to get it, now would be a good time to speak up. in that case I would like to speak up ;-) I was already busy making some changes to the WFS-Plugin (fixed the Schema issue). So if nobody has any objections? Best regards, Andreas -- l a t / l o n GmbH Aennchenstrasse 19 53177 Bonn, Germany phone ++49 +228 18496-11 fax ++49 +228 1849629 http://www.lat-lon.dehttp://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] Progress on OpenJUMP CVS Unstable Branch
SS, OK, sign me up for write access too. Since our SkyJUMP work is mostly complete, I'll try to find some time at home to port over some of our more popular improvements. regards, Larry Becker On 6/12/07, Andreas Schmitz [EMAIL PROTECTED] wrote: Sunburned Surveyor wrote: Hello, to the SVN. If you don't have write access currently but would like to get it, now would be a good time to speak up. in that case I would like to speak up ;-) I was already busy making some changes to the WFS-Plugin (fixed the Schema issue). So if nobody has any objections? Best regards, Andreas -- l a t / l o n GmbH Aennchenstrasse 19 53177 Bonn, Germany phone ++49 +228 18496-11 fax ++49 +228 1849629 http://www.lat-lon.dehttp://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 -- 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
Re: [JPP-Devel] Progress on OpenJUMP CVS Unstable Branch
I don't think anyone will have a problem giving Larry or Andreas write access to the SVN repository. If there are no objections I will take care of this when I set up the SVN. (I'm hoping I can take care of this today after work.) SS On 6/12/07, Michaël Michaud [EMAIL PROTECTED] wrote: Hey, good new again :-) , As you know, I have started to backport some of your excellent improvements, but I hardly find time to backport all of them... Michaël Larry Becker a écrit : SS, OK, sign me up for write access too. Since our SkyJUMP work is mostly complete, I'll try to find some time at home to port over some of our more popular improvements. regards, Larry Becker On 6/12/07, Andreas Schmitz [EMAIL PROTECTED] wrote: Sunburned Surveyor wrote: Hello, to the SVN. If you don't have write access currently but would like to get it, now would be a good time to speak up. in that case I would like to speak up ;-) I was already busy making some changes to the WFS-Plugin (fixed the Schema issue). So if nobody has any objections? Best regards, Andreas -- l a t / l o n GmbH Aennchenstrasse 19 53177 Bonn, Germany phone ++49 +228 18496-11 fax ++49 +228 1849629 http://www.lat-lon.dehttp://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 - 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, Does anybody know how windows users are supposed to patch those kind of diff files ? I only find one java lib claiming to do that (jpatchlib), but development is ongoing and it is not yet very user friendly (no gui, no jar, no build, only .java) ? Michaël Paul Index: src/org/openjump/OpenJumpConfiguration.java === RCS file: /cvsroot/jump-pilot/openjump/src/org/openjump/OpenJumpConfiguration.java,v retrieving revision 1.42 diff -u -r1.42 OpenJumpConfiguration.java --- src/org/openjump/OpenJumpConfiguration.java24 Mar 2007 12:27:45 - 1.42 +++ src/org/openjump/OpenJumpConfiguration.java11 Jun 2007 19:26:47 - @@ -10,10 +10,16 @@ */ package org.openjump; -import javax.swing.JMenu; +import java.util.Date; + import javax.swing.JPopupMenu; import org.openjump.core.ccordsys.srid.EnsureAllLayersHaveSRIDStylePlugIn; +import org.openjump.core.ui.builder.DateTimeUiBuilder; +import org.openjump.core.ui.builder.DateUIBuilder; +import org.openjump.core.ui.builder.FeatureUiBuilder; +import org.openjump.core.ui.builder.UiBuilderRegistry; +import org.openjump.core.ui.component.InfoModelDetailPanel; import org.openjump.core.ui.plugin.customize.BeanToolsPlugIn; import org.openjump.core.ui.plugin.edit.ReplicateSelectedItemsPlugIn; import org.openjump.core.ui.plugin.edit.SelectAllLayerItemsPlugIn; @@ -54,19 +60,19 @@ import org.openjump.core.ui.plugin.view.ShowScalePlugIn; import org.openjump.core.ui.plugin.view.ZoomToScalePlugIn; import org.openjump.core.ui.plugin.wms.ZoomToWMSPlugIn; +import org.openjump.core.ui.style.decoration.ArrowLineStringMiddlepointStyle; import org.openjump.sigle.plugin.geoprocessing.layers.SpatialJoinPlugIn; import org.openjump.sigle.plugin.geoprocessing.oneLayer.topology.PlanarGraphPlugIn; import org.openjump.sigle.plugin.joinTable.JoinTablePlugIn; import org.openjump.sigle.plugin.replace.ReplaceValuePlugIn; -import org.openjump.core.ui.style.decoration.ArrowLineStringMiddlepointStyle; - +import com.vividsolutions.jump.feature.Feature; import com.vividsolutions.jump.workbench.WorkbenchContext; import com.vividsolutions.jump.workbench.plugin.PlugInContext; +import com.vividsolutions.jump.workbench.ui.InfoFrame; import com.vividsolutions.jump.workbench.ui.LayerViewPanel; -import com.vividsolutions.jump.workbench.ui.MenuNames; -import com.vividsolutions.jump.workbench.ui.plugin.FeatureInstaller; import com.vividsolutions.jump.workbench.ui.plugin.BeanShellPlugIn; +import com.vividsolutions.jump.workbench.ui.swing.ComponentFactoryRegistry; import de.fho.jump.pirol.plugins.EditAttributeByFormula.EditAttributeByFormulaPlugIn; import de.latlon.deejump.plugin.SaveLegendPlugIn; @@ -360,5 +366,17 @@ projectionPlugin.initialize(new PlugInContext(workbenchContext, null, null, null, null)); */ +/** + * UI Builders + **/ +UiBuilderRegistry htmlrendererRepository = UiBuilderRegistry.getInstance(workbenchContext); +htmlrendererRepository.addRenderer(Feature.class, new FeatureUiBuilder()); +htmlrendererRepository.addRenderer(Date.class, new DateTimeUiBuilder()); +htmlrendererRepository.addRenderer(java.sql.Date.class, new DateUIBuilder()); + +/*** + * Info Frame Panels + **/ +ComponentFactoryRegistry.addComponentFactory(workbenchContext, InfoFrame.CLASSIFICATION, InfoModelDetailPanel.class); } } Index: src/com/vividsolutions/jump/workbench/ui/InfoFrame.java === RCS file: /cvsroot/jump-pilot/openjump/src/com/vividsolutions/jump/workbench/ui/InfoFrame.java,v retrieving revision 1.3 diff -u -r1.3 InfoFrame.java --- src/com/vividsolutions/jump/workbench/ui/InfoFrame.java3 Jun 2007 20:53:31 - 1.3 +++ src/com/vividsolutions/jump/workbench/ui/InfoFrame.java11 Jun 2007 19:26:46 - @@ -30,159 +30,201 @@ * www.vividsolutions.com */ package com.vividsolutions.jump.workbench.ui; + import java.awt.BorderLayout; +import java.util.Iterator; +import java.util.List; + +import javax.swing.JComponent; import javax.swing.JInternalFrame; import javax.swing.JPanel; import javax.swing.JTabbedPane; import javax.swing.event.InternalFrameAdapter; import javax.swing.event.InternalFrameEvent; + import com.vividsolutions.jts.util.Assert; import com.vividsolutions.jump.I18N; import com.vividsolutions.jump.workbench.WorkbenchContext; import com.vividsolutions.jump.workbench.model.LayerManager; import com.vividsolutions.jump.workbench.model.LayerManagerProxy; import com.vividsolutions.jump.workbench.model.Task; -import com.vividsolutions.jump.workbench.ui.cursortool.editing.EditingPlugIn; +import com.vividsolutions.jump.workbench.registry.Registry; import
Re: [JPP-Devel] named FeatureSchema
for me you posts get even more complicated. ;) but what i like to say is (although i don't want to weak up sleeping dogs), that i don't realy see a point against a name for a feature collection if it is not a compulsory property that must be set. At least i don't see how it could harm the current implementation (???) But on the other hand i know that Larry and Martin are the wise guys here and that project driven devleopment is rather bad for a clean architecture. (just a note to explain why i always consult Larry on devel things, is that i would like to have more or less Skyjump in sync with OJ) stefan Martin Davis schrieb: I think that FeatureSchema instances would be local to the data source used to load the layer (e.g. file or database connection), within the scope of that names should be unique. Hmm... seems to me this would then require all code that depended on name uniqueness to then be aware of the DataSource of the FeatureSchema - which isn't currently provided in the schema, and might be fiddly to check. Perhaps the data source could be used to generate a unique namespace (as a String). Yup, this is getting complicated. - 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] Progress on OpenJUMP CVS Unstable Branch
btw. Sunburned.. don't forget to give yourself write access to the SVN (apart from Steve, your the only one who does not have yet ;) I have added Larry to the developer list and Andreas still needs to provide his name. stefan Sunburned Surveyor schrieb: I don't think anyone will have a problem giving Larry or Andreas write access to the SVN repository. If there are no objections I will take care of this when I set up the SVN. (I'm hoping I can take care of this today after work.) SS On 6/12/07, Michaël Michaud [EMAIL PROTECTED] wrote: Hey, good new again :-) , As you know, I have started to backport some of your excellent improvements, but I hardly find time to backport all of them... Michaël Larry Becker a écrit : SS, OK, sign me up for write access too. Since our SkyJUMP work is mostly complete, I'll try to find some time at home to port over some of our more popular improvements. regards, Larry Becker On 6/12/07, Andreas Schmitz [EMAIL PROTECTED] wrote: Sunburned Surveyor wrote: Hello, to the SVN. If you don't have write access currently but would like to get it, now would be a good time to speak up. in that case I would like to speak up ;-) I was already busy making some changes to the WFS-Plugin (fixed the Schema issue). So if nobody has any objections? Best regards, Andreas -- l a t / l o n GmbH Aennchenstrasse 19 53177 Bonn, Germany phone ++49 +228 18496-11 fax ++49 +228 1849629 http://www.lat-lon.dehttp://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 - 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] named FeatureSchema
I must weigh in with Paul on this one guys. I see a lot of potential uses for uniquely identifying FeatureSchemas. I guess that I would call this a FeatureType. If you are curious about the applications of defining and uniquely identifying FeatureTypes just take a look at the ESRI Geodatabase. (For example, FeatureTypes would allow you to specify a range of allowed values for an attribute.) I believe in ESRI FeatureTypes are called FeatureClasses. I also don't think that it is unreasonable to specify that an OpenJUMP project contain no duplicate FeatureTypes. However, I do see that we allow Layers to have the same name, which I think is a bad thing... I guess that I never noticed this before. Martin wrote: This all seems like a lot of extra complexity to support something that at the moment is really only your own use case. Perhaps you should publish this as a plugin for now, and if it gets used a lot then the JUMP project can think about incorporating it in the core. I would agree with Martin on this point. I don't think it would be to difficult to encapsulate a system for uniquely identifying FeatureSchema's in a plug-in. You'd could automatically add the Layer name (as the unique ID for the FeatureSchema) and a reference to the FeatureSchema for a FeatureCollection to a HashMap in the plug-in. If the user tried to create a Layer with a duplicate name you could create an error message. Or you could prompt the user to enter a name for a FeatureSchema when creating a layer, although this might be more confusing for them. I think the best solution would be to allow users to assign a unique FeatureType or FeatureSchema to the Layers that they select (after the Layers had been created, of course). That way we aren't forcing this on users that have no need for it. You could capture the relationship between the FeatureSchema, Layer, and unique FeatureSchema indentification at the time that the user made the association. If you want it to be really easy you could automatically fill the unique id text box with the name of the Layer that the user selected for the association. That would solve your reflection problem. You would never need to ask a FeatureSchema if it had a unique name. You could just see if there was a unique id associated with the instance of FeatureSchema by asking the plug-in. If Paul think's he would be interested in doing something with FeatureTypes or uniquely identified FeatureSchemas via a plug-in I'd be interested in the design, as I think this really is something that I will want to tap into in the future. 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] Progress on OpenJUMP CVS Unstable Branch
Roger that Stefan. Did you already take care of the SVN set-up? If you have, that is great! SS On 6/12/07, Stefan Steiniger [EMAIL PROTECTED] wrote: btw. Sunburned.. don't forget to give yourself write access to the SVN (apart from Steve, your the only one who does not have yet ;) I have added Larry to the developer list and Andreas still needs to provide his name. stefan Sunburned Surveyor schrieb: I don't think anyone will have a problem giving Larry or Andreas write access to the SVN repository. If there are no objections I will take care of this when I set up the SVN. (I'm hoping I can take care of this today after work.) SS On 6/12/07, Michaël Michaud [EMAIL PROTECTED] wrote: Hey, good new again :-) , As you know, I have started to backport some of your excellent improvements, but I hardly find time to backport all of them... Michaël Larry Becker a écrit : SS, OK, sign me up for write access too. Since our SkyJUMP work is mostly complete, I'll try to find some time at home to port over some of our more popular improvements. regards, Larry Becker On 6/12/07, Andreas Schmitz [EMAIL PROTECTED] wrote: Sunburned Surveyor wrote: Hello, to the SVN. If you don't have write access currently but would like to get it, now would be a good time to speak up. in that case I would like to speak up ;-) I was already busy making some changes to the WFS-Plugin (fixed the Schema issue). So if nobody has any objections? Best regards, Andreas -- l a t / l o n GmbH Aennchenstrasse 19 53177 Bonn, Germany phone ++49 +228 18496-11 fax ++49 +228 1849629 http://www.lat-lon.dehttp://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 - 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] named FeatureSchema
I would disagree on the point about not allowing two layers with the same name in a Project. Consider the case where you load in two Multi-Layer files for different mapsheets, each one of them may have a road layer. I would make the restriction that within a category you can't have two layers with the same name. In my case I make the file into a category and have the layers for that file below it. 92g044 - Road - River 92g043 - Road - River Paul Sunburned Surveyor wrote: I must weigh in with Paul on this one guys. I see a lot of potential uses for uniquely identifying FeatureSchemas. I guess that I would call this a FeatureType. If you are curious about the applications of defining and uniquely identifying FeatureTypes just take a look at the ESRI Geodatabase. (For example, FeatureTypes would allow you to specify a range of allowed values for an attribute.) I believe in ESRI FeatureTypes are called FeatureClasses. I also don't think that it is unreasonable to specify that an OpenJUMP project contain no duplicate FeatureTypes. However, I do see that we allow Layers to have the same name, which I think is a bad thing... I guess that I never noticed this before. Martin wrote: This all seems like a lot of extra complexity to support something that at the moment is really only your own use case. Perhaps you should publish this as a plugin for now, and if it gets used a lot then the JUMP project can think about incorporating it in the core. I would agree with Martin on this point. I don't think it would be to difficult to encapsulate a system for uniquely identifying FeatureSchema's in a plug-in. You'd could automatically add the Layer name (as the unique ID for the FeatureSchema) and a reference to the FeatureSchema for a FeatureCollection to a HashMap in the plug-in. If the user tried to create a Layer with a duplicate name you could create an error message. Or you could prompt the user to enter a name for a FeatureSchema when creating a layer, although this might be more confusing for them. I think the best solution would be to allow users to assign a unique FeatureType or FeatureSchema to the Layers that they select (after the Layers had been created, of course). That way we aren't forcing this on users that have no need for it. You could capture the relationship between the FeatureSchema, Layer, and unique FeatureSchema indentification at the time that the user made the association. If you want it to be really easy you could automatically fill the unique id text box with the name of the Layer that the user selected for the association. That would solve your reflection problem. You would never need to ask a FeatureSchema if it had a unique name. You could just see if there was a unique id associated with the instance of FeatureSchema by asking the plug-in. If Paul think's he would be interested in doing something with FeatureTypes or uniquely identified FeatureSchemas via a plug-in I'd be interested in the design, as I think this really is something that I will want to tap into in the future. 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
Re: [JPP-Devel] named FeatureSchema
mhm.. i dont realy understand are we talking about a featureType or a FeatureSchema-Name. The first is (as far as i remember) used by Pirol.. if somebody wants to have a look on it.. for images, trianguations or so? .. see PirolFeatureCollectionRoleTypes.java I found the idea quite useful. But somebody need to maintain such a list. @Paul what also comes to my mind. Jon developed the SRID plugin (attached to postgis) which registers for every layer a SRID. Maybe this example can help you for your custom development? Sunburned Surveyor schrieb: I must weigh in with Paul on this one guys. I see a lot of potential uses for uniquely identifying FeatureSchemas. I guess that I would call this a FeatureType. If you are curious about the applications of defining and uniquely identifying FeatureTypes just take a look at the ESRI Geodatabase. (For example, FeatureTypes would allow you to specify a range of allowed values for an attribute.) I believe in ESRI FeatureTypes are called FeatureClasses. I also don't think that it is unreasonable to specify that an OpenJUMP project contain no duplicate FeatureTypes. However, I do see that we allow Layers to have the same name, which I think is a bad thing... I guess that I never noticed this before. Martin wrote: This all seems like a lot of extra complexity to support something that at the moment is really only your own use case. Perhaps you should publish this as a plugin for now, and if it gets used a lot then the JUMP project can think about incorporating it in the core. I would agree with Martin on this point. I don't think it would be to difficult to encapsulate a system for uniquely identifying FeatureSchema's in a plug-in. You'd could automatically add the Layer name (as the unique ID for the FeatureSchema) and a reference to the FeatureSchema for a FeatureCollection to a HashMap in the plug-in. If the user tried to create a Layer with a duplicate name you could create an error message. Or you could prompt the user to enter a name for a FeatureSchema when creating a layer, although this might be more confusing for them. I think the best solution would be to allow users to assign a unique FeatureType or FeatureSchema to the Layers that they select (after the Layers had been created, of course). That way we aren't forcing this on users that have no need for it. You could capture the relationship between the FeatureSchema, Layer, and unique FeatureSchema indentification at the time that the user made the association. If you want it to be really easy you could automatically fill the unique id text box with the name of the Layer that the user selected for the association. That would solve your reflection problem. You would never need to ask a FeatureSchema if it had a unique name. You could just see if there was a unique id associated with the instance of FeatureSchema by asking the plug-in. If Paul think's he would be interested in doing something with FeatureTypes or uniquely identified FeatureSchemas via a plug-in I'd be interested in the design, as I think this really is something that I will want to tap into in the future. 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
Re: [JPP-Devel] Progress on OpenJUMP CVS Unstable Branch
Sunburned Surveyor schrieb: Roger that Stefan. Did you already take care of the SVN set-up? If you have, that is great! nope.. because this requires some reading SS On 6/12/07, Stefan Steiniger [EMAIL PROTECTED] wrote: btw. Sunburned.. don't forget to give yourself write access to the SVN (apart from Steve, your the only one who does not have yet ;) I have added Larry to the developer list and Andreas still needs to provide his name. stefan Sunburned Surveyor schrieb: I don't think anyone will have a problem giving Larry or Andreas write access to the SVN repository. If there are no objections I will take care of this when I set up the SVN. (I'm hoping I can take care of this today after work.) SS On 6/12/07, Michaël Michaud [EMAIL PROTECTED] wrote: Hey, good new again :-) , As you know, I have started to backport some of your excellent improvements, but I hardly find time to backport all of them... Michaël Larry Becker a écrit : SS, OK, sign me up for write access too. Since our SkyJUMP work is mostly complete, I'll try to find some time at home to port over some of our more popular improvements. regards, Larry Becker On 6/12/07, Andreas Schmitz [EMAIL PROTECTED] wrote: Sunburned Surveyor wrote: Hello, to the SVN. If you don't have write access currently but would like to get it, now would be a good time to speak up. in that case I would like to speak up ;-) I was already busy making some changes to the WFS-Plugin (fixed the Schema issue). So if nobody has any objections? Best regards, Andreas -- l a t / l o n GmbH Aennchenstrasse 19 53177 Bonn, Germany phone ++49 +228 18496-11 fax ++49 +228 1849629 http://www.lat-lon.dehttp://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 - 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
Re: [JPP-Devel] named FeatureSchema
So how do you disambiguate these layers in plugin dropdowns which show layer names? Paul Austin wrote: I would disagree on the point about not allowing two layers with the same name in a Project. Consider the case where you load in two Multi-Layer files for different mapsheets, each one of them may have a road layer. I would make the restriction that within a category you can't have two layers with the same name. In my case I make the file into a category and have the layers for that file below it. 92g044 - Road - River 92g043 - Road - River Paul Sunburned Surveyor wrote: I must weigh in with Paul on this one guys. I see a lot of potential uses for uniquely identifying FeatureSchemas. I guess that I would call this a FeatureType. If you are curious about the applications of defining and uniquely identifying FeatureTypes just take a look at the ESRI Geodatabase. (For example, FeatureTypes would allow you to specify a range of allowed values for an attribute.) I believe in ESRI FeatureTypes are called FeatureClasses. I also don't think that it is unreasonable to specify that an OpenJUMP project contain no duplicate FeatureTypes. However, I do see that we allow Layers to have the same name, which I think is a bad thing... I guess that I never noticed this before. Martin wrote: This all seems like a lot of extra complexity to support something that at the moment is really only your own use case. Perhaps you should publish this as a plugin for now, and if it gets used a lot then the JUMP project can think about incorporating it in the core. I would agree with Martin on this point. I don't think it would be to difficult to encapsulate a system for uniquely identifying FeatureSchema's in a plug-in. You'd could automatically add the Layer name (as the unique ID for the FeatureSchema) and a reference to the FeatureSchema for a FeatureCollection to a HashMap in the plug-in. If the user tried to create a Layer with a duplicate name you could create an error message. Or you could prompt the user to enter a name for a FeatureSchema when creating a layer, although this might be more confusing for them. I think the best solution would be to allow users to assign a unique FeatureType or FeatureSchema to the Layers that they select (after the Layers had been created, of course). That way we aren't forcing this on users that have no need for it. You could capture the relationship between the FeatureSchema, Layer, and unique FeatureSchema indentification at the time that the user made the association. If you want it to be really easy you could automatically fill the unique id text box with the name of the Layer that the user selected for the association. That would solve your reflection problem. You would never need to ask a FeatureSchema if it had a unique name. You could just see if there was a unique id associated with the instance of FeatureSchema by asking the plug-in. If Paul think's he would be interested in doing something with FeatureTypes or uniquely identified FeatureSchemas via a plug-in I'd be interested in the design, as I think this really is something that I will want to tap into in the future. 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 -- 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] named FeatureSchema
FeatureType seems like a good name for this. It does seem like this could be added without too much risk right now, with very little semantics or functionality around it (other than what Paul is presumably building). I guess if there's a real need for this functionality it will become obvious as people ask for more functionality exposed for it. I'm just a bit worried that this whole area in general has no very clear model to follow. Every system seems to do something a bit different. If there's no initial overall vision of where this is going, we risk building off in directions which are very hard to corral back later. It would be nice to pick an existing model and follow or extend it. Maybe the Geodatabase model is a good one to look at. They certainly follow the relational paradigm pretty closely, which will make Landon happy 8^) Me too, actually - I don't have anything against the relational paradigm, and it's certainly a lot more battle-hardened than the object DBMS world. Sunburned Surveyor wrote: I must weigh in with Paul on this one guys. I see a lot of potential uses for uniquely identifying FeatureSchemas. I guess that I would call this a FeatureType. If you are curious about the applications of defining and uniquely identifying FeatureTypes just take a look at the ESRI Geodatabase. (For example, FeatureTypes would allow you to specify a range of allowed values for an attribute.) I believe in ESRI FeatureTypes are called FeatureClasses. I also don't think that it is unreasonable to specify that an OpenJUMP project contain no duplicate FeatureTypes. However, I do see that we allow Layers to have the same name, which I think is a bad thing... I guess that I never noticed this before. Martin wrote: This all seems like a lot of extra complexity to support something that at the moment is really only your own use case. Perhaps you should publish this as a plugin for now, and if it gets used a lot then the JUMP project can think about incorporating it in the core. I would agree with Martin on this point. I don't think it would be to difficult to encapsulate a system for uniquely identifying FeatureSchema's in a plug-in. You'd could automatically add the Layer name (as the unique ID for the FeatureSchema) and a reference to the FeatureSchema for a FeatureCollection to a HashMap in the plug-in. If the user tried to create a Layer with a duplicate name you could create an error message. Or you could prompt the user to enter a name for a FeatureSchema when creating a layer, although this might be more confusing for them. I think the best solution would be to allow users to assign a unique FeatureType or FeatureSchema to the Layers that they select (after the Layers had been created, of course). That way we aren't forcing this on users that have no need for it. You could capture the relationship between the FeatureSchema, Layer, and unique FeatureSchema indentification at the time that the user made the association. If you want it to be really easy you could automatically fill the unique id text box with the name of the Layer that the user selected for the association. That would solve your reflection problem. You would never need to ask a FeatureSchema if it had a unique name. You could just see if there was a unique id associated with the instance of FeatureSchema by asking the plug-in. If Paul think's he would be interested in doing something with FeatureTypes or uniquely identified FeatureSchemas via a plug-in I'd be interested in the design, as I think this really is something that I will want to tap into in the future. 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 -- 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] named FeatureSchema
I've been thinking about this, and now I am really confused! I think I can summarize my confusion by saying this: I don't think we will need to introduce a uniquely identified FeatureSchema and/or a FeatureType if we introduce a restriction for unique Layers. (Or at least a way to associate a unique identifier with Layers.) I can associate any type or constraint or restriction on a uniquely identified Layer as easily as I can a uniquely identified FeatureSchema. After thinking about it I believe that it is better to work with Layer objects than it is FeatureSchema objects. This is because we don't expose FeatureCollections or FeatureSchemas to the user at this point. We expose Layers. A user won't want to apply a attribute value range or other constraint to a FeatureSchema, they'll want to apply it to a Layer. If I'm a user that doesn't subscribe to this list I don't even know that FeatueSchemas and FeatureCollections exist. I say we keep it that way. The only downfall that I can think of to this system is that If a programmer is interested in using OpenJUMP's feature model as a library in an external program, but doesn't want to use Layers they won't have the control we are talking about. Maybe Paul has some reasons why this won't work in his situation. The Sunburned Surveyor On 6/12/07, Martin Davis [EMAIL PROTECTED] wrote: FeatureType seems like a good name for this. It does seem like this could be added without too much risk right now, with very little semantics or functionality around it (other than what Paul is presumably building). I guess if there's a real need for this functionality it will become obvious as people ask for more functionality exposed for it. I'm just a bit worried that this whole area in general has no very clear model to follow. Every system seems to do something a bit different. If there's no initial overall vision of where this is going, we risk building off in directions which are very hard to corral back later. It would be nice to pick an existing model and follow or extend it. Maybe the Geodatabase model is a good one to look at. They certainly follow the relational paradigm pretty closely, which will make Landon happy 8^) Me too, actually - I don't have anything against the relational paradigm, and it's certainly a lot more battle-hardened than the object DBMS world. Sunburned Surveyor wrote: I must weigh in with Paul on this one guys. I see a lot of potential uses for uniquely identifying FeatureSchemas. I guess that I would call this a FeatureType. If you are curious about the applications of defining and uniquely identifying FeatureTypes just take a look at the ESRI Geodatabase. (For example, FeatureTypes would allow you to specify a range of allowed values for an attribute.) I believe in ESRI FeatureTypes are called FeatureClasses. I also don't think that it is unreasonable to specify that an OpenJUMP project contain no duplicate FeatureTypes. However, I do see that we allow Layers to have the same name, which I think is a bad thing... I guess that I never noticed this before. Martin wrote: This all seems like a lot of extra complexity to support something that at the moment is really only your own use case. Perhaps you should publish this as a plugin for now, and if it gets used a lot then the JUMP project can think about incorporating it in the core. I would agree with Martin on this point. I don't think it would be to difficult to encapsulate a system for uniquely identifying FeatureSchema's in a plug-in. You'd could automatically add the Layer name (as the unique ID for the FeatureSchema) and a reference to the FeatureSchema for a FeatureCollection to a HashMap in the plug-in. If the user tried to create a Layer with a duplicate name you could create an error message. Or you could prompt the user to enter a name for a FeatureSchema when creating a layer, although this might be more confusing for them. I think the best solution would be to allow users to assign a unique FeatureType or FeatureSchema to the Layers that they select (after the Layers had been created, of course). That way we aren't forcing this on users that have no need for it. You could capture the relationship between the FeatureSchema, Layer, and unique FeatureSchema indentification at the time that the user made the association. If you want it to be really easy you could automatically fill the unique id text box with the name of the Layer that the user selected for the association. That would solve your reflection problem. You would never need to ask a FeatureSchema if it had a unique name. You could just see if there was a unique id associated with the instance of FeatureSchema by asking the plug-in. If Paul think's he would be interested in doing something with FeatureTypes or uniquely identified FeatureSchemas via a plug-in I'd be interested in the design, as I think
Re: [JPP-Devel] named FeatureSchema
Martin wrote: They certainly follow the relational paradigm pretty closely, which will make Landon happy 8^) Me too, actually - I don't have anything against the relational paradigm, and it's certainly a lot more battle-hardened than the object DBMS world. It's not that I am a fan of the realtional model. I'm often frustrated at the limitations of it when I am designing relational databases. If I have my choice when building a data tracking system from scratch I'd rather use objects and a Java program than a relational database. However, I find in my work with OpenJUMP that it is often easier to associate a new property or function with an existing class than it is to add it. Maybe if I wasn't working on a huge hunk of legacy code with a bunch of public interfaces that have already been exposed to plug-in developers this would be different. SS On 6/12/07, Sunburned Surveyor [EMAIL PROTECTED] wrote: I've been thinking about this, and now I am really confused! I think I can summarize my confusion by saying this: I don't think we will need to introduce a uniquely identified FeatureSchema and/or a FeatureType if we introduce a restriction for unique Layers. (Or at least a way to associate a unique identifier with Layers.) I can associate any type or constraint or restriction on a uniquely identified Layer as easily as I can a uniquely identified FeatureSchema. After thinking about it I believe that it is better to work with Layer objects than it is FeatureSchema objects. This is because we don't expose FeatureCollections or FeatureSchemas to the user at this point. We expose Layers. A user won't want to apply a attribute value range or other constraint to a FeatureSchema, they'll want to apply it to a Layer. If I'm a user that doesn't subscribe to this list I don't even know that FeatueSchemas and FeatureCollections exist. I say we keep it that way. The only downfall that I can think of to this system is that If a programmer is interested in using OpenJUMP's feature model as a library in an external program, but doesn't want to use Layers they won't have the control we are talking about. Maybe Paul has some reasons why this won't work in his situation. The Sunburned Surveyor On 6/12/07, Martin Davis [EMAIL PROTECTED] wrote: FeatureType seems like a good name for this. It does seem like this could be added without too much risk right now, with very little semantics or functionality around it (other than what Paul is presumably building). I guess if there's a real need for this functionality it will become obvious as people ask for more functionality exposed for it. I'm just a bit worried that this whole area in general has no very clear model to follow. Every system seems to do something a bit different. If there's no initial overall vision of where this is going, we risk building off in directions which are very hard to corral back later. It would be nice to pick an existing model and follow or extend it. Maybe the Geodatabase model is a good one to look at. They certainly follow the relational paradigm pretty closely, which will make Landon happy 8^) Me too, actually - I don't have anything against the relational paradigm, and it's certainly a lot more battle-hardened than the object DBMS world. Sunburned Surveyor wrote: I must weigh in with Paul on this one guys. I see a lot of potential uses for uniquely identifying FeatureSchemas. I guess that I would call this a FeatureType. If you are curious about the applications of defining and uniquely identifying FeatureTypes just take a look at the ESRI Geodatabase. (For example, FeatureTypes would allow you to specify a range of allowed values for an attribute.) I believe in ESRI FeatureTypes are called FeatureClasses. I also don't think that it is unreasonable to specify that an OpenJUMP project contain no duplicate FeatureTypes. However, I do see that we allow Layers to have the same name, which I think is a bad thing... I guess that I never noticed this before. Martin wrote: This all seems like a lot of extra complexity to support something that at the moment is really only your own use case. Perhaps you should publish this as a plugin for now, and if it gets used a lot then the JUMP project can think about incorporating it in the core. I would agree with Martin on this point. I don't think it would be to difficult to encapsulate a system for uniquely identifying FeatureSchema's in a plug-in. You'd could automatically add the Layer name (as the unique ID for the FeatureSchema) and a reference to the FeatureSchema for a FeatureCollection to a HashMap in the plug-in. If the user tried to create a Layer with a duplicate name you could create an error message. Or you could prompt the user to enter a name for a FeatureSchema when creating a layer, although this might be more confusing for them.
