Jump to content
  • 1
JJe

Snapping to geometry in referenced layers in rotated plan view not working VW2017

Question

I have a referenced drawing (from an external source) and snapping to that geometry only works when the plan rotation is set to 0.00 degrees.

Anyone else have the same problem?

Share this post


Link to post

16 answers to this question

Recommended Posts

  • 0

I don't have this issue in VW 2017, it snaps to referenced layers when in rotated plan view.

 

You may have to wait a little bit before the snap activates as there can be a small delay depending on file size etc.

 

What format is the referenced file? e.g. Vectorworks, dwg, pdf?

 

What version of Vectorworks are you using and on Mac or Windows?

Edited by Art V

Share this post


Link to post
  • 0

Hi, I'm having the same issue.

It seems to be a combination of user origin set to a large distance and plan rotation that breaks snapping in 2017. I have attached a 2016 and 2017 version of the same file that works in 2016 (SP4 Build 315580 Mac 64-bit) but not in 2017 (Build 327801 Mac 64-bit) .

In the file called reference the user origin is set to 530000000, 180000000 (central London in UK OS Coordinates in mm) objects are at an angle (assuming true north is +Y). This file is then referenced in to the file called master as a design layer viewport. In 2016 snapping works equally well if plan rotation is 0 or if its set to the rotation of the geometry. In 2017 the snapping works with 0 rotation but not otherwise.

 

Hope anyone else is able to replicate this.

 

Thanks,

Tobias

Master v2016.vwx

Master v2017.vwx

Reference v2016.vwx

Reference v2017.vwx

Share this post


Link to post
  • 0
2 hours ago, Tobias J said:

Hi, I'm having the same issue.

It seems to be a combination of user origin set to a large distance and plan rotation that breaks snapping in 2017. I have attached a 2016 and 2017 version of the same file that works in 2016 (SP4 Build 315580 Mac 64-bit) but not in 2017 (Build 327801 Mac 64-bit) .

In the file called reference the user origin is set to 530000000, 180000000 (central London in UK OS Coordinates in mm) objects are at an angle (assuming true north is +Y). This file is then referenced in to the file called master as a design layer viewport. In 2016 snapping works equally well if plan rotation is 0 or if its set to the rotation of the geometry. In 2017 the snapping works with 0 rotation but not otherwise.

 

Hope anyone else is able to replicate this.

 

I can confirm the issue of not snapping in VW2017 in your. However... I also noticed it is not possible to normally select the referenced viewport by clicking on it whereas I can do this with my drawing with a referenced viewport in VW2017. In your file I have to use a selection window or select all to be able to select your viewport.

 

It seems to me that the issue of not being able to snap to the reference viewport may be tied to not being able to select it directly.

 

So I created a new reference in VW2017 to the reference file using the create viewport method (not through the organization palette/window), selected the source file and then rotated the plan view and set the user origin to the lower left corner of the referenced viewport on the design layer.

Then snapping worked just fine.

Edited by Art V

Share this post


Link to post
  • 0
1 hour ago, Art V said:

 

I can confirm the issue of not snapping in VW2017 in your. However... I also noticed it is not possible to normally select the referenced viewport by clicking on it whereas I can do this with my drawing with a referenced viewport in VW2017. In your file I have to use a selection window or select all to be able to select your viewport.

 

It seems to me that the issue of not being able to snap to the reference viewport may be tied to not being able to select it directly.

 

So I created a new reference in VW2017 to the reference file using the create viewport method (not through the organization palette/window), selected the source file and then rotated the plan view and set the user origin to the lower left corner of the referenced viewport on the design layer.

Then snapping worked just fine.

 

Thanks for confirming. Im not sure I quire follow your workaround.

I have created a new reference from View > Create Viewport... and selecting the reference file as external source. The new viewport is created as expected at 530000000, 180000000 and snapping works correctly regardless of plan rotation.

The reference is however very far form the internal origin and as I understand it this is not where you want to do your drawing (due limitations of floating point numbers). One option is to move the reference close to the internal origin however this brings back the snapping issues. The other option is to set the user origin in the master file to be the same as the reference bringing the viewport close to the internal origin with snapping intact. 

 

The use case I'm replicating is having a OS Map / Survey drawing in one file (reference in example) in the correct position to be able to give eastings and northings using the stake tool. The building would be drawn in a separate file (master in example) close to the internal origin and drawn orthogonally to x and y.  The site file needs to be able to be referenced from the building file. 

I am relatively new to VW so maybe I'm going about this the wrong way. Is it the case that all files used in a multi file project have to have the same user origin? Does the workflow I describe make sense or is there a different way I should go about it?

 

Thanks again.

Share this post


Link to post
  • 0

Hi you will possibly find that if yo have anything more than a few miles away from your origin (Like survey points) it causes all manner of issues with the program Have had windows disappearing all the 3D model goe drastically pixilated, Lines moving way off etc. After a number of discussions with OzCad the answer was to delete those items way of and everytime the file responded normally again.

HTH

Share this post


Link to post
  • 0
1 hour ago, Tobias J said:

The reference is however very far form the internal origin and as I understand it this is not where you want to do your drawing (due limitations of floating point numbers). One option is to move the reference close to the internal origin however this brings back the snapping issues. The other option is to set the user origin in the master file to be the same as the reference bringing the viewport close to the internal origin with snapping intact. 

This should not really be an issue, I'm hundreds of kilometres away from the origin and have not experienced snapping problems since VW 2014/2015 so I would not worry about this.

 

I'll repeat what I've said in other discussions :) .... if you are working with (properly) georeferenced drawings make sure the internal origin and user origin are aligned otherwise you may get problems with coordinates etc. when exporting.

Also make sure that when you are using rotated plan, unrotate before doing any exports in that case.

Also, adjusting unit may help a little, i.e. use metres instead of millimetres.

 

1 hour ago, Tobias J said:

The use case I'm replicating is having a OS Map / Survey drawing in one file (reference in example) in the correct position to be able to give eastings and northings using the stake tool. The building would be drawn in a separate file (master in example) close to the internal origin and drawn orthogonally to x and y.  The site file needs to be able to be referenced from the building file. 

I am relatively new to VW so maybe I'm going about this the wrong way. Is it the case that all files used in a multi file project have to have the same user origin? Does the workflow I describe make sense or is there a different way I should go about it?

 

If you are working with georeferenced drawings, have the origin of the coordinate system and the user origin aligned with the internal origin of the document. Moving any reference location to the document origin and then set the user origin to compensate for that shift so that your location's coordinates will be near the document origin will mess with your projection. Depending on how critical the coordinates are this may be equal to asking for major trouble down the road.

 

When using multiple files and using references, again it is best to have all critical files to use the same origin and georeferencing, if only for making sure you have your coordinates correct and to make sure when copy/paste items they will end up at the right coordinates..

 

An alternative can be to create a local coordinate system (e.g. a site coordinate grid) and provide a reference to the georeferenced coordinate system. E.g. 0,0 m of the site coordinate system is 756000, 1000000 m in the georeferenced system. Then you could work with a local grid system. This will work if your site is relatively small, .e.g a square kilometre may work. For larger areas I suggest you check with a geodesist and the client on how critical the coordinates are.

Share this post


Link to post
  • 0

I have the same problem as well referencing floorpans into a site layout and only being able to snap when the page orientation is set to 0 - This did not happen in VW 2015 or VW2016.  I have checked and the site plan is geo-referenced (as it should be) and each of the houses are drawn at the origin points on their own file (or very close to).

 

I could create a local coordinate system, but I am not convinced that that will fix an error in the software.  Once you move off a grid, it is very easy to forget the transposed coordinates (especially if there is more than one person working on the project - as I have in my office).  I would also be unable to issue setting out coordinates as the setting out coordinates are generated from the site plan which is based on the OS grid. Also when registering new properties with the keeper (Register of Scotland), I am required to issue a dwg file with all properties and boundaries located on an OS grid - so a local grid cannot be used.

 

There is definitely a graphics problem with VW2017.

Share this post


Link to post
  • 0

@Kevin C

It could be that the file conversion from 2016 to 2017 has caused an issue, though I have not yet noticed this issue with my files so far.

 

When using @Tobias Joriginal file the snapping didn't work, but I could not simply select the viewport either with the pick/selection tool by clicking on it, so it could be a conversion issue.

When using his VW2017 reference file and use a blank VW drawing to create the referenced viewport, the snapping worked just fine, regardless of what I did to change the user origin or move things etc.

 

Are your problem files conversion from VW2016 (or older) to VW2017 or new VW 2017 files? If they are conversions then there might be a bug somewhere with that.

 

I agree creating a local coordinate system is not the best way to handle this, and I wouldn't to that myself as a first option but if it helps to get the job done and things are turned back into the original coordinate system when delivering the information then it could be a workaround until the issue gets solved.

Share this post


Link to post
  • 0

@Art V

 

The issue is with converted files - Ie live projects.  I do not have the time to "test" scenarios - that is what the software development is for.

 

For projects which are in an early design stage, yes workarounds are a possible solution as you do not need to get production information out to tender or site and have to worry about everything being coordinated. But for projects which are live and information has to be issued it is not acceptable for temporary solutions to be proposed.

 

There are a couple of nice features in VW2017, but the bugs in the system at the moment mean to me that they are just not worth it.  Take the resource browser for example, to use it to its full potential it it has to sit as a floating palette and take up a large portion of the workspace, but to use it on a day to day basis - it really has to be docked which means that access to the additional funtions is extremely limited - unless you have massive or multiple screens (I'm working of a 27" iMac).  Also - what has happened to the startup interface - I don't want to see a hazed over desktop it is very annoying to the eyes - I want to be able to access my desktop when I don't have drawings open, leave it as clear space please or blank it out !!

 

I was also very exited to see a specific handrail / railing tool as this is something which VW has been lacking for ever, until I tried it - it works well as a standalone tool but is useless for use inside a building if you want to link a stair and landing balustrade. Say you start at the bottom of a stair go up to top of the stair and continue along the landing and return into a wall, pretty standard stuff, but the tool does not attach between levels and stories, and will not go up a stair - WHY!!!

 

I am very quickly coming to the conclusion that VW2017 in its current form is broken and I may have to export all my live projects back to 2016 and uninstall VW 2017 until this problem is sorted - Just as well the batch file conversion facility doesn't work this year or I would have been more angry with this upgrade than I am at the moment.

Share this post


Link to post
  • 0
48 minutes ago, Kevin C said:

For projects which are in an early design stage, yes workarounds are a possible solution as you do not need to get production information out to tender or site and have to worry about everything being coordinated. But for projects which are live and information has to be issued it is not acceptable for temporary solutions to be proposed.

 

I agree, at the moment sticking with 2016 seems like the way forward at least for running projects, at least for now. 

Thanks everyone whose taken the time to confirm the issue and suggest workarounds.

 

@JimW Could you log this as a bug please. Also what's the current (2016/2017) best practice on working to OS coordinates, this thread suggests a few options; user origin, draw far away from the internal origin, create a local coordinate system (keep track of offset external to VW).

 

Thanks

Tobias

Share this post


Link to post
  • 0
1 hour ago, Tobias J said:

@JimW Could you log this as a bug please. Also what's the current (2016/2017) best practice on working to OS coordinates, this thread suggests a few options; user origin, draw far away from the internal origin, create a local coordinate system (keep track of offset external to VW).

Though I'm not JimW I have discussed this with people working in geomatics as well a a senior geodesist and they confirmed my experiences with VW, it boils down to whether you are working with a projected coordinate reference system (CRS) or a cartesian coordinate system without projection.

 

Translated to Vectorworks:

1. In general, if you are working with a projected CRS: make sure all origins align with the internal origin of the vectorworks document and do not touch/change/modify the CRS in any way (i.e. do not shift things around and set the user origin to something else than the internal origin of the document. Work at coordinates, even if that means you will be far away from the internal origin.

 

2. If you are working with a projected CRS and accuracy of coordinates is not critical (i.e. some deviation is allowed) and on a small area near the central meridian of the CRS you could (i.e. not should, but could) move things to the internal origin and shift the user origin and pretend there is no projection and in the end move things back to the original locations before exporting.

 

3. If you are working in a cartesian coordinate system without projection, you can do as you please with regard to user origin/internal origin as long as you keep track of coordinate shifts with your custom user origin etc.

 

The reasons for 1 and 2 are that a projection with a projected CRS may cause objects to be reshaped. The farther away you are from the central meridian the larger the "distorsion/reshape" effect of the projection. Shifting your user origin and objects to the internal origin will may your objects to be at the edge of the projected CRS (if not almost there) and may cause issues depending on how well Vectorworks can compensate for your " adaptations" (expect little or no compensation). Upon moving a reprojection may occur and things may start to deviate. Hence their advice for working with a projected CRS... align all origins with the internal origin of the Vectorworks document and then leave the projected CRS alone. Work at actual coordinates. This should avoid potential problems with exporting to e.g. shapefiles and other georeferenced formats or reading out data.

 

Granted, this was before VW implemented the EPSG catalog, and I don't know if there are any other under the hood changes to their GIS module's calculations etc. as I have not got to testing it yet, but the above advice would still be sound.

 

Also, when rotating a plan view, the horizontal/vertical coordinates change so before any export, undo the plan rotation (i.e. set it back to 0) otherwise your coordinates will not be accurate.

Share this post


Link to post
  • 0
3 minutes ago, Art V said:

1. In general, if you are working with a projected CRS: make sure all origins align with the internal origin of the vectorworks document and do not touch/change/modify the CRS in any way (i.e. do not shift things around and set the user origin to something else than the internal origin of the document. Work at coordinates, even if that means you will be far away from the internal origin.

 

2. If you are working with a projected CRS and accuracy of coordinates is not critical (i.e. some deviation is allowed) and on a small area near the central meridian of the CRS you could (i.e. not should, but could) move things to the internal origin and shift the user origin and pretend there is no projection and in the end move things back to the original locations before exporting.

 

3. If you are working in a cartesian coordinate system without projection, you can do as you please with regard to user origin/internal origin as long as you keep track of coordinate shifts with your custom user origin etc.

 

These recommendations are also the ones from engineering.

I could file this as a bug, but it would be bounced back or put on hold. Currently there is no way to address the problems that come from working far from the origin, there are theories as to how this could be fixed in the future, but for now it has to be handled via the above suggestions. This will almost assuredly not change in Vectorworks 2017 or even 2018 so adapting your workflow is necessary.

Share this post


Link to post
  • 0

Just to hopefully finish this one off.

  • None of my drawings are ever set up on a shifted user origin
  • When drawing site layouts (masterplans), the base drawing is always brought in as a OS Map in its original location and using the original units - metres (which is coordinated to actual GPS coordinates).  This will allow for a topographical survey to be directly reference in and it will be in the correct location.
  • The house block symbols are inserted - These are drawn as close to the 0,0,0 as possible with the bottom LH corner of the block usually set at 0,0,0

It is common (and I would say good) practice to rotate the view so that offsets can be made and be sure that they are all on the same plane.  also makes it easier for dimensioning and everything else if you don't have to skew your neck when looking at a drawing.

 

By drawing this way - you can be sure that everything is in its correct location (relative to GPS)

 

If I am setting up my drawings up wrongly - please tell me as I do not know how to set them up differently.

 

 

Share this post


Link to post
  • 0

Just installed SP1 hoping that this problem was fixed - NO it hasn't.  This is a serious issue. This problem did not exist is 2011,2012,2013,2014,2015,2016  - There has been a change to the graphics system.  This is not as simple as a bug - there is a fault in the software. Oh and BTW - the "Update catalogue" problem is still there to.

 

On 9/30/2016 at 3:50 PM, JimW said:

These recommendations are also the ones from engineering.

I could file this as a bug, but it would be bounced back or put on hold. Currently there is no way to address the problems that come from working far from the origin, there are theories as to how this could be fixed in the future, but for now it has to be handled via the above suggestions. This will almost assuredly not change in Vectorworks 2017 or even 2018 so adapting your workflow is necessary.

 

Jim,  It has been assumed that we are working far from the origin - This is not the case, your response is based on the drawings being set up incorrectly.  The drawings are set up correctly, the site plans (in my case) are either directly imported survey files or directly imported ordinance survey files.

 

The procedure which is carried out each time is as follows:

  1. Create a new drawing (without template)
  2. Import topo survey or OS Map (settings as per Screen Grabs) - The topo would be imported in 3D if it is 3D, but VW seems to prefer importing as full 2D files (quite often the surveyor thought a few 3D blocks into the drawing, this just makes everything 2D).

 

Screen Grab 1.pngScreen Grab 2.png


 

  1. Go into the class settings and turn off the solid fill on every class (why are classes filled by default??) and then change pen settings to what I want
  2. Save file as a VW file
  3. That then becomes the base file for the site
  4. Create my layers for masterplanning and start drawing
  5. It is important to remember that the coordinates must match the GPS or OS coordinates in the survey files for the northings and eastings or I cannot generate coordinates or align the drawing with third party data (such as google maps)

One of the great things about VW is to be able to rotate the view and work orthogonally, (so I am not having to twist my neck every time I look at the screen) and always be in a position to return it to normal with a simple click of a button - This is something that Autodesk does not have to the same extent.

 

When I am working in a 2D environment and the site layout does not require the use of full 3D modelled files, I just use a symbol on the drawing to represent the house - this works fine, but when trying to work with a referenced viewport. Ie. referencing multiple model files to create a full model for client presentation / planning etc. I am unable to snap to points in the referenced viewport when the viewport is rotated.

 

Please do not tell me that I am no longer able to work in a GPS coordinated environment.

 

This is just the problem in this specific instance, it is endemic in 2017.

 

 

Edited by Kevin C
Typo
  • Like 1

Share this post


Link to post
  • 0

When using georeferenced data I always use the "align with internal origin" option (the last one of the 4, not shown in your screen capture) and also set the georeferencing before importing the dwg file. This assuming that the coordinates have been set up properly in the dwg file. This ensures that all origins align with the internal origin of the document, which is for now the preferred way of working with georeferenced data.

 

With regard to your referenced viewport issue... in your original document I had the same problem. When I recreated the referenced viewport using your reference drawing then snapping worked on the referenced viewport. You may want to try to recreate the referenced viewport in VW2017.

Edited by Art V

Share this post


Link to post
  • 0
On 9/26/2016 at 10:08 AM, JJe said:

I have a referenced drawing (from an external source) and snapping to that geometry only works when the plan rotation is set to 0.00 degrees.

Anyone else have the same problem?

 

Finally, after fiddling with a non-snappable dlvp for a couple day I have determined that this is the issue I am experiencing. Have any of the service pack updates addressed this issue?

Share this post


Link to post

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
Answer this question...

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


 

7150 Riverwood Drive, Columbia, Maryland 21046, USA   |   Contact Us:   410-290-5114

 

© 2018 Vectorworks, Inc. All Rights Reserved. Vectorworks, Inc. is part of the Nemetschek Group.

×
×
  • Create New...