Georeferencing poor match

Gaieus

Hi Jack (and welcome),

I wonder why you had to "add more imagery"? This is usually only available when you have already added some location to the model. If that location is very far, the add more imagery function will cause similar errors. It should usually be only used in a very close proximity of the original location (say a city block)

jack_sprat

I did indeed already have the model georeferenced before grabbing the terrain, but this would've been no more than 300m from the GE terrain location.

I guess that my process is actually:

Georeferenced and positioned an image of an OS map of the area (~ 400m x 450m)
Built a rough model of a bunch of Nissen huts and water towers, using the OS map.
Grabbed terrain from GE in SU, using 'Add more imagery...' tool.
Re-positioned OS map and model against the GE snapshot image.
Adjusted heights to match GE terrain.
Exported model to KMZ.
Imported KMZ into GE

So, maybe it is 'more imagery' because of the pre-existing OS map PNG.

Is the fact that I didn't grab the GE terrain first really likely to be the issue?

I just tried a test, using the procedure I originally posted - this results in ~2.5m offset, but good vertical referencing.

Interesting.

JS

Gaieus

Well, I have not made too much calculation how much is much so cannot tell if that 300 metres is much or not.

Just being interested: why do you need that map at all? I see that the GE imagery is not perfect there but IMO good enough to place those buildings more or less accurately.

jack_sprat

Gai,

FYI: Adding the terrain was kind of an afterthought, having built a model of a proposed house-build on a plot adjacent to the buildings you see in the screen-grabs in my OP. The OS map has the plot boundary on it (which obviously isn't part of GE imagery).

It seems that the order in which the various steps are undertaken is critical, i.e. you can't reliably add GE terrain to an already georeferenced model. I find this surprising, particularly when using 'Add more imagery...' tool zooms directly to the zeroed axes of the defined model.

I will re-build the model, with imported GE terrain as the base.

I wonder (but doubt) whether the fact that I'm running SU8 under Wine (1.3.36) on a Linux (openSUSE 12.1) machine has any bearing on the issue...

best - JS

Gaieus

Unfortunately I do not know if Linux adds anything to this (I am even surprised that it allows adding the location and opens the map as these parts are usually the most problematic).

There are some experienced Linux / SketchUp / GE users here so hopefully they can chime in on this part of it.

jack_sprat

FYI:
I followed installation as per: http://sites.google.com/site/sketchupsage/problems/linux;
I initially had issues with openSUSE12.1, but these were resolved with Wine1.3.35, as per http://bugs.winehq.org/show_bug.cgi?id=29404

(just noting these in case someone picks up this thread while searching for similar solution)

JS

Gaieus

Ah, that's Aerilius (one of those I thought of when mentioning Linux users above). I trust he knows what he is writing.

Aerilius

Hi,
I assume when you adjusted the models drawn on OpenStreetMap plan to the Google Maps satellite image, you moved the models (and did not unlock and move the terrain).

SketchUp does not save the vertical position of the model (elevation) but assumes the origin to be at terrain level. It often happens that additional imagery does not match vertically.

What happens if you create a new (not geo-referenced) model and add a terrain using "Add Location", then import your geo-referenced model file into this?

jack_sprat

Aerilius, hello

I'll take this opportunity to sing your praises for the excellent and helpful post describing how to get SU running on Linux (mentioned above) - thanks.

@unknownuser said:

I assume when you adjusted the models drawn on OpenStreetMap plan to the Google Maps satellite image, you moved the models (and did not unlock and move the terrain).

definitely - GE terrain remained locked throughout. (Also, 'OS' is Ordnance Survey, the UK govt. cartographers).

@unknownuser said:

What happens if you create a new (not geo-referenced) model and add a terrain using "Add Location", then import your geo-referenced model file into this?

that's what I suggested I would do next in my 3rd post... and now I've done it. It works a treat - AND, I didn't have to move any of the model, i.e. the imported model was correctly geo-referenced, all along.

So it seems that adding terrain from GE after creating and geo-referencing a model screws with the geo-referencing; even though the model location tag in the exported KML is the same as the manually specified geo-reference for the original model:


    <Placemark>
      <name>Model</name>
      <description></description>
      <Style id="default"/>
      <Model>
        <altitudeMode>relativeToGround</altitudeMode>
        <Location>
          <latitude>dd.dddddd</latitude>
          <longitude>-d.dddddd</longitude>
          <altitude>0</altitude>
        </Location>
        ......
    </Placemark>

Lesson learned!

thanks for your interest - JS

Aerilius

So the work-around works
Theoretically the "Add location" feature should work no matter if the model is already geo-referenced and no matter how it is geo-referenced.
SketchUp adds some special attributes when the terrain is imported with "Add location":
ModelTranslationX -18855495.7977869 ModelTranslationY -215494081.152937 ModelTranslationZ -4278.33784800286 ZValueCentered -4278.33784800286
I have no clue what that means, but it's certainly missing if you only have the normal coordinates. I'll test it out or report the problem to Google.