Solar North defaulting to green axis for all geo locations


#1

I’m teaching Sketchup in the first semester of the Architecture programme at LTH, Lund university, Sweden. During my teaching I’ve encountered a couple of tools, features and techniques that might be improved, to have a more coherent logic in relation to the rest of the software. First one is Solar North:

  • Solar North should always default to green axis, not be a couple of degrees off. I see no logical explanation to this behaviour, either than someone sometime confusing solar north with magnetic north. Geographic north (grid north, gps north) is the same as solar north, right?

I teach geo-location and sun/shadows as a fundamental strength of Sketchup, and it kind of erodes the confidence in Sketchup for analyzing sun and shadows precisely.


#2

Verify in Ruby Console that the following is not 0.0:

Sketchup.active_model.shadow_info["NorthAngle"]

if it is, track down the template that was used to start the model. (Some templates may already be Geo-Located, or someone made the template from a model that was rotated to match some buildsite.)
ADD: In the Ruby Console this will list the template path (except in v2015 which is bugged and returns an empty string. It was fixed for v2016.)

Sketchup.template.inspect

So with this respect, since you are controlling the software environment for students, it is YOUR responsibility that any templates the students use, have the basic settings and styles that YOUR classes expect.

Now, that does not mean you might not have found a “filebug” where one of the standard templates has the north angle misset. (Such template bugs have happened in the past, and sometimes propagate by copying templates from older SketchUp version manually to newer.)

Seems like this might be a perfect excuse to teach about the ShadowInfo properties collection:
http://www.sketchup.com/intl/en/developer/docs/ourdoc/shadowinfo

Maybe someone, in the past, set the north angle off a bit to illustrate this to the students ?


#3

The Solar North issue is described in more detail in this thread: Solar North & Geolocation

We’re using strictly vanilla tools and templates (in our case, Architecture Millimeters), and the Solar North issue is persistant. It is off for most places on earth.

I teach general purpose techniques for using Sketchup in an architectural process, to students with wildly different computer skills. So I try to teach the logic of the software, and the strengths of it, rather than special puprose techniques. In Sketchup 2016 my single biggest lack-of-logic-complaint has been fixed: Inference with arrow keys now works with all of the tools. That is pure awesomeness! Teach the students arrow key inference for one tool, and they can apply it across the board. That is software logic that is empowering for a beginner.

Since I teach a new batch of beginners each year, the logic pitfalls becomes apparent with the effort it takes to teach the workarounds, and the number of questions and errors coming from the students. But in essence, this post is not to make my teaching more comfortable, but to request some features that could make Sketchup more coherent and user friendly, based om my experience in teaching.


#4

OK that explains the issues much better. (I bookmarked it.)

I also tested the template your using. It has the North Angle set to 0.0, before Geo-Location.

I suspect there is some difficulty between the Google Earth API and SketchUp’s API. There are known issues with the internal Shadow engine. (Shadows, Sunrise and Sunset are not correct for all elevations.)

What I understood in the past, was that the North Angle feature was used for orientating the model after it was placed into Google Earth.


#5

@abcdaniel, thank you for this link to the other thread by Mat. I missed it.
Often with this subject magnetic north is mentioned to somehow be (part of) the cause of any differens in default north (green axis) and solar north after geolocating the model. To me it seems that magnetic north has no part wathsoever. The magnetic north has no fixed position and ttravels “quite fast” over a period of time, making it necessary to correct (nautical) maps. Deviation data changes every year.
I’ll try to come up with some explanation but I do think that it is tied to Google Earth. No satisfying anwer for the time being, I know. This question was raised several times before with (FAIK/R) no answer.


#6

The Su program collects inputs from users and their model to make predications you are using but it can not be assumed they are 100% correct;
They accept a city input but cities can be many miles in extent so what is really used for that city location. Is it geographic center, population center or??
The USGS ( United States Geological Survey) controls that in their data base but what is used in Sweden I have no idea. However if one uses what is in the actual USGS data sheet you will see a different map location vs. the city input approach if Boulder is used
As you will know the staring point of any accurate estimate will be where the ascending node of the Earth’s equator crosses the plane of the ecliptic and the time. Then to make an accurate predication a time like Julian date is used with greater accuracy than what is input to SU.
I am not trying to fault SU it uses what it was designed for although it could still have some problem. Here is info I find useful maybe it helps you https://www.e-education.psu.edu/natureofgeoinfo/c2_p16.html#comment-6996