If you take a look at mobile apps listing houses for sale, there are many that allow you to search within a map by drawing a shape around the area you are interested in. While such a feature allows users to customise their searches quickly and simply, there are a lot of technical issues that need to be solved in order to implement a reliable and effective search.
This article looks at idealista, the leading online real estate classifieds platform in Southern Europe, and their implementation of a so-called ‘draw a search’ feature within their mobile and web apps.
An overview of how the team implemented this particular feature, and the kind of technical constraints the development team had to deal with follows.
idealista’s web and mobile apps
idealista is one of the leading companies in the provision of online services to both sellers and buyers interested in real estate properties. Their primary service provides users with the opportunity to look for properties available for sale or to rent by means of a web portal that is accessible as both a mobile and a desktop (via their website) application.
Search features need to function in many ways in this particular context. For instance, users may want to look for properties within an area around a specific point in a map. In this case, the input required for the search might be an address.
This approach is simple and quite effective, but is limited by the constraint of the circular shape of the search area, where the specified address is the center, and the remainder is defined by a (potentially customisable) radius.
An alternative option is to search within specific areas, which might be an entire city, a region, a province or specific neighbourhoods. Of course, the bigger the area, the higher the number of results, which in turn might make the search less useful from a searcher’s perspective.
The specific-area approach solves the limitation related to the shape of the search area, since each sub-area has its own geometry. However, having to constrain the search to a specific district or districts might be annoying for a user who wants to look for specific sub-areas, perhaps within a district or across two or more regions.
To address these limitations, idealista opted for the ‘draw a search’ feature, which allows the user to draw a custom outline on a map, specifying the area of interest. This means there are no constraints on the region shape, or on the size of such an area.
Moreover, the ability to draw on a map results in a better user experience and a more natural interaction, which also increases the usability of both the mobile app and the web application.
Technologies
In terms of technologies, the implementation of the ‘draw a search’ feature has taken different approaches, depending on the platform.
Web app
Starting with the web app, idealista relied on the Google Maps integration provided by the Google API. However, this approach revealed some practical issues that needed to be solved:
Each property on sale can be displayed with a graphical pin, as is usually the case within Google Maps when highlighting search results. If the number of pins is limited, rendering them on top of the map is not an issue for modern browsers.
However, based on the size of the area selected by the user, the number of pins might be very high. If that happens to be the case (and it often is), a different solution is required to overcome the limitations imposed by browser capabilities, as well as the computational resources available in current devices.
Consequently, the team decided to optimize the pins visualization by implementing a sort of hierarchical visualization based on a custom tile server.
Based on Node.js and CartoCSS, this solution consisted of a set of pre-rendered images (generated on the backend), that are shown on the map at a density based on the level of magnification. Instead of rendering each pin every time, a single image is generated and sent to the browser, which can simply show the image without high computational requirements.
When the user decides to explore an area with a different level of magnification, another image is rendered and provided to the browser, to adjust the window contents accordingly.
Mobile
In the mobile app development process, the team opted for native API for both the iOS and Android apps, including those required for rendering maps. Instead of relying on cross-platform development frameworks, such as Flutter or Xamarin, the team opted for a native approach in order to improve results in terms of performance.
The introduction of the ‘draw a search’ feature occurred when the apps were already in use; consequently, it was not a situation where the entire app had to – or could – be redesigned and reimplemented just to introduce this feature.
Draw a search: polygon management
It is interesting to understand in more detail how the drawn area is actually used to perform the search. The first problem here is quite simply how to represent such an area.
The first distinction that we need to make here is how this area can be drawn through the idealista apps. Considering the web app (which can be accessed at this link), the process of drawing consists of specifying, one after the other, a set of points that are joined to form a polygon.
Such a polygon can be sent to a web server, which will then use it to perform a search.
When selecting this set of points in the web app, it is likely that the user will not input a huge number of points, but will instead limit the search within an area that defined by less than ten points – at least in most situations. However, this scenario changes in the mobile app.
As often happens, interaction with mobile devices is quite different from what happens on a desktop computer. In this case, the ‘draw a search’ feature does not require the mobile app user to select every vertex of the polygon, but instead allows the user to draw a freehand custom shape such as the heart shape shown in the previous image.
While this approach is both useful and engaging for the user, it creates several issues from a developer’s point of view. Firstly, any custom shape needs to be converted into a polygon, in order to be usable for a search. A very complex shape is made up of a very high number of points, which might make the search quite computationally demanding.
To avoid this problem, a common solution (also adopted by the idealista team) is the implementation of the Visvalingam–Whyatt algorithm, used for line simplification.
This is not the place to go into detail about this algorithm (more information is available on Wikipedia); the only useful thing to mention here is that such a solution allows a dramatic reduction in the number of points used to define the polygon, thus simplifying it while keeping an almost identical shape.
With this solution, even freehand shapes become manageable, avoiding the risk of overly complex polygon-based queries.
The Visvalingam–Whyatt algorithm is not the only post-processing algorithm applied to polygons. Indeed, there are several other issues that need to be solved before a polygon is really useful for performing searches.
Other actions required are aimed at filling holes within shapes, and closing curves (in situations where the last point does not coincide exactly with the first).
An additional procedure is also used to identify crossover paths. Imagine, for instance, that a user draws a figure-of-eight shaped polygon, in which two lines cross each other. The polygon-based search does not support such an abnormal shape, which is actually made up of two separate polygons sharing a single vertex.
The issue is solved by splitting the polygons every time a crossover is recognised. In this way, the system can perform a sub-search for each sub-polygon, and all the partial results can finally be put together and returned to the user as requested.
It is worth mentioning that all this processing is performed by means of a Java backend, exploiting the features provided by the Java Topology Suite (JTS).
Polygon-based search
Now that the shape-related data representation and management has been clarified, let’s take a closer look at how the actual search is performed.
There are many search frameworks that might be suitable for polygon-based searches. Among them, Elasticsearch is probably one of the best known and respected. However, the team decided to opt for another solution, which was already in use before the introduction of the ‘draw a search’ feature (and even before Elasticsearch’s first release): Apache Solr.
Apache Solr exploits a semantic engine written in Java and based on Lucene. Major features include full-text search, hit highlighting, faceted search, real-time indexing, dynamic clustering, database integration and NoSQL features.
As well as these features, Apache Solr also allows users to search for point coordinates within a specific area, which is exactly what the idealista team required. This feature is known as spatial search, and it is described in the Apache Solr documentation.
All the locations of properties for sale are stored within a database as 2D coordinates. Solr thus allows retrieval of all the locations situated within a specific polygon, as long as such a polygon has no holes or crossovers (which explains the need for the aforementioned post-processing techniques).
Conclusions
It is clear by now how many issues may hide behind the hood of an apparently simple feature. Dealing with user selections and spatial data requires several constraints to be managed properly.
The idealista case discussed here is an excellent example of how development teams need to continuously find new solutions to unexpected issues. Using the right tools, such as JTS and Solr in this specific context, is crucial for those who wish to speed up the development process and increase the maintainability of the codebase.
