#Geodist solr how to#

It’s far more useful to add a field alias, much like you would in SQL, which you can use to retrieve the value later. Again, you can use a helper: $query -> addField ( $helper -> geodist ( 'latlon', doubleval ( $latitude ), doubleval ( $longitude ) ) ) If you want to return the distance with the search results, you’ll need to add the geodist function to the list of fields, using the same values as the geofilt filter. If you prefer to work in miles, you simply need to multiply $distance by 1.609344: $query -> createFilterQuery ( 'distance' ) -> setQuery ( $helper -> geofilt ( 'latlon', doubleval ( $latitude ), doubleval ( $longitude ), doubleval ( $distance * 1.609344 ) ) ) )

#Geodist solr how to#

Here’s an example of how to add an additional filter to a search query, which – given a $latitude and a $longitude – limits the results to within $distance kilometres: $query -> createFilterQuery ( 'distance' ) -> setQuery ( $helper -> geofilt ( 'latlon', doubleval ( $latitude ), doubleval ( $longitude ), doubleval ( $distance ) ) ) Basically, these act as syntactic sugar, enabling you to create more complex queries without having to worry too much about the underlying SOLR query syntax. You might recall that in part three of the SOLR series, we looked at Solarium’s helpers. You’ll find an example schema.xml file in the sample application’s repository. Next, let’s look at how to populate that field. Your schema is now set up to support latitude / longitude pairs, and we’ve added a field called latlon. īoth the and declarations go in the section. _coordinate refers to the suffix we specified when we defined our location field type above. You’ll also need to set up a dynamic field for the components i.e. It’s important that multiValued is set to false – multiple lat/lon pairs aren’t supported. In the following example, I’m calling it latlon: Now that the types are set up, you can define a new field to hold the latitude and longitude. We need to ensure we have a suitable type for those: Īs you can see, it’s basically a field of type double (specifically tdouble, represented internally by the Java class solr.TrieDoubleField).īoth of these declarations need to be placed within the element of your schema.xml. Note that this field is made up of sub-fields i.e., a latitude and a longitude.

The first thing we need to do is to add the location field type to schema.xml: In order to get our SOLR core setup to support geographical locations, we need to perform some tweaks to the schema. Finally, just so we have all bases covered, and for the geo-geeks among us, we’ll include text fields in which users can manually enter their latitude and longitude. For convenience and simplicity we’ll include an arbitrary list of some major cities, which when clicked will populate the latitude and longitude from some hard-coded values. We’ll use the HTML5 geolocation functionality to allow the user’s browser to locate them. In our example application we’ll hedge our bets and take three approaches. So, the first challenge when you’re doing any sort of geo-related work is to work out how to determine the start point – i.e., where to search from. (If you want to take the latter approach, I’ve written about it before.) Geolocation comes in handy here, because it can be used to determine the latitude and longitude of “where you are”, without the ambiguities of place names. One of the challenges when you’re developing anything involving geographic points is that you need some way of making sense of them for people who don’t think in latitude and longitude – which I’m pretty sure is most of us. A latitude and longitude defines a point on the globe, potentially to within a few metres. Specifically, we’re really talking about a latitude and longitude pair. In geospatial applications we often talk about “points” i.e., a specific geographical location.