put in a todo why I'm punting properly handling holes for now

git-svn-id: http://svn.osgeo.org/postgis/trunk@7121 b70326c6-7e19-0410-871a-916f4a2858ee

diff --git a/liblwgeom/lwout_x3d.c b/liblwgeom/lwout_x3d.c
index dd3e685684b91711edfb979dfdd08af15235eeca..396ec0753233e455a0411c0aadc89ec54073676d 100644 (file)
--- a/liblwgeom/lwout_x3d.c
+++ b/liblwgeom/lwout_x3d.c
@@ -253,7 +253,15 @@ asx3d3_mpoly_coordindex(const LWMPOLY *psur, char *output)
                        j += k;\r
                        if (l < (patch->nrings - 1) )\r
                        {\r
-                               ptr += sprintf(ptr, " -1 "); //separator for each inner ring I know its probably wrong - place holder for now\r
+                           /** @todo TODO: Decide the best way to render holes\r
+                           *  Evidentally according to my X3D expert the X3D consortium doesn't really \r
+                           *  support holes and it's an issue of argument among many that feel it should. He thinks CAD x3d extensions to spec might.\r
+                           *  What he has done and others developing X3D exports to simulate a hole is to cut around it.\r
+                           *  So if you have a donut, you would cut it into half and have 2 solid polygons.  Not really sure the best way to handle this.\r
+                           *  For now will leave it as polygons stacked on top of each other -- which is what we are doing here and perhaps an option\r
+                           *  to color differently.  It's not ideal but the alternative sounds complicated.\r
+                           **/\r
+                               ptr += sprintf(ptr, " -1 "); //separator for each inner ring. Ideally we should probably triangulate and cut around as others do \r
                        }\r
                }\r
                if (i < (psur->ngeoms - 1) )\r