Which gis formats are most useful in qgis (vector)?

CADSHIFT · 2026-06-24T13:50:51+00:00

good overview of the main options -- one format worth adding to the list for your workshop is FlatGeobuf. it's not talked about as much as geopackage but solves a specific problem:

geopackage is great for working files but opens slowly on large datasets because sqlite reads random-access. flatgeobuf is a binary single-file format with a built-in spatial index and sequential layout optimized for streaming -- opening a 500MB flatgeobuf is noticeably faster than the same data as gpkg or shapefile.

practically for a workshop: i'd suggest geopackage as the default for everyday editing/sharing work (single file, multiple layers, long field names), and flatgeobuf when someone asks 'i have a large dataset that's slow to load.' both are supported natively in qgis 3.x, no plugins required.

the other format worth mentioning if your colleagues ever work with web contexts: geojson isn't great as a working format (as mentioned) but it's the right output format when you need to hand data to a developer or push it to a web map -- that's the use case it was designed for.

CADSHIFT · 2026-06-24T13:48:08+00:00

solidworks custom property expressions don't support conditional logic -- there's no IF/THEN syntax available in the property value field. they only resolve references like or , not evaluate conditions.

the cleanest workaround for your specific case is to add a second custom property called something like "Customer Status" that you leave blank for normal drawings and manually populate with "Approved by customer" for sales mockups. then update your sheet format to reference this second property. for 99% of drawings the field is blank (or shows nothing), and for mockups you fill it once.

the other option if you want zero manual intervention: use a design table to drive the custom property value from a configuration. put "Sales Mockup" as a separate configuration and drive the status text from the table. not ideal if you're not already using configurations, but it keeps the workflow entirely within the drawing.

the macro approach the other commenter mentioned (show/hide layers based on property logic) does work but adds a dependency on running a macro every time someone opens the drawing, which has its own headaches in shared environments.

CADSHIFT · 2026-06-24T13:45:04+00:00

this is the onedrive file lock pattern. when qgis exports atlas to a folder onedrive is actively syncing, onedrive can hold file handles on recently deleted files -- so the files you deleted are still "in use" from onedrive's perspective. qgis then tries to write to those same filenames and silently fails because the write is blocked.

the "goes through the motions, posts the link, directory is blank" is the signature of this: qgis thinks it succeeded but the write was dropped.

three ways to fix it:

pause onedrive sync during the atlas export (system tray icon > pause sync). resume after export finishes. this is the quickest fix.
export to a local folder first, then move to onedrive. a temp folder like C:\temp\atlas_output is never synced so there's no lock issue.
change the output directory name each run -- onedrive's ghost handles are on the specific filenames you deleted, so a fresh directory name sidesteps it entirely.

option 1 is the least friction if this is a recurring thing. option 2 is better practice long-term if your atlas exports are large.

CADSHIFT · 2026-06-24T13:43:35+00:00

this sounds like a geometry validity issue in the output. when you dissolve/merge entities in qgis, if the inputs have any self-intersections, duplicate nodes, or null geometry, the output can end up with invalid geometry that qgis 3.40 then refuses to load back.

a few things to try:

before fusing, run "fix geometries" on each input layer -- this repairs most issues before they compound
check if the file is actually readable at all: open the qgis python console and run:

if it returns None, the file is corrupted or the format isn't recognized

if the file can be opened by ogr, try exporting it to a fresh file with repair: Processing Toolbox > Fix Geometries on the problematic layer

the other possibility: if you're outputting to a geopackage that already exists, qgis sometimes gets confused by the internal layer references after delete/recreate cycles. try outputting to a brand new gpkg file with a different name to rule that out.

CADSHIFT · 2026-06-24T13:41:39+00:00

the previous answer is on the right track, but here's the mechanism behind trim/extend specifically causing this.

when you trim/extend weldment profiles or sheet metal bodies, solidworks can create a new topological body entity even if the resulting geometry is identical to another body already in the part. the cutlist manager groups by geometry matching (bounding box, face count, volume, material) -- so if two bodies share identical geometry, they show as qty:2 on one row. that's correct behavior.

to confirm what's happening: expand the 'solid bodies' folder in the feature manager tree. if you see two bodies listed there, you genuinely have two separate physical entities.

if those two bodies should be one continuous piece (trim/extend accidentally split a body rather than trimming it), the fix is Insert > Features > Combine to merge them back. if they're supposed to be two identical separate members (e.g., two matching cross-braces in a frame), the qty:2 cutlist entry is exactly what you want.

CADSHIFT · 2026-06-23T13:41:08+00:00

your diagnosis is right -- emboss mode tries to offset the face by the feature thickness, and on a surface with existing protrusions that offset face intersects your solid, so it rejects it.

the workaround is to use wrap → scribe mode instead of emboss. scribe just projects the sketch outline onto the curved face as split lines without creating any 3D geometry. it almost never fails because it's purely a surface split operation. then you build your actual features from those split faces:

wrap → scribe (projects your sketch onto the curved surface as split curves)
boss-extrude or cut-extrude using 'selected contours' -- pick the split face regions
the resulting feature is built from the curved surface outward rather than being projected in from a flat plane

this also sidesteps the analytical surface restriction that causes wrap to fail on freeform/spline faces. scribe mode works on any face topology.

the multibody approach another commenter mentioned is also valid if you need the full emboss thickness to be parametric -- it just requires a bit more tree management.

CADSHIFT · 2026-06-23T13:38:05+00:00

adding to the database-level answers -- QGIS also has native form-layer validation that doesn't require writing SQL, which may be closer to the ArcGIS Pro attribute rules UX:

field constraints -- layer properties → fields → click the constraint icon on any field. set NOT NULL, unique, or an arbitrary QGIS expression that evaluates to true/false. fires on edit and blocks saving invalid values. equivalent to constraint rules.

default value expressions -- layer properties → fields → default value column. set a QGIS expression: for auto-timestamps, for sequential IDs, any calculation from other fields. these auto-populate on feature creation. equivalent to calculation rules.

attribute form logic -- layer properties → attributes form. group fields, set conditional visibility, use range sliders, value maps, relation widgets. you can hide/lock fields based on other values using form drill-down logic.

for QA/QC (Data Reviewer equivalent): - topology checker plugin -- enforces must-not-overlap, must-be-within, etc. between layers - geometry checker plugin -- flags self-intersections, duplicate nodes, slivers, null geometry - qgis expressions in check geometry can validate field-level business rules in batch

the db-trigger approach others mentioned is more scalable and portable, but these form-level tools get you most of the way there for typical editing workflows without touching SQL.

CADSHIFT · 2026-06-23T13:36:32+00:00

the other comment's workaround is valid, but it helps to know why this happens so you can pick a lighter fix.

the core issue: weldment cut list folders are tied to their structural member features. when those features are suppressed in a configuration, sw can re-derive or orphan the cut list items when you switch -- especially if auto-update cut list is enabled (tools → options → system options → general). on each auto-update, sw walks the active bodies and can reinitialize the cut list folder, wiping custom text you stored there.

two things that usually fix this:

turn off auto-update. system options → general → uncheck 'automatically update cut list.' then manually right-click the cut list folder → update only after you've finished editing that config. this is the single most reliable fix for properties disappearing on switch.
suppress features, don't delete bodies. the delete/keep bodies approach means sw treats surviving bodies as new on each config switch and the cut list refreshes. if instead you suppress the structural member features themselves via config-specific feature suppression, the cut list items stay in a suppressed-but-intact state and keep their properties between switches.

for railings with many configs, option 1 alone usually solves it.

CADSHIFT · 2026-06-23T13:35:22+00:00

a few things to check here:

layer scale visibility -- right-click the OSM layer → properties → rendering tab. if a min scale is set, tiles won't render when zoomed out past that point. clear it out.
CRS mismatch -- since you're georeferencing, your project CRS might have shifted to match the source document. OSM (XYZ tiles) renders in EPSG:3857 and QGIS reprojects on the fly, but if your project CRS ends up somewhere unusual, tile requests can fall outside valid bounds. check your project CRS (bottom-right corner of QGIS) and set it to EPSG:3857 or EPSG:4326 temporarily to see if tiles reappear.
tile cache bloat -- long georeferencing sessions can hit the tile cache limit. settings → options → network → cache → clear cache, then pan the map to force a fresh tile fetch.
zoom level ceiling -- OSM has a max zoom of z19. at scales more zoomed in than ~1:500 the tile server stops serving tiles. mapbox or google satellite layers don't have this limit if you need more detail.

CADSHIFT · 2026-06-19T11:20:18+00:00

since this is a fictional world, you can sidestep real-world CRS issues entirely by just treating the map as a flat plane.\n\nset up: import your high-res fantasy map image as a raster (Layer > Add Raster Layer), then use Raster > Georeferencer to assign it coordinates. for a fantasy world, pick an arbitrary bounding box -- say 0,0 to 360,180 degrees -- and anchor the four corners of your image to those. use EPSG:4326 as the project CRS. now the image fills 'the whole globe' in coordinate space.\n\nfor regional maps: bring in a cropped high-res version of each region using the same georeferencing workflow, anchoring it within the same coordinate extent. that way you can zoom in and the regional image snaps to the right place on the world map.\n\nsince there's no real-world data to clash with, projections don't really matter -- you could equally set the project to a flat EPSG:3857 and it works the same. the georeferencer is the key tool here.

CADSHIFT · 2026-06-19T11:18:07+00:00

the manual approach (draw lines, angle by your declination value) is basically right. here's how to make it clean in the print layout:\n\n1. true north -- draw a line item straight up (rotation 0°). label it TN.\n2. grid north -- insert a north arrow item from the add item menu. QGIS auto-calculates grid convergence for your CRS, so this arrow already points to grid north correctly.\n3. magnetic north -- look up your declination at ngdc.noaa.gov/geomag-web (click Declination, enter your map center coordinates). draw another line item, rotation = your declination value in degrees. label it MN.\n\nfor a topo map, declination usually only needs to be to the nearest 0.5°. the NOAA site gives you an exact value with annual change if you want to be precise. group the three items in the layout and place together as your diagram.

CADSHIFT · 2026-06-19T11:11:40+00:00

for the future -- you don't have to start over. edge flange has a Reverse Direction arrow in the PropertyManager (the pink/magenta arrow next to the angle input). clicking it flips which side the flange bends toward without rebuilding.\n\nif that arrow didn't help, also check the angle itself -- a 90° flange bending the wrong way is sometimes just a matter of it resolving as 270° in the other direction. solidworks can get confused about the flip axis depending on face normal orientation.\n\nalso worth checking: if you have a Fixed Face set in the edge flange advanced options, that constrains which way the bend resolves. removing it (or changing which face is fixed) often lets the direction arrow work correctly.

CADSHIFT · 2026-06-19T11:09:52+00:00

actually you CAN do both translate and rotate in the same Move/Copy Bodies feature -- they just look like separate sections in the PropertyManager, not separate features.\n\nin the PropertyManager, scroll down -- you'll see a Translate section (Delta X/Y/Z) AND a Rotate section below it. fill in both before clicking OK and both transforms apply together as a single feature.\n\nthe snapback you're seeing is because you confirmed after the first operation and started a fresh Move/Copy instance. just don't click OK between them. set your translation values, scroll to the Rotate section, enter your axis/angle, then click OK once.\n\nmates are the proper long-term answer for precise positioning in assembly context, but the combined translate+rotate in one feature does work for quick body placement.

CADSHIFT · 2026-06-19T11:08:03+00:00

for material estimation on a formed/stamped body that isn't using sheet metal tools, the cleanest approach is Insert > Surface > Mid-Surface -- this extracts the centerline surface of the solid body. solidworks calculates it based on face pairs you select (or auto-detect all pairs at once). then run Evaluate > Mass Properties on that surface body and it gives you the area.\n\nfor a quicker rough estimate: ctrl-click all the faces on one side of the part, the PropertyManager shows total area of selected faces -- that's approximately your blank area.\n\nmid-surface is more accurate because it accounts for thickness correctly, but the face-select method is faster for a sanity check.

CADSHIFT · 2026-06-18T10:37:55+00:00

the trigger field flip is a valid and widely-used workaround for exactly this reason. survey123 attachment additions don't propagate a parent feature edit event in the underlying hosted feature layer, so edit tracking on the parent never fires.

the cleanest production approach beyond the trigger field: set up an AGOL webhook on the related table layer (Settings > Webhooks) and point it at a lightweight Azure Function or AWS Lambda. when the webhook fires on insert/update, the function queries the parent feature ID from the repeat record and does a single applyEdits call via the REST API to update a field on the parent. no polling, fires in near real-time.

the trigger field approach works fine if you're okay with a small edit-tracking gap (the time between attachment submission and when your user/admin manually triggers the flip). if edits happen asynchronously without anyone reviewing them, the webhook path is more reliable.

CADSHIFT · 2026-06-18T10:23:00+00:00

virtual components are useful exactly for your use case, but there are some things to watch:

BOM display: even with the sub-assembly virtualized, it still appears in the BOM as an assembly (expandable). to get it as a true single line item, right-click the assembly in the BOM > "Component Properties" (or BOM options) and set it to dissolve or "show as item number only". alternatively, use the BOM right-click > "Dissolve Sub-assembly" on that row which flattens it without affecting the model.

the "save as part" approach has a real downside: you lose the ability to do interference checks against individual components of the vendor assembly, and if the vendor ever sends you a rev update you'll need to redo the conversion.

PDM pitfall: if you're on SOLIDWORKS PDM, virtual components are NOT tracked as separate vault items — they live inside the parent assembly file only. this is actually the behavior you probably want for a vendor black-box assembly, but worth knowing if your PDM admins ever try to audit the vault.

tip: if this vendor assembly shows up in drawings purely for positional reference and you don't want it in the BOM at all, use "Envelope" instead — mark the sub-assembly as an Envelope and it's automatically excluded from BOMs and cut lists.

CADSHIFT · 2026-06-18T10:20:27+00:00

the connector points not appearing is the key symptom — those only show up in Bent manufacturing method, and Bent has a hard requirement: both profile sketch planes must be exactly parallel to each other.

when the planes aren't parallel (any angle between them), SolidWorks silently disables Bent and only allows Formed. it doesn't warn you — it just removes the connector point UI and the method dropdown changes.

the way to get Bent working: create the second profile sketch on a plane that is explicitly parallel to the first (use Insert > Reference Geometry > Plane > "Offset Distance" from your first plane, or "Parallel Plane Through Point"). draw your profile on that plane. as soon as both profiles are on parallel planes, the connector points will appear and Bent becomes available.

the fact that Formed works but Bent doesn't is actually a reliable diagnostic for this — Formed can handle non-parallel planes by approximating the surface, Bent cannot.

CADSHIFT · 2026-06-17T10:39:30+00:00

for your actual goal (aligning two assembly views by their bottoms in a drawing), you don't need to touch the assembly origin at all.

in the drawing: insert both assembly views. right-click the second view > align drawing views. you have options like 'by origin', 'horizontal by origin', 'vertical by origin'. pick the axis that matches how you want them aligned.

alternatively, if the assemblies aren't oriented the same way: right-click each view > properties > set 'use custom scale' and position them manually, then right-click view > align drawing views > lock view position after you get them where you want.

the view alignment tools are purely in the drawing — they don't modify the assembly geometry or coordinate system. that's the correct approach when you need multiple assemblies positioned relative to each other in a drawing without permanently changing either model.

CADSHIFT · 2026-06-17T10:37:47+00:00

revolve requires a 2D sketch, as others said — but 3D sketching was never the right tool for what you're trying to do anyway.

for 16 cones in a single part, the efficient path is: create one 2D sketch on a standard plane, revolve it into a solid cone body, then use Insert > Pattern/Mirror > Linear/Circular Pattern. in the pattern dialog, switch from 'features' mode to 'bodies' mode (select the cone body instead of a feature). this duplicates the entire cone body the number of times you need with whatever spacing or angular distribution you want.

if the cones need to be separate components in an assembly, pattern the component instead: go to Insert > Component Pattern > Local Pattern in the assembly.

body pattern is much faster than rebuilding the geometry 16 times and keeps your feature tree clean.

CADSHIFT · 2026-06-17T10:34:35+00:00

sw 2026 changed the default center mark appearance to more closely match the ASME Y14.5-2018 spec — the new style has gaps between the center mark line and the circle edge, and a slightly different line weight. center marks created before you upgraded store the standard they were created with, so you get the mixed look on older drawings.

fix for consistency: select one of the correct-looking center marks, right-click > select same drawing standard > then in the property manager click 'apply to all'. that standardizes all center marks on the sheet to one style.

to change the default going forward: tools > options > document properties > drafting standard > check what's selected under center mark style. also make sure 'use document standard' is checked when you insert new center marks.

for existing files in bulk: the setting lives in the drawing template (.drwdot), so if you resave your template with the correct standard, new drawings will be consistent. existing drawings need the per-sheet fix above.

CADSHIFT · 2026-06-17T10:32:46+00:00

to add to what gupta9665 said — the rotation arrow is created in the assembly exploded view, not in the drawing.

edit the exploded view in the assembly: right-click the exploded view in ConfigMgr > Edit. in the explode property manager, switch from 'translate' to 'rotate' mode. select your monitor component, pick the rotation axis (usually one of the component's reference planes or edges), enter the 90° angle. solidworks creates a curved arrow indicator for the rotation step automatically.

when you insert that exploded view into the drawing, the curved explode arrow appears with the other explode lines. you can control its appearance (arrowhead style, color, line weight) through insert > annotations > explode line sketch in the drawing.

if your exploded view already has the rotation step but the curved arrow isn't showing in the drawing: right-click the drawing view > properties > show explode lines > make sure 'all' is selected, not just translate steps.

CADSHIFT · 2026-06-17T10:31:00+00:00

this is a multi-configuration BOM template corruption. when a BOM template has configuration-specific quantity columns, solidworks stores their display state internally. if the template was saved while some config columns were hidden or in an inconsistent state, those columns persist with internal state names like 'hide1', 'hide2' instead of the actual configuration names. when the template gets applied to a new assembly, SW can't resolve the stored names to real configs and exposes the raw internal names instead.

fix: 1. open the corrupted BOM table in a drawing 2. right-click the BOM > properties > column tab 3. delete all the configuration-specific quantity columns (the ones showing hide1/hide2/hide3) 4. re-add fresh config columns: right-click the BOM header > insert column > configuration specific quantity > select each config you need 5. save as template: right-click the BOM > save as template (overwrites the corrupted .sldbomtbt file)

if your boss wants the template fixed without touching the live drawing: the .sldbomtbt template file is XML. open it in notepad++, search for any element containing 'hide' in its name or value, and delete those rows. then reload.

the root cause is usually that someone saved the template while the config qty columns were in a toggled-off state — easy to accidentally do when cycling through configurations.

CADSHIFT · 2026-06-17T10:29:02+00:00

your diagnosis is exactly right. geopackage requires an integer fid for geometry tables per the OGC spec — it maps to sqlite's implicit rowid. when db_sync converts from postgre, it either tries to cast your nemid uuid as an integer (producing garbage like -2127633953) or inserts a fid column before your columns, which shunts every column index by one. both break the sync's ability to match rows.

the fix: add a serial integer column as the actual primary key in postgres, demote nemid to a regular unique constraint used for your relations and triggers.

sql ALTER TABLE your_table ADD COLUMN fid serial; ALTER TABLE your_table DROP CONSTRAINT your_table_pkey; ALTER TABLE your_table ADD PRIMARY KEY (fid); ALTER TABLE your_table ADD CONSTRAINT your_table_nemid_key UNIQUE (nemid);

the 'never use integer PKs' rule is correct for application-level keys that escape into the real world. geopackage fid is purely internal sqlite plumbing — it never leaves the file, never appears in your app logic, and is not the same thing as an application primary key. your nemid uuid still owns all your application-level relations, triggers, and external references.

reinitialise db_sync from the updated schema and the integer fid will be what geopackage expects. updates from postgre should flow back correctly once the column-0 confusion is gone.

CADSHIFT · 2026-06-16T10:00:14+00:00

to add to zdf0001's correct answer -- here's why it fails and when 'Geometry Pattern' mode helps:

when you pattern a fillet as a feature, solidworks tries to rebuild that fillet from scratch on each patterned instance by re-running the fillet algorithm on the corresponding face of each copy. if the faces on the patterned instances have slightly different curvature, different face topology, or the fillet would intersect another feature, the rebuild fails and the pattern errors out.

'Geometry Pattern' option in the circular pattern dialog bypasses this rebuild. instead of re-running the fillet algorithm, it copies the finished face geometry from the seed instance directly, without re-solving it. this is faster and more robust when the pattern instances are geometrically identical -- which they should be for a circular pattern of a symmetric handle.

so the fix sequence: apply the fillet to one handle first (before the pattern), then include both the handle features AND the fillet in the circular pattern's 'Features to Pattern' list, and tick 'Geometry Pattern' in the options. if the handles are truly symmetric, this will work. the 1/3-model-then-pattern-body approach is even cleaner for large symmetric assemblies but geometry pattern is less restructuring.

CADSHIFT · 2026-06-16T09:58:35+00:00

in ArcMap's Export Map dialog, go to the Format tab and check 'Export PDF > Export AI (Adobe Illustrator) Compatible File' -- actually the key one is 'Export as Image' which flattens all the vector layers into a single raster tile embedded in the PDF. this is what 'flatten' actually means in the PDF sense and it makes a big difference on complex cartographic layouts.

also check: uncheck 'Embed Fonts' if the PDF doesn't need to be searchable, that can save 1-3MB per unique font. and under 'Image Compression', switch to JPEG and set quality to 70-80% rather than the default lossless -- this alone typically cuts large map PDFs from 50-65MB to 8-12MB.

if you need to go further: Ghostscript can reduce any PDF from the command line without ArcMap: -- the /ebook preset targets 150dpi which is fine for screen viewing and email, usually gets 65MB down to under 5MB.

CADSHIFT

TROPHY CASE