Integrating Google Maps in Flutter Apps
Adding Google Maps to a Flutter app is one of those features that instantly makes an application feel alive. A map is never just a map. It is a place where your users search for a store, locate a delivery driver, choose a pickup point, compare routes, pin a favorite destination, or simply trust your app a little more because it feels grounded in the real world. Flutter makes this experience surprisingly smooth through the google_maps_flutter plugin, which provides a Google Maps widget for Android, iOS, and web. The plugin is federated, and its platform packages do not support every feature equally, so it is worth understanding the platform behavior early rather than discovering differences in the middle of a release cycle. The current package documentation also notes that Android support starts at SDK 24+, iOS at 14+, and web follows Flutter’s web support model. Google’s setup guide further states that you should enable billing, create an API key, and configure the key for all target platforms before you build your map experience.
What makes Google Maps in Flutter so appealing is the balance between power and familiarity. You can render a map, move the camera, add markers, draw polylines, display polygons, show circles, and react to user gestures without leaving Flutter’s declarative style. The GoogleMap widget is a stateful widget that exposes a rich set of properties, including camera position, map type, markers, polygons, polylines, circles, heatmaps, gesture controls, and callbacks such as onMapCreated, onCameraMove, onTap, and onLongPress. In other words, the map is not a special case outside your app architecture; it becomes just another widget in your UI tree, which means you can compose it with the rest of your screens cleanly.
Why Google Maps still matters in a Flutter app
There are plenty of mapping solutions in the ecosystem, but Google Maps remains a strong choice when your app needs broad recognition, familiar UI patterns, and a flexible set of map interactions. Users already know how to pan, zoom, long-press, inspect markers, and open routes. That lowers friction immediately. Google’s Flutter documentation describes the package as a way to add Google Maps data to iOS, Android, and web apps, while the map itself handles access to Google Maps servers, rendering, and gesture response. It also supports additional objects such as markers, polylines, ground overlays, and info windows. That combination is especially useful for apps in logistics, travel, food delivery, home services, property search, field sales, and event discovery.
A second reason Google Maps is still attractive is the ecosystem around it. A map alone is often not enough. Real products need geocoding, place search, route visualization, geolocation, and sometimes navigation. Google’s platform documentation places Google Maps for Flutter alongside the broader Maps Platform family, which includes Maps SDKs, Routes, Places, Geocoding, and Navigation-related products. That matters because app teams usually start with a map widget, then quickly grow into nearby tasks such as “find this address,” “show nearby results,” or “open directions.” It is reassuring to know that the Flutter integration sits inside a broader platform rather than as an isolated widget with nowhere to grow.
Before you code: the essential setup mindset
Before writing a single line of UI, it helps to approach the integration as a three-part job: platform preparation, API key management, and widget implementation. Google’s setup guide explicitly says to enable billing and create an API key before configuring the Flutter project. It also recommends using separate API keys and applying application restrictions for Android, iOS, and web. That is not just a formal requirement; it is a security habit that saves teams from nasty surprises later, especially when an API key leaks into a public repository or a build artifact.
This is the kind of feature where developers sometimes rush straight into the UI and then spend half a day debugging a blank map because one platform configuration is missing. The smoother path is the boring one: verify prerequisites, add the package, configure each platform, then build the widget. Google’s official guide is structured exactly that way, and it is a very sensible order.
Add the package
The Flutter package you need is google_maps_flutter. The package page describes it as a Flutter plugin that provides a Google Maps widget. The package also states that not all functionality is available on all platforms, which is important if you are planning a single codebase across mobile and web.
dependencies:
flutter:
sdk: flutter
google_maps_flutter: ^2.6.1
The exact version you use may vary depending on your project, but the idea stays the same: add the package, fetch dependencies, and then let Flutter wire the platform implementations through the plugin system. Flutter’s own package and plugin documentation explains that plugins are the mechanism for using platform-specific code from a single app-facing package.
After adding the dependency, run:
flutter pub get
If you create a fresh project specifically for this feature, Google’s setup guide shows the typical flow with flutter create and then flutter pub add google_maps_flutter. It also notes that the sample project can target iOS, Android, and web, while desktop apps are not supported by the Google Maps SDK outside the browser at this time. That limitation is easy to miss, so it is better to design for it upfront rather than assume the same map experience will run everywhere Flutter can compile.
Android configuration
Android setup usually involves three things: setting the minimum SDK version, storing your key securely, and making sure the manifest passes the right metadata to Google Maps. Google’s setup guide recommends setting minSdkVersion to 21 in android/app/build.gradle. It also recommends using the Secrets Gradle Plugin for Android, storing the key in local.properties, and injecting it into the manifest through the com.google.android.geo.API_KEY metadata name. The documentation specifically says that this metadata name is the recommended one and warns that only one API key metadata name should be specified.
Here is a clean Android setup pattern:
android {
defaultConfig {
applicationId "com.example.google_maps_in_flutter"
minSdkVersion 21
targetSdkVersion flutter.targetSdkVersion
versionCode flutterVersionCode.toInteger()
versionName flutterVersionName
}
}
If you are using the Secrets Gradle Plugin approach, your local.properties may contain:
MAPS_API_KEY=YOUR_API_KEY
And your AndroidManifest.xml should include:
<meta-data
android:name="com.google.android.geo.API_KEY"
android:value="${MAPS_API_KEY}" />
This is one of those tiny pieces of configuration that can decide the entire success of the integration. When a map does not appear, the cause is often not the Dart code. It is the Android manifest, the min SDK version, or the API key restriction settings. The official docs make clear that the com.google.android.geo.API_KEY metadata is the recommended approach for Google Maps-based APIs on Android and that the older com.google.android.maps.v2.API_KEY name is kept only for backward compatibility.
iOS configuration
On iOS, the setup lives in AppDelegate.swift. Google’s guide says to import GoogleMaps and call GMSServices.provideAPIKey("YOUR_API_KEY") inside application(_:didFinishLaunchingWithOptions:). That step is simple, but it must happen before the map is used. The official docs show the pattern clearly, and the sample AppDelegate includes the plugin registration alongside the API key call.
A typical iOS setup looks like this:
import UIKit
import Flutter
import GoogleMaps
@UIApplicationMain
@objc class AppDelegate: FlutterAppDelegate {
override func application(
_ application: UIApplication,
didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
) -> Bool {
GeneratedPluginRegistrant.register(with: self)
GMSServices.provideAPIKey("YOUR_API_KEY")
return super.application(application, didFinishLaunchingWithOptions: launchOptions)
}
}
If your map appears on Android but stays blank on iOS, this file is one of the first places to inspect. Because the Google Maps Flutter package is backed by native platform code, the iOS setup is not optional decoration; it is part of the actual runtime path.
Web configuration
Web requires its own handling. Google’s setup guide says to place the API key inside web/index.html, and the current web package documentation notes that if you use Advanced Markers you also need the marker library in the Google Maps JavaScript API script tag. The web package documentation further states that legacy Marker APIs are deprecated in favor of Advanced Markers, and that new features are expected only through the Advanced Marker system.
A simple starting point for web/index.html looks like this:
<!DOCTYPE html>
<html>
<head>
<base href="/" />
<meta charset="UTF-8" />
<meta content="IE=Edge" http-equiv="X-UA-Compatible" />
<meta name="description" content="A new Flutter project." />
<script>
// Google Maps JavaScript API bootstrap goes here with your key.
</script>
</head>
<body>
<script src="main.dart.js" type="application/javascript"></script>
</body>
</html>
For Advanced Markers on web, the package documentation shows that the Maps JavaScript API should include the marker library. It also notes that marker clustering on web uses the @googlemaps/markerclusterer library and recommends version 2.5.3. If your Flutter app needs dense point visualization, that detail will matter much more than it seems at first glance.
Building your first map screen
The core map widget is GoogleMap. It requires an initial camera position, and it can accept many optional behaviors and overlays. The official API documentation lists properties such as markers, polylines, polygons, circles, clusterManagers, heatmaps, tileOverlays, groundOverlays, onMapCreated, onCameraMove, onCameraIdle, onTap, and more. That means you can build a surprisingly rich map experience without abandoning the Flutter widget tree.
A very small but complete map screen might look like this:
import 'package:flutter/material.dart';
import 'package:google_maps_flutter/google_maps_flutter.dart';
class SimpleMapScreen extends StatefulWidget {
const SimpleMapScreen({super.key});
@override
State<SimpleMapScreen> createState() => _SimpleMapScreenState();
}
class _SimpleMapScreenState extends State<SimpleMapScreen> {
late GoogleMapController _mapController;
static const CameraPosition _initialPosition = CameraPosition(
target: LatLng(37.7749, -122.4194),
zoom: 12,
);
@override
Widget build(BuildContext context) {
return Scaffold(
appBar: AppBar(
title: const Text('Google Maps in Flutter'),
),
body: GoogleMap(
initialCameraPosition: _initialPosition,
onMapCreated: (controller) {
_mapController = controller;
},
myLocationButtonEnabled: true,
myLocationEnabled: false,
zoomControlsEnabled: true,
),
);
}
}
This is the minimum viable experience: render the map, keep a controller, and give the user a familiar map canvas. The GoogleMap widget’s constructor exposes the essential pieces you will reach for again and again, including camera setup, style, gesture handling, and overlay collections.
Moving the camera with intention
A map is only useful when it feels intentional. Users should not feel like they are staring at a static screenshot with a few controls. They should feel guided. That is why camera control matters so much. Google Maps Flutter exposes camera-related callbacks and a map controller that lets you animate or jump to new positions. Even though the widget itself is declarative, the user experience can still feel dynamic and responsive. The API documentation shows onMapCreated, onCameraMoveStarted, onCameraMove, and onCameraIdle, which are ideal hooks for syncing map state with the rest of your interface.
void _goToCity() {
_mapController.animateCamera(
CameraUpdate.newCameraPosition(
const CameraPosition(
target: LatLng(34.020882, -6.841650),
zoom: 13,
),
),
);
}
This kind of motion is small, but it changes the feel of the app. A sudden jump can feel mechanical, while a brief animation can feel thoughtful. In delivery apps, for example, you might animate from a list result to a store location. In travel apps, you might animate from a country overview to a city detail. In a property search app, you might animate when the user filters by neighborhood. The map becomes part of the narrative rather than a passive backdrop.
Markers that feel useful, not noisy
Markers are often the first overlay developers add, and for good reason. They are a direct way to show points of interest. The Google Maps Flutter docs explicitly say the package supports markers, polylines, ground overlays, and info windows. The GoogleMap API also exposes a markers set, and the package documentation lists Marker among the core map objects.
A marker example:
final Set<Marker> _markers = {
Marker(
markerId: const MarkerId('store_1'),
position: const LatLng(34.020882, -6.841650),
infoWindow: const InfoWindow(
title: 'Main Store',
snippet: 'Open today until 10 PM',
),
onTap: () {
debugPrint('Marker tapped');
},
),
};
And then attach it to the map:
GoogleMap(
initialCameraPosition: _initialPosition,
markers: _markers,
onMapCreated: (controller) {
_mapController = controller;
},
)
The trick with markers is restraint. Too many markers with no hierarchy can make a map feel like confetti. A more human design approach is to use markers with a clear purpose. For example, show only the most relevant stores, highlight the selected item, or cluster dense locations. The web package documentation specifically supports marker clustering and points you to the Google-maintained marker clusterer library for web use. That is a strong hint that clustering is not just a performance optimization; it is often the difference between usable and unusable.
Drawing routes with polylines
Polylines are one of the most satisfying parts of map work. They turn a set of coordinates into a story: this is the route, this is the boundary, this is the path someone actually takes. The Google Maps Flutter docs explicitly list polylines as supported overlay objects, and the GoogleMap constructor accepts a polylines set.
A simple route line might look like this:
final Set<Polyline> _polylines = {
Polyline(
polylineId: const PolylineId('route_1'),
color: Colors.blue,
width: 5,
points: const [
LatLng(34.020882, -6.841650),
LatLng(34.025000, -6.830000),
LatLng(34.030000, -6.820000),
],
),
};
Then:
GoogleMap(
initialCameraPosition: _initialPosition,
polylines: _polylines,
)
In real apps, the points usually come from an API response rather than hardcoded coordinates. A route service might return a polyline that you decode before drawing it. A field operations app might fetch a daily path from the backend. A travel app might display a walking route between stops. The map widget itself does not care where the line came from; it only needs a set of points and a clear design purpose. That separation keeps your Flutter code clean and easier to test.
Adding circles, polygons, and boundaries
When a map moves beyond “show one pin,” shapes become important. Circles help with radius-based search. Polygons help with service areas, geofences, neighborhoods, or map regions. The Google Maps Flutter API exposes both circles and polygons, and the package documentation lists them among the supported objects.
A circle example:
final Set<Circle> _circles = {
Circle(
circleId: const CircleId('coverage_area'),
center: const LatLng(34.020882, -6.841650),
radius: 1200,
fillColor: Colors.blue.withOpacity(0.15),
strokeColor: Colors.blue,
strokeWidth: 2,
),
};
A polygon example:
final Set<Polygon> _polygons = {
Polygon(
polygonId: const PolygonId('service_zone'),
points: const [
LatLng(34.020882, -6.841650),
LatLng(34.025000, -6.830000),
LatLng(34.030000, -6.835000),
LatLng(34.028000, -6.845000),
],
fillColor: Colors.green.withOpacity(0.15),
strokeColor: Colors.green,
strokeWidth: 2,
),
};
These shapes can make a map feel much more intelligent. A radius around a warehouse helps users understand delivery coverage. A polygon around a property zone helps buyers understand the area. A circle around a clinic helps people grasp appointment distance. Shapes are small design details, but they communicate service logic in a way plain text cannot.
Styling the map
Styling is where many apps quietly improve from “working” to “pleasant.” The GoogleMap constructor includes a style parameter, which means you can apply a custom visual style to match your app’s tone. This may sound minor, but map styling matters a lot in dark mode, in premium apps, and in products where visual coherence is part of trust. The same widget also includes properties such as mapType, compassEnabled, zoomControlsEnabled, trafficEnabled, buildingsEnabled, indoorViewEnabled, and liteModeEnabled, giving you control over both look and function.
A subtle dark-style approach might be:
GoogleMap(
initialCameraPosition: _initialPosition,
style: _darkMapStyle,
mapType: MapType.normal,
)
The style string is usually loaded from a JSON asset or a constant. That means your app can synchronize the map to a broader visual language instead of letting the native map defaults dominate the screen. A map that matches the app feels intentional. A map that ignores the app feels pasted in. The difference is small, but users notice it instantly.
Handling user location responsibly
User location is one of the features that makes a map feel personal, but it also requires careful handling. The GoogleMap widget includes myLocationEnabled and myLocationButtonEnabled options. Those flags are useful, but they do not replace permissions, privacy policy, or proper user communication. If your app shows the user’s location, it should do so transparently and only after the user understands why.
A practical pattern is to keep location off by default until the user requests it:
GoogleMap(
initialCameraPosition: _initialPosition,
myLocationEnabled: _locationPermissionGranted,
myLocationButtonEnabled: _locationPermissionGranted,
)
From a product perspective, this can dramatically reduce friction. You do not have to force location access on first launch. Instead, you can explain the benefit in context: “Show nearby drivers,” “Find stores near you,” or “Improve route accuracy.” The code is simple, but the user experience is much better when the permission request feels attached to a meaningful action.
A more complete screen example
Let us bring the pieces together in one Flutter screen. This example includes a map, a few markers, a polyline, a circle, and a button that moves the camera. The values are intentionally simple so the structure is easy to understand and adapt.
import 'package:flutter/material.dart';
import 'package:google_maps_flutter/google_maps_flutter.dart';
class MapDemoScreen extends StatefulWidget {
const MapDemoScreen({super.key});
@override
State<MapDemoScreen> createState() => _MapDemoScreenState();
}
class _MapDemoScreenState extends State<MapDemoScreen> {
GoogleMapController? _controller;
static const CameraPosition _initialPosition = CameraPosition(
target: LatLng(34.020882, -6.841650),
zoom: 12,
);
final Set<Marker> _markers = {
const Marker(
markerId: MarkerId('center'),
position: LatLng(34.020882, -6.841650),
infoWindow: InfoWindow(
title: 'Central Point',
snippet: 'This is the first marker',
),
),
const Marker(
markerId: MarkerId('second'),
position: LatLng(34.028000, -6.832000),
infoWindow: InfoWindow(
title: 'Second Point',
snippet: 'Another useful location',
),
),
};
final Set<Polyline> _polylines = {
const Polyline(
polylineId: PolylineId('demo_route'),
points: [
LatLng(34.020882, -6.841650),
LatLng(34.024000, -6.837000),
LatLng(34.028000, -6.832000),
],
width: 4,
),
};
final Set<Circle> _circles = {
Circle(
circleId: const CircleId('zone'),
center: const LatLng(34.020882, -6.841650),
radius: 1500,
strokeWidth: 2,
fillColor: Colors.blue.withOpacity(0.15),
),
};
void _moveCamera() {
_controller?.animateCamera(
CameraUpdate.newCameraPosition(
const CameraPosition(
target: LatLng(34.028000, -6.832000),
zoom: 14,
),
),
);
}
@override
Widget build(BuildContext context) {
return Scaffold(
appBar: AppBar(
title: const Text('Map Demo'),
actions: [
IconButton(
icon: const Icon(Icons.location_searching),
onPressed: _moveCamera,
),
],
),
body: GoogleMap(
initialCameraPosition: _initialPosition,
markers: _markers,
polylines: _polylines,
circles: _circles,
onMapCreated: (controller) {
_controller = controller;
},
mapType: MapType.normal,
zoomControlsEnabled: true,
compassEnabled: true,
myLocationButtonEnabled: false,
),
);
}
}
This is the kind of screen that developers can grow naturally. You can inject data from a repository, swap the markers from static to dynamic, connect the route to a backend, or move the map into a tabbed detail layout. The map remains a widget, not a special universe. That is one of Flutter’s biggest strengths.
Fetching map data from an API
Most real applications do not hardcode map points. They fetch them from a backend service. A restaurant app might request nearby branches, a courier app might ask for driver locations, and a marketplace might return all available pickup points. The Google Maps Flutter codelab explicitly frames the experience around fetching map data from a web service and displaying it as markers, which is a very common production pattern.
A simple repository approach might look like this:
class Place {
final String id;
final String name;
final double latitude;
final double longitude;
const Place({
required this.id,
required this.name,
required this.latitude,
required this.longitude,
});
}
class PlacesRepository {
Future<List<Place>> fetchPlaces() async {
await Future.delayed(const Duration(milliseconds: 500));
return const [
Place(id: '1', name: 'Place A', latitude: 34.020882, longitude: -6.841650),
Place(id: '2', name: 'Place B', latitude: 34.028000, longitude: -6.832000),
];
}
}
Then convert those records into markers:
Set<Marker> buildMarkers(List<Place> places) {
return places.map((place) {
return Marker(
markerId: MarkerId(place.id),
position: LatLng(place.latitude, place.longitude),
infoWindow: InfoWindow(title: place.name),
);
}).toSet();
}
The advantage of this structure is that the map screen stays focused on rendering, while the repository handles data fetching. That separation pays off quickly once you add filters, offline caching, loading indicators, or pagination. The map becomes the last step in a clean data pipeline rather than a dumping ground for everything the app knows.
Clustering for dense maps
Once you have many points, clustering becomes essential. A map with dozens or hundreds of markers can become unreadable very quickly. The web package documentation explicitly mentions marker clustering support and recommends the supported @googlemaps/markerclusterer version for web apps. On mobile, you will often solve the same problem by clustering on the Dart side or by grouping points in your backend. The principle is identical: reduce visual noise so the user can understand the geography at a glance.
A clustering mindset usually looks like this:
class ClusteredPlaceGroup {
final LatLng center;
final int count;
const ClusteredPlaceGroup({
required this.center,
required this.count,
});
}
Then you render a cluster marker instead of every single point. The cluster may show a count, a stack, or a custom icon. It is a small interaction that changes the feeling of the whole map. Users can explore the density first, then zoom in for detail. That progressive disclosure is often the difference between a map that helps and a map that overwhelms.
Performance and polish
Performance matters with maps because map screens tend to combine native rendering, overlays, asynchronous data, and gesture handling all at once. The package documentation’s warning that not all functionality is supported across all platforms is a reminder to test each target environment carefully. A feature that behaves nicely on Android may need adjustment on web or iOS. Likewise, platform-specific markers or web-only libraries may require different fallback behavior.
A few habits make a big difference. Keep your markers stable and avoid rebuilding them unnecessarily. Load large datasets in the background. Use clustering when point density grows. Avoid unnecessary camera jumps. Make sure your overlays are relevant, not decorative. When possible, preserve map state as the user moves through nearby screens so they do not lose context every time they navigate. The GoogleMap widget gives you the primitives, but the quality of the experience depends on the surrounding architecture.
Another practical detail is map mode selection. For some use cases, liteModeEnabled can reduce resource usage on Android, while mapType, trafficEnabled, and buildingsEnabled can be switched based on user intent rather than always being enabled. The better the map matches the job, the lighter the cognitive load on the user.
Legal notices and attribution
This is the part many teams forget until the last minute. Google’s documentation states that applications using the Google Maps for Flutter package must include the attribution text in a legal notices section, accessible from a dedicated menu item or an About section. It also says that you can get the attribution text by calling showLicensePage. This is not just paperwork; it is part of using the platform correctly.
A simple pattern is to add an About item in your app settings screen:
ListTile(
title: const Text('Legal notices'),
onTap: () {
showLicensePage(
context: context,
applicationName: 'My Map App',
applicationVersion: '1.0.0',
);
},
)
That small addition helps your app feel complete and compliant. It also signals care. Well-made products do not hide the details users may need later. They make them available in a predictable place.
Common mistakes and how to avoid them
The first common mistake is treating the map as a single Flutter-only configuration problem. It is not. Google Maps in Flutter is a cross-platform feature with native platform setup on Android, iOS, and web. If the map is blank or the key is rejected, the issue often lives outside Dart. The setup guide makes this clear by separating the Android, iOS, and web instructions into distinct steps.
The second mistake is overtrusting a single API key. Google recommends separate API keys and application restrictions for each platform. That guidance matters because a key that works in development might be too open for production, and a key that is overly restricted might fail silently in one environment. Keys deserve the same discipline as passwords, even if they are not secret in the same sense.
The third mistake is assuming every map feature is available everywhere. The package page warns that not all functionality is supported on all platforms. The web package documentation also highlights Advanced Markers and clustering guidance that are specifically relevant to web use. Designing with platform differences in mind avoids a lot of awkward “works on my device” moments.
The fourth mistake is allowing the map to become cluttered. A map full of markers, circles, and polylines without hierarchy is hard to read. The best maps are not the ones with the most overlays. They are the ones that answer the user’s question fastest. That usually means fewer visible objects, better grouping, and more thoughtful zoom logic.
A clean project structure
For anything beyond a demo, it helps to separate responsibilities. A neat structure might include a map screen, a map controller service, a repository for places, and a small model layer for points and routes. The screen should render the map and react to state changes. The repository should fetch and transform data. The controller or service should handle camera movement and map-specific behavior. This makes the app easier to test and easier to maintain when the product grows. Flutter’s plugin architecture is built for this kind of separation, because the widget lives at the app layer while native integration stays behind the plugin boundary.
A practical folder structure could be:
lib/
features/
map/
data/
places_repository.dart
models/
place.dart
presentation/
map_demo_screen.dart
map_controls.dart
services/
map_camera_service.dart
That is not a requirement from Google; it is simply a healthy way to avoid stuffing everything into main.dart. When a map feature becomes central to the product, structure matters as much as visuals. A clean layout makes it much easier to iterate without fear.
Thinking beyond the widget
A Google Maps screen is often only the beginning. Once the map is in place, product teams usually ask for place search, reverse geocoding, address autocomplete, route optimization, delivery ETA, map snapshots, custom overlays, or geofencing. Google’s broader Maps Platform documentation makes it clear that the Flutter package sits alongside other services such as Places, Routes, Navigation, and Geocoding. In practical terms, that means your Flutter map can grow with the product instead of being rebuilt from scratch every time a feature request arrives.
That growth path is worth planning for early. The app that starts with “show the nearest store” often ends with “show all nearby stores, filter by availability, draw the delivery radius, open the full route, and send navigation instructions.” A good map integration is one that can survive that evolution gracefully. The best time to design for it is before the first marker lands on the screen.
Final thoughts
Integrating Google Maps in Flutter is not difficult, but it rewards care. The package is mature, the widget API is rich, and the documentation is clear about the major setup requirements: enable billing, create an API key, configure Android, iOS, and web correctly, respect the platform-specific limits, and include proper attribution in your app’s legal notices. Once those foundations are in place, the rest becomes enjoyable. You can render a map, guide the camera, add markers, draw routes, cluster dense data, and shape the map around your product rather than forcing the product around the map.