{"id":25,"date":"2026-08-14T17:21:58","date_gmt":"2026-08-14T17:21:58","guid":{"rendered":"https:\/\/drawingstamppro.com\/blog\/?p=25"},"modified":"2026-08-14T17:21:58","modified_gmt":"2026-08-14T17:21:58","slug":"stampkit-die-merkmalserkennung-als-baustein-im-eigenen-system","status":"publish","type":"post","link":"https:\/\/drawingstamppro.com\/blog\/stampkit-die-merkmalserkennung-als-baustein-im-eigenen-system\/","title":{"rendered":"StampKit: die Merkmalserkennung als Baustein im eigenen System"},"content":{"rendered":"

Eine Frage kommt in Gespr\u00e4chen immer wieder: \u201eK\u00f6nnen wir nur die Erkennung haben?“ Dahinter steht ein nachvollziehbarer Wunsch. Wer ein CAQ-System, ein ERP oder ein eigenes Portal betreibt, will seine Anwender nicht in ein zweites Programm schicken, nur damit eine Zeichnung nummeriert wird. Die Merkmale sollen dort entstehen, wo ohnehin gearbeitet wird. Genau daf\u00fcr gibt es StampKit<\/strong>.<\/p>\n

Der Kern, nicht die Kopie<\/h2>\n

StampKit ist der Erkennungskern von DrawingStamp Pro, herausgel\u00f6st in eine eigene Programmbibliothek. Wichtig ist uns dabei ein Punkt, der nach einer Formalie klingt und keine ist: Es handelt sich nicht um einen Nachbau des Verfahrens und auch nicht um einen eingefrorenen Zweitstand, sondern um denselben Code<\/em>, der auch in der Anwendung selbst die Merkmale findet. Wer StampKit einbaut, bekommt jede Verbesserung an der Erkennung mit \u2014 und muss nicht damit rechnen, dass die eingebaute Variante mit den Jahren hinter der Anwendung zur\u00fcckbleibt.<\/p>\n

Eine Bibliothek statt eines Dienstes \u2014 und warum das der Punkt ist<\/h2>\n

Die naheliegende Bauweise w\u00e4re heute ein Web-Dienst: Zeichnung hochladen, Merkmale zur\u00fcckbekommen. Wir haben uns bewusst dagegen entschieden. StampKit ist eine native Bibliothek, die im Prozess der eigenen Anwendung<\/strong> l\u00e4uft \u2014 kein Dienst, der gestartet werden muss, keine Datenbank, keine Netzverbindung. Angesprochen wird sie \u00fcber eine bewusst schlanke C-Schnittstelle; alles, was eine C-Bibliothek laden kann, kann sie aufrufen, ob das eigene System nun in .NET, Java, Python oder C++ geschrieben ist. Windows, macOS und Linux werden gleicherma\u00dfen bedient.<\/p>\n

Der eigentliche Grund f\u00fcr diese Bauweise ist aber kein technischer, sondern ein vertraglicher: Die Zeichnungen bleiben im Haus.<\/strong> Es gibt keinen Dienst, der Zeichnungen entgegennimmt, und keinen Weg, auf dem eine Zeichnung nach au\u00dfen ginge. Bei Teilen unter Geheimhaltung ist genau das der Punkt, an dem eine Freigabe sonst h\u00e4ngen bleibt \u2014 und die Frage \u201eWo werden unsere Zeichnungen verarbeitet?“ beantwortet sich mit \u201eauf unseren eigenen Rechnern“ deutlich schneller als mit einer Auftragsverarbeitungsvereinbarung.<\/p>\n

Was hinten herauskommt<\/h2>\n

Aus einer technischen Zeichnung werden strukturierte Pr\u00fcfmerkmale: Ma\u00dfe, Toleranzen, GD&T-Angaben und Oberfl\u00e4chenangaben \u2014 jeweils mit ihrer Position auf der Zeichnung, ihrer Kategorie und dem ausgewerteten Toleranzbereich. Was das eigene System daraus baut, bleibt dessen Sache: ein Pr\u00fcfplan, eine Merkmalsliste, ein Datensatz in der eigenen Datenbank, ein Vorschlag zur Best\u00e4tigung durch den Pr\u00fcfer. StampKit liefert die Daten, nicht die Oberfl\u00e4che.<\/p>\n

Drei Stellen, an denen sich das lohnt<\/h2>\n