What is the recommended way of updating geolocation while preserving associated data?

I have the following structure:

I would like to update the location, while preserving the data

There is GeoFire.set(key, location) https://github.com/firebase/geofire-js#geofiresetkey-location

But when I call it the data would be lost.

I think I’ve found a workaround but it doesn’t seem very intuitive to me:

        firebaseRef.child('data').once('value', function(snap) {
          var data = snap.val();
          geofire.set(name, [lat, long]).then(function() {
           firebaseRef.child('data').set(data);
          }, function(error) {
            console.log('Error: ' + error);
          });
        });

1. Saving data locally
2. Updating geofire
3. Storing data back to Firebase

Seem like a lot of work. Is there a better way?

Video explanation: https://www.youtube.com/watch?v=i5u77q7l8dU

You data sets are updating niceely: https://publicdata-transit.firebaseio.com/sf-muni 😃

Thanks!

[jwngr]

Hey @stefek99 - The issue here is that GeoFire doesn’t support storing data inside of its index. Instead, you should store that information elsewhere, for multiple reasons. First, let me talk about what the solution here is. You should structure your data like this:

{
  geofire: {
    "-J9aZZl94Sx6h": { "g": <geohash>, "l": {} }
    "-Jhacf97x4S3h": { "g": <geohash>, "l": {} },
    ...
  },
  "locations": {
    "-J9aZZl94Sx6h": { <location-data> },
    "-Jhacf97x4S3h": { <location-data> }
  }
}

Note that the keys used for GeoFire are just the push IDs from the /locations/ node. This is important because when you receive a key from a key_entered or key_exited event, you can easily use it to look up the data by doing a rootRef.child("locations").child(key).once("value").

Now, what is the benefit of doing it this way? For one, this is the only way that really works with GeoFire. Doing what you are trying to do and hack your own solution into the GeoFire index itself is probably not going to work. You don’t have enough control over that.

Also, it’s important to realize that there is often a difference in security between your GeoFire index and your data. If you store them all together, you can’t separate their security rules. And since the GeoFire needs to be pretty open to work properly, that would mean your secure location data would also need to be open. Separating them allows you to give them separate security rules.

Finally, not including your data in the GeoFire index reduces the amount of data going across the wire. If you stored all that data in the index, every time a location moved would result in a lot of wasted bytes. If you do what I suggested, you would only load data that you actually need, when you need it.

You will notice our transit open data set is structured in exactly this way. The GeoFire index for it can be found here. If you look at that, you’ll see that the GeoFire keys (e.g. lametro:7869) are a combination of the transit provider and bus ID. This allows us to easily look up bus info by doing a ref.child(provider).child("vehicles").child(busId).once("value") call. This is exactly what we do in our SF MUNI demo code.

I’m going to close this issue but please feel free to respond if you still have questions.

[jwngr]

Yes, you should look them up individually by ID. This does require 100 calls, but since we use a websocket which has already established an HTTPS connection, it should be fast. It’s not like you are making 100 HTTPS requests which are all opening connections to our server.