Ede, OJ can't support multiple geometries and it would be a difficult task to make >well, in theory it can. the model as is merely limits geometry to be _only one_ of the attributes. as Geometry is a proper attribute type we can easily add more than one, they won't be displayed though ;) Actually, FeatureSchema.addAttribute check that no Geometry geometryIndex is -1 (and set geometryIndex to a index > -1 if non exist). Object type can be used how about a new BLOB attribute type, signifying that the column contains plain bytes, in case blobs are delivered by the underlying data reader? What would be the advantage over Object ? - to preserve original data as much as possible, but will generally not survive if it is not saveable w/o data loss the write should simply err out and give the user a chance to save it another way. as much as i understand the industry standardness of the shapefile format, we shouldn't strive to make it limiting factor for OJ data formats. I think that in most drivers, Object type is converted to String with toString() method, which is not so bad.Probably a warning would be appreciated. Error would probably force the user to remove the column before saving without offering better alternative. - to offer plugin developpers a way to store structured data for in-memory usage watcha mean by "structured data for in-memory usage" ?.. ede E.g. computing different simplified geometries for different scale representoins in named attributes g1, g2, g3. Could not be saved in file, but could be used by a plugin aware of these attributes and avoid on the fly computation. Could also read image from a read-only database to display it on screen... Not sure these example are relevant, just ideas. |
_______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel