Paul, It sounds like (a) named Feature Schemas are a pretty specialized use case (I certainly have never had the need for them in all my JUMP projects, and (b) you aren't proposing to provide any functionality to expose them to JUMP users.
In this case, I wonder whether there's a real need to add them to the JUMP Feature model right now? In some of my projects I've achieved similar functionality (and a whole lot more) simply by creating custom subclasses of Feature. Client code can easily check the subclass and make decisions based on it. I'm not against the idea of named schemas, since that moves things in the direction of a more "database-like" Feature API. But if they're not really used anywhere in the JUMP codebase except in your own custom code, it seems like it might be better to hold off designing them in. "Parts left out cost nothing". My 2c worth.... Paul Austin wrote: > Hi Larry, > > At the moment the FeatureSchema is designed just to allow you to get the > list of attributes for a feature. If you want to know the "type" of > feature you are dealing with you have to know the layer the feature is > in to get the "type" of the feature. I would say that 99% of the time > the name of the feature schema would be the same as the layer name. > > I would probably not persist the feature schema name in the .jmp file, > instead internally in jump update the feature schema name when the layer > name changes. This of course would not be the case if we had "themed" > layers as per Martins suggestions regarding the Catalogue concept. > > Here are the cases where it would be used. > > 1. For features that contain properties that are features (they don't > have to have geometry), I think I'm the only one using this and > it's supported by JUMP as a property can contain any object value > 2. Where you want to process a feature collection and don't have the > associated layer but would want to do some QA tasks that vary > based on the type of feature. For example you could have a minimum > length plug-in that could have different minimum lengths for road > vs. river segments > > The name on the feature is the only change I require to the feature > model in JUMP (for now ;) ) > > Paul > > Larry Becker wrote: > >> Hi Paul, >> >> Just a few questions regarding the FeatureSchema Name, since I'm >> unable to come up with the use case myself. I can see that it is >> simpler to look at the Name than to compare all of the attributeNames >> individually, but I would hate to make that assumption and then find >> that the user has deleted an attribute I was depending on. Also, >> would the FeatureSchema Name be persisted in the Task (.jmp) file, and >> if so how does that affect compatibility? >> >> thanks, >> Larry Becker >> >> On 6/9/07, Stefan Steiniger <[EMAIL PROTECTED]> wrote: >> >> >>> hei Paul, >>> >>> mhm.. if you write the function (that also supports empty names) >>> this should be possible to include if Michael and Larry agree >>> >>> stefan >>> >>> btw. although you are following specific interests, and changes to the >>> core need to be discussed it is open to you to join the jpp-team >>> >>> Paul Austin schrieb: >>> >>> >>>> Martin, >>>> >>>> If the FeatureSchema class could be extended to have a name property, >>>> with a getName (and maybe a setName) with a default constructor and a >>>> constructor that takes the name as an argument then that would be great. >>>> As we have default constructor existing code won't break as the name is >>>> optional. >>>> >>>> The advantage of having the name is that if you were doing some >>>> processing of features and don't have reference to the layer you can >>>> find out what type of feature it is and do different processing >>>> accordingly. >>>> >>>> Paul >>>> >>>> Martin Davis wrote: >>>> >>>> >>>>> BTW, the idea of having hum-readable names for FeatureSchemas is a nice >>>>> one. I'd definitely support adding that functionality, even if it isn't >>>>> exposed right now. >>>>> >>>>> >>>>> >>>> ------------------------------------------------------------------------- >>>> 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
