We have been thinking about geolocation and want to do some development work for it in April. Please let me know what you think and if we’ve missed something.
[EDIT] Unfortunately we have to put our planned dev work for geolocation on the back burner due to higher priority development work that is directly required for our engineering projects
[/EDIT]
Geolocation in streams improves interoperability because it would enable correct geographic placement of models among different software packages. Next to interoperability, geolocation could support several other use cases, to name a few: portfolio overview of multiple models on a map, carbon calculations (distance to production and site), and structural calculations (load zones).
Initial workflows to focus on
Revit → QGIS
Civil3D → QGIS
Bentley → QGIS
Required information
We believe the basic information required to capture the geolocation is:
Location. There are two options:
- EPSG code (preferred)
- Latitude + Longitude (less precise)
Offset from location (EPSG / Lat + Long). Offset in xyz + Rotation
Scale (units)
We are thinking to put the required information in a Speckle geolocation object that is added to the Speckle commit object. (any thoughts on this?)
Clients - sending
We want to start by capturing the geolocation with the senders. Add a checkbox in the stream settings windows to send the geolocation. (should it be turned on / of by default?)
Ideally, we want to let the user define the location within the application itself. Then the connector can retrieve the info and add it to the stream.
If the location is undefined, show a popup with a brief description how to add the geolocation in that specific application.
Clients - receiving
Initially focus on getting the data correctly located in QGIS.
My first thought is, what if geolocation information was stored at the stream level rather than at the commit level?
We could quite easily keep geolocation info in the Globals branch if we’re happy assuming that it will apply to all branches/commits. This could also simplify things a lot when visualizing multiple branches/commits at the same time.
Another remark is around units, currently they are actually stored at an object level - not sure how it affects things.
PS @Kateryna recently hacked something really cool in the viewer where models could be loaded on a map for geolocation purposes. Maybe she has a gif to share!
Hi @JdB !
This is actually a valid point. So far, I’ve been thinking more on dragging the geo-referenced data to zero-coordinates when working in CAD or viewer, rather than actually attaching a location data that would make the object appear at different pivot points in CAD or GIS. Both could work! As Matteo mentioned, the stream-wide location can be a relatively easy option, I am also curious to see your thoughts. Then, I guess, we would need some adjustments in the connectors that would reposition the received model depending on the software (CAD/GIS). For now, there is some hacky way to do it by creating a separate pivot point geometry.
So far we implemented (haven’t released yet) a location reference in the web viewer to pull Mapbox basemap and 3d buildings from OSM. Lat/lon and angle to true North are stored in Globals and are valid for the entire stream. This works pretty well with one building, but will have to test with larger areas created in CAD (how precisely CAD-drawing will be converted into coordinate reference system).
I can see a benefit in the coordsys being stored as a branch level rather than stream level.
Scenario:
User 1 commits geometry to “Main” branch EPSG:27700 Cartesian coordinates (generic CAD in UK)
User 2 receives geometry and aggregates with mapping data and commits to “reprojected” branch as EPSG:3035 (used for GPS in Europe)
Both are correct but the second will have been projected. These are less about translating with a line from one point to another, but simultaneously correct but incompatible branches.
If it is global at a stream level, the shared context is more tenuous.
If it is set (and reset) per commit, that is conceptually burdonsome on the viewer (human or machine)
We would prefer to store the geolocation on the commit because then you always know the data is based on the correct geolocation at that time. The geolocation could change during the design of a project (e.g.: initial location is pointed out on a map and later on updated with actual surveyed data OR initially choosing a lat / long and later on an EPSG code). So that’s why we think it would be preferred to keep the geolocation and data close to each other.
What if the geolocation would be stored on the globals branch and updated during the project, wouldn’t the data in previous commits becomes unreliable because they are based on a different geolocation?
And what if people send data from different software packages to different branches? They could have different geolocations?
Interesting to see the web viewer with Mapbox and OSM integration!
Good point about units, something to explore a bit further.
That was my thinking about branch level as once the data is pushed in the commit all objects are then queryable in the context of the branch (by traversal) but the commit they were part of is unavailable.
Unfortunately we have to put our planned dev work for geolocation on the back burner due to higher priority development work that is directly required for our engineering projects. But it’s good to already have this topic with input from multiple people so we, or anyone else, can continue with it at a later stage.
When we have priority to pick this up again I’ll report back here.
Hello, this looks absolutely amazing.
I’m trying to do it, but I don’t have the button that was clicked to display the map box content.
How is it done? I am in the middle of a project and this is exactly what we need
Hi @jan-casas ! Unfortunately I don’t think this feature is on the roadmap as far as I know
But it reminded me of this discussion, and I wanted to share with @JdB that some sort of geolocation object is being attached now in QGIS and ArcGIS connectors, as a “crs” property of Vector or Raster Layers. It contains WKT (full string interpretable into CRS object by any GIS software), units, and name. Also likely, the central meridian and latitude of origin (long term for “coordinate center”) will be specified separately (but they can already be found in WKT string).
The location is attached to the layer rather than commit/branch/stream, to preserve GIS way of handling the data, when each layer can technically have different coordinate reference system.
Old commit but the structure of the geolocation property didn’t change much:
We are testing geolocation in a project in a different way: with a Rhino to Revit workflow. The team did setup a model in Rhino and wants to receive it correctly rotated in Revit. But when receiving in Revit on the project base point, the rotation to true north isn’t applied. The geometry is moved to the location of the project base point, but not rotated (see screenshots).
I used 2.13. I double checked and now also used the XYZ server, the result is the same: no rotation to True North when receiving on the project base point.
Test stream can be found here (line object from Rhino): Speckle
Thanks for testing @JdB - Your previous post is also helpful. The base case is that it should handle data coming from the software without understanding the real location and, consequently, no rotations embedded in commits.
If I understand it, your suggestion is that where Revit PBP has a rotation to True North, this base case should assume source data is True North based and apply rotation on Receive. Is that right?
