Cartographic interface – simple or complex?

At its core, what exactly is a cartographic interface? On the one hand, it seems simple – you barely need to draw anything, because YOUR ENTIRE INTERFACE IS THE MAP. But let’s try to take a closer look at this question.
In this article, we will focus on data visualization in 2D. The specifics of creating interfaces for 3D will be covered separately.
The questions related to cartographic interfaces can be divided into two main categories:

• Rules for data visualization. The usability of your solution primarily depends on how effectively you solve the problem of data visualization, as well as the supporting map elements.
• Toolbox visualization. This includes map navigation, data editing, and auto-filling functionalities.

As with any interface, it must be built around a clear and well-defined purpose. The design and structure of a cartographic interface can vary dramatically depending on the application – whether it’s for driver navigation, agricultural field monitoring, or real-time tracking of emergency response teams. Each use case demands a tailored approach. The type of information displayed, its prioritization, whether it appears within the map view or in a separate panel, and even the size and placement of control elements – all these factors must be aligned with the specific goals of the system. An  effective interface starts by understanding why and for whom it is being built.

Let’s outline a few key questions that must be addressed when developing a cartographic interface. To begin with, we need to consider what we are visualizing.

1. Choose the right map base layer

Pulling map data from Google, Mapbox, or OpenStreetMap is not the same – each source has its own strengths and limitations. The base map should be selected specifically to support your application’s goals. In some cases, it may be necessary to offer multiple base layers, allowing users to switch between them depending on the task at hand.

• If it’s high-resolution satellite imagery, ensure that the data is updated at the necessary frequency to meet your specific requirements.
• If you’re working with multispectral imagery, ensure that the data is visualized using the correct band combinations for your needs. For agricultural solutions, you’ll need a False Color combination rather than Natural Color, as the infrared band is essential, not the traditional RGB (Red-Green-Blue) bands.
• If it’s vector data, ensure that it meets the required level of accuracy for your needs.

Don’t hesitate to use paid services! The development of your solution already incurs costs, and if it doesn’t deliver results simply because you didn’t invest in the necessary data, who are you ultimately harming?

Finally, consider your own map base layers! If you have regularly updated data for a specific area and access to historical data, why rely on third-party base layers? Build your own mapping service! In some cases, you could even develop a local service that competes nationally – even with Google – simply because your data is more frequently updated or more accurate.

2. Information visualization order

This part is simple: at the bottom is the map base layer, above it are your raster layers, then come vector polygon layers, followed by vector line layers, and at the top – vector point layers.

Here are a few tips:

• Remember multispectral imagery: if your image has 7 bands, only 3 can be displayed at any given moment. Choose the band combination wisely.
• Consider using indexes. Sometimes, indexes visualize information more effectively than raw bands. Also, a single index may be calculated using more than just three bands.
• Color your data meaningfully. Don’t just apply a standard color scale. For example, if you color all pixels from red to blue, it shouldn’t be the same whether your data values range from 0 to 100 or from -10 to +10. Study what exactly you are showing, how to divide the value range into meaningful intervals, and which values should draw the user’s attention. It’s similar to Google Maps navigation – when the road ahead appears red or dark brown, you instantly know it’s better to avoid it. These colors directly reflect average traffic speed. The same applies in agriculture. Suppose you’re monitoring a wheat field. You know that by a certain date, a specific variety of wheat should fall within a certain NDVI range. Highlight pixels in the wheat fields that fall within this normal NDVI range in green, and those outside the expected range in yellow or red.
• Remove unnecessary layers. Have you noticed that when you turn on navigation in Google Maps, the building layer disappears? That’s purposeful – at that moment, only the road network matters, and other details would distract you and clutter the map. The same goes for your own data. In the NDVI example above, you should display information only for the fields you’re interested in. The NDVI is calculated for the entire image, but why show values for water bodies, forests, roads, or cities if they’re not relevant?
• Identify which factors distort the data, and highlight any distorted information. If there’s a chance that the data at a particular point is inaccurate, it’s better to warn the user before they have a heart attack. For example, haze and thin clouds can make NDVI values appear as if the crops in a field have died and need to be replanted. What should you do? That’s right—find a satellite and spectral band that can filter out the haze and display the haze distribution over the fields of interest.
• Transparency does not work well with raster data. If you need to work with a series of rasters taken at different times, don’t try to overlay them using transparency tools. Rasters are not uniform, and you’ll end up seeing nothing useful. Instead, use tools like Swipe or Flicker for manual comparison. Even better – take the time to develop a dedicated feature that performs the image comparison for you. This could be a difference image (don’t forget about proper color mapping and removing irrelevant data!), or even automatic generation of vector objects – particularly useful if you’re tracking changes in forest boundaries, riverbeds, or the surface area of a reservoir.
• Choose the appropriate method for displaying different types of thematic information in vector data. For example, don’t use fill colors to show absolute values – they are better represented with charts or by varying the size of symbols. In the agribusiness context, for instance, there’s no need to color-code fields based on total crop yield. Instead, use color to represent relative indicators—such as yield per hectare (e.g., quintals per hectare) and similar metrics.
• It’s better to place vector data over raster, rather than stacking raster on raster. A drawn vector object typically has smoother and clearer boundaries than a raster region. So, for example, if you want to display areas covered by clouds or cloud shadows, generate vector objects and show them as vector layers. This will make it easier for users to interpret and work with your solution.

3. Optimize the visible map area

 As we move into the supporting elements of your map, it’s important to follow one core principle: every supporting element takes up screen space and reduces the visible map area. Therefore, only display the supporting information that the user needs at that specific moment. Ideally, such elements should appear on click, rather than being constantly visible.

The legend is one of the primary supporting elements. In addition to creating a visually appealing map, you also need to clearly explain to the user what they’re looking at.

Here are some useful tips for designing your legend:

• Minimize the number of gradations in what you are visualizing. In the example with wheat and NDVI, there could be gradations such as: normal, below normal (fertilizers needed), significantly below normal (crops have dried out), above normal (suspicion of weed growth).
• Choose the right scale. It doesn’t necessarily have to be linear or uniform.
• Visualizing the legend on the map. You will have many layers, but usually the user works with one or two, the rest are presented ‘just in case’. Here are some tips to take into account:
  • rest are presented ‘just in case’. Here are some tips to take into account:
  • there’s no need to display the legend for all layers
  • for the necessary layers, the legend can be shown on demand (or permanently, if the screen size allows)
  • in some cases, the correspondence of an object to the legend can also be displayed next to the cursor. However, this information should be minimized both in terms of volume and duration of display. Typically, the area the user hovers over with the cursor is of the most interest to them. If we cover it with an overlay showing explanatory values, it could reduce the user’s efficiency in working with the data, and as a result, negatively impact the entire solution.

4. The scale

Often, it’s important for the client to remember the approximate size of an object. Therefore, it’s very convenient to display a linear scale on the map—a segment of a specific length, with labels showing the corresponding distance on the ground (and these values should change dynamically as the user zooms in or out).

5. Attribute Information

It can be displayed either in the form of a table (which will partially or fully overlay the map window), or, like with the legend, the information can be shown on the map next to each object (for example, the vehicle’s serial number, fuel level, order number, and so on).

6. What to display on the map at the start?

A very important point – if your map has a large extent, it’s crucial to determine which area should be displayed initially. This could be:

• Your current coordinates (just like in Google Maps)
• The coordinates of your last project (e.g., the most recent data acquisition from your UAVs)
• The current coordinates of a tracked asset (e.g., a train, ship, or vehicle)

Visualizing the tools

 The key principle here is that the map should remain the focal point, and any toolboxes (supporting map elements) will inevitably overlay the map, thus limiting the user’s field of view. It’s important to consider how these tools are presented. Let’s explore a few examples of the tools.

1. Navigation tools

This includes zoom buttons, pan controls, the map’s orientation to the north, etc. We recommend implementing these tools not as buttons, but by defining the logic behind user actions. For example, when using a computer, it’s important how the map responds to scrolling. When working with touchscreens, it’s essential to consider how the map reacts to user gestures. We suggest keeping buttons only for specific navigation options, such as zooming in on an object, or switching to predefined scale values (e.g., 1:500, 1:5000, etc.).

2. Editing tools

It’s difficult to set universal rules here, but perhaps the most important principle is this: understand how the tool is meant to work, and do everything you can to help the user edit accurately and efficiently. For example, if the task involves digitizing an object, display a small zoomed-in window near the cursor to allow for more precise editing. From my experience developing advanced AI-powered editing tools, I can say that automating routine tasks truly motivates users –  it allows them to focus on more complex and meaningful analytical work, rather than spending time on basic digitization.

3. Is a Table of Contents (ToC) necessary?

Everyone who has studied GIS has been taught that layer management tools are essential. However, in practice, your user is utilizing the solution to solve a specific task based on geospatial data – often with predefined data configurations. That’s why we recommend not providing the full flexibility typical of traditional GIS software, but instead offering preset layer and toolbox configurations that are tailored to the user’s specific workflow. This way, the visualization setup is typically predefined in our solutions, which significantly standardizes and simplifies the experience for different users.

4. Attributive data entry

Here, it’s crucial to use every available method of auto-filling (such as automatically populating coordinates or importing attributes from other sources) and to minimize the potential for user error. This can be done through dropdown lists for each field, input templates for specific fields, and other interface enhancements.

Conclusion

Thus, despite the apparent simplicity of a mapping interface, as you can see, there is still a great deal to consider when designing your own map interface. On one hand, it’s simply about displaying a map – but on the other hand, the map must be presented correctly in order to help achieve the desired results.