PostGIS  2.2.7dev-r@@SVN_REVISION@@
static size_t asx3d3_mpoly_coordindex ( const LWMPOLY psur,
char *  output 
)
static
Todo:
TODO: Decide the best way to render holes Evidentally according to my X3D expert the X3D consortium doesn't really support holes and it's an issue of argument among many that feel it should. He thinks CAD x3d extensions to spec might. What he has done and others developing X3D exports to simulate a hole is to cut around it. 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. For now will leave it as polygons stacked on top of each other – which is what we are doing here and perhaps an option to color differently. It's not ideal but the alternative sounds complicated.

Definition at line 244 of file lwout_x3d.c.

References LWMPOLY::geoms, LWMPOLY::ngeoms, POINTARRAY::npoints, LWPOLY::nrings, and LWPOLY::rings.

Referenced by asx3d3_multi_buf().

245 {
246  char *ptr=output;
247  LWPOLY *patch;
248  int i, j, k, l;
249  int np;
250  j = 0;
251  for (i=0; i<psur->ngeoms; i++)
252  {
253  patch = (LWPOLY *) psur->geoms[i];
254  for (l=0; l < patch->nrings; l++)
255  {
256  np = patch->rings[l]->npoints - 1;
257  for (k=0; k < np ; k++)
258  {
259  if (k)
260  {
261  ptr += sprintf(ptr, " ");
262  }
263  ptr += sprintf(ptr, "%d", (j + k));
264  }
265  j += k;
266  if (l < (patch->nrings - 1) )
267  {
276  ptr += sprintf(ptr, " -1 "); /* separator for each inner ring. Ideally we should probably triangulate and cut around as others do */
277  }
278  }
279  if (i < (psur->ngeoms - 1) )
280  {
281  ptr += sprintf(ptr, " -1 "); /* separator for each subgeom */
282  }
283  }
284  return (ptr-output);
285 }
int npoints
Definition: liblwgeom.h:355
LWPOLY ** geoms
Definition: liblwgeom.h:480
POINTARRAY ** rings
Definition: liblwgeom.h:441
int nrings
Definition: liblwgeom.h:439
int ngeoms
Definition: liblwgeom.h:478

Here is the caller graph for this function: