Geolocation in Speckle stream

Hi everyone!

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:

  1. Location. There are two options:
    - EPSG code (preferred)
    - Latitude + Longitude (less precise)
  2. Offset from location (EPSG / Lat + Long). Offset in xyz + Rotation
  3. 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.

5 Likes

This is interesting!

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!

3 Likes

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).
basemap_demo_short_compressed

3 Likes

I can see a benefit in the coordsys being stored as a branch level rather than stream level.

Scenario:

  1. User 1 commits geometry to “Main” branch EPSG:27700 Cartesian coordinates (generic CAD in UK)
  2. 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)

5 Likes

Thank you all for the input!

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.

1 Like

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.

¯\(ツ)

1 Like

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.

2 Likes