I know that the default North location is aligned with the green axis. (I’m using the Solar North plugin to see this.)
But when you geo-locate and import Google Earth terrain, the North direction changes depending upon where you’ve geolocated the model on earth. In this example, I chose Boston, MA and you can see the North direction has been adjusted. Also, notice how the imported image is rotated slightly to match the new North orientation, but the group it is contained in is aligned to the model axes.
I have a couple of questions about this:
What does the angle between the green axis and the new North orientation represent? I have a suspicion that the default North along the green axis is relative to a specific Boulder, CO location. Whenever you geo-locate, you are seeing the difference between solar north angle at Boulder, CO, and solar north at your new location. I could be wrong though. (But, if you consider the fact that you can use the shadow tool without specifying a location, then there HAS to be a default location that each Sketchup file is set to in order to position the sun. If you go to Model Info > Geo-locate > Set Manual Location, you’ll see it has Boulder, CO set as default. Hmm.)
Since the imported terrain is cropped parallel to its relative North direction, wouldn’t it make more sense to retain the north direction already set in the model, and have the terrain and image import parallel to north? What’s the benefit of having it imported slightly rotated and changing the north direction? I feel like this is especially important when a user has changed the north direction using the Solar North plugin. If you geolocate, it throws out any changes you’ve made to North.
I just don’t understand why North should ever change automatically without direct user input. If the difference in angle we are seeing is relative to the Boulder, CO location, why do we need to see that? It’s more valuable to have North remain constant, to either the default green axis alignment, or to whatever the user set north to using the Solar North tool. It shouldn’t change just because we imported Google Earth data. Google Earth should be rotated to MATCH our defined north in the model. Am I right?
There’s probably a logical reason for this behavior, I just need to be enlightened.
I ran the question around the office and have a couple of possibilities. I’ve seen this and never had a solid answer (though I probably could have looked harder) so I’ve only used my best guess. That guess is that there is a “Magnetic North” vs “True North” thing going on here, though I don’t know the declination difference between the two. This could be off base though, because my ask just now also revealed an outstanding bug we’re investigating about this difference. I don’t have much more information about this bug so … that might not be as helpful as you’d like.
I put the question before the whole of SketchUp engineering so maybe someone will have an answer and post it here. There is also a chance that nobody has a good answer, so there may be no good response beyond this one.
This is probably a great place to talk about workarounds if they exist for the time being, but also we might dig into this and find a proper cause that will solve the bug for future resolution. Do you notice if it’s more severe at different locations (I imagine you probably model mostly in your region, so others who are bothered by this issue might chime in from where they are modeling.)
Great question Matt, hopefully we can figure something out.
Edit: Just to clarify, the Add Location tool is using Google Earth’s version of North, we’re calculating Solar North for shadows which is likely not “True North” as they use.
Yes, it is definitely a different angle at different locations. Sometimes it’s a positive angle, sometimes it’s negative. I’m sure it has something to do with the magnetic vs true north thing, but I’m no expert.
I really have a feeling that the default “north along green axis” is the “solar” north for a hidden default location. Since SketchUp uses the sun for shadows, then it would be required for it to have some sort of default location on earth plugged in for it to position the sun. I’ve tried to test this theory by geolocating to Boulder, CO and the new north is very close to the green axis.
Another thing I just realized, which makes a ton of sense, the north location gets saved in scenes that have shadow properties saved. So even though north gets adjusted when geolocating, it will be lost if the user has a scene saved with the default north-along-green-axis.
You can look up the magnetic declination (angle between magnetic and true or “solar” north) for any location using this site:
I suppose by testing at a bunch of locations one could check the theory that this is what’s going on. I notice that for Boulder CO it is about 8.5 degrees east.
So I just compared boulder 8.58°E and Boston 14°46’W, so I guess my theory is wrong. When I plug Boston into SketchUp, north is only ~1.4° off of the green axis. So that doesn’t seem to match up.
Just as a mater of observation. If you plug into SU Boulder, Colorado for geo-location it returns and displays a location that is not correct per the NGS North American Datum 83 ie NAD 83 .Its correct position is 400055.41 N and 1051646.56W per NGS data sheet. If you in put that data the SU location shows on the correct street which is 1778 Broadway Street.
When you set the geo-location that becomes the origin ref for the xy location reported in SU. However, those are taken from some of type projection and I have yet to find what SU uses. It probably is UTM or SPO. Sine the distortion of the projection is worse for UTM, my guess is SU uses state plane for CONUS , UTM would be required else where. To get solar north one has to use some type of sideral info which means the earth crossing the plane of ecliptic ( First Point of Aries) and the Julian date. What is used in the plugin I have not found yet. However , NOAA has a on line free calculator to obtain that info and they use the correct (almost) Boulder Location vs the NGS which should => small error.
NOAA solar cal. link NOAA Solar Position Calculator
I input the local time for this date for solar noon which is plotted as yellow. As would be expected this time of year that occurs at 180 deg az CW from north with elevation about 26 degs. The green is for sun rise, red sun set both of which include atmospheric diffraction affects. Yellow is solar noon for Boulder , large pin for that location…
I have not understood what the solar north is used for. I guess it is shadow studies??
Since I was a boy scout, I thought a compass showed magnetic north, while a map showed north as defined by the spherical surface of the Earth. The angle in Ottawa, Ontario Canada was about 17 degrees. That’s the difference you’d see when you put a compass with rotating dial on a flat map, oriented by sighting. (The stars, the East West arc of the sun) The magnetic pole is that far away from the North Pole. The 17 degree angle changes as you change latitudes, obviously.
Regardless, as a passive house designer, my concern with the software is gaining the proper orientation to the sun. For me, it’s only about that. I’m building an 8" CMU (no mortar joints, oak wood regulator strips horizontally, and filled with concrete) wall in my kitchen, up to counter height. Being in the desert, the wall adds thermal mass (NREL’s BeOpt software is yet to be conquered) to the hottest room in the house, so the mass is in shadow, the sun shouldn’t touch it. The sun comes through windows and a patio door on the opposite wall(s). I can use the counter top (concrete too) as an extended roof overhang to shade the blocks underneath, but as designed that won’t be necessary, according to Sketchup. As a carpenter/builder, note that in a northern climate (like Quebec) the mass would be capturing as much sunlight as possible. The opposite. No one in Palm Springs seems to get that.
The deviation of SketchUp’s North directions comes down to different precise definitions of “North” being used in different contexts.
It appears that Google imagery comes as aligned to Grid North of the UTM grid, while SketchUp’s green axis is probably and sensibly expected to be along True (geodetic) North. The deviation between the two is called meridian convergence. It varies by geographic latitude and the difference in longitude from the central meridian of the applicable UTM zone.
I confirmed this by using a coordinate conversion tool . For my residence I got 0.7°, and for the cited example (Boston), I the convergence is –1.4°. The magnitudes agree with the SketchUp examples we see, and the direction (+/–) should be easy to work out.
After a bit more digging I figured that the SketchUp North conventions, as of 2016, evidently are as follows:
Google Maps are aligned with True North, which, given the necessary worldwide coverage, seamless and at all map scales, use a variant of the original Mercator projection that is oriented along the Earth’s polar axis.
SketchUp’s solid green axis in a model is an immutable “world” axis and will be interpreted as UTM Grid North when geolocating the model. The camera Standard Views (Top, Bottom, etc.) are always with respect to these original world axes. Neither using the Axes tool nor geolocating a SketchUp model affects the original drawing axes or alters their interpretation. Upon geolocating, a North Angle is added which points towards True North.
Imported Google Maps imagery will be aligned with True North. Location and Terrain image groups will be aligned along the original drawing axes, i.e., UTM Grid North.
SketchUp solar shadows are calculated and shown correctly with respect to True North. Further, the shadow model evidently and correctly takes into account the equation of time, i.e., the difference between true local solar noon and mean local solar noon which varies through the course of a year by up to about 20 min. This is done at appropriate but not astronomical accuracy. There is no accounting for the added day of a leap year and no input for a year as such. Both aspects give rise to periodic and secular deviations of the local solar azimuth and altitude for a given time of day and day of year.
Going back to the mapping aspects: The deviation of True North from UTM Grid North is the meridian convergence (γ), which is location-dependent. The convergence increases with increasing longitude away from the zone central meridian (Δλ), and with increasing geographic latitude (φ). In a first approximation, not taking into account flattening of the earth, the convergence can be calculated from:
tan γ = tan Δλ × sin φ
Importantly, the meridian convergence jumps sign when the reference location changes from one UTM zone to another. It occurred to me that this is testable as follows: I modeled a roughly 1500 ft. tall solar gnomon and geo-located it at two different locations on the Alaskan coast, chosen for high latitude and thus expected big effect. The locations are a mere 1500 ft. (500 m) apart at roughly the same latitude, but are chosen to lie on different sides of a UTM zone boundary, i.e., in different UTM zones. As expected, after geolocating the resulting imagery is angled towards the right in one model and towards the left in the other. The resulting North angles (as inspected in the Solar North SketchUp extension) are about 2.7° away from 0°, and at different sign, as expected. Both angles agree with the sperical approximation of the meridian convergence (above formula) to within 2×10-4 degrees.
The attached screenshots illustrate the findings. Note how the True North directions (orange) and the solar shadows match up between the two locations, despite the imagery being projected into two differing UTM grid orientations.
It certainly helps explaining the little dfference between green and ‘Add Locaition given north’.
7 (isometric) can be any of the four possible combinations (like SE isometric) depending on the camera’s location and target prior to selecting this view.
We have been using this imagery for building models and they have been coming back rendered at the “solar north” angle rather than the “google maps/earth” angle. This makes it difficult to align them to the ground plans that we are making maps with.
It’s really messing with our renders and the maps we’re making. All of the renders we send out come back at different angles and most don’t align to the google maps/earth imagery we base them on.
I have always assumed “Green North” Was true north and could never figure out why terrain used another north. I even assumed Model#latlong_to_point and Model#point_to_lat_long was bugged and used the wrong sign for the “solar north angle”.
I am having an issue when importing models into Google Earth (GE). I have been using the Solar North plug-in for all my models after geolocating to get accurate shadows. However, for the first time that I just tried importing the model into GE, the alignment is off. I did a couple of test files and have weird results that leave me not knowing how to do this accurately.
When I geolocate a model and leave north as it is set with no adjustment, and place geometry over homes and roads, and import that into GE, it nearly aligns and the angle of the modeled geometry is very close. To test things I placed additional geometry in the model and aligned it to north in SketchUp [SU), but when imported into GE that geometry is not actually aligned with north in GE, it is off by a few degrees.
So, to adjust for this I used the Solar North plugin and reset the axis and re-imported it into GE. Now, the north from the model aligns with North in GE, but all the other geometry that I created on the house and roads is now off by that degree difference.
I don’t see how to be able to work in SU with geolocated models if the intent is to be able to bring into GE and accurately align. Either Solar North must remain unadjusted for in SU and north in SU doesn’t match north in GE, or everything is off when brought into GE.
I am sure there is more to these tools and geolocation than I know and understand, so am I missing something. Has anyone else geolocated a model, aligned to solar north, and exported to GE and everything align?
A smaller issue is that I am working with models that have specific GPS points for boundaries and the alignment of the imagery brought in from Digital Globe into SU doesn’t fully align with GE. I can move a whole model and terrain in SketchUp to align to visually align with the imagery in GE (even though I would love not to because I can’t import more terrain without readjusting back). I want to build an accurate model in SU on geolocated terrain, export that model to send to others so they can import it into GU, and have it be as accurate as possible. Digital Globe is free, maybe the paid imagery option has better alignment?
’
