From: Benjamin D. <ben...@fa...> - 2014-11-18 19:50:01
|
Hi Volker, [snip] >> >> Would it be conceivable to use 64bit pointers instead >> to remove that limit? > > I think this should be possible, although I'm not sure it makes much > sense (see below). > In practice, it is probably not a limit that matters at the moment. But it seems an artificial limit to me, and I wonder whether it is necessary to impose it (assuming that it can be easily removed). [snip] > > Currently there are no plans to support strings. Why would you like to > store a sensor name per point? I think stuff like that should be stored > in a metadata or a header file instead. Or a database. > Multi-sensor arrays produce dense tracks of measurements that need to preserve the original sensor and track IDs in the point cloud, because we want to be able to apply per-track or per-sensor error corrections. I can see some alternatives to this. One option would be to replace verbose labels with integer IDs, but that would require the user to keep around some sort of lookup list or table, metadata or whatever. I would like to keep this structural information in the data itself. The other alternative would be to store the input data separately per track and sensor, using the file name to identify them. But with a lot of tracks and sensors, that approach becomes very unwieldy. [snip] >> >> We would certainly want to implement a spatial index file. >> Maybe it would be possible to design such an index together and >> make it part of the SPC standard, no matter whether it will ever >> be implemented on the SAGA side? > > I'm open to discuss this, but in order to make use of such an index, we > would also need methods to read junks directly from file (currently the > .spc files are loaded completely) which might be very inefficient unless > you reorder the points in the file (something which is, in case of LiDAR > data, not always wanted). Also, do you think of 2D or 3D spatial > indexing? Something to consider in case you think about providing > support not only for airborne LiDAR but also for other point cloud types > which are "more" 3D. > Indeed, I think 3D indexing would be the way to go. Although there is no operation in gvSIG CE at the moment that could make use of the Z data, I think extending an index from 2D to 3D is pretty straight-forward, and a 2D index would just be a subset with constant Z=0. >> >> The VRT tiling is a smart approach that we have also considered. >> Currently, it seems that it would require fundamental API changes, >> but it is something to be explored further. >> > > The .spc format is mainly designed as a processing format, allowing for > great flexibility like attaching attributes as you like (besides > strings). In case you are only interested in data management (storage, > visualization, distribution), did you have a look at the LAS/LAZ format > and lastools? Their LAS support already has spatial indexing, and there > is an ongoing discussion whether LAZ should be extended to allow it too > (as the proprietary ZLAS format from ESRI supports it). > We really need exactly what .spc is designed for: a format that is compact and suitable for processing very large point clouds. LAS support is also something that should also go into gvSIG CE at some point, but at the moment it's all about processing large point clouds: interpolation, filtering, error corrections, ... [snip] > > I don't think that shapefiles are a format suited for point clouds, > that's why we decided to add the spc format to SAGA. But even with the > spc format it makes not much sense to create really large files, > swamping RAM and increasing the time to load. All processing > environments I know usually work on (spatial) tile sizes > of about 100-500 meters for processing, depending on point density. > True; we need to look into tile-based storage. Best, Ben > Best regards, > Volker > >> >> Best and thanks for your answers, >> >> Ben >> >>> Best regards, >>> Volker >>> >>>> >>>> Sorry for flooding you with questions... >>>> >>>> Cheers, >>>> >>>> Ben >>>> > > > > ------------------------------------------------------------------------------ > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk > _______________________________________________ > saga-gis-developer mailing list > sag...@li... > https://lists.sourceforge.net/lists/listinfo/saga-gis-developer > -- Dr. Benjamin Ducke {*} Geospatial Consultant {*} GIS Developer Spatial technology for the masses, not the classes: experience free and open source GIS at http://gvsigce.org |