Art V Posted March 25, 2016 Share Posted March 25, 2016 We are finding that it is not the references that are changing orgin but the file itself is having its user origin changed. Still happening in 2016 SP2 - though the files are older. This is my experience too from the few times I ran into this issue. Which is why I make sure that all files have their origins, page and coordinate system aligned with the internal origin of the file. Especially after a dwg import an user origin shift can happen and I always re-align it to the internal origin. This seems to solve 99.9% of my shift issues with referenced files. (The 0.1% is for those occasions where it does not solve the issue but I have not yet encountered) Quote Link to comment
P Retondo Posted March 25, 2016 Share Posted March 25, 2016 Had this issue in v2015, reported it as a bug back then, but what exactly causes the shift is still a question for me. Do what Alan says - reset all your origins to the internal origin. Once I did that thoroughly, the issue has not re-occurred. Don't give in to expedience by moving the referenced viewport to correct the problem, it just gets worse. Tools-> Origin -> User Origin -> "Set User Origin to Internal Origin". Jim, unless this is fixed it makes setting a user origin a dangerous thing to do in any file which is part of a multi-file project. I can only imagine what it would do in the new project-sharing environment. As a general comment, often-repeated and probably just as often resented by VW engineers, I would much rather have NNA spend coding time making all these basic tools rock solid than have some new (probably not really useful) trick feature. Just add some code to the function that moves the origin to prevent it's being moved without notifying the user and verifying the intent. That way, whatever obscure combination of events calls the function, it can never be executed without "authorization." 1 Quote Link to comment
Tom Klaber Posted March 31, 2016 Share Posted March 31, 2016 We localized the problem. It does relate back to rotated plans. The user origin shifts while in rotated plan - and the act of referencing in or updating a reference then reset the user origin to the rotated position. 1 Quote Link to comment
P Retondo Posted March 31, 2016 Share Posted March 31, 2016 Tom, thanks very much for tracking that down. Many hours were spent dealing with this problem. It's up to VW to fix this very avoidable issue. I remember when rotated plan was being developed, and I pleaded with them to isolate the rotated plan concept to avoid this very kind of problem. To no avail. What is rotated plan? In essence, it's rotating the screen view and orienting orthogonal tools to the rotated coordinate system. If they had just focused on that instead of messing with geometry fundamentals, none of this kind of thing could have occurred. Quote Link to comment
gfp38 Posted November 4, 2016 Share Posted November 4, 2016 I'm running Fundamentals 2017 SP1 and having problems with the XREF user origin jumping way off from where it should be. This has happened about 6 or 7 times since upgrading to 2017. Is this a know issue for 2017? Quote Link to comment
Tom Klaber Posted November 11, 2016 Share Posted November 11, 2016 Does it jump after you update the xref? or does it jump even if there is no new xref? Quote Link to comment
Art V Posted November 13, 2016 Share Posted November 13, 2016 On 04/11/2016 at 4:54 PM, gfp38 said: I'm running Fundamentals 2017 SP1 and having problems with the XREF user origin jumping way off from where it should be. This has happened about 6 or 7 times since upgrading to 2017. Is this a know issue for 2017? In addition to Tom's questions, is this on 3rd party provided files or on files you created yourself or from converted older files? Quote Link to comment
gfp38 Posted November 13, 2016 Share Posted November 13, 2016 17 minutes ago, Art V said: In addition to Tom's questions, is this on 3rd party provided files or on files you created yourself or from converted older files? Files I've created myself. Quote Link to comment
gfp38 Posted November 13, 2016 Share Posted November 13, 2016 On 11/11/2016 at 3:47 PM, Tom Klaber said: Does it jump after you update the xref? or does it jump even if there is no new xref? No. When I open a drawing, the origin has moved along way away. Oddly, not all the referenced files move, but the ones that do, have moved in relationship to the new origin position. I then reset my user origin, open the 'Organisation' box, select the ref files and update them. Then my drawing is all back together again. Quote Link to comment
Art V Posted November 13, 2016 Share Posted November 13, 2016 6 minutes ago, gfp38 said: No. When I open a drawing, the origin has moved along way away. Oddly, not all the referenced files move, but the ones that do, have moved in relationship to the new origin position. I then reset my user origin, open the 'Organisation' box, select the ref files and update them. Then my drawing is all back together again. The best way to solve x-ref origin issues is to have all origins of all used files to align with the internal origin. This could cause your drawing to end up being far away from the internal origin but in my experience this is the best way to avoid origins/x-ref shifts to occur. Quote Link to comment
Diamond Posted November 13, 2016 Share Posted November 13, 2016 (edited) 17 hours ago, Art V said: The best way to solve x-ref origin issues is to have all origins of all used files to align with the internal origin. This could cause your drawing to end up being far away from the internal origin but in my experience this is the best way to avoid origins/x-ref shifts to occur. Whist that might address this bug, it doesn't help when working in a BIM world. When you are working with geo-referenced surveys, or surveys using a local datum (often km's away from the site) this is not an option. Each discipline should be working to the survey as the master setout. And what happens if the survey is updated, which is a common enough occurrence on my projects. On 01/04/2016 at 2:00 AM, Tom Klaber said: We localized the problem. It does relate back to rotated plans. The user origin shifts while in rotated plan - and the act of referencing in or updating a reference then reset the user origin to the rotated position. Good to know this Tom. I has suspected it, but had not had time to do further digging. I have noticed this on two recent projects using project sharing, running 2016 SP4. I will run some tests today and see if I can confirm this conclusion. Regarding a possible secondary cause of this problem, do you have any objects further than the 4.5km distance from the internal origin? Just checking, because I have found this to be the true cause of all types of underlying Vectorworks problems. And finally – to get around this, have you been switching to an unrotated top/plan view, and then updating the reference? Thanks. Edited November 13, 2016 by Diamond Added Vectorworks SP info Quote Link to comment
Art V Posted November 14, 2016 Share Posted November 14, 2016 19 hours ago, Diamond said: When you are working with geo-referenced surveys, or surveys using a local datum (often km's away from the site) this is not an option. Each discipline should be working to the survey as the master setout. And what happens if the survey is updated, which is a common enough occurrence on my projects. Copying my reply to someone else in another topic: "When importing the dwg file containing the survey make sure that in the location tab of the import dialogue you set the option " Align with internal origin" . That way the 0,0 of your survey will align with the internal origin of your document an shifts or your origin should not occur. Upon (re)importing updated files and maintaining this setting it should import at the proper location. The "downside" is that the survey may end up (hundreds of) miles away from your internal origin. Shapefiles should already import aligned with the internal origin of the document provided you did set up the georeferencing properly. Rule of thumb for working with georeferenced files... make sure all origins of all documents are aligned with the internal origin and then leave it alone, that should prevent shifts of the origin, especially if you are referencing files." If the survey is the basis for all drawings then the above does apply, as it also means everyone should be working at actual/real coordinates and not some local 0,0,0 at the corner of the construction site. If you have to reference to the construction site local grid then you'll have to meddle with the survey origin etc. and will have a risk of drawings shifting as you are experiencing now. I wouldn't worry too much about your survey being kilometres/miles away from the origin, as in my experience this does not really cause much issues unless you are dealing with extremely large drawings or with lots of polygons having lots of nodes (or a combination of both). 1 Quote Link to comment
Diamond Posted November 15, 2016 Share Posted November 15, 2016 On 15/11/2016 at 1:22 AM, Art V said: Rule of thumb for working with georeferenced files... make sure all origins of all documents are aligned with the internal origin and then leave it alone, that should prevent shifts of the origin, especially if you are referencing files." I keep the site files set to survey origin, but each building has it's own origin and it asserted into the site. Our studio employs designers and architects, and wherever I have worked, these types generally struggle with drafting technique. Drawing at right angles is angles is a challenge, and so working to obscure rotated angles may be a bridge too far. Quote Link to comment
Art V Posted November 16, 2016 Share Posted November 16, 2016 11 hours ago, Diamond said: I keep the site files set to survey origin, but each building has it's own origin and it asserted into the site. Our studio employs designers and architects, and wherever I have worked, these types generally struggle with drafting technique. Drawing at right angles is angles is a challenge, and so working to obscure rotated angles may be a bridge too far. Could it be an option to set the building origin at survey coordinates relative to the internal origin. Then set the user origin to the building origin while working on the drawing and once work has finished reset the user origin to the internal origin before referencing or updating the reference? If the survey coordinates are rotated relative to the building you could use rotated plan view if they are working in VW. It is a workaround that shouldn't be necessary, but it might mitigate your issue a little bit. Though it will depend on how often you have to update references whether this is a doable workaround. Quote Link to comment
Diamond Posted November 16, 2016 Share Posted November 16, 2016 Thanks for that, but that sounds harder. For the moment I am telling my team, switch to an un-rotated top/plan view before they update their references. Quote Link to comment
Art V Posted November 17, 2016 Share Posted November 17, 2016 21 hours ago, Diamond said: For the moment I am telling my team, switch to an un-rotated top/plan view before they update their references. If that solves the issue for you then this is definitely the easier way to go as it avoids setting/resetting origins which always has a risk of being off a little bit if not done properly. Quote Link to comment
anton5 Posted January 4, 2017 Share Posted January 4, 2017 We are having the same issue, and we are on SP 4 vector works 2016.... any suggestions? kind regards Quote Link to comment
zoomer Posted January 4, 2017 Share Posted January 4, 2017 That may be irrelevant in that case, but for VW 2016 there is already a SP 6, which finally gives OS X Sierra Support and some further bug fixing. Quote Link to comment
anton5 Posted February 9, 2017 Share Posted February 9, 2017 We just upgraded one of our projects (including all reference files/sheet files etc) to 2017 SP2 from 2016 SP6, and without changing any information (basically just save as 2017vw), the user origin (from working file to sheet files) has shifted in a majority of our drawings. We have 5 point buildings, each in their own VW file, and 2 podium in separate files, all referenced into sheet files. This is very frustrating as there doesn't seem to be a logic behind it. As some of the sheet files (for individual blocks) shows up fine, with correct user origin, but in others, like site wide plans the building / parts of bldg has shifted... Any new help suggestions would be much appreciated. Frustrated VW2017 user... kind regards a Quote Link to comment
AlanW Posted February 10, 2017 Share Posted February 10, 2017 On 23/11/2014 at 10:09 PM, Alan Woodwell said: Hi, I had this issue where one of the xrefed drawing viewports moved and we found that we fixed it by resetting the 0,0 point back on the reference drawing that moved. and reopened the drawing or refreshed the viewport reference and it came back to the original position. Don't try moving the drawing back. Just make sure they all have the same 0,0 point. Hope this helps. Hi, try this to fix the problem. No reason was ever found for the reason the files shifted, but this fixed the issue. Also just make sure nothing that is references is a few 100 miles from the VW origin. HTH Quote Link to comment
Vectorworks, Inc Employee BNicholson Posted May 31, 2017 Vectorworks, Inc Employee Share Posted May 31, 2017 On 11/14/2016 at 7:22 AM, Art V said: Copying my reply to someone else in another topic: "When importing the dwg file containing the survey make sure that in the location tab of the import dialogue you set the option " Align with internal origin" . That way the 0,0 of your survey will align with the internal origin of your document an shifts or your origin should not occur. Upon (re)importing updated files and maintaining this setting it should import at the proper location. The "downside" is that the survey may end up (hundreds of) miles away from your internal origin. Shapefiles should already import aligned with the internal origin of the document provided you did set up the georeferencing properly. Rule of thumb for working with georeferenced files... make sure all origins of all documents are aligned with the internal origin and then leave it alone, that should prevent shifts of the origin, especially if you are referencing files." If the survey is the basis for all drawings then the above does apply, as it also means everyone should be working at actual/real coordinates and not some local 0,0,0 at the corner of the construction site. If you have to reference to the construction site local grid then you'll have to meddle with the survey origin etc. and will have a risk of drawings shifting as you are experiencing now. I wouldn't worry too much about your survey being kilometres/miles away from the origin, as in my experience this does not really cause much issues unless you are dealing with extremely large drawings or with lots of polygons having lots of nodes (or a combination of both). I had the same issue when setting up my current project file and found that "Align with Internal Origin" kept the origin of the civil engineering base file intact. The 'downside' of having the drawing objects miles away from the origin is revealing itself in the graphic display of my 3D objects. This is something that I have experienced in SketchUp as well and makes collaborating on a multi-disciplinary team challenging. I attached a file showing how my raised planters were getting clipped and some elements appear to be floating. A previous firm I worked for used Revit for architecture models and they created a collaboration worksheet which identified the real-world coordinates and rotation and placed a graphic marker at this location. Their process was to then move all live linework closer to 0,0 and export the file to the real-world coordinates and rotation or move linework back to the graphic marker. It sounds complicated but there were 6 separate firms sharing Revit models and AutoCad files and this kept everything lined up. Just wanted to share my current and previous experience if it helps. Quote Link to comment
anton5 Posted June 1, 2017 Share Posted June 1, 2017 A temporary solution (using VW2017 sp3) we've found is to when updating references, keep the working layers unrotated (i.e. to '0' degrees), and your referenced in viewports should hopefully shift back into place, at least they did that for three of our projects. So happy days ;-) kind regards anton Quote Link to comment
gfp38 Posted June 23, 2017 Share Posted June 23, 2017 Our Vectorworks project has been problem-free. Well, I meant in terms of the user origin jumping miles from where it should be. Problem-free until last week when a colleague updated one of the referenced plan files, saved it and lo and behold, it's way off when the master plan references it back in. I don't know if it's anything to do with Dropbox; I don't think so. Perhaps something to do with my colleague using a PC whereas I use a Mac? I'd love to get to the bottom of this. Quote Link to comment
anton5 Posted June 26, 2017 Share Posted June 26, 2017 is the layers rotated to '0' degrees when updating the referenced link? kind regards anton Quote Link to comment
gfp38 Posted June 26, 2017 Share Posted June 26, 2017 Anton, No, we're all working in Vectorworks Fundamentals so don't have that luxury. We could be working on the project, updating drawings through Dropbox for weeks without a glitch, but then get this origins problem. I need to try and track which designer is upsetting the XREF setup. Latest thought is that a particular designer is using VW 2017 on PC whereas the rest of us are on macs. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.