Structure Data for Honeycomb
Honeycomb Maps is a tool for visualizing geospatial (location) data. The data you use with the tool must be structured in a format that Honeycomb can understand.
Supported types of location data
All data sources used with Honeycomb must have at least one column that contains location data. This location data can be one of the following:
| Type | Description | Example data |
|---|---|---|
| Points | Individual locations, like stores | latitude: 40.7128 longitude: -74.0060 |
| Lines | Routes or paths, like a vehicle route | LINESTRING (-74.006 40.713, -73.935 40.730) |
| Polygons | Areas, like the boundary of a city | POLYGON ((-74.04 40.68, -73.94 40.68, -73.94 40.78, -74.04 40.78, -74.04 40.68)) |
| H3 cells | Hexagonal grid areas | 8a283082a677fff |
Note: The chart above uses WKT encoding for line and polygon data, but GeoJSON can be used as well.
Raster Data
Honeycomb does not support raster data. If you are using raster data, we recommend performing your analysis with specialized raster tools and then producing an output with metrics per H3 cell or per polygon area. This output can then be visualized with Honeycomb.
Supported file types
The prior section described the type of location data that Honeycomb Maps can load. This data should be stored in one of the following file formats:
- CSV
- Parquet
- GeoJSON
- KML/KMZ
- Google Sheets (only when connected to Google Drive)
For CSV and Parquet file types and Google Sheets, see the table data requirements section below.
TIP
Honeycomb Maps offers a free geospatial file converter on our website. This tool converts specialized geospatial formats like Shapefiles (.shp) or FlatGeobuf (.fgb) to a spreadsheet format that is easy to use and compatible with Honeycomb.
Table data requirements
Table data formats (CSV, Parquet, Google Drive) are very common. However, they are not specifically geospatial file formats, so location data within them needs to be structured in a certain way so that Honeycomb can use it.
Database Tables
When querying data from Snowflake or other databases, tables you query with SQL should follow the guidelines here
Point data
Point data requires two separate columns for latitude and longitude, using the WGS84 coordinate system. Honeycomb automatically detects these columns.
Honeycomb supports 5-10 million points depending on the end user's computer.
H3 indexes
H3 indexes can be provided as a string in hexadecimal format (8a283082a677fff) or as an integer (622203769624952831).
H3 is efficient for large datasets and offers better performance with massive data. However, it requires pre-aggregation and is therefore less granular than point data.
Geography data
Honeycomb supports Line and Polygon (including MultiPolygon) data types inside of data tables. The data must be encoded in GeoJSON or WKT format and use the EPSG:4326 (WGS 84) coordinate system.
Honeycomb supports visualizing approximately 10k polygons and 20k linestrings (depending on the number of vertices) on the screen at a time without performance degradation. Filters can be used to limit the number of rows displayed on screen.
Structuring data in Snowflake tables
The Honeycomb Maps Snowflake Native App can query data directly from Snowflake tables. Snowflake tables should follow the structure for tabular data described in the previous section.
Snowflake columns with the GEOGRAPHY type will be recognized automatically.
Snowflake also provides native H3 functions, which can be useful for pre-aggregating data to display in Honeycomb Maps.
Troubleshooting issues
Data loads, but objects don't appear where you expect on the map
This is typically caused by a coordinate system issue.
Honeycomb requires coordinates in EPSG:4326 (WGS 84), the standard CRS used by GPS devices, web APIs, and GeoJSON. Coordinates are expressed as latitude and longitude in decimal degrees:
| Axis | Valid range | Meaning |
|---|---|---|
| Latitude | -90° to +90° | South Pole to North Pole |
| Longitude | -180° to +180° | West to East of the Prime Meridian |
If your coordinates have more than three digits before the decimal point, they are not in EPSG:4326. They are likely in a projected coordinate system:
| CRS | Typical value range | Units |
|---|---|---|
| EPSG:4326 (WGS 84) | lat ±90, lon ±180 | degrees |
| EPSG:3857 (Web Mercator) | ±20,037,508 | meters |
| UTM zones | easting ~100k–900k, northing ~0–10M | meters |
| State Plane (US) | varies, often 6–7 digits | feet or meters |
Other common issues
- Swapped axes — GeoJSON uses (longitude, latitude) while Google Maps uses (latitude, longitude). If your latitudes range from -180 to 180, the axes are likely swapped.
- Points at (0, 0) — Known as "Null Island", this usually indicates missing or default data rather than real locations.
- Points in the wrong place — If data meant for San Francisco shows up in the ocean near Africa, lat/lon are probably flipped.
A polygon column exists in your data, but Honeycomb doesn't show it as an option for the Polygon Layer
This typically happens because Honeycomb doesn't detect the column type correctly.
When data is loaded, Honeycomb scans the first 5 rows of data to determine what type of geospatial data each column contains. If the first rows of a location data column are null, then Honeycomb will fail to recognize this column as a location data column and will not show it as an option for certain layers like the polygon layer.
To resolve this issue, add a [GEO_COLUMN] IS NOT NULL clause to your SQL query, or manually remove rows that are not valid geography objects.