From: Basques, Bob (CI-StPaul) Sent: Wednesday, December 18, 2013 11:04 AM To: 'PostGIS Users Discussion' Subject: RE: [postgis-users] Old question resurfacing
Rémi, I’ve already played around with Cloud Compare, found it a few weeks ago during another research cycle. I think the first step is to get a chunk of data into Postgres to test live queries with. I’ll focus on this in the near term, not going to happen immediately though, lot’s of other paid work in the way I’m afraid. :c) I know there are methods out there for draping “a” image on a surface, but when you try more than one image, then it becomes a problem. We have all our data sources separated into separate overlays for display, being able to re-use these services for end user control of layer visibility will be an important need moving forward for us. Bobb From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Rémi Cura Sent: Wednesday, December 18, 2013 10:48 AM To: PostGIS Users Discussion Subject: Re: [postgis-users] Old question resurfacing Hey, getting something similar to a surface visualization out of points without computing explicit surface is actively researched. Usually it's very easy for a graphic card (GC) to drape a texture over a geometry. It is its main purpose. I wouldn't worry too much about that (already done in WebGL). Of course it would be cool to get some color out of raster, maybe with postgis raster (I just began to test it, actually trying to do the inverse : create DEM from points). What you call average vector is the estimated normal vector of the point. It can be estimated with various methods and is required for almost everything (including display to get shadows or lighting effects very useful to better "understand" the surface for an human eye). If it's just for visualization, you can let the GC do the work. It is incredibly fast. (various "shaders" do it). If you need normal for other computing (most algorithm use it), you may want to pre-compute. This can become tricky for 3 reasons : _it is in fact a local surface interpolation. So, what surface do you choose, and how local is it (plan, sphere, polynom , fixed distance, fixed number of neighbors ...) _the computing always involve nearest neighbors. Needless to say you *have* to use a LOD (for example, compute per patch, on small patch, or use an octree). _How to store it? You can do it in pointcloud of course but is is a little boring. A dirty workaround would be to store it as float[3][]. Usually in point cloud software it is stored like X,Y,Z and other attributes, something like n_x,n_y ... If you want to play with point cloud and see various option to visualize with normal based lighting, and to compute normal with various parameters, a very good open source software is CloudCompare<http://www.danielgm.net/cc/>. It is easy (like drag and drop point cloud file) and powerful. Cheers, Rémi-C
_______________________________________________ postgis-users mailing list [email protected] http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
