adGeometry IDL comment documents the 'angle' field in CadGeometry.TessParametersStruct
as "deviation between normals of facets".

Neither the IDL nor the CAD Services spec. indicate what angular units should be used.

This oversight was corrected by indicating the required use of degrees for angle units.

The type of the 'normals' field in TessellationStruct should be VectorStructSeq
instead of PointStructSeq.

Agreed. IDL modified.

Should there be a get_parameter_set function at the Model interface level?

see above

CadBrep Edge.nearest_points function needs clarification for
'nearest_points' argument.

How are the nearest_points defined? It is declared as a PointStructSeq,
but no further details are provided. Will there always be 2? Is the
first point of the sequence a point on the given edge and the second
point a point on the edge corresponding to the input argument? What is
the expected behavior if there are multiple locations that the 2 edges
have an identical minimum distance?

see above

CadBrep Edge.nearest_points function incorrectly defines the
'nearest_points' argument as 'in'.

CAD Services spec documents Edge.nearest as 'Determines the minimum
distance, and corresponding closest points, between this Edge and the input
Edge. The returned value is the minimum distance'. The 'nearest_points'
argument should be declared as 'out'.

Resolved through removing the nearest_points operation. See issue 4493.

CadBrep Edge IDL defines a 'start_vertex()' function, but not
an 'end_vertex()' function.

Agreed. An operation was added to the Edge interface.

CadBrep Oriented Edge IDL defines an 'end_vertex()' function,
but not a 'start_vertex()' function.

Agreed. An operation was added to the OrientedEdge interface

Binding for Face.nurbs_representation needs major design overhaul or
removal.

IDL indicates the function returns a CadUtility.NurbsSurfaceStruct. A
simple NURBS surface structure cannot represent arbitrary faces w/
irregular boundaries, both outer and inner.

see above

CAD Services specification needs to clarify 'exact' for
nurbs_representation functions.

nurbs_representation indicates that if the NURBS is exact, then tolerance
is returned as negative value. Is that exact geometrically or exact
geometrically AND parametrically?

see above

Edge.nurbs_representation should h. 'tolerance' argument declared as
'inout' instead of 'in'.

CAD Services specification indicates that 'If the representation is exact -
tolerance will be returned as a negative value.

Agreed. This corrections involved a minor modification of the IDL.

Surface.nurbs_approximation should have 'tolerance' argument declared as
'inout' instead of 'in'.

CAD Services specification indicates that 'If nurbs representation is
exact, tolerance will be returned as a negative'. By the way, the 'NURBS'
acronym should be capitalized in the spec and IDL when used in this
context.

see above

Surface.nurbs_approximation should be renamed nurbs_representation to be
consistent w/ Curve.nurbs_representation.

Agree. Representation is a better description

I was building a Java3d display for CadServices data and I realized that
> we do not return the object color in the PresentationStruct. We return
> the color of the highlight (specular_color), and various parameter about
> reflectance - but we do not include the base color of the object.
>
> I think we need to add a "ColorStruct color;" to the PresentationStruct.

see above

• IDL extracts in the document are inconsistent about showing module
  declarations.

Module declarations added to the document

UML looks like Corba profile, but is not quite. In particular the
<<Interface>> stereotype should be <<CORBAInterface>>. There may also
be some "in" tags in the wrong place.

CORBA UML diagrams throughout the document were updated to an appropriate format

Mikhail Kazakov mentioned that some of the Cad Services interfaces may be under-specified. Here is a list of operations needing additional documentation:
1. CadMain:: open_model( …) - the question involves whether this operation loads the specified model into memory or are all the available models in memory and the open_model() operation merely returns an object reference to the model.

Recommendation: the documentation should include the following: The open_model() operation loads the specified model into memory and can be unloaded by invoking close_model() on the Model object reference.

2. CadMain:: top_level_entities (in CadUtility::TypeCodeSeq entity_types) - what happens when an empty TypeCodeSeq is passed? One could respond with all top level entities or none.
Recommendation: Documentation shall state that an empty TypeCodesSeq will result in a system exception (BAD_PARAM).

3. unsigned long unique_entities_count (in CadUtility::TypeCodeSeq entity_types) raises (NotValidCadType, CadUtility::CadError); - what happens when an empty TypeCodeSeq is passed? One could respond with all entites or none.
Recommendation: Documentation shall state that an empty TypeCodesSeq will result in a system exception (BAD_PARAM).

4. CadFoundation::EntitySeq unique_entities (in CadUtility::TypeCodeSeq entity_types) raises (NotValidCadType, CadUtility::CadError); – what happens when an empty TypeCodeSeq is passed? One could respond with all entites or none.
Recommendation: Documentation shall state that an empty TypeCodesSeq will result in a system exception (BAD_PARAM).

The identified recommendations were agreed.

double inertial_moment_spherical;
double gyration_radius_spherical;
CadUtility::VectorStruct first_moments_centroidal;
CadUtility::VectorStruct inertial_moments_centroidal;
CadUtility::VectorStruct inertial_products_centroidal;
CadUtility::VectorStruct principle_moments_centroidal;
CadUtility::VectorStruct gyration_radii_centroidal;

are unclear.

Jim Stevens identified the following:

The "centroidal" moments are the various mass properties with respect to the center of mass for the body. This is the more "typical" case for mass properties. They correspond to similar mass property calculations in the structure that are with respect to a specific coordinate system.
Principle moments are moments inertia along the principle axes through the center of gravity of an object.
When defining a moment of inertia around an arbitrary axis thru the center of mass you end up with product terms. There is
one axis definition for which the product terms are zero, which is called the principle axis and the moments of inertia when
using that axis definition are the principle moments.
Radius of gyration is related to the moments of inertia and the mass along each axis.
I am not sure about the meaning of first moments. I am pretty sure that inertial_moment_spherical and
gyration_radius_spherical have to do with representing the model with a single sphere that would have
the same overall inertial characteristics as the analyzed body.
Jim Stephens

Based on Jim's comments I am not certain that we need the first moments or the spherical inertial moment and gyration radius.

see above

Here is a quick itemization of necessary changes (most from Sergey and
a few additional). Following the list is a modified section of the IDL
that can be used to replace the corresponding lines in the existing
CadMain.idl file. *** NOTE: Also need to add 'typedef sequence<LongSeq> LongSeqSeq;'
to CadUtility.idl.

index_faces:
Needs 'SeqSeq' of oriented_eloops instead of 'Seq'
For consistency, arg should probably be 'oriented_edge_loops' instead of 'oriented_eloops'
Does not need eloops, edges.
index_edge_loops:
Needs 'SeqSeq' oriented_edges instead of 'Seq'
index_shells:
Needs 'SeqSeq' oriented_faces instead of 'Seq'
index_bodies:
Needs 'SeqSeq' oriented_shells instead of 'Seq'
index_vertex_loops:
Ok (just included in IDL below for easier replacement of old IDL section)
index_oriented_edges
Need 'BooleanSeq senses'
index_oriented_faces
Need 'BooleanSeq senses'
No vertices or vLoops needed
index_oriented_edge_loops
For consistency, should probably be 'index_oriented_edge_loops' not 'index_oriented_edgeloops'
Need 'Seq edge_loops' not 'Seq edges'
Need 'BooleanSeq senses'
index_oriented_shells:
Need 'Seq shells' not 'Seq ofaces'
Need 'BooleanSeq senses'
No vloops needed

CadUtility::LongSeq index_faces(in CadUtility::LongSeqSeq oriented_edge_loops,
in CadUtility::LongSeq vertex_loops, in CadUtility::LongSeq surfaces)
raises (IncorrectIndex, CadUtility::CadError);
CadUtility::LongSeq index_edge_loops(in CadUtility::LongSeqSeq oriented_edges)
raises (IncorrectIndex, CadUtility::CadError);
CadUtility::LongSeq index_shells (in CadUtility::LongSeqSeq oriented_faces)
raises (IncorrectIndex, CadUtility::CadError);
CadUtility::LongSeq index_bodies (in CadUtility::LongSeqSeq oriented_shells)
raises (IncorrectIndex, CadUtility::CadError);
CadUtility::LongSeq index_vertex_loops (in CadUtility::LongSeq vertices)
raises (IncorrectIndex, CadUtility::CadError);
CadUtility::LongSeq index_oriented_edges(in CadUtility::LongSeq edges,
in CadUtility::BooleanSeq senses)
raises (IncorrectIndex, CadUtility::CadError);
CadUtility::LongSeq index_oriented_faces(in CadUtility::LongSeq faces,
in CadUtility::BooleanSeq senses)
raises (IncorrectIndex, CadUtility::CadError);
CadUtility::LongSeq index_oriented_edge_loops(in CadUtility::LongSeq edge_loops,
in CadUtility::BooleanSeq senses)
raises (IncorrectIndex, CadUtility::CadError);
CadUtility::LongSeq index_oriented_shells(in CadUtility::LongSeq shells,
in CadUtility::BooleanSeq senses)
raises (IncorrectIndex, CadUtility::CadError);

see above

5. Function
CadUtility::LongSeq index_oriented_faces(in CadUtility::LongSeq faces,
in CadUtility::LongSeq vertices,
in CadUtility::LongSeq vloops)

Maybe instead of this, the description should be something like this:

index_oriented_faces(in CadUtility::LongSeq faces,
in CadUtility::BooleanSeq senses)?

For what reason should you put the vertices and vloops in parameters?

Please see resolution in issue 4632.

4. Function
CadUtility::LongSeq index_oriented_xxxxxxxx

For functions which create oriented entities, boolean flags "sense" should be present in parameters, i.e. like BooleanSeq senses.

Please see resolution in issue 4632.

3. Function
CadUtility::LongSeq index_shells (in CadUtility::LongSeq oriented_faces)
raises (IncorrectIndex, CadUtility::CadError);

The same situation. "In" parameter orieneted_faces should be CadUtility::LongSeqSeq, because shell is a set of faces.

Please see resolution in issue 4632.

2. Function
CadUtility::LongSeq index_edge_loops(in CadUtility::LongSeq oriented_edges)

Edge loop is described by list of edges, because of this, the "in" parameter oriented_edges should be CadUtility::LongSeqSeq.

Please see resolution in issue 4632.

Function
CadUtility::LongSeq index_faces(in CadUtility::LongSeq oriented_eloops,
in CadUtility::LongSeq eloops, in CadUtility::LongSeq edges,
in CadUtility::LongSeq vertex_loops, in CadUtility::LongSeq surfaces)

Could you describe, please, the reason of presence of "eloops" and "edges" in the parameters?

Please see resolution in issue 4632

Suggest interface for STEP open shell, ie a collection of faces that do not enclose a volume.

This functionality is available in the current CadGeometry::Shell interface.

Possible resolution:

Add methods:

interface CadSystem

interface Model

This is essentially the same issue as involved with 4571.

Replace
CadUtility::PointStruct position () raises (CadUtility::CadError);
// Returns a struct of the coordinates of a single, reference location on
// the entity that should be unique relative to neighboring entities.
method by
CadUtility::TransformationStruct location () raises (CadUtility::CadError);
// Returns a struct of the applied transformation, which represents
// the location (position, turn, scale) of the entity according the global coordinates

In that case, we will be able to refer the entity according any other entities.
This method doesn't return the "last applied transformation", but "the superposition
of all applied transformations". In that case, location of the entity in 3D space will be returned.

Duplicate

There is no way to delete any CadFoundation::Entity interface child.
We shall add the possibility to delete:

Model
ModelInstance
BrepEntity
Curve
Surface

see above

There is no "3D Location" function in Entity interface.
There is only Entity.Position(), which returns PointStructure,
but it is not enough to describe a 3D transformation.
It's necessary to return TransofmrationStruct from such a function.
It's necessary also to mention, that Entity interface has a method for
transformation.

However, if Position() has another goal, than 3D location of Entity, it
shall be described in the document.

see above

The 'intersection_parameters' argument in Surface.intersect_ray() must be type 'CadUtility::UvStructSeq' instead of 'CadUtility::DoubleSeq'.

Agreed.

In the CadServer interface we have the ability to inquire launch
properties for the CadSystem, and then pass in a set of properties
when we call connect() or connect_with_password().

Once the CadSystem is running we do not have a way to query or
change the properties.

As an example - UG has a property for the search path for files.
You can set this property when you initially start up the CadSystem.
If it needs to be changed during a session the only choice is to
shut down the CadSystem with disconnect() then call connect()
again.

Also, if you connect to an already running CadSystem you
cannot determine what properties were used during the original
connect().

I think I would propose adding something like "get_properties"
and "set_properties" for the CadSystem interface. These calls
would basically allow a query and update of the properties
provided to the CadServer via the connect() calls.

CosPropertyService::Properties get_properties();
void set_properties( in CosPropertyService::Properties props );

The proposed operations were added to the CadSystem interface.

7. Creation of ModelInstances. I haven't found any way to create ModelInstance. And it's not explained in the specification.

see above

6. #include list of CadGeometry module contain:
#include "CadFeature.idl"
that has to be replaced by #include "CadFoundation.idl".
CAD Geometry never use features explicitly.

This is a good observation. The #include was modified.

5. Method names in topological entities are not everywhere unified. To return a single entity we use normally prefix get_entity.
To return a sequence we use no prefix normally: for example

Shell get_shell () raises (CadUtility::CadError);
OrientedFaceSeq oriented_faces () raises (CadUtility::CadError);

Not all method names in CadBrep module satisfy this rule.

All operations that did not follow the standard naming procedure were changed.

3. It is not clearly described in the specification document, how to add new topological entities to existing model with sharing of existing entities.
Let's say we have 2 vertexes already created and we would like to add an edge.
While implementing EntityFactory interface, a developer have to care about this sharing. Otherwise vertexes won't be shared.
And from my point of view we have to speak about that in the document.

see above

OrientedEdgeLoopSeq edge_loop() raises (CadUtility::CadError); method of CadMain::EdgeLoop has to be renamed to
OrientedEdgeLoopSeq oriented_edge_loop() raises (CadUtility::CadError);
for unification.

The operation is renamed.

1. Perhaps we have to generalize is_manifold() methods in all BRep entities. I propose to have is_manifold() only in BrepEntity interface, but not in each interface. The only restriction is vertex, which can return anytime TRUE.

see above

Our entity groups in Cad Services don't have any form of an
identifier or name that can be retrieved through the interface.
The only returned data is either a list of entities in the group or
the count. It makes it difficult to present this information to a
user.

We might consider adding an attribute to the entity group,
however that means it gets inherited to the layer.

readonly attribute string native_label;

A readonly attribute was added to the EntityGroup interface.

Section 3.4, Editorial: Although the description of interaction with
PDM Enablers is fairly clear, a sequence diagram (or several, for
the several cases) would increase the likelihood of
interoperability.

Appropriate sequence diagrams were added to the specification.

Sections 1.8, 2.8, 3.1, 3.2, Editorial: Compliance points / levels
and optional interfaces are spread around the document in a way that
would hamper formal claims of conformance.

see above

Support for STEP input / output?

see above

Body.property_info, several values are calculated. What is the return accuracy? Should a separate accuracy for each separate property be returned? Should accuracy be returned at all?

see above

Should Shell.tessellation return a similar structure to Body.tessellation? Currently shell tessellation returns a FaceTessellationStructSeq while body tessellation returns a BodyTessellationStruct. Shell tessellation results are the only tessellation results that do not have an object reference to underlying topology. Rename BodyTessellationStruct to something like ConnectedFaceTessellationStruct?

see above

Model level parameters for geometry creation. Should the model creation operation support new parameters?

Agreed. A Model creation operation was modified in the CadSystem interface.