Open dadino opened 8 years ago
Absolutely something we have on the roadmap - it will be very useful! We already have issues for this in our core, but tracking it here is great as well. It's very unlikely to happen before this Christmas though, but definitely before next :-)
I guess if the code at the below address works it can be converted to Java (Android). https://github.com/mhergon/RealmGeoQueries/blob/master/GeoQueries.swift
This would actually be pretty cool, the evaluation of RealmResults in a circle, sorted by distance
any updates on this issue please? any ETA?
@sharathp there's an issue for geospatial indexing in the core, but I think the sync support is getting all the attention at the moment.
Anyone who have converted the link @efkan have linked? Or have any qeoquery extension to Realm?
I think I've only seen people use square cutoff instead of a radial cutoff, unfortunately.
I tried figuring out that swift code, but it seems to use some kind of NSPredicate that doesn't translate to Java.
There was also an open issue in iOS https://github.com/realm/realm-cocoa/issues/2569 and in core https://github.com/realm/realm-core/issues/1184
@Zhuinden this swift code can be converted into kotlin code
@marinovskiy but can the NSPredicate be converted to an equivalent Realm-Java query?
@Zhuinden Realm is fully compatible with Kotlin. And you can use kotlin code with java code in one project, so if you want you can just convert this swift code into kotlin code and add one kotlin file to project
@marinovskiy now that I read the code a bit more, yeah it creates a "GeoBox" to limit the objects into a box defined by lat/lon, and then iterates the result set manually and filters for circular radius.
https://github.com/mhergon/RealmGeoQueries/blob/master/GeoQueries.swift#L139-L144
That doesn't scale that well because you need an O(n) iteration to filter the elements, and every proxy has to be created and the whole dataset must be read to evaluate the results directly, but otherwise it's ok because it can work
Almost two years, any news on this?
+1
Guys please update on this, it is very important feature for mobile applications and will very helpful to reduce manual calculations.
+1
Consider using the Google Maps APIs and Fused Location Provider to work with geopoints and distance etc, at least while Realm catches up with this issue. They even have a Java client for consuming these APIs: https://github.com/googlemaps/google-maps-services-java/ Hope this helps somebody...
@lordplagus02 this is a good solution for applications which would work online. Offline applications would still have this problem.
+1
Hi, any news on this? This feature would be great for a year end gift! Thanks.
We need this too
We need this too, please :pray:
@bmunkholm 3 years later and nothing?
@filipef101 That's correct ;-) Time since a feature request was first made is not a big factor in prioritizing. While we would still love to make this, it's not currently highest on the priority list, unfortunately.
Okay, thanks for the reply :)
We have to did SQLite for tables which are needs to be sorted this way.
It loses a point when a db engine doesn't support geospatial queries.
Highly needed!!
Would love to see this happen for RealmSwift! it would simplify everything. Any update on the progress of this issue? IMO this should be high on the priority list of features realm is missing. Love <3
Looking at your welcome page, it's clear you see value in queries for maps, but there is some friction in this library when it comes to these things (#1765). Other libraries (eg. Parse, MongoDB) have the concept of points with coordinates, with operators that make these kind of queries pretty easy. I'm proposing a
RealmGeoPoint
, withlatitude
andlongitude
(maybealtitude
, I can't see a use for that), with a set of operators to apply on theRealmQuery
.Possible operators:
.inRange(String fieldName, LatLng origin, double range)
.inBounds(String fieldName, LatLngBounds bounds)
.orderByDistance(String fieldName, LatLng origin)
.closest(String fieldName, LatLng origin)
.farthest(String fieldName, LatLng origin)
I guess this could be even better if these comes from
core
, but (as we say here) it's not always Christmas.