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