Georeferenceing in SketchUp

[matthiasbasler]

Hi Google/Trimble team,

I am aware that I scratched this topic already at another place in another context, but since I just experienced a minor once hiccup again I thought it a good time to repeat my request:

Please establish a more robust way of georeferencing in SketchUp for geomodelling for Google Earth.

The current approach, which is storing the real-world coordinates of the terrain's center point the is clearly a workaround that is "just working", and yes, in 90% of all cases it is not a problem. However even I (as an experienced modeller) waste my time working around the glitches involved:

- Components must have their origin onto the terrain, otherwise they appear sunken/floating when uploaded to the 3DWH. (I guess every newbie trying this out stumbles at least once). If I have a large model containing several components I can be certain I forgot to re-set the axes somewhere after minor last-minute corrections. Plus, there's no way in SU of previewing the location of just one component in GE !
- If the model contains an old terrain and the user just imports a fresh, changed terrain patch without clearing the georeferencing beforehand, the new terrain patch will not be georeferenced correctly (the old georeferencing info is not overwritten?), resulting in wrong previews, which in turn result in models being sunken/floating although the look well in SketchUp.
- Imported terrain patches in mountaineous terrain (especially mountain tops) show significant rounding errors which can lead to differences of 0.5m vertically between what you see in SketchUp and what you later get in Google Earth.
- Wrong previews if the terrain layer is manipulated for whatever reason. (Better keep it locked!)
- Inability to import georeferenced (spatial) data delivered by surveying offices etc. without having to visually align it with the GE snapshot or writing own plugins that are aware of the Georeferencing metadata in the model attributes.

(Speaking of the last point: Ideally the Ruby API should provide methods to convert real-world coordinates to the local coordinate system for georeferenced models. This would make writing georeferencing-aware plugins so much easier.)

Please Trimble and Google programmers: Find a solution which is reliable in all cases, thus saving both modellers and reviewers a lot of time.
Thanks.

Matthias Basler

[Google Guide Alex]

Thanks for the thorough feedback, Matthias! I'll make sure to get your thoughts to the Trimble folks. 

[Ron Hall]

Would also like to have an option similar to the old "Get Current View" (SketchUp 7). This would allow for the use of GIS data in Google Earth that could then be imported into SketchUp for use in modeling (or additional graphic info). Since part of Trimble's mission is data collection, this would allow for the leverage of GIS data into the 3D world of SketchUp.

[Randy]

Hi,

 

I don't know if there is a language barrier at work, but I'd like to comment on your concerns. We sometimes need to step back and think about the specific task at hand, the proper tool to use for the task, the limitations of the tool, and most importantly if the chosen tool was  designed for the task. I commend the guides because I'm sure at some point they want to reach out and smack us across the face and say "Of course it 'doesn't work that way. It was never meant to."

 

But, to each of your concerns, here is my commentary on them:

1. "Please establish a more robust way of georeferencing in ...etc..." 

   We mark an area on a map, we click a button and wait. We receive a representation of the terrain and its coordinates. It works perfectly. What more do we need?

1. "Components must have their origin onto the terrain, otherwise they appear sunken/floating when uploaded to the 3DWH. (I guess every newbie trying this out stumbles at least once). If I have a large model containing several components I can be certain I forgot to re-set the axes somewhere after minor last-minute corrections. Plus, there's no way in SU of previewing the location of just one component in GE "

1. Not exactly true. At least, that's not the way it works.  

   When you start a new model using the Google Earth Template, the axis/origin is already established and is visible in the viewer. Have you ever wondered why it's there if you haven't drawn anything yet? The default axis (red/blue/green lines) position marks the "Spacial Center" of your model. Everything you add will be relative to that point in space. You can move the axis anywhere you'd like but it will not change the location of that spacial center. If you do move the axis, when you import the terrain, it will still align itself to the spacial center and not to where you moved the axis. Anything else you insert or draw will be also be aligned relative to that position. If you insert or make a component, all objects within that component will be aligned relative to the component's axis (child-parent) and the component will be aligned relative to the spacial center. You can completely delete the terrain and it won't affect anything. The terrain is only there to serve as a visual marker so that you can reposition the drawing axis and not lose your spacial center.

    

   You have to think "Object Oriented." Every object you draw is oriented to the axis of its container, not the the axis of the terrain. The exception being the outer/upper most object (the Model itself). The contents of a component (child objects) are oriented to the axis of the component (parent). If you move an object that contains child objects, the children AND their axis will move with them. Your sketchup model is the parent of everything contained within it and IT is aligned relative to the spacial center This is true with all aspects of Object Oriented Programming and not unique to Sketchup.

1. "If the model contains an old terrain and the user just imports a fresh, changed terrain patch without clearing the georeferencing beforehand, the new terrain patch will not be georeferenced correctly (the old georeferencing info is not overwritten?), resulting in wrong previews, which in turn result in models being sunken/floating although the look well in SketchUp."
   
   

1. Again, not exactly true. The easy straightforward answer is...User Error. The more difficult answer is the explanation of what they did wrong. Any additional terrain the user imports will always be correctly georeferenced. The issue is NOT with incorrect geo-referencing. The issue is that the user can't find the spacial Center of the model for whatever reason. Notice that I didn't say the user missplaced the center (because it cannot be moved), I said the user can't find it (because they moved the markers). When the user adds fresh terrain, they don't need to clear the geo-referencing. In fact, that is probably one of the things NOT to do. At least not for a few years. (Long and Lats shift aprox 1 degree/year). Google will eventually need to find a way to lock models to a position on the ground and not to a position on a moving grid that is draped over the ground. A lesson can be learned from aviation maps. Actually, the solution lies within Sketchup itself. Each component does not have its own coordinates. They each share the same origin. Why not apply that approach to the models on the 3D layer? It shouldn't be too difficult to pinpoint the center of the earth. Afterall, it can only be in one spot which in relation to us, it doesn't move. But I digress.
   
   Anyway, the only thing that needs to be done is to swap out the terrain photo with the new one by using "File > Add More imagry". Then see what changes (if any) needs to be made to the position of the model I've made a short demo here (0:44).

1. "Wrong previews if the terrain layer is manipulated for whatever reason. (Better keep it locked!)"
   
   

1. Again, not exactly true. You can delete the terrain entirely, and it will not affect the position of the model on Google Earth.

[SnowTiger]

I cannot comment on the accuracy or inaccuracy of anyone's statements or SU facts.
But I will offer what I think is a helpful solution.

Every single time I create a new SU Geo-Referenced Model, I create the exact same Scenes, resulting in a system that has worked for me under all circumstances (whether I import new/updated terrain at a later date or not).

The thing I do after Importing the GE Satellite Imagery and Terrain Data is create the following 4 Scenes (minimum).

Default Axis
Model Axis
Terrain ON
Terrain & Shadows ON

If the model is going to require more than 1 Axis (due to angled walls), I will create additional Model Axis Scenes ie. Model Axis 2, MA 3 etc.
The bottom line is that I ALWAYS retain/maintain the Original GE Axis with all my models.

When I have finally completed my models, I make a Copy that I can upload, leaving the Original Imagery, Terrain and Default Axis in the main model which I can return to for updates later if need be.

That Copy which I intend to upload (without the GE Terrain of course), had everything collapsed to Layer 0 and all Scenes are Deleted "unless" I want to leave a couple for viewers to use in Tour.
But there is Always an "Upload Scene" which is positioned whichever way I want but it is actually the Default Axis which has been renamed only. The Default Axis is the only axis that is actually uploaded.

So again, while I don't know anything about that which Matthias and Randy appear to debate here, I do know that this method I use "seems" to have negated any issues mentioned here as I have never had to do anything to correct elevations until and unless the GE Satellite Imagery and/or Terrain is updated. And even then it is simple and quick to do.
I should mention however, that my very first model did have Rotational Issues after being uploaded, but that turned out to be a GE issue and not my model. Of course it took my first model for Google to learn about and fix this issue. It was a rough start that ended well for me and everyone.

[SnowTiger]

I guess I should also point out that I continue to use SU 7 Pro ... I have not yet used or tried v8. So maybe the issues discussed are specifically related to it ?!! Although, I was under the impression (for some unknown reason) that Matthias also uses v7. Sorry if I'm wrong about that.

[matthiasbasler]

Hi Randy,

I have read your lengthy comments with interest, and yet I will not
agree with you on several points. My findings are based on several
years of experience and experiments done myself. Of course I can be
wrong anyway... but read below..

>>    1. "*Please establish a more robust way of georeferencing in ...etc..." *

>
>    We mark an area on a map, we click a button and wait. We receive a
>    representation of the terrain and its coordinates. It works perfectly. What
>    more do we need?

As I said myself it *usually* works fine for a new model, but ...
Have you often grabbed a terrain on, lets say, the peak of a steep
mountain to model a moutain lodge/cabin? One forum user did and
recieved noticable offsets. I repeated the test myself and confirmed
the issue. I have a guess why it happens in this case but don't want
to give a lengthy explanation here. Its only a guess, after all.

>>    2. "Components must have their origin onto the terrain, otherwise they

>>   appear sunken/floating when uploaded to the 3DWH.
>

>    Not exactly true. At least, that's not the way it works. [...]

Um, are you sure you have ever uploaded a single component using the
"Share component" action instead of uploading the whole model? Because
those that have know what I was talking about. Just try it yourself:
1. Create a new model
2. Import terrain
3. Create a building
4. Make the building a component
5. Position the component's (!) axes on the building's roof a few
meters above the terrain. (... insted of what would be correct, onto
the terrain.)
6. From outside the componet right-click on the component and choose
"Share component"
7. Wait until KMZ has been generated in 3DWH and download that KMZ
into GE.
What do you see? Your model should be severely sunken, I predict.

And I am pretty sure this is how it is supposed to be done, event the
Google Guides have recommended f.e. splitting a model of a whole
quarter into separate building components and uploading them
separately in order to follow the "one structure per model" rule.

>    3. "If the model contains an old terrain and the user just imports a
>    fresh, changed terrain patch *without clearing the georeferencing*beforehand, the new terrain patch will not be georeferenced correctly (the

>    old georeferencing info is not overwritten?), resulting in wrong previews, which in turn result in models being sunken/floating although the look well
>    in SketchUp."
>
>    Again, not exactly true. The easy straightforward answer is...User
>    Error. The more difficult answer is the explanation of what they did wrong.

>    Any additional terrain the user imports *will always be correctly
>    georeferenced*. The issue is NOT with incorrect geo-referencing. The

>    issue is that the user can't find the spacial Center of the model for
>    whatever reason.

Not sure I understand that. It is imho not the user's task to find
that spacial center, not even to know that it exists. ;-)

> When the user adds fresh terrain, they don't need to
>    clear the geo-referencing. In fact, that is probably one of the things NOT
>    to do.

Think what you want, but my experience after re-positioning dozens of
models after an imagery change last year speak a clear language:
Whenever I loaded the old model (with old SU7 grayscale terrain), just
removed the terrain and imagery (after unlocking) and imported new
imagery right away, the new terrain would be located quite differently
(on a hilltop this was extremely different, on a flat plane it was
barely noticable). Placing the building onto that new terrain so it
looked right in SU made it be wrongly positioned in GE.

Whenever I explicitely removed the georeferenceing everything was
fine.

In case you still don't belive me: Do you want an old model of mine
(with outdated terrain and imagery) to try it out yourself and draw
your own conclusions?


> I've made a short demo here <http://youtu.be/SPL7CVqbuG8> (0:44).
Nice you did that. Unfortunately I cannot check that video during the
next days. Hope I can have a look at it later.

>    4. "Wrong previews if the terrain layer is manipulated for whatever

>    reason. (Better keep it locked!)"
>
>    Again, not exactly true. You can delete the terrain entirely, and it
>    will not affect the position of the model on Google Earth.

You are correct about the delete aspect, but...
...you can *modify* it and if you modify the center region it *will*
affect the position of the model. Just do the "preview in Google
Earth" to check. I cannot go into details here, but again, I and
others have explicitely tested and proven this.

P.S. @Snowtiger: I use SU8 for around a year now and don't have any
particular version 8 specific problems with it.

Matthias Basler

[SnowTiger]

@Matthias >>> Cool      that's good to know because I hope to upgrade to v8 Pro within a week (payday).
I figure any issues that v8 might have or has had, have already been sufficiently dealt with. That's why I'm always late upgrading software. Now if only I could say the same thing for games !

Matthias >   I know you have used SU for a long time (several versions) and have no doubt you know what you are speaking of. I know this ... you know a heck of allot more about anything to do with SketchUp than I do.

[Randy]

Um, are you sure you have ever uploaded a single component using the "Share component" action instead of uploading the whole model? Because those that have know what I was talking about. Just try it yourself:

I just tried what you explained, step by step, and I do see what you describe, but (and there is always a but) I looked into it deeper and discovered that there is a consideration of which you may not be aware. When you move the component's axis before you share it, it also moves the components "Insert Point" to the axis' origin. After you move the axis to roof, you have to reset the insert point before you share it. If you don't, when you download the component, it will come in with the roof locked onto the terrain. But, even so, there is nothing preventing you from raising it so that it's not sunken. It's not glued to the ground, it just comes in that way. But with anything you import, After you import it, you have to place it correctly before you preview it.