Georeferencing (rotated earth) vs Rotated Model

[Christiaan]

Am I right in saying that the fundamental advantage of rotating one's building model to fit the orientation of the site and using Rotated Plan to work on it square to the screen, is that cartesian x/y coordinates can be set to match geographic Easting/Northing coordinates, whereas using Georeferencing Angle to True North to rotate the earth under the building model results in two coordinate systems that are not aligned (x/y cartesian coordinates in the OIP vs easting/northing geographic coordinates measure by the stake object).

So would it be fair to say that it's is a choice between which pain you prefer:

The Georeferencing Method: Perfect, frictionless 3D modeling and drafting, but you have to use the Stake Tool to read real-world coordinates.

The Physical Rotation Method: Perfect, frictionless coordinate reading in the OIP, but you have to fight the software on standard 3D views, hatch alignments, and a bunch of other stuff.

[Christiaan]

I'm ready to give Georefencing + Angle to True North a go. Relying on stake objects to measure coordinates doesn't seem so bad compared with all the niggles that come with working in a rotated view.

[Katarina Ollikainen]

@Christiaan, I would go with georeferencing every time. Yes, you have to use the stake tool to get the correct coordinates, but this is a small price compared to the advantages.

By doing this, you can export your model, placed in the correct place, both in Project North and in True North.

 

[HebHeb]

some additional thoughts to consider:

 

1. using just „world coordinates“ (given survey is already transformed or geolocated (i.e. in Germany, most common)
2. using „real“ GIS-Geolocating Feature with EPSG Codes

 

the seccond methos is of course the most professional and flexible,

but if done without the needed expertise, it is not easy to handle… I struggle extremely to teach this every team member in a needed depth…

 

when using in large projects, there is in fact a huge impact on performance when referencing across different files

when updating them, the „transforming geolocated objects…“ takes very long loading times (often not worth the hustle when survey is already set…)

 

when copying or transferring geometries in different systems, there are three methods (not always easy to choose which one to use… and most importantly, they give different results… so handle with care … )

 

Edited April 8 by HebHeb

[Jeff Prince]

Almost every architect I work with does their building in Cartesian coordinates, square to the screen.  Then they reference the building(s) into the site plan for orientation.  This works for projects of all sizes and scope.

 

The ones that geoposition their building model always do something wrong that gets fixed by civil or structural in my experience.  I get that small residential projects might get located off an architectural site plan, but I’ve never seen an architect produce survey grade data for staking out a site, hence the responsibility lies with Civil, and they largely do not touch VWX.

 

I guess architects are going to architect and make things more difficult than they need to be 😉

[Luka Stefanovic]

Hi @Christiaan

I would say that this is true in both cases:

9 hours ago, Christiaan said:

rotate the earth under the building model results in two coordinate systems

You have a dual coordinate system in each case - a project coordinate system and a cartesian one, depending on whether you're in true north or in project north view. I suppose the main difference is with Rotated Plan, it's a temporary one and with Georeferencing it's a permanent one. 

 

I get your point about not being able to read coordinates straight from the OIP but for me as an architect, I need to be in project north view much more often than I need to read coordinates so it's a no brainer 🙂  

[shorter]

I am not going to be drawn on this one...  I have had a nice week or two NOT engaging with social media or forum chat. 😉

[Christiaan]

4 hours ago, Jeff Prince said:

Almost every architect I work with does their building in Cartesian coordinates, square to the screen.  Then they reference the building(s) into the site plan for orientation.  This works for projects of all sizes and scope.

Good point. The third way. I've actually used this method multiple times in the past with good success. One disadvantage being that you have to manage multiple files, even with a single building. This introduces complexity, but also a vector for bugs.

Another disadvantage is that you can't copy paste in-place across the site model file and a building model file. Not the end of the world, but a niggle none the less. In fact, looking back, I see I have one project (which had two houses) where I still rotated the houses in their own files, so that when I referenced them into the site model they were already in the right location.

[Christiaan]

5 hours ago, Jeff Prince said:

I guess architects are going to architect and make things more difficult than they need to be 😉

If I had it my way I would always work in rotated view, but I would have all the problems fixed:
https://forum.vectorworks.net/index.php?/topic/129461-various-little-problems-when-working-in-rotated-topplan/

 

[Jeff Prince]

1 hour ago, Christiaan said:

Good point. The third way. I've actually used this method multiple times in the past with good success. One disadvantage being that you have to manage multiple files, even with a single building. This introduces complexity, but also a vector for bugs.

Another disadvantage is that you can't copy paste in-place across the site model file and a building model file. Not the end of the world, but a niggle none the less. In fact, looking back, I see I have one project (which had two houses) where I still rotated the houses in their own files, so that when I referenced them into the site model they were already in the right location.

That’s the key issue with these workflows, no matter how you do it, there will be compromises.

 

The example I shared seems to be the least error prone and most likely how architects and engineers are used to working and sharing information (for the most part).

 

 The big issue with geolocating your building is the chaos that can ensue when your building or the site moves.  It is not uncommon for geolocation to change due to survey refinement or jurisdictional requirements.

 

Also, it is fairly common for commercial projects to be developed as site agnostic prototypes, speculative to acquire property, or well in advance of a survey being commissioned.  And then there is the case of one building being repeated multiple times on a site….

[Christiaan]

10 hours ago, shorter said:

I am not going to be drawn on this one...  I have had a nice week or two NOT engaging with social media or forum chat. 😉

 

So I'm guessing you're still working in rotated view? Not tempted by the separate site model file and building model file method?
https://forum.vectorworks.net/index.php?/topic/129461-various-little-problems-when-working-in-rotated-topplan/#comment-557674

 

[line-weight]

On 4/8/2026 at 7:03 AM, Christiaan said:

Am I right in saying that the fundamental advantage of rotating one's building model to fit the orientation of the site and using Rotated Plan to work on it square to the screen, is that cartesian x/y coordinates can be set to match geographic Easting/Northing coordinates, whereas using Georeferencing Angle to True North to rotate the earth under the building model results in two coordinate systems that are not aligned (x/y cartesian coordinates in the OIP vs easting/northing geographic coordinates measure by the stake object).

So would it be fair to say that it's is a choice between which pain you prefer:

The Georeferencing Method: Perfect, frictionless 3D modeling and drafting, but you have to use the Stake Tool to read real-world coordinates.

The Physical Rotation Method: Perfect, frictionless coordinate reading in the OIP, but you have to fight the software on standard 3D views, hatch alignments, and a bunch of other stuff.

 

I've asked a similar question before. There doesn't seem to be an official answer on "best practice".

 

One thing that bothers me a bit about the georeferencing method is you can't reallly define the rotation precisely - it basically means you have to determine it manually by trial and error. Maybe this doesn't matter in practice.

 

And here's a very confusing discussion about rotation and georeferencing when it comes to exports.

 

Edited April 9 by line-weight

[Tom W.]

58 minutes ago, line-weight said:

One thing that bothers me a bit about the georeferencing method is you can't reallly define the rotation precisely - it basically means you have to determine it manually by trial and error.

 

This wasn't my experience. You just enter the angle + the globe rotates accordingly. That said I am happy leaving the globe as it is + using Rotate Plan, partly because a site often has a number of different orientations + this allows me to set up different views depending on the part of the model I'm working on.

[line-weight]

9 minutes ago, Tom W. said:

You just enter the angle + the globe rotates accordingly.

Yes, but how do you first determine the angle in order to enter it? Effectively you have to work it out manually.

 

Geometrically, it should be possible to give VW the real-world co-ordinates of two or more points on the model, and have it work out both the translation & rotation of the globe beneath.

[Tom W.]

4 minutes ago, line-weight said:

Yes, but how do you first determine the angle in order to enter it? Effectively you have to work it out manually.

 

Yes but working out the angle manually should be quite straightforward + precise + not involve any trial + error. I may be missing something because I only did it in a series of tests when I was playing with the Survey Point Tool but remember it all being fairly simple+ accurate.

[line-weight]

2 hours ago, Tom W. said:

 

Yes but working out the angle manually should be quite straightforward + precise + not involve any trial + error. I may be missing something because I only did it in a series of tests when I was playing with the Survey Point Tool but remember it all being fairly simple+ accurate.

 

The scenario I am talking about is as follows:

- I have a survey of the real world site, and this contains a set of points with georeferencing co-ordinates. These points correspond to, for example, building corners.

- I have a model in Vectorworks. That model contains a representation of the real world buldings.

- I want to tell VW, these building corners in the model correspond with these real-world co-ordinates, and I want VW to translate & rotate the globe so that it fits.

- Note that the real-world co-ordinates will never exactly match the model. I'm looking for a "best fit". It might be using 2 points or it might be using 5 or 10 or more.

 

As far as I know this is not possible. VW can not do this calculation for me - I have to manually move the "globe" around until I get a good fit. By definition this is a trial and error process. Move, see how many of the points are a reasonably good fit, move again to see if I can get something better, and so on.

 

In many cases, maybe this doesn't matter - what I can get by this process is "good enough". Really I'm just pointing out that it's a manual process and VW can't do the maths to find me the best fit in one go, which is something that other applications can do in similar contexts.

 

Part of the reason to point this out, is that I started out assuming this is what the tool could do - it took a while to realise that it doesn't. I think it's worth this being clear so that other users don't spend time searching for the method when it doesn't exist.

[Tom W.]

53 minutes ago, line-weight said:

 

The scenario I am talking about is as follows:

- I have a survey of the real world site, and this contains a set of points with georeferencing co-ordinates. These points correspond to, for example, building corners.

- I have a model in Vectorworks. That model contains a representation of the real world buldings.

- I want to tell VW, these building corners in the model correspond with these real-world co-ordinates, and I want VW to translate & rotate the globe so that it fits.

- Note that the real-world co-ordinates will never exactly match the model. I'm looking for a "best fit". It might be using 2 points or it might be using 5 or 10 or more.

 

As far as I know this is not possible. VW can not do this calculation for me - I have to manually move the "globe" around until I get a good fit. By definition this is a trial and error process. Move, see how many of the points are a reasonably good fit, move again to see if I can get something better, and so on.

 

In many cases, maybe this doesn't matter - what I can get by this process is "good enough". Really I'm just pointing out that it's a manual process and VW can't do the maths to find me the best fit in one go, which is something that other applications can do in similar contexts.

 

Part of the reason to point this out, is that I started out assuming this is what the tool could do - it took a while to realise that it doesn't. I think it's worth this being clear so that other users don't spend time searching for the method when it doesn't exist.

 

Ok I see. I guess in that scenario I would expect to have the survey first + have plotted my building footprint over the top of it before modelling it so that the matching-the-model-to-the-survey process would have happened at the outset + the angle to true north determined at that point. The scenario you describe sounds like you took your own site dims initially + modelled the building/s from them, then acquired a survey afterwards + needed to match them up...? Anyway, if this is something that other softwares can do then I suppose not unreasonable to expect VW to do it too.

[Katarina Ollikainen]

@line-weight, The exact scenario you're suggesting is not supported, but it's an interesting development. However, I've seen some truly horrifying results of 'best fitting' of projects, where the survey data has been taken as the truth, until actually arriving on site, and nothing created on the drawing board fits the land. I assume this is more useful for architecture if you're working with siloed geometry (where the exact position of objects is only relative within the building) and the silos then have to be placed 'somewhere' in the world.

That said, I do understand the benefit of this. I will do some research and see what would be necessary to allow adjusting the map. It's important to note - dirty map alignment doesn't change the underlying coordinates - it just manipulates the map image. You would not be able to use the map and extract coordinates from it. If there are systems that do both, please let me know, and I'll look into it.

 

[line-weight]

@Katarina Ollikainen To illustrate graphically - here I'm imagining the four red locii are where the survey says the four corners of a rectangular building are. The rectangle is the building as it exists in the model. The reason they don't match exactly might be a mixture of things, including survey accuracy, or the fact that the real building is not built exactly square.

 

The two blue loci are also points from the survey...lets say they are the gateposts at the entrance to the site.

 

As a user I just want to get things as close as possible - a best fit of the model rectangle with the four red points. This will involve a rotation of all six points. I want to get the position of those gateposts (relative to the building) as close as I can. Very small rotational movements of the red points relative to the building rectangle can of course cause somewhat larger movement of the blue points.

 

I can do it by eye... but it's reassuring to have it done mathematically, using a process that tries to even out the errors across those 4 points.

 

I've seen this kind of thing in panorama stitching software, and also in QGIS when you are georeferencing for example a historic map against modern survey data. In both those cases, it usually involves some kind of warping/stretching, and that's definitely not what we want in VW - but the part of the process that calculates the best fit for multiple points and then applies translation/rotation I imagine to be doing something very similar to what I'm describing.

 

I do understand your concern about potentially horrifying results where there are big errors and the user doesn't really understand what's happening. So it would still have to rely on the user being able to check manually that whatever the tool produces actually makes sense.

 

 

 

[shorter]

On 4/9/2026 at 5:21 AM, Christiaan said:

 

So I'm guessing you're still working in rotated view? Not tempted by the separate site model file and building model file method?
https://forum.vectorworks.net/index.php?/topic/129461-various-little-problems-when-working-in-rotated-topplan/#comment-557674

 

 

Yes, but in a heavily referenced system, using 'geo-referencing', with multiple buildings, it failed catastrophically.

Edited April 10 by shorter

[Katarina Ollikainen]

@shorter, It would be interesting to know where things failed catastrophically.

We're doing a lot of work on all things georeferencing right now, and I would appreciate exact scenarios where things failed.

I know we met last year and looked at the example you posted in the forum - three buildings, each with its own project coordinates and rotation - and that worked perfectly as soon as you georeferenced the files.

I'm sure you have more complex examples, and it would be good to ensure the changes we're making support them as well. So, please share - I do understand if you can't share the actual files, but let us know of the scenarios where things break apart.

 

[Christiaan]

1 hour ago, shorter said:

 

Yes, but in a heavily referenced system, using 'geo-referencing', with multiple buildings, it failed catastrophically.

What's the (theoretical) advantage of using georeferencing with separate referenced files? I think I already know the answer but maybe I haven't got the full picture.

[shorter]

19 hours ago, Katarina Ollikainen said:

@shorter, It would be interesting to know where things failed catastrophically.

We're doing a lot of work on all things georeferencing right now, and I would appreciate exact scenarios where things failed.

I know we met last year and looked at the example you posted in the forum - three buildings, each with its own project coordinates and rotation - and that worked perfectly as soon as you georeferenced the files.

I'm sure you have more complex examples, and it would be good to ensure the changes we're making support them as well. So, please share - I do understand if you can't share the actual files, but let us know of the scenarios where things break apart.

 

 

@Katarina Ollikainen It did not work perfectly in practice, as you know and as discussed with you and others at the time.

It's probably a good idea to remind ourselves why modelling orthogonal to the screen, or 'Screen-Aligned Modelled, or 'SAM' for short, is considered a good idea, and what the pros and cons are, and why many have historically worked this way in CAD and do so in BIM.  I am not advocating it's use, by the way; simply looking at why someone might choose this method.

SAM is how most prefer to work in Revit, although this is becoming less often as many discover 'scope boxes', which is similar, sort of, to rotating the view in Vectorworks.

When employing SAM the building is the focus.  The building does not move.  If the building moves on the site, it is the site that moves, not the building.  This means you have to constantly adjust the position of the site at early stages (and if using georeferencing and multiple buildings this can be fun... not!).  Also, Revit-users tend to not like moving their models, so this is another consideration, if you are working on BIM projects involving other players.

SAM ensures that any views taken from the model, and placed on sheets as viewports, do not move, since the buidling does not move.

In a SAM the building has a local origin, and therefore coordination of 2D detail with the model, in section and elevation, is 'easier' to manage.

SAM tends to work better when exchanging BCF with Revit-users, assuming all models are located to the same origin, height alignment and rotation.

 

The downside of SAM, is that it is not easy to issue setting out information from the SAM (although there are simple workarounds for this) and referencing the site and any other building to the SAM relies on georeferencing, or relocated viewports of the site and adjacent buildings.

Whereas...

Modelling true north, and with a geolocated origin, MANGO? 😉 , presents problems with all the above, except for issuing setting out information, as judicious use of the user origin satisfies most setting out scenarios.

MANGO is though, unerringly reliable.  There is far, far less to go wrong as long as you have set the user origin and any rotation angles correctly.  There are simply fewer variables, and less management involved.  Dare I say, it is more user friendly?  You just have to be aware of the downsides if you move a model.

I would be interested to understand what others think the percieved benefits are of using georeferencing when there are already methodologies within the software to satisfy most scenarios, except those perhaps involving the curvature of the each, which I have to say, have been fairly limited in my experience as an Architect.

We typically work on and are asked to assist on multiple building projects (MBP) and masterplans.  We typically have multiple models, with one building per file, and often segregate each building into multiple models, each referenced to each other, or not, depending on the needs of the project and the team. 

Typically it is rarely necessary to reference building A to building B, but it is always necessary to reference the site to both and both to the site.

The site is never embedded in the building model, except at very early stages where the site's development is aligned to developments in the massing and distribution of buildings on the site.  Once the location of buildings is fixed, the models are segregated and referencing employed in order to keep file sizes small and file organisation as consistent, logical, and navigable as possible; a hallmark of our 'system'.

In the MBP projects we have set up using geoferencing (and we have used georeferencing in 2D and 3D), each building was located as a SAM, with a local origin.  The SAM origin might be located on the grid intersection, or corner of the building, whereas the site origin is usually centred on the site boundary, or shared with one of the buildings; the latter is particularly beneficial in a single building SAM, when using viewports, as the viewport rotates around it's insertion point which is, of course, 0,0.

Each buidling would then have a corresponding coordinate for it's origin on the site, in a similar manner to how the project base point works in revit.

The aim on each project was to align each physical SAM with the rest of the (usually revit-based) design team and make coordination in local coordinates the primary objective, knowing that all had proven they were able to issue models in OS coordinates via the coordination test.  We can then carry out clash detection and reporting in either coordinate system, local or global.

Using georeferencing though, because each building had a different location on the site and a different orientation, and in order to locate the origin sensibly and give setting out information for each building in 'flat earth' coordinates (since this is generally how buildings are set-out), each had to have a different georeferencing system, i.e. the coordinates defined in the X, Y in the document georeference settings were related to each building, and were not the same as the site's coordinate. 

Therefore, an MBP requires multiple georeferencing systems (GRS) to co-exist.

And this would appear to be it's achilles heel.

If there is one GRS for the site, and if the buildings share the same system, it would appear to work as you expect, despite being possibly easier to manage using viewports.
 

However, as soon as there are multiple GRS in play, it gets horribly confused, and I cannot see how you cannot have multiple GRSs in play in such a scenario.  Perhaps you aren't meant to?

 

While we have been able to tame GRS in a 2D environment (although there was so much management of coordinates involved when building locations were not fixed georeferencing was abandoned just for this reason alone on one project), the issues became catastrophic in 3D, where models would not only reference in different locations as they had done in 2D when they should not have done (we figured this was down to GRS conflicts), but also rotate out of position, and almost always with some effect on the three dimensionality of the model, i.e. the model often collapsed.  It was hopelessly unreliable, so it was quickly abandoned and reverting to layer referencing and modelling true north, i.e. applying our standard approach, fixed the issue, as it so often does.

We have actually had better results using viewports and positioning models as viewports in the correct location for export (which works for DWG), or using the ifc export settings (which does not work for DWG), than using geo-referencing, and I would suggest that if someone wants to follow the SAM approach, they agree where the local origin is with their design team, build their models about that origin, orthogonally to the screen (despite very few buildings being absolutely orthogonal in plan so rotate view has to be used to some degree), and use a viewport of the site as a background orientated to suit, and have a system in place as we do to communicate plot and building setting out on the site to the internal and wider design team.  Georeferencing is technically not necessary, in my experience.

Other issues we have found with georeferencing include:

DWG linked into Revit when georeferencing is present.
Importing DWG with georeferencing present because users simply do not know whether to tick the georeferencing option or not.

Navisworks does not like georeferenced IFCs.  It also does not like the IFC export settings.

 

I know these may be issues in the recipient's choice of software but there is very little point not being able to issue reliable data to other design team members who might then rely on that data.

Of course, if you are not bothered about coordination with others and are only concerned about the production of your own deliverables, assisted by the model, aka Model-Assisted Delivery or MAD, then the above will have no relevance.

Having recently taken a vow of social media silence I now feel like the hermit in Monty Python's Life of Brian!  Someone has just stepped on my metaphorical toe!

I would love to send you the models where we had the most issues but as you correctly surmise, I am not at liberty to do so.  And unfortunately, I no longer have the funds available nor the time to build example models to demonstrate the issues to you.

[shorter]

20 hours ago, Christiaan said:

What's the (theoretical) advantage of using georeferencing with separate referenced files? I think I already know the answer but maybe I haven't got the full picture.

 

See above... 😉  I am not sure there is.

[shorter]

Just thinking about the other benefits of not being in rotated view...

As @Christiaan mentions, handling hatches becomes far easier, but so does the reliability of custom content such as 3D symbols and groups that have histrically not enjoyed being created in rotated view, or rather than caused issues on export because they were created in rotated view.

 

Of course, the latter is easily overcome.  The former not because there is no simple way to rotate the hatch defintion in the hatch creation dialog, other than 'in symbols' and 'in walls'.  It can only be rotated after placement using the attribute mapping tool.  Shame there is no 'in rotated view' option.

Edited April 11 by shorter