Google Maps on Steroids - Part 1

Mapping functionality is something I have been implementing since I started developing web applications 18 years ago. Google Maps has always been a great tool to include mapping functionality in my applications. 

Mendix has offered Maps widgets, including Google Maps (and others), in Mendix applications. 

There are 10 Google Maps widget options in the Marketplace and 15 map-related content options in the Marketplace. With 25.000+ downloads, it is undoubtedly a community favourite type of functionality.

Unfortunately, the basic Google Maps options are somewhat limited. Although there are numerous extensions and a few alternatives, it can be challenging to find all the necessary functions for specific projects in one solution. Ideally, this solution would be versatile and encompass all the desired features without being too complex to configure when integrating the functionality into an application.

For this reason, we requested that Jelte develop a very feature-rich Google Maps solution. The core requirements are simple:

• Easy to implement
• Performant
• Open to interactions from the rest of the application
• Future proof
• Maintainable by others

And Jelte sure delivered. While the solution is extremely feature-rich, it is relatively easy for anyone with Mendix app-building experience to implement. Anything that you need (or we need) is in there. While it has not yet been required, anyone with Mendix widget-building experience may maintain the solution.

Features

Implementing the Google Maps solution starts with configuring the widget. 

Some basics are required, like the API key (read more about configuring this here).

If multiple maps are on the same page, you want to configure a Map ID to identify each specifically.

To keep the configuration manageable, select which features you would like to show the configuration for. Each configuration item you enable will add an additional tab. 

UI customisation

Customising the user interface (UI) is divided into multiple parts of the widget configuration. 

UI

From the UI tab, you may set the dimensions for the entire map area to the control size (all the button-like elements on the page).

On this tab, you can also configure additional Google Map styles. This allows you to customise your map to look any way you like, like styling a web application.

Controls

The Controls tab allows you to customise where the controls on the map are located and if they are enabled. 

Map view customisation

When the map is loaded, the type of map can be configured. Depending on your scenario, you can show the roadmap, satellite view, a hybrid of those two, or the terrain map. 

The static centre will decide which centre will be used to orient the map around the default. Who can guess the default? 😄

However, you would usually want to configure the centre dynamically, perhaps oriented around the centre of the markers you are rendering. This can be accomplished by using the dynamic centre lat and long-expression values.

Combine that with the zoom level, and your map will load in the perfect context.

Marker rendering

Markers may be rendered via two methods. As a single marker with the option to drag and drop the marker (editable). Or a group of markers. 

Both are rendered based on the data from the context within which the map is placed. 

The configuration of these markers starts in the Data Sources tab.

Single Data points

The single data points are relatively easy to configure. After all, you can define everything in the edit popup's four tabs. Starting with the general tab where you define the marker as data type Marker and logic that enables the marker (default: true).

The data tab defines where the marker is rendered and what the title (tooltip on hover) will show. When you use the expression, the marker is never editable. But when you use attributes for the latitude and longitude, you may make the marker editable. Moving the marker, in that case, will store the new latitude and longitude in those attributes.

The Interaction tab allows you to specify the on-click and on-change behaviour. The on-change is only available when the marker is editable.

The UI tab determines how the marker is rendered. You may opt for a marker icon, a static image or one from an object. 

If you want to make the marker dynamic, specify the ID here. Read down below how dynamic marker images are rendered.

Enabling the info window will allow you to render an “advanced tooltip” when clicking on the marker. The contents of this info window may be placed in an area that will be rendered on the page

List Data

List data works very similarly to static markers. Of course, in this case, you will need to retrieve a list of objects to render.

Retrieving the data works like any other data source configuration in Mendix.

A small workaround has been implemented because it is impossible to store the latitude and longitude directly in attributes from the actual object. You store the data of the changed object (id) and the latitude and longitude in an attribute from a non-persistent object and then parse that in the on-change logic.

The UI tab only has the dynamic marker ID option. This is done as the list of data sources is expected to have multiple types of markers that you would want to configure dynamically.

Dynamic marker images

When you configure the marker ID for the single or list data markers, you can define those markers in this tab. The easy option is to configure the default marker. However, custom markers are where the fun starts.

You can configure single identifiers to match the marker IDs or combine multiple items in a list to identify custom cluster icons. This latter option is particularly useful when multiple markers are essentially rendered in the same location when fully zoomed in. Assigning custom cluster markers provides a clearer overview for your users.

Clusterer

When you place more than one marker on your map, there is a high likelihood that, at several zoom levels, multiple markers will overlap. This is where the clusterer aids in organising the map markers while ensuring an acceptable interaction.

You may set an icon for the clusters that are used when no dynamic marker is found. Or you could render the cluster marker based on the styling properties. The min cluster size and grid size determine when markers are grouped. This is dynamically updated when the zoom level changes or additional markers are added to the map. 

When you reach the maximum zoom level, you will still want to allow the user to interact with those markers. The configured action will be triggered when you click on such a marker, and the marker details will be stored in the specified attribute. Furthermore, you can configure a specific information window that will open when you click on the cluster marker.

Layer rendering

Besides markers, you may render KML or GeoJSON layers. This will give a whole new dimension to your map implementation. 

You may configure the layers as a single data point (will only load one file/object) or as list data. 

KML file

KML format is only available to load from a file, which means that you must configure the data attribute to the file's contents. 

The widget will subsequently render the KML layer as specified in the file on your map. When rendering a list of files, all of them will be displayed. Unlike some implementations, the KML rendering does not require the KML to be publicly accessible. Everything is contained within the widget itself.

GeoJSON file

Rendering a GeoJSON file is especially useful when working with drawings on your map. They act similarly to KML layer files but just with a different format.

GeoJSON from database 

When using the drawing functionality of the widget, you will likely store the GeoJSON that describes those drawings in the database, as the data is identical to what you retrieve from the GeoJSON file. You may also utilise the expression data type in this case, although using an attribute will work perfectly.

Autocomplete

The auto-complete feature uses Google Maps to look up any place or address and suggest locations based on user input. 

When the user chooses a location, you will receive the basic data returned as a JSON in the attribute you configured or if you require the extended data. Both will be stored on an attribute you set.

By configuring an action, you may instantly process the data returned and use it in your logic.

Measurement

There are two measurement tools available. Measuring a straight line or an area by drawing a square on the map. For both options, you may set the units used for measurement. 

Selection

The selection tool enables you to draw a circle on the map, capturing every marker within that circle. When this occurs, an attribute is set with JSON or a Custom event is triggered. This custom event can be captured by any event listener in the client (JavaScript). With this, you may unlock an entirely different level of interaction with your markers.

Drawing

With this widget, you may draw additional markers, lines, squares, circles, or any shape you can create with a minimum of three connected lines. These drawings are then stored in GeoJSONJ format, which you can use at a later stage or even export if needed.

Elevation

To measure the elevation over a straight line (path), all you need to do is draw that line, and a JSON string is returned + you could trigger an action. We use this to show a nice graph of the elevation differences over the line pulled.

Directions

To render directions in our widget, you will only need to pass data from Google’s direction API to the widget; you may then specify your travel mode and, optionally, the styling you would like to apply. Of course, you will need to retrieve the directions data. We purposefully kept this outside of the widget as that grants more freedom. For the solution we built with OrangeCubes we wanted to minimise the required API calls. Previous solutions required a call in the widget and one server side to retrieve metadata from the API call. With this solution, we essentially saved 50% of the calls.

To be continued

This newsletter iteration has already become a long read (even with the images). This will be split into two. Next month, I will show you the runtime capabilities and make a demo project available to give you all a feel for the functionalities.

Subscribe to the Mendix Ignite newsletter to get notified once the next part is published!

#mendixignite #mendix #googlemaps #lowcode