Hello,
Is there any way to show on the map the current location of the user as a (for example) blue dot, so that the user knows how far he is from the markers?
I have not found anything on the forum so far.
Thanks a lot
1 Like
I don’t believe we have the blue dot like we did in Classic Apps although I wish we did.
The only way I could figure out how to do it:
- Add an extra row in your table and filter the screen so it’s attached to that row specifically.
- Then add a user specific column to hold the user’s current location.
- Fill that user specific columns using the location component. The location component seems to continuously update with the user’s current coordinates while it’s turned on.
- Then have an IF column that returns either that user specific location or the other locations based on which columns are filled or not.
- Change your map to use the IF column.
This will add the user’s current location as a pin. It’s hard to decipher which pin is which, but the one pin should continuously move with the user.
3 Likes
Thank you Jeff,
And do you know if you can somehow customize this pin then? Can you customize the pins at all somehow visually?
No, not at this time. Maybe with CSS if you have a Business or Enterprise plan, but not natively.
1 Like
I believe this is a must have feature for a map component.
Having to invent work arounds to get it forces me to use the Classic Apps instead.
1 Like
I’m quite sure there is a tutorial somewhere in this community that explains how to create colored pins on the map (if you have access to custom css in your plan)
I did this a while ago following those instructions
That thread was mine, but it was on Classic Apps.
I did exactly the method @Jeff_Hager outlined above and it works. My implementation requires the user to click the Location component to update the field in the User table. Is there a version of this that can eliminate that step? It seems like it should be possible, as the Distance column type can calculate the distance from the user’s current location live, without any user intervention.
Can you check if this is correct (and your app is continuously on the screen). If this is the case, you only need them to turn the switch on once.
1 Like
If you have 3 known locations, and you know the users distance from each location in real time (which you do), then you can use trilateration to determine the users current location. I’ve not tried it myself, but I’d expect you should be able to craft a JavaScript function to do this.
2 Likes
I’ve done it…it worked for the most part…but it was quite a complicated and ugly setup.
I’ve done it by starting with three points on earth (0,0), (0,1), and (1,0) or something to that effect…and effectively I had to run through the same cycle about 5 or 6 times to get an accurate location. Each cycle gave me a new set of coordinates which I used to create three new offset points, calculate distance to each one, and run the trilateration calc again. Six times. Six sets of identical columns. The first cycle gets you within a couple thousand miles or less of your exact location and each subsequent cycle gets you closer until it is right on somewhere between the 4th and 6th cycle. Could have been simplified if I was hyper focused on a small geographic area, but I wanted it to work globally.
Long story short, it worked pretty well, until something caused it to crash enough where the app still ran, but it would stop tracking location until I restarted the app. Guessing the javascript got bad data somewhere along the line, causing it to lock up. Due to the complexity, I never really pursued it further within glide.
Ultimately it just felt dumb because Glide already knows my exact location to calculate distance, but doesn’t make it available to us, so I had to reverse engineer it and use my location to calculate distance, to ultimately figure out…my location. It was a lot of overhead to get from a known point A back to point A in a roundabout way.
This was for a personal pet project that I ultimately migrated to code solution outside of Glide so I could have a lot more creative freedom.
Glide really needs to add the the current location dot back onto the map. I know for a fact that it’s a very trivial thing to add with only a few lines of code. I’d even suggest Leaflet as an open source alternative map, which is quite flexible to modify and lightweight in my opinion. Another option could be to provide a computed column that exposes the user’s current location, but I totally understand why they make it so difficult to do that. Exposing a user’s live geo location would make it way too easy for someone to whip up a malicious app to track someone without their full knowledge. I firmly believe they are trying to make it obvious to the user with the switch to grab a user’s current location only when the user chooses to do so. Also, a lot of people ask for Uber or Lyft type apps, but something like that would require a ridiculous amount of database I/O that would not be good for Glide or anyone else. I know some ways around it, but for the reasons above, it’s something I would not ever share. Plus, live tracting is not great in web based apps because all tracting stops when the app loses focus (not exactly what’s being asked for here, but just pointing it out).
All in all, I think the best and safest option within Glide would be for them to add the location dot back onto the map. I would not recommend any other solution that would involve storing a user’s live and dynamic location within the database for I/O and/or privacy reasons.
For anyone curious, this is a portion of my app (not Glide), where Leaflet allows you to add overlays of all sorts, such as a custom SVG location pointer that I’ve set up to rotate to match the device compass or heading direction depending on if I’m moving or not, SVG pins for POIs that can look however you want, custom buttons such as the one I added to turn on or off the feature to keep the map centered on my location as I’m moving, being able to draw my track on the map as I move, various custom informational overlays, and several options for map tiles or custom map tiles beyond street and satellite view. A small handful of these features would be amazing in Glide.
3 Likes
That’s a good point. I tried switching one of my 3 known locations to somewhere on the other side of the world (Seattle), and that broke it. Might be fixable - I asked ChatGPT to help with the JavaScript - I’ll see what it says 
1 Like
Yeah, I did all of that a few years ago prior to AI being a widely available (which would have been a lot more useful back then). I do wonder if spreading out the three points would help, but it really comes down to the fact that the earth is not a perfect sphere, whereas the haversine formula assumes a perfect sphere. So over greater distance, accuracy starts to suffer. That’s why I ended up doing the same thing 6 times. Each time the three points get closer to my actual location, which improved the accuracy.
Okay, so after a bit of back and forth with ChatGPT I got a version that works reasonably well. It accepts any number of points and uses the best 3.
This is what we wound up with:
const points = JSON.parse(p1);
return (trilaterate(points));
function trilaterate(points) {
const R = 6371000; // Earth radius in meters
// Convert lat/lon to Cartesian (ECEF)
function toCartesian(lat, lon) {
lat = lat * Math.PI / 180;
lon = lon * Math.PI / 180;
return [
R * Math.cos(lat) * Math.cos(lon),
R * Math.cos(lat) * Math.sin(lon),
R * Math.sin(lat)
];
}
// Convert arc distance to chord distance
function arcToChord(s) {
return 2 * R * Math.sin(s / (2 * R));
}
// Build anchor list
const anchors = points.map(p => ({
xyz: toCartesian(parseFloat(p.lat), parseFloat(p.lon)),
r: arcToChord(parseFloat(p.dist))
}));
if (anchors.length < 3) {
throw new Error("At least 3 reference points are required.");
}
// Initial guess: average of anchors
let x = 0, y = 0, z = 0;
anchors.forEach(a => { x += a.xyz[0]; y += a.xyz[1]; z += a.xyz[2]; });
x /= anchors.length; y /= anchors.length; z /= anchors.length;
// Iteratively refine using Gauss-Newton style updates
for (let iter = 0; iter < 20; iter++) {
let dx = 0, dy = 0, dz = 0;
anchors.forEach(a => {
const dist = Math.sqrt((x - a.xyz[0])**2 + (y - a.xyz[1])**2 + (z - a.xyz[2])**2);
const err = dist - a.r;
if (dist > 0) {
dx += err * (x - a.xyz[0]) / dist;
dy += err * (y - a.xyz[1]) / dist;
dz += err * (z - a.xyz[2]) / dist;
}
});
x -= dx / anchors.length;
y -= dy / anchors.length;
z -= dz / anchors.length;
}
// Project back to the Earth surface
const norm = Math.sqrt(x*x + y*y + z*z);
x = (x / norm) * R;
y = (y / norm) * R;
z = (z / norm) * R;
const lat = Math.asin(z / R) * 180 / Math.PI;
const lon = Math.atan2(y, x) * 180 / Math.PI;
return `${lat}, ${lon}`;
}
I pass a list of locations/distances to the function as a JSON string like so:
[
{
"lat": "47.6145202027",
"lon": "-122.3206316883",
"dist": 12980689.919369303
},
{
"lat": "-31.952087582622525",
"lon": "115.8638444665685",
"dist": 3910344.046993789
},
{
"lat": "59.93253188444967",
"lon": "30.366073129788116",
"dist": 8968163.640954673
},
{
"lat": "3.152073465167341",
"lon": "101.70557490017445",
"dist": 312222.71896776656
},
{
"lat": "3.8307772555426003",
"lon": "103.3476196863522",
"dist": 284803.878753309
}
]
In testing it I found that if I started with just 3 points that were in remote corners of the world the result wuld be quite inaccurate, but as soon as I gave it a single point in my own geographical region the the accuracy improved significantly.
4 Likes
Oh! That’s quite an interesting approach.
I once did this using a helper table and only with 2 points, to handle location errors against the given reference point and the radius boundary set for students. Then I used CSS to differentiate the marker of the current user. I haven’t had the chance to test whether it can update the location in real time as the user moves.
1 Like
I suspect it wouldn’t update if the user moves if you’re just using the Location component. My understanding of the way that works is it writes the location when the user toggles the switch on, and then that won’t change unless/until they toggle it off/on again.
1 Like
Wow, you guys got way ahead of me on this one! I’d thought of the JavaScript triangulation approach as well, but doesn’t it seem odd that we have to jump through such hoops when we’re using our current location in these complex calculations to derive… our current location? Feels like a valid feature request is lurking in here somewhere.
Anyway, my collab with ChatGPT did work, but as has been pointed out, it’s going to lose accuracy at extremes. I hadn’t gotten as far as supplying a list of locations and picking the best three — that’s very clever, as I need my solution to work globally.
If it’s helpful here’s my simple solution that takes three hard-coded locations.
// ----- INPUT -----
// p1, p2, p3 are distances (miles) from your unknown location to A, B, C.
// Fill in your known reference points (degrees):
const A = { lat: /* e.g. 37.8044 */, lon: /* e.g. -122.2712 */ };
const B = { lat: /* e.g. 37.7749 */, lon: /* e.g. -122.4194 */ };
const C = { lat: /* e.g. 37.8715 */, lon: /* e.g. -122.2730 */ };
// ----- VALIDATION -----
const dMiles = [p1, p2, p3].map(v => parseFloat(v));
if (dMiles.some(v => isNaN(v) || v < 0)) {
return "Invalid distances";
}
// ----- CONSTANTS -----
const R = 6371000; // Earth radius (meters)
const milesToMeters = 1609.344;
const r = dMiles.map(m => m * milesToMeters);
// ----- HELPERS -----
const toRad = d => d * Math.PI / 180;
// Reference latitude/longitude (use average to stabilize local projection)
const lat0 = toRad((A.lat + B.lat + C.lat) / 3);
const lon0 = toRad((A.lon + B.lon + C.lon) / 3);
// Convert WGS84 (approx) to local tangent plane (equirectangular)
function llToXY(latDeg, lonDeg) {
const lat = toRad(latDeg);
const lon = toRad(lonDeg);
const x = R * (lon - lon0) * Math.cos(lat0);
const y = R * (lat - lat0);
return { x, y };
}
const a = llToXY(A.lat, A.lon);
const b = llToXY(B.lat, B.lon);
const c = llToXY(C.lat, C.lon);
// ----- TRILATERATION (planar, least-squares with 2 equations) -----
// From (x - xi)^2 + (y - yi)^2 = ri^2, subtract eq.1 from eq.2 and eq.3
// 2(x2-x1) x + 2(y2-y1) y = r1^2 - r2^2 - x1^2 + x2^2 - y1^2 + y2^2
// 2(x3-x1) x + 2(y3-y1) y = r1^2 - r3^2 - x1^2 + x3^2 - y1^2 + y3^2
const A11 = 2 * (b.x - a.x);
const A12 = 2 * (b.y - a.y);
const A21 = 2 * (c.x - a.x);
const A22 = 2 * (c.y - a.y);
const b1 = (r[0]*r[0] - r[1]*r[1]) - (a.x*a.x - b.x*b.x) - (a.y*a.y - b.y*b.y);
const b2 = (r[0]*r[0] - r[2]*r[2]) - (a.x*a.x - c.x*c.x) - (a.y*a.y - c.y*c.y);
// Solve 2x2 linear system
const det = A11 * A22 - A12 * A21;
if (Math.abs(det) < 1e-9) {
return "No solution (points nearly colinear)";
}
const x = ( b1 * A22 - A12 * b2) / det;
const y = ( A11 * b2 - b1 * A21) / det;
// ----- BACK TO LAT/LON -----
const lat = (y / R + lat0) * 180 / Math.PI;
const lon = (x / (R * Math.cos(lat0)) + lon0) * 180 / Math.PI;
// Optional sanity check: residuals (how well distances fit)
function residual(px, py, cx, cy, rr) {
const d = Math.hypot(px - cx, py - cy);
return Math.abs(d - rr);
}
const resA = residual(x, y, a.x, a.y, r[0]);
const resB = residual(x, y, b.x, b.y, r[1]);
const resC = residual(x, y, c.x, c.y, r[2]);
const maxRes = Math.max(resA, resB, resC);
// If the fit is very poor, warn user (tune threshold as needed, e.g. 200 m)
if (maxRes > 2000) { // 2 km mismatch suggests bad inputs or far-from-planar region
// You can return a warning string instead if preferred.
// return "Inconsistent inputs (large residuals)";
}
// Format output
return lat.toFixed(6) + ", " + lon.toFixed(6);
1 Like
Has anyone actually taken these hacks for a walk or a drive to see if they update in real time? My tests would seem to indicate that they don’t.