Dear community!

Based on market research and community feedback, we’ve seen that more and more companies are using location-based information to make important decisions. Also usage of geolocation tools as a way to show map-based information to the end user is growing.

It is increasingly important to know where the information is being generated, showing maps of your entities, understanding where your users are filling in your forms from, or where they are uploading documents from. Showing maps with your offices’ location, training courses, etc is the norm on many IT projects nowadays.

This is why one of the Epics we are working for Liferay 7.0 is adding the geolocation layer to (y)our platform. The goal of this article is to explain the use cases we are covering with our current implementation in order to get your feedback, thoughts and ideas NOW we are in development phase (as opposed to after the official release, when it’ll be too late to quickly iterate).

#1: Geolocate documents, web contents and ddl records

The first feature the engineering team has been working on is adding the geolocation field to DDMStructures. This means that now you can add an additional field to your web content structures, document types (therefore images) and DDL records. Every time a user creates one of those assets, he’ll be able to define “where” it is.

The geolocation system can work in two different ways: first by letting the system know where you are using HTML5 (specially useful on mobile devices) or second by the user giving the system directions to a concrete place

[Note that we are currently implementing DDMStructure based custom fields, so when that is ready, this geolocation field will be available not only to assets but to all entities in the portal!]

#2: Show maps of assets

After the content is geolocalized by your users, the next step is to show that content on a map. For that, we’ve added map support to Liferay. We have created a reusable taglib that you can use in your portlets, ADTs and templates. Out of the box we have an ADT called “Maps” that can be used on your Asset Publisher: once you choose it, a map view will be loaded and you’ll see your geolocalized assets on it. Obviously, if you define filters in that Asset Publisher, they’ll be respected. Cool, isn’t it? ;)

#3: Support for different map providers

We’ve also thought on those who want to have the power to decide which map provider to use. We’ve made it configurable, and out of the box we offer Google Maps and Open Street Maps support, but of course, it is extensible, so you can create your own integration for additional map providers.

Conclusions

By this time you already know that we LOVE beta testers and feedback and that is why we share all this info with you. Before we continue implementing more user stories related to geolocation, we wanted to ask you: what do you think about these features? Do you think they’ll be useful for your projects? Are you thinking in a user case we are not covering? How could we improve it to better suit your needs?

Thanks for your help and passion!

Juan Fernández