From: doug s. <hig...@ho...> - 2011-10-31 13:44:32
|
> A geospatial feature table will have a geometry field -which is > unreadable by a normal table row browser- and contains points, linework > and area geometry. IIRC in GIS you say what kind of geometry a table will have: point, line or area. In other words each table is geometry-specific. In web3d we have a lot of different nodes. To follow the GIS analogy I think they would each have a separate table, as well as a scene table. Routes would be in a separate table. The fields of a node would be the columns of the table. Then just the geometry tables would be indexed for searching in 2D or 3D. In GIS all the geometry is in absolute coordinates -usually mapping plane XY or geographic latitude and longitude- making geographic indexing straightforeward to implement. In web3d children inheret the transform of their parents. If you change a parent transform, ideally you would not have to change all the children records to update their 2D/3D search extents. To do that the indexing and searching algorithms and how they are updated would need to be different. One way to generate the tables is with a generator script based on the web3d node specs. > But lets say that's all worked out. Then with the versioning and > multi-user capabilities it could be good for those rare large web3d > projects. |