-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issue 687 - Add Drawings Support #688
Conversation
… and order for clarity
…d update) and removed -f from processDrawing args
…s from import manager when compiling without oda support
…specifics from import manager when compiling without oda support" This reverts commit 4fc28e5.
…dler def and initialisation of multiple queues more general
Hi @carmenfan, did you say that size and format had been added to the queue message? It doesn't appear to be so in 5090, though I am probably looking in the wrong place! |
Thank you! |
This is now receiving a post request like so via 5090,
And processing it successfully. We might want to wait for the endpoint to get the SVGs to make sure it can be read as well, but if that works all the changes should be addressed now! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sebjf There's a type descrepancy on the id of the image:
tjhe entry in .history is written as a UUID:
But the ID in .ref
is in string
JS will just pass it as is to the database query so mongo will return with no entry. So we either need both to be string or both to be UUID 😢
Also, can we conver the extension on the name to be .svg please?
@sebjf another thing, just checking out the svg against the same drawing exported to PDF, this is what the PDF looks like: And this is the DWG. The annotations are coming out in weird colours, sometimes it's it's obscured as well because the background colour is the same as the font colour: |
Opening it the ODA app i can see it's assuming a black background... I wonder if this is a setting we can tweak... |
Hi @carmenfan,
Gah, missed it after the refactor - fixed!
Done! I noticed though that |
Hi @carmenfan,
Yes, the |
model is stored as a string because of legacy reason (if you open the settings collection in a db you'll see they're all string ID, and it'll be difficult to store it as LUUID in one place and string in other as they're usually passed around and queried everywhere) I do want to convert to UUID in the future but it's going to take a big migration script 🤦... so future work 😆 |
Got it - bouncer has been updated to consider it a string! |
(@carmenfan , something I just remembered was that ODA fails to set the |
@sebjf not 100% sure what this means 😆 . Are we waiting on a fix from ODA? or do we need add this ourselves as part of this branch? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM - just need to double check with you what the SVG height/width entails 😆
Sorry end of the day post 😆 SVG files have both a This should not be problem in theory because the At first I was just going to make sure our 2D viewer could handle SVGs without the tags, but given Firefox's issues, I think the best solution is just to add the fields on export. We know the width and height because we set up the view properties ourselves. This is something we'd do in bouncer; we wouldn't try and get ODA to modify their exporter. I will do it today as part of this ticket, in case we want to merge before Milestone 5. |
…, and added unit test to make sure they dont break in the future
Hi @carmenfan, Added the attributes. There are a couple more magic numbers/strings than I usually like but not sure its worth creating an svg helper header yet - I've updated the unit tests in case the svg exporter changes with the ODA upgrade. |
@sebjf thanks! Probably prefer it to be in the base class but not really a big issue 😆 |
This fixes #687
Description
Adds support for processing drawings in a similar manner to 3d models, but where the drawing to process is provided via an existing revision node.
Specifically, this PR:
RevisionNode
a superclass andModelRevisionNode
&DrawingRevisionNode
subclasses, with members appropriately scoped to each.fs
ref node, since that is how files will be provided for drawings as opposed to via the bouncer import configFileProcessor
superclass so that it can now be initialised to collect geometry data, SVG data, or both, from a single file (SVG data collected via theDrawingImageInfo
type, which is analogous but not directly equivalent toGeometryCollector
).DrawingImageInfo
, to the DWG and DGN file processor subclasses. This uses theSvgExportModule
which is included as part of ODA.DrawingManager
, which is responsible for interacting with the databaseDrawingImportManager
, which is responsible for selecting the right importer and using it to populate theDrawingImageInfo
processDrawingRevision
, toRepoManipulator
&RepoController
, that will acquire a file from a drawing revision, process it using the aforementioned importers, and update the revision node in the database.processDrawingRevision
to a new commandprocessDrawing
in 3drepobouncerClientAdditionally, changes to
bouncer_worker
include:drawingQueueHandler.js
, has been added, as well as a new label toqueueLabel
for it.queueHandler.js
queueHandler.js
has been refactored slightly so that dereferencing (and validation) of labels to queue names from the config happens immediately inconnectToQueue
orrunNTasks
, and from there on in the queue names are used to resolve handlers, allowing queue initialisation and handling methods to be more generalized throughout.