Feature request: Optional custom data

My current project is based on Polymer/Firebase/Maps API. I have to display to the user the number of records within the area he is viewing, using clustering technique. All is fine with GeoFire and thousand of records (require some tweaks with the Polymer data binding system).

The user can filter records by type using the on/off switch buttons:

If GeoFire lets me add custom data, then I can achieve this in a simple way without server side code.

For my use case, and for performance reasons, the added data must be relatively tiny. For exemple:

"2016-001": {
  "g" : "u07t4v857n",
  "l" : [ 47.31595982215497, 5.042859856945543 ],
  "t" : "a"
}

“t” stands for “type”.

I understand that adding custom data has an impact on performances. It might be up to the user of GeoFire to decide the best compromise, depending on the context, between adding data and performance.

I’ll link a PR to this issue.

[mikepugh]

@sonaye that is right - GeoFire is not downloading all of that data when I execute a query. I don’t have precise perf figures for you but basically GeoFire makes a couple of calls out to Firebase and streams the results to my app over the websocket connection. For a sample search near my location, Firebase sent me ~10 frames and each frame was between 1 KB and 6 KB. Each frame contained multiple search results - I think I had about 30 results displayed to the user, but GeoFire provided ~60 results.

The way GeoFire works is it takes your search lat/long coordinates and a search radius, and it calculates GeoHash values for the bounding box of that circle. Since GeoFire requires a Firebase index on the geohash value for all keys stored on the geo node, it is then able to very quickly query those indexes and stream the results to you. It does stream more results than what is strictly within your search radius since it’s working off a bounding box. GeoFire then locally trims out results which aren’t within your search radius.

So it does get a bit more than absolutely necessary but it’s still very fast and reasonably lightweight.

Some of the data I store on my geo node include:

• Display Name
• Phone #
• E-mail
• Company Name
• Certifications
• Id

The extra data isn’t huge, so I haven’t had any performance issues with it.

The recommended approach where-by I store that data on some other node in Firebase and query it directly by id was much slower. But my data set is fairly static - I’m tracking local companies so their locations don’t move around and at most my app is going to display ~75 results to the end user. So your mileage will vary with my solution.

[mikepugh]

@sonaye - I have a modified GeoFire-JS fork that can store data on the GeoFire index. I just updated it a few minutes ago to bring it in line with GeoFire v4.1.2

Try it out and let me know if it works for you.

https://github.com/mikepugh/geofire-js