Adding Geolocation Support to Liferay 7.0

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

Blogs
Great work Juan!
We LOVE the geo functionality you are working on; thanks again for the effort! ;)

Cheers, J.
We are pleased to this blog, because we have developed a geolocation solution for Liferay 6.1 and 6.2 to display and search all default assets and custom assets, across a Google Map, OenStreet Map or Bing. This solution called MapIt and it's present on MarketPlace and won at the last Liferay Contest. So for us is an amazing news have a built in solution to do all this feature.
Sorry but the best part for me is :
"we are currently implementing DDMStructure based custom fields"

It's an incredible powerfull solution !
I like it, keep up the good work! :-) And what about extending the geolocation support to any type of asset? For example, with a dedicated table and a taglib? So even assets that don't use the DDM framework can be geolocalized.
IHMO, adding geo-localization only as DDM filed is only a good start.

I agree with Andrea, this has to be added as a taglib to allow people to use it on custom asset or inside standard assets (MessageBoard, Blogs, Wiki).

Like rating system, geoloc needs to have his own database table, that allow developer:
* to do sql having that table in the from clause (power)
* to have geoloc in a standard field inside Indexer
* have multiple coordinates linked to a single element

Actually (6.2) an Asset Publisher allow you to filter or order for DDM fields only if you configure it with a specific asset subtype. This is a big limitation if I want, for example, implement an AssetPublisher showing WebContent and Documents related to a specific GeoLocation.
With a standalone entity this use-case can be more easy to solved.

Having a standalone table you can use database specific geospatial functionality to solve problems like:
* things 30km far from this point
* things inside NorthWest-South-East rectangle

On the UI side, you have to allow user to choose a position different of the one detected by gps.
For standard browsers would be good to have a popup with a map and a search field.

As Maps system both Google Maps and OpenStreetmap have to be implemented. Better if maps engine is plugable.
Wow! So many comments! Cool! emoticon
Here are some answers to your questions:

- Some of you ask for supporting geolocation on assets. We are planning something better: we are going to add this as Expando field type when we move Expando to DDM, so every entity (and not only assets) will benefit from this.

- We have created JS modules that allow to create maps and listen to events to get data and show the info. We support both GMaps and OpenStreetMaps

- The new taglib liferay-ui:maps make use of these modules to geolocalize or show geolocalized modules.

- The UI team is working to make these components OSGi modules, so that you can deploy and use any kind of map implementation and also mae them available as marketplace apps.

- We'll write another more technical blog entry when we have the OSGi modules ready for you.

Thanks for your feedback! Keep it coming! ;)
Juan
Awesome, this new feature will rock ! I especially love the map asset publisher.

Since you asked for thoughts and ideas, here's what poped in my mind :

- A new search facet (results within 500m, 5km, 50km of user location) is definitely something we can use,

- Add some geoname lookup, so that users can type a street address instead of finding a place on a map (in the case someone will want to add content located somewhere they are not)
Hi Thomas! Thanks for the feedback
The search facet is something we are currently analyzing and good news are that geoname lookup is already done! ;)
I'll update you about our progress
Best!
Juan
I'm not so excited about DDM. Actually the storage can be an XML string inside a table field, or Expando Tables (until it will be merged inside DDM).

Let me identify a use case: I want to have the list of Blogs Entry, Wikis, And CalendarBookings geolocated inside a rectangle identified by NW="45.566265, 12.151319" and SE="45.403069, 12.445890".

AssetPublisher ootb uses search engine to retrieve the assets I'm able to see. To build a valid query I need to have the geo-coordinates inside the index.
And for every coordinate I have to do a specific filter "longitude between W and E", "latitude between "N and S".

Using Expando I can have the Blogs one called "Place", the Wiki one called "Where" and Calendar one called "Location".
I know, is a strange worst case, but this can happen.
I we have to provide a good interface to allow user to configure AssetPubblisher to gain his goal.

And if want, or need, to use database to collect the same assets?

It is not simple to make a query where the condition is based on elements inside a string field. Maybe some db-engine are able to do that more powerfull that others.
But the performance are not exciting.

DDM are powerfull but doesn't covers all needs. Sometimes users prefer to create a portlet with custom assets to have full control of data via indexer and via SQL.

To solve questions like "5Km from this point" actually I'm using database geoquery extensions. Having coordinates stored as known fields helps alot
Thanks Mauro, those are definitely good points.

A counter argument could be that in some cases you need two fields with coordinates.

Maybe one solution that would address all needs would be to have an standardized custom field for the location that has a predefined name. It will still be possible to add additional fields of type "Location" with custom names if needed.

What do you think?
Hi Jorge,

actually I'm not able to argument, in terms of performance or custom needs, if your solution to have geo location inside DDM infrastructure is good or worst about having it in a specific database table.

We have implemented a geo solution on Liferay 6.0 and we decided to have a separate table (with two separated field for latitude and longitude) to be able to filter assets by coordinates (in 6.0 Asset Publisher uses Demoticon. And sort it.
And have a taglib to allow use to add coordinates to standard assets but also to custom ones.

In the Marketplace there are some plugins developed by 3F Consulting. They use custom fields (two separated field for latitude and longitude) to add coordinates to the assets and are able to filter it. Some filters are done on client side other server-side using Indexer (because fields has standard name) or DB (because Expando values are stored on Demoticon.

I hope the final liferay solution will allow developers two goals:
* easily adds coordinates (at least one pair) on custom assets
* easily grap assets related also to a "geo-rectangle"

Having a framework providing it we can provide information for "augmented reality solutions", "internet of things solutions", "mobile / desktop / portlat apps", everything emoticon

Is it possible to modify that geo api that way user can add route when adding new article, without creating custom portlet? Just the same way as adding that geo?