User Origin Marker

[shorter]

We respectfully request that the ubiquitous user origin is made visible in the same way the internal origin is made visible via Display Preferences, perhaps in red, as opposed to blue if for no other reason than to make users aware that they have a user origin.

 

The current yellow indicator where the rulers meet is useful but does not show you where the new coordinate 0,0 is as a consequence of a user origin shift, either deliberate or otherwise.

 

It might make users more aware of the impact of using 'centre on import' when importing DWGs where Vectorworks moves the user origin to a completely arbitrary location.

 

Thank you.

[_James]

Anything to make the User Origin/Internal Origin system less confusing!

 

I understand the concept (I think) but others in the office cannot get their heads around it at all. It leads to so many problems.

[shorter]

User Origins are quite simple when you don't use them, or when you do, you have a strategy for why a file has one or does not.

 

You must always be in control of where it is, or more specifically and more importantly where your user origin is in relation to the site.

 

The biggest issue is that 90% of issues with user origins is because one was created without knowing why or how it got there.

Edited July 7, 2023 by shorter

[Tom W.]

The User Origin is represented by the red/green (+ blue) axes. So as long as 'Show 3D axes' (+ 'Show 3D Z axis') is enabled you can see where the User Origin is.

 

e.g.

 

Or you want something in addition to this?

[shorter]

The internal origin is blue and has a definitive icon.  The user origin should be likewise but red, IMHO.

 

 

I suppose it's more about consistency which even Revit has been able to do in this respect.

 

When you are in a 2D view it needs to be a lot clearer since this is where you set the user origin.

[Tom W.]

6 hours ago, shorter said:

User Origins are quite simple when you don't use them, or when you do, you have a strategy for why a file has one or does not.

 

You must always be in control of where it is, or more specifically and more importantly where your user origin is in relation to the site.

 

The biggest issue is that 90% of issues with user origins is because one was created without knowing why or how it got there.

 

My User Origin is always in the same place: the 0,0 point for the British National Grid. I never need to move it anywhere else.

[shorter]

On 7/7/2023 at 5:33 PM, Tom W. said:

 

My User Origin is always in the same place: the 0,0 point for the British National Grid. I never need to move it anywhere else.

 

You mean you work in true OS coordinates all the time, up to 970km away from the internal origin!?

[Tom W.]

Just now, shorter said:

 

You mean you work in true OS coordinates all the time, up to 970km away from the internal origin!?

 

No. My geometry is centred on the Internal Origin.

[shorter]

And your user origin is somewhere remote to the bottom left hand corner of the site, and somewhere sensible to the nearest 10m?

 

We still get user of another software get their Eastings and Northings the wrong way around, which is quite disturbing when it's the surveyor...

 

 

[Tom W.]

My User Origin is aligned with the OSGB36 datum i.e. located south west of the Scilly Isles. My Internal Origin is in Norfolk...

[shorter]

Cmd 9...

 

What does it say?

[Tom W.]

[shorter]

I am guessing, and it is a wild guess ;-), that you used the recommend 'centred on import' setting when importing the original DWG?

[Tom W.]

What original DWG? This is a georeferenced template file. But if I import a georeferenced DWG into it the import settings automatically default to the 'Align with Internal Origin' option + the imported geometry will be correctly located relative to the User Origin. Which is precisely what I want. Then once I've designed the building I can give the surveyor the coordinates for the foundations + he can mark them out on site. Because we're all working to the same coordinate system.

 

[shorter]

Georeferenced using Latitude and Longitude?

[Tom W.]

Using the 'Document Georeferencing' settings which are set to OSGB 1936 / British National Grid by default in UK licensed files. It's something I set up once in 2020 + haven't gone back to since...

[Christiaan]

That's how we're doing it too

[zoomer]

AFAIK, by default now all VW templates are geolocated.

(At least for the german localized VW version)

Maybe driven automatically by computer language settings ....

 

In Switzerland it is centered to the city of Bern.

In Germany it is at Brandenburger Tor in Berlin.

 

 

I am totally unsure about which geolocation system is suitable.

When I have a building site location, I try some of these systems

in geolocation manager until I find my site by the help of the areal view.

Then I geolocate a fix point (potential building grid start axis crossing),

try to find the definition of north offset angle definition for input.

 

But I do Never adapt my User Origin to geolocation !

User Origin down left is for landscape architects and such.

I am not interested in real world coordinates at all - I want my

bottom left building corner (Axes) to be 0.000/0.000.

So that I can directly see when my Column center is not a n-times 7,20 m

but 14,3999999978 m or so ...

[shorter]

It is interesting that the thing that is singularly missing in current documentation is how we actually coordinate our models in the first place!

 

For example... where is 'origin' or 'coordinate system' in this lot?

 

https://www.thenbs.com/periodic-table-of-bim

 

Have we lost sight of one of the basic principles of coordination and think coordination will happen without trying as long as one names one's files correctly?

 

The origin is the most critical point in a model. Fullstop!

 

Where it is in relation to the world is important but it is secondary to where it needs to be if you are to share models effectively.

 

And to share models effectively you all have to establish the same coordinate at the same point in the model.

 

And that coordinate needs to be written down and recorded in the BEP.

 

It is far easier to tell someone using revit or vectorworks to set their internal origin to 531240m , 185720m, than 531238.34567284923625131526374...e08m, etc.

 

And conversely establishing the coordinate system in Vectorworks is easier if you set the User Origin, either via the User Origin command or now via Geo-referencing, and let the longitude and latitude follow, not the other way round which will invariably end up with user origins accurate to a million decimal places and which no-one can write down precisely because software has a tendency to round things.

 

Our User Origin is very different to yours.

 

 

The coordinate varies project to project since we set this to the coordinate that is defined in the BEP and this of course varies per project.

 

This ensures that the internal origin in VW matches the IO in RVT, etc.

 

That way we are always working within sniffing distance of the site, and we can work in local or global coordinates.

[Tom W.]

But isn't it useful to be able to take coordinates from your models? Like when setting-out on site?

 

The only reason I have e08m numbers for my Internal Origin offsets is because I didn't centre my geometry on the Internal Origin particularly carefully as I didn't need to as I'm not coordinating with anyone else using the IO. I could have easily ensured it had nice round numbers if I'd wanted but I didn't need to: all I was concerned about was ensuring that my geometry was within the 5k safe working zone or whatever it's called. You don't need to move the User Origin in order to have nice round numbers for the IO offsets. You can put the IO wherever you want it (or rather move the geometry wherever you want it relative to the IO). Surely the easiest + simplest thing is for everyone to set their User Origin to the British National Grid rather than moving it around from project to project...? Then agree a common IO location for each project? 

[shorter]

Ps

 

apologies, i clearly digress from the subject of my own thread!

[Jeff Prince]

On 7/7/2023 at 2:46 AM, shorter said:

We respectfully request that the ubiquitous user origin is made visible in the same way the internal origin is made visible

 

I do not agree here.  Tom illustrated how the user origin is already visible.  What is great about that method is they are graphically unique.  It become very easy visually identify and discuss the differences because of this.  Make them differentiated by color only is just asking for trouble IMHO.  Since the existing method is further enhanced by depicting the 3 primary axis, what's to fix?

 

 

On 7/7/2023 at 3:11 AM, _James said:

Anything to make the User Origin/Internal Origin system less confusing!

 

This is definitely needed.  Best handled with better documentation and real world examples IMHO.

 

Teaching new users how to navigate these systems shouldn't feel more complicated than actually drawing our projects 🙂

The hours wasted on explaining how Vectorworks georeferences and fixing people's mistakes might be the most costly problem in the program.

That and fixing & shrinking PDF issues.

[shorter]

@Tom W. of course and we do hence the presence of a user origin but we turn it on and off. It is only on when exporting or for setting out otherwise we have found certain objects do not like being in OS coordinates and rotated view at the same time.  Models are more reliable when linked via the internal origin too.

 

I think since there does not appear to be any clear guidance on this I will offer the following, as far as they relate to architecture:

 

1 all models in all softwares should be set out about a common internal origin located to the bottom left hand corner of the site or in the middle of the site boundary on a larger project

 

2 the internal origin should be ‘geo-located’ ideally using eastings and Northings ie Cartesian coordinates according to the local site Coordinate system eg U.K. OS coordinates.

 

3 The coordinate defined at the internal origin should accurate to the nearest site unit and not rounded ie the nearest metre but ideally to the nearest 10m. eg

 

531240m

185720m

 

4 longitude and latitude should be set to the Cartesian coordinate above using a suitable conversion tool if not in-built into the software like vectorworks 2023 😉 

5 longitude and latitude accurate to 8 decimal places are sufficient to establish 1mm accuracy on the ground which is generally sufficient  given the distance if the sun to the surface of the earth… 😉

 

6 models should be set out true north

 

7 rotation angles used to define rotated views to work orthogonally to the screen (aka ‘project north’) should be accurate to max. 4 decimal places and not rounded. (This does require a leap of faith as many treat their surveys as being minutely accurate whereas they are probably +_ 50mm tops)

 

8 Common levels should be established across all models.  A decision should be made as early as possible whether models will be built in true height AOD or relative to a datum such that ground floor FFL = 0m, which in turn relates to 100m AOD.

 

9 Carry out proof of concept test and view results in a non-proprietary viewer such as Solibri.

 

Discuss.

[shorter]

2 minutes ago, jeff prince said:

Since the existing method is further enhanced by depicting the 3 primary axis, what's to fix?

Because it only works in 3D?

[shorter]

2 minutes ago, jeff prince said:

shrinking PDF issues.

Don’t use printer page sizes if you want to fix that. Set up true full bleed page sizes in the printer setup

[shorter]

38 minutes ago, Tom W. said:

Surely the easiest + simplest thing is for everyone to set their User Origin to the British National Grid rather than moving it around from project to project...? Then agree a common IO location for each project? 

Unfortunately not as you stray outside that 5k limit on every project if you only ever set one user origin, don’t you?