|
The reason I was thinking of Object type for Ids is that then you could
use a Long, Integer or String for the feature ID depending on the type
of data. I normally use Long but some models may use String based
globally unique ids, I wouldn't want to use String for numeric fields
all the time. On the schema issue, I still like to have a schema associated with a feature but not making it mandatory, having the schema there allows you to do validation on the feature to make sure it conforms to the schema (e.g. type and allowed values for enumerations). When I'm looking at a feature model I'm looking at it for passing around in a processing pipeline for transformation, spatial processing and validation rather than just for the display in JUMP. Paul Michaël Michaud wrote: Hi Paul, 1. Do you really need Object type for ids (I think ids are Strings in GeoTools - don't know if there is performance penality compared to int ids, or some cases where a genaral Object type is needed) 2/3. If I can remember, GeoTools complex feature model fulfill 2 and 3 requirements, and define a subclass (SimpleFeature ?) looking like jump's feature model (more or less) 4. I already thought that a feature should't have a schema. Fundamentally, I think a feature is like a map with attribute/value pairs, and that feature schema belong to the feature collection level. It would be interesting to know why jump's designers have choosen to include a featureschema reference in each feature.Michaël Paul Austin a écrit : |
------------------------------------------------------------------------- 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
