UTM coordinates lost during export

Hello

I have modelled an object in Sketchup in a point cloud. The client needs a .dwg drawing with the model at the right UTM coordinates. When I export the file, the coordinates are gone.
Can somebody help me please?

I don’t know if the SketchUp DWG exporter is sophisticated enough to honor UTMs. Also I’m wondering if the model has correct UTM to start with. Did you geo-locate it before importing the point cloud and had the point cloud appear in the correct position automatically? A sophisticated point cloud tool should IMO be able to geo-locate the model when placing a geo-located point cloud, but I’m not sure if any SketchUp point cloud extension does that.

It is usually not practicable to use real map coordinates when modelling in SketchUp (or 3D/BIM applications in general). I always create my models relative to a local origin, and if I need a DWG file that uses the “real” coordinates, I move my model or lines to the right place after exporting, in AutoCad.

SketchUp lacks a “survey point” feature (like in Revit or Archicad). I wonder if a Ruby guru could create a plugin, using perhaps a dynamic component as the locator.

The problem lies in precisely geo locating and reading geo location through the API. The functionality does exist in SketchUp, but it’s hard to reach due to lacking API coverage and documentation.

The only thing a DC could do is being a user interface, and that can be done better in other ways.

I posted some related requests in the API issue tracker earlier today: Geolocation · Issue #412 · SketchUp/api-issue-tracker · GitHub

The Point cloud extension is called “undet”. When importing the point cloud the utm coordinates are imported as well. To model on the right coordinates is almost impossible because the origin point in Sketchup is too far away. The Extension has the possibility to move it to the origin point in Sketchup, start and finish modelling and then move the point cloud and model back to the right coordinates.
But the export fails.

Talk to the undet guys - they are extremely helpful.

The type of geolocation that Google or OSM uses is useless for most applications where we need DWG exports using map coordinates. The exports would need to use the coordinates of the locally used map system, be it USM or other.

That is what I meant. The user inputs the “real world” xyz coordinates in custom fields in the DC. Then the exporter ought to add these to all the coordinates exported. This is how it works in Revit or Archicad. I don’t know if the DWG exporter is exposed to the Ruby API in this way.

SketchUp does support UTM with the following datums in the API it appears:

Adindan
Afgooye
Ain el Abd 1970
Anna 1 Astro 1965
Arc 1950
Arc 1960
Ascension Island 58
Astro B4 Sorol Atoll
Astro Beacon E
Astro DOS 71/4
Astronomic Stn 52
Australian Geod 66
Australian Geod 84
Bellevue (IGN)
Bermuda 1957
Bogota Observatory
Campo Inchauspe
Canton Astro 1966
Cape
Cape Canaveral
Carthage
CH-1903
Chatham 1971
Chua Astro
Corrego Alegre
Djakarta (Batavia)
DOS 1968
Easter Island 1967
European 1950
European 1979
Finland Hayford
Gandajika Base
Geodetic Datum 49
Guam 1963
GUX 1 Astro
Hjorsey 1955
Hong Kong 1963
Indian Bangladesh
Indian Thailand
Ireland 1965
ISTS 073 Astro 69
Johnston Island
Kandawala
Kerguelen Island
Kertau 1948
L.C. 5 Astro
Liberia 1964
Luzon Mindanao
Luzon Philippines
Mahe 1971
Marco Astro
Massawa
Merchich
Midway Astro 1961
Minna
NAD27 Alaska
NAD27 Bahamas
NAD27 Canada
NAD27 Canal Zone
NAD27 Caribbean
NAD27 Central
NAD27 CONUS
NAD27 Cuba
NAD27 Greenland
NAD27 Mexico
NAD27 San Salvador
NAD83
Nahrwn Masirah Ilnd
Nahrwn Saudi Arbia
Nahrwn United Arab
Naparima BWI
Observatorio 1966
Old Egyptian
Old Hawaiian
Oman
Ord Srvy Grt Britn
Pico De Las Nieves
Pitcairn Astro 1967
Prov So Amrican 56
Prov So Chilean 63
Puerto Rico
Qatar National
Qornoq
Reunion
Rome 1940
RT 90
Santo (DOS)
Sao Braz
Sapper Hill 1943
Schwarzeck
South American 69
South Asia
Southeast Base
Southwest Base
Timbalai 1948
Tokyo
Tristan Astro 1968
Viti Levu 1916
Wake-Eniwetok 60
WGS 72
WGS 84
Zanderij

I don’t have much experience with precise geo locationing, but it seams to me SketchUp has good support in the back end, just lacks support in importers, exporters and user interface.

As far as I have experienced neither the SketchUp DWG nor the DXF exporter honors geolocation. This is easy to verify with the DXF exporter as this is a pure text file.
A properly geolocated SketchUp model exported to DXF should contain the geolocation information in a GEODATA object in the OBJECTS section.
But no such object will be found there (as of the Sketchup 2019.2 version). So this is an issue with the exporters themselves.
(It is harder to look into the interior of the DWG file, as the DWG format is a proprietary binary format.)

It’s been a long time since I tried to work with precise geo-location in SketchUp but I remember it to be quite difficult. Ironically SketchUp appears to have a strong back end for this, but with lacking documentation and without harnessing this power for importers and exporters. Am I correct SketchUp would achieve a nect level of profesionality if it seamlessly supported geo-location throughout the workflow?

Perhaps it is time to call in the product managers and let them see this?

Some practical examples what could be added are:

  • UTM coordinates and LatLong auto text from model point in LayOut
  • UTM coordinates and LatLong inspection/test tool in SketchUp
  • Importing geo-located DWG to geo-located SketchUp model offers you to place it correctly (see placing geo-located modle from 3dwarehouse in geo-located model for UI)
  • Importing geo-located DWG (or SKetchUp model for that matter) to non-geo-located SketchUp model offers you to geo-locate the working model accordingly
  • Warn when mobing a geo-located object inside the model. Offer to update the model’s geo-location, and the position of other geo-located objects accordingly.

Most of this can be easily implemented as an extension with some API fixes and improved documentation. The exporters, importers and AutoText are the expectations.

There’s a Revit importer Beta for sketchup being tested out by some sketchup users. If adding a set of coordinates to the local origin is the Revit way,

then certainly now must be the time to get those coordinates stored to the .skp file, so that exports will put that model at the same place as from the imports, and updates to some imported Revit geometry comes in at the same place.

This logic, if used throughout all imports and exports, also for dwg and ifc, is certainly a distinctively more “PRO” workflow… as in these suggested dwg import settings:

It you dont want added geolocation, dont set it. It you need it, it should be stored to the file, so all importers and exporters use those same coordinates.

To comply to how others uses location data ( at least where I work), all that is needed is this distance from map origin to user origin. People use those data without thinking too much about what map system is being referred, UTM 32/33 in my case. If you add map specs that could be an alternative way to set location in order to get your shadows correct. (although shadows dont need that millimeter level of precision one wants in order to place the model correctly onto the map)

So consciously setting up your local origin as a distance from map origin could also give you the ability to refer real coordinates on your site plan in Layout.