• Skip to primary navigation
  • Skip to main content
  • Skip to footer

Codemotion Magazine

We code the future. Together

  • Discover
    • Events
    • Community
    • Partners
    • Become a partner
    • Hackathons
  • Magazine
    • Backend
    • Frontend
    • AI/ML
    • DevOps
    • Dev Life
    • Soft Skills
    • Infographics
  • Talent
    • Discover Talent
    • Jobs
    • Manifesto
  • Companies
  • For Business
    • EN
    • IT
    • ES
  • Sign in

Vito GentileMay 26, 2021

Draw a Search: Implementing Polygon-based Searches on Maps

Backend
Draw a Search Implementing Polygon-based Searches on Maps
facebooktwitterlinkedinreddit

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. 

Recommended article
May 13, 2025

Start building REST APIs with Django REST Framework

raffaelegrieco.it

raffaelegrieco.it

Backend

An overview of how the team implemented this particular feature, and the kind of technical constraints the development team had to deal with follows.

Table Of Contents
  1. idealista’s web and mobile apps
  2. Technologies
    • Web app
    • Mobile
  3. Draw a search: polygon management
  4. Polygon-based search
  5. Conclusions

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.

Screenshot from the Idealista app, showing results gathered from the draw-to-search feature.
Screenshot from the idealista app, showing results gathered from the draw-to-search feature.

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.

GIF: Graphical representation of line simplification algorithm. (source: Wikipedia)
Graphical representation of line simplification algorithm. (source: Wikipedia)

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.

Logo of 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.

Related Posts

Top 10 online platforms to practice Python every dev should know

Lucilla Tomassi
May 13, 2025

.NET Refactoring Series: Episode 1 — How to Approach Service Refactoring

giovanni-ferrari
April 2, 2025

Queueing Without a Queue: The PostgreSQL Hack

Puppo92
March 13, 2025

How to tell if you’ve got what it takes: let’s do a code review

Matteo Baccan
January 14, 2025
Share on:facebooktwitterlinkedinreddit

Tagged as:Java Mobile Node.js NoSQL User Experience

Vito Gentile
I’m a data scientist, tech writer, software developer with experience in mobile, web (full-stack) and Python programming, and former researcher with interests in human-computer interaction. I thus have a multi-faceted experience in the area of software development, and that’s why I love my job(s)!
Bring More AI/ML Projects to Production by Increasing Access to Primary Data
Previous Post
C++ to Microservices: Back-end Migration to Continuous Integration
Next Post

Footer

Discover

  • Events
  • Community
  • Partners
  • Become a partner
  • Hackathons

Magazine

  • Tech articles

Talent

  • Discover talent
  • Jobs

Companies

  • Discover companies

For Business

  • Codemotion for companies

About

  • About us
  • Become a contributor
  • Work with us
  • Contact us

Follow Us

© Copyright Codemotion srl Via Marsala, 29/H, 00185 Roma P.IVA 12392791005 | Privacy policy | Terms and conditions