I am currently importing and geolocating terrain maps using Sketchup 2018 and the
Sketchup C-API SDK_Win_x64_18-0-18664.
I get this to work with some additional “tricks”, but I am really wondering whether there are bugs in the current C-API.
To geolocate I use this simple call:
su_res = SUModelSetGeoReference(model_, latitude, longitude, height, true, false);
if (su_res == SU_ERROR_NONE)
res = true;
Thereafter I check the result using this API call:
In both cases I get the result SU_ERROR_NONE. The latter call returns ok = true, which should imply that geolocation is set just fine.
However, the Sketchup Model Info / Geo-location dialog box says “This model is not geolocated”, which is kind of strange, because when you press the available “Set Manual Location…” button the very same information entered in SUModelSetGeoReference call is displayed.
So… the SUModelSetGeoReference call works - kind of - but Sketchup is still not satisfied.
Then, pressing the OK button in the “Set Manual Geo-location” should fix this, right?
No, not so, you actually have to change some information in this dialog box, before Sketchup will accept that the file is truly geo-located!
Anyone beside me who has observed this behaviour and found it strange? Or anyone who can tell me what I do wrong?
Anyone from Trimble here?
SketchUp also will create or change an AttributeDictionary attached to the model object named “GeoReference”.
We’ve discussed this before here, do a forum search.
Thanks for all the tips.
The datum for the file which Sketchup claims is still not geo-located is “WGS 84” (which is default) - checked through Ruby.
I will do some more investigations tomorrow (too late now).
To me it appears logical that if the call to
SUModelSetGeoReference(model_, latitude, longitude, height, true, false);
succeeds, then the file ought to be truly geo-located.
The set Manual Geo-location button will geo-locate it - if I make a small change, say adds a letter to the Location field (modifies “Somewhere” to “Somewherex”). I really have not added any geolocation information by this dialog (if so, why would not the dialog present such info?).
To me, this smells of a bug…
Anyway, I will revisit this item tomorrow.