RE: re[2]: [cgmo-webcgm] problems with NUBS

[Robert Orosz <roboro@AUTO-TROL.com>]

Don,

Which defect report are you referring to, 8632-1/065 or 8632:1999-1/001?
The latter is the critical one, and it appears to have gone into a bit
bucket somewhere.  It needs to be approved, before I'll be comfortable
allowing NUBS and NURBS into WebCGM 2.0.

Regards,

Rob

-----Original Message-----
From: Don Larson [mailto:dlarson@cgmlarson.com]
Sent: Thursday, September 01, 2005 3:46 PM
To: Lofton Henderson; cgmo-webcgm@lists.oasis-open.org
Subject: re[2]: [cgmo-webcgm] problems with NUBS


All,

We too had a problem with the NUBS and NURBS as they were originally 
specified in ISO/IEC 8632-1. However, once we saw the defect report,  we
were able to successfully implement and have been supporting them
for some time.

I believe we should keep the NUBS and NURBS in the WebCGM profile
because they are used by some CAD systems and CAD format translator.
We use NUBS and NURBS in our Autocad to CGM converter. If we
dropped them, we would have to convert NUBS and NURBS to 
Polylines thereby loosing this potentially useful information for editors.

Regards, 
Don.

  > At 07:53 AM 8/30/2005 +0200, Dieter  Weidenbrück wrote:
  > >[...]excellent summary.

  > Yes, thanks Rob!

  > >To make a long story short:
  > >
  > > > question: "Are NUBS and NURBS absolutely required for WebCGM
  > > > 2.0?"
  > >No, no, and no.
  > >
  > >And I strongly suggest to eliminate them in front of this situation.
  > >This does not mean that we don't have to resolve the issues with
  > >CGM:1999, however, this won't happen before WebCGM 2.0.
  > >
  > >Does anybody object to removing the NUBS/NURBS from the CD?

  > [Dave, I think this wants to be on next Agenda.
  > All -- please circulate opinions by email, prior to telecon.]

  > I don't feel strongly -- it's more or less a user call.  Having said
that, 
  > if the defects mean that implementations are all over the map and won't 
  > interoperate, then deferring NUBS & NURBS is probably sensible.  It is
hard   > to tell, how long it will take to sort this out.

  > More embedded...

  > > > -----Original Message-----
  > > > From: Robert Orosz [mailto:roboro@AUTO-TROL.com]
  > > > Sent: Tuesday, August 30, 2005 2:13 AM
  > > > To: 'cgmo-webcgm@lists.oasis-open.org'
  > > > Subject: [cgmo-webcgm] problems with NUBS
  > > >
  > > > All,
  > > >
  > > > I've spent the better part of the past two days trying to
  > > > fulfill one of my action items, namely, generate a CGM file
  > > > with NUBS in it for the test suite.  Along the way, I've
  > > > encountered a number of problems which lead me to ask the
  > > > question: "Are NUBS and NURBS absolutely required for WebCGM
  > > > 2.0?"  If the answer is yes, then there are some problems
  > > > which need to be worked out.  I'll describe the issues below
  > > > in the order that I encountered them.
  > > >
  > > > 1) Profile should require clamped splines.  This one is easy
  > > > and appears to be resolved; the Model Profile as specified in
  > > > the WebCGM 2.0 draft profile PPF does not specify that
  > > > splines should be clamped.  This is apparently a
  > > > transcription error and will be corrected.  Interestingly,
  > > > the ATA made the exact same error.
  > > >
  > > > 2) The parameter end value parameter.  I had a recollection
  > > > that the NUBS specification in CGM92 had a defect, namely,
  > > > that the parameter end value was incorrectly specified to be
  > > > less than the n-th knot value.  Since CGM99 was supposed to
  > > > have all of the defect corrections in place, I looked at the
  > > > NUBS specification in CGM99.  I was dismayed to discover that
  > > > it was unchanged with respect to the parameter end value
  > > > parameter of NUBS and NURBS.  I then went searching for that
  > > > defect report (8632-1/065).  This was frustrating at first
  > > > until I discovered that Lofton is an excellent document
  > > > repository!  He sent me a copy of that report.  I read it and
  > > > was dismayed to discover that it too was unchanged with
  > > > respect to the parameter end value parameter of NUBS and
  > > > NURBS.  So, that probably explains why CGM99 had no changes
  > > > for parameter end value.  Other changes from 8632-1/065 are
  > > > incorporated into CGM99.
  > > >
  > > > Lofton then sent me another defect report (8632:1999-1/001)
  > > > which addresses the issue of the parameter value.  It states
  > > > that the end value shall be less than or equal to the (n+1)st
  > > > knot value.  However, he does not know the status of this
  > > > defect report.

  > Right.  This is another case where our liaison w/ SC24 failed in the
years 
  > around 1999.  (I won't name names!  Okay ... actually, I must share the 
  > responsibility with our former SC24 Liaison officer.)

  > With SC24, I'm now trying to actively sort out the Registry problem.  I 
  > will follow up with this one -- we apparently prepared a defect report,
but   > possibly it didn't go anywhere.

  > > >
  > > > 3) Interval over which the higher order basis functions are
  > > > non-zero.  I noticed this discrepancy while reading
  > > > 8632-1/065.  It states that the interval over which the
  > > > higher order (k > 1) basis functions evaluate to non-zero is
  > > > T[i] <= t <= T[i+k].  However, CGM99 gives the interval as
  > > > T[i] <= t < T[i+k].  So, B[i,k](t) = 0 when t = T[i+k}
  > > > according to CGM99.  It does not equal 0 according to the
  > > > 8632-1/065 defect report, and you must evaluate the two terms
  > > > in the basis function to obtain the value.
  > > >
  > > > The 8632-1/065 defect report states: "The CGM defects editor
  > > > has convened an ad hoc committee of NURBS and CGM experts.
  > > > ...", so that tends to make me believe it over CGM99.
  > > > However, I'm not a NURBS expert myself, so I have no idea
  > > > which is correct.  It's possible that the numerators of the
  > > > two terms in the basis function evaluate to 0 when t = T[i+k]
  > > > in which case there is no discrepancy.  I haven't checked
  > > > this possibility.  Like I said, I'm not a NURBS expert.

  > This sounds familiar.  Dave, is this the issue that we worked out with 
  > Richard Fuhr?  Or was that worked out earlier and incorporated into 
  > CGM:1999 (8632-1/065), and then visited again (8632:1999-1/001)?

  > Long story short, Dave, do you have access to a NURBS expert who can
answer   > these questions for us?  (I guess the only real question is #3,
as #1 seems   > agreed [clamped], and #2 appears to be a bona-fide erratum
whose processing   > got derailed.)

  > Regards,
  > -Lofton.