Skip to content

generating UUID v5 identifier in STEP pre-processor #424

Open

Description

@TRThurman

Apologies for slightly off-topic issue.
We are working on a project to support CAD-CAD data exchange and update of a model.
We are planning to facilitate the exchange by using UUID v5 idenfitiers on specific STEP objects and aggregtes of STEP objects.
We are expecting to use the path from "the" root node of the CAD object tree to the current object as the "name" input to the UUIDv5 generator.
We are expecting to let the enterprise to set the value for the "namespace" input to the UUIDv5 generator.
The intent is that the resulting STEP file could be read back in to the originating CAD system and unchanged CAD objects would not be re-created by the post-processor.
If there is interest in this capability, please let me know.

Activity

  1. brlcad commented on Aug 16, 2021

    @brlcad
    Member

    Cool Tom! We implemented something loosely similar in BRL-CAD for cache objects using UUIDv5's, though I opted to use a binary serialization instead of the object name instead of relying on namespacing. I didn't tie that work to STEP though, only to our format.

    In any regard, that's of course all not answering your question. I think what you're suggesting sounds interesting, personally. I'm not sure what it means in terms of STEPcode tools or API -- perhaps there could be a STEPentity iterator for computing and storing the uuid on entities, and/or another iterator for two STEPfile instances that calculates and compares? Or are you suggesting some new processing tool that would be bundled with STEPcode? What did you have in mind?

  2. TRThurman commented on Aug 16, 2021

    @TRThurman
    MemberAuthor

    Glad to hear!
    The CAD-CAD use case requires that unmodified data doesn't cause a re-write of the internal CAD model when ingested.
    A generic STEPentity iterator will result in a multi-rooted tree. Maybe that is ok, but that is why we are focused on iterating over the internal CAD model as that "should" be a single-rooted tree. ;-)
    To me that implies persistent storage internally in the CAD system of the mapping from objects to STEP entities.

    I don't really have any specific thing in mind. I was hoping to kick off a conversation and get confirmation that the techincal approach of traversing a path from the root of the CAD tree to an object is robust.

    And once we get down to the object, we are intending to capture the objects "below" that object in an aggregate.
    So that a feature that has a complex representation would not only be identified at the feature object but also all its data values over in the representation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions