Jump to content

referenced layers spontaneously move origin


Recommended Posts

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)

Link to comment

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."

  • Like 1
Link to comment

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.

Link to comment
  • 7 months later...
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?

Link to comment
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.

Link to comment
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.

Link to comment
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 by Diamond
Added Vectorworks SP info
Link to comment
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).

 

  • Like 1
Link to comment
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.

Link to comment
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.

Link to comment
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.

Link to comment
  • 1 month later...
  • 1 month later...

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

Link to comment
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

Link to comment
  • 3 months later...
  • Vectorworks, Inc Employee
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.

Screen Shot 2017-05-25 at 3.26.36 PM.png

Link to comment

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

Link to comment
  • 3 weeks later...

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.

Link to comment

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.

Link to comment

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...