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
