On 9/29/2020 14:22, Michaud Michael wrote: > Ede, > > > OJ can't support multiple geometries and it would be a difficult task to make > this change. > > >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).
not saying there are no obstacles. just saying there is nothing that prevents us from implementing it. > 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 ? your mail quoting seems to be broken agn ;9 the advantage would be the explicit typed binary nature, while for an Object we do not know how the attribute backend handles it internally. actually afaics we use Object if we get something from a data source that does not match a known data type. > - to preserve original data as much as possible, but will generally not > survive > a complete roundtrip (maybe a more specific serialization format could achieve > this goal, but with format like shapefile, we will rapidly encounter the 255 > char problem). > > 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. well, it's bad in case of BLOBs > Probably a warning would be appreciated. Error would > probably force the user to remove the column before saving without offering > better alternative. or saving to another format or converting the blob into WKT and save that to CSV. the possibilities are endless :)) > - to offer plugin developpers a way to store structured data for in-memory > usage > (e.g. multiscale display as suggested by Jukka). I'm not aware of a concrete > use-case though. > > 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. ic. yeah let's table that thought. i'm merely interested in not destroying additional geometry columns in datasets or at least warn that they are there or ignore them with a warning, so the user dosn't get a chance to corrupt them, if that makes sense. ..ede _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
